导图社区 IT项目经理成长手记
很多人觉得开会只是一个形式，没什么必要，但是，接下来，从制定项目沟通计划的步骤、项目与外部的沟通、非正式沟通的利与弊等方面来说明，开会是不是必要的，没有开会会失去沟通的机会，会让项目安排不明朗，无沟通会使项目降低效率！所以，开会也是任务。
社区模板帮助中心，点此进入>>
开会也是任务-有计划地沟通
案例背景
提前上线问题反思换位思考
非常明确的一点：部分提前上线的起因正是沟通不畅造成的
高层无奈
客户高层推动项目也有很大的阻力
对项目进展情况又弄不清楚
从侧面听到的都是一些不利信息
希望从项目组得到直接信息时却没有被认真对待
结果
误解逐步加深、信息不断失真
最后采用部分上线的方案也是无奈之举
强推新方案也有不同意见，只能通过政治任务的方式
问题根源
根源还是在沟通上！
之前
PM特别反感会议和报告，怕多了之后影响项目进度
PM总是尽力阻挡各种会议，重要的会议也是派人应付
现在
PM认识到会议、报告不但非常重要，而且是确保项目成功的一个重要因素
必须把开会当成一项任务，而且要被有效的管理
做为一名新的项目经理能及时反思就打补丁也是值得我们学习的
制定项目沟通计划的步骤
沟通计划主要是为了解决沟通的规范化和制度化，在项目组内可以有效执行
第一
列出主要角色和关系，以及项目中的主要报告和会议的框架
由项目组的PMO负责落实沟通计划的执行
第二
制定沟通矩阵来理清项目干系人之间的沟通关系
沟通矩阵第一列代表信息的提供方，第一行代表信息的接收方，相关的交叉点上，就是两方的信息交互关系
第三
根据沟通矩阵确定沟通的方式、时间、频度、对象，制定详细的沟通计划。固定的沟通任务包括书面沟通和会议沟通两类
第四
将沟通制度化，重新梳理项目，制定会议沟通计划
项目与外部的沟通
为了有效管理与外部的沟通，项目组采用了客户建议的-《业务联系书》
业务联系书使用场景
一
需要正式地向客户提交文档，相当于签收的过程
比如完成了需求分析，正式提交《需求分析报告》，同时提出评审申请
二
需要从客户索取资料，或者需要必要的信息和正式答复
收到对方承诺之后，则记录在案并按时间要求进行跟踪
三
跨部门布置项目工作时，相当于任务书
比如，需要网点资料的调查信息，则可以通过业务联系书的方式提出申请，并提供调查的文档模板
例子
最近一次测试中，发现合作厂商的“系统接口异常”
PM通过正式的业务联系书发出了请求，落到文字+时间限制，接收方会重视起来。即使不能按期解决，也会按期回复将如何处理
非正式沟通的利与弊
利
客户反映远程监控系统“根本不能用”，结果原因是用户界面不友好，而工程师态度比较生硬，客户不满，从而作出上述结论
会前的非正式沟通可以了解各方要反映的问题，提前解决
弊
一名骨干调到其他项目组，在PM还没跟客户沟通之前，这名员工就到客户那里告别了，并表示是因为关系好“私下先透露一下”
人事变动沟通遵循的原则
当事人不得事前直接与客户沟通自己变动的情况
原则上必须由其上一级负责人与客户进行沟通
必须同时说明替代的解决方案，并征得客户的同意
不得在人事变动沟通完成前，擅自进行人事变动
经验与教训
沟通是确保项目成功的一个重要因素，项目经理可能80%的时间都花在沟通上，沟通也需要好好计划，识别沟通对象和信息要求，并确定正确的沟通方式
