对于复杂项目和PMO管理思路的一些杂谈

昨天和一位业界同仁沟通项目管理、PMO、敏捷实践的话题，擦出了一些思想的火花，针对以下两点，觉得有必要梳理一下。

一）对于复杂项目的理解

二）项目管理者究竟要做到什么

一）对于复杂项目的理解

大多数人的思维是纵向思维，在自己的领域里面做深。而IT项目会涉及很多方面，更擅长纵向技术或者纵向产业务逻辑的产品技术小伙伴们，往往从精力和经验上难以应付非常复杂的局面。这个时候需要从体制上保障，有人去进行横向推动工作。比如PMO体制，或者类似大规模敏捷SAFe框架的RTE。

当面临复杂局面的时候，一名优秀的IT项目管理者，要始终保持冷静的横向思维，在其他人集体无意识或者整体发懵的时候，把纵向任务模块梳理出来，存在问题梳理出来，找到每项纵向任务的责任人和Review者，从整体角度推动项目取得进展。

以下内容以瀑布式项目管理的语境来描述问题。如果问题符合敏捷模型，当然可以以敏捷方式去考虑对策。

项目的复杂原因，简单整理如下。

1、业务本身复杂

2、需求方太多，立场不同导致的复杂

3、技术验证和攻关带来的不确定性

4、项目跨团队较多，容易沟通疏漏和扯皮

5、项目规模大

1、业务本身复杂

要充分主动的挖掘需求，利用各种方式循循善诱，有目的性的主动调研，帮助业务方提出完整闭环的需求，在WBS中明确把挖掘需求的工作项列入进去。

往往发生的情况是：

1）业务方往往不能充分描述需求，或者因为表达方式和思维方式与IT不同，或者出现理解偏差

2）他自己在脑海中为需求设计了一套方案，只表达了方案，没充分表达目的

3）细节和异常情况没有提前考虑，导致中途出现大的变更

2、需求方太多，立场不同

往往会发生以下情况

1）不同人塞进来自己的需求，无论是否合理，都要求提高优先级

2）对于方案有不同意见，比如财务不同意运营方案，运营认为产品方案太Low

3）漏掉了重要关系人，导致方案在研发过程中出现大的变更

这个时候需要PM外圆内方，小心翼翼，进行干系人分析，利用各种方式推动各方形成理解一致

1）首先深刻理解项目的目标，并形成自己的判断标准

2）单独跟每个干系人沟通，深刻评估他们的立场和诉求，做到心中有数，看破不说破

3）分析出意见冲突的团队和冲突点，在沟通会议上引导他们充分进行意见碰撞，但PM要控场，维持住斗而不破

4）PM的唯一立场就服务于项目目标，对每个干系人都是中立的，避免自己各某一方发生冲突

5）把针对具体冲突点的沟通，纳入到WBS中进行管理

3、技术验证和攻关带来的不确定性

要明确哪些部分是不确定的，有没有备用方案，一般要有三种方案。确保即使攻关失败也不会影响正常业务，要避免业务对技术攻关内容形成依赖。孤注一掷往往比较惨烈，要充分考虑业务风险。同时压力过大会导致人的立场发生改变，大部分人是不愿意承担过大压力的。

在技术攻关中，要仔细评估研发团队是否在自嗨，技术方案是否需要超前于业务发展，是需要经过慎重决策和论证的，要合理约束架构师们抑制不住的超前重构冲动，基于业务优先级来权衡任务分配。

如果经过了论证，就要全力支持他们，解决所有横向问题和后勤保障，确保他们不会分心。

4、项目跨团队较多，容易沟通疏漏和扯皮

扯皮往往发生于研发中后期，当出现需求理解、系统架构、接口调用、测试环境等各种问题时，业务、产品、研发、测试、运维会发生扯皮、甩锅、推卸责任的行为。

作为有经验的PM，要能够预判出哪些方面容易发生扯皮，提前下手在早期明确责任，在前期的会议纪要、项目报告中体现出来，形成威慑力，避免扯皮的发生。

如果问题已经发生，要避免产生只解释推脱，而不去面对和解决问题的情况，要把所有人拉到同一立场上来，共同面对问题。这一方面，依靠PM的掌舵经验和沟通技巧，难以展开细说。

5、项目规模大

如果项目规模大，就拆分成几个耦合度不高的项目，分期推动。

或者建立项目PMO机制，可以参考下图。

二）项目管理者要实现的

1、时刻确保干系人对项目目标和范围的理解一致

2、解决因立场不同而导致的冲突

3、针对范围和计划安排，建立承诺和约束

4、为项目成员扫清障碍

对于1、2，无论是瀑布模型，还是敏捷模型，都要有具体手段去实现。包括瀑布的各种评审会议、Scrum里面的站会、Review会、计划会、梳理会，还有看板，各种协同工具都是手段。

对于3，在评审阶段要建立计划，明确范围，使各团队按照计划去实施项目。需要重点强调指出的是，2和3中都涉及了人的立场，弱矩阵下项目管理者对于团队只有协调职能，没有管理权限。所谓的约束，来自于项目交付目标日期，以及团队之间的制约，比如研发团队会要求产品团队如期评审通过，测试团队会要求研发如期提测，研发团队间会要求接口的如期提供，有经验的项目管理者会充分利用这种制约，在不同阶段重点制约不同团队，确保项目的如期推进。如果团队已经具备了敏捷认知或者在开展敏捷实践，这种制约会相对容易实现。

对于4，项目成员往往更希望专注于纵向任务，同时不擅长横向沟通，那么项目管理者要提前解决项目成员面临的非纵向问题。比如测试环境、数据脚本、并行任务的优先级协调、跨团队需求确认等。

需要强调的是，我们一定要推动项目和个人及团队的多赢，使团队利用项目过程提升能力。而Scrum敏捷实践是非常好的方式，Scrum也能够利用各种形式提升团队成员的横向能力，比如计划会的故事点评估、站会、DoR、DoD的自我评估、回顾会的问题分析等。

在理解Scrum套路之前，要充分领会Scrum的三个支柱，理解其本源含义，确保能够利用Scrum实践来实现个人及团队的成长。