一件事，几个人，几个过程，优先级，执行者，决策者
1. 为什么想写这个
最近在工作中遇到几次特别的情况，需要紧急发版。作为这些事的参与执行者，一直处于有点混乱的状态。所以，想从自己的角度说说为什么会乱，以更好地应对以后工作中类似的事情
2. 为什么会乱
- 事情紧急，个人无计划
每次都是突然就被通知：开发正在开发中，然后测试验收一下，今天晚上要发个版或者过会儿就要发版。事情突然发生时，习惯性第一反应是“服从指令”。没有思考，没有计划，不知道前因后果。无论什么时候，都要对事情进行规划
- 没有找到对的人，小范围决定
“啊，我不知道这个事情”。紧急情况下，常常听到好多人说这句话，自己也会有这种疑惑。于是，当有突发情况发生时，常常看到几个人围在一起“密谋”什么，而且不止一两次，而且每次在不同的“小群体”中在讲同样的事情。比如，最近的一次情况是：线上优先级很高的bug(起因)——服务端的人讨论决定说不能发服务端，风险很大——让客户端发hotfix，客户端决定只能发版解决——客户端的开发老大自己做了决定(间接原因：没有知会其他有决策权的人)——他把事情通知给开发和测试(执行者)——执行的人已经开始为这个事做准备——服务端老大(决策者)后面才知道这个事情，他不认可——找来产品(决策者)，产品也不认可——几个有决策权的人在一起商量做了决定——通知了开发——测试表示什么也不知道——测试咨询开发，开发表示“码代码中，有点烦......”。这个过程中，(1)多次的信息传达，把简单的事情复杂化，导致办公室显得很混乱；(2)决策不被认可，导致执行者做无用功，耽误了事情的解决进度；(3)不是所有执行者都了解自己要做什么，有点乱；(4)有时，主管对实际业务实现并不完全了解，可能做出错误的决策，只能从头再来。所以，决策阶段，找到对的人做正确且被一致认可的决定(比如：产品、开发主管、对该功能很熟悉的开发/测试)——决定要通知到所有执行者(除了开发，测试也应该被同时通知到)——执行——事情结束时，通知所有应该了解情况的人(比如主管)
- 讨论问题的方式
紧急的时候，形式流程基本都不存在的。大家就直接站在一起，然后你一言我一语。可是，我觉得这种方式效率有点低。很多时候需要讨论到技术层面，每个技术人员会有自己的逻辑，每个都有表达的欲望。所以，讨论的时候，我常常会听到好几个人把相关的技术流程讲述一遍。讲得费时，可是理解和接受的内容并不多。如果我们可以把这种复杂的流程可视化，写出来，其实讲一遍就够了吧，剩下的就是在其中做一些调整
- 表达欲望这件事
报着想把事情解决的心态，每个人都会希望发表自己的观点，在讨论中不太会去注意倾听。所以，一场讨论会显得很“热闹”，充斥了好多重复的信息，没有价值的信息。如果能在讨论中把关键点写出来，这有助于增加个人接收的信息量。当自己想表述观点时，对于已经存在的相同的点，可以稍微克制一下，尽量去说不同的点，对于自己不是完全确定的事也尽量不要过多阐述，以免误导其他完全不知情的人。
- 合适的执行者
本来一个功能是由A开发的，可是出现紧急情况时却让B来修改。这个是我一直没有搞懂的事情。为什么紧急情况下会做这种决定。如果A当前有开发任务，而且优先级没有那么高时，为什么不能暂时抽出时间来呢？这种方式反而导致任务量的增加。我个人的观点还是：紧急时，让熟悉的来做熟悉的事