layout: post title: 理解流程 modified: 2022-08-23 tags: [principle, leadership] image: feature: abstract-3.jpg credit: dargadgetz creditlink: http://www.dargadgetz.com/ios-7-abstract-wallpaper-pack-for-iphone-5-and-ipod-touch-retina/ comments: true
请允许我在这里以一种低姿态来讨论流程。流程当然可以被聊的高级且深刻，就像在《创新者的窘境》一书中谈论的那样，把流程与公司的文化还有价值，以及创新能力联系在一起。但我们不如来优先解决眼下日常工作中的流程问题。
如果我问你，你多大程度上喜欢当前的开发流程，你一定会觉得我疯了。流程能给人无感的感受就已经是相当正面的评价了，大部分时候我们吐槽的是它怎么能设计的这么反人类。
我的建议是，当我们决定公允的对它进行评价前，我们考虑的问题不应该是我了它会怎么样，而是没有它会怎么样。
我们从一个会贯穿整篇文章的例子开始：在我所在的团队中，我们需要以邮件的形式频繁的和国外客户进行沟通，在开发人员回复客户的邮件之前，我们曾经有过类似这样的规定：
我先单说模版
光是听到这个流程我想你们当中已经有人不爽了，这不是在侮辱人的沟通能力嘛——其实大部分人开发人员的沟通能力并非理想中的优秀，再加上非母语环境，这种不理想会被放大。最后传达给客户的感受就是不专业的低效沟通。这里的优秀，一部分指的是单纯的沟通技巧，即把一件事有条理且简单扼要的解释清楚；另一方是指在项目的上下文内读懂问题背后的问题。后者更重要。
例如客户邮件询问某个页面他为什么无法访问，开发人员在没有经验的情况下会下意识的从程序设计角度去解释：该用户缺少某种类型的角色身份，邮件中引用的角色可能还直接复制自代码里的驼峰变量。这对于非技术背景的业务人员太不友好了，并且这里并没有（完整）回答客户的（隐藏）问题
我们不妨看看根据模版还需要填充什么内容:
模版带的魅力便是在此，比如它能够让新人快速上手，减少犯错的空间。
相比之下的第二个步骤争议颇多：每一封邮件需要在发送前找人评审，相信在多次的沟通练习之后，大部分人都可以驾轻就熟。
在这个例子的开头我其实撒了一个谎，这整套流程在我们的团队中并非是规定，而是「指导意见」（guideline）
在决定将一套经验是否上升到流程高度为我看来只有一点：没有它我们将付出多大的额外成本。这里成本由两部分组成：重复的学习成本和试错成本，即效率和风险
试想我们的经验如果只是口口相传的话，每个加入团队的新人都需要老人言传身教一遍，即使在付出了这些时间之后他可能依然找不到对的人或者把步骤遗忘，那不如把经验固化成流程。这便是为了节约学习成本，
至于风险，在上面的例子中，如果不巧新人完全没有遵守建议自由发挥的话，实话实说代价还是可以承受的，即低风险。我们会收到客户抱怨我们不专业的反馈，但不至于威胁到我们和客户的合作关系。可在某些某些领域中，安全问题哪怕只有发生一次的概率也是不允许的。
理想情况下我们期望流程带来的是高效率和低风险的双收益，但实际情况是风险降低了，效率也同样降低了。
想象一下把上面的例子转化成流程多半是这么落地的：在发送邮件前我们需要在系统内录入各种表单然后提交，接着等待各位大佬的审批回复，有可能邮件被再次打回需要重新修改。来来回回一天之内能把邮件发出去就万幸了。诸如此类的流程还暗示了另一件事：流程是对上负责而不是对下负责的。这会带来权力与义务倒置的问题：一线执行者需要完成大部分工作却因为流程束缚住了手脚。
这便是大家讨厌流程的原因之一：我们看不到真金白银的收益，赤裸裸的事倍功半却是有目共睹的。悄悄修正一下，更准确的说收益后置的太远。如果你把流程想象成为安全带会好理解很多。问题是你让我骑个自行车也要求强制系安全带就过分了。
之所以出现这样的情况，是因为风险多半是流程的出发点，同时在流程设计是前置的，也就是我们并无经验但是却又想防止问题的发生，于是保守是第一选择。本文开始的例子从经验固化为流程其实是极少数的理想情况。
为了解决这个问题，从我的经验看有两个方向。
首先流程不应该是一成不变的，它应该定期被评审被反馈。这样我们才能让那些以"保险起见"名义的工作量被在反复验证无效之后被移除。但这有一些难度，因为正如上文所说流程其实是对上负责的，撼动它最好的方式其实是从上至下，或者团队内部有通畅的沟通机制让执行者的声音能够被听到。
第二个建议听上去可能是反流程的：流程应该有退出机制（opt-out），即在关键的时候我可以不遵循流程，当然这并应该是常态。但我越来越感受到在处理一些突发事件上或者当流程手册里没有涵盖当前情况时，去遵循你的经验随机应变说不定才是最好的方案。
再次回到最初的例子，在我提到的邮件模板中我们需要告诉客户 bug 的根本原因是什么。但如果寻找 bug 原因的人力耗费巨大，我们不建议他们这么做；又或者它根本是第三方云服务商的问题超出我们的能力之外，那如何解释完全就依赖个人能力了，这超出了模板范围之外。模板能够表达的显得捉襟见肘，这个时候模板反而成为了一种束缚。
我想说的是，如果流程算是一种“必要的恶（Necessary evil）”的话，那自由则是另一种对抗这种恶所必须存在的“必要的恶”。
我想起来哈佛商业评论的一篇谈苹果公司如何创新的文章《How Apple Is Organized for Innovation》，通篇阅读下来给我最大的感受即是对于人而非制度的尊重。例如公司内部的行业领域专家会为所有的技术决策负责；产品团队可以独自决策而不必遭受财务压力的约束。
我想说的自由的价值也是如此。
你可能会喜欢