文章目录

制定目标
分解目标(任务)
- 任务拆分
- 任务分配
- - 人岗匹配
  - “事”和“人”的分层
对齐目标
- 向目标看齐
- 多走一步
- 文化与价值观

距离项目管理第一招的文章已经过去了个把月了，一直也没想好这第二招应该写点啥。前阵子接触到OKR，突然灵光一现，项目中最重要的也是要全项目团队对其目标；但是团队中每个层次负责的内容是不一样的，这就涉及到对项目目标的分解。项目经理的工作就是需要让每个小团队对其大目标，完成好自己的小目标。

所以，我决定将第二招命名为：对齐目标，大事化小。

在这个系列的第一篇：
IT项目管理就那么几招：开场

中，提到了几个关键问题

需求打架，一堆人都出来说自己手里的需求和问题是最关键和最紧急的。除了各种KPI的影响，其实很多情况下都是因为每个人都站在自己的角度和目标上去考虑问题，而不是在整体的目标上去考虑，才会对需求和问题的优先级判断出现偏差。
需求变更，项目没事老在改需求。同样的，这是项目组和客户，或者说产品和研发团队没有对齐目标导致。
需求变形。这是因为每个小组或者上下游的每个人没有对齐目标。

可以看到，这些问题都和没有对齐目标有关，每个团队，甚至每个人都站在自己的角度思考问题，思考问题的角度都是瞄准的不同的目标，才会出现上述的各种问题。所以，整个团队对齐目标是整个项目成功的重中之重，这篇文章也主要是围绕着目标来说。

对齐目标的过程可以拆分成三个阶段：

制定目标，先有一个靠谱的目标。
分解目标，大事化小，将目标分解成更多靠谱的小目标。
对齐目标，保持大目标和小目标一致。

制定目标

一般来说，除了你是自己干革命，不然一般的项目目标都是由上级交代的，对目标的内容一般来说没有太大的选择余地。作为项目经理，对于目标，我们只需要使用SMART原则去评估：

S，Specific。表示项目目标要具体而明确。比如制定一个项目目标：“完成一个具有竞争力的电商平台”。那么这个就不明确，啥叫有竞争力？每个人都会有不同的理解，是GMV达到多少？点击率超过多少？还是用户规模达到多少？这个目标就是模棱两可的，无法指导后续项目的开展。
M，Measurable。表示项目目标要可度量。这个很好理解，基本逻辑就是进行数字化评估。基本上是配合上面的S一起使用，来制定一个具体的，可度量的项目目标。
A，Attainable。表示是可实现的，不要随便吹牛逼。这个地方我觉得是需要对程序员出身的项目经理好好说一下，有时候老板或者上级交代的目标是不靠谱的，大部分都是会比较激进和不太现实的。这个时候项目经理们一般会出现下面两种情况：
- 老板都说了，搞不定也要搞定，不管三七二十一先应下来，结果后面各种问题和救火。实际上，你要理解，老板或者上级他往往不清楚目标实现的难度和细节，评估目标实现的难度和细节是作为专业人士的项目经理来判断的。作为专业人士的团队如果不做好准确的判断，很容易让整个团队陷入大跃进的氛围当中。当然，在项目初期的时候会有种打了鸡血的冲劲，但是客观的事实摆在那里，如果多次无法正常的完成目标，这种挫败感对团队的损害也是巨大的。所以，理性的应对这种激进的目标是非常有必要的。
- 过分保守，这个功能代码实现起来会不会有问题。那个人员不足，这个模块没人开发等等。程序员出身的项目经理往往会陷入对这种技术细节的担忧，从而对目标过于的保守估计。这种情况下，项目经理应该站在更高的角度去评估，而不是已自身的技术实操水平去评估，项目经理的重要工作是针对目标去匹配资源，而不是根据现有资源去匹配目标。这实际上是对项目经理的技术水平提出了更高的要求。
R，Relevant。就是目标的相关工作必须是和目标紧密相关的。
T，Time-bound。所有的目标都是有时限性的，不是无限久的。

所以，不管什么样的项目目标，在项目经理这，必须符合SMART原则。

分解目标(任务)

