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

多層級多部門的協作專案，還能敏捷起來麼？