项目带崩了怎么办？

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料： 

• 《项目实战（视频）》：从书中学，往事上“练”
• 《互联网高频面试题》：面朝简历学习，春暖花开
• 《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
• 《精进 Java 学习指南》：系统学习，互联网主流技术栈
• 《必读 Java 源码专栏》：知其然，知其所以然

来源：叶小钗

• 项目逆风了
• 项目执行方法论
• 项目执行三板斧
• 项目启动模板
• 确认风险
• 项目日会
• 风险处理|资源协调
• 案例·逆风怎么办
• 任何形式的放弃
• 任何形式的内讧（甩锅）
• 结语·意识与操作

项目逆风了

之前在综艺节目《开拍吧》彭宥纶给我留下了深刻的印象：

彭宥纶负责一个电影项目的产出，但她最终却失败了，没有产出作品。

她在项目过程中所表现出来的能力，很难负责复杂的项目，但比较令人惊奇的是：弹幕中有很多人在抱怨工作人员碌碌无为 ，一般群众看待问题的角度太片面，这不客观。

无论如何工作人员都是吃这碗饭的人，绝对不会出现完全带不动 的场景，如果项目被带崩，多半是项目负责人本身出了问题，我们看到彭宥纶在第三天的时候心态就开始崩了 ，这是项目负责人的大忌

换句话说，我们日常做项目会遇到很多Case，也会碰到队友带不动的情况，那么这个时候怎么办：

Case1：面对陌生的环境下，时间紧，人不足，风险点评估不全，这种怎么带，如何把控？

Case2：在高压时，作为负责人忍不住跟组员吵架了 ，这时如何处理团队的负面情绪、如何协调好团队分工？

Case3：如果一个项目有新人该怎么处理，Owner本身节奏有问题该怎么处理？Owner的时间分配有问题怎么办？

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

项目执行方法论

上述其实都可以被归类为项目问题，作为互联网工作者，执行项目相当于打怪升级，必不可少，但多数人却不能带好项目，却不知这其实是有实现路径的...

如何追到一个女孩、如何进入一家公司、如何面试一个人、如何成为一个幽默的人、如何评价一个人、如何成为老马那样的人？

类似这种问题其实都是有迹可循的，不是说我们一定能成为像老马一样的人（其实就是不能），但是总有路径能让我们接近老马，比如成为老马的儿子。

所谓路径即“方法论”，掌握合适的方法论，能让你更容易追到这个女孩，如果追不到可能只是因为你穷。

言归正传，今天的目的不是教大家如何去追女孩子，毕竟那是一件非常简单的事情，今天的目的是将之前带项目的一些经验分享给大家，并且希望这些知识对可以让大家后面少走一些弯路。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

项目执行三板斧

所谓项目，即为创造独特的产品、服务或成果，而进行的“临时性”工作。

所谓项目管理，即通过运用管理的知识、工具、技能和技术于项目上，来解决项目的问题或达到项目的目标。

根据这几年的经验，项目管理事实上是一门实践的学问 ，正因为是实践而得来的，面对同样的场景，不同的人处理的方式会不尽相 ，但是其基础的思维框架 是大同小异 的，只有通过不停的实践，才能真正掌握项目管理的精髓，成为好的项目实践者。

作为一个全局负责人的话需要特别有节奏感

这个节奏感，如王者荣耀打野一般，需要掌握大龙小龙刷新的时间点、需要在合适的时间点去推塔，也就是：

1）在正确的时间 做正确的事情；

2）暴露 正确的信息，不要乱带节奏 ，导致项目失利；

这个就是所谓的节奏，再说直白一点就是：

对一件事的时间点（事件点）的敏感，而后对信息的正确处理

着眼于产研的项目，作为一个Owner（负责人）需要知道自己的几个发力点：

① 产品运营驱动

② 技术Owner驱动

③ 测试驱动

④ 商务运营驱动

⑤ Owner复盘

从项目执行角度来说，Owner的发力主要点是前两个阶段，也是信息对齐 、需求梳理 的重要阶段。

镜头再拉进到技术Owner，如果过早介入，需求产出受挫容易白费力；

晚一步介入，需求不清，会导致研发、测试走弯路而项目延期甚至流产；

在合适的时间点将推动项目运行的主导权 交给对应的队友，才更容易成功。当然从头至尾的信息传递 都是Owner需要做好的。

综上，项目做好其实不难，只需要：

1）掌握节奏，让合适的人做合适的事；

