千日拱卒(2)：流程与效率

今天做了两个工作：

1. 向过渡给我接手的项目前开发同事了解了一下产品部署问题、以及交付给客户的注意事项
2. 为一个大项目制定了完整了版本管理流程

这两个工作单从内容本身看，都是直接的——前者了解情况，后者（我已经参与该项目一段时间，比较了解情况了）基于项目团队和产品本身的风格写好文档即可，但是真实的工作场景却不是这样的。

对于第一项工作，我实际早于前两天就预定了一个会议、邀请该开发同事和项目经理共同参加，过程中除了必要的录像记录、还有邮件书面总结，该总结的框架是会议开始前就拟定好、在会议召开的同期就完成并让集体确认发送。

对于第二项工作，我完成初稿后，先是同Scrum Master一起审核，然后根据他的意见和我对应给出的方案做出一次修正——这些只是整个工作的第一步，之后他还需要将和项目经理共同就此流程的可执行性进行讨论，再召集产品核心组件的负责人研讨流程是否能覆盖他们日常开发工作遇到的场景，最后该流程才会发放给项目组全体成员；后期可能是我或者Scrum Master来培训大家学习和执行流程，到整个流程真正成为团队成员日常开发的习惯，还需要1-2个Sprint。

这两个工作各自代表着不同场景，前者是我们常见的举手之间（一个电话）就可以解决的事情，却多出若干环境——铺垫和记录；后者其实可由少数人拍板决定之后就付诸执行（前提都是流程本身质量足够过硬），却需要层层把关、步步推进。

这两个工作常见的方式带来的是“效率”的提高——任务分配给我、任务交付完成，因而直观上流程就是阻挡效率的坏角色。但是这种“效率”只是狭义，在广义的理解上，流程反而对于特定组织、甚至对于我个人都是提高效率的事情：

• 流程通过层层把关，控制了质量，继而能够避免更大的损失。诚然各个流程拉长了事情处理的周期，但是从出发点来看，是为了保证让问题及时暴露，不至于在真实的生产环境（交付给客户后，产品上线）出现问题。届时带来的损失除了依旧有人力的弥补，还有经济乃至信誉上的损失。
• 通过流程，倒逼流程各个参与者精益生产。没人喜欢繁琐的流程（我内心依然是碍于组织规章不得不如此），更不喜欢因为流程某个环节没有通过而反复执行流程（工作初期反复修bug的痛苦经历历历在目），因此要求流程的参与者都负起责任保证自己的工作质量。另外，这种流程也利用一种潜在的人际相处相互作用提高个人的质量——你总不希望自己总是那个没有做好工作而给大家带来麻烦的人。
• 流程实质化每个人的工作，以保护个人的方式进而保障个人的效率。试想一种情况，没有记录、没有实证，事情出了差错，你难保别人把责任推给你的时候你可以置身之外。暂且不提这类情况发生给你带来心情上的失落、职场上的失意，就说你要为此付出的时间精力、都不能说这是有效率的行为。

后记：但是流程对广义意义上的效率的提升仍然有前提的，所谓“特定组织”其实就是组织的规模程度以及组织成员的素质水平。之前我任职的团队人员规模小，在小林子里鸟儿低头不见抬头见、大家也都是同进同出，鲜有背后开暗枪的，因此这类场景下四平八稳的流程反而是种拖累、倒不及扯一嗓子大家围着你七嘴八舌讨论一番收工的方式来得便利。至于说到底什么样的团队规模和成员素质搭配什么样的方式，现在的我还是缺乏经验和理论支持。