一次突来其来的业务上升
好想骂人但仍需冷静面对
昨日晚上⑧点准备早点下班，来自业务方的一封问题上升邮件随电脑飘来，心理禁不住骂CNM，一个美好的夜晚就这么被摧毁了，再次对不起宝宝了！
事件缘由：系统间切换对业务造成影响，业务在原系统操作每次需要五万条，新系统目前只支持五千条，即使近期优化才能达到两万条，和五万条还是有差距的。
从这个层面上来讲，业务是有道理的。毕竟这样的体验放谁那里都会不爽，尤其是技术层面更是如此。这样的操作短期内操作只会有一两次，每次只消耗1-2小时，但业务反馈反馈比较紧张，也无力增加资源（有可能想都没想内部协调），也让大领导看能否增加资源。
快速应对：领导收到邮件后，第一时间肯定是了解事情始末，为什么会有这样的差距？怎样弥补这样的差距？项目本身是不是有沟通问题？为什么上升？
就领导的问题，与相关的主要干系人（具体开发、开发组长、开发领导、具体测试、测试组长、测试领导、项目经理、项目经理组长、项目经理领导）立即沟通，拉群对齐信息，准备领导的问题。原因是什么？怎么解决？解决的时间点是什么？解决前可以怎么快速支持业务？
具体开发/开发组长：解释问题发生的原因，进一步梳理系统改造方案（拉架构师一起对齐），拉测试对齐提测，测试完成时间和上线时间。
具体测试/测试组长：测试性能问题下次怎样测试支持，怎样快速上线，考虑按优先级来处理，业务侧对齐。
项目经理/项目经理组长：拉相关研发同事入群，整体对齐问题始末，组织同步文案，争取快速上线。进一步沟通准备，比如回复邮件，同步领导看怎么解决等。
信息同步完成，文本准备好给大家评审，和领导沟通来龙去脉和解决方案，项目经理是否回复邮件可以跟直接领导商量，因为很快大领导就会找下来，就有进一步面聊的机会了。主动 vs. 被动，此时此刻究竟什么比较好，这本来就是一门学问。
还不知道大领导会如何提问，重要的是我们已经准备好。真的不容易，一次这样的事件引发如此多人的关注，反过来想，其实也是挺好的，模式问题还是需要解决的嘛！
事后复盘：怎样第一时间解决问题？不让其上升
从项目管理角度，干系人和沟通管理肯定没有做好。区分每个干系人的角色和性格，不同干系人采取不同的管理策略，关键干系人要令其满意，这哥们确实急性子，虽然邮件很不客气，但也是事实。事情发展到这个地步，补救是一方面，另一方面是后续怎样改进。
从业务产品角度，业务是上帝，产品是业务研发沟通的桥梁，产品对质量不满，业务也会不满，产品通过业务给技术施加压力，这也是一种方式。至于这种方式好不好，只要有效都算好吧。正常情况下业务人员支撑不了，产品是可以临时支持的。产品业务一条船的时候，只能靠研发支持了，但办法总是有的嘛。
从开发测试角度，这个问题其实是已知的，也跟产品沟通或先上线支持业务，然后逐步迭代提升性能。上线第一个版本是原来性能的1/10，确实有点低，本来承诺是2万，确实有些打脸。当时想当然觉得这样也没啥大问题，大不了多做几次，本来短期内次数也不频繁，暂时可以接受嘛！当然，对于工具类，测试参与度低也是一个问题，上线还是有质量的上线比较靠谱。
从团队合作角度，在一个业务方面前如此优秀的团队，在另一个业务方面前被批斗得一无是处，本来就会有些问题。这个肯定是沟通机制包括上升机制未能同步到位。其实矛盾一开始就有，怎样化解这些矛盾，本来就是一门值得自己深入学习的学问。当然每个团队资源安排是自己的事情，别人也无从干涉，这个也许是激起业务反弹的原因之一，下次也要注意了，看人。
下一篇－满满的正能量，再次分析，其实这个邮件只是一个量积累到质积累的过程，任何事情都不是简单的一次性事件，邮件里面还提到去年系统性能差呢。说明矛盾一开始就存在，一个长期合作的团队，更多需要的是向心力，而不是毁坏团队互信的负能量。
