[[94459]]

最近我們重新規(guī)劃和設(shè)計敏捷項目總體流程，對需求伊始直至項目上線的目標(biāo)、指標(biāo)、時間節(jié)點(diǎn)和責(zé)任人都做了定義。但當(dāng)我們制定更詳細(xì)的計劃時，發(fā)現(xiàn)一個嚴(yán)重的問題：這是一個“夢幻日程計劃”。在項目生命周期管理的探索與實(shí)踐上，我們經(jīng)歷過瀑布式、迭代式、增量式以及混合的Scrum敏捷式，如果只針對項目管理而言，我相信在一個Sprint周期內(nèi)，做到“一切盡在掌握”是可行的，但放眼至一個季度甚至半年的最終目標(biāo)上，夢幻計劃的完美主義的思想又成為了另一個極端。

為了讓計劃更加務(wù)實(shí)，我們需要采用盡可能短的時間盒管理項目，2周是一個理想并充滿挑戰(zhàn)的周期，但我們相信只要控制好Sprin就t可以實(shí)現(xiàn)它。

從遠(yuǎn)期看，我們的產(chǎn)品上線目標(biāo)和最終運(yùn)營目標(biāo)都充滿挑戰(zhàn)，并且時間只剩半年。為了讓不可能的任務(wù)更有說服力，我嘗試著制定整整6個月的計劃，但計劃剛剛開始我就結(jié)束了這個愚蠢的想法 ——未來的Idea充滿了未知。雖然scrum敏捷能帶給我們更強(qiáng)的控制力，但從產(chǎn)品創(chuàng)建的生命周期看，2周時間盒顯然給需求的產(chǎn)出帶來了極大的困擾：如果需求的定義僅限2周，只有鬼知道這兩周的量能否滿足下一個項目Sprint的胃口，這還沒有考慮不同功能和需求的大小。一個用戶體驗改 進(jìn)與一個成長體系的需求量，放在兩個同樣長度的時間盒顯然是不公平的，更何況產(chǎn)品經(jīng)理還需要對頁面設(shè)計、制作進(jìn)行協(xié)調(diào)以及參與Spring周期結(jié)束時的部署驗收。

在一個復(fù)雜又充滿挑戰(zhàn)的項目中，為了避免這個問題，同時又發(fā)揮Scrum敏捷式項目管理的優(yōu)點(diǎn)，可以采取“供應(yīng)鏈管式項目管理”方法。

在傳統(tǒng)制造業(yè)企業(yè)中，為了保證生產(chǎn)的穩(wěn)定，制造商會有一定的原材料庫存。但隨著供應(yīng)鏈管理思想的深入發(fā)展，越來越多的制造商整合供應(yīng)鏈資源，與供應(yīng)商共同管理庫存，以確保在生產(chǎn)最經(jīng)濟(jì)的情況下滿足市場的變化，即“柔性供應(yīng)鏈”。

在互聯(lián)網(wǎng)項目管理中，可以簡單的抽象需求、設(shè)計、頁面制作為供應(yīng)商，總設(shè)、開發(fā)、測試為制造商，庫存即“待開發(fā)需求池”。與傳統(tǒng)制造業(yè)不同的是， 互聯(lián)網(wǎng)項目團(tuán)隊可以簡化為2個供應(yīng)鏈中的節(jié)點(diǎn)，供應(yīng)商為制造商提供生產(chǎn)原材料，制造商將其加工測試后交付給市場。

[[94460]]

相比Scrum敏捷式項目管理，供應(yīng)鏈?zhǔn)巾椖抗芾韽?qiáng)調(diào)了“庫存”的價值，產(chǎn)品需要在下一個時間盒開始前保持“待開發(fā)需求池”的水量；開發(fā)需要確保能夠及時消耗掉庫存中的Backlog。 這使得團(tuán)隊成員的注意力更容易集中在最重要的部分（設(shè)計或者開發(fā)），而不是無效率的溝通。換句話說，傳統(tǒng)的Scrum項目管理的流程更像是一條大河，上游需要確保充足穩(wěn)定的水量以確保下游的承受能力；下游需要保持足夠的消化能力以避免洪水泛濫或者干涸。供應(yīng)鏈?zhǔn)降捻椖抗芾砭褪窃诤拥郎辖ㄆ鹆艘蛔髩危灰ＷC水庫中的水在安全范圍以內(nèi)，無論洪峰還是大旱（需求暴增或需求銳減），下游生產(chǎn)都可以確保 安全與效率。管理的焦點(diǎn)可以集中在“待開發(fā)需求池”的安全范圍以及優(yōu)先級。

供應(yīng)鏈?zhǔn)巾椖抗芾硎歉暧^的管理，它闡述了產(chǎn)品管理與項目管理的上下游關(guān)系。純粹的Scrum可能更適合老外那種程序員也是產(chǎn)品經(jīng)理的創(chuàng)業(yè)作風(fēng)，我看過幾乎所有被奉為圣經(jīng)的項目管理書籍都將定義需求作為一個項目的起始，這表面看起來無比正確，卻如同雞肋般既沒有說清楚如何定義需求（推薦《用戶體驗的要素》），又給國內(nèi)的項目經(jīng)理和程序員造成了困擾。

產(chǎn)品（供應(yīng)商）：

產(chǎn)品從“需求池”到“待開發(fā)需求池Backlog”，需要經(jīng)歷線框圖、需求文檔、頁面設(shè)計、頁面制作4個環(huán)節(jié)，產(chǎn)品設(shè)計的迭代由產(chǎn)品經(jīng)理全權(quán)負(fù)責(zé)，在需求池挑選高優(yōu)先級的目標(biāo)，設(shè)計并交付最終完整需求至待開發(fā)需求池中，需求需要以“情景故事”為單位打包，并區(qū)分優(yōu)先級；需求包的優(yōu)先級需要滿足正態(tài)分布曲線，如水庫在每個Spring開始前，安全范圍為5-15個情景故事，當(dāng)有10個故事時，2個優(yōu)先級為1，6個優(yōu)先級為2，2個優(yōu)先級為3。

技術(shù)（制造商）：

技術(shù)在下一個時間盒迭代開始前一周，由項目經(jīng)理根據(jù)團(tuán)隊承受能力與產(chǎn)品共同確認(rèn)Sprint Backlog，并立即進(jìn)行需求和用例評審。一旦范圍確定，即可立即展開項目（在需求線框圖出來后，測試與架構(gòu)師就可以介入開展前期工作了），并用燃盡圖等工具進(jìn)行監(jiān)控。后面只需要保持好節(jié)奏，相信掌控項目的感覺會讓你身心舒暢。

我并不清楚供應(yīng)鏈?zhǔn)巾椖抗芾硭枷胧欠裼腥诉M(jìn)行過類似嘗試，它的本質(zhì)是對敏捷項目時間盒內(nèi)的需求與開發(fā)進(jìn)行解耦，需要需求提前至少一個時間盒完成并冗余在待開發(fā)需求池內(nèi)，把為了增強(qiáng)項目控制力而壓縮的2周Sprint還給項目程序員和測試工程師。它的困難在于，需求為了保證待開發(fā)需求池的安全范圍而必須承擔(dān)足夠的壓力，還好我相信這種壓力是我們可以承受的。

這只是一個產(chǎn)品經(jīng)理對項目管理的思路，實(shí)踐后會進(jìn)一步總結(jié)，如果你有更好的主意，歡迎與我分享。

原文鏈接：http://www.hanjunxing.com/supply-chain-project-management