《網易一千零一晚上》項目管理之高度延伸

項目啓動階段

團隊組建

這種狀況主要發生在職能劃分的研發團隊，各個研發成員按照資源池的形式劃分。雖然需求來時，各個職能的tl都會答應，但實際人員到位狀況以及支持力度遠遠不夠，極可能致使最後延期。

措施： 拉各個職能的一把手開會，當場肯定好支持的人員以及到位時間；若是其不能當場確認，也要下班前給出回覆。而且，在每一個時間節點開始和結束的節點親自進行確認。

備註： 在有些靈活的創業團隊，需求的負責人和開發團隊的組織也是比較靈活的，所以也須要掌握這點常識。

自我受權

不少時候，領導喜歡給咱們工做，卻又不明確受權，而咱們去跟各個方面接洽溝通的時候，又不得不解釋，本身不能順利、徹底發揮本身的能力和工做內容。

措施： 把領導以及相關人叫齊，正式聲明本身的工做職責、工做內容，你們要全力配合。其中不要過於擔憂自我受權後，某些工做作很差，這畢竟是一個過程，沒有誰開始就能作好。

備註：另外，要區分好，自我受權與給title的區別。不能否認有些工做是必須某些崗位或者等級才能作的，但領導可能以爲你等級還不夠，想讓你鍛鍊下，合格了再給title。也能夠理解，但那只是個title，自我受權仍是必要的。若是不去主動正式聲明本身的工做內容和工做職責，就會名不正言不順。

需求可視化

這個主要出如今過程的弱管理上，沒有敏捷的場景。由於開發老是預估一個模糊時間點，項目經理因而只有節點去問，完成了倒還好，沒完成的狀況和緣由有不少，致使項目不可控。而若是中間去問，開發人員又給不出準確的進度狀況。

措施：需求可視化，把一件事提上日程，天天計劃作什麼，天天過進度，今天應該完成的進度是什麼，今天作了什麼，明天作什麼，最好白板的方式公示。這樣明確之後，誰比較忙，誰比較空，哪一個需求提早，哪一個需求延後了很是清楚，這就是可視化，小顆粒度的項目過程控制。固然瞭解的人可能會說這不就是敏捷麼？對敏捷的特色之一就是需求可控可視，當你的團隊不能完整的實現敏捷的時候，在需求控制上實現可視化也是可行方案。這比要求你們發日報、週報來的有效的多，固然若是你的領導想知道項目進度，能夠由項目經理進行整理相關節點和進度進行上報，沒有必要每一個人都去寫。

固定溝通渠道

在項目的需求討論以及研發過程當中，你們都是傾向於不回答、不討論的，尤爲人不少或者回答也沒有意義的時候。這種在研發團隊司空見慣，待久了，你們都會以爲這個團隊沒有發展空間，沒有成長和溝通的土壤。

措施：必定要主動的去問，去了解，最好一對一的去問每一個人的見解和建議，去徵求大多數人喜歡溝通的方式，創建有效的週期性討論。若是有一天別人回答的你不多，那麼有兩種可能：1 根本不想和你溝通，由於不能互相理解或者由於即便溝通有了觀點也沒有下文 ；2 在本身的認知和能力內，已經對當前的團隊和產品沒有什麼大的建議了。固然大多數狀況下，其實屬於第一種。

備註：其實固定溝通渠道，只不過爲團隊打開反饋的窗口，至因而否真的要執行週期性討論，取決於團隊真實意願和需求。有一點不得不提的是，真正重要的是團隊的氛圍，要珍惜並重用每一個人的見解和能力，讓他們有機會說，有機會作，甚至有機會主導。這樣，這個措施的目的纔是真正的達到。

產品初創階段

項目如何走向正軌

如何保證需求遇上工期

備註：特別說明關鍵路徑法，也是項目管理中的重要常識，就是找出影響項目主要進度的主要需求，進行需求的拆解、資源調配，來減小工期。

溝通方式

溝通方式	說明	效果
樹型	從上到下，層級的溝通	鏈路最長，效果很差
拓撲	同級負責人溝通，再向下溝通	鏈路取中，比較依賴負責人的狀態
動態拓撲	不一樣職能指定特定負責人，再向下溝通	鏈路取中，比較靈活
網狀拓撲	任何職能，任何等級的均可以互相溝通	鏈路最短，效果最差，最靈活，只有在部門小或者某些小事情上能夠如此

總結：公司級別的決策以及下發都建議樹型溝通；平常公司的運行建議普通拓撲；一些具體項目的推動實施，能夠動態拓撲；細節的雜事，反饋機制，能夠考慮網狀拓撲。

敏捷教練類型

編寫中。。。