2008-07-30
沟通失败与应急处理（下）
【阅世书生原创·转载请注明出处】
书接上回。既然事情已经演变成一次应急处理，那么必须马上想出办法：如何在无法获得WD资源支持的情况下，确保当晚上线？挂掉电话之后我的确有些沮丧，并且还有些混乱，甚至我一时都没有反应过来，究竟是哪个页面出了问题？
先给自己15分钟时间，把前后往返的邮件统统看了一遍，站在产品人员的立场上，确认发生的问题究竟有多严重。——产品经理应当将这些问题under control，虽然看起来这是个比较细碎的问题，但既然已经扩大成应急事件了，那么PM至少必须明白是怎么回事。执行力是沟通能力发挥作用的基础。
了解了情况之后，发现的确不是个大问题。WD的拒绝多少是有些个人情绪在里面，开发的工作量相当之小。于是有了Plan-B：找这个项目的UED，看看是否能通过UED的资源，把这个问题解决掉。我从PM的角度，感觉UED是能够处理的。
马上实施。找到UED，叫上QA，把现存的问题向UED交待清楚，请她协助解决。这次的沟通比较顺利，UED表示了她的担心：出于CSS规范的考虑，不一定能解决，但可以马上尝试。很欣慰。问题正在朝着好的方向发展。
利用UED尝试的时间，我开始考虑Plan-C：如果UED尝试失败，怎么处理？这么说吧，如果UED尝试失败，那就表示只有WD可以处理这个问题，那基本上就算是山穷水尽了。似乎只有延期上线一个选择了。我一边盼着UED的结果，一边考虑着Plan-C，一边已经在写项目延期的邮件了。等我写完，UED很抱歉地对我说，不行，这个CSS规范只有WD可以改。
那一刻我还是比较绝望的。看时间已经只剩2个小时不到了。现在延期上线，那我必须要到第二天的例会上解释原因承担责任，还要在31日的时候，无论如何确保上线无误。
无奈之下我又把整个项目捋了一遍。又一次站在产品设计人员的角度审视PRD和测试结果，我所要的结果是当晚安全上线，存在的问题是一个页面的样式无法调整。办法？要么延期上线，要么避开这个页面。避开页面的办法？要么修改，要么……这个页面先不上。嗯，这就是Plan-C了。
我知道这并不是一个足够好的办法：一个项目拆分开来上线，不仅可能影响功能的实现，还可能存在技术的风险。但看起来，这是两者权衡的唯一办法了。马上评估:找PD评估是否存在技术上的风险，自己再从产品设计人员的角度看PRD，是否影响功能实现。万幸的是，对功能实现基本没有影响，页面本身也不需要强调处理，PD的反馈也不存在风险。马上邮件老板通报情况，老板点头，ok，邮件所有关系人，通告当晚上线，产品存在瑕疵，第二天修订，31日补上线。
用了一个不是办法的办法，应急的问题是解决了，经验值得总结：（参考《项目管理流程》）
- PM对产品的掌握，必须要从立项的那一刻就开始。这次问题的发生，就是源于交接过程中，没有明确时间点。
- PM对产品的控制，时间点是最重要的控制手段。立项的时候就必须心中有数，分配资源和人手的时候，必须向各个关系人明确时间节点。WD不愿意配合，正是因为时间点没有及时明确。
- 对每个时间节点必须按时跟进。之所以这么匆忙，是因为没有按时跟进QA结束测试这个时间点。
- 对每个时间节点上可能出现的问题，必须准备1个以上的备用计划。自己弄得这么紧张，就是因为没有事先准备备用计划。有备用计划，就不会压力这么大。
- 所有流程必须及时通知相关关系人。这是给自己留条后路，同时也是督促自己必须做到上述4条。
