81 lines
8.3 KiB
Markdown
81 lines
8.3 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
093 兰军：团队研发效率低下的要因分析
|
||
你好，我是梅沙科技创始人兰军（Blues），今天想跟大家分享提升互联网产品团队研发效率的一些实践。
|
||
|
||
研发效率未达预期是很多团队都会遇到的问题，项目延期的情况也并不少见。其原因也是多种多样，可能是因为遇到某个技术难题解决不了，可能是因为需求发生了变更，可能是因为设计提出了修改方案等等，表面上总有各种各样的突发情况导致延期。
|
||
|
||
那延期之后要不要追责呢？一个问题留给大家。然而不论是否追责，这并不能从根本上解决研发效率太慢的问题，我们需要找出更深层原因，总结经验与教训，避免再踩入同样的坑。
|
||
|
||
这里分享一个我从腾讯学到的分析方法：冰山模型的要因分析法。
|
||
|
||
如图中所示，研发效率未达预期只是冰山露出水面的部分，只是表象，在水面之下，存在着各种各样的问题，是真正的诱因。
|
||
|
||
|
||
|
||
我们可以粗略的将其分成三类：一是近因，即表面原因；二是过渡因，即深度迷惑我们的原因；三是远因，即改善后能从根本解决问题的原因。
|
||
|
||
1.头脑风暴找原因
|
||
|
||
所有这些原因都是从实践过程中不断发现、总结而来的，所以我会组织产品、技术、设计等所有相关人员进行头脑风暴，来找出研发效率低下的各种原因。做产品需求的时候头脑风暴，查找原因的时候，自然也可以用头脑风暴。
|
||
|
||
问题头脑风暴的关键是尽可能多的列举，不要反驳，把所有能想到的问题都列下来。最后，我们列出了各种各样的原因，包括需求评审不到位、执行态度问题、执行能力问题、主动性不足、考核制度不完善、沟通不到位、不理解整体规划、招聘问题等等，涉及到方方面面。
|
||
|
||
2.因果分析与评分
|
||
|
||
仅仅找出原因还不够，为了解决研发效率过低的问题，我们还需要对这些问题进行分析与评分，找出其中的关键点。
|
||
|
||
如图中所示，我将总结出的所有原因列成表格，分别在横向与纵向一一列举，再两两比较，进行打分，是“因”记-1分，是果记+1分。举个例子，A和B相比较，如果B是A的因，那么B得-1分，A得+1分，反之亦然。如果两者互不为因果关系就记0分。
|
||
|
||
|
||
|
||
然后在表格最右一列对每一行的分数进行求和，得出每个原因所得的分数，并进行排序。按照之前的设定，是“因”记-1分，是果记+1分，所以可以看出分数越高，越代表这个原因是近因，只是表象；分数越低，越代表它是远因，更深层的原因，一旦改善能从根本解决问题。
|
||
|
||
举个例子，我的表格中，得分最高的原因是“需求更改过多”，有8分，得分最低的是“导师指导不到位”，有-11分，显然前者只是一个表面原因，而后者是更深层的根本原因。
|
||
|
||
那怎么判断其他原因到底处在哪个水平呢？我们可以把最高分和最低分分别除以2，得到的数字就是近因和过渡因，以及过渡因和远因之间的分界线。还是以我的团队为例，最高分8除以2等于4，最低分-11除以2等于-5.5，那么得分大于4的原因就是近因，得分小于-5.5的就是远因，而处于两者之间的就是过渡因。
|
||
|
||
在用这种方法进行分析归纳之后，我们团队研发效率未达预期的近因包括：需求更改过多、产品架构能力不足、项目管理能力不足、项目推进意识不足、不清楚整体规划、交互能力不足、执行力不足、版本发布拖延等。
|
||
|
||
过渡原因包括：版本计划周期过长、需求分析能力不足、合作分工不明确、目标路径不清晰、全局意识、没有方法、负面情绪、主动性不足、对项目理解不足等。
|
||
|
||
而远因包括：招聘问题、专业培训不足、导师指导不到位等。可以看到，远因基本上都和领导者相关，很多时候，老板就是公司的天花板。
|
||
|
||
另外，因为问题特别多，很多都没有逻辑性，所以需要找到它们共性的地方，并对其进行分类，大体上可以分为组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。然后在实际操作中，我们可以针对这四大类问题采取相应的解决措施。
|
||
|
||
3.研发流程梳理
|
||
|
||
以组织与制度问题中的研发流程为例，各个公司研发流程的整体步骤其实并没有太大区别，无非是先提需求，然后需求评审，评审通过后出设计方案和技术方案，接着是开发，开发之后是验收，包括产品验收和设计验收，待验收完，再开发提测。如果一切顺利，就可以进入发布环节，而在正式发布之前还有灰度发布，最终才正式发布，大体如此。
|
||
|
||
我们也是按照这套流程做事，但细究之下，发现在实际执行中会遇到很多问题。目前，我们在使用的是腾讯的研发管理平台TAPD，它的默认流程没有问题，只是还不够细致。于是，我们对它进行了梳理，梳理之后发现中间的很多环节都可以进一步细化，以符合自己的研发流程需要。
|
||
|
||
举个例子，光是需求一项，我们就梳理出了21种状态，包括：新需求状态、挂起状态、规划中状态、已规划状态、需求评审状态、已拒绝状态、设计资源分配状态、开发资源分配状态、需求讲解状态、技术方案评审状态、UI设计状态、UI稿评审状态、开发中状态、需求变更状态、UI验收状态、产品功能验收状态、开发提测状态、测试状态、产品发布状态、外网验证状态、已实现状态等。TAPD里面没有那么全，很多步骤都是我们自己定义的。
|
||
|
||
定义完详细流程之后，需要进行流程的跳转，而流程跳转也是在这21个状态之间进行，非常复杂，所以我们需要确定每一个流程能跳到哪几个流程，每个流程的负责人是谁，下一步它能够进行怎样的跳转等等，把所有的环节都梳理清楚并明确负责人。
|
||
|
||
这样梳理下来之后，整个流程图会很长、很繁杂，但对提升团队研发效率的效果非常明显。最初，没有细化流程图，也没有按照流程图做事的时候，遇到问题后，团队成员就会比较迷茫，不知道问题出在哪儿，也不确定该如何解决，甚至搞不清楚下一步的做法。
|
||
|
||
当然，在总结、细化出这个流程图之后，我在团队中进行了很多探讨和培训，让他们能真正清楚这个流程，并约定好每一步的评审人员和把关人员，确保遇到问题时能够及时处理。
|
||
|
||
小结
|
||
|
||
研发效率未达预期是很多管理者都会头疼的问题，本文分析了这一问题背后的诸多原因，包括需求评审不到位、执行态度问题、执行能力问题、主动性不足、沟通不到位等，并通过冰山模型的要因分析法，将这些原因分为近因、过度因和远因三大类。
|
||
|
||
同时，通过提炼共性，将这些原因分成了组织与制度问题、能力问题、沟通问题、招聘与解聘问题这四大类。在实际操作中，可以有针对性的从这四个方面采取相应的解决措施。
|
||
|
||
本文还分享了改善组织与制度问题中，梅沙科技在研发流程梳理方面的实践，包括细化需求状态、定义详细的流程和流程跳转图，确定每个环节的把关人等，将细节掌控做到位。这样，即使出现问题，也能及时定位，快速解决。
|
||
|
||
接下来，我还将分享为提升研发效率，我们在能力问题、沟通问题、招聘与解聘问题等方面的实践，欢迎继续关注。
|
||
|
||
作者简介
|
||
|
||
兰军（BLUES）：梅沙科技创始人，致力于教育+互联网行业产品打造，原迅雷产品总监，腾讯、YY语音高级产品经理，公众号ID：bluemidou，已经写了600多篇原创文章，欢迎交流。
|
||
|
||
（本文整理自兰军在ArchSummit全球架构师峰会上的分享，有删减。）
|
||
|
||
|
||
|
||
|