面向DeadLine編程老延期怎么辦

本篇內容介紹了“面向DeadLine編程老延期怎么辦”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

合理資源配置

延期有一個很容易忽略的原因是資源不足。因此項目開始之前，PM或者項目Leader去整合資源是必要的，去尋找項目需要的參與者和三方資源，讓項目可以順利的啟動。可以從下面幾項考慮：

• 人員配置，項目開始之前，PM可以先考慮一下人員配置。根據項目工作量大小，相關工作經驗安排誰去做或者多少人去做。并且還要做好人員梯度，我當然希望團隊里面都是經驗豐富的“大哥”，但是事實上，“大哥”工資高，小弟扛不住啊。一般合理的做法都是有一個團隊梯度，以老帶新。

• 知識配置，項目可能涉及到多端，多個方面，包括產品、UI、開發、測試等。最好可以配置相關工作經驗的人員參與，如果沒有，可過通過招聘或者通過知識調研等方式補充知識空白。

• 資源配置，項目所需的服務器資源，三方軟硬件資源等等盡量考慮在內。

• 資源合作，在某些團隊中，技術授權凌駕于需求和設計授權之上；在其他團隊中，則是從屬其下；而在最佳的團隊中，這幾種類型的授權之間會有一種合作的關系。

明確的需求 & 評審

需求文檔是一個產品從無到可視化的過程，是后期一切工作的重要依據，如果后續的工作過程中好要不斷的重新回顧整理需求流程的話，無疑是浪費時間的。因此一份明確的需求是非常重要的，從初稿到最終原型，可以通過一些評審來不斷精煉。

• 評審建議參與項目的人員都參與，包括PM、產品經理、開發、測試等。

• 評審的目的：

1. 讓參與項目的人充分了解項目；

2. 找出需求中的不足和補充，并做好記錄，為下次評審或者后面的工作修改；

3. 讓參與項目的人同意，并認可這個項目要做的事情；

4. 風險把控。

• 評審并不會只有一次，但盡量用最少的次數輸出一些完整的原型

• 評審的質疑和提問，這并不是否定產品，而是通過提問來推進產品審評的過程，讓大家跟了解將要的做的事情。

• 最終的輸出是大家都一直理解并認同的原型文稿

必要的“業務需求轉化成技術需求”

這個過程其實是項目過程中的必要階段，但是大多團隊往往會忽略，或者做的不夠充分，引起后期代碼開發者的疑惑。也有團隊覺得這也OK的，我們的工程師經驗很豐富，代碼結構了然于胸，但是缺乏記錄的過程，往往會讓后續維護人員無從下手。

這一部分工作會根據業務的不同有不一樣的答案，每位 IT 架構師對此問題的答案的關注點都或多或少有自己的特別之處。

下面提供一個建議流程：

• 抽象出服務模型，以客戶為核心整理出我們將要提供的服務。

• 服務流程，從客戶體驗服務開始，客戶端，服務端以及其他服務商交互流程的整理。

• 任務分解，將流程中的任務分解成小任務，盡量細化，并輸出work list，每一個work單獨評估完成時間。

合理的進度

首先要說進度表的目的是什么，有三點：

• 第一：是承諾，是對什么時候完成任務的承諾，確定每個人在什么時間交付什么工作成果。

• 第二：每個人努力把自己的任務當成整個項目的整體的一部分，可以把自己的任務和他人的任務結合起來，如果每個人都可以按時合理的完成自己的任務，從而不影響他人的工作，對于整個進度就是一個良性的促進作用。

• 第三：就是提供了一種能夠追蹤項目和把工作分成若干個易于管理的小塊的工具。把工作分成一天或者兩天的量，能夠幫助團隊更好地理解他們到底需要做些什么。

我們需要用好工具去管理進度。記錄，追溯，合作開發是項目必備，聰明的團隊會找一些工具，或者自己開發一些工具來幫助自己，例如Jira、GitLab WorkFlow。

