如何做好一個跨團(tuán)隊協(xié)作項目

入職阿里從雙十一會場前端PM到平臺項目等PM大大小小的擔(dān)任了不少，自認(rèn)為是老司機(jī)，不想還是踩了坑，這段時間好好地回想了下這次項目中的一些問題，根據(jù)個人經(jīng)驗整理了這篇文章，方便后續(xù)的回顧以及能幫助有同樣問題的人。

先簡單定義什么是跨團(tuán)隊協(xié)作項目：跨團(tuán)隊協(xié)作是指在給指定時間約束規(guī)范內(nèi)，不同部門與部門之間、個人與個人之間的協(xié)調(diào)與配合完成一項明確目標(biāo)的獨(dú)立的工作任務(wù)。

大體上來說一次項目的的流程分五個階段“項目啟動”->“需求評審”->“開發(fā)”->“測試（驗收）”->“發(fā)布上線”，中間涉及的角色有“PD(and 業(yè)務(wù))”、“PM”、“設(shè)計”、“開發(fā)”、“測試”，具體的流程可以看下圖

在項目的運(yùn)轉(zhuǎn)中，從最開始來自業(yè)務(wù)或產(chǎn)品的規(guī)劃，到需求對焦和分工明確，以及推進(jìn)到最終上線整個環(huán)節(jié)中PM的角色都扮演者非常重要的一環(huán)，技術(shù)PM不僅僅需要了解項目管理的大致流程，也需要了解業(yè)務(wù)和技術(shù)方案，在中間才能推進(jìn)項目的順利落地。

后續(xù)的章節(jié)會重點(diǎn)圍繞聚合后的“項目初期”、“項目中期”以及收尾來展開，重點(diǎn)描述下在這個3個大階段都要做哪些工作和重點(diǎn)注意的事。

一個項目的發(fā)起，最終過濾層層環(huán)節(jié)到達(dá)你身上時，至少從戰(zhàn)略上是的得到大家的認(rèn)可(當(dāng)然還是需要保留自己的主觀意識做好判斷)，在項目啟動前做為PM需要先了解這個項目，為什么做？目標(biāo)是什么？可能要涉及哪些角色？作為項目PM，如何自己都搞不清楚前面三個問題，那大概率這個項目做不好，理好些問題后才能更好的去協(xié)同資源同時明確目標(biāo)和項目組的同學(xué)一起拿到結(jié)果。

在明確了解清楚這3個問題后，第一項要做的就是KO立項

可能有同學(xué)眼里KO看到的和上圖一樣，一次項目KO非常重要，通過KO可以把關(guān)聯(lián)的同學(xué)聚集到一起，分享項目背景和目標(biāo)形成共識，另外還可以明確人員邊界分工和里程碑方便后續(xù)的項目驅(qū)動通過這個儀式感讓參與的同學(xué)感謝存在和認(rèn)可更強(qiáng)，那一次KO需要準(zhǔn)備哪些東西：

1. 梳理項目涉及的角色和關(guān)聯(lián)域負(fù)責(zé)人線下達(dá)成一致，明確子域接口人

2. KO PPT 準(zhǔn)備（“背景描述”、“目標(biāo)價值”、“項目介紹”、“產(chǎn)品架構(gòu)”、“技術(shù)架構(gòu)”、“里程碑”、“人員分工”等）

3. 正式會議邀約，講價值打雞血

KO目的是讓大家對這個項目有第一印象和共識，通過需求評審能讓大家深入的了解項目，一次項目需求評審可能有2次以上，第一次初稿的評審會有產(chǎn)品思考不全的地方，作為PM最重要的除了了解需求本身外需要定制需求截止時間，讓需求能快速的評審確定，便于后續(xù)的流程正常運(yùn)行，需求評審需要多了解細(xì)節(jié)多問為什么，跳開技術(shù)的身份去思考業(yè)務(wù)，帶著技術(shù)的身份去思考可實(shí)施性。

