项目崩了？不用讨论，经理的锅！
叶小钗约 10 分钟关注公众号回复1，加我微信
这是管理课程《揭秘公司治理框架》的第二章《人治的英雄经理》、第十四节《项目管理，经理的主战场》
如前所述，公司的运转是围绕着项目执行而展开，而一线经理是项目执行的核心力量，所以本节我们聊聊如何做执行侧的项目管理。
首先，回答一个问题什么是项目？
什么是项目
所谓项目，即为创造独特的产品、服务或成果，而进行的“临时性”工作。
所谓项目管理，即通过运用管理的知识、工具、技能和技术于项目上，来解决项目的问题或达到项目的目标。
根据这几年的经验，项目管理事实上是一门实践的学问，正因为是实践而得来的，面对同样的场景，不同的人处理的方式会不尽相。
但是其基础的思维框架是大同小异的，只有通过不停的实践，才能真正掌握项目管理的精髓，成为好的项目实践者。
作为一个全局负责人的话需要特别有节奏感。
这个节奏感，如王者荣耀打野一般，需要掌握大龙小龙刷新的时间点、需要在合适的时间点去推塔，也就是：
在正确的时间做正确的事情； 暴露正确的信息，不要乱带节奏，导致项目失利；
这个就是所谓的节奏，再说直白一点就是：对一件事的时间点（事件点）的敏感，而后对信息的正确处理。
举个例子，在一个产研项目中，作为一个项目负责人，需要知道的几个发力点：
产品运营驱动 技术驱动 测试驱动 商务运营驱动 负责人组织复盘
从产研项目执行角度来说，产品负责人的发力主要点是前两个阶段，也是信息对齐、需求梳理的重要阶段。
镜头再拉进到技术项目负责人，如果过早介入，需求产出受挫容易白费力；
晚一步介入，需求不清，会导致研发、测试走弯路而项目延期甚至流产；
在合适的时间点将推动项目运行的主导权交给对应的队友，才更容易成功。当然从头至尾的信息传递都是项目负责人需要做好的。
综上，项目做好其实不难，只需要：
掌握节奏，让合适的人做合适的事； 风险暴露，信息传递； 协调资源，解决卡点；
从执行角度看，一个项目的完整周期是这样的：
根据以上内容便可以得出项目执行的两个核心：准备清单与清单解决。
一、项目启动模板
项目是十分复杂的事情，因为他会涉及非常多的人，一件事情涉及的人越多，那么会更难：
除了事情本身专业度所带来的困难，一般来说最大难度来源于两方面：
沟通过程中产生的信息不同步； 做一件特定的事情（一类事情），总是会出错；
所以需要一套机制来保证多数信息的一致性，以便我们要追溯某一段信息的时候无从下手；
其次，需要一类清单，这种清单记录了我们之前做某一类事情犯过的错，清除所有的错误可能，那么我们就会更容易达到成功，所以这里给出了项目启动模板：
标红的部分是必须提供的，使用项目模板，会保证项目执行的下限。其中项目日历大概如此：
项目日历一出，整个项目的时间线就确定了。
二、确认风险
项目旁枝错节过多，项目负责人想要把握每一个细节无异于痴人说梦，这里便要求相信队友。
但是相信不是不作为，在我看来项目负责人80%的精力应该放到风险管理
确认风险点，规避风险点，设计风险已发生的解决方案，是一个项目的重中之重！！！
那么，如何规避风险呢？首先得找到风险点，于是需要定义什么是风险点。我们做一个项目，需要穷举（尽你之能）什么是绝对不能接受的情况，这个可以是：
项目延期XX天（会不会延期、信息不同步等等因素） APP崩溃 订单不能支付 某页面打不开 充值有漏洞 结算延迟超过底线 ......
不同项目会有不同的风险点，首先穷举这些风险点，然后再看看我们要处理哪些风险点，这里的规则是：
这个事情会不会发生，如果发生你能不能承担。
一旦确定要处理的风险点后，那么项目负责人的工作便确定下来了：解决掉所有的风险点，其他全部交给队友。
这里担心各位疑惑，再啰嗦几句：
① 项目初期，根据过往经验（有些项目是周而复始的、有些项目是同一类型的），判断可能会有什么问题（项目负责人越高阶，此能力越强）
② 需求评审阶段，让关键同学提出风险点，最终确认项目日历
③ 评审后整理所有风险点，并且了解细节，再拉风险评估会，与队友确认风险点，并要求队友提供对应方案
④ 如果风险点技术侧不能绕过，马上拉运营、产品商量规避方案
⑤ 如果不能完全规避，与对应同学设计如果已经出问题的项目补救方案，和触发机制
虽然我们期望能前置所有的风险点，但这往往是不可能的，风险可能在项目的任何阶段爆发，所以项目日会很重要！
三、项目日会
项目日会很重要，但多数项目组做的一塌糊涂！
所谓项目日会，也是执行日志（用以追溯整个项目）重要的内容来源，很多同学常见的问题是：
日会时候各自说下你做了什么，我做了什么，然后自以为是的拼出了一个虚假的项目完成度，这是大错特错的！
项目日会的真正意义是用来暴露风险的！或者说项目日会是用来帮助你梳理项目风险点的，这里真实的流程是：
① 开项目日会，对照项目日历（时间表）看看今天应该达到什么进度
② 哪些模块晚于这个进度，找出为什么
③ 清理出需要帮助队友的清单，并且当天协调资源帮助解决
④ 如果日会暴露出项目风险不能解决，必须马上升级求助
所以项目日会的本质是：
1）暴露风险点，形成清单；
2）同步风险解决进度；
正常情况日会10分钟就要结束，不要陷入细节。关键点是确定谁在什么时间点达到什么目标
反映当前真实的项目状态，知道症结点（风险点）在哪，协调资源解决风险点。
启动模板与项目日会，都是在做信息同步和风险暴露的工作，项目负责人大半时间都在处理这些风险。
启动模板和日会是为了拿到项目风险清单；
项目负责人多数时间是协调资源解决清单中的问题；
如果项目负责人发现，风险无法独立解决，便需要马上上报！
项目复盘
在项目执行中有个非常重要的环节就是复盘：
他可以是项目过程中发生的一些事故，我们针对这个事故做Case Study； 他也可以是在项目执行结束后，统一的对项目执行过程中做得好与不好的点做复盘、探讨；
CaseStudy：针对平时工作中爆发的各种问题，需要责任人写CS（CaseStudy）文档，每周固定时间，相关人一起做复盘的机制，旨在杜绝类似问题产生。
前几节我们重点探讨过如何做复盘，实操方面这里不多说，这里重点回顾下之前的机制后置性问题。
问题过载
在一些团队里面，由于历史债比较重，可能会频繁的做CaseStudy，甚至重复的问题重复做。
这类事件多了，也容易引起大家的疑惑：每次复盘都没有真实解决问题，这种复盘又有什么意义呢？
一线同学看到在一个复盘、CS中的一个具体的问题没有解决，这是因为要改变一个事件的结构/规则的成本很高，或者一些其他原因：
当前的问题并没有很严重、很紧急，需要马上处理； 团队可能也没有资源能够马上投入修改； 就算团队进行了修改，规则的变化可能会有一定后置性；
但如前所述，复盘的意义更多的是为了信息输入，为之后机制建设做准备；另一方面其实在做复盘文化建设，呼唤更多人的主动与自律，是人治框架的结果。
项目管理的主体框架就上述那些内容，接下来讨论一下在项目执行过程中经常会遇到的一些case，其实case处理对应的是经理的应变能力模型。
案例：项目逆风了
项目逆风是经常发生的事情，作为项目负责人，心态要平和。
越是逆风的情况下，关键的风险预估越是必不可少，因为所有的必要步骤都是对你项目失败的兜底方案，只要你放弃这些兜底，那无异于在裸奔，失败的风险大大提高。
一个真实案例是一次重要项目，由于项目资源紧张，核心开发技术方案迟迟不能给出，甚至想放弃写技术方案，直接上手代码，这里可能的风险是：
① 项目压力大的时候容易做错误的决定
② 没有技术方案，就是没有计划，没有计划的事情失败的概率会高很多
③ 在极大的压力下，失败的第一步会导致持续的失败从而引发雪崩
当时的处理方式是，项目负责人加班加点进行兜底，等他缓过劲来。
很多边界问题、困难的点，需要项目负责人协调资源帮助补齐，否则被放弃的部分很容易成为败因。
在这个案例里面项目负责人的补位非常关键，而项目负责人补位的前提是：
① 提前梳理项目风险点，知道哪里容易成为突破口
② 项目负责人深入业务，而不是瞎指挥
案例：团队内讧了
项目逆风不重要，队友心态很重要，一旦队友心态崩了，那么马上就会引起吵架，整个团队散了，失败也就不远了：
小王第一次做项目负责人，十分想做好这个事情，但是他影响力不足，所以团队的小伙伴有些我行我素，弱小的小王尽力的推进着整体项目，但在执行过程中依旧出了很多问题，于是他跟组员在群里吵起来了，双方经理看不下去，也加入了争吵的队列，这里的两个点是：
① 小王认为对应同学对项目不上心；
② 一线同学觉得小王不懂瞎指挥；
双方经理各执一词，执行情况十分糟糕，最后项目也出了一些事故，大家都收到了惨痛的教训，回顾这个事情，出现了几个关键问题：
① 执行不当，没有提前找到项目风险点，或者说之前的兜底方案不足，也没人补位，项目进入逆风。
② 逆风时候，整个项目成员开始甩锅吵架。
③ 小王没有稳住团队心态争取最后的胜利，而是开始抱怨委屈加入战斗。
④ 双方队员教练（经理），没有去协助稳住局面，而是加入了甩锅、吵架环节。
有了以上表现后，项目多半是砸了，这类问题的解决方案是：
① 项目负责人决不能参与吵架，更不能甩锅！
② 在团队逆风或者出现矛盾时，更多的去发现项目风险点，解决项目风险点
③ 当项目负责人感觉控制不了局面时要及时上抛问题求助
类似的案例有很多，大家可以去网上找找。
作为一线管理者，除了考虑项目成功执行，还要考虑项目用更少的成本执行，这又不得不提到冗余识别了。
识别冗余
项目负责人作为常见的一线管理者，需要具备成本意识，所以管事这里依旧需要做冗余识别，这里的点在于：识别项目中无意义的事项。
只要能识别团队中无意义的事，便能将用于这部分事的资源，投入到更有意义的地方，举个例子：
案例：项目中的人为制造冗余
某中型互联网公司在开发新移动应用时，项目团队逐渐陷入低效合作和进度拖延，具体问题如下：
重复的报告与会议
团队中部分成员为证明自身价值，频繁要求其他成员提供冗长、详尽的报告，并组织过多、不聚焦的会议，严重浪费时间。未经验证的功能需求
一些设计师和市场人员提出大量未经充分论证的功能需求，频繁干扰开发流程，导致资源浪费和团队疲惫。过度文档编写
对每个小改动都要求详细文档记录，大幅增加开发与测试团队的工作量，但这些文档实际使用价值很低。
类似这种问题，能识别就能优化：
简化报告与会议
制定统一的报告模板，减少报告频率；优化会议机制，将例会时间压缩到30分钟以内，确保聚焦关键问题。需求评审机制
引入需求评审委员会，所有新增需求需通过严格审核，优先落实经过市场验证的功能，避免频繁变更。优化文档管理
聚焦关键功能和重大改动，简化文档编写；通过自动化工具生成基础文档，减少人工重复劳动。
最终优化效果如下：
提高时间利用率
团队在报告和会议上的时间减少60%，成员能专注于开发和测试。 文档编写时间减少70%，提升整体效率。
需求变更次数减少50%，开发团队更专注于核心功能，实现进度大幅提速。 更严格的需求管理使项目更加稳定、灵活。
团队成员摆脱冗余工作压力，集中精力于创造性任务，满意度和凝聚力显著增强。
优化冗余并非小事，简化流程、聚焦资源不仅能节省成本，还能解放员工。
结语
项目执行的主体多是以一线经理领导一线员工进行开展，公司执行力的核心会落到一线管理者身上。
公司所有的不合理，包括项目优先级混乱、资源配置浪费、流程不合理、员工负能量、资源分配不合理等问题全部会在一线经理做项目过程中集中爆发。
所以在公司视角下，对经理最大的期待就是做好项目、做好项目过程的风险处理、做好员工的组织与安抚，这也是其英雄价值最直观的体现。
在多数公司，一线管理的优劣，直接影响人效，经理是组织能力建设的核心。