我個人也比較喜歡開發或者尋找一些工具來提升團隊效率，因為任何書面式，人為監督的規章，規范都不如用一個工具來監控，提示，幫助大家來的更有效果。建議團隊根據自己的情況，不斷積累經驗，找到最合適的團隊的工具，還是那句話，最終的目的是"Everything is OK!"

建立有凝聚力的團隊

不斷讓自己的團隊有凝聚力，是應對任何延期的問題最有力的武器。PM或者團隊leader可以從以下幾個方面努力：

溝通

項目整個過程都伴隨一個重要的元素，溝通，準確的說是有質量的溝通。溝通的5個基本的狀態：傳達、收到、理解、同意、轉換成有效的行動。

溝通也經常失敗，原因傳達不夠明確，沒有傾聽，理解上的誤差導致團隊由對事情的意見轉為人身攻擊，嘲諷都是有的。團隊是由每一個自然人組成的，剛剛成立的項目組彼此之間的陌生和不信任是可能的。

這里有幾個建議：

1. 明確角色和各自擔任的工作任務；

2. 自我介紹，通過過往的工作和生活背景，讓大家更了解彼此；

3. 激勵，挑戰。每一個角色通過努力輸出成果，從而取得彼此的信任；

4. 明確的項目目標，讓每一個角色忽略一些不必要的，向同一個目標努力；

5. 項目經理從自己做起，努力幫助他人，讓團隊更加團結。

給團隊適當的壓力

壓力是一種強制而令人受約束的影響力或力量 施加壓力和緩解壓力是每個團隊應該考慮到的問題，分為：

1. 施加壓力可以是人為賦予的正面的壓力，在艱難時期更加努力工作和提高效能的人，就會得到獎勵（例如加薪、提升、獎金），也有負面壓力，包括斥責、使人產生罪惡感，或者威脅，通過這類方式讓眾人努力工作。我個人提倡多用一些正面壓力估計他人，適當的用一些負面情緒。根據項目情況而定的一種戰略而已。

2. 緩解壓力，大多是放下暫時的工作，組織運動，用經費（如果團隊里面多的話）旅游，我個人比較喜歡茶話會。喝茶的同時可以讓大家彼此了解。

適當的英雄情結

其實少量的英雄主義對于整個團隊來說是一件好事，可以提高團隊的整體效率和競爭力。但是過于英雄主義或者是黑客的電影看多了可能會讓項目引起不穩定的因素。

以過往的工作經驗來看，出現在程序員的工作里面比較多，尤其是工作一兩年的，或者是剛剛進去某個團隊急于證明自己，甚至是工作很多年的， 主要表現在，沒有合理的代碼設計，有需求直接上代碼。過渡自信的評估時間。只為自己而做，對于他人的工作漠不關心，也不會積極配合。

所以在之后的程序員面試中我往往都會問一些相關問題，例如，你有沒有覺得過往公司的同事中誰的技術比較好？有沒有從他那里學習到什么或者你覺得誰的代碼設計比較給力？這樣來看看對方的團隊意識如何。

勇敢面對錯誤

迭代開發難免會有很多的問題，隨時準備應對并解決各種問題的團隊才是強大的。

解決問題的思維閉環：項目平穩進行 --> 問題出現 --> 認識到這確實是一個嚴重的錯誤 --> 冷靜一下 --> 尋找問題處在哪里 --> 解決并上線 --> 問題不在出現 --> 項目平穩進行

盡量做到周期盡短，項目由平穩最終再到平穩的閉環，有必要的話最后開一個問題復盤會議。

最后，我們需注意的是，延期并不是否定自己的團隊和自己付出的努力，PM應該帶領大家復盤項目，總結項目經驗。在下一個迭代周期不要有同樣的錯誤發生，取得團隊流程上的進步才是最重要的。

“面向DeadLine編程老延期怎么辦”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！