圍，你的SOW和WBS可能也寫得很詳盡。但此刻，你的團隊里只有2個后端開發(fā)人員，沒有前端工程師和數(shù)據(jù)庫開發(fā)工程師，也沒有測試人員來保證項目的質量。這是一個多么悲傷的話題啊，就像你選定了要演奏的曲目，確定了音樂會的時間和場地，但僅有2個音樂師能夠出席。所以，那個音樂指揮家揮舞著指揮棒在想，可不可以把這場音樂演奏會變成音樂獨奏會?
這樣的情況下，你依然需要淡定地把項目方案建議書和需求規(guī)格說明書重新審視一遍。結合用戶需求思考和權衡，哪些功能是目前比較關注的，而哪些功能是未來系統(tǒng)需要關注的。這個其實并不難，如果你和用戶開放地溝通過，項目功能的輕重緩急，你應該心里有數(shù)。所以，你很有必要在此基礎之上，整理出項目當前階段的需求規(guī)格說明書來。不要一味地喊叫資源不足，這樣的方式只會引起領導對你做事能力的懷疑，而不能解決根本問題。
5、確定核心功能的優(yōu)先級
關于個人工作效率的經(jīng)典之作《高效能人士的七個習慣》一書里依據(jù)縱坐標(重要性)和橫坐標(緊急性)來劃分任務，有如下四種組合：
(1)重要且緊急，迅猛龍式出擊。
(2)重要但不緊急, 準備好未來的方案、策略和計劃。
(3)不重要但緊急，學會說不，拒絕任何承諾。
(4)不重要也不緊急，可以研究下隔壁的妹紙為何每次遇見你都會笑得很好看。
一個大型的項目，利益相關方會很多。常常會有很多年輕而對項目管理知識無知的利益相關方從方便個人利益的角度出發(fā)，突然過來很莫名地給你講，XX報表要放在你的系統(tǒng)里實現(xiàn)而且某大領導非常重視。這時，你需要做的就是果斷拒絕，不要給任何承諾。很明顯，這是不重要也不緊急的事情。因為凡是重要且緊急的任務，領導都會在需求討論會上明確地強調多次。項目經(jīng)理心里要有一桿秤，哪些人的需求是需要理會的，哪些人的需求是不用過多關注的。
整理完核心功能和關鍵任務的優(yōu)先級列表后，你會發(fā)現(xiàn)項目一半的范圍進行了裁剪。這是一個好的趨勢和結果，因為縮減和明確項目范圍永遠對項目的如期交付是有利的。而一個項目的實施，10個人有10個人的計劃和結果，2個人也有2個人的計劃和結果。當你無法爭取標配的資源獲得對這個項目的足夠支持時，只能關注核心功能并在核心功能范圍內進行任務的優(yōu)先級排序。
6、制定可行的迭代計劃
迭代這個詞現(xiàn)在很泛濫，但很多人都不明白需要迭代什么。項目經(jīng)理首先要明確，在這些核心功能清單中，哪些是需要放在持續(xù)的迭代計劃當中的。不是項目所有的功能都需要迭代，成熟的功能基本都是一次開發(fā)就落地實現(xiàn)，如果你說要迭代設計登陸和退出功能就顯得非常逗比和無知。通常需要迭代的任務都是那些比較復雜的，業(yè)界技術不是很明確或者用戶未來期望也不是很明確的功能，比如權限體系、報表體系等。
迭代周期不要過短(團隊Hold不住，時間都會浪費在代碼分支合并沖突檢測、各種測試、Bug修復、上線發(fā)布中)，也不要太長(否則失去了敏捷開發(fā)的意義)，為了給不成熟的團隊留出充分的容錯時間，所以需要具體情況具體分析。這時作為項目經(jīng)理的你，需要和開發(fā)人員探討每個里程碑的實現(xiàn)程度。
7、設計前瞻的系統(tǒng)架構
如果你有幸遇到一個有全局觀、有前瞻性的系統(tǒng)架構師，項目會順利很多。系統(tǒng)的架構就像交通工具的骨骼，你需要和架構師進行密切的溝通。開發(fā)未動、架構先行的準則是保證系統(tǒng)未來不會宕機和崩潰的重要準則。所以你不要期望“老牛破車”的架構和框架之上，能繼續(xù)朝里面添加或者迭代什么功能，也不要指望它能夠跑得有多快、有多遠。甚至，更多的可能是，你在項目功能進行迭代的時候，