|
|
# 16｜学会对焦，从头到尾把事做成（下）
|
|
|
|
|
|
你好，我是雷蓓蓓。
|
|
|
|
|
|
上节课我跟你分享了目标和人员的失焦。对于一个完整的项目，当人和事都清晰之后，你还可能会面临以下两类失焦：
|
|
|
|
|
|
1. 计划的失焦：团队成员不知道什么时候该干什么，互相依赖或冲突。
|
|
|
2. 行动的失焦：遇到问题时，你说要这样，他说得那样，没有统一、可落地的解决方案。
|
|
|
|
|
|
要想“使众人行”，从头到尾把事做成。接下来就需要对齐计划、统一行动方案，攻克计划失焦和行动失焦这两个难题。
|
|
|
|
|
|
## 第三步：对齐计划，设定步调节奏
|
|
|
|
|
|
项目启动之后，项目经理要做的第一件事，就是制定一份靠谱的计划。这份计划会把团队各方的工作，放在同一条时间线上，让大家明确地知道什么人负责什么事儿，什么时候该干什么事儿，从而解决互相冲突或依赖的问题，设定好协作节奏和行动步调。
|
|
|
|
|
|
> 启动会之后，团队的热情空前高涨，不过艾文却忙得焦头烂额，因为每天不断有人过来问她各种问题：我需要更加明确的需求，好提前做些架构准备，什么时候能给？上线前是否需要安排灰度测试？等等。
|
|
|
|
|
|
> 各种大小会议，扑面而来的大量信息，艾文感觉自己快要被淹没了，一切都乱糟糟的。
|
|
|
|
|
|
> 吃饭时艾文坐在我对面，顶着一头同样乱糟糟的头发，向我求助：“老师，启动会过去3天了，我也知道要做个计划，可现实是，我跑去跟开发确认工作量，开发说策划稿还没完全定呢；问策划，策划说我能给的都已经给了，现在方案卡在算法组那边，要看他们评估下来可行性如何。这不，我上午刚刚找了算法组……”
|
|
|
|
|
|
> 我看着艾文一脸无奈的样子，就知道之前讲过做计划的知识点，她还没完全参透。“艾文，还记得我说过，**计划是各角色协调工作的基准**。你知道什么叫“基准”吗？”
|
|
|
|
|
|
> 艾文摇头，我用筷子在桌上画了一条线，“基准，就是这样一条线。”看着艾文疑惑的表情，我笑了笑，接着说，“现在，发令枪已经打出去了，有人很积极想要抢跑，有人说我还得再等等，结果是大家一顿乱跑，对吗？”
|
|
|
|
|
|
> “你说得太对了！现在每个人都来问我，到底该怎么跑。”艾文点头表示认同。我看着艾文，继续说：“所以解决方法也很简单，那就是你先画上一条基准线。”
|
|
|
|
|
|
> “我来画？可是，现在还有很多不确定的部分，要是画得不准怎么办？”
|
|
|
|
|
|
讲到这里暂停一下。艾文的问题其实很普遍，如果要把计划中的所有不确定都搞清楚，再开始做计划的话，那恐怕项目都快要结束了。你要知道，计划永远只是个预测。你先给出一个预测，就可以**让这个不确定的世界，更多一点确定**。
|
|
|
|
|
|
这个时候，项目经理需要做的，就是跟项目组成员设定好步调节奏。**对齐计划，就是画出一条清晰明确的基准线，明确谁先跑，谁后跑，什么时候交接**。一开始画得不准没关系，你可以先拿出一版计划来讨论。
|
|
|
|
|
|
> 艾文回到项目组，迅速把各个角色叫到了一起，并拿出了自己画的一个初步计划。当有一条时间线真实摆在面前时，马上就有人提出来，“如果要在这个点提测的话，必须提前3天把动画效果给到我”，于是艾文就在前面加上一个点，标注好截止时间。
|
|
|
|
|
|
> 有人说，“算法这点时间肯定不够的，加上调优时间，至少要再加5天。”“5天？如果这样联调怎么办，提测肯定来不及啊。”开发连忙叫道。
|
|
|
|
|
|
> 艾文见状问道：“这样，算法今天单独给我一个时间安排，把调优时间分开。我们插入一个中间节点，用来标识开发什么时间，可以先开展这块的工作。”算法和开发同学都点头同意。
|
|
|
|
|
|
> 大家你一言我一语，不到半个小时，艾文处理了近10条建议，这么一轮下来，一个计划终于成型了。更重要的是，这个一起做计划的过程，让大家**更清晰地对了焦，明确彼此的相互依赖和影响，以及接下来我们该怎么更好地合作**。
|
|
|
|
|
|
> 会后，艾文总结大家的讨论，又结合各部分详细的WBS工作分解，终于把新版的计划整理了出来。这版计划公开发布之后，团队的节奏一下子清晰起来，每天来找艾文询问的人立马少多了。
|
|
|
|
|
|
关于做计划的步骤和要点，我在第5讲中有详细的介绍，你可以返回参考查看。另外，有同学在留言区提了一个非常有价值的问题，他说第5讲中的计划图画得非常好，但是在实际项目中，往往时间非常紧，并没有足够的时间去画出很美观的图，该怎么办？
|
|
|
|
|
|
事实上，画一张多么漂亮或精确的图，并不是做计划的重点。
|
|
|
|
|
|
总结来说，你需要明确两点。第一，**计划是你用来跟大家对焦的工具**，是用来拉齐行动节奏的。通过计划，成员之间可以更清晰地了解彼此的相互依赖和影响，知道接下来该以怎样的节奏合作，这才是更重要的。就像艾文上面的故事中，她用这个计划图，**引发了大家对于时间线的充分交流和碰撞**，最终拉齐了大家的节奏。所以计划图是否美观，并没有那么重要。只要清晰、可视，成员之间可以互相看懂就行了。
|
|
|
|
|
|
第二，计划并不是一次性的工作，在不确定的大环境下，计划作为对焦的手段，是应该伴随着项目的进展，与时俱进，渐进明晰的。你可以在第13讲中，找到做计划最实用的工具实践。
|
|
|
|
|
|
## 第四步：统一行动方案，有效推动问题解决
|
|
|
|
|
|
在项目进入执行阶段之后，项目经理的视角，始终要关注对项目成功真正重要的事上，不断地去发现问题、找到统一落地的解决方案，并有效推动问题解决。
|
|
|
|
|
|
> 计划发布之后，艾文跟各组明确了常规的沟通机制，包括每周的状态同步会、工作群以及周报。项目逐渐步入正轨，艾文总算有时间，仔细思考对项目成功真正重要的事了。
|
|
|
|
|
|
> 艾文拿出了计划甘特图，认真研究起来。和她之前的判断一致，关键路径（项目中工期最长的路径）果然是算法，且这条路径的成果，直接决定了整个活动的成败。加上算法组并不在艾文老板的范围内，属于跨部门合作，艾文意识到这是整个项目当中管理最困难的部分。
|
|
|
|
|
|
> 这不，刚过去3天，问题就来了。原本策划的想法被算法组验证不可行，策划稿看来全部要大改。艾文顿时傻眼了，之前好不容易对齐的计划，恐怕也要泡汤了。
|
|
|
|
|
|
> 于是艾文风尘仆仆地找到了我，“老师，计划赶不上变化，算法组的成果不确定性实在太高，这么下去不是办法，我该怎么办？”
|
|
|
|
|
|
这里停一下。在执行过程中，关键路径上的问题会让整个项目组陷入巨大风险。所以，**凡是关键路径上的重大问题，一定要当作最高优先级**。
|
|
|
|
|
|
那么这个时候项目经理需要做的，一方面要**拉响警铃，引起全项目组的重视**，迅速组织所有相关方，集思广益；另一方面，还要**结合各方意见，统一行动方案，保证项目快速往前推进**。
|
|
|
|
|
|
> 于是，艾文果断拉了个会，找来算法、策划、开发三方，把最新的情况同步给了大家。开发首先跳起来了，“这样不行啊，这样改来改去，我后面通宵都来不及！”算法和策划肖云对望了一眼，肖云忍不住开了口，“你以为我想这么改啊，算法不确定性确实比较高，我们已经以最快速度在研究了，真的没办法再加快了。要不然，你行你上？”
|
|
|
|
|
|
> 会议一下子陷入了僵局，谁也不愿意说话。艾文见状，忙出来打圆场，“大家先别急，有难度能理解，今天咱们就是集思广益，在接受这个不确定的前提下，看看有没有更好的办法，让我们大家的工作都更有保障？”艾文的话，让大家陷入了思考。
|
|
|
|
|
|
> 一阵沉默之后，算法同学开了口，“各位，算法工作我做了十几年，确实是这么个性质。不过想要加快，倒是有个办法。之前我们项目攻坚的时候，大家都是封闭开发，现在我们几个坐得太远了。如果我们可以早点沟通想法，趁早提出问题，策划稿就不会需要改那么多了。”策划肖云听了，立刻点头同意，开发也欣然响应。
|
|
|
|
|
|
> 于是，“小黑屋”计划就这么愉快地决定了。会后，策划、算法、开发、测试马上都搬进来了，有问题就吼一声，立刻有人响应。不到两天，Demo就做了出来。
|
|
|
|
|
|
你看，项目中遇到问题很正常。不同的立场会让大家各执一词，你说要这样，他说得那样，往往好几天过去了，事情还是停滞不前。要想“使众人行”，作为项目经理，这个时候你该怎么做呢？
|
|
|
|
|
|
答案就是放下个人主观评判，**客观地去看每个人观点差异背后，事实的合理性，并以此为基点，找到统一且落地的行动方案**。故事中的艾文就做了一个很好的示范：承认算法拥有不确定性，基于这个大家都没有疑问的事实，再去引导大家寻找更优的方案，最终找到了“小黑屋”这个解决方案。这不仅降低了关键路径上的风险，同时还促进了项目的更多突破性进展。
|
|
|
|
|
|
注意，承认事实合理性，并不是要你强行认同每一个观点，而是要**承认主观背后存在的客观事实。**当事情陷入僵局时，你可以试着从对话中找到这样一个具备共识的小基点，然后围绕这个共识，把大家拉回到同一个现实中。再基于此，去共创统一的解决方案。
|
|
|
|
|
|
> 算法问题突破后，没想到还有更棘手的问题等着艾文：测试组的三个实习生由于个人原因，一起提了离职。这下测试的问题就很难在短时间内解决了。
|
|
|
|
|
|
> 艾文集中生智：“对了，我们搞一次Bugbash，动员大家一起来测试！这样可以让大家提早感受活动玩法对用户的吸引力，同时也能解决测试的问题。”
|
|
|
|
|
|
> 于是一拍即合！在项目组的全员周会上，艾文做了Bugbash的动员，明确时间就放在第一轮功能测试结束之后。项目组从上到下，放下所有工作，一起来给活动找Bug。
|
|
|
|
|
|
> 到了找Bug这天，不光是开发、测试、产品、设计、算法，连市场、运营、编辑，都被艾文关进了小黑屋，1个小时全心全意找Bug。艾文将现场人员分组，每个组划分了不同的测试方向，并且在大屏幕上，实时滚动Bug排名数据。
|
|
|
|
|
|
> 一场活动下来，收获了269个Bug，49条建议，高峰和老K还给获胜的前三位同学颁发了大奖。除了消除质量隐患外，这次活动中，市场同学发现了一个活动规则上的漏洞，阻止了一个被攻击的可能性；大家还在运营方案及文案设计上，接连做了几次头脑风暴，用户的可玩性增强了不少。
|
|
|
|
|
|
> 在大家紧张有序的共同努力下，“测试一下你的性格原色”活动如期上线。上线5个小时内，就完成了既定的活动目标，学生群体很买账，朋友圈里到处是刷屏的颜色。而且由于测试出的颜色和文案深戳人心，用户纷纷晒图交流，好几波话题都上了热搜。
|
|
|
|
|
|
看似一场突发且无解的危机，竟然被一个充满创造力的想法激活，不仅解决了当下测试的问题，同时还变成了一次项目团队整体作战的突破契机，得到了上上下下的一致认可。所以，你看项目经理解决问题的途径，并不只有加人一条。
|
|
|
|
|
|
办法总比问题多！
|
|
|
|
|
|
从艾文的故事中我们可以看到，**从头到尾把事做成，意味着不被问题本身限制，发动所有可以发动的力量，围绕项目目标，创造性地解决问题，找到统一且落地的解决方案**。
|
|
|
|
|
|
另外，这次突如其来的风险，也让艾文充分认识到了，**项目风险不能只靠上报，项目经理一定要深入了解一线**，不能假手于人，做信息的二道贩子。此后艾文一直谨记我的教导，有意识地和那些平时交流甚少的团队多聚餐，这个习惯让艾文在风险管理上进步了一大截。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
好了，艾文的故事就讲到这里，从头到尾经历这么完整的一次项目实战，艾文说，读再多的项目管理书，都不如真刀真枪练一次！
|
|
|
|
|
|
项目管理，永远是一门实战科学。要想从头到尾把事做成，过程中你需要战胜四个失焦：目标的失焦、人力的失焦、计划的失焦、行动的失焦。应对以上四类挑战，最根本的就是**从项目管理底层思维出发，在各个场景中，真正把“对焦”吃透**。
|
|
|
|
|
|
## 畅所欲言
|
|
|
|
|
|
今天，我与你分享了项目管理的底层思维，请你结合自己的场景，来跟我聊聊，你所面临的哪些问题，是可以灵活运用“对焦”思维来解决的？对此，你有哪些好的做法？
|
|
|
|
|
|
欢迎你畅所欲言，我在留言区等你。
|
|
|
|