本專案案例根據真實故事進行改編。
劇情介紹這是一個典型的緊急需求。X團隊在週一開早會時，被告知有一個需求，本週三晚務必要完成開發並上線。對於突如其來的緊急需求，X團隊是如何應對，又面臨了怎樣的挑戰和總結？
“這個緊急需求，週三必須上線”這是和往常一樣的週一，但不一樣的是新的挑戰。
在週一最早的公司晨會上，CEO對大家說，接下來，為了更快推進公司業務的市場拓展，我們需要接入第三方平臺，減少現場人員的手工操作成本，提高人效，釋放人力。“因此”，頓了一下，CEO繼續說，“為了配合實體店的擴張，這個緊急需求，週三必須上線”。
在這之前的30分鐘，在高管早會上，CTO根據當前團隊的專案安排，以及當前緊急需求的情況，評估下來，約週五才能完成開發和上線。
這是一個典型的緊急需求，其特點有：
1、來得突然，並且基於實際業務的開展，有明顯的上線時間限制
2、根據常規的做法，技術團隊評估需要一週時間，但需求方期望用一半的時間就完成，專案時間被壓縮
3、非常依賴於外部第三方、合作伙伴或供應商的支援與配合，包括但不限於合同簽定、賬號許可權開通、API介面對接、業務整合
分工合作，說幹就幹！所幸的是，X團隊是一支作風優良、敢打勝仗、經驗豐富的團隊，根據“定好需求、輸出原型，排期開發、釋出上線”的十六字方針，在進行公司晨會結束後，CTO立即組織了產品經理和專案干係人對此需求進行了需求評審。
在完成需求評審後，根據本次需求所涉及的系統調整範圍，以及團隊情況，參與本次的緊急需求的專案干係人共7人，主要有：
產品經理：1人，負責本次的緊急需求梳理與輸出。Java開發工程師：2人，分別負責第三方系統和介面的對接；以及內部主流程和管理後臺的後端開發。前端開發工程師：2人，分別負責主流程小程式的開發；以及管理後臺的前端開發。安卓開發工程師：1人，負責APP客戶端的調整與開發。測試工程師：1人，負責整體需求的測試、迴歸和驗收。明確專案里程碑、參與人員和分工後，各自人員便根據自身情況，對需求的理解以及對原有系統、應用、程式碼的理解，對各自所負責的具體需求拆解了任務，並估計工作量（即工時，以小時為單位）和完成時間（即排期）。
評估後的任務、工時、完成時間和負責人，如下（部分，敏感資訊已隱藏）：
專案排期如下：
按時上線，使命必達在接下來的幾天，團隊成員各司其職，有的負責第三方平臺的賬號申請開通和充值，有的負責API介面文件的對接，有的負責內部管理後臺資料錄入與配置的開發。
值得注意的細節是，在前期，團隊識別到了對第三方高度依賴的風險，因此針對需要呼叫到第三方的3個介面，在前期開發時，採用了根據介面文件中的介面規約進行資料的模擬，極大避免了對第三方API的依賴和對進度的阻礙。
最終，經過研發團隊、市場部和產品部的積極配合，此緊急需求在週三晚如期按時上線。
在公司大群裡，受到了老闆的肯定：
在專案群裡，也收到了大大的紅包。
後續調整和週末問題排查在週三晚上約21點，完成了這次的緊急需求的釋出上線，但是否意味著本次需求就到此圓滿結束？
不是的，通常而言，緊急需求上線後，很大機率會發生新的問題。原因在於：
1、由於時間緊張，很多細分場景和邊緣系統，未能充分考慮周到
2、新的系統接入，在完成兩個生態體系對接後，任何一個細微的欄位都會導致現場線下業務的運轉，甚至引起客訴
3、在未正式上線前，在未經過實際業務檢驗前，都可能會存在之前未曾預料或無法識別的偏差
所以，當週四上班後，在進行了內部測試和現場試執行後，針對新發現的問題，技術人員繼續進行了最佳化、修復和調整。
到了週五，又發現了部分訂單存在狀態不一致問題。
到了週末，又發現了另一個問題，為此技術人員需要趕回公司才能進行現場的除錯和排查。
經過多次的迭代和最佳化，本次的緊急需求，終於完美融入了現有的系統、業務和程式碼。
對本次緊急需求的回顧與總結站在故事的尾聲，當我們回顧本次緊急需求的專案燃盡圖時，可以發現本次的燃盡圖也體現了典型的緊急需求和生命週期和其獨特的特徵。
專案燃盡圖，有3條線，分別是：
參考線：計劃排期下的理論進度實際線：實際執行後的真實進度對角斜線：基準線本次需求的專案總工時為：85H，約10.5人天，其中在週四任務工時增加是因為後續發現新問題進行需求調整帶來的新工作量。
按《人月神話》裡的解釋以及真實情況，並這是這樣理解和假設的。實際上，參與本次專案的有5名技術人員，時間跨度了4個工作日。
回顧以下本次緊急需求的專案燃盡圖，我們發現：
1、計劃排期的參考線（黃線），在對角斜線之下，表示計劃排期比最快速度還要快速，否則不可能在指定日期完成開發和上線2、實際的進度（藍線），在參考線之上，表示實際進度通常都會落後於計劃進度，要麼因為任務未完成，要麼時間緊張未及時更新任務完成狀態3、在專案上線後，專案工時增加，是因為上線後發現了新的問題需要繼續最佳化緊急需求的應對和損害對於其他團隊，根據對緊急需求的經驗總結，當自己遇到緊急需求時，我們應該如何更好地應對呢？
緊急需求應對策略1：需求早提早上線
需求早提早上線，這是非常重要的經驗總結。專案和需求流轉下來，最終壓縮的都是最後執行團隊的時間，也就是技術團隊的開發時間，尤其會壓縮的是測試時間。
如果一個需求，前期溝通和梳理花了1個月的時間，到產品原型輸出時又用了1周時間，當明確要做的時候，可能留給技術團隊的時間只有3天時間，而給測試人員的時間很可能就只有3小時了。
如果儘早確定需求，確定需求要不要，優先順序如何，具體需求怎樣，那麼就能為技術團隊爭取更多的時間視窗。
說到這裡，我們會發現一個很有趣的現象，就是決定軟體專案的開發時間，不是專業的工程師本人，而是需求方。需求方往往會說，“3天不行，今天就要上線”，產品或許會經常說，“這個需求很簡單的，改幾行程式碼不就可以了嗎？”。
如果一個病人去醫院就診，他肯定不會說，“這個點滴我要5分鐘內打完，我等不了45分鐘那麼久，因為我還要趕去上班。”因為他會聽從專業醫生的建議。那為什麼在軟體開發行業裡，不是由技術團隊自己決定專案的時間呢？很可能，在別人看來，我們不是專業的人士，甚至在我們自己看來，我們自己也只是碼農、程式設計師，而不是專業的工程師。在外部因素裡，需求方所定的時間，也是基於激烈市場競爭環境而作出的要求。因為，創業實在需要分秒必爭，尤其是網際網路企業。要快，更快，非常快，做到最快。
緊急需求應對策略2：提前識別延期風險
對於緊急需求，最大的阻礙就是無法上線，其次是延期上線。
阻礙上線的因素，最大的風險不是來自內部，而是來自外部，第三方平臺如果不簽訂合同、不開通賬號、不提供API介面文件和許可權，都會導致最終專案的上線。因此，這些非技術的因素，作為專案負責人，要第一時間識別、跟進和溝通。
導致專案延期上線，很大的程度決定於兩邊對接的進度。在明確需求後，找對方負責人獲取相應的開發文件、提供測試環境和測試賬號、並要求安排相應的技術對接負責人，能極大保障和加快對接的順暢度。
緊急需求應對策略3：做好抗衝擊的準備
緊急需求，並不是上線就結束了，而是一個新的開始。要做好對業務的監控、進行內部試執行、還要對即將發生的各種問題做好排查的準備。
任何一個不恰當的地方，任何一行不對的程式碼，都會被內部的員工或者被外部成千上萬的使用者找到，群眾的眼睛是雪亮的。
另一方面，緊急需求並不是百利而無一害的。緊急需求，也有它自身的損害。一方面，緊急需求是排期性的，也就是說，如果一個人優先做了緊急需求，那麼他就不能同時繼續完成原來既定的需求安排。這樣，會導致其他原來的需求延期，從而影響了原來其他專案的正常計劃。假若是被影響的需求和專案是其他產品業務線或產品經理負責的，那麼這將會展開另一波的溝通工作。
另一方面，緊急需求會導致技術債務的產生，增加了系統的不穩定性和日後的維護成本。由於時間緊張，技術人員第一想到的是完成需求，而對於系統架構、擴充套件性、程式碼質量、資料庫設計、自動化測試這些非功能性需求，很可能會暫且放下。曾經在飯堂和技術總監吃飯聊天時，他說道，現在房地產的房子，越快時間建好得越不敢住，因為一棟樓本來要6年時間才能蓋好的，現在2年時間就建好，真不知他們為了趕工期而忽略了哪些重要的地方。我覺得，專案開發，也是如此。時間一壓縮，註定會留坑。
YesDev小技巧在專案管理模組，建立專案後，可以透過工作組圈定專案干係人，進行需求關聯，拆解分配任務。隨後，YesDev會自動生成專案排期表和專案燃盡圖。