評審?fù)瓿珊笞钪匾沫h(huán)節(jié)除了任務(wù)和優(yōu)先級拆解，以及資源、成本估算和風(fēng)險評估外，最最重要的就是按照KO大的里程碑將時間節(jié)奏計劃產(chǎn)出，后續(xù)的項目推進(jìn)將重點(diǎn)圍繞這份時間節(jié)奏執(zhí)行。

在需求評審?fù)瓿珊螅托枰_始做子域的劃分和任務(wù)拆解，避免如上圖一團(tuán)亂麻發(fā)力的問題，任務(wù)拆解在項目管理中也有類似術(shù)語叫做“工作分解結(jié)構(gòu)”（WBS），即把一個項目，按一定的原則分解，項目分解成任務(wù)，任務(wù)再分解成一項項工作，再把一項項工作分配到每個人，直到分解不下去為止，在做項目分解時可以順便做好需求優(yōu)先級的拆解，業(yè)務(wù)或產(chǎn)品的需求總是一塊比較大而全的東西，在實(shí)際實(shí)現(xiàn)時沒法做到一次性完美落地，因為做好優(yōu)先級的拆解才可以分期按版本完成，優(yōu)先級的拆解可以按功能的關(guān)聯(lián)度和是否是主流程以及項目目標(biāo)和業(yè)務(wù)價值作為判斷依據(jù)，另外任務(wù)拆解的力度盡量要細(xì)避免因為過粗導(dǎo)致評估不足和忽略影響整個項目進(jìn)度的問題，任務(wù)拆解中我們可以按照子域和項目中的功能模塊來拆解，這樣有對比參照，任務(wù)拆解完畢后可以通過甘特圖等工具來管理。

另外在實(shí)際的項目中，由于涉及的人員比較多，絕大部分任務(wù)是由子域負(fù)責(zé)人在拆解下去，所以在這里明確好角色和分工職責(zé)非常重要，角色界定不清晰也是時常影響到我們項目落地的一大因素。

任何一個項目技術(shù)評審均是必不可少的一環(huán)，在需求和任務(wù)拆解完畢后，分域做技術(shù)評審拉通上下游依賴做正式的review，可以發(fā)現(xiàn)在任務(wù)拆分或需求評審中所沒考慮到的細(xì)節(jié)，在前期將風(fēng)險扼殺在搖籃中，另外在做技術(shù)成本預(yù)估時一定要加上buffer時間，這個buffer時間可以按照以往的經(jīng)驗作為一個系數(shù)乘上去如0.3，因為方案評審并不能做到所有的細(xì)節(jié)一次性考慮周全，不要將自己的加班時間算進(jìn)去，這本身已經(jīng)是項目風(fēng)險。

技術(shù)評審需要哪些內(nèi)容：

1. 業(yè)務(wù)流程圖（基于業(yè)務(wù)視角你所在域的環(huán)節(jié)和用戶操作流程）

2. 技術(shù)框架圖（架構(gòu)或分層，可以了解到你所在域和周邊依賴）

3. 方案設(shè)計

4. 任務(wù)拆解&時間軸

5. 上下游依賴&風(fēng)險

項目管理中溝通是最重要的一個環(huán)節(jié)，啟動后最大的障礙就在交流溝通上，一個完整的項目會拆分為很多子域，每個子域間會有依賴，在信息傳達(dá)和處理中可能因為溝通不及時或者理解偏差導(dǎo)致方案設(shè)計的問題，如何把這些人聚集在一起項目室是個比較有效的解決方式，可以通過項目室在對項目執(zhí)行過程時，保持項目成員的溝通的有效性確保方案設(shè)計和理解一致。

建立周會和日會機(jī)制，按項目的不同階段運(yùn)行，在開發(fā)開始運(yùn)行時可以通過周會的方式，一周同步下當(dāng)前進(jìn)度和風(fēng)險以及下周重點(diǎn)計劃，確保項目按期執(zhí)行，運(yùn)行至中后期時需要開始日會機(jī)制，加強(qiáng)溝通交流，方便風(fēng)險和問題及時同步，會議的主要內(nèi)容可以按以下方式：

