扫码阅读
手机扫码阅读

项目管理实践常见困境(六)

284 2023-11-09

这个系列基于大家工作中时常会面临的问题、困境,期望从不同视角提示思考问题的方向。
其中描述的“场景”和“问题”均来源于大家平时讨论的话题;“反馈”则来源于个人参与讨论时的输出,可能会在整理时根据其它人的反馈内容稍作调整精进,以期能够提示到更多的视角来看待相应的场景和问题。在此也感谢亦师亦友的伙伴们的支持。

本期话题:
  1. 案例:敏捷转型建立规则。迭代结束时间到,有US未完成。问题已发生(不谈预防),项目经理该怎么办?
  2. 案例:收到项目经理求助,如何帮其推动另一个事业部研发协助?


01

如下情况如何建立规则?

迭代结束时间到,有US未完成。

问题已发生(不谈预防),

项目经理该怎么办?

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

项目场景:

敏捷转型环境,PMO建立规则的一个案例。补充背景:to B的业务,客户必须要,未完成的US阻断迭代目标。

问题:

如下情况如何建立规则?迭代结束时间到,有US未完成。问题已发生(不谈预防),项目经理该怎么办?

反馈:

1、定整体规则,考虑分层,即项目层和交付层可以分开。相应的,客户发布和开发交付是分开的。敏捷转型可以是针对交付方式,客户端项目管理再根据场景选择相应的方式(当然后面这个要看整体敏捷转型的规划了)。

2、关于细化到具体交付规则的问题,延长最后一个迭代还是在新的迭代内。这个基于上面的分层组织方式看:客户端项目层增加一个上线节点,如果正好在敏捷交付和项目上线的缓冲期,那么交付层不动迭代周期,在新的迭代内高优先地完成即可;或者项目层上补资源协助赶工,都是可以的。都是两层打配合完成的。

简单说就是不要把项目管理和敏捷交付的管理方式完全割裂开,而只盯着开发交付这一层;还有更多关注用户/客户视角的项目层可以配合敏捷交付团队的PO。



02
收到项目经理求助,
如何帮其推动另一个事业部研发协助?
项目场景:

案例:收到一位项目经理求助,希望能帮他推动另外一个部门的研发协助我们解决问题。背景:这位项目经理的团队在研发过程中调用了另外一个事业部的一个软件接口,发现这个接口已经2年没更新,功能不兼容,需要这个事业部的研发同事帮忙一起解决问题。

问题:

如果是你,你怎么推动另外一个事业部的研发解决问题?

反馈:

1、首先看自己所在层流程中(看作是本职能业务运营)是否有通路能够获取对方部门的积极反馈。下面一层的项目经理无法解决,但到了自己所在这层,可能流程中的通路就存在了。

2、沟通方面两条腿走路。一方面找平行部门,从对双方事业部的收益来分析看能否达成共识配合一起完成;另一方面,向上反馈,寻求更高层在事业部间的通路和支持。

3、平行部门沟通方面,除了针对事实讲困难讲(负面)影响,更多地是关注能够给对方部门业务带来什么正收益,如果有负收益,是否能够协助解决,作为某种程度上的利益交换。而且基于重要性的分析,拉动对方同步向上反馈也许能在对方实在存在资源冲突时加快进程。

4、向上反馈方面,按流程做吧。

5、另外技术处理方面,自己这个层级是否可能有资源准备一个临时过渡方案,通过临时加入协作的方式或许能减小对对方部门的影响,并加快处理进程。



后记:

这个系列目前计划以个人的梳理为主。欢迎关注,期待交流,扩充视角,不断精进。
    
想要了解更多,点击 查看原文