制定完目标之后，项目经理面临的首要事情就是如何拆分目标，或者说如何拆分任务。

分解目标是一个比较讲究的事情，我想把这个事情分成两个部分：

任务的拆分，主要针对事，说的是怎么把一个大的任务分解成小的任务。
任务的分配，主要针对人，说的是怎么合适的去分配任务到每个人。

任务拆分

首先，任务拆分这个事情在项目管理领域有个黑话：WBS(Work Breakdown Structure，工作分解结构)。

分解方式：基本上是从上至下，按照树形结构展开，至于按照什么维度来分，这个和业务强相关：可以按照团队职能来分；也可以按照交付件来分；也可以按照项目的过程顺序来分。
分解原则：
1. WBS的叶子节点必须是到个人，不要是一个团队或者是两个人。否则就可以再将这个任务拆解，如果不进行拆分，这个任务就会出现责任不清，你等我做，我等你做的情况就会出现。
2. 要分解到每个人的日常工作当中去，从时间维度上来说，我喜欢控制在一个人一周左右的工作量作为WBS结构的叶子结点。
3. 所有的下层节点是可以支撑上一节点完成的，不要有遗漏。
实际上这个就是梳理出整个项目的工作范围。而工作范围是项目的计划和执行阶段的关键所在。

其次，通过WBS将所有的任务分解出来之后，还可以做的一件事情就是梳理这些任务的先后顺序和依赖关系。把这些时间按照顺序排列好之后就可以形成第二个输出件：前导图。前导图中的任务有如下几种关系：

结束-开始。也就是前面的任务结束后就可以开始了。
开始-开始。前面的任务必须开始后，后面的任务才可以开始。
开始-结束。前面的任务必须开始后，后面的才开始结束。
结束-结束。前面的任务结束后，后面的才可以结束。

前导图出来之后，我们可以得到项目计划中的一个关键信息：关键路径。

任务分配

上面一小节是将怎么把大目标分小，这个实际上对程序员出身的项目经理们来说不是什么难事，毕竟做需求的时候拆分模块和函数和这个过程也差不了多少。但是接下来的一部分才是对程序员出身的项目经理的挑战，也就是怎么把这些分解好的事情分配到团队中的每个人身上。

关于如何分配到人有很多技巧，但是我个人觉得主要遵循两个原则，至于技巧，其实是需要跟进具体情况和具体人员来确定的。

原则一：岗得其人，人适其岗。
原则二：事事有人做，人人有事做。

人岗匹配

咱们先来看看怎么去按照原则一做事。做事风格因人而异，我这里写的都是个人意见，各位看客觉得有用就点赞，觉得不对或没用也请不用纠正。

首先来看看“岗”这个事情。我将“岗”分成三个部分去定义：

岗位职责。这个是最容易想到的，IT项目中基本上也就是那几个岗位：产品，架构，开发，测试，运营等等。这个在业界都是成熟的定位，各个项目因自己项目的情况做一些小改动即可。
岗位在工作流程中的位置。项目经理必须定义项目的工作流程。比如产品与开发如何协同，需求的传递需要有哪些动作来保证正确。开发和测试的配合，版本转测试的流程与方式。项目沟通例会等等，项目经理必须清楚每个岗位在整个工作流中的位置。并将这个位置的能力抽象出来。
岗位的输入和输出。清楚了岗位在工作流中的位置之后，接下来就是需要明确每个岗位针对上下游节点的输入和输出。其实也就是界定权责，做好工作节点的顺利流转。

有了岗位的定义之后，项目经理就可以根据这个岗位职责和能力需求去申请资源和组建团队。

“事”和“人”的分层

在IT项目里，上面的人岗匹配相对来说还好做一点，毕竟每个岗位的能力需求在业界都是有这相对固定的标准。而在项目推进的过程中，不停地调整任务的分配情况，从而达到“事事有人做，人人有事做” 还是比较困难的。个人有下面几条经验：

