研发效率为什么总是慢？开发资源怎么总是不够用？是不是哪里从一开始、从所有人就出错了？

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

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

砍需求，提升研发效率

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

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

用户规模、市场规模、产品功能规模不断变化，技术架构也同样需要跟着生态来成长甚至重构，不然怎么支撑不断庞大的产品架构。

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

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

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

工欲善其事，必先利其器，可是有多少大厂中厂小厂、有多少人愿意花时间去磨刀呢？产品经理们，你们一定要对开发者好一点，给他们主动挤出时间做技术的升级，和谐团队不说，产品也获得了健壮的技术架构支撑。