⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 叶小钗 「叶小钗」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

项目逆风了

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

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

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

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

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

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

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

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

项目执行方法论

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

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

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

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

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

项目执行三板斧

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

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

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

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

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

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能轻松化解项目中的风险点,这里有两个答案:

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

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

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

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

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

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

文章目录
  1. 1. 项目逆风了
  2. 2. 项目执行方法论
  3. 3. 项目执行三板斧
    1. 3.1. 项目启动模板
    2. 3.2. 确认风险
    3. 3.3. 项目日会
    4. 3.4. 风险处理|资源协调
  4. 4. 案例·逆风怎么办
    1. 4.1. 任何形式的放弃
    2. 4.2. 任何形式的内讧(甩锅)
  5. 5. 结语·意识与操作