项目管理的简单总结

项目管理

项目管理的四个重要的方面：

• 范围：需要做什么事
• 时间：什么时间做完这些事
• 成本：花多少钱做成这些事
• 质量：这些事做到什么程度客户才满意

围绕着项目管理展开的其他问题，如沟通、资源、风险等也是为这四个目标服务的，最终让这四个目标取得最佳的平衡。

什么是主 R

最早接触主 R 这个概念，是我在美团工作的时候，当初也不清楚这个到底是个什么概念（甚至以为 R 是 RD 的简写）。在后来的工作中，慢慢了解到主 R 来源于 RACI 模型，是有理论基础的。

RACI 模型是在项目管理或组织改造时常用的工具，主要是用来定义某一项活动中人员的角色和责任。通常，RACI 包含以下几项目：

• R: Responsible 负责
• A: Accountable 批准
• C: Consulted 咨询
• I: Informed 告知

在美团的实践中，有时还会看到 S 这个角色，这是因为在 RACI 的扩展版本 RASCI/RASIC 中将 Responsible 做了如下拆分：

• R: Responsible 负责
• S: Support 支持

项目管理要兼顾可行性和可操作性，才能保证效率和效果。RACI 相对来说比较简单有效，明确了参与者的角色和责任。在实践中，主 R 中的 R 就是 RACI 的 R，是负责执行任务的角色，是实际完成工作的任务者；主 R 就是主要（或第一）负责人，要同时兼具 A 的角色，要对任务负责。

主 R 的作用

主 R 最主要的作用是推动需求如期交付，在这个过程中需要做到：保障评审、开发、测试、上线、复盘等各个环节正常进行；沟通和协调产品、研发、设计、测试、运维等各个相关方有序推进。总而言之，遇事不决找主 R。个人认为主 R 解决了以下问题：

• 明确了责任。主 R 会对需求负责，避免出现铁路警察各管一段的现象
• 降低了风险。在日常推进过程中，能够及时发现风险，避免最后时刻暴雷

主 R 的基本素养

首先，要有责任心。项目管理不是走过场，而是要解决实际问题，因此责任心尤为重要。举个例子，当需求中的某个任务出现延期的时候，不是在日报、周报中 @ 一下相关的人就完事了，这只是在做表面文章；我们应该做的是了解导致延期的真正原因，并给出对应的解决方案。如果一个没有责任心的人去做主 R，很可能 @ 一下只是做给老板看的，至于问题能不能解决那不是重点。

其次，能够有效的沟通。主 R 除了和事情打交道之外，还要和各个角色进行沟通；如果沟通方面有问题的话，会影响到组织协调。这涉及到两个问题，一个是能够让自己理解别人的意图，另一个是能让别人理解自己的意图。看似简单，其实挺难的。

最后，正确的做事情。方法对了，事半功倍；方法错了，事倍功半。因此，需要有一些流程和规范做指导，这里不做展开讨论。

在《人月神话》这本书中，提到了 “外科手术队伍” 这个概念，在外科手术中，外科医生主导手术，其他人给予相应的支持。由一个人来完成任务的分解，其他人给予他所需要的支持，从某些角度上来说可以提高效率和生产力。我们所说的主 O 与 “外科医生” 这个角色比较类似。

在团队不断发展和整合的过程中，负责的业务越来越多，常常会面临人力短缺的问题。我们采用的办法是将业务分为几个业务方向，然后将开发人员分为两种：

• Owner 对各方面能力要求较高，负责某个项目或业务方向。Owner 要懂技术实现，对项目框架、代码了如指掌；Owner 要懂业务，知道业务的逻辑和方向；Owner 要懂相关方，了解后端、测试解决问题的方法。换句话说，要尽量做到对项目的全方位了解，要比所有人都懂。除此之外，还要强调 Owner 意识。主 Owner 要对其业务方向负责。
• Developer 要有开发能力，并不固定到某个业务。所有的 Developer 相当于在一个资源池中，高优支持优先级高的需求。并且需要进行培养，要慢慢成长为项目的 Owner。Developer 要对其开发的内容负责。

在人力的频繁调整过程中，主 O 的存在可以保障项目的正常推进，并且对开发效率有一定的保障。Owner 可以对其他人进行指导和帮助，可以让大家快速投入开发中。铁打的 Owner，流水的Developer。首先，这样避免人等需求的现象，在人力吃紧的情况下，一个萝卜一个坑的状态，会导致旱的旱死涝的涝死。其次，这在一定承担上过滤掉了不重要的需求，让团队聚焦于更重要的业务。