做好WBS，让每项任务都是原子的，都有明确的责任人和时间段，这样可以保证事事有人做。
打破“能者多劳”的怪圈。有这么个现象大家可能都碰到过，一个项目里总有那么一两个人是全面手，他懂得所有的业务，熟悉项目中的每项技术，所有的任务只要交到他手里就肯定可以搞定。每个项目经理都喜欢这样的人，美名其曰“能者多劳”，但是这样的结构对与项目成果的达成和项目团队的氛围是不利的。
- 所有的任务都会压到这个人手里，他逐步会变成整个项目的瓶颈所在。
- 人是会疲劳的，再有冲劲的人，也会有懈怠的时候，这样会造成多做多错的情况。
- 团队其他成员没有成就感，所有的任务都会甩锅一样甩到这个人身上。这个关键人物因为被团队所有人关注，造成心理压力巨大，一旦出问题，其他成员很有可能会是“事不关己高高挂起”的状态。这样的团队氛围对项目是致命的打击。
我个人解决这个问题的方式如下：
- 对事情做好拆分，做人员做好A/B角备份。一个项目中的事项一般可以分成4个象限：
  - 重要且紧急
  - 重要不紧急
  - 紧急不重要
  - 不紧急也不重要
  将其中的一些重要但不紧急的事项分配给关键人物的B角，给相对充分的时间让他们将这些人物承担起来，从而慢慢将关键事项均衡的分配到若干人的手上。
- 做好知识沉淀和传递。每个项目都会存在新人的进入和老员工的离开，所有的项目知识必须有足够的归档和沉淀体系，让新员工或者能力有欠缺的成员可以通过知识体系来学习，而不是完全通过老员工手把手的口口相传来做知识的传递，这样的话效率极低。
- 给出容错的空间，项目经理一定要给自己做好心理建设。团队中每个成员都需要有出错的空间，也就是给出他们成长的空间。不然老是想着只给自己放心的那个关键人物去做的话，就会掉入“能者多劳”的这个怪圈了。

通过上面几个手段，将事和人都进行分层，并进行人和事的匹配，来达到“事事有人做，人人有事做”的目的。

对齐目标

上面的两个章节指导我们制定好了目标，也拆分好了目标。但是对于一个团队来说，最重要的事让所有的成员对齐目标，需要让所有的成员“向上看”，也就是说要了解项目的整体目标是什么，项目成员自己的子目标可以为项目的整体目标实现什么样的价值。

向目标看齐

回到开场那篇文章里提到的两个问题：需求打架 & 需求变更 & 需求变形，我们通过这两个问题来说下目标的重要性。

需求打架。造成这个问题的本质原因我认为在于是每个人都站在自己的角度去考虑问题，或者说每个人都是在考虑自己的小目标的角度去考虑。不同模板的产品经理或者项目经理都是关心自己的需求是否能上线，是因为这个需求的上线影响了他们在项目中的子目标。但是如果我们能跳出这个子目标，每个人都回到项目的大目标上去思考，情况就会大不一样。比如，当前项目的目标是要提高界面的流畅度和用户视觉体验，从而引流更多用户来体验。那么当前的数据库扩展或者日志监控等需求就可以往后排。如果当前是需要系统的稳定性，那么用户的一些视觉体验需求就可以往后排。所以说，项目的总体目标对于需求排期是有非常大的指导意义的。
需求变更 & 需求变形。项目的每个环节实际上都是对需求变更这个问题比较困扰。实际上我个人认为也是因为目标没有对齐而造成的，每个环节在制定需求的时候没有对目标有足够的认识，因此制定出来的需求没有达到目标才会发现的变更。

还有就是发生需求变更时，将这个需求的why，也就是为什么要做这个需求，这个需求解决了什么问题，做好这个需求是不是让项目里目标更近了。必须将这个信息准确无误的传达到技术支撑团队，这样才能让技术支撑团队更好的理解需求，从而为保证需求不变形打好基础（还有别的手段来保证需求不变形）。

这就要求项目经理经常性地将项目目标向不同的团队去对齐和引导，包括项目的所有干系人：客户，上层领导，不同的技术支持团队。

多走一步

目标除了要向上看的同时，还需要“向左看，向右看”。也就是说链条的上下游团队需要互相清楚对方的目标，并且互相为对方的目标提供支撑。更通俗的说就是“多走一步”，每个人多走一步就会让整个项目的链条更加顺滑的运转。

