前言

在1997年，开源运动的领导者之一 Eric S·Raymond发表文章，阐述了开源项目两种不同开发模式，并将其比喻为「大教堂模式」与「集市模式」。随后在 1999 年出版成书，被称为开源圣经的《大教堂与集市》。

在Linux的开源世界里，采用的是“集市”模式，更多是自主、自发、自我的协作和创作，面对未知的领域，通过Bottom-Up自下而上，Linux是颠覆性的，并取得了巨大的成功。

受此启发，对于商业软件系统、对于企业、对于创业团队，应该采用哪种开发流程、哪个协作模式，才不会混乱、才不会内耗、反而更能让项目取得成功呢？

标准化研发流程搭建思路和方向

一家企业，从招聘软件开发工程师、产品经理、技术经理、测试人员到组建开发团队，在日常企业办公过程中，在国内，与国外的氛围不同，需要在内部制定一套标准化的研发流程，明确每个岗位、每个人员需要共事的流转流程。不能过于崇尚所谓的敏捷开发而任其个人自我发挥。

在过往十多年的研发管理过程中，我发现，不管是做游戏开发，还是做电商行业；不管是几个人的创业团队，还是几百人成熟企业亦或是上市公司，作为老板、CTO、技术管理者、或技术经理，都需要在内部明确一套标准化的开发流程，甚至还需要在企业大范围内明确好和其他部门进行跨部门沟通协作的大流程。

没有流程那不行；有了标准化的研发流程却不匹配你的现状也不行；流程匹配了但不执行也不行；执行了却没有及时动态调整升级你的流程也不行。总而言之，研发流程不是万能的，没有最好的说法，只有更合适。更适合你和你自己团队的，就是更好的。匹配，更重要。

我曾经在给一家做SaaS解决方案的企业做技术顾问时，就见证了他们研发从痛苦到规范化的成长过程。一开始，他们内部也有明确研发流程，但是不匹配。表现出来的症状是什么呢？最明显、最为痛苦、最尴尬的莫过于在每次要给股东大客户进行系统演示时，总会出现这样那样的问题，验收时总掉链子。老板很尴尬、很纠结也很无力感，明明知道问题出现在那，却不知道怎么规避和从根本上解决。员工和团队也很累，天天都很忙，验收演示前一晚总得要加班到很晚，第2天一演示还是有问题。开发说是测试的问题，测试说是开发的问题，差点都要拍桌子干起来，怎么办？！

后来经过梳理发现，背后的流程明显不匹配产品开发和交付的现状。例如：缺少统一的预发布环境，都是在开发人员本地电脑上进行联调测试，在验收前直接合并发布到正式环境，东拼西凑，总会有这个那个的遗漏，没有统一进行集成测试。又如：每次演示时经常会出现数据库报错。为什么？因为数据库新加的字段又没忘了同步到正式数据库！后来要求每一次DDL和DML都要记录到git代码仓库中，发布前统一申请线上数据库变更，有了记录和变更申请的环节，后来这类问题就给杜绝了。还有：以前每次发布都是人工进行操作，没有做到自动化、一键发布，甚至那边正在验收开大会投大屏演示，这边还在手动发布改正式环境，那有系统不崩的道理。很多问题，都是流程不规范、操作不规范、不透明、不科学导致的。

归根到底，要么是流程有问题、要么是沟通有问题、要么是太依赖于人员和手工操作，导致每一次交付的质量和效率，都不如人意。

为此，老板总是私下问我：软件开发，怎么就那么难？

管理者需要一个好工具

软件开发，真的好难吗？不见得。那，软件开发，真的好容易吗？也不是。

但，办法总比困难多，花点时间、花点精力，问题总是能解决的。这也是作为技术管理者应该肩负的责任。

如果你的团队也正在经历开发慢、协作难、交付差的情况，我的建议是，重新再一起梳理你团队现有的开发流程，并且让每个成员（如开发人员、测试人员、产品经理、项目经理等）、每个对接的部门（如市场部门、客服部门、财务部门、运营部门等）、每个老板（如你的上级、总监、老板）都清楚、认同和支持统一的开发流程。最后，把开发流程图画出来，贴出来，共享出来。有必要，可以组织会议进行培训、讲解和明确。

 

接下来，再结合你团队现在正在使用的项目管理工具，进行流程上的约束、明确和记录。

例如，过往我们就用YesDev为不少企业解决了研发过程中遇到的各类问题，而且还根据企业的需要进行了开发流程的个性化设置、配置和调整。

 

后台管理：如何搭建和设计你团队的开发流程？

首先，定义你团队开发流程中所需要的需求节点状态。对于互联网SaaS产品，常用的需求状态是（从起点到结束）：需求中、设计中、排期中、研发中、待测试、测试中、待发布、已上线、已完成、挂起。

企业管理员也可以到YesDev后台自己进行配置，包括：需求状态、需求优先级、需求评审状态。

 

例如，对于需求优先级，在某家轻医美企业他们的定义是：P0：临时紧急且重要需求；P1:紧急且重要；P2:重要不紧急；P3: 紧急不重要；P4：不紧急且不重要。并且，需求收集每个月和各部门需求方开会收集一次，先放到腾讯在线excel文档，再同步录入到YesDev需求池集中管理。

随后，管理员还可以根据实际需求流转的过程，把每一个需求状态能流转的节点和顺序在后台进行约束和配置。例如：对于已完成的需求，不希望再进行任何流转，可以对于已完成的需求，取消全部的状态流转。

 

上面两步是针对需求开发流程的设计和配置，简单好用又直接。如果管理员还需要针对需求列表和单个开发的需求进行调整和偏好配置，例如，如果需要对需求列表默认显示的需求字段和需求搜索条件进行调整，可以自行设置默认需求筛选器：

 

最后对于单个需求所需要的默认组件，管理员也可以根据业务需要进行个性化配置。

 

前台使用：如何落地进行和形成闭环考核？

对于产品经理：

可以定期收集业务部门的需求，用excel批量导入或单个录入到YesDev需求池。如果需要区分不同的产品线需求，可以通过产品分类来实现；如果需要区分不同需求方的需求，可以使用需求方字段；如果还需要其他自定义的需求分类方式，可以使用自定义需求标签。

 

对于需求方：

可以查看每周需求排期，查看本周或自己提的需求什么时候可以发布上线，以及当前是处理什么流转阶段。

 

对于开发人员：

在每个协作的需求，可以根据制定的需求流转顺序和过程，进行流转。后面还可以统计每个需求状态停留的时长和研发效率。

 

对于项目经理：

可以统一管理和查看每个项目的需求数量、完成情况和项目进度，还可以进行分组管理。

 

对于测试人员：

测试人员可以创建测试用例、测试库和测试计划，并和项目关联，最后提交Bug缺陷时，还可以和需求进行关联。

 

最后，当需要进行每月考核时，可以使用YesDev提供的周报、月报、统计报表和其他分析数据，形成你团队的闭环考核。持续复盘总结和提升。