2）信息传递；

3）协调资源；

从执行角度看，一个项目的完整周期是这样的：

我们根据以上内容可以形成项目执行三板斧，说白了就是准备清单 与清单解决

项目启动模板

项目是十分复杂的事情，因为他会涉及非常多的人，一件事情涉及的人越多，那么会更难：

除了事情本身专业度所带来的困难，一般来说最大难度来源于两方面：

① 沟通过程中产生的信息不同步；

② 做一件特定的事情（一类事情），总是会出错；

所以我们需要一套【机制】来保证多数信息的一致性，以便我们要追溯某一段信息的时候无从下手；

其次我们需要一类清单 ，这种清单记录了我们之前做某一类事情犯过的错，清除所有的错误可能，那么我们就会更容易达到成功，所以这里给出了项目启动模板：

标红的部分是必须提供的，使用项目模板，会保证项目执行的下限。其中项目日历大概如此：

项目日历一出，整个项目的时间线就确定了。

确认风险

项目旁枝错节过多，Owner想要把握每一个细节无异于痴人说梦，这里便要求相信队友。

但是相信不是不作为，在我看来Owner80%的精力应该放到风险管理

确认风险点，规避风险点，设计风险已发生的解决方案，是一个项目的重中之重！！！

那么，如何规避风险呢？首先得找到风险点，于是需要定义什么是风险点。我们做一个项目，需要穷举（尽你之能）什么是绝对不能接受的情况，这个可以是：

① 项目延期XX天（会不会延期、信息不同步等等因素）

② APP崩溃

③ 订单不能支付

④ 某页面打不开

⑤ 充值有漏洞

⑥ 结算延迟超过底线

⑦ ......

不同项目会有不同的风险点，首先穷举这些风险点，然后再看看我们要处理哪些风险点，这里的规则是：

这个事情会不会发生，如果发生你能不能承担。

一旦确定要处理的风险点后，那么Owner的工作便已经确定下来了：解决掉所有的风险点，其他全部交给队友。

这里担心各位疑惑，再啰嗦几句：

① 项目初期，根据过往经验（有些项目是周而复始的、有些项目是同一类型的），判断可能会有什么问题（Owner越高阶，此能力越强）

② 需求评审阶段，让关键 同学提出风险点，最终确认项目日历

③ 评审后整理所有风险点，并且了解细节，再拉风险评估会，与队友确认风险点，并要求队友提供对应方案

④ 如果风险点技术侧不能绕过，马上拉运营、产品商量规避方案

⑤ 如果不能完全规避，与对应同学设计如果已经出问题的项目补救方案，和触发机制

虽然我们期望能前置所有的风险点，但这往往是不可能的，风险可能在项目的任何阶段爆发，所以项目日会很重要！

项目日会

项目日会很重要，但多数项目组做的一塌糊涂！

所谓项目日会，也是执行日志（用以追溯整个项目）重要的内容来源，很多同学常见的问题是：

日会时候各自说下你做了什么，我做了什么，然后自以为是的拼出了一个虚假的 项目完成度，这是大错特错的！

项目日会的真正意义是用来暴露风险 的！或者说项目日会是用来帮助你梳理项目风险点的，这里真实的流程是：

① 开项目日会，对照项目日历（时间表）看看今天应该达到什么进度

② 哪些模块晚于这个进度，找出为什么

③ 清理出需要帮助队友的清单 ，并且当天协调资源 帮助解决

④ 如果日会暴露出项目风险不能解决，必须马上升级 求助

所以项目日会的本质是：

1）暴露风险点，形成清单；

2）同步风险解决进度；

正常情况日会10分钟就要结束，不要陷入细节。关键点是确定谁在什么时间点达到什么目标

反映当前真实的项目状态，知道症结点（风险点）在哪，协调资源解决风险点。

风险处理|资源协调

启动模板与项目日会，都是在做信息同步和风险暴露的工作，Owner大半时间都在处理这些风险。

大白话：

启动模板和日会是为了拿到项目风险清单；

Owner多数时间是协调资源解决清单中的问题；

比如案例一中的西安事件其实是需要on-call机制解决紧急事件，很多时候都会需要Owner Case By Case的处理特定问题，要有合适的权责利模型，不然就会变成甩锅现场。

案例二中的很多问题，需要一一分解。

案例·逆风怎么办

先不说逆风怎么办，我们先来盘点下什么行为会导致失败：