比如开场里提到“他怎么不知道”的这个问题，除了程序不同的模块的团队会发生这种问题之外。还有更多的场景：

开发代码提交了，测试不知道代码已经提交可以测试了。
测试测完了，现场不知道这个版本可以发布了。
运维已经把版本升级了，客户或者客服不知道新功能已经上线了，没法通知客户。

然后出了问题一层一层追溯下去的话，项目经理会发现每个团队都完成好了自己的目标，但是团队的目标就是没有完成。

项目经理解决这个问题的办法还是让各个团队对齐目标，知道自己上下游的目标时什么，并鼓励和制定一定的措施去让上下游团队“多走一步”，让WBS的层次之间也有一条线连接起来：

每个人都做走一步，才能让整个流程顺利的运行起来。

文化与价值观

这个标题起的很大，但是确实是最有用的部分。其实我觉得团队文化通俗一点讲就是“一群人做事的风格，碰到问题的选择风格”。在上下左右都对齐目标之后，怎么保证大家都会以背靠背的态度去做好项目呢。

作为职场，当然需要有制度，但我理解制度是对大家行为的最低要求，是实在不行了才用制度。
而文化则是对大家行为的最高要求，我理解就和社会中的法律和道德类似。这个需要项目组每位成员的认同，并由每位成员认知去执行，经过日积月累才能成型的一种最高品质。

作为一个曾经的华为人，我最喜欢也是最推崇的团队文化就是两句话：胜则举杯相庆，败则拼死相救

项目管理第二招：对齐目标，大事化小相关推荐

float布局设置同一行行高一样_布局思想：大事化小、先行后列、见缝插针
display属性 block: 块级元素 inline: 行级(内联)元素 inline-block: 行内块元素,既在同一行内呈现,也能设置width,height none: 隐藏元素 floa ...
【大事化小，小事化无】的意思和解释
[大事化小,小事化无] 是什么意思(来源:辞典修订版) 缩小或消除冲突.<文明小史．第一回>:「他见我们地方官以礼相待,就是有点需索便也不好十分需索,能够大事化小,小事化无.」也作「大事化 ...
全民一起VBA实战篇专题4 第五回递归算法流程独特大事化小思路清奇
相关知识点: 区别于循环在于,把大问题转换成小问题,总结递进的推导公式:知道最小问题的答案(递归的停止条件). 例1 阶乘(循环语句) Sub demo() Msgbox 阶乘(4) End Sub ...
针对遥感目标检测（小目标、旋转框、密集目标）的论文整理
文献整理文章目录文献整理 A Multi-Feature Fusion-Based Change Detection Method for Remote Sensing Images 内容摘要 A ...
2021年春季学期-信号与系统-第二次作业参考答案-第九小题
本文是 2021年春季学期-信号与系统-第二次作业参考答案的参考答案. ▌第九题 9. 已知三个系统的输入输出关系分别为: 把上述三个子系统进行如下的级联,求系统的输入输出关系,它是线性.时不变系统 ...
目标检测之小目标检测和遮挡问题
小目标检测trick 小目标难检测原因小目标在原图中尺寸比较小,通用目标检测模型中,一般的基础骨干神经网络(VGG系列和Resnet系列)都有几次下采样处理: 导致小目标在特征图的尺寸基本上只有个位 ...
小嘿嘿之目标检测关键小技术focal loss/DCN/ROI Align/FPN
目标检测小技术 Focal loss 1.概念 2.损失函数形式 Deformable Convlolutional Networks 1.背景问题 2.原理与结构 3.Deformable RoI ...
葵花宝典第二招：突破单峰密集
不知道大家在炒股初期是不是有这样的错觉:买了就跌,卖了就涨.注意注意,对我来说不是错觉不是错觉.但是经过多年修炼,终于让我练成了葵花宝典,总结出选股技巧11招,摆脱了被割韭菜的命运.下面第二招,分享给 ...
ORA-64203: 目标缓冲区太小, 无法容纳字符集转换之后的 CLOB 数据
线上遇到bug,日志显示错误ORA-64203: Destination buffer too small to hold CLOB data after character set conversi ...

项目管理第二招：对齐目标，大事化小