流程 ,Not流程 ?

 

     为什么项目过程中折腾我们的往往是一些微不足道的小事?新功能添加"顺手就改,转眼就忘,一旦出错,一问就蒙"的情况如何避免?

 

答案:流程

 

        一年前我还对流程表示反感和排斥,因为我将"流程"简单地等同于堆积如山的文档和照本宣科的会议,牺牲了弥足珍贵的设计和开发时间.而现实不会在你自作聪明的时候纠正你,而是在后续的某个时间点上给你一记响亮的耳光.屡教不改者,耳光声此起彼伏,痛定思痛之后,偏见终将纠正……

 

   如果我们的软件开发是这样一个过程:领导告诉项目经理在站点添加一个站内短信功能一周上线,项目经理简单设计一下就开始分配任务(甚至自己就动手了).做好之后就告诉测试组添加了一个新功能你们测试一下.两三天后项目经理问:"测完了么?" 测试人员答曰:"OK!" 于是功能上线……

   你会发现如下问题:

• 没有设计文档
• 开发出来的"站内短信"是不是领导所说的"站内短信"很难讲
• 没有测试用例文档
• 在没有测试用例文档的情况下,竟然得出了"测试完成"的结论

    然后风和日丽的某一天领导告诉项目经理"站内短信"出问题了,于是项目经理在努力回想领导对功能的描述之后找到测试人员:"你不是都测试了么?这种情况怎么没有测到?" 测试人员说:"没有设计文档,我怎么知道还有这种情况?" 项目经理说:"时间那么紧哪里有空写什么文档?"

     貌似这是一个纠缠不清的糊涂账,谁都有责任可是谁都有理由,大家错都错得那么义正言辞,正义凛然.问题的原因可以找到很多条,可是归根到底一句话:"没有流程"

 

      假设我们走了一个简单的设计评审,测试用例评审,项目验收的流程,那会怎样呢?

•  项目经理对"站内短信"功能的设计偏差将在设计评审时得到纠正
• 测试用例的不合适或者遗漏将会在测试评审时得到纠正和补充
• 项目验收系统是面向最终用户的最后一站,不能免,免了早晚会重蹈"三鹿牛奶"覆辙

     这样无论设计还是测试的问题会在比较早的一个时间点上被发现并纠正,层层把关,且把关有理有据!你说测试完成了,只要看一下测试用例覆盖程度就可以了,这就是流程的力量!实际上流程产出的是什么呢?是决策结果!决策产出于流程中的若干会议.做事情的人往往是没有决策权的,所以决策结果的产生对于做事的人太重要了.而争论和责任推诿往往是由于没有什么依据来判断谁有问题,而依据存在于之前决策结果中,或许就是那份领导拍板的文档.

      也可以这么说如果一个会议的能做决策的人不能出席,那么会议就取消好了.否则会议就会变成一个百家争鸣,各抒己见,气氛融洽,百无一用的茶话会.当然要是旨在交流感情那也算是有点用了,仅此而已.

 

      继续我们那个关于"站内短信"的故事,假如走了流程上线之后还是出错了

      项目经理找到了以前设计文档,做了检查,做代码修改.同时和测试沟通添加或者修改测试用例.

      这就是我认为流程另外一个重要作用就是:跟踪

      大家最缺的除了钱就是时间,而如果每一件事情都要从头开始思考回顾,那就浪费了太多的时间了.比较理想的是能马上切入着手处理,而这就要求要处理的事情能跟踪到以前做了什么,做到了什么程度.而流程产出的文档和会议记录就可以做到一件事情可以跟踪.而且流程产出的这些东西你一点也不必放在脑子里面.留点空思考点别的,存着这些陈年旧账可能有用但是太累.

     不按照流程走事情就很难跟踪,君不见"正龙拍虎"已经浪费了多少国家的行政资源,根源不就是没有走验证流程就上报虎讯了么.

      

     然后,通过一个真实的事例来说明问题.

     背景:我们的网站做增量更新,运维工作人员和开发人员在不同地点办公区.

    2006年我第一次旁观两位同事做增量更新,增量更新是开发组做运维同事负责服务器状态检查.那时候两位同事闪电般备份旧文件,停掉负载均衡,停掉IIS,覆盖新文件,启动IIS,加入负载均衡.要是中间出错,在服务器上打开文件,略加修改一切恢复正常!旁边的我有一种幻觉:是这两位高手不断向各个站点输送内力才得以正常运行!

      那一年的更新,惊心动魄!

 

  2007年,更新的事情到我来做.于是可真的苦了配合我更新的运维的同事.我也在服务器上修改文件,但是几经波折,不断重启IIS,甚至还要让运维的同事恢复到上一版本甚至重启服务器.修改完又忘记把文件同步到源代码管理工具中,于是下一次更新又错.直到现在我还对那位配合我更新的同事充满歉意.

    那一年的更新,险象环生!

 

  2008年,站点的更新是运维的同事来做!这一切的秘密就在于流程:开发人员提供更新文件和部署说明,部署之后测试负责做更新的确认.之前运维的同事不能做更新不是说有什么技术门槛,而是因为我们做开发的把服务上的文件搞得乱七八糟人家理不清.现在运维完全掌控站点的更新状况,文件备份也是他们管理,可以很容易根据时间跟踪到某一个版本,出现问题后的版本回滚也速度迅速.今年我没有在服务器上改过文件!

     这一年的更新,风平浪静!

 

  更新的流程化帮助我们肃清了跟新过程的种种混乱,把以前貌似艰难的问题变得顺利.站点更新变成一件很平常的事情,看来它真的顺利了!

  上面说的都是在软件开发过程中的流程,其实对于我们个人为自己设定几个流程也是有必要的.工作没有流程，又想把工作做好的人，总是感到人手不够或者没有时间.“办事情条理化”已经被美国哈佛经典教材《管理之门》列为管理人必须做到的一项基本工作,什么是条理化,不就是按流程做事么.

 

 

总结:

• 流程的重要产出是:决策和依据!这些产出能帮助我们跟踪问题!
• 没有决策者出席的会议没有价值,开会--你需要一个能拍板的人
• 做事的人往往不能决策,而做事的人最需要就是决策结果,那是做事依据
• 不要把所有的事情都放在脑子里,放在文档里,然后忘掉
• 做一件事情的门槛往往不是因为它难,而是因为它混乱
• 流程能帮我们肃清混乱,良性循环
• 我们需要流程,无论项目大小

 

           身在项目中的你对于流程有咩看法?