多層級多部門的協作項目，還能敏捷起來么？

前天中午，王立杰老師（@無敵哥）在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等要求的那些文檔，非常重要，做好研發過程的透明化，可視化，讓問題真正暴露出來，讓上層老板認識到問題的原因，找到證據，是說服老板改革的關鍵。