任何形式的放弃

一旦放弃绝对失败 ，比如放弃风险预估。

越是逆风的情况下，关键的风险预估越是必不可少，因为所有的必要步骤都是对你项目失败的兜底方案 ，只要你放弃这些兜底，那无异于在裸奔 ，失败的风险大大提高。

一个真实案例是一次重要项目，由于项目资源紧张，核心开发技术方案迟迟不能给出，甚至想放弃写技术方案，直接上手代码，这里可能的风险是：

① 项目压力大的时候容易做错误的决定

② 没有技术方案，就是没有计划，没有计划的事情失败的概率会高很多

③ 在极大的压力下，失败的第一步会导致持续的失败从而引发雪崩

当时的处理方式是，Leader加班进行兜底，等他缓过劲来。

所以很多边界问题、困难的点，需要Owner协调资源帮助补齐，不至于让这条线成为败因。

在这个案例里面Owner的补位非常关键，而Owner补位的前提是：

① 提前梳理项目风险点，知道哪里容易成为突破口

② Owner深入业务，而不是瞎指挥

任何形式的内讧（甩锅）

项目逆风不重要，队友心态很重要，一旦队友心态崩了，那么马上就会引起吵架，整个团队散了，失败也就不远了：

小王第一次做Owner，十分想做好这个事情，但是他势能不足，所以团队的小伙伴有些我行我素，弱小的小王尽力的推进着整体项目，但在执行过程中依旧出了很多问题，于是他跟组员在群里吵起来了，双方经理看不下去，也加入了争吵的队列，这里的两个点是：

① Owner认为对应同学对项目不上心

② 一线同学觉得Owner不懂瞎指挥

双方经理各执一词，执行情况十分糟糕，最后项目也出了一些事故，大家都收到了惨痛的教训，回顾这个事情，出现了几个关键问题：

① 执行不当，没有提前找到项目风险点，或者说之前的兜底方案不足，也没人补位，项目进入逆风。

② 逆风时候，整个项目成员开始甩锅吵架。

③ Owner没有稳住团队心态争取最后的胜利，而是开始抱怨委屈 加入战斗。

④ 双方队员教练（经理），没有去协助稳住局面，而是加入了甩锅、吵架环节。

有了以上表现后，项目多半是砸了，这类问题的解决方案是：

① Owner决不能参与吵架，更不能甩锅！

② 在团队逆风或者出现矛盾时，更多的去发现项目风险点，解决项目风险点

③ 当Owner感觉控制不了局面时要及时上抛问题求助

结语·意识与操作

以王者荣耀一局游戏作为项目，那么选手的两个能力最重要：

① 意识能力

如何感知风险是常见的意识能力的体现

② 操作能力

如何做风险处理就是操作能力的体现

这样说有点虚，做一个类比，意识能力的四个层次是：

① 你知道草丛里面有人，所以你不进去

② 你知道草丛里面有人，并且有什么人，所以你不进去

③ 你知道草丛里面有什么人，并且你告诉了你队友

④ 你知道草丛里面有人，并且告诉了队友，并且制定了合适的战略取得了成功

而操作能力的层次是：

① 队友告诉草里有人，但我脑袋一热非要冲过去，并且死了

② 队友告诉草里有2个人，我评估了自己的操作水平，冲了上去并且死了

③ 队友告诉草里有3个人，我评估了自己的操作水平，对面的经济情况，依旧冲了上去，并且拿了三杀！

意识好便不需要以少打多，很难进入逆风；操作好就算进入逆风也能Carry全场。

但是任何形式的死扛都是有风险的，没人能一打五，所以意识大于操作

而顶级的项目Owner对意识、操作都有要求！

回答很简单，问题却很复杂，相当于一个白银问王者，你为什么知道草丛里面有人或者你为什么能一打三？

回到项目，为什么有些Owner能够很快发现项目的风险点；又为什么有些Owner能轻松化解项目中的风险点，这里有两个答案：

① 第一个很简单，多带项目，多看复盘

② 第二个很复杂，需要天赋，提升软素质

正如一般同学上王者很容易，但上王者百星很难，没有什么事情能一蹴而就。

可以做的就是提供更多已经实践的方法论，留给有心的同学去学习，比如这篇文章。

其实整篇文章都在教大家如何不要把项目带崩，这里的主旨依旧只有一个：

提高意识，提高操作，更落地一点的回答是提前找到你项目中的风险点，并且干掉他。