研发效率为什么总是慢?开发资源怎么总是不够用?是不是哪里从一开始、从所有人就出错了?
为什么产品研发都要特别重效率?
任何研发团队,大概率都在绞尽脑汁想要提高研发效率,与时间赛跑,抢占短暂的高光窗口期、甜蜜空白期;资本或者vp圈的增长预期压迫;研发这个高成本的团队组织,不论从时间线、成本线上都指向了必须高效运转起来。
砍需求,提升研发效率
往往我们会因为研发效率的提升应该从需求管理入手,懂得“砍需求”,砍掉不必要的、没有性价比的、非真相的需求,抓住关键路径上的高价值需求,这样子我们都是在做高价值的事情,可是仍会发现为什么还会出现了研发效率低下呢?
长焦变短焦,看更大的视野,我们很简单的看到,一个支持用户进行价值交易的产品。除了成品的皮肤、功能框架、产品逻辑、产品架构,背后更有技术架构。而技术结构并不是一开始就会有的,跟产品架构类似,开始的时候,没有架构,都是为了满足直接的业务需求,走着走着生态在变,架构也就需要逐渐形成。
用户规模、市场规模、产品功能规模不断变化,技术架构也同样需要跟着生态来成长甚至重构,不然怎么支撑不断庞大的产品架构。
但矛盾的地方在于,往往产品的功能框架、产品架构的升级是比较显性的,在业务上、管理者视角上,是和价值链条直接相关的,也是更加紧迫的。必然不断导致,技术话语权被压制,疲于奔命的应对滔滔不绝的需求迭代,根本无暇考虑代码的优化。更时有发生的情况是,在破烂不堪的代码基础上,继续承接新的需求,硬着头皮构建这栋摇摇欲坠的大厦。
短视的行为必然是,每个产品为了自己显性的产品成就和表现,哪管开发者的技术架构,恨不得24小时让程序员coding。这种做法很讨喜,管理者甚至认为这是个得力的助手,能够有效的推动项目的进展。很多简单的事情,这个时候变得迷雾重重,无人看清,叹息:可能vp也需要表现吧!
技术的重构和产品的成长必然是双螺旋结构,加上市场/商业,形成三螺旋合力一股绳。产品需要关注自己所依赖的强健的技术架构,技术结构背后也需要稳定的it架构。它们的前提又需要有清晰耐打的业务架构做支撑。
工欲善其事,必先利其器,可是有多少大厂中厂小厂、有多少人愿意花时间去磨刀呢?产品经理们,你们一定要对开发者好一点,给他们主动挤出时间做技术的升级,和谐团队不说,产品也获得了健壮的技术架构支撑。