上次写第一部分时还是在第一次汇报（6.11）的前一天，心里充满了忐忑，不确定客户对阶段成果能否认可，那天结果还算可以。这篇文章动笔是在第二次汇报（6.24）的第二天（居然断续写到了6.29），客户对这一阶段的成果给予认可，还是很欣慰的。连续一个月的密集高节奏工作也算是告一段落。这段时间，上下班忽略、周末忽略、假期忽略，承受着来自客户的责备、不信任，这些都接受，不说话，笑脸以对。这段时间，有来自领导的信任与加油、有多部门的支援、伙伴的同心协力，这些都感受，不说话，更努力。所有都只为最后这个令客户、令领导、令队友、令自己满意的结果。在享受满意结果，感慨辛苦过程时，也不断思考这个项目管理过程的得与失，用复盘（我从任项目经理的角度复盘整个过程，项目成果是项目团队共同努力的结果）的心回顾整个过程，只为下一次做得更好。
一、进场时的情况很不美丽
这是一个G级项目，项目实施成功与否，将有可能影响公司产品在这个行业内的口碑和市场。进项目组前，甲方拉了一个长长的单子有20个大小问题，并投诉到公司。在这样的状况下，我被临时调入项目组任项目经理。进场后，真切体会到客户自上而下的不满，项目成果存在效果、效率、功能、界面等好多问题。客户要在6月底向上级领导汇报，“能做你们就解决问题，不能做你们就走人”，这就是当时入场时的状况。
二、进场后的目标非常明确
进场后的目标非常明确，在一个月之内解决掉客户反馈的问题，完成主要功能研发，让主要干系人的满意，争取到给更高领导汇报的机会。领导给我的要求是：以目标为导向，不惜一切代价。
三、一个月后结果基本合格
一个月之后，项目组解决掉客户最初反馈问题的90%，完成核心功能研发，完成（6.11、6.24）两次面向关键干系人的汇报，汇报效果良好，客户满意度能达到及格（嗯从很低很低的谷底上来，及格就已经狠狠开心了），争取到继续向上汇报的机会。
四、是什么保障了这一个多月的成果？
是的，比较短的时间，我们做了什么来达到目标呢？我挑出其中重要的四个方面。
1、高级别关注 保障了项目资源
公司在接到投诉后第一时间做的事情就是整合重要资源。多个级别的领导对应客方各领导做客户公关，给项目争取到时间。同时为项目组调集了高级别资源，从产品研发与支持、数据优化、应用开发、项目管理等多个方面抽调了各岗位上专业优秀的人进入项目组，虽然大家临时组队，但都是精兵强将，确保优势力量在本项目上的集中。
资源一下子进来，为了确保资源的充分利用，我们将资源进行了定位，共成立了5个重要的群，除了领导所在的群之外，我重点维护了与公司内部产品对接的群（跟产品负责人直接对接，确保产品使用上的问题能被及时解决）、项目现场群（现场任务分配，跟进并反馈项目每天工作状态）以及跟客户对接的群（跟客户联系人及时同步项目状态，目的是让客户及时感受到我们的努力以及项目进展）。
领导给了高级别资源，面向这五个资源群，作为项目经理，我做的一件很重要的事情就是将每日工作状态以及现场与客户沟通的情况及时在群内同步，信息的同步，使得大家能够对项目的形成共识，包括进展的共识、困难的共识、资源请求的共识，使得各组能够及时给予资源和支持。
2、问题多而不乱，现场高效组织
在资源保障到位的前提下，现场如何高效开展工作是项目经理需要重点关注的，这一环节的做法，我在《临时抽调入项目组的一点小结（一）》进行了说明。重点是目标明确、分解任务，及时跟踪、更新并同步状态。
3、保护好项目成果，（努力做到）每一次让客户都能看到进展
在现场工作，客户随时都有可能过来了解情况，看看进展，但是项目组在过程常常有出图效果很丑、出图效率很低、功能崩溃等各种状况，这种状况下如果客户过来想看看进展，我们尽量委婉拒绝对方。因为如果这是给客户看了，不管当时的状态是否是一个严重或者简单的问题，给客户的感觉都会很差，会更加损害客户的信心。所以，我们做到的是，尽可能跟客户在约定时间共同看一下项目成果，并且尽量去做到每一次看都要有点进展，这样做的目的也是通过每一点的进度一点点积累客户的信心。
4、做好成果汇报，让汇报有思想
关于做得好与说得好，很多人都有过辩论，不赘述。我深信做得好是基础，说得好是关键。在项目上，客户汇报是项目成果的直接呈现。不同的汇报思路与水平，决定了客户双方领导对你项目的打分，甚至项目的成败。我的领导对客户汇报非常重视，汇报前一天拉着我和另外一位同事打磨汇报脚本，一直到凌晨才有一个基本满意的结果。成果汇报稿在组织上采用总分总结构化行文。在内容上，总结了项目的目标、技术特点、能力体现、核心功能、典型业务场景。有意思的是，领导将项目的思想总结成金字塔（塔尖是目标和特点，塔身是核心功能、能力体现，塔底是业务场景），跟《金字塔原理》一书所提内容有异曲同工的意思。
这样的汇报思路，让汇报成体系，让听汇报的人能抓住重点、感受到系统的逻辑或者系统的内在思想，能给人留下高级感。
五、我感受最深的是什么？
1、时间和需求是这个项目的两条高压线，信任度低的情况下，感受到需求管控的难度
自进场后，就感受到客户的需求很急切，要求快速（快速到今天提完，明天看到结果）响应。项目组进场后，从对最终结果负责的角度（或者希望能在满足客户需求的前提下创造一点客户惊喜），项目组计划要对原系统重构，在满足客户当下需求与系统重构计划的压力下，项目组做不到按照原计划推进项目进度。没有办法的情况下，项目组被迫扯出了两条线，一条线快速响应客户变化，另一条线赶工快速重构系统架构和界面，在赶工的后期完成了两条线的回合，呈现了汇报系统的成果。
但是要知道这个过程，实际是很辛苦的。一方面项目成员压力很大（我记得在第一次汇报时，有成员不在场，后来我问为什么没来参加成果汇报，这是咱们成果体现。他对我说：“刚才有一阵子感到心悸，跳得很快...”，我听了不知道该怎么安慰他），另一方面在开发过程中做不到每次都保障汇报效果。其中就有一次正在合并过程中，客户要求必须汇报，结果出了不少问题，导致客户不满意。
在这个过程中，我尝试过通过沟通管控客户需求，听一下我们的计划，项目组需要时间来一个相对好的转变。但是由于前期客户信任度很低，他除了马上看到效果外，不想听任何的计划或承诺，那个时刻，我真切感觉到沟通的难度，所以选择先不说了，能做的也就只有是努力赶进度，赶效果，用结果来讲话。
2、扒开客户号称的需求，找到客户的真正需求
项目经理对需求很敏感，我自认为对需求的识别和管控都还不错。但是在这个项目上却还是吃了伪需求的亏。项目组进场后在对系统重构的过程中，继承原有内容时，虽然我对某个需求（跟ZRZY相关的多个视角的快速定位）有过疑问，但是由于客户说过继承，我就很漂亮地给继承下来了。结果客户对这个需求的继承效果给批了一通。究其原因就是我知道这个需求是什么，但是没有去了解或者挖掘这个需求要解决什么问题（该需求只是为了方便演示，并不是重点，不希望它多醒目。我把它搞得很漂亮适得其反了），好在在识别到真正需求后，我们快速响应，最终做到客户满意的效果。
这里我想说的是，在跟客户沟通需求是，要做两个层次上的事情，第一个层次是弄明白客户需求是什么，也叫澄清理解偏差。怎么做叫弄明白呢？可以在理解后，用自己的表达认识复述一遍，确认自己的理解跟客户表达的是同一个意思。这一步做到了，可以说清楚了表面（客户号称的）需求；第二个层次是思考这个需求要解决什么问题，也就是真正需求是什么，也叫澄清隐藏偏差。怎么做到挖掘真正需求呢？站在对方的角度，多问为什么，客户要这个需求的原因是什么？是要解决什么问题？这一步认识到了才叫发现了真正需求。找到真正需求的思考方式，可以参考Simon Fisher的冲突层模型。
所以说，做需求，一定要扒开表面需求（是什么），找到真正需求（为什么）。
3、管控客户预期，将我们能做到以及客户预期的两条线慢慢对齐
项目交付实际上交付的是客户的预期，当交付结果与客户的预期结果一致时，客户满意度高。反之，当交付结果达不到客户的预期，客户看到的现状与ta的期望之间有距离，那么客户满意度就会下降。
要做到提高满意度，要做的就是缩短交付与预期之间的距离。怎么去缩短距离呢？那就需要从管控需求开始，过程中去管控客户的预期，说是管控，其实就是通过沟通让双方对需求形成共识，对预期的成果形成共识，逐渐将客户的预期与我们能做到的水平，这两条线拉齐。当结果呈现时，客户的预期不会跌的很低，或者说最好能制造一点超出预期的东西来提高满意度。
六、总结
全文用复盘的思维回看项目，从一个多月的项目经历中吸收经验，反思不足，增长力量！做项目看上去是在组织项目团队完成一个项目成果，最终交付这个成果。实际上是在双方有一定信任的情况下，乙方交付甲方的预期，兑现承诺。结果符合预期，信任感增强，好感增强。结果达不到预期，信任感降低，好感渐渐损失。
项目中双方的关系如此，人与人之间的交往亦如此。