换个视角,再看互联网产品研发效率!

内容转载自:Kris_3zzz

研发效率为什么总是慢?

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

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

一、为什么产品研发都要特别重效率?

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

二、快砍需求!提升研发效率

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

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

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

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

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

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

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

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

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

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

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

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

本文地址:http://mip.sunnao.cn/archives/1196

以上内容源自互联网,由运营助手整理汇总,其目的在于收集传播生活技巧,行业技能,本网站不对其真实性、可靠性承担任何法律责任。如发现本站文章存在版权问题,烦请提供版权疑问、侵权链接、联系方式等信息发邮件至candieraddenipc92@gmail.com,我们将及时处理。