本文是關(guān)于作者在To B 項目敏捷開發(fā)的一點個人心得，希望能對處于相同環(huán)境的朋友提供一點參考，一起來文中看看~

通過盡早和不斷交付有價值的軟件滿足客戶需要——敏捷宣言。

筆者于2015年第一次接觸敏捷開發(fā)且第一次碰觸Scrum，當(dāng)時scrum的理念確實為筆者的打開了一扇開發(fā)的窗，但結(jié)合自身境遇，仔細(xì)分析后認(rèn)定敏捷比較適合于做內(nèi)部的產(chǎn)品，不適合做ToB解決方案型項目（以下簡稱Tob項目），原因如下：

1. 立場：Tob項目甲乙雙方關(guān)系為被服務(wù)與服務(wù)的關(guān)系，甲方希望最少成本做最多的事，節(jié)約成本，乙方希望項目可以利潤最大化，提高收益。
2. 背景：ToB項目甲方期初需要經(jīng)歷項目可行性研究、項目立項、項目評審等過程，前后需準(zhǔn)備大量的描述材料，如果實施結(jié)果與預(yù)期目標(biāo)偏差過大，會被審計組審計。同時，也會對項目申請人的能力產(chǎn)生質(zhì)疑，因此客戶的建設(shè)理念往往傾向于傳統(tǒng)瀑布模式，注重交付成果的一致性。
3. 合同：ToB項目以固定總價合同模式居多，固定總價合同前期就有明確的范圍、進(jìn)度、成本、交付成果等要求。
4. 觀點：ToB項目團隊往往會由甲乙雙方共同組成，雙方背后都有不同的利益組織，因此觀點比較復(fù)雜，針對共同目標(biāo)雙方患難與共，但同時又因各為其主，會在一些細(xì)節(jié)上產(chǎn)生分歧，尤其是在變更的時候，因為會涉及到成本、進(jìn)度等要素，弄得每一次變更都像打架一樣。
5. 傾注：ToB項目建設(shè)往往由甲方業(yè)務(wù)方申請，IT部門承建，受益人與負(fù)責(zé)人不為同一人，由于利益、職責(zé)不同，甲方負(fù)責(zé)人的投入熱忱也不盡相同。

因此ToB解決方案型項目使用敏捷模式可謂如履薄冰，稍有不慎便有需求蔓延、影響交付的風(fēng)險。

2018年1月，筆者所在的公司承接了某地產(chǎn)龍頭的云視頻平臺建設(shè)項目，該集團信息化事業(yè)部有著比較豐富的項目建設(shè)經(jīng)驗，本項目為總價合同模式，預(yù)計建設(shè)周期9個月，合同簽定之初甲方項目總監(jiān)就要求項目快速上線，盡早滿足該集團業(yè)務(wù)訴求，優(yōu)惠條件是項目組可以不用駐場開發(fā)（筆者所在公司與項目現(xiàn)場相隔千里）。

筆者權(quán)衡再三，與甲方約定項目采用敏捷開發(fā)模式，并且達(dá)成了具體落地方法，具體如下：

一、架構(gòu)職責(zé)

架構(gòu)職責(zé)：由甲方項目總監(jiān)、產(chǎn)品經(jīng)理、乙方項目經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)經(jīng)理、測試經(jīng)理組成項目核心團隊。

1. 甲方項目總監(jiān)：負(fù)責(zé)甲方整體項目把控工作；
2. 甲方項目經(jīng)理：負(fù)責(zé)需求篩選，優(yōu)先級排序，協(xié)調(diào)甲方技術(shù)、業(yè)務(wù)人員配合本項目建設(shè)等工作；
3. 乙方項目經(jīng)理：負(fù)責(zé)編寫WBS、編制項目計劃、信息同步、風(fēng)險跟蹤等工作；
4. 乙方產(chǎn)品經(jīng)理：負(fù)責(zé)需求收集、梳理、分析、原型制作、需求確認(rèn)、改進(jìn)方案等工作；
5. 乙方技術(shù)經(jīng)理：負(fù)責(zé)構(gòu)建系統(tǒng)架構(gòu)、指導(dǎo)開發(fā)、外部接口對接、重點問題攻堅工作等工作；
6. 乙方測試經(jīng)理：負(fù)責(zé)組織測試規(guī)劃、方案、用例、BUG管理、培訓(xùn)等工作。

二、拆分階段

拆分階段：將原9個月的建設(shè)周期拆分成三個階段，即每三個月一個大階段，每階段里再拆分成3個小迭代，每個小迭代均提供有價值的交付物。

