流程是用来解决问题而不是制造问题
贾彦民
讲述：杜力大小：1.64M时长：03:35
流程是一个常常引起争论的话题。同样的情形，事情搞砸了，或归罪于糟糕的流程束缚了大家的手脚，这是大公司的通病；或归罪于没有流程或只有形同虚设的流程，这是小公司的鄙陋。
我认为，《创新者的窘境》对流程的概念做了最好的诠释，即有效的流程是可复制的成功。流程是可变的，而不是僵化的；流程是灵活的，而不是教条的。我们把在软件开发实践中那些行之有效的做法，固定下来，即是流程。比如开始一个新的重要的项目，我们常常由对项目最懂的工程师领衔，临时组织一个跨开发与测试的动态小组（Dynamic Team），根据项目需要，随时加入新的成员，而完成任务的成员及时退出，项目做完后，小组全部解散。
正是这种临时拼凑的貌似杂牌军的动态开发小组迸发出了无与伦比的战斗力和创造力，常常高效快速地完成不可能的艰难任务。我们的团队常常同时有好几个这样的动态小组工作在不同的项目上。这完全是一个不成文的流程，有的同事在完成任务退出时甚至不知道自己被拉进了一个动态小组。
流程是用来解决问题而不是制造问题，我的意思是说，并非所有的开发实践都可以套用流程，为了流程而流程，等于自觉地向僵化和教条的鬼蜮伸出了橄榄枝。记得当年在 IBM 时，我所在的部门照本宣科地模仿所谓的敏捷开发 (Aigile Software Development ) 流程。每天早上，所有的开发和测试小组开始工作前，都要单独聚在一起开一个长至半个小时的例会 (SCRUM meeting)，检查一下当前的状态，并协调下一步的任务。
听起来蛮不错，问题是在我们已有的流程中，每天每周已经有很多类似的会议在不停地同步项目的状态了，工程师们有无数的机会向大大小小的经理们不断地报告自己做了什么，正在做什么，还有哪些没做。在 IBM 的组织架构里，有管人的人事经理 (People Manager)，有管事的项目经理 (Project Manager)，若没有那么多的会议，这些经理们充沛的精力又往哪里释放呢？印象中 IBM 最吃紧的资源就是会议室。
于是，工程师们不得不再把一天中最美好的时光献给无聊的会议。一日之计在于晨，如果大家在头脑最好使的时候思考一下当天要解决的问题，不是更有意义吗？所以，任何流程在执行的过程中，必须保持足够的灵活性。
例如，我们要求提交到主干分支的代码必须经过审查和测试。而对于简单地修改，比如只是更改一个字符串，审查和测试就是多此一举，这种情况下，只要言语一声，允许直接把代码合并到主干分支。
事事讲流程，事事走流程，架屋叠床，常常是向官僚主义发出了邀请函。见怪不怪，有些喜欢生活在安乐窝 (comfort zone) 中的平庸的工程师仿佛得了流程病。言必称流程，拿流程当作不思进取的挡箭牌。事情弄坏了，流程变成了推诿搪塞的口实。完全不知道责任是什么，油瓶倒了都不会去扶，为什么要扶呢？流程里面并没有规定我扶啊。凡事都要听流程，何必要到办公室上班呢？被送到幼儿园按照老师的指令做个乖宝宝不是更好吗？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
嵇斌关于晨会，在诺基亚的时候我们有一种实践是下午五点左右开，一来可以留出宝贵的上午时间，二来有效地杜绝996，再者可以防止周一早上想不起上周五干了啥...3
旭东(Frank)很多领导也把流程当做自己的工作，所以这个动态识别流程个应用流程管理对团队的要求比较高。最起码大家对流程管理的认识需要一个全面正确的认识。领导更应该对此有深刻认识1
悟1、团队足够稳定 2、团队之间很了解彼此 3、成员能力差距不能太大 4、不能有太多牛逼人物
收起评论