起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識當項目管理遇上最后期限，我們可以做些什么？
老大說，我們要做個新功能。還沒定下來到底做成啥樣，就已經定了個上線時間，還是個不可能的最后期限。所以，直接倒退時間就得了，還做啥估算啊，然并卵啊。這場景好熟啊！不過，辦法總比問題多。當項目管理遇上最后期限時，我們可以做些什么？與您分享時間管理的百寶箱。
時間管理百寶箱
在拿出工具寶貝之前，咱們先講個基礎項目管理概念，那就是項目管理鐵三角：時間——范圍——質量。最后交付的產品，由這三個方面組合決定。而這三個方面，本身又是此消彼長的關系，比如，削減項目時間，勢必帶來產品范圍的削減或者質量的下降。
因此，首要的是明確對產品來說，這三個維度的重要性排序，也就是產品最看重的到底是按期交付、還是穩定的質量、還是確定的范圍？這樣，在遇到時間管理問題時，我們才能對百寶箱中的工具做取舍，來選擇最合適項目的工具。
我們以緊急項目A為例進行具體討論。
百寶工具0. 真的是最后期限嗎？
我們習慣于被給定一個命題，而不去質疑這個命題是否成立。無論是否能夠改變命題，我們至少應該問一下“為什么”。并且可以嘗試去做一些爭取，了解所謂的“保守底線”和“真實底線”。大多數合作項目中，看起來需求方設定的交付時間是最后期限，但溝通具體的方案以及實際用途后，往往會發現是有余地的。不爭取，你怎么知道那就是“最后”的期限呢？
百寶工具1. 負荷度
在我們準備任何時間管理措施之前，我們需要先來看看團隊目前的工作負荷。如果大家都處于相對寬松的工作負荷情況下，我們一上來就開始砍范圍壓質量，顯然沒有說服力。但是，要讓大家開始齊心協力開始奮斗，也不是項目經理一兩句話就能鼓搗起來的。
我們曾經提過“透明”的力量。
所謂“透明”，就是從項目背景、目標，到項目計劃、進度過程、風險問題等信息，都和團隊共享。了解了項目的重要性和緊迫性，看到了具體的項目計劃，實時了解了我們的進度位置以及和計劃的偏差，很多東西就不用再多講了，大家都懂的。先是把全體項目成員都喊來開了個項目啟動會，項目總監從商務背景到價值意義，再到可能的影響和布局，都給大家做了介紹，也做了現場的問答解釋；之后，向大家介紹了項目計劃和執行方式。會后，你可能會發現，自己的具體計劃還沒發出郵件，大家已經紛紛行動起來開始準備了。這就是“透明”的力量！
除此之外，用白板和每日站會，并且每天在popo群上貼出燃盡圖來展示進度偏差?？吹酱蠹視驗檫M度落后而紛紛喊著“好緊張啊”，看到大家會因為趕上進度而感慨“執行力爆棚”，你就會覺得大家的士氣被無形中調動起來了。
在“透明”的執行方式下，直接的作用就是團隊負荷度提高了。在緊急項目A中，啟動之前團隊的負荷度在90%-100%之間，而兩個迭代下來，團隊負荷度一直是超飽和的，分別達到了112%和117%。當然，超飽和的工作負荷是特殊時期的短期狀態，也是應對特殊項目情況下不得已而為之。
百寶工具2. 計劃緩沖
項目經理做計劃的時候，并不是簡單的把大家的估算做個合計就可以了，必須根據產品和團隊的實際情況，考慮項目風險狀態，留下一定的緩沖。
大家對緩沖容易有幾個誤區：
- 因為有緩沖，所以開發是否認真估算就不重要了，大不了用緩沖！
- 項目時間壓力太大，太緊張了，沒余地留緩沖！
- 上次的緩沖我們沒怎么用，這次我們也不用留了！
緩沖究竟是用來干什么的？它既可以用來應對無預期的請假情況，也可以用來承載需求蔓延或需求變動引起的任務增加，也可以用來對沖因前期調研不足而導致工作量加大的任務等等。
緩沖的預留量因團隊和產品各異，我們的一般經驗值是20%-30%。
在緊急項目A中，我們在計劃里做了兩層的緩沖設置。首先將整個產品一期開發分成了7個迭代，平均每個迭代5-10個工作日。第一層緩沖留在了各個迭代內部，比例是20%-30%，主要目的用途在于承載需求蔓延以及全新系統的聯調風險；第二層緩沖留在了第四個迭代之后，設置了一個緩沖迭代（見下圖），用以承載可能的系統優化需求。這主要是因為產品是全新系統，在前期風險識別時，認為對全新系統的需求分析和策劃交互很難一步到位，需要留有調整優化的空間。這其實本身就是一項風險應對的措施。
不要因為本身時間就不夠了而忽略緩沖，這并不是在解決問題，而是在回避真正的風險。
百寶工具3. 范圍縮減預案
在完成了上面兩步基本計劃的制定之后，才開始真正的考慮最后期限可行性問題。通過對業務、技術、后勤三方面風險的完整考察后，在規定時間內完成既定范圍的風險被列為了項目A最高的三項風險之一。因此，必須為這項風險預留一定的緊急預案。
在時間被限定死的前提下，大家都很容易想到一個方案，那就是范圍縮減。于是，分析了現有的產品需求，和策劃討論了分批實現的可能性。之后，在與合作方的需求確認會上，就提出了這一風險，以及建議制定應對風險的緊急預案：部分用戶2個月之后才會用到的功能延后到二期實現。合作方欣然接受了在風險情況下啟動預案的提議。
系統往往是越完整越好，但面對風險情況下的預案準備，往往會發現系統事實上是可以被分解的。那么計劃的安排可以對應做些準備，預案中可能被縮減的模塊，可以放到晚些的迭代來做，這樣可以在前期更好地對風險狀況做個判斷，并為預案的啟動留下了空間。
百寶工具4. 需求簡化預案
縮減了范圍，但看上去還是做不完，怎么辦？我們還有寶貝嗎？
我們又仔細研究了需求，發現其中部分模塊是系統運營所用，并非終端用戶所用，也就意味著，功能是必須的，但是，方案可能是可以簡化的。于是，和策劃做了討論，又追加了簡化運營系統的緊急預案，同樣在溝通后得到了合作方的理解。
所以，面對“范圍”維度，我們能做的不僅僅是“砍”一個字，也許還有“化繁為簡”的方案，原則是盡可能去挖掘那個真正的“最小集”。
還有個血淚教訓，永遠別忘了那些被你砍掉或者簡化了的功能。我們經常會在達到最后期限之后，就只記得繼續前行，而不記得去撿起那些為了趕工而犧牲了的功能或者體驗，結果就是打造了一個滿是傷疤的不完美不精致的產品。所以，要在范圍縮減時，及時做好被縮減掉范圍的需求管理，制定計劃把它們補上！
面對這些百寶工具，您有沒有下述疑問？
問：質量可以被縮減嗎？
前面的工具里，既有“時間”縮減的工具，也有“范圍”縮減的工具，那么，“質量”可以同樣被縮減嗎？
這個問題的答案并不是一語概之的。一般來說，互聯網產品的終端用戶就是千萬網民，所以，并不存在可以妥協的產品質量。因而“質量”往往是我們最謹慎去碰觸的縮減維度。但這個問題并不是絕對和毫無商量余地的。比如，針對運營后臺，因為用戶是運營管理員，用戶數有限且是內部可控的，我們可能可以只覆蓋主路徑測試即可。在項目經理的百寶箱里，有一些寶貝是帶著“邪惡”力量的，它們的使用可能會造成比較嚴重的負面效果，質量相關的工具就屬于這類，輕易不用。
問：你怎么不說加人？
不可否認，不少項目是靠加人來趕進度的，但這并不是一種可以推廣的方法。少量加熟練工，確實可以緩解部分進度壓力。但單純希望靠增加人數來縮短工期，無疑是個焦油坑，我們的項目曾經就遇到過短時間內加了兩倍人，但生產率反而降低的情況。而附加帶來的歸屬感、團隊文化、溝通問題，更是讓項目根本無法前行。
問：如果還是趕不上進度呢？
即使機器貓本領萬千，康夫依然可能通不過考試。同樣的，即使項目經理使出渾身解數，即使團隊很拼命，可能項目延期依然難以避免。那是不是項目延期就意味著失敗呢？我們是不是依然有辦法讓項目“成功”起來呢？我們是不是依然有辦法讓合作方滿意呢？
其實有一套方法是萬變不離其宗的有效工具，無論延期能否避免，我們都能夠讓路走得更順一些。那，就是，過程同步——風險預告——及時坦誠。這是伴隨著時間管理的很重要的溝通管理。
- 過程同步：是為了讓重要干系人了解項目進展以及團隊有效的工作。大家在同樣的進度信息面前，討論問題有了同樣的前提，也更容易讓干系人或者合作方和團隊能夠站在同樣的戰壕里共同應對問題。
- 風險預告：我們并不需要粉飾太平，尤其在挑戰性項目面前。相反的，干系人或合作方的心里同樣有風險的問號，及早把風險預告出來，可以建立大家類似的心理預期，也為未來的緊急預案實施做好了準備鋪墊。
- 及時坦誠：風險監控顯示風險即將顯現時，不妨及時、坦誠地和干系人或合作方溝通。當然，必須有前兩步的鋪墊和溝通，這時坦然啟動緊急預案即可，即使是延期的預案，大家也是有預期的和可接受的了。
壓箱寶貝
接下來，壓箱底的寶貝來啦！就是三個字：穩！悲！樂！
對于“時間”這個問題來講，項目經理事實上是團隊的依靠所在。而只要項目經理做好了上一節所說的“過程同步——風險預告——及時坦誠”，那么，天其實是塌不下來的，也沒有什么坎是無法逾越的。因此，項目經理必須有一個“穩”的心態，讓團隊相信，有你在，沒問題！
在“穩”的基本心態之上，項目經理要具備：以“悲”觀的心態看風險，以“樂”觀的心態對團隊。時間管理的問題，歸根到底是風險的問題，項目經理應該是謹慎的全面的風險識別者和監控者，并為之盡早制定各種預案；同時，對團隊所承受的壓力應該有所把握控制，在展示風險“施壓”的同時，善于觀察團隊狀態，及時給出舒緩，確保團隊樂觀前行。
壓箱寶貝，說到底是項目經理的修煉所在，及時觀察分析能力，又是經驗判斷，更是平衡把握，實屬不易。
寶貝會被用盡嗎？
當機器貓一件件掏出自己的百寶工具時，我們不禁要問，會不會有一天，寶貝被用盡了呢？同樣的，會不會有一天，項目經理面對時間問題用盡了所有的辦法，一籌莫展了呢？
只要大家沒有看到可愛的機器貓掏空口袋，那么一樣，不會看到項目經理用盡寶貝的那一刻。今天我們只是列出了百寶工具的幾個方向以及幾個簡單的例子，而事實上我們面對的項目狀況復雜多變，項目經理們一定能掏出更多的方法來應對。無論是一定程度的并行，還是迭代變化組合等等，都是可能應用的更多百寶工具。
正所謂“辦法總比問題多”，只要我們秉持這樣的信念，再加上我們的壓箱寶貝，那就真的是無堅不摧的了！
作者：曹智清，網易杭研項目管理部總監。曾經感受過IBM的專業嚴謹，領略過ASK搜索的起起伏伏，體會過創業中的酸甜苦辣。目前致力于在線教育行業的探索，同時關注項目管理在互聯網產品全生命周期的應用，專注于敏捷精神的滲透和實踐?！毒W易一千零一夜》主要作者之一。
本文由 @網易杭研項目管理（微信公眾號：NetEasePM） 原創發布于人人都是產品經理。未經許可，禁止轉載。
大家都用什么來排期項目？
1、作者這個有點體系化，復雜些，非那個方面，具體案列中，設計甲乙丙丁等幾方的協調，不是一個乙方自虐，死扣的問題，
辦法總比問題多！ ??
每日站會是個很扯的方式，不敢茍同。我之前也這樣經歷過，我得出的結論就是在站會前，每人都在翻看項目計劃，考慮如何應對；會后就是討論如何一番。
嗯嗯您覺得每日站會是有什麼問題呢？其實這是一個信息快速同步的方法，也不一定每日，也可以隔日。在網易大部分項目都有這樣的站會習慣，也是促使各環節彼此溝通、同步風險。我們的書《網易一千零一夜》里面也有針對站會，做深入分析哈。
首先原諒我沒有讀過您的作品，本月一定要拜讀下。其次，我初始提出站會的目的跟您的目的應該是一致的，讓大家周知項目的進度，除此之外還加入了分享機制，讓每一個人能思考，會發言，隨著時間推進，分享被做成了故事會（開始提出的時候就沒限制范圍）；因為我們每天要填寫項目完成進度，所以，所以站會就是讀進度，而且大家都是分模塊處理的，好像彼此都不是太關心他人的進度，針對這樣的結果，希望您能給出建議如何解決。
嗯嗯～您的問題其實很多團隊都發生過～哈。所以其實就是控制站會講昨天做什麼，今天打算做什麼，以及有什麼風險。整個站會只能十～十五分鐘左右快速碰，不詳細展開與討論。深入討論與分享，都是另外開會。另外要注意站會的人數，十人左右已經很多，如果太多人且彼此關聯很低，可以考慮分開幾個模塊各別站會，最後各模塊負責人整體站會。畢竟團隊負責人、項目經理、QA等人，可能還是想知道整個模塊彼此協作，項目經理也應該把握站會氣氛，叮嚀大家專心聽其他人講。深入的分析書上會有～哈。您看完有更多問題，歡迎一起交流哈。 ??
謝謝指點 ??