思可相反，得须相成。
一个项目，经常是多个组织单元协作，通过软性技能沟通可以更好的解决项目中各种实（che）际（dan）问题。作为项目经理，当遇到强势管理者或者恃才傲物的技术人员（换言之就是拒你千里之外的脸），但又需要施加影响时，最重要的不是推销自己的想法，而是努力解读对方的想法，用对方能够接受且认同的方式去影响他。
用一颗举一反三的心，倾听沟通中表面的诉求和内心的呐喊，洞察身边的老司机的一举一动，认真学习有效的套路；制造强势但不强硬的感觉，产出良好的计划、积极的协调、努力的推动、有变通但更坚持原则。
当kickoff拉开帷幕，项目经理和产品经理友谊的小船可不能说翻就翻。
两个PM手挽手要好的能穿一条裤子：
Product Manager负责做正确的事，Project Manager负责正确的做事；
我们不是一家亲但我们胜似twins，前者挖掘需求规划产品的want，后者协调资源明确项目的need。
如果你在恋爱中是把好手（want≠need），请将此真理映射在识别需求、具体化需求中，作为优先级和迭代功能的可衡量性基础，这是项目经理和产品经理务必达到一致的关键。
虽然产品经理可能会有那么几个快（yi）速（lian）试（meng）错（bi）的功能影响项目按时发布以及结果质量，但工作量和风险程度都那么easy地控制在安全范围内的产品还需要项目经理嘛？
项目规划阶段，Product Manager整理行业认知及分析、需求挖掘和分析，制定产品策略、方案；Project Manager获取的产品规划、目标产出项目范围管理。
举个例子参考意会下：一对夫妇乔迁新居，宴请狂朋恠友，以主菜牛排为例。
吃了这盘肉，世界充满爱。
需求管理阶段（当然最好是整个项目生命周期里）二个PM形影不离，国家需要忠臣闺蜜需要诤友，互相协作又互相制衡；了解变化，适时调整，把控方向，确保目标的一致性并且可实现。
项目渐进明晰，项目经理责任大权力小，时限紧资源少，这都是项目的常态。
做计划的时候，无论是圆桌会议还是逐个攻破，别纠缠多余的评断和情绪，也不要陷入对他人的喜好之争；最重要的是让大家达成“相对共识”，聪明点不要太入戏自己也别表演。做个知心大叔，不怯场压住台（甭管是抽皮鞭还是扛大刀请绷住扑克脸），接收多方的立场，找到表面原因和深层原因（聪慧如你还是要拿笔记记）。
规划沟通也还是用乔迁新居宴请狂朋恠友为例发散下：
项目计划阶段一定要舍得花时间趴在交互和技术方案论证上，如果到了项目中期提出实现不了必须换一个技术方案，这就是自己挖的坑。也许平常和开发小伙子们接得了段子也给得了信任，但这一耙子威信就弱了。这种不确定性因素带进执行阶段，每天心情简直生无可恋。
合理规划各个里程碑节点，将里程碑的压力传递给项目中的每一个人；尽可能颗粒度量化到每个工作日，梳理各个活动之间不同的逻辑关系：A完成B开始、A和B同时开始、A和B同时完成、A开始n日B可以开始（以此类推加入C、D、E...）。
项目计划的信息量不小篇幅最好够简洁，让干系人快速理解意图；拿到高层授权落实团队需要的资源，按照项目的节奏和机制跑起来吧！
产品范围（产出的可交付成果）已分解，还需要对项目范围（为产出的可交付成果要做的工作）进行进一步分解。
比如，烤牛排是产品范围，而宴请人数、材料准备、烹制方式等就是项目范围。并且，整个项目的进度、成本、风险等都是由项目范围决定的，各组织间也需要交付和验收。
此时需要有条不紊的大管家上场（心中有一股强大的洪荒之力，不仅给自己提供力量，还能感染别人）：
章程首条：听产品大大的话，不要镀金。任务分解是以可交付成果为目标的工作层级分解，任何一点变化都可能引起连锁反应，避免小聪明式的捷径、费力不讨好的现象。
章程次条：每个任务有清晰的分割界限和先后顺序，事事有人负责人人有事可做。
章程末条：不可以有遗漏项。我们可以先把每个角色和任务分配对应起来。
如上，任务的审核人、责任人、协助人、有谁提供输入、成果输出给谁就明确了。对于复杂程度高或风险大的项目，粒度更细致些比较稳妥。
项目计划与执行
管家分派任务后，还需合理控制每项活动的进度，即计划开始和实际完成时间。佛瑞德·布鲁克斯(Fred Brooks)说过：“无论多少个女人，孕育一个生命也需要九个月。”(《人月神话》)。
有一些软件开发任务是有顺序约束的，需要的时间是一定的，无论多少人参与时间都不会减少。另一方面，对于项目经理来说，技术过程服务于业务目标，需要把业务目标放在技术实现之前。
不论协调或是妥协，都要先弄清楚他为什么如此坚持、扩展或模块化、公司流程限制、业务上的意义？从对方的话语里指出可以成立的点，延展开去，再渗透其他重要干系人的看法。先肯定对方再讲自己意见，沟通会更顺畅有效。落地的时间节点，一定要获取主要干系人的认同、保留可追溯的痕迹，并保证所有相关干系人信息对称。
不同的职位层级/角色，对计划的关注点也不同：面向结果的、面向阶段的分解结构可以产出项目整体计划、子项目计划，月、周计划，列表、里程碑、甘特图等都可以展现。
理想很丰满现实很骨感，实施过程中往往不会那么顺利。在制定详细计划可以运用正推法vs逆推法，即最早开始/最早结束vs最晚开始/最晚结束。给每项重要任务安排警告时间点，到了这个点还没有完成，就要提醒或预警各方了。核心目的是通过这样的节奏，及时了解进度的情况，预见可能的风险，找到解决的方法，同时周期性和主要干系人进行沟通。
风险控制不一定能确保问题不出现，而是确保能够在最早的时间意识到问题的出现，及时采取应对措施。如果暴风雨来临，不要慌；以后回顾起这个项目，肯定是更喜欢大家拼尽全力度过瓶颈的日子，而不是一帆风顺的那些日子。
管家的优缺点
第一大优点：会管。
任务基本符合每个人的喜好和擅长，不用马来耕田牛来打仗。知人善任，调动项目成员的积极性和主动性。
第二大优点：敢管。
针对不好的苗头和现象，搞事情、违反原则的人敢于指出整改，努力营造有责任感、旺盛士气的团队氛围。在计划-监控-实施这个闭环管理中，项目经理会扮演卖萌的鼓励师、活力的小打杂、坚强的保护伞、奔跑的消防员、把酒言欢的兄弟，有时候也需要肩扛一把大刀用来摆谱加强气场坚持原则。
请点击此处输入图片描述
管家必败之缺点：事无巨细，所有问题都自己扛，不堪重负。
首先，会打击团队成员的积极性，破坏团队成员间信任关系只关注自己的任务和得失；
其次，剥夺了团队成员的挑战性和成就感，思路延展不到全盘，学不到东西是造成人员流动的重要因素；
最后，一个人的精力是有限的，抬头观望全局比埋头做事更重要。相信每个人都愿意很努力地往高处爬，不是为了被世界看见，而是更想看见整个世界。
项目变更
计划并不是一成不变的，永远不变的只有改变。
越是周期长的软件项目，变更控制流程越重要。问题也许是发生在项目执行阶段，但根源还是在需求管理阶段。
变更类型主要分为软件功能变更、业务流程变更和实施人员变更，这些都可能引发进度计划变更。项目经理也许没有权利拒绝某些变更要求，但有权利按照流程把变更提交到正确的层面做决策。
参考变更流程如下图所示：
在项目实施过程中，组织间陆续产出交付物，上一重要节点的阶段性成果，是否确认或是需要变更，对下一重要节点的正式启动至关重要。就像管家在晚餐开始前，都会严格地一一检查，用尺子量每一副餐具摆放的位置，蜡烛的长短，餐巾的折叠，鲜花的多少，灯光的明暗程度。里程碑时刻，可以提前制定程序规避遗漏项，主要包括参与人、时间地点、审核(验收)内容以及确认情况、审核(验收)意见、问题解决方式、签字(盖章)。
项目收尾
一步一个脚印儿，项目到了最后一个阶段的验收，按照交付标准保证满足了相应要求。所以就结束了吗？请先发出项目成果的报喜邮件(意义、感谢、展望)！
项目收尾阶段起码还要做三件事：
整理、归档相关文件资料(审计)；
综合绩效评定、表彰庆功；
回顾成功经验、问题不足及改进建议。
项目管理本身不生产价值，但是促使价值产生。愿每个项目经理灵活使用软性技能，根据受众适时调整角色，真正的情商，最高境界是自有分寸。
愿耐心看完小文的你，深知世界的复杂，依然选择面对复杂，保持喜欢（比心❤）。
本文作者：彭姝（点融黑帮），任职于Lender Team担任项目经理，专注于项目管理和ISO20000相关工作8年，曾任职于巨人网络技术中心，喜欢烹饪。