6天时间修改一行代码，流程的错吗？

在知乎看到周筠老师提的一个问题：

很多流程的目的是帮助大家减少风险，确保质量，但是流程未必全都是正面作用。请看下面的故事：走6天流程改一行代码：  ， 这种情况需要改进么，如何改进?

看到这个问题我首先想到了项目管理里面经常谈到的一个问题？即在项目管理中做的项目计划经常不准确，我们还需要做项目计划吗？为什么说这两个问题相当类似，其实这两个问题的关键点都在持续改进上，即我们制定流程规范或做项目计划的目的往往不是单纯的当前的一个项目或一件事情，其核心的作用往往在于找到问题并持续改进。

大家可以先读一下上面超链接里面提到的故事，6天时间只修改了一行代码，这个故事确实向我们展示了在流程上面花费和占用了不少时间？但是可以看到其实里面很多时间都花费在了两个核心的地方。其一是团队成员没有形成基础的团队词汇表或者说对流程规范本身就不熟悉，其二是在流程推行前期需要做的诸多基础数据配置工作并没有完成，而是等到流程需要的才在处理。再次，我们对领导或经理出差状况下相应的应急处理机制没有明确制定，也导致了时间上的拖延。如果要真说流程相关的，只有第三个方面是涉及到流程本身改进，而其它内容往往都是团队学习和培训需要改进的地方。

有时候我们经常谈敏捷，但是并不是说敏捷就没有流程，没有规范。我一直强调过，往往在敏捷方法论或极限编程中更加强调流程和记录，只是我们在敏捷方法论中更加强调有用的流程，强调通过协同的方式来减少原有方法论中的大量流程串行，强调不要由于流程约束了开放式的协同。一个企业或一个团队，刚开始的时候引入流程规范一定是降低效率的，但是只要大家都对流程熟悉并形成潜移默化的习惯后，流程本身对效率并不会产生大的影响，同时有了规范流程往往极大的降低了返工，加强了项目和团队资产库的积累。

流程的作用其一是持续改进，这个改进本身包括了流程本身的改进和优化，也包括了团队本身的改进，在流程执行过程中发现了问题重点就是针对问题点逐步去改进和优化，看看究竟是流程的问题，还是团队成员态度的问题，还是对流程本身不熟悉的问题，有针对性的去改进和优化。而不是将所有问题和延误都归集到流程本身。比如我们说的项目任务中填写工作日志，每天填写可能就1-2分钟，但是很多人在心态上往往是抵触的，这些都不是流程本身，而是团队价值观和意愿的问题。

流程的作用其二是知识和资产积累，对于一个大的项目或一个团队，人员经常变动，那么流程流转中相应的过程资产积累就相当重要了。对于做软件开发的相信大家都很容易理解接受一个文档注释都没有的项目或代码是多么苦憋的事情。但是往往更有意思的就是，新接手的人仍然是旧方式的延续而不是想着规范化。当面对一个焦油坑的时候很多人唯一能做到往往是如何让自己不陷进去，而不是想着如何让后人能走上柏油马路。

 

流程可轻可重，这个和团队的规模，团队人员的知识结构，项目本身的复杂度等诸多方面都有关系。但是一定不是不需要流程，流程本身的作用就是增加可重复性，解决我们在前面没有流程中团队执行或协同中出现的问题，而不是约束我们的手脚。CMMI中谈的更多的一个词是过程包括过程改进，当我们谈过程的时候更加强调了流程，人和方法工具技术三者之间的有机融合，这有这三者完美整合好，才可能形成一个高效率的体系。

原文链接：http://blog.sina.com.cn/s/blog_493a84550102vhoz.html