1. 今日主要做的事&整體進(jìn)度

2. 是否有風(fēng)險和依賴

3. 明日計劃

4. 昨天風(fēng)險是否接觸

風(fēng)險的主要來源很多，比如前期需求理解不一致、項目計劃不合理或需求變更等等，風(fēng)險是無法完全避免的，但我們可以通過歷史經(jīng)驗或項目管理來提前發(fā)現(xiàn)、最小化風(fēng)險，整個項目最核心的也就是這部分，風(fēng)險的大小和暴露的早晚會直接影響到這些項目是否順利，因此對于項目中暴露的問題需要保持足夠的敏銳度，遵循墨菲定律，另外加強(qiáng)溝通、管理和交流保持信息獲取的有效性。

在項目進(jìn)行到后期收尾階段，最大問題就是issue的fix和測試覆蓋是否齊全的問題，每個問題的修復(fù)可能都會暴露出新的問題，問題修復(fù)的越早，留個測試和項目的時間也會越足，因此在開發(fā)聯(lián)通提測前需要開始測試用例的梳理和評審，確保測試流程覆蓋度，在測試開始后需要關(guān)注問題的推進(jìn)和修復(fù)，盡量確保問題日清。

項目的最后一個環(huán)節(jié)就是驗收，驗收方式分2種，一種為組織會議預(yù)演，另外一種為推進(jìn)產(chǎn)品（業(yè)務(wù)）和視覺驗收（走查），第一種比較容易理解，即申請正式的會議拉上關(guān)聯(lián)項目組成員和業(yè)務(wù)同學(xué)做產(chǎn)品功能的預(yù)演，確保產(chǎn)品和業(yè)務(wù)理解一直以及功能完善，第二種則由產(chǎn)品和業(yè)務(wù)以及設(shè)計同學(xué)，分別以各自的域走查，確保視覺還原、產(chǎn)品邏輯、產(chǎn)品文案的一致性。

另外最重要的一點(diǎn)是項目方案如果涉及到新老版本交替時，一定要考慮到二者的兼容和對用戶的影響以及預(yù)案，避免影響用戶，如果是個block change那需要確保足夠的穩(wěn)定，用戶為第一優(yōu)先級

1. 過分悲觀 or 樂觀：這兩者均建立在對項目掌控度不夠的情況下，會導(dǎo)致對于項目的判斷失誤，過分悲觀會影響到項目組同學(xué)的積極性，反之會導(dǎo)致風(fēng)險暴露在后期。

2. 忽略細(xì)節(jié)：即墨菲定律，凡是覺得可能出錯或小概率出錯的事一定會出錯，當(dāng)review發(fā)現(xiàn)問題時需要深入到細(xì)節(jié)中了解和推進(jìn)，避免問題最終暴露在線上。

3. 信息斷層：跨團(tuán)隊項目中涉及的人較多，信息傳遞中因為不同的同學(xué)判斷和思考方式不一樣，導(dǎo)致最終你得到的信息可能是有誤或缺失的信息，需要多問多了解。

4. 考慮不全：每個人拋開項目PM都有自己原本的角色，比如前端、某某平臺開發(fā)，導(dǎo)致自己站位思考會下意識從當(dāng)前域去看，丟失了其他面，作為項目PM需要拋開自己的身份，站更廣的域思考。

5. 不敢取舍：項目啟動后因為外部各種因素感染導(dǎo)致項目的需求上變化，針對明確的項目目標(biāo)和計劃需要做好取舍，了解需求的本質(zhì)，敢于說不。

6. 前松后緊：不合理的規(guī)劃會導(dǎo)致項目陷入這種狀態(tài)，導(dǎo)致提測時問題過多，開發(fā)未自測質(zhì)量差等情況

