勤奋――RACI要用好 　　

　　项目不能想当然，责任分配矩阵的RACI必须清晰。最近给公司法务部发邮件，确定一个开源软件的付费要求。最终，我四处奔走，与一小群人交谈，但始终未能追踪到。大家很容易忽略谁是决定者，谁要跟随。可以升级到领导找支持，扩大群沟通，电话沟通。你唯一不能理解的就是不要演戏，不要说话，不要装死。这是最大的罪。始于终，闭环思维，向上管理，主动沟通，工作可靠，是项目经理的基本要求。团队周会开吗？至少核心人员必须参与重要信息的同步…我之前最常整合的信息是业务端的更新，产品技术架构负责人的更新(中长期规划，上周进度，本周计划)，长短期里程碑，项目风险和关键跟进事项的更新，偶尔穿插项目复盘，项目负责人想解决的问题。长的一个多小时，短的30分钟。这个机制一定要建立好，在多个团队参与的情况下，每周项目会议的沟通尤为重要。主动询问项目负责人，提前准备解决方案，努力为项目的成功出一份力。项目经理需要熟悉业务和技术吗，尤其是技术驱动的项目？是的，传统行业的瀑布模型和V-V模型都强调要一次做对，安全和流程。但是，前瞻性的需求很难一步规划清楚。相对于竞争对手的需求，两三年后能在市场上处于领先地位并不容易。技术驱动型公司需要不断学习新的理论、方法和实践，了解研发中心每个人提到的领域知识；d流程，从架构框架、深度学习、神经网络、各种模型到大数据分析，再到日常各种行业规范。他们需要深刻理解概念并不断总结，查漏补缺，争取在广度上有所收获。在面向客户的项目谈判中，双方公司都有自己的利益要维护，争执在所难免，秘密一定不能泄露，说话的艺术需要掌握，可以恰当，可以确定节奏，可以控制重点，可以明确主次。一线人员反复沟通没有效果，哪些事项需要提升到顶层，哪些需要整体考虑，哪些需要一个个突破，哪些需要坚持。先易后难(帮助营造合作氛围)或先易后难(帮助解决问题)。同时，要做好文档版本管理。它是注释型和直接调整型。最好能反映出对方的评论，否则多个混乱的版本会让人不舒服。命名本身就是一门艺术，至少需要加上一个日期。项目里程碑要内外兼顾，内部的要细，外部的要粗，缓冲时间肯定是需要的。一线大公司的客户接受流程往往比较严格，所以前期要做好充分的准备，能多做就多做。外部客户有自己的要求，一旦写进合同就很难调整。结合内部成本、资源等提供切实可行的反馈非常重要。内部里程碑也是逐步细化的，初步预估和最终落地，内外整合，不同模块的依赖程度都会影响关键路径的活动。开发经理会太多，自己都承受不了了。总是问他不好。每周主动预约一次还是很有必要的。每一次，雪球越滚越大。与集团内外的同事沟通，获取更多信息，促进更多信息的整合。