方才一个开发经理和兄弟项目组的产品经理怼起来了。事情大概是，两边对接，那边希望我们出一个接口，而我们这边实际上是两个完全不同的实体概念，开发经理觉得应该提供两个基础接口，合成一个不科学。 吵得难分难解，我则狗在一边不说话，希望他们最后能自行解决。结果还是被抓到，锅，你说到底要咋整…… 之前则有一对更合不来的项目经理和产品经理，来找我分别聊，“这项目经理是不是管太多了……”，“这产品经理是不是管太多了……”。矛盾日积月累，最后公开化，群里国骂都出来了，公司只好做了调离处理。 触景生情，聊聊产品经理与研发…… 一、产品与研发的前世今生 这类冲突往往爆发于，研发的leader与产品
方才一个开发经理和兄弟项目组的产品经理怼起来了。事情大概是，两边对接，那边希望我们出一个接口，而我们这边实际上是两个完全不同的实体概念，开发经理觉得应该提供两个基础接口，合成一个不科学。 吵得难分难解，我则狗在一边不说话，希望他们最后能自行解决。结果还是被抓到，锅，你说到底要咋整…… 之前则有一对更合不来的项目经理和产品经理，来找我分别聊，“这项目经理是不是管太多了……”，“这产品经理是不是管太多了……”。矛盾日积月累，最后公开化，群里国骂都出来了，公司只好做了调离处理。 触景生情，聊聊产品经理与研发…… 一、产品与研发的前世今生 这类冲突往往爆发于，研发的leader与产品
在软件研发过程中，往往随着为了快速满足业务要求的压力，用户需求的变更，软件代码的增多，以及版本的迭代，团队成员的变化等等因素，导致一个软件项目随着时间推移，欠的技术债会越积越多，用户使用容易出错，部署流程也变得复杂。技术债务不及时还掉，就会产生“利息”，进而导致软件复杂度呈指数级增长。代码行越多，逻辑越复杂，技术债务就会欠的越来越多，最终到了某个临界点的特定时刻，软件代码就会变得失控，没人知道里面改动会带来什么后果。每一次的需求修改调整，引发即使很小的代码修改，可能由于软件复杂度变高，都会带来新的问题，轻则导致软件无法正常使用，重则导致出现严重的问题，甚至系统崩溃无法正常使用等问题。随着时间的
在软件研发过程中，往往随着为了快速满足业务要求的压力，用户需求的变更，软件代码的增多，以及版本的迭代，团队成员的变化等等因素，导致一个软件项目随着时间推移，欠的技术债会越积越多，用户使用容易出错，部署流程也变得复杂。技术债务不及时还掉，就会产生“利息”，进而导致软件复杂度呈指数级增长。代码行越多，逻辑越复杂，技术债务就会欠的越来越多，最终到了某个临界点的特定时刻，软件代码就会变得失控，没人知道里面改动会带来什么后果。每一次的需求修改调整，引发即使很小的代码修改，可能由于软件复杂度变高，都会带来新的问题，轻则导致软件无法正常使用，重则导致出现严重的问题，甚至系统崩溃无法正常使用等问题。随着时间的
写文档也是技术活01：实践对于多数开发同学来说，很多时候即讨厌没有研发文档，但是自己又不愿意常写文档，痛且倔强着；程序员该不该写文档，与争论哪种编程语言最好一样，想撕的嘴不留情，该写的笔不停耕；当自我的意识上去纠结一件事情要不要去做的时候，不妨停下来看一看，大的职场环境是如何选择的，纠结自然就没必要了；对于写文档这件事情，并不需要去思考能带来哪些好处或者会占用多少时间，用心去写自然明白当中利弊；最近两年听到不少搬砖的朋友说，公司已经把文档管理提升到资产层面，在重大版本推进过程中，预留文档输出的时间，这可不是一般的大聪明；从工作的这几年实践经验来看，写文档原则上本着复杂的事项细写，简单的事项简写
写文档也是技术活01：实践对于多数开发同学来说，很多时候即讨厌没有研发文档，但是自己又不愿意常写文档，痛且倔强着；程序员该不该写文档，与争论哪种编程语言最好一样，想撕的嘴不留情，该写的笔不停耕；当自我的意识上去纠结一件事情要不要去做的时候，不妨停下来看一看，大的职场环境是如何选择的，纠结自然就没必要了；对于写文档这件事情，并不需要去思考能带来哪些好处或者会占用多少时间，用心去写自然明白当中利弊；最近两年听到不少搬砖的朋友说，公司已经把文档管理提升到资产层面，在重大版本推进过程中，预留文档输出的时间，这可不是一般的大聪明；从工作的这几年实践经验来看，写文档原则上本着复杂的事项细写，简单的事项简写
前言 在谈效能之前，我想先谈谈作为一个技术人或者技术TL，研发的核心价值是什么？之前看了一篇文章，比较有意思，分享一下观念： T外包公司：最核心的竞争力不是技术，而是快速响应、资源调配整合、项目成本控制等方面。 企业信息化公司：研发的核心价值有三个层次：第一层是运用技术更好的去支撑业务；第二层是用技术推动业务，用自身业务经验（服务很多客户）帮助客户；第三层是去用经验积累去影响行业。 解决特定场景和问题的产品公司：核心价值就在于技术，专注与做技术深度。 那我们的核心价值是什么？ （1）高效支撑业务：一个是支撑，一个是高效 支撑：对我们的要求就是：阶段性与业务目标，落地产品对齐。 高效：研发效
前言 在谈效能之前，我想先谈谈作为一个技术人或者技术TL，研发的核心价值是什么？之前看了一篇文章，比较有意思，分享一下观念： T外包公司：最核心的竞争力不是技术，而是快速响应、资源调配整合、项目成本控制等方面。 企业信息化公司：研发的核心价值有三个层次：第一层是运用技术更好的去支撑业务；第二层是用技术推动业务，用自身业务经验（服务很多客户）帮助客户；第三层是去用经验积累去影响行业。 解决特定场景和问题的产品公司：核心价值就在于技术，专注与做技术深度。 那我们的核心价值是什么？ （1）高效支撑业务：一个是支撑，一个是高效 支撑：对我们的要求就是：阶段性与业务目标，落地产品对齐。 高效：研发效
前言“君子和而不同，小人同而不和。”--孔子我们认为，对于任何一个有研发诉求的企业，账号体系都是需要尽早考虑、慎重对待，且不应该随意变更的。问题类型研发团队在设计账号体系和管理账号的时候经常会遇到各种问题，比如：问题1：业务在变化，组织也要随时调整，导致与之相应的账号权限也要频繁调整：在企业业务高速发展的大背景下，为了适应业务变化，企业的组织架构经常会进行调整，研发人员也会在不同的业务中来回切换，甚至在不同的业务中会承担不同的角色。因此，设计账号体系的时候，需要考虑账号权限能灵活调整、即时生效，避免因为权限缺失阻碍研发活动，或是因为权限泛滥引起安全风险。问题2：研发活动中存在多种角色，一个账号
前言“君子和而不同，小人同而不和。”--孔子我们认为，对于任何一个有研发诉求的企业，账号体系都是需要尽早考虑、慎重对待，且不应该随意变更的。问题类型研发团队在设计账号体系和管理账号的时候经常会遇到各种问题，比如：问题1：业务在变化，组织也要随时调整，导致与之相应的账号权限也要频繁调整：在企业业务高速发展的大背景下，为了适应业务变化，企业的组织架构经常会进行调整，研发人员也会在不同的业务中来回切换，甚至在不同的业务中会承担不同的角色。因此，设计账号体系的时候，需要考虑账号权限能灵活调整、即时生效，避免因为权限缺失阻碍研发活动，或是因为权限泛滥引起安全风险。问题2：研发活动中存在多种角色，一个账号
