关于研发组织的思考

例行的季度述职中，相似的场景又反复出现了：先是研发总结没有按计划完任务，提问题建议时吐槽受临时、定制项目插入的影响，无法保证长期计划的投入。然后老板指示要控制需求，优先做重要的事情。相似的场景反复出现，这里面肯定有问题，而且问题没有得到解决。那么问题到底是什么样的呢？这几天一直都在思考这个问题。

显而易见，问题长期存在且覆盖大部分产品团队，那么可以得出结论：这是研发领导甚至是老板的问题。这个答案简单不需要思考，且符合情绪。得出这个答案实在是让人充满怨气的暗爽了两天，甚至产生了爷要另谋高处，不想再陷在这泥潭里的想法。但作为一个参与者如果只能得出这么一个结论，显然是不合格的。反过来也说明，顺从情绪、倾向而得出的结论，基本没有意义甚至有毒。

那组织是怎么运转导致这么个结果的呢？作为一个基层研发主管，试着从下往上的视角进行观察分析。ps：信息有限犹如盲人摸象，仅限于自我排解。
首先，基层的研发主管负责组织人员完成产品的迭代开发和项目开发任务，同时向产品经理和更高一级的研发经理汇报。研发主管虽然负责分派具体的工作，但属于任务的分解以及组织实现。而什么时候要做什么任务，基本是由产品经理决定。这也是研发主管吐槽定制项目影响长期计划的由来。

研发主管并不能决定什么样的项目不做，也不能决定资源的投入方向。靠研发主管没法改变目前项目导向的开发机制。这相当于要求研发主管硬顶着产品经理和公司研发领导的决定，坚持做自己认为正确的事情，这在公司体制里基本不可能实现。即使背着研发管理不力的锅都比那样做好。没有人能永远正确和成功，背离领导的决定坚持做自己认为正确的事情，意味者不管是错误或者失误，甚至是不管什么原因造成的失败，都得承担全部责任。而且领导可以跳过研发主管直接安排研发活动，也可以在频繁的组织调整中解决掉不听话的研发主管。这并不是没有先例。

研发主管也不是全知全能者。项目相关的信息，是由产品经理给出的。项目的大小、客户或合作伙伴的重要程度，项目与公司战略方向契合程度，都决定着项目优先级，不了解这些信息是没办法做出正确的决策的。而产品开发也依赖于产品经理的市场调研、功能规划、原型设计。公司的研发组织关系里，是研发主管向产品经理汇报，不是平等或者是产品经理配合研发主管的关系。

产品经理或者更高一级的研发经理为什么没有解决这个问题呢？
产品经理面向市场，销售为了拿单对研发资源投入的需求是没有上限的。严格控制产品的项目需求，意味者产品经理作为主责任人去拒绝销售要求的研发投入，在没有执行标准的情况下，就会得罪很多销售，更何况很多时候还要面对公司二把手-负责销售的总裁的亲自问询。因此产品经理并没有太大的动力去解决这问题。服务好销售，给出客户认可的方案或产品规划是产品经理的责任，产品的质量是研发主管的责任。这也会导致不管项目大小和重要程度，只有临交付节点了产品经理才会提上日程，毕竟为重要项目提前准备充足的时间需要产品经理拒绝掉更多的项目。

与产品经理同级的研发经理似乎可以负起这个责任。他不直面销售总裁的压力，按理可以投入更多的精力在研发中重要的事情而不是紧急的事情，调度更多资源到产品研发中的长期而重要的事情上。实际运作中他虽然投入更多的精力去关注和跟踪那些长期而重要的事情，但没有直接和产品经理对线，帮助下面的研发主管拒绝掉过多的定制项目。具体原因不得而知，可能是他在和产品经理的对线中落了下风。理想的做法，应该是和每个研发主管一起确定产品研发中重要的事情，并制定好计划，制定计划时可以合理要求对应产品经理给出产品半年以上的中长期规划。这样面对产品经理传递过来的项目中的资源投入需求，就可以有理有据的拒绝。至少市场需要有更充分的理由来说服更高级的领导来介入才能调整计划。