下面的問題主要是個人見解不一定是最佳實(shí)踐，有好的其他答案歡迎回復(fù)。

• 換位：每個人每個Team都有自己規(guī)劃好的事，當(dāng)我們換位思考了解當(dāng)前依賴的團(tuán)隊目前的規(guī)劃和方向是怎樣，是否有周邊其他方向一致的合作伙伴，才能更和的切入推進(jìn)和合作

• 利他&共贏：這2個詞可以合成一個，做好一件事的前提條件一定是大家方向目標(biāo)一致，這樣才能長期正常的運(yùn)作下去，只有利他才能形成良好的運(yùn)作模式，拋開屁股意識尤為重要，避免短期利益，另外在找上下游尋求幫助前一定要提前想清楚他要什么？我能給什么？想不清楚建議在重新review是否找對人和做對事。

• 借勢：分2種情況，第一和當(dāng)前大團(tuán)隊或者集團(tuán)大的方向目標(biāo)捆綁，跟著大的背景驅(qū)動下前行；第二向上尋求幫助，個人的力量和可以調(diào)動的資源總歸有限，要學(xué)會向上管理尋求幫助

• 項目開始前：風(fēng)險往往發(fā)生在你所未關(guān)注的視角或者依賴的上下游部分，一個復(fù)雜的項目涉及的人和方案會較多，不同域方案不一樣一個人的精力總歸有限，這種情況下拆域化簡明確分工職責(zé)和接口人尤其重要，細(xì)分好域明確子域同學(xué)職責(zé)

• 項目中：”溝通“項目協(xié)同管理最核心的事，和子域負(fù)責(zé)人保持信息溝通交流，定期(日、周會等方式)對焦進(jìn)度和風(fēng)險，才能提早發(fā)現(xiàn)問題，另外避免只把自己局限在自己這塊域上，更深入的了解細(xì)節(jié)和技術(shù)方案才能比較好推進(jìn)，方案評估時對于時間節(jié)奏buffer才能掌控自如，以及提前發(fā)現(xiàn)風(fēng)險和推進(jìn)解決

• 項目上線時：作為項目最后一環(huán)較多問題主要為之前忽視偶現(xiàn)難排查問題以及未考慮應(yīng)急預(yù)案，遵循墨菲定律，你所未在意的問題可能成為壓倒這個項目的最后那根稻草，上線前多預(yù)演和準(zhǔn)備好check list以及預(yù)案手冊

任何一件事或項目光靠一份文檔是無法保障穩(wěn)定的，還是需要更多自己沉淀、積累以及跟進(jìn)，做的多了跟的緊了才能確保沒問題和沉淀自己的方法論，事在人為。

作者所屬團(tuán)隊：阿里淘系營銷活動前端團(tuán)隊，主導(dǎo)集團(tuán)超大型營銷活動雙11全球狂歡節(jié)，負(fù)責(zé)淘系電商每年幾千場營銷活動以及支撐這個體系的搭建技術(shù)產(chǎn)品，服務(wù)千級運(yùn)營，萬級商家，億級消費(fèi)者，提供如絲般順滑的線上購物瀏覽體驗。

歡迎有志之士加入，簡歷投遞[email protected] 注明【簡歷】

關(guān)注數(shù)：10億+?文章數(shù)：10億+
粉絲量：10億+?點(diǎn)擊量：10億+
?
懸賞博主專區(qū)請掃描這里

喜愛數(shù)：?1億+?發(fā)帖數(shù)：?1億+
回帖數(shù)：?1億+?結(jié)貼率：?99.9%

—————END—————


喜歡本文的朋友，歡迎關(guān)注公眾號?程序員哆啦A夢，收看更多精彩內(nèi)容
點(diǎn)個[在看]，是對小達(dá)最大的支持！

如果覺得這篇文章還不錯，來個【分享、點(diǎn)贊、在看】三連吧，讓更多的人也看到~