1. 每個大階段提前三周做需求收集、需求分析、需求排序等工作，規(guī)劃好本階段的工作內(nèi)容，以及完成第一個小迭代的交互稿細(xì)化；
2. 每個小迭代前兩周做需求收集、需求分析、需求排序、交互稿細(xì)化等工作；
3. 每個小迭代內(nèi)如無特殊情況，不做項目變更；
4. 第一個階段不做小迭代拆分（建設(shè)初期初始化的事情太多：如確定需求基線、整體架構(gòu)設(shè)計、硬件資源、網(wǎng)絡(luò)資源、域名、安全檢查、各種評審以及新團隊成員組建磨合等）；

三、溝通模式

1. 溝通模式：現(xiàn)場會議、電話會議、IM、郵件等。
2. 項目周報：郵件形式面向項目組全體成員，每周一次。
3. 會議紀(jì)要：郵件形式面向項目組與會人員及雙方領(lǐng)導(dǎo)，每次會議。
4. 階段成果確認(rèn)：郵件形式面向?qū)?yīng)負(fù)責(zé)人及雙方領(lǐng)導(dǎo)，每階段。
5. 乙方內(nèi)部敏捷溝通模式：站會、周會、回顧會。
6. 各大階段前兩周，甲乙雙方當(dāng)面交流，一般交流周期為一周（很重要?。?/li>

四、需求范圍

需求范圍：以需求規(guī)格說明書為需求基線，并輔以需求變更單.

1. 以需求規(guī)格說明書為需求基線；
2. 需求收集、需求分析、需求排序階段甲乙雙方共同參與，并達(dá)成共識；
3. 統(tǒng)一思想，擁抱變更，重點強調(diào)本項目會有較多變更，大家心里上一定要認(rèn)同這一點，當(dāng)出現(xiàn)變更時，雙方一同分析變更影響（含工作量、工期、建設(shè)節(jié)奏等），達(dá)成共識后，迅速對變更需求給予確認(rèn)；

在雙方達(dá)成共識的基礎(chǔ)上，該項目基本按即定計劃執(zhí)行，項目整體提前1個月，即用時8個月建設(shè)完成，在完成的同時也整理一下個人的心得。

1. 互信：互信非常重要，本項目由于分小迭代上線，在對最終用戶需求做出及時反饋的同時，項目組也面對著大量的變更，是否符合變更，變更工作量多少均達(dá)成共識，雖然大家是為一個項目服務(wù)，但背后利益群體不同，達(dá)成互信非常不易；
2. 互助：本項目在建設(shè)的過程中除遇到變更外，因甲方客觀情況需要，曾嘗試過雙周迭代，項目組很好的滿足了甲方高層級的業(yè)務(wù)需求，雙方的友誼更進(jìn)了一步；
3. 互補：甲方項目經(jīng)理出身產(chǎn)品設(shè)計，本項目中兼了甲方產(chǎn)品經(jīng)理和甲方項目經(jīng)理兩個職務(wù)，由于項目管理經(jīng)驗和技術(shù)能力相對薄弱，項目組會對該項目經(jīng)理給予一定的幫助，一同面對項目中的問題，幫助其快速成長，該項目經(jīng)理成長后，在很大程度上對項目起了推動作用；
4. 迅速確認(rèn)：由于本項目有大量的變更，為防止這些變更遺漏、事后無法追述等情況，在確定變更后，雙方迅速確認(rèn)；同時，階段性成果也要迅速確認(rèn)；
5. 節(jié)奏：本項目直接參與建設(shè)人員平均人數(shù)為30人，峰值時達(dá)到45人左右，如何保障大團隊能一直高效的工作，節(jié)奏很重要，項目組通過提前規(guī)劃需求、提前出交互稿的形式，使大團隊每輪迭代后均后新任務(wù)執(zhí)行；
6. 不足：ToB項目，尤其是首次合作的ToB項目，項目的約束條件會很多，干系人溝通渠道的很大，需要用大量的時間來識別及應(yīng)對，而此時實現(xiàn)短期項目上線，進(jìn)度風(fēng)險特別大，本項目第一階段就因溝通不夠充分，導(dǎo)致延期上線一周。

最后，此次項目雖然通過敏捷的方式取得了成功，但個人總結(jié)ToB項目在總價合同的模式下，想要實現(xiàn)敏捷必須要具備以下幾點要素：

1. 甲方IT建設(shè)的成熟度要高；
2. 雙方理解并認(rèn)同敏捷的模式；
3. 甲方會對本項目做出大量的建設(shè)投入；
4. 乙方項目經(jīng)理要有很好的控場能力，并且對項目的走向有一定的前瞻能力。

以上為我在To B 項目敏捷開發(fā)的一點個人心得，希望能對處于相同環(huán)境的朋友提供一點參考。

作者：王磊，就職于網(wǎng)易杭研項目管理部，擔(dān)任交付項目管理職位，致力于團隊的大客項目交付及流程持續(xù)優(yōu)化。

本文由 @網(wǎng)易杭研項目管理（微信公眾號：NetEasePM） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議

愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺；

想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）