过往案例表明，公司领导更关注项目的交付，产品立项和研发资源的调动投入都需要有项目的支撑，而且根据项目紧急程度而不是项目重要程度来决定资源投入。例如，公司最大单一客户并不认可公司目前的产品状态，而产品经理的优秀方案得到了客户的认可。该方案可以认为是合作的压舱石，也是公司产品建立核心竞争力的迭代方向，但即使这样的任务，因为没有具体的面临交付的项目支撑，也没办法从大大小小的项目中争取到研发资源的投入，导致一年过去方案仍停留在PPT上。而有项目支撑的需求，不管背后的项目可行性怎么样，都能得到领导的关注而投入。比如一个友商跟进并投入开发半年以上的项目，由于达不到客户的要求而获得机会。在产品处于劣势的情况下销售仍要求研发全力投入用一个星期时间模仿实现友商定制的功能，只是为了展示公司舍得投入的诚意而争取项目机会。而这样的资源投入需求得到研发副总的支持，在研发主管明确拒绝的情况下越过研发主管直接安排开发人员进行支撑。结果是由于开发时间短产出质量远差于友商且同样不满足客户需求而项目失败，研发为产出质量负责任。研发副总成为了项目驱动的研发活动的强力执行者。日常产品经理在产品立项和规划上，如果没有可见的要求交付的项目进行支撑，项目评审会上都不会得到公司领导的认可而获得通过。似乎产品规划的必要性都需要在PPT阶段得到项目的背书。也导致产品经理普遍基于项目来做产品规划。

而且公司领导在组织结构调整中也以项目管理能力和服从性做为研发主管和经理的主要考核指标，不能在有限的时间内带领团队完成项目交付基本都被替换。如此也合理解释研发经理在和产品经理的对线中落了下风，没办法争取出研发资源投入到产品上。研发团队陷入大大小小的项目中。甚至产品经理的产品规划也是基于方向不一的项目，没有长期统一的规划。产品研发多年仍在问题多多，没有竞争力。

到这里，基本符合最初的结论：研发的问题出在公司领导。那老板多次强调要注重产品质量，把精力放到重要的事情上，资源不足时可以砍掉项目甚至可以砍掉产品，只是喊口号而已吗？事实上公司对研发的投入并不低，研发团队的员工占比超过50%，虽然比不上一些小创业公司的70-80%，但相对于几个友商比例并不低。纯粹的项目导向，应该是某个友商那样，有项目是产品就激活修改没项目时封存，以至于总员工数两倍于当前公司但研发团队人数不到当前公司的一半。如此重视研发投入，那么老板对研发团队把精力主要投入到产品上的要求就不仅仅是口号。

那么是什么造成老板如此分裂呢？或者说研发经理、研发副总为什么不能在老板面前硬气起来？换位思考下，从老板的角度好像研发团队没有给力过，在项目竞争中不拖后腿已是万幸，几乎没有通过PK力压友商而拿下的项目。更多是在产品劣势的情况下销售人员争取到项目，而研发在为达到交付条件而努力。公司发展到当前规模依赖于老板谈下的几个重要合作伙伴，研发团队也仍然在为达到重要合作伙伴的需求而努力。如此陷入一个死结：研发需要拒绝更多项目来打造产品竞争力，给销售提供支撑而不是拖后腿；公司发展到如此规模是老板和销售拿下的项目拖着研发往前走达到的，研发团队至今仍存在交付困难，也从没有证明过自己。

现状维持下去是否具有可持续性？公司的发展壮大，需要业绩的支撑。高速发展的高估值，也需要优秀的产品支撑。公司当前的高速发展，是引入的投资驱动的快速扩张。而项目主导的开发，由于偏低的投入产出比，支撑不起当前规模的公司继续高速扩张。一旦螺旋上升的趋势不存在，当下公司的利润并不足以支撑目前的规模，将会螺旋坍塌。因此打破惯性解开这个死结刻不容缓。

公司也在尝试打破惯性，比如半年为周期的替换研发经理，换上了项目管理能力更强的管理者；比如引入质量经理，严控研发过程。严控研发过程的经理，目前看来并没有控制得了需求的导入。而不能控制需求导入保证研发周期的情况下，严控研发流程更像是雪上加霜。新的研发经理是否能顶住老板、销售副总、研发副总的压力，仍待观察。

怎么才能打破惯性，解开这个死结呢？作为一个研发主管，没办法决定资源的投入方向，似乎只能靠挤压资源来投入自己认为正确的事情上。但在项目交付存在压力的情况下，挤压不出多少资源。即使挤压出一点资源，也很难保证不被产品经理拿去支撑更多项目。况且低比例资源的投入，是很难Pk得过友商的。如此结果不可能打破公司的惯性。即使杯水车薪，也可以从几个方面来挤压资源：1、积极配合质量经理的研发过程，被动的拉长项目周期来抵挡项目交付压力，存下更多水分。2、在研发过程中调节繁简，收集水分投入到正确的事情上。产品经理的角度的话，最好能利用老板的口号和出发点，说服老板和研发副总将研发团队进行拆分，将半数以上的研发人员脱离出项目支撑团队，成立产品中台专注产品开发，减少产品经理可以调动到的资源。如此在和产品经理的对线中处于弱势的情况下让产品经理承担更多的控制项目需求的责任。

问题都经不起琢磨，重要的是不要带有情绪和倾向。相对于琢磨这些问题，写代码和架构设计其实更爽。不过对于项目驱动的公司，要的是项目管理能力，代码和架构的价值都被压低了。