开发资源为什么总是不够用，到底哪里出错了？

———— / BEGIN / ————

研发效率为什么总是慢？

开发资源怎么总是不够用？

是不是哪里从一开始、从所有人就出错了？

为什么产品研发都要特别重效率？

任何研发团队，大概率都在绞尽脑汁想要提高研发效率，与时间赛跑，抢占短暂的市场高光窗口期、甜蜜空白期；资本或者vp圈的增长预期压迫；研发这个高成本的团队组织，不论从时间角度、成本角度上都要求必须研发需要高效运转起来。

快砍需求！提升研发效率

往往我们会因为研发效率的提升应该从需求管理入手，懂得“砍需求”，砍掉不必要的、没有性价比的、非真相的需求，抓住关键路径上的高价值需求，这样子我们就都是在做高价值的事情。

这当然是需要的，是产品经理团队、开发团队都应该考虑的最基本的事情，可事实是大家仍会发现，为什么还是出现了研发效率低下呢？资源总是不够用，总是追着业务走。

换成发展视角再看研发效率

长焦变短焦，看更大的视野，我们很简单的看到，一个支持用户进行价值交易的产品，除了成品的皮肤、功能框架、产品逻辑、产品架构，背后更有技术架构。而技术结构并不是一开始就会有的，跟产品架构类似，开始的时候，没有架构，都是为了满足直接的业务需求，走着走着生态在变，架构也就需要逐渐形成。

技术架构、产品架构他们都有共同的基准对象，就是业务架构的发展性，外部环境和约束的变动，导致业务发展的不确定性，从而驱动要求不论是组织结构还是信息化结构的同步迅速调整。

用户规模、市场规模、产品功能规模不断变化，技术架构也同样需要跟着生态来成长甚至重构，不然怎么支撑不断庞大的产品架构。这时候，想一想，自己团队规划代码重构、技术重构是多久前的事情了。

藏在水面下的效率阻碍冰山

矛盾的地方在于，往往产品的功能框架、产品架构的升级是比较显性的，在业务上、管理者视角上，是和团队主价值链条直接相关的，也是更加紧迫的。必然不断导致，技术话语权被压制，疲于奔命的应对滔滔不绝的需求迭代，根本无暇考虑代码/技术层的优化。更时有发生的情况是，在破烂不堪的代码基础上，继续承接新的需求，硬着头皮构建这栋摇摇欲坠的大厦。

短视的行为必然是，每个产品经理也都为了自己显性的产品成就和表现，哪管开发者的技术架构，恨不得24小时让程序员coding。这种做法很讨喜，管理者甚至认为这是个得力的助手，能够有效的推动项目的进展。很多简单的事情，这个时候变得迷雾重重，无人看清，叹息：可能团队里的vp也需要表现吧！

然而，技术的重构和产品的成长必然是双螺旋结构，加上市场/商业，形成三螺旋合力一股绳。产品需要关注自己所依赖的强健的技术架构，技术结构背后也需要稳定的it架构。它们的前提又需要有清晰耐打的业务架构做支撑。

工欲善其事，必先利其器，可是有多少大厂中厂小厂、有多少人愿意花时间去磨刀呢？

产品经理们，你们一定要对开发者好一点，给他们主动挤出时间做技术的升级，和谐团队不说，产品也获得了健壮的技术架构支撑。