背景
入職阿裡從雙十一會場前端PM到平台項目等PM大大小小的擔任了不少，自認為是老司機，不想還是踩了坑，這段時間好好地回想了下這次項目中的一些問題，根據個人經驗整理了這篇文章，友善後續的回顧以及能幫助有同樣問題的人。
定義
先簡單定義什麼是跨團隊協作項目：跨團隊協作是指在給指定時間限制規範内，不同部門與部門之間、個人與個人之間的協調與配合完成一項明确目标的獨立的工作任務。
大體上來說一次項目的的流程分五個階段“項目啟動”->“需求評審”->“開發”->“測試（驗收）”->“釋出上線”，中間涉及的角色有“PD(and 業務)”、“PM”、“設計”、“開發”、“測試”，具體的流程可以看下圖
項目流程圖
在項目的運轉中，從最開始來自業務或産品的規劃，到需求對焦和分工明确，以及推進到最終上線整個環節中PM的角色都扮演者非常重要的一環，技術PM不僅僅需要了解項目管理的大緻流程，也需要了解業務和技術方案，在中間才能推進項目的順利落地。
後續的章節會重點圍繞聚合後的“項目初期”、“項目中期”以及收尾來展開，重點描述下在這個3個大階段都要做哪些工作和重點注意的事。
NO.1
項目初期
1.1 KO立項
一個項目的發起，最終過濾層層環節到達你身上時，至少從戰略上是的得到大家的認可(當然還是需要保留自己的主觀意識做好判斷)，在項目啟動前做為PM需要先了解這個項目，為什麼做？目标是什麼？可能要涉及哪些角色？作為項目PM，如何自己都搞不清楚前面三個問題，那大機率這個項目做不好，理好些問題後才能更好的去協同資源同時明确目标和項目組的同學一起拿到結果。
在明确了解清楚這3個問題後，第一項要做的就是KO立項
可能有同學眼裡KO看到的和上圖一樣，一次項目KO非常重要，通過KO可以把關聯的同學聚集到一起，分享項目背景和目标形成共識，另外還可以明确人員邊界分工和裡程碑友善後續的項目驅動通過這個儀式感讓參與的同學感謝存在和認可更強，那一次KO需要準備哪些東西：
- 梳理項目涉及的角色和關聯域負責人線下達成一緻，明确子域接口人
- KO PPT 準備（“背景描述”、“目标價值”、“項目介紹”、“産品架構”、“技術架構”、“裡程碑”、“人員分工”等）
- 正式會議邀約，講價值打雞血
1.2 需求評審
KO目的是讓大家對這個項目有第一印象和共識，通過需求評審能讓大家深入的了解項目，一次項目需求評審可能有2次以上，第一次初稿的評審會有産品思考不全的地方，作為PM最重要的除了了解需求本身外需要定制需求截止時間，讓需求能快速的評審确定，便于後續的流程正常運作，需求評審需要多了解細節多問為什麼，跳開技術的身份去思考業務，帶着技術的身份去思考可實施性。
評審完成後最重要的環節除了任務和優先級拆解，以及資源、成本估算和風險評估外，最最重要的就是按照KO大的裡程碑将時間節奏計劃産出，後續的項目推進将重點圍繞這份時間節奏執行。
1.3 任務拆解
在需求評審完成後，就需要開始做子域的劃分和任務拆解，避免如上圖一團亂麻發力的問題，任務拆解在項目管理中也有類似術語叫做“工作分解結構”（WBS），即把一個項目，按一定的原則分解，項目分解成任務，任務再分解成一項項工作，再把一項項工作配置設定到每個人，直到分解不下去為止，在做項目分解時可以順便做好需求優先級的拆解，業務或産品的需求總是一塊比較大而全的東西，在實際實作時沒法做到一次性完美落地，因為做好優先級的拆解才可以分期按版本完成，優先級的拆解可以按功能的關聯度和是否是主流程以及項目目标和業務價值作為判斷依據，另外任務拆解的力度盡量要細避免因為過粗導緻評估不足和忽略影響整個項目進度的問題，任務拆解中我們可以按照子域和項目中的功能子產品來拆解，這樣有對比參照，任務拆解完畢後可以通過甘特圖等工具來管理。
另外在實際的項目中，由于涉及的人員比較多，絕大部分任務是由子域負責人在拆解下去，是以在這裡明确好角色和分工職責非常重要，角色界定不清晰也是時常影響到我們項目落地的一大因素。
1.4 技術評審
任何一個項目技術評審均是必不可少的一環，在需求和任務拆解完畢後，分域做技術評審拉通上下遊依賴做正式的review，可以發現在任務拆分或需求評審中所沒考慮到的細節，在前期将風險扼殺在搖籃中，另外在做技術成本預估時一定要加上buffer時間，這個buffer時間可以按照以往的經驗作為一個系數乘上去如0.3，因為方案評審并不能做到所有的細節一次性考慮周全，不要将自己的加班時間算進去，這本身已經是項目風險。
技術評審需要哪些内容：
- 業務流程圖（基于業務視角你所在域的環節和使用者操作流程）
- 技術架構圖（架構或分層，可以了解到你所在域和周邊依賴）
- 方案設計
- 任務拆解&時間軸
- 上下遊依賴&風險
項目中期
2.1 交流溝通
項目管理中溝通是最重要的一個環節，啟動後最大的障礙就在交流溝通上，一個完整的項目會拆分為很多子域，每個子域間會有依賴，在資訊傳達和進行中可能因為溝通不及時或者了解偏差導緻方案設計的問題，如何把這些人聚集在一起項目室是個比較有效的解決方式，可以通過項目室在對項目執行過程時，保持項目成員的溝通的有效性確定方案設計和了解一緻。
建立周會和日會機制，按項目的不同階段運作，在開發開始運作時可以通過周會的方式，一周同步下目前進度和風險以及下周重點計劃，確定項目按期執行，運作至中後期時需要開始日會機制，加強溝通交流，友善風險和問題及時同步，會議的主要内容可以按以下方式：
- 今日主要做的事&整體進度
- 是否有風險和依賴
- 明日計劃
- 昨天風險是否接觸
2.2 風險控制
風險的主要來源很多，比如前期需求了解不一緻、項目計劃不合理或需求變更等等，風險是無法完全避免的，但我們可以通過曆史經驗或項目管理來提前發現、最小化風險，整個項目最核心的也就是這部分，風險的大小和暴露的早晚會直接影響到這些項目是否順利，是以對于項目中暴露的問題需要保持足夠的敏銳度，遵循墨菲定律，另外加強溝通、管理和交流保持資訊擷取的有效性。
NO.3
項目收尾
3.1 測試問題推進
在項目進行到後期收尾階段，最大問題就是issue的fix和測試覆寫是否齊全的問題，每個問題的修複可能都會暴露出新的問題，問題修複的越早，留個測試和項目的時間也會越足，是以在開發聯通提測前需要開始測試用例的梳理和評審，確定測試流程覆寫度，在測試開始後需要關注問題的推進和修複，盡量確定問題日清。
3.2 項目驗收
項目的最後一個環節就是驗收，驗收方式分2種，一種為組織會議預演，另外一種為推進産品（業務）和視覺驗收（走查），第一種比較容易了解，即申請正式的會議拉上關聯項目組成員和業務同學做産品功能的預演，確定産品和業務了解一直以及功能完善，第二種則由産品和業務以及設計同學，分别以各自的域走查，確定視覺還原、産品邏輯、産品文案的一緻性。
另外最重要的一點是項目方案如果涉及到新老版本交替時，一定要考慮到二者的相容和對使用者的影響以及預案，避免影響使用者，如果是個block change那需要確定足夠的穩定，使用者為第一優先級
NO.4
常見誤區
- 過分悲觀 or 樂觀：這兩者均建立在對項目掌控度不夠的情況下，會導緻對于項目的判斷失誤，過分悲觀會影響到項目組同學的積極性，反之會導緻風險暴露在後期。
- 忽略細節：即墨菲定律，凡是覺得可能出錯或小機率出錯的事一定會出錯，當review發現問題時需要深入到細節中了解和推進，避免問題最終暴露線上上。
- 資訊斷層：跨團隊項目中涉及的人較多，資訊傳遞中因為不同的同學判斷和思考方式不一樣，導緻最終你得到的資訊可能是有誤或缺失的資訊，需要多問多了解。
- 考慮不全：每個人抛開項目PM都有自己原本的角色，比如前端、某某平台開發，導緻自己站位思考會下意識從目前域去看，丢失了其他面，作為項目PM需要抛開自己的身份，站更廣的域思考。
- 不敢取舍：項目啟動後因為外部各種因素感染導緻項目的需求上變化，針對明确的項目目标和計劃需要做好取舍，了解需求的本質，敢于說不。
- 前松後緊：不合理的規劃會導緻項目陷入這種狀态，導緻提測時問題過多，開發未自測品質差等情況
NO.5
常見問題
下面的問題主要是個人見解不一定是最佳實踐，有好的其他答案歡迎回複。
5.1 上下遊不配合如何推進？
換位：每個人每個Team都有自己規劃好的事，當我們換位思考了解目前依賴的團隊目前的規劃和方向是怎樣，是否有周邊其他方向一緻的合作夥伴，才能更和的切入推進和合作
利他&共赢：這2個詞可以合成一個，做好一件事的前提條件一定是大家方向目标一緻，這樣才能長期正常的運作下去，隻有利他才能形成良好的運作模式，抛開屁股意識尤為重要，避免短期利益，另外在找上下遊尋求幫助前一定要提前想清楚他要什麼？我能給什麼？想不清楚建議在重新review是否找對人和做對事。
借勢：分2種情況，第一和目前大團隊或者集團大的方向目标捆綁，跟着大的背景驅動下前行；第二向上尋求幫助，個人的力量和可以調動的資源總歸有限，要學會向上管理尋求幫助
5.2 如何做好項目風險把控？
項目開始前：風險往往發生在你所未關注的視角或者依賴的上下遊部分，一個複雜的項目涉及的人和方案會較多，不同域方案不一樣一個人的精力總歸有限，這種情況下拆域化簡明确分工職責和接口人尤其重要，細分好域明确子域同學職責
項目中：”溝通“項目協同管理最核心的事，和子域負責人保持資訊溝通交流，定期(日、周會等方式)對焦進度和風險，才能提早發現問題，另外避免隻把自己局限在自己這塊域上，更深入的了解細節和技術方案才能比較好推進，方案評估時對于時間節奏buffer才能掌控自如，以及提前發現風險和推進解決
項目上線時：作為項目最後一環較多問題主要為之前忽視偶現難排查問題以及未考慮應急預案，遵循墨菲定律，你所未在意的問題可能成為壓倒這個項目的最後那根稻草，上線前多預演和準備好check list以及預案手冊
NO.6
總結
任何一件事或項目光靠一份文檔是無法保障穩定的，還是需要更多自己沉澱、積累以及跟進，做的多了跟的緊了才能確定沒問題和沉澱自己的方法論，事在人為。