风险来源

在任何项目或需求的推进过程中，风险暴露的越早，付出的代价越低。简单总结一下风险的来源如下：

• 频繁的需求变更。频繁的需求变更不可避免会对研发的进度造成影响。但是如果对变更不做支持，最终做出的东西可能又不能交付，这就造成了一个进退两难困境，所以最终总会有人做出妥协。换句话说，如果变更需求，产品需要对此付出怎样的成本？当成本大于收益的时候，需求变更还会继续吗？所以一定要让需求变更有成本，当然时间也可以看作是成本。另外，研发需要在需求评审等环节，通过自身的专业技术给出一些建议，提前预见一些不合理的情况，避免之后需求变更。额外提一句，产品的能力一定要匹配研发的实力，否则是对研发资源的浪费。
• 无限制的加需求。在《人月神话》中对康恩定律做了一些拓展，“时间再多一件事情也不可能做得完美，但总有时间做完一件事情”。特别对于一些按版本迭代的项目，要控制好范围和边界，时间和资源是有限的，要做恰当的拒绝和必要的妥协。成年人要学会做取舍，不可能做到都要。阿里巴巴也只强调 “既要、也要、还要”，并没有 “都要”。
• 资源发生调整。投入的人力发生变化，要及时周知相关方，然后达成新的契约。这个不展开讨论。
• 技术或条件不能满足。很多研发不重视需求评审，觉得是在走过程，不认真去思考和研究需求，然后在开发过程中发现某些功能不能实现。需求评审笑嘻嘻，开发过程 MMP。在需求评审、技术评审的过程中，要把需求细节确认清楚，要把实现方案确认清楚，要把相关依赖方现状确认清楚。如果在开发过程中出现了技术问题，一定要及时暴露出来，或需求帮助、或协调资源解决。有的人就是喜欢死磕到底，结果不知不觉时间溜走了，最后造成进度无法补救。如果在开发过程中，发现功能无法实现，研发或多或少都要承担一部分责任。
• 依赖方造成风险。依赖方造成的风险，屡见不鲜。push 能力是一项很有用的能力，如果主 R 缺乏推进能力，即使风险暴露出来，也无能为力。也有极端的情况，是 push 也 push 不动，向上反馈也不一定有用。这样造成的结果就是，大家老死不相往来，能自建绝不依赖别人。但是奉劝大家，做人留一线，日后好相见。

项目中的风险随处可见，上面只是简单列举一下，不可能都列出来。比如在很久以前，我写点代码就赶紧 push 到远端仓库，因为总是担心在上下班途中电脑被人抢了。当然，北京的治安比较好，现在已经放松警惕了。通过上面的一些讨论，也不难看出，对于风险要 “提前预防” 和 “有效处理”。

风险控制

在大家做项目或需求时，经常会问大家一个问题：是 “乐观” 还是 “悲观”。有的同学一接到需求就很悲观，他觉得这不靠谱那不靠谱，一副总有刁民想陷害朕的样子，悲观之情溢于言表。与此相反，有的同学则大言不惭地盲目乐观。

作为团队负责人，有必要了解需求的状态，并做出相应的动作。对于 “悲观” 的状态，要做出强有力的支持和指导；对于乐观的状态要给出风险提示和建议。

对每个人的能力和特点，要有大致的预期。比如，如果你已经确认某个人能力不行，还要让他去做某件事证明他真的不行，这个做法是有问题的，这会导致之后投入更多的资源去填坑。也有一些情况，是提供一些成长的机会，这也需要我们投入一些关注，不能做甩手掌柜，避免出现问题。

要辩证的看待风险。吃饭也有风险，但是不能因噎废食。有的同学总觉得需求有风险，你问他是什么风险，他说他也不知道，只有碰见了才知道是什么风险。只要做事情那必然会有风险，但是我们不能预设风险，否则事情没法做了。另外，有的同学在排期的时候，因为觉得和自己配合的人不靠谱，会额外增加几天。这种做法也是有问题的，在项目过程中我们要相信每个人建立的契约，如果你怀疑别人的契约，干嘛要立这个契约呢？

总结

本文写的东西，整体来看是很虚的，不一定有什么用。因为每个人面临的问题不一样，采取的措施也不一样。此之甘饴，彼之砒霜。适合自己的，才是最好的。

本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/ISuLIME7fy66pjKjV1Ruyg