供應(yīng)鏈?zhǔn)巾?xiàng)目管理
最近我們重新規(guī)劃和設(shè)計(jì)敏捷項(xiàng)目總體流程，對(duì)需求伊始直至項(xiàng)目上線的目標(biāo)、指標(biāo)、時(shí)間節(jié)點(diǎn)和責(zé)任人都做了定義。但當(dāng)我們制定更詳細(xì)的計(jì)劃時(shí)，發(fā)現(xiàn)一個(gè)嚴(yán)重的問題：這是一個(gè)“夢(mèng)幻日程計(jì)劃”。在項(xiàng)目生命周期管理的探索與實(shí)踐上，我們經(jīng)歷過瀑布式、迭代式、增量式以及混合的Scrum敏捷式，如果只針對(duì)項(xiàng)目管理而言，我相信在一個(gè)Sprint周期內(nèi)，做到“一切盡在掌握”是可行的，但放眼至一個(gè)季度甚至半年的最終目標(biāo)上，夢(mèng)幻計(jì)劃的完美主義的思想又成為了另一個(gè)極端。
為了讓計(jì)劃更加務(wù)實(shí)，我們需要采用盡可能短的時(shí)間盒管理項(xiàng)目，2周是一個(gè)理想并充滿挑戰(zhàn)的周期，但我們相信只要控制好Sprin就t可以實(shí)現(xiàn)它。
|
項(xiàng)目自始至終周期過長(zhǎng)，會(huì)造成心理放松，對(duì)于項(xiàng)目危機(jī)感缺失，以至于造成前期浪費(fèi)時(shí)間，后期加班趕時(shí)間的窘相。所以我們需要通過不斷地迭代，在一次次循環(huán)中完成可交付的增量，基于事實(shí)的決策遠(yuǎn)比前端預(yù)測(cè)型決策更為有效。——Reinhardt |
從遠(yuǎn)期看，我們的產(chǎn)品上線目標(biāo)和最終運(yùn)營(yíng)目標(biāo)都充滿挑戰(zhàn)，并且時(shí)間只剩半年。為了讓不可能的任務(wù)更有說服力，我嘗試著制定整整6個(gè)月的計(jì)劃，但計(jì)劃剛剛開始我就結(jié)束了這個(gè)愚蠢的想法 ——未來的Idea充滿了未知。雖然scrum敏捷能帶給我們更強(qiáng)的控制力，但從產(chǎn)品創(chuàng)建的生命周期看，2周時(shí)間盒顯然給需求的產(chǎn)出帶來了極大的困擾：如果需求的定義僅限2周，只有鬼知道這兩周的量能否滿足下一個(gè)項(xiàng)目Sprint的胃口，這還沒有考慮不同功能和需求的大小。一個(gè)用戶體驗(yàn)改 進(jìn)與一個(gè)成長(zhǎng)體系的需求量，放在兩個(gè)同樣長(zhǎng)度的時(shí)間盒顯然是不公平的，更何況產(chǎn)品經(jīng)理還需要對(duì)頁(yè)面設(shè)計(jì)、制作進(jìn)行協(xié)調(diào)以及參與Spring周期結(jié)束時(shí)的部署驗(yàn)收。
在一個(gè)復(fù)雜又充滿挑戰(zhàn)的項(xiàng)目中，為了避免這個(gè)問題，同時(shí)又發(fā)揮Scrum敏捷式項(xiàng)目管理的優(yōu)點(diǎn)，可以采取“供應(yīng)鏈管式項(xiàng)目管理”方法。
在傳統(tǒng)制造業(yè)企業(yè)中，為了保證生產(chǎn)的穩(wěn)定，制造商會(huì)有一定的原材料庫(kù)存。但隨著供應(yīng)鏈管理思想的深入發(fā)展，越來越多的制造商整合供應(yīng)鏈資源，與供應(yīng)商共同管理庫(kù)存，以確保在生產(chǎn)最經(jīng)濟(jì)的情況下滿足市場(chǎng)的變化，即“柔性供應(yīng)鏈”。
在互聯(lián)網(wǎng)項(xiàng)目管理中，可以簡(jiǎn)單的抽象需求、設(shè)計(jì)、頁(yè)面制作為供應(yīng)商，總設(shè)、開發(fā)、測(cè)試為制造商，庫(kù)存即“待開發(fā)需求池”。與傳統(tǒng)制造業(yè)不同的是， 互聯(lián)網(wǎng)項(xiàng)目團(tuán)隊(duì)可以簡(jiǎn)化為2個(gè)供應(yīng)鏈中的節(jié)點(diǎn)，供應(yīng)商為制造商提供生產(chǎn)原材料，制造商將其加工測(cè)試后交付給市場(chǎng)。
相比Scrum敏捷式項(xiàng)目管理，供應(yīng)鏈?zhǔn)巾?xiàng)目管理強(qiáng)調(diào)了“庫(kù)存”的價(jià)值，產(chǎn)品需要在下一個(gè)時(shí)間盒開始前保持“待開發(fā)需求池”的水量；開發(fā)需要確保能夠及時(shí)消耗掉庫(kù)存中的Backlog。 這使得團(tuán)隊(duì)成員的注意力更容易集中在最重要的部分（設(shè)計(jì)或者開發(fā)），而不是無效率的溝通。換句話說，傳統(tǒng)的Scrum項(xiàng)目管理的流程更像是一條大河，上游需要確保充足穩(wěn)定的水量以確保下游的承受能力；下游需要保持足夠的消化能力以避免洪水泛濫或者干涸。供應(yīng)鏈?zhǔn)降捻?xiàng)目管理就是在河道上建起了一座大壩，只要保證水庫(kù)中的水在安全范圍以內(nèi)，無論洪峰還是大旱（需求暴增或需求銳減），下游生產(chǎn)都可以確保 安全與效率。管理的焦點(diǎn)可以集中在“待開發(fā)需求池”的安全范圍以及優(yōu)先級(jí)。
供應(yīng)鏈?zhǔn)巾?xiàng)目管理是更宏觀的管理，它闡述了產(chǎn)品管理與項(xiàng)目管理的上下游關(guān)系。純粹的Scrum可能更適合老外那種程序員也是產(chǎn)品經(jīng)理的創(chuàng)業(yè)作風(fēng)，我看過幾乎所有被奉為圣經(jīng)的項(xiàng)目管理書籍都將定義需求作為一個(gè)項(xiàng)目的起始，這表面看起來無比正確，卻如同雞肋般既沒有說清楚如何定義需求（推薦《用戶體驗(yàn)的要素》），又給國(guó)內(nèi)的項(xiàng)目經(jīng)理和程序員造成了困擾。
產(chǎn)品（供應(yīng)商）：
產(chǎn)品從“需求池”到“待開發(fā)需求池Backlog”，需要經(jīng)歷線框圖、需求文檔、頁(yè)面設(shè)計(jì)、頁(yè)面制作4個(gè)環(huán)節(jié)，產(chǎn)品設(shè)計(jì)的迭代由產(chǎn)品經(jīng)理全權(quán)負(fù)責(zé)，在需求池挑選高優(yōu)先級(jí)的目標(biāo)，設(shè)計(jì)并交付最終完整需求至待開發(fā)需求池中，需求需要以“情景故事”為單位打包，并區(qū)分優(yōu)先級(jí)；需求包的優(yōu)先級(jí)需要滿足正態(tài)分布曲線，如水庫(kù)在每個(gè)Spring開始前，安全范圍為5-15個(gè)情景故事，當(dāng)有10個(gè)故事時(shí)，2個(gè)優(yōu)先級(jí)為1，6個(gè)優(yōu)先級(jí)為2，2個(gè)優(yōu)先級(jí)為3。
技術(shù)（制造商）：
技術(shù)在下一個(gè)時(shí)間盒迭代開始前一周，由項(xiàng)目經(jīng)理根據(jù)團(tuán)隊(duì)承受能力與產(chǎn)品共同確認(rèn)Sprint Backlog，并立即進(jìn)行需求和用例評(píng)審。一旦范圍確定，即可立即展開項(xiàng)目（在需求線框圖出來后，測(cè)試與架構(gòu)師就可以介入開展前期工作了），并用燃盡圖等工具進(jìn)行監(jiān)控。后面只需要保持好節(jié)奏，相信掌控項(xiàng)目的感覺會(huì)讓你身心舒暢。
我并不清楚供應(yīng)鏈?zhǔn)巾?xiàng)目管理思想是否有人進(jìn)行過類似嘗試，它的本質(zhì)是對(duì)敏捷項(xiàng)目時(shí)間盒內(nèi)的需求與開發(fā)進(jìn)行解耦，需要需求提前至少一個(gè)時(shí)間盒完成并冗余在待開發(fā)需求池內(nèi)，把為了增強(qiáng)項(xiàng)目控制力而壓縮的2周Sprint還給項(xiàng)目程序員和測(cè)試工程師。它的困難在于，需求為了保證待開發(fā)需求池的安全范圍而必須承擔(dān)足夠的壓力，還好我相信這種壓力是我們可以承受的。
這只是一個(gè)產(chǎn)品經(jīng)理對(duì)項(xiàng)目管理的思路，實(shí)踐后會(huì)進(jìn)一步總結(jié)，如果你有更好的主意，歡迎與我分享。
原文鏈接：http://www.hanjunxing.com/supply-chain-project-management
