多层级多部门的协作项目，还能敏捷起来么？

前天中午，王立杰老师（@无敌哥）在IDCF的FDCC认证学员群里抛出了这样一个问题：

站在用户的角度思考问题，与客户深入沟通，找到西工网站设计与西工网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：网站设计、成都网站建设、企业官网、英文网站、手机端网站、网站推广、国际域名空间、网络空间、企业邮箱。业务覆盖西工地区。

某传统企业公司组织架构有很多层级，很多部门协同，把传统项目管理做得很重，很流程。现在涉及跨项目、跨部门、供应商的项目占比超过70%，研发效率低。

面对这样的情况，该如何管理和协同各方？短期该如何做，长期又该如何做？

针对这个问题，群里的小伙伴结合自己的经验展开讨论，一中午的时间里大家聊了超过200条微信消息，我们将本次讨论的部分内容进行了整理，分享给大家。

讨论焦点一：产生这个问题的原因可能有哪些？

1、部门墙导致各方立场不一致，产生推进障碍

多方协同的项目越来越多，且组织层级多，猜测其原因可能是部门墙导致项目中会有太多的声音不好管理，或者可能多方进度不同步，相互成了对方的障碍导致项目难以推进。

2、管理、执行、文化等问题导致好的制度推进不下去

问题可能产生于领导力、团队执行力、团队协作等因素，这些非项目管理能解决。很多团队是制度流程很完善，但团队人员技能遇到瓶颈，或者好的制度流程执行不下去，也没人跟没人管，缺乏监督、缺乏激励、缺乏奖惩，导致恶性循环。

3、上层老板的风格导致的问题

产生这个问题的原因往大了说是老板的风格、目标愿景的导向，企业文化、工作氛围、组织架构设置、分权授权设置是否合理，会不会导致沟通低效、不对称，推进的团队没有权利和推动力，会不会有问题管不了、没人听；往小了说，就是项目本身执行的透明、检视、调整没有做好。很多传统企业都是项目集群管理的壳，敏捷的心。

4、这是长周期项目本身的特性所导致的

长周期项目对供应商或客户依赖太大，需要大量的沟通协调。长周期项目必定离不开项目规划、项目目标、优先级、阶段性，所以很难绕开传统项目管理的影子。一般是内部平台研发或C端采用敏捷，B端交付依旧是瀑布式，瀑布里裹着敏捷，四不像。

长期项目的特点：需求不是连续的，阶段性交付不是均衡的，受制客户或供应商等外部因素很多，变更也很多。如果单独组成独立项目组会导致资源不能合理利用，同样也不利于公司业务平台化架构体系的统一，有可能会产生很多定制个性化。

讨论焦点二：如何诊断具体问题找出原因？

1、定期沟通，过程改进，找出问题

可以先组织各个部门参与定期沟通，过程改进组辅导大家用看板或者其他方式，先确保各项目有优先级，进度可视化，把矛盾和问题暴露出来。而且有了上层的优先排序，下层资源冲突时也可以有参考，辅导方也更容易发现里面隐藏的其他问题，然后再针对更具体的问题进行解决。

2、项目可视化，对照访谈，定位问题

首先需要进行访谈，看是“谁的”“什么问题”，其次用价值流或者其他工具把项目在各部门各个角色的流动画出来，把按角色/部门分的泳道和价值流图结合起来做成一张图，能够清楚地展示项目的现状，尝试找出障碍阻塞，跟访谈结果对照，找到真正的问题。

讨论焦点三：长期/短期有什么能够见效的解决方案？

1、若是偏职能型的组织或以资源为中心的管理团队，这个问题很难根本性解决。若是70%这么高的比例，最好可以整理出一个比较典型的案例来做分析，重新梳理业务，明确如何做到向客户交付路径最短，再根据实际情况调整组织架构。

2、短期来说，可以考虑先选一个项目做试点，尝试项目制管理；长期的话，可以考虑按业务、专长等特性拆分成事业组群进行管理。

3、分类分级分策略，区分重点、非重点，识别各个项目管理的要点。

• 短期：抓重点项目，职责明确，问题清晰，进展透明；

• 长期：定制度流程，配QA质量保证，分阶段管理跟踪。

核心是：技术研发类和非技术研发类可以都是项目化管理，但是管理要点、抓手设置是要有区分的。

4、产品研发部分可以采用间断性敏捷方法，排Sprint优先级后，多项目交叉的Sprint切换进行。

5、长期来看，要按照业务做组织改革，跟Spotify里划分tribe类似，尽量把组织解耦；同时仿照类似多级看板的管理流程来管理项目，在不同组织层级对齐不同粒度的项目状态，让项目进展明晰起来。

6、建议短期项目保持，找个长期有价值非高风险的项目做试点，成立虚拟组织，组内拉通绩效，项目群执行的各种敏捷方法跟上慢慢来。

讨论焦点四：长项目周期特性问题该如何解决？

按照一个完整的MVP业务闭环设计方案和迭代，将长周期的项目拆分成小的阶段；短期没有效果的项目可以适当让些资源给短期见效的项目。总之需求部门之间要先通气，统一组织整体的目标，而非各自为战自我消耗。

讨论焦点五：外部因素（供应商）导致的问题该怎么解决？

1、做到可视化，找出等待的原因

经常有开发在等供应商联调，但因为没有透明出来，导致其他项目在等这些开发资源，这就是浪费。其问题在于我们不知道需要等待，如果等待是已知的，那么应该鼓励把等待的任务放到blocker，然后接着做新的任务。所以，不管什么问题，首先还得可视化，才能看到浪费和阻塞，才能说怎么解决。

2、有自己的流程和标准

和供应商一起开发联调，关键自己要有流程和标准，架构自主可控，BA、IA自己设计，共同参与评审。

供应商多，也要约定好接口一个个来，供应商进度跟不上，自己人就先去做其他的，相关功能要么先不上，要么以手动的方式替代，这些只要沟通好还是可以解决的。至于供应商的问题，看如果没有这个功能的话哪个部门最痛，就让哪个部门去推进，供应商肯定也有合同约束的。

讨论焦点六：如何得到上层对改革的支持？

改革自下而上推不动，上层要变革，需要中层有方案、底层可执行。

首先，要让上层老板们觉得这是问题，传统公司基本上是长周期瀑布为主，敏捷只是个装门头的玩意儿。

很多时候执行人员跟老板说有问题，但说服推动的能力欠缺，没有强有力的证据，也没有可靠的建议方案或替代方案，只说问题不说解药，老板无法决策。

改革决策难做，很多时候是卡在不透明，不能暴露真实问题，也有很多时候卡在知道问题在哪里但是没有替代方案。

所以传统管理认为ISO、CMMI、IPD等要求的那些文档，非常重要，做好研发过程的透明化，可视化，让问题真正暴露出来，让上层老板认识到问题的原因，找到证据，是说服老板改革的关键。