项目经理的宏观和微观管理
不谋全局者，不足谋一域。
以下正文转载来自：https://mp.weixin.qq.com/s/yvSzW9I1yqeKpzCTmQsqtQ
作为项目经理，你做的每件事都应该紧扣大环境这一背景——忽视这一点就一定会失败。相对地，你同时还负责项目的日常细节。在以进度表为核心的项目计划中，战略描绘的是全局，而进度表则给出了按任务逐项详细分解的工作流。因此，你必须依靠一手抓宏观，一手抓微观，才能实现对项目执行的管理。
对项目前景的展望，第一步是描绘全局——战略。我们按照当前的项目节奏会取得什么成果它在整个项目中的运作机制是怎么样的？各项工作彼此之间有何关联？团队成员应该是知道这些问题的答案的——毕竟，他们会帮助你制定战略——但当他们关注具体的可交付成果时，可能会迷失原本的目标。因此，你需要时刻紧盯战略目标，检查支持这些目标的具体任务，以确保各项工作得以完成。当你了解的情况越来越多，你会希望确保相应的工作内容都按正确的顺序一一完成了。
追踪项目执行的工作大部分通过项目进度表来完成。与团队成员合作以记录其真实的工作完成情况——每个任务的开始、结束、工作量或持续时间——看看这些会对下一个里程碑和项目结束期限有何影响。如果进度表得到了精心维护，那么一旦有什么事偏离了原计划，你就能很快发现。一旦你发现了实际情况与原计划的偏差，就应对照战略理清其整体影响。尽管你可能会考虑对进度表进行调整以继续执行原计划，但你最应该该做的其实是抵制这种诱惑。
我见过有项目经理在进度表上乱了方寸，不断把各种任务调来调去，以显示他们能够赶上最终期限。等到他们发现自己做不到的时候，已经没时间用别的方法挽救整个项目了。如果他们曾经停下来，对全局进行评估，就会发现项目的漏洞已经大得无法弥补，完全不是在进度表上改几个链接就能搞定的。这些项目经理没能很好地掌控细节，而是被细节牵着鼻子走。
当战略已经明显不可行时，你应当从工作中抽身，评估当前的状况，分析下一步的对策。对不同的假想情境进行剖析，你就能知道该在战略和进度表之间如何取舍。
等到你决心已定，就需要对战略进行重新规划了。首先更新你的战略，然后按照这个战略更改任务，对进度表上的链接和持续时间进行更新。这是你在项目规划阶段的工作的延续。
注意计划相关性
作为项目经理，你有责任统筹全局。当项目团队成员专注于贯彻细节时，你需要确保这些细节能形成合力，得到切实可行的可交付成果。当他们专注于眼前的工作时，你的眼睛应当看到明天、未来几周和几个月后的发展。
在你制定战略时，首先会考察如何规划以逐渐打造出最终产品。在这一战略的每个阶段，你都要确定需要完成打造最终产品的哪些部分以最终进行整合。你需要对当前的阶段有着透彻的了解，还要清楚它对后继的其他阶段有何影响。这么做的重要性在于，一旦在当前阶段遇到了问题，你就不得不作出决策，而这个决策能直接影响后继的阶段。在某个阶段匆忙抛出的应急方案可能与后继的阶段发生冲突。你之后又不得不取消这个应急方案。因此，最好是制定与未来的工作协调一致的解决方案来理会当前的问题。
在你管理团队的时候，需要明确对最终产品而言哪些功能是必不可少的，并强调将项目的所有成果按时整合的重要性。团队成员必须明白他们需要完成哪些工作才能开始进行整合，而这些工作与其个人认为的首要任务可能并不完全重合。比如说，当满足绩效要求的难度较大时，开发人员可能会专注于解决这些限制因素，从而忽略了其他团队成员需要的功能。然后，如果被忽略的功能正是开始整合过程所需的，这种缺失就会耽误其他团队成员的工作。
密切关注细节
反思战略（即全局情况）不用花太多时间。你真正需要关注的重点是项目进度表，以及项目计划中的各支持环节：质量、风险、实现的手段等。在战略方面，你应当预判接下来几个阶段的情况，也就是提前几个月进行预测。而在项目进度表方面，你应该关注更短的时间段（通常为四周左右）内的项目细节。
考察项目细节时，你需要处置的事项包括：
整个团队即将取得的下一个成就：必须达成什么目标和达成的方法。考虑如何统合团队，避免团队成员各自为政。
对哪些事项来说，时间比较关键：哪些必须提前完成或者前置期较长？是否该在某些事项上加快进度？团队成员的认知和首要任务与你不同，你觉得时间紧迫的事项可能会被他们忽视。你需要提醒他们，甚至协助他们的工作。
有什么风险？风险应当与可交付成果相关联，而且也应该有个时间表。在你生产这些可交付成果或按照给定的时间表提前准备时，应当考虑该怎么做才能最透彻地了解风险，从而确定在最初的风险计划里有哪些措施是行之有效的，以及在必要时可以采取哪些其他的手段来规避风险。
哪些会严重影响质量我们能做些什么来巩固内部质量，比如说通宵测试？个别成员会在什么地方偷工减料（例如测试）？如果真有这种情况，对后继的阶段或最终的产品有何影响？然后，驱动员工采取行动的主要因素是他们对当前情况的理解，你需要确保这种理解不会对后继进度有什么损害。
在规划阶段，你的项目计划可能会由于时间紧迫或无法预测未来，因而不得不进行假设或简化。现在你的时间更少，但同时你也开始了解到实际的进度。在你检查项目进度表时，重新梳理当初的假设，判断原来的时刻表是否依然合理。不要盲目地坚持已经失效的计划。不过，你还是必须努力坚持当初制定的里程碑。你必须尽一切努力避免违背自己的承诺。
追踪和管理项目的执行情况
尽管前瞻性的检查很重要，但你应当把更多的时间放在对项目执行的追踪和管理上。追踪就是判断和记录你当前的进度，并将其与标准计划进行比较，以衡量项目进展的健康程度。你为此对项目进行了快速评估，以便决定是否需要进行更详细的评估。如果你定期开展这项工作并且十分顺利，就有可能在问题刚冒出苗头时尽早发现它，从而得以留出更多时间来应对之。
追踪工作首先从项目进度表开始。针对正在进行或近期完成的任务，定期（一般是一周）收集以下相关参数：所有已开始任务的实际开始时间；实际完成的工作量；正在进行的任务的剩余工作量；已完成任务的实际完工时间；已分配资源的分配比例（如与原分配计划不同）。
这些就是你掌握的“实际情况”。
上面列出的并不包括完成比例，因为这个的参数可以变得非常主观。我有很多次都在已经完成了90%的任务上卡了好几天甚至好几周。这个参数很能误导人：如果你只更新完成百分比，你的进度表处置软件会将实际开始时间设置为预定开始时间，将实际完工时间设置为预定完工时间等。那么当进度表理应进行变更时反而不会有变化。更新上面列出的参数将迫使你的进度表处置软件为你计算完成百分比。该软件还会根据实际数据调整下游任务的日期和里程碑。现在你可以轻松地看出项目中哪些部分进度超前，哪些进度落后。
定期进行这样的追踪工作是很有必要的。只有经过正确地维护，你的进度表才会提醒你潜在的问题。而且，每周都对进度表进行更新的话，工作量并没有多少。如果你平时把更新工作放着不管，等做起来的时候就会叫苦连天。如果你的老板需要在几个小时后召开的会议上更新一下项目进展，你要么能随手拿出数据，要么就只能乱成一团，忙着更新早就过时的进度表。
维持适时更新的进度表是管理一个项目必不可少的，但这还不够。项目的重点不是时间，而是创造有用的产品。时间只是一个限制因素。根据你的预期，你让项目团队将精力集中在代表整合过程开始的重要里程碑上。在追踪时，你必须识别项目的当前状态：是否所有人都在整合期限前完成了进度？他们是否已经开发出了项目所需的和原计划预定的功能？是否存在潜在风险？然后将这些答案综合起来，看对未来的里程碑有何影响。比如，你的预估数据是否要进行更新？
在进行追踪时，记住你最宝贵的项目管理工具就是你的耳朵。倾听团队成员的反馈，你能从中了解到未曾预见到的问题和机会。利用你了解到的这些信息，你就能在成功管理项目方面大有作为。
还有，虽说项目经理容易牵扯进当日最重要的事务，但他们恰恰不应该这么做。项目经理应当有选择性地参与处置对全局有重大影响的问题，比如说，下一个里程碑。
收集信息
为了追踪和管理项目的执行情况，你需要收集信息，即搞清楚项目进展的实际情况如何。收集信息有两个好方法，一是与团队成员个人沟通，二是召集整个团队开汇报会。这两种方法是互补的，所以你不能只用其中一种。
一对一沟通：收集信息的最佳方式就是和你的团队成员保持联系。惠普为此引入了一个很有效的管理技巧，名为“走动式管理”（MBWA）。这不只是搜集项目状态信息的好方法，还能提高团队成员个人给整个项目带来的价值。实际上，只要团队成员手头没有什么十万火急的任务，你就可以走到他身边开始跟他聊。用这些问题作为开场白：工作怎么样了？有什么新问题或者麻烦吗？你需要什么帮助吗？
然后你听他说，接着再问一些问题，这样做既是为了确保你理解他的话，也是为了加强沟通的效果。这个时候很适合讨论接下来要达到的里程碑，并验证该团队成员是否能及时完成项目。如果按时完成有困难，你们可以讨论一下有无其他方法，可能的话或许能就解决方案达成共识。如果做不到，就让该团队成员继续考虑。如果发现了特别好或者特别糟糕的消息，你可能需要即时召开团队会议来进行讨论。
对于这类谈话，你需要谨记一点，这是一种简短的非正式的聊天而非拷问。你是为了帮助这名成员成功完成工作任务才和他交谈的。
项目状态会议。你应当定期（通常为每周）与整个团队举行状态会议。尽管你在状态会议期间也在收集信息，但让团队专注于项目，尤其是下一个里程碑，这才是更重要的事。所以，在会上应该让每个人快速汇报最新的进展和遇到的问题，并讨论接下来数周的安排。在合作意识较强的团队环境中，团队成员会与状态会议之外的人分享遇到的问题并拟定解决方案，但有时候项目中也会出现意外情况，很适合拿到状态会议上讨论。
一一询问每个成员，了解他们是否已经为即将开始的项目整合做好了准备，如果没有，是哪方面没有准备好。如果发现有人无法及时完成可交付成果，一定要召集大家集体讨论这一情况对其他团队成员的影响。让整个团队共同讨论不同的情境和潜在的应急方案。在讨论中要营造紧迫感。
一定要让团队结合战略进行讨论。这样你才是在管理最终产品开发的节奏，而不是单纯地对单独的可交付成果或者时间进行管理。
最后，会议开得越短越好。即使你原本打算开一个小时，也可以在15分钟之内就开完。如果没有讨论的必要，就不要多花哪怕一分钟。团队成员都愿意开短会。出现重大问题时就应当花多些时间开会，这一点是显而易见的，因为所有人都会参与讨论如何解决实际的问题。