YesDev:如何快速搭建企业标准化研发流程?-技术圈

前言

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

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

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

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

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

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

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

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

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

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

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

管理者需要一个好工具

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

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

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