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