项目经理的角色扮演：人生在世，全靠演技

                                                项目管理本身不生产价值，但是促使价值产生。愿每个项目经理灵活使用软性技能，根据受众适时调整角色，真正的情商，最高境界是自有分寸。思可相反，得须相成。

一个项目，经常是多个组织单元协作，通过软性技能沟通可以更好的解决项目中各种实际（che dan）问题。作为项目经理，当遇到强势管理者或者恃才傲物的技术人员（总之就是拒你千里之外的脸），但又需要施加影响时，最重要的不是推销自己的想法，而是努力解读对方的想法，用对方能够接受的认同的方式去影响他。
用一颗举一反三的心，倾听沟通中表面的诉求和内心的呐喊，洞察身边的老司机认真学习有效的套路；制造强势但不强硬的感觉，产出良好的计划、积极的协调、努力的推动、有变通但更坚持原则。
项目经理的角色扮演
当kickoff拉开帷幕，项目经理和产品经理友谊的小船可不能说翻就翻，二个PM手挽手要好的能穿一条裤子。Product Manager负责做正确的事，Project Manager负责正确地做事；我们不是一家亲但我们胜似twins，前者挖掘需求规划产品的want，后者协调资源明确项目的need。如果在恋爱中你是把好手（want≠need），请将此真理映射在识别需求、具体化需求中，作为优先级和迭代功能的可衡量性基础。这是项目经理和产品经理协作的关键，虽然产品经理可能会有那么几个快速试错的功能影响项目按时发布以及结果质量，但工作量和风险程度都辣么easy控制在安全范围内的产品还需要项目经理嘛？
此阶段Product Manager整理行业认知及分析、需求挖掘和定位，制定产品策略、方案；Project Manager根据获取的产品规划、目标才能产出后续的项目范围，举个例子参考意会下：A couple乔迁新居，宴请狂朋恠友，以主菜牛排为例。

吃了这盘肉，世界充满爱。需求规划阶段（当然最好是整个项目生命周期里）二个PM形影不离，国家需要忠臣闺蜜需要诤友，互相协作又互相制衡；了解变化，适时调整，把控方向，确保目标的一致性并且可实现。
需求渐进明晰，项目经理责任大权力小，时限紧资源少，这都是项目的常态。做规划的时候，无论是圆桌会议还是逐个攻破，别纠缠多余的评断和情绪，也不要陷入对他人的喜好之争；最重要的是让大家达成“相对共识”，聪明人不入戏自己也别表演。做个知心大叔表怯场（甭管是抽皮鞭还是扛大刀请hold住场），接收多方的立场，找到表面原因和深层原因（聪慧如你还是要拿笔记记）。沟通模式可覆盖的问题点也还是用乔迁新居宴请狂朋恠友为例发散下：

规划阶段一定要舍得花时间趴在交互和实现方案论证上，如果到了具体开发时提出实现不了必须调整技术方案，这就是挖的坑。也许平常和开发小伙子们接得了段子也给得了信任，但这一耙子威信就弱了。这种不确定性因素带进执行阶段，每天心情简直生无可恋。合理制定各个里程碑节点，将里程碑的压力传递给项目中的每一个人；尽可能颗粒度量化到每周，梳理各个活动之间不同的逻辑关系：A完成B开始、A和B同时开始、A和B同时完成、A开始n日B可以开始（以此类推加入C、D、E……产品分析理顺各环节的分解也适用于项目任务分解wbs）。
项目规划的信息量不小篇幅最好够简洁，让重要干系人快速理解意图；确认高层授权落实团队需要的资源，按照项目的节奏和机制跑起来吧！
产品范围（产出的可交付成果）已分解，还需要对项目范围（为产出的可交付成果要做的工作）进行进一步分解。
比如，烤牛排是产品范围，而宴请人数、材料准备、烹制方式等就是项目范围。并且，整个项目的进度、成本、风险等都是由项目范围决定的，各组织间也需要交付和验收。
此时需要有条不紊的大管家上场（心中有一股强大的洪荒之力，不仅给自己提供力量，还能感染别人）：

章程首条：听产品大大的话，不要镀金。任务分解是以可交付成果为目标的工作层级分解，任何一点变化都可能引起连锁反应，避免小聪明式的捷径、费力不讨好的现象。

章程次条：每个任务有清晰的分割界限和先后顺序，事事有人负责人人有事可做。

章程末条：不可以有遗漏项。我们可以先把每个角色和任务分配对应起来。


（以宴请为例表现责任分配矩阵）
如上，任务的审核人、责任人、协助人、有谁提供输入、成果输出给谁就明确了。对于复杂程度高或风险大的项目，粒度更细致些比较稳妥。
项目计划于执行
管家分派任务后，还需合理控制每项活动的进度，即计划开始和实际完成时间。佛瑞德·布鲁克斯(Fred Brooks)说过：“无论多少个女人，孕育一个生命也需要九个月。”(《人月神话》)。
有一些软件开发任务是有顺序约束的，需要的时间是一定的，无论多少人参与时间都不会减少。另一方面，对于项目经理来说，技术过程服务于业务目标，需要把业务目标放在技术实现之前。
不论协调或是妥协，都要先弄清楚他为什么如此坚持、扩展或模块化、公司流程限制、业务上的意义？从对方的话语里指出可以成立的点，延展开去，再渗透其他重要干系人的看法。先肯定对方再讲自己意见，沟通会更顺畅有效。落地的时间节点，一定要获取主要干系人的认同、保留可追溯的痕迹，并保证所有相关干系人信息对称。
不同的职位层级/角色，对计划的关注点也不同：面向结果的、面向阶段的分解结构可以产出项目整体计划、子项目计划，月、周计划，列表、里程碑、甘特图等都可以展现。
理想很丰满现实很骨感，实施过程中往往不会那么顺利。在制定详细计划可以运用正推法vs逆推法，即最早开始/最早结束vs最晚开始/最晚结束。给每项重要任务安排警告时间点，到了这个点还没有完成，就要提醒或预警各方了。核心目的是通过这样的节奏，及时了解进度的情况，预见可能的风险，找到解决的方法，同时周期性和主要干系人进行沟通。
风险控制不一定能确保问题不出现，而是确保能够在最早的时间意识到问题的出现，及时采取应对措施。如果暴风雨来临，不要慌；以后回顾起这个项目，肯定是更喜欢大家拼尽全力度过瓶颈的日子，而不是一帆风顺的那些日子。
管家的优缺点
优点
[ol]

会管：任务基本符合每个人的喜好和擅长，不用马来耕田牛来打仗。知人善任，调动项目成员的积极性和主动性。

敢管：针对不好的苗头和现象，搞事情、违反原则的人敢于指出整改，努力营造有责任感、旺盛士气的团队氛围。在计划-监控-实施这个闭环管理中，项目经理会扮演卖萌的鼓励师、活力的小打杂、坚强的保护伞、奔跑的消防员、把酒言欢的兄弟，有时候也需要肩扛一把大刀用来摆谱加强气场坚持原则。
[/ol]

缺点
管家必败之缺点：事无巨细，所有问题都自己扛，不堪重负。

首先，会打击团队成员的积极性，破坏团队成员间信任关系只关注自己的任务和得失；

其次，剥夺了团队成员的挑战性和成就感，思路延展不到全盘，学不到东西是造成人员流动的重要因素；

最后，一个人的精力是有限的，抬头观望全局比埋头做事更重要。相信每个人都愿意很努力地往高处爬，不是为了被世界看见，而是更想看见整个世界。

项目变更
计划并不是一成不变的，永远不变的只有改变。
越是周期长的软件项目，变更控制流程越重要。问题也许是发生在项目执行阶段，但根源还是在需求管理阶段。
变更类型主要分为软件功能变更、业务流程变更和实施人员变更，这些都可能引发进度计划变更。项目经理也许没有权利拒绝某些变更要求，但有权利按照流程把变更提交到正确的层面做决策。
参考变更流程如下图所示：

在项目实施过程中，组织间陆续产出交付物，上一重要节点的阶段性成果，是否确认或是需要变更，对下一重要节点的正式启动至关重要。就像管家在晚餐开始前，都会严格地一一检查，用尺子量每一副餐具摆放的位置，蜡烛的长短，餐巾的折叠，鲜花的多少，灯光的明暗程度。里程碑时刻，可以提前制定程序规避遗漏项，主要包括参与人、时间地点、审核(验收)内容以及确认情况、审核(验收)意见、问题解决方式、签字(盖章)。

项目收尾
一步一个脚印儿，项目到了最后一个阶段的验收，按照交付标准保证满足了相应要求。所以就结束了吗？请先发出项目成果的报喜邮件(意义、感谢、展望)！
项目收尾阶段起码还要做三件事：

整理、归档相关文件资料(审计)；

综合绩效评定、表彰庆功；

回顾成功经验、问题不足及改进建议。

项目管理本身不生产价值，但是促使价值产生。愿每个项目经理灵活使用软性技能，根据受众适时调整角色，真正的情商，最高境界是自有分寸。
愿耐心看完小文的你，深知世界的复杂，依然选择面对复杂，保持喜欢（比心❤）。