|
|
# 12 | 流程和规范：红绿灯不是约束，而是用来提高效率
|
|
|
|
|
|
你好，我是宝玉，我今天想与你讨论流程和规范的价值，以及如何参与制定好的流程规范。
|
|
|
|
|
|
不知道你所在的软件项目中是不是也有各种流程规范，例如：
|
|
|
|
|
|
* 开发人员不能直接在生产环境修改代码操作数据库，必须在本地先测试验证后，由运维操作；
|
|
|
* 代码需要Review通过才能合并主分支；
|
|
|
* 代码需要遵守各种规范，像命名、格式，还有缩进用几个空格还是tab的细节问题；
|
|
|
* 遇到Bug，先提交到Bug跟踪系统。
|
|
|
|
|
|
在我经历的项目中，或多或少都会有各种各样的流程规范，而且越是大的、正规的项目团队，流程规范越是多。
|
|
|
|
|
|
然而很多人对于流程规范并不是很理解，甚至觉得是一种约束。
|
|
|
|
|
|
## 为什么要有流程规范？
|
|
|
|
|
|
从某种程度上来说，流程规范确实是一种约束：约束了我们如何做一件事，约束了我们用什么标准做事，约束了我们用特定的顺序做事。
|
|
|
|
|
|
既然如此约束我们，为什么还要有流程规范呢？
|
|
|
|
|
|
### 提升团队效率
|
|
|
|
|
|
**从个体来看，因为流程规范的存在，确实可能存在效率降低的情况，但从团队的角度来看，好的流程规范反而是提升效率的。**
|
|
|
|
|
|
这其实很像我们生活中的红绿灯，用一个简单的规则：红灯停绿灯行，来约束车辆行人按照指示灯行进。
|
|
|
|
|
|
从单个车辆来看，看似是因为红绿灯的存在而影响了效率，但是从整体来看，因为红绿灯的存在，有效避免了拥堵，反而是提升了大家出行的效率。
|
|
|
|
|
|
其实红绿灯除了能提高效率，还有其他好处：
|
|
|
|
|
|
* 红绿灯这样好的管理交通的经验，形成流程规范后，就可以全世界共享这种先进的经验；
|
|
|
|
|
|
* 红绿灯不再处处依赖于人指挥交通，而变成了让红绿灯的规则来指挥交通。
|
|
|
|
|
|
|
|
|
软件项目中的流程规范是不是也有这样的效果呢？
|
|
|
|
|
|
以代码审查的规范为例，对于技术高的程序员来说，代码审查可能会耽误一点时间，但对整个团队来讲：
|
|
|
|
|
|
* 即使是水平高的程序员，也可能会被发现有错误，代码审查可以降低出错的概率，保障质量；
|
|
|
|
|
|
* 对于水平低的程序员，可以通过代码审查学习和成长，代码被高水平程序员审查后，可以有效提高质量。
|
|
|
|
|
|
|
|
|
软件项目中这样的例子还有很多，类似的还有像遇到Bug要提交到Bug跟踪系统，还需要配合重现步骤说明，看起来繁琐，但是却让Bug可以有效跟踪，让开发人员可以重现和定位，从而高效的修复Bug。
|
|
|
|
|
|
### 将好的实践标准化流程化，让大家可以共享经验
|
|
|
|
|
|
我们知道，在运动项目上，有些运动员特别有天分，总能拿好的成绩，而这些运动员的动作，会被反复的研究学习，最终形成标准化动作。而其他天分一般的运动员，按照研究出来的标准动作练习，也能取得非常好的成绩。
|
|
|
|
|
|
软件工程也是这样，早些年的软件项目，就是个人英雄主义盛行的时代，项目的成败极其依赖于个别厉害的项目经理或者技术高手，而这种牛人，总是稀缺的存在。
|
|
|
|
|
|
所以后来很多编程高手写代码的方式，甚至写代码的格式，也会被研究，最终形成一套套的代码规范。其他水平一般的程序员，按照代码规范，也能写出不错的代码。
|
|
|
|
|
|
代码规范还有个好处，就是大家写出来的代码看起来差不多，换个人接手别人的代码，也能很快上手。
|
|
|
|
|
|
如果我们站在流程规范的角度看软件工程的开发模式，它也是源自实践过程中，有些厉害的项目经理发现了好的、可以提升软件质量的开发实践，不断总结改进，最后变成了流程，让普通的项目经理按照这一套流程，也能做出不错的软件。
|
|
|
|
|
|
你看瀑布模型也好，敏捷开发也好，最后落实下来，不就是开发过程中一个个的流程规范么？所以瀑布模型我们需要各种阶段评审，敏捷开发需要每天开站立会议，需要每个Sprint有计划会、评审会。
|
|
|
|
|
|
### 借助流程规范，让项目管理从人治到“法治”
|
|
|
|
|
|
在《[10 | 如果你想技术转管理，先来试试管好一个项目](http://time.geekbang.org/column/article/86375)》这篇文章中我就提到过，管理就是管人和管事，而管人，就要借助流程规范来管理。
|
|
|
|
|
|
因为如果在项目管理中，过于依赖人的管理，项目经理就会成为瓶颈，大事小事都需要项目经理来决策。再说项目经理也不能保证每次决策的正确性，如果决策失误，会很可能导致一些冲突。
|
|
|
|
|
|
**而好的项目管理，不需要直接管人管事，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。**
|
|
|
|
|
|
我以前工作过的一个项目组，一个项目持续了好多年，中间人换了一批又一批，甚至有时候连项目经理都空缺，而项目一直井然有序的进行着，没有出什么问题，靠的就是多年积累下来的适合项目组的流程规范。
|
|
|
|
|
|
就像在《[06 | 大厂都在用哪些敏捷方法？（上）](http://time.geekbang.org/column/article/84652)》这篇文章中描述的那样：项目成员日常从看板就可以知道要做什么任务，代码审查、自动化测试可以有效保证质量，项目文档可以保证新人加入时能快速上手，结对编程可以保证新人遇到问题可以得到直接的帮助。
|
|
|
|
|
|
还有一个常见场景就是需求变更，产品经理想加一个紧急需求，这通常是让项目经理为难的事情：加吧，影响项目进度，开发人员有意见；不加呢，可能客户或者产品经理有意见。一个不小心就两边都得罪了。
|
|
|
|
|
|
如果你有一个大家认可的需求变更流程，就不再需要靠项目经理一个人决定该不该加需求，而是通过流程，来大家一起决策是不是要加这个流程。
|
|
|
|
|
|
所以你看，**流程规范，看起来是约束，实际上你用的好的话，不仅可以提高团队效率，还可以将好的实践标准化流程化，让大家可以共享经验，还可以有效的管理项目。**
|
|
|
|
|
|
## 如何制定好流程规范？
|
|
|
|
|
|
在项目管理中，难免要去制定流程规范。即使你不是管理者，也可以提出合理的流程规范，帮助把项目管理好。
|
|
|
|
|
|
有一个科学的制定流程规范的方法，可以让你更好地制定出好的流程规范。
|
|
|
|
|
|
### 制定流程规范的四个步骤
|
|
|
|
|
|
对于流程规范的制定，可以通过四个步骤来开展。
|
|
|
|
|
|
**第一步：明确要解决的问题**
|
|
|
|
|
|
要制定一个流程规范，第一步就是明确你是要解决什么样的问题。项目中很多问题，都可以思考是不是能通过流程解决。
|
|
|
|
|
|
比如说有程序员在生产环境操作，误删了数据表，造成了严重问题。如果只是对程序员进行处罚，寄希望于小心谨慎避免类似问题，那么下一次还有可能会有类似的事情发生。
|
|
|
|
|
|
如果说在流程上规范起来，例如：数据库操作之前先备份数据库，事先写好SQL语句，需要有人审查，测试环境先测试通过，最后再生产环境执行，那么就可以避免以后再出现不小心删除数据表的事情发生。
|
|
|
|
|
|
**第二步：提出解决方案**
|
|
|
|
|
|
对于问题，也不用着急马上就想着用流程规范，可以先思考解决的方法，有了方法后再进一步思考是否能提炼流程规范。
|
|
|
|
|
|
那么方法和流程规范有什么区别呢？
|
|
|
|
|
|
相对来说，方法更有针对性，可能只适用于特定场景或者特定人，而要将方法上升到流程规范，则需要有一定的普适性，能变成具体的步骤或者标准，让每个人都能执行。
|
|
|
|
|
|
比如说服务器部署后出现问题，高手可能就直接上服务器操作，直接修改代码编译解决，这是一个解决方法，但这不能成为一个流程规范，因为换一个水平不行或者对代码不熟悉的人来做，可能会搞出更大的问题。这时候回滚操作就是一个相对普适的方法，可以变成一个部署后出现问题的流程。
|
|
|
|
|
|
在提出解决方案，制定开发流程时，可以参考借鉴软件工程中，大家公认的好的实践。比如说：
|
|
|
|
|
|
* **敏捷开发的流程：**虽然你的项目不一定采用敏捷开发的方式，但是敏捷开发中一些好的流程是可以借鉴的，例如参考我之前文章提到的像看板、站立会议、持续集成，这些好的工作流程，都可以借鉴。
|
|
|
|
|
|
* **代码规范：**其实很多公司都公开了他们的代码规范，可以直接基于这些规范制定团队的规范。例如说前端的有Airbnb的代码规范 [Airbnb JavaScript Style Guide](http://github.com/airbnb/javascript)，Java的有 [Google Java Style Guide](http://google.github.io/styleguide/javaguide.html) ，.Net的有[.NET Guide](http://docs.microsoft.com/en-us/dotnet/standard/index)，等等。
|
|
|
|
|
|
* **源代码管理流程：**现在的源代码主流是git，而基于Git的代码管理已经有很多成熟的流程规范可以参考。例如阮一峰老师写过的《 [Git 使用规范流程](http://www.ruanyifeng.com/blog/2015/08/git-use-process.html) 》《[Git 工作流程](http://www.ruanyifeng.com/blog/2015/12/git-workflow.html)》和《[Git分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html)》，或者Github官方出品的《[Understanding the GitHub flow](http://guides.github.com/introduction/flow/index.html)》，Gitlab官方推荐的《[Introduction to GitLab Flow](http://docs.gitlab.com/ee/workflow/gitlab_flow.html)》。
|
|
|
|
|
|
* **部署流程：**十年前，每日定时构建还是很时髦的部署流程，而现在，主流的部署流程已经变成了持续部署，每次代码合并到主分支都可以触发一次自动部署，这样一有问题，就能马上知道发生在哪个环节。
|
|
|
|
|
|
|
|
|
像这样的好的流程还有很多，在我们专栏会介绍一些。如果平时多留心，你也可以学到很多。
|
|
|
|
|
|
**第三步：达成共识，推广执行**
|
|
|
|
|
|
在流程规范提出后，还需要得到大家认可，只有大家认可，达成共识，才能共同遵守，保障制度的执行。
|
|
|
|
|
|
对于大家都认可、很重要的流程规范，一定要让大家严格遵守，必要的时候需要配合一些奖惩制度，以保障其执行。
|
|
|
|
|
|
比如说流程规范的执行和绩效考评挂钩，对于没有执行的需要私下沟通提醒，严重的需要批评教育。否则流程规范会形同虚设，没有太大的意义。
|
|
|
|
|
|
**第四步： 持续优化，不断改进**
|
|
|
|
|
|
流程制定后，在实际执行的时候，难免发现一些不合理或者不科学的地方，这时候就需要对其进行调整。
|
|
|
|
|
|
还有一些流程规范，随着时间推移，可能已经不能符合要求了，也需要考虑改进甚至放弃，不然反而会成为一种阻碍。
|
|
|
|
|
|
比如说以前采用瀑布模型开发时，项目经理因为需要了解进度，所以每个项目成员要写日报，如果有站立会议了，日报这种形式就可以完全被站立会议替代，没有再存在的必要。
|
|
|
|
|
|
通过以上四个步骤，你就可以将日常项目中遇到的一些问题，用流程规范的方式逐步管理起来，在实施的过程中再不断优化改进，淘汰不合适的流程规范。
|
|
|
|
|
|
### 将流程规范工具化
|
|
|
|
|
|
如果说，以前我还是人为去推动一些流程规范的执行，近些年，我越来越感觉到，**应该尽可能借助技术手段来推动甚至替代流程规范。**
|
|
|
|
|
|
例如说代码规范，以前代码规范的执行，主要靠反复的教育宣传和代码审查中一个个去检查。而现在，借助VSCode这种强大的IDE，以及ESLint这种代码检查工具，可以方便的检测出不符合规范的代码，甚至于可以帮你直接格式化成满足代码规范的格式。
|
|
|
|
|
|
还有像保证代码质量的问题，早些年必须依赖测试人员大量手工的测试，而现在借助CI（Continuous Integration，持续集成）、自动化测试和Git，可以保证代码必须在通过测试以后，才会合并到主分支，从而很好的保证了代码的质量。
|
|
|
|
|
|
就像任正非的《全面提升软件工程能力与实践，打造可信的高质量产品》公开信中题记的这一段话说的：
|
|
|
|
|
|
> “软件工程”和“质量工程”需要依靠架构技术，而不是依靠CMM和QA管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。
|
|
|
|
|
|
“软件工程”不要过于依赖流程和管理手段，要思考怎么通过技术手段去解决问题。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
流程和规范，就像红绿灯一样，不是一种约束，而是牺牲一点个体利益，提高团队效率；流程和规范将好的实践标准化流程化，让大家可以共享经验；流程和规范，让项目管理从人治变成“法治”。
|
|
|
|
|
|
要制定好项目规范，先明确要解决的问题，然后提出解决方案，看是否可以通过流程规范来解决，有了方案后需要团队成员一起达成一致，最后再推广执行。在执行过程中需要持续的优化，不断改进。
|
|
|
|
|
|
对于需要手动操作的流程，可以思考是不是能采用技术手段自动化，通过技术手段去解决。
|
|
|
|
|
|
## 课后思考
|
|
|
|
|
|
你所在项目中有没有不合理的流程规范？或者欠缺流程规范导致混乱的情况？如果有，你觉得可以制定什么样的流程规范来改善？欢迎在留言区与我分享讨论。
|
|
|
|
|
|
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
|
|
|
|