“软技能”这个不容忽视的问题，在一定程度上划分了公司用人的分水岭。
它甚至重要到会影响一个产品乃至一个公司的生命周期。
而前端作为生产环节中沟通纽带，这个问题显得尤为重要。
我直接来讲一个每天都可能发生故事，希望能引起共鸣或者是中肯的反驳。
我负责与PM（产品人员）UI, UE，RD(后端)一同开发一个周期为1周的小项目 A。
我喜欢这样的小项目，因为它足够敏捷，从产品与市场角度可以快速试错。
更重要的是我和我的团队很容易“从一个胜利走向另一个胜利”。
那么问题来了，如果PM给出一个大大的计划，经过技术评审，周期甚至超过2个月，你又当如何？
A. 深入分析业务需求，调派人手，保证如期完成。
B. 深入分析业务需求，协助产品经理合理拆分项目。
我们如期的开发完毕，经过RD,PM,UI,UE的确认，并群发邮件把进度通报人转移到了RD，
于是大家愉快的进入前后端联调阶段。
联调是一种模糊的等待，没有明确的结束是时间，but why ?
某天一通急促的电话质问我们什么时候提测？
我表示一头雾水（RD并没有告诉我联调完毕）。
经过各种沟通。提测了。。。
1. 接着PM发现遗漏了什么，要求我们做了一个“小修改”。
A. 我觉得PM应该不会再改了，直接注释掉了原来的代码，写了一小段快速完成了。
B.我花了一下午时间去兼容业务可能的变动。然后找各方已确认。
C. 我没有立即动手，看看PM是否还有别的改动，并拉了个讨论组 加 UI,UE,RD,QA一起讨论。
2. 隔了2天QA提出了一个“推翻性的”需求修改，且理由很充分。PM希望我们上线时间不变的前提下做这次修改。
A. 我觉得虽然麻烦确实应该改，就直接动手改了。
B. 这种简单在线沟通，我担心会理解有误，于是直接当面问清楚，尽管我们不在一个办公楼。
C. 虽然口头沟通过了，但我觉得每个变更都该有记录，于是说服PM更新UI，UE.甚至PRD。
D. 从业务逻辑和代码层面思考可能的时间风险。考虑是否争取延期或者加派人手。
3. 由于紧急项目B插入，人力原因我们必须放下手里的工作，去做B。
A. 我直接发邮件跟A项目的相关人，说明停止A，然后做B项目。
B. 我评估B的工作量，找人帮忙cover 项目B。A项目组人员（或部分人员）继续做A项目。
C. 我先反思这种情况是否会变成一种常态，怎样规避。在线发起项目组讨论。
to be continue ….
