一个失败的项目管理案例

文章目录

1、背景介绍
2、原因分析
3、解决方案
4、总结

1、背景介绍

从 2020 年三月底开始做一个设计管理平台的项目，我被指派为这个项目的项目经理，项目成员包括产品经理（1）、后端（4）、前端（2）、UED（1）、UI（1），共 10 位成员。从项目正式启动，到七月初，第一个被需求方、发起人都认可的 V1.0 版本原型才确定。在这接近四个月的过程中，几乎项目管理的全部坑都踩了个遍，特别是干系人管理、冲突管理以及变更管理与项目管理的基本要求几乎完成全部背离。这个项目为何会走到这个几乎失控的地步呢？

2、原因分析

下面全面来进行一下问题的分析，可以从项目筹备阶段开始
1、项目定位不清晰（干系人管理）
关于这个项目的定位，业务方领导与技术方领导有完全不同的定位，技术领导认为应该要设计管理平台，而业务方领导明确表示我们需要的设计协同平台，双方经过几次交流，但是始终未能够对产品的定位达成一致。产品经理找需求方确认过的需求，技术领导不认可，不仅技术领导不认可，甚至业务领导也不认可。
此处项目经理有较大责任，需求的确认完全交由产品经理处理，但是在项目的进行过程中，明确发现产品经理确认的需求、设计的原型得不到技术领导与业务方的双方的认可，此时应该组织需求讨论会议，让相关的干系人（技术领导、业务领导）需同时参加，明确 alpha 版本的需求。而不是只埋头在进度控制中，需求没有得到核心干系人一致认可的时候，做的越多，偏离越远。
2、责任权限不清晰
项目中有产品经理、项目经理，在项目启动阶段并没有明确说明产品经理与项目经理的职责与权限。产品经理管理需求，但是未对干系人进行有效管理，项目经理此时要不要去强力干预对干系人进行管理？
项目经理是作为整个项目的负责人，但是常常被定义在技术负责人的位置，管理技术选型，开发进度控制，没有对整体项目的成败负责，常常对着两位老总不同的产品定位叹气，但是没有采取有效的措施来解决这种问题。
3、迭代内容周期控制（项目进度计划管理）
项目节点是在 6.30 号发布第一版，实际开发时间有两个月，产品一边出原型，开发同时同步进行开发。按照约定的第一个原型版本，是有足够的时间进行开发的。这时对接的业务方要求增加四个审批流程，并且这四个流程可以循环往复交替进行。当时接到产品经理的这个需求时，我第一反应是拒绝的。这个地方描述增加一下产品经理背景描述，产品经理有深厚的行业背景，产品开发经验稍有不足。 我跟产品进行沟通，询问是否可以放到下个迭代，得到的回复是可以，但是没有这个流程，用户是无法使用这个产品的。我考虑到有当时还有较为充沛的时间，同时这个需求设计到核心的功能，决定在这个开发周期内将这个新增的流程功能开发完成。最终完成了任务流程功能的开发，但是由于业务逻辑较为复杂，一方面产品并未完全梳理清晰全部业务逻辑，另一方面，此功能为经过充分测试，在一次产品演示的时候，技术领导表示该流程交互太复杂，业务领导表示这这个任务流程完全不是他想要的。
这里的问题是在需求原型确定的情况下，项目经理应该缩短每个迭代的任务周期，最多不超过三周。一个迭代版本的时间近两个月的时间，最后核心干系人告诉你这不是他想要的。应该在每完成一次迭代的时候，举行迭代回顾会议，演示产品，让核心干系人对阶段成果进行演示。必须完成第一个迭代的验收，才能进行下一个阶段的开发工作。 如若不然，还不学学新技术实在。
4、变更控制严重缺乏（变更管理）
由于文件版本管理做为其他应用获取模型信息的一个统一入口，技术领导对项目比较关心，时常要求产品演示，同时针对产品提出许多改进意见，态度较为强势，产品经理与我扛不住压力，频繁变更。由于这个变更，业务方是不知情的，所以变更后的产品同时又得不到业务方的认可，这样最后就导致了一个干系人不认可、目标用户不接受的产品的产生。
项目经理在这件事情上负有主要责任，作为一个项目经理，一定需要严格的管控变更。如果要进行变更，必须核心干系人同意，技术领导的优化意见必须要业务领导认可，才能执行变更。并且变更是不在当前迭代周期内进行的，把变更作为需求记录起来，在下个迭代内进行讨论开发。

3、解决方案

这种情况在 PMO 的强力介入后，得到了极大的改善，推了一个核心干系人都满意的 v1.0 版本原型，那么是怎么做到的呢？
1、强力的干系人管理。每次进行需求确认时，确保全部干系人认可。具体流程是先与业务对接人进行需求讨论，然后与需求领导进行需求原型评审确认（需求确认时最好技术领导在场），最后与技术领导进行原型评审确认。若有异议，组织与业务领导的讨论，直到双方都同意该原型为止，最终确定原型为 1.0 版本。不管领导多么强势，一定要坚持自己的立场，守住自己的原则，不跟着领导天马行空，只做跟需求方确认过的需求，其他一切需求都要经过讨论后再进行设计开发。
2、严格的范围控制。确定一个最小 mvp 进行迭代，迭代周期改为 2~3 周，这两到三周内任何变更都不做，只记录变更点，在下一个迭代启动时，再进行变更的讨论。
3、强力推动项目。对于设计管理与设计协同的争议，先不去管他。将争议搁置，先看需求方当前最需要什么东西，我们先在最小范围内，用最简单的方式满足其需求。搁置争议，推动项目。

4、总结

这个项目遇到的问题都是项目管理中较为常见的问题。 PMO 介入后，用这一套组合拳，虽然非常简单，甚至是许多方法有点老生常谈，但是很有效。项目的新原型，业务方与技术方领导都较为满意。其实许多项目的点，我们开始也有做，但是没有强有力的去执行，遇到强势的领导以及需求方就妥协了。这种妥协的结果只能是一个妥协的产品，在可用性、稳健性上都无法得到保证。
项目经理一定要有对整个项目负责的准备，不要只把自己定义在进度管理的小圈圈里。此外就是项目经理必须做好干系人管理，同时在遇到外界压力时，必须坚持自己的原则，此时的一分妥协，后期需要十分的加班去填坑。