為什麼項目會出現這樣的情況呢？單就這個項目來說，先抛開人員的能力問題來講，我覺得就項目管理方面來講，有以下幾方面的問題：
1， 對項目的評估不足（包括項目的複雜度，風險，人力投入等）
在項目開始的時候，過于樂觀，認為技術不是問題，因為對項目的技術風險，人員的投入都沒有進行充分地評估，就急急忙忙碼代碼了。
2， 項目計劃制定得過過于宏觀，沒有仔細做好任務分解
我認為項目經理最重要的任務，就是将項目進行分解，做詳細的開發與驗證計劃。這些恰恰是這個項目欠缺的。項目經理認為，隻要我們給了業務流程，再把原型圖給到前後端，就不需要再制定項目計劃了。由于沒有深入到具體的操作層面，把品質和進度的風險把握到細節。如果項目中不能夠及時調整和規避風險，很容易到出結果的時候已經為時過晚。是以項目計劃也是一個不斷漸進明細的過程。
3， 項目監控不到位
項目監控不是一會松一會嚴就能做好的。項目監控應該有固定的頻率和方法。這位老闆最嚴厲的時候要求開發人員用什麼番茄工作法，每十五分鐘填一次日志，我真心覺得這除了增加開發人員的工作量以外，沒有别的用處了啊。這位老大嚴格起來像瘋子，寬松起來就更像瘋子了，前端沒有按照要求完成任務，他幫前端開脫，後端沒有完成任務，他幫後端開脫。這樣忽左忽右的态度，研發人員無法适應。
項目計劃階段是制定完整的項目計劃，并最後确定項目的目标和範圍，指導後階段項目執行，是項目成功的重要保證。對于複雜的項目，在各領域、各層次都需要進行全面細緻的計劃工作。
兩次世界大戰時期德國都被打敗，但德軍的作戰形象依然是令人望而生畏的，素質優秀，戰鬥力強大。德軍的大腦總參謀部發揮着核心性作用，他們有一項特長，就是在戰前制定周密的計劃，比如一戰時的施裡芬計劃，二戰時對波蘭、法國的閃擊戰計劃，對蘇聯的巴巴羅薩計劃。德國人制定作戰計劃時的詳細和刻闆是讓人難以想象的，甚至每一支部隊有多少人力，比對多少武器裝備，補給的運輸計劃等都非常詳盡。
一位著名的德國将領曾經坦率地說“戰前必須制定作戰計劃，但戰争一旦開始，所有計劃必須廢棄，聽炮火的聲音指揮部隊方向。”他想說計劃沒有用？當然不是。計劃的目的是為了統籌複雜的事務，事先制定計劃有重大價值，首先制定計劃的過程就是明确戰略方向，統一上上下下意志和決心，盤點資源家底的過程；第二點，通過細化執行計劃可以形成小型的執行子產品，在計劃執行過程中雖然整體計劃調整，但各個小型執行單元仍然能夠高效推動；第三點，如果事先有計劃，應變者就有一個資源架構可以利用，制定計劃、執行計劃、調整計劃這一系列動作中，資源是最重大的限制和限制條件。
德國軍隊以善于做計劃聞名，制定計劃也造就了德國基層指揮官的高素質，一方面他們被強有力的計劃限制目标和行為，一方面他們根據戰地瞬息萬變的局勢發展，作出有針對性的調整和部署。
德國軍隊的戰鬥力建構經驗告訴我們，沒有計劃是萬萬不行的，有計劃不執行，不應變也是不行的。
那麼我們來說說如何預防進度拖延
明确目标和需求： 在項目啟動階段確定對項目目标和需求有清晰的了解。這有助于避免在項目執行過程中因為需求變更而導緻的拖延。
制定詳細計劃：制定詳細的項目計劃，包括裡程碑、任務配置設定、時間表等。合理規劃工作量和時間，確定所有相關方都對項目的時間表有共識。
風險評估和管理： 在項目計劃中加入風險評估和管理步驟。提前識别潛在風險，制定相應的應對計劃，以減少可能的拖延。
團隊合作與溝通：保持良好的團隊合作和溝通非常重要。確定團隊成員明确任務、進度和項目目标，及時溝通問題，避免資訊斷層。
追蹤和監控進度： 定期追蹤項目進度，確定項目按計劃進行。使用項目管理工具來監控任務的完成情況，及時發現并解決潛在的問題。
階段評審： 在項目的關鍵階段進行評審，確定項目在每個階段都符合品質标準和目标。這可以幫助早期發現問題并進行糾正。
合理配置設定資源：確定項目獲得足夠的資源，包括人力、資金和裝置。合理配置設定資源可以減少項目拖延的風險。
采用疊代開發模型：對于大型硬體項目，考慮采用疊代開發模型。這樣可以在項目早期傳遞部分功能，減小項目整體失敗的風險。
技術驗證和原型測試： 在項目早期進行技術驗證和原型測試，以驗證關鍵技術和功能。這有助于在項目後期減少因技術問題而導緻的拖延。
靈活應對變更：雖然盡量避免變更是重要的，但有時變更是不可避免的。建立一個合理的變更管理流程，確定變更不會導緻不必要的拖延。
需求與計劃的變更管理
其中最重要的措施我們分解分析如下：
【措施1、用人】
《曾國藩家書》中有許多關于用人之道的精辟見解，簡而概之：廣攬、慎用、勤教、嚴繩。
1. 廣攬，通過各種途徑挖掘各方面人才。
要想廣攬人才，首先要有科學的擇才态度。“英雄莫問出處”這話雖然簡單，但真正在選人時幾人能真正摘掉有色眼鏡，不問學曆，不問出身？曾氏帳下各種人才俱至，這首先得益于曾國藩獨到的識才藝術。
2. 慎用，合适的人要用在合适的崗位上。
很多人會廣攬人才，但能用好人才的卻不多。曾國藩雖然廣攬人才，但在人才的使用上卻非常謹慎。他善于從細節上判斷一個人的品性德行，進而對人才形成全面的判斷。
曾國藩在主政兩江時，很多鄉親好友前來投奔他，但他都是給足盤纏要他們回去。他說：好馬劣馬不能同槽喂食，否則好馬也會變劣馬。我的兩江總督府是一個人才府，如果平庸之才也進了人才府，那麼真正的人才就會寒心而走人。
3. 勤教，就是經常教育訓練、教育。
曾國藩很善于通過書信、面談及飯前閑談對部屬進行教育訓練、教育。書信好了解，曾國藩家書洋洋灑灑幾百萬字，無所不談。面談相當于今天的績效面談，總結成績，指出不足，探讨改進方法，促進部屬成長。這些教育訓練方法讓曾國藩帳下很多人受益匪淺，這在100多年前相當難得。
4. 嚴繩，就是通過建立健全規章制度來管理和督促部屬。
制度不健全，好人幹壞事；制度完善了，壞人也做好事。100多年前的曾國藩就明白了這個道理，并進行了豐富的實踐，可歎今人還在這個問題上認識不清。
這8個字中，“勤教”是最難的。這也是華為說的：“先固化、再僵化、再優化”，這個過程，需要主管、項目經理下足夠的功夫。例如“例會”、“問題跟蹤”，很多很多次的動作才能形成一個習慣，很多很多的習慣才能形成一種傳統，很多很多的傳統才能形成一種文化。華為的流程文化，也是很長時間的曆練才能形成，并且有大量人的智力和體力的投入。
是以在初創團隊中，要想建立一套“規章制度”、“規範”、“流程”，這些文檔網上都有，流程建立的核心是“人”，流程執行的核心也是“人”。華為的IPD流程，網上有很多文章，照搬肯定不行的，關鍵是吸收精髓，然後為我所用。
項目經理的人選就尤為重要，項目經理的選人也非常重要，這是為什麼華為讓研發人員去負責招聘，而不是交給獵頭公司和HR，是有原因的。
是以老話說得好：“兵熊熊一個，将熊熊一窩”，初創團隊的CEO、大公司的項目經理，決定項目和公司的生死。
【措施2、把牢需求，從源頭控制進度】
從上圖可以看到，産品的開發之前，需要有一個收集産品需求的流程。這個流程，保證了兩點：
1、需求是有依據的
2、需求有基線，歸檔并跟蹤
3、需求有讨論，不是一言堂，不是拍腦袋。
需求控制出了問題的話，就會出現範圍蔓延。
範圍蔓延從内部和外部都有可能發生。由于開發人員往往出于主動性，會把自己放置在使用者的角度思考，會按照自己想法臆想需求，往往就會出現需求的範圍蔓延，無端的增加了很多原本沒有讨論過的需求；一些定制項目的硬體開發周期比較長，客戶很可能在開發過程中随意的提出一些不合理的需求；有些老闆和上司在開發過程中發現了新的價值點或者新的商業機會，也會忍不住要提出新需求。
為了避免需求在開發過程中的走樣，我們需要進行“範圍管理”。項目範圍的管理也就是對項目應該包括什麼和不應該包括什麼進行相應的定義和控制。它包括用以保證項目能按要求的範圍完成所涉及的所有過程，包括：确定項目的需求、定義規劃項目的範圍、範圍管理的實施、範圍的變更控制管理以及範圍核實等。項目範圍是指産生項目産品所包括的所有工作及産生這些産品所用的過程。項目幹系人必須在項目要産生什麼樣的産品方面達成共識，也要在如何生産這些産品方面達成一定的共識。
範圍管理的目的是在項目開發過程中，出現範圍蔓延。範圍的蔓延，勢必影響項目的品質、時間和成本。是以，我們需要制約項目的需求蔓延，制約一個項目需求蔓延，就的條件是确定項目“限制條件”——範圍、需求、時間、成本、品質。範圍的蔓延，勢必影響項目的品質、時間和成本。
範圍管理
【措施3、拆解關鍵動作，保證計劃落實】
在項目中大家可能都經曆過以下幾個場景
案例一：銷售和客戶簽好了合同，産品遲遲傳遞不不來，銷售抱怨研發硬體團隊太不靠譜
大家去飯店吃飯，點了菜等了良久，卻遲遲不上菜，心裡急的好像熱鍋上的螞蟻。産品傳遞延期給客戶的感覺就是如此，銷售人員催你“趕緊供貨啊”，可你還有好多問題沒有解決完，這時後悔當初不應該把計劃排的這麼激進。一個難解的技術問題就導緻這個計劃達不成了，客戶催，銷售着急，可你也沒辦法啊。
是以硬體計劃一定要靠譜，計劃不靠譜，别人就會覺得硬體項目經理不靠譜。
案例二：單闆回來了，軟體調試沒有準備好，下一步測試活動遲遲開展不了
項目進度緊張，等着裝置搶占市場，硬體工程師加班加點，提前完成了PCB投闆工作，還加速完成了單闆加工，第一批單闆産出時間比原計劃早了兩周。單闆回來了，發現底軟的同僚還沒有完成調試軟體的準備，基礎子產品調通整整花了一周時間，大家都在等待中，這一周測試活動都沒法開展。硬體工程師心裡急啊，那些省出來的時間都是團隊成員辛苦努力的成果，可在單闆調試這裡阻塞延誤了一周，太可惜了。
後來，我們的團隊在制定計劃時對，項目開發中耦合關系重點清楚，什麼時候硬體給制作PCB的工程師，什麼時候單闆能回來，軟體什麼時候能提供可以用于測試的軟體包，試制驗證BOM什麼時候能穩定，這些都是重點讨論的内容。
案例三：老闆覺得你的計劃不夠細，要求你細化到天，排計劃費時費力，指導意義差
老闆對你負責的項目非常重視，5個月内一定要把産品交出來，他自己來稽核項目計劃，你把準備好的計劃拿出來給他看，他覺得不太滿意，他給你提了新的要求：“小明，這個項目對公司的很重要，提前一天都是有價值的，你這個計劃還是太粗了，盡快拉大家再讨論一下，我們的計劃一定要細化到天，要以天為顆粒度制定執行計劃。”對這個任務你直撓頭，不過老闆的指令一定要執行啊，于是你連夜拉着團隊成員把計劃進行拆解，終于排出了細化到150天工作計劃。可項目一開始時就發現問題了，計劃顆粒度太細了，很難執行，綁住了工程師的手腳；項目早期，特别是項目開始的時候内外部環境條件很大，項目計劃需要修正的地方很多，一個過分細化的計劃，每次調整耗時耗力。最後這個“精細”的計劃被束之高閣，大家都覺得之前排的計劃好用，時間顆粒度大并不影響執行，可以在周例會上對齊重新整理，特别是關鍵任務準備開始時，可以針對關鍵任務拆解細緻。
總結以上的幾個案例，項目有序開展就是靠項目計劃指引，計劃是項目的節拍器，計劃首要是要靠譜，按照承諾的時間點傳遞；好的計劃會在各團隊耦合點上充分進行讨論，做好充分的準備，避免因為互相之間的等待消耗時間；制定一個好的計劃一定是分層分級，逐漸明晰的，不要追求項目一開始就制定一個完美精細的計劃，我們要保證的是方向正确，逐漸調整，利于執行。
立項評審通過後，就正式立項了。從項目的開始到項目關閉，項目管理者始終都會奮戰在一線。項目開發主要的幾個階段：
項目啟動（概念）→項目計劃→項目開發與驗證→項目釋出→項目關閉
項目啟動:啟動階段說白了就是拉人成立山頭的過程。告訴大家，我有番号了，是正規軍，你們都跟着我幹吧，面包洋酒都會有的。于是SE，測試經理，硬體，軟體，結構，RQA，配置經理統統都來了，來給開發代表打工了。開發代表介紹立項材料，需求，大概可以花多少錢，多長時間内要完成。然後大家一起評估下工作量，看看時間是很緊張呢還是很很緊張呢。
這個階段必須要完成一些基礎的配置：比如項目編碼申請，建立項目基本資訊，記錄預算分攤關系等等。
項目計劃：華為的項目計劃包括很多個獨立的計劃：開發與驗證計劃，版本計劃，版本轉維計劃，測試計劃，品質策劃，還有子項目計劃（硬體，軟體，結構，邏輯等等）。
做這麼多計劃的核心，其實還是那句話，将一個龐大的項目切分成子產品，各個子產品的負責人再來根據子產品的具體情況，手上的資源情況，制定進一步的計劃。開發代表這個時候要做好的就是各方的溝通協調工作，特别是有依賴關系的幾個子產品，在計劃上就一定要銜接好，還要充分考慮可能出現的風險，留出部分的預估時間。
項目開發與驗證：這個階段的重點工作其實就是跟蹤與監控了，定期檢視各個子項目的進展情況，是否有突發的風險，需要新引進的物料是否能按時走完流程，一些特定客戶需要的認證準備，等等。還是一句話，跟蹤和監控需要有序有力地進行，任何不确定的因素都要想辦法确定下來，不給後面的釋出埋雷。大多數的項目經理都會用到的一個管理工具推薦給大家《任務跟蹤表》。
項目釋出：按照計劃執行對内對外的釋出，項目驗收，做好各方位的交接工作。其實隻要項目的進度偏差不是太大，也沒有出現重大的bug攻關不下，到了釋出這個階段，基本上大家都可以稍稍松口氣了。當然，還是不能大意。這個時候，更多的是跟各方的一個交接動作。
項目關閉：關閉遺留問題，項目編碼停用，文檔歸檔，經驗教訓總結等。該獎勵的獎勵，該打闆子的打闆子。(此處,可以說明華為年終獎與此挂鈎)
這幾個主要的階段介紹完了，看上去是不是還是蠻簡單的。實際上在整個的項目管理的過程中，還穿插着大量的風險管理，需求變更管理，團隊成員的即時激勵等等工作，有時候緊急，有時候可以緩緩，但是都需要開發代表妥善的解決。我對一件事情印象很深，就是我當時所在的整個小組都被借到另外一個産品線去做伺服器的開發項目，就是因為當時這個項目的硬體經理不給力，直接被開發代表撤換，然後又沒有合适的人力投入，開發代表就通過種種辦法，硬是完成了不可完成的任務。從團隊的磨合到解決前期留下的各種問題，天天都是忙飛了，這種進度和強度，都是很大的。
好的管理是“過程管理”
【措施4、統籌方法】
1、用好跟蹤工具，并與績效挂鈎。
開發代表,隻是負責項目群，對産品的各個版本的傳遞負責，是以他負責在整個産品的各個版本傳遞的時候，有很多工具PMM（類似于Redmine系統，web的項目管理軟體）、缺陷庫、問題跟蹤表、燃盡圖。這些工具，很多初創團隊都有在用，但是是否落實在實處？就看計劃的嚴肅性和績效管理是否挂鈎。這樣的話，大家都重視計劃，勝則舉杯相慶，敗則拼死相救。
2、計劃制定，要嚴謹，并用統籌方法配置設定進度。
我們以“智能電源盒”項目作為例子，一起看看如何分層管理，逐漸明晰一個項目計劃。
1、先定目标，做出整體計劃，設定裡程點
項目開始階段，硬體項目經理為了統一全團隊目标，設定了整體計劃，這個計劃除了定好項目的起點和終點以外，最重要的是定義我們項目中的裡程碑節點。這就好像長跑中我們把20公裡的跑步總長度分為幾個為幾公裡長度的小目标，一個個目标跑出來，每跑一個看一下離之前的時間目标差距有多大，再根據體力情況和時間目标進行調整。
在做智能電源盒這個項目的時候，我們就是立項，設計和計劃，單闆投闆，研發驗收，客戶驗收這5個關鍵節點，每個節點都有一個可考察、可量化的目标。在項目執行的過程中，如果各個節點進度或品質差距很大，那就要對項目亮紅燈預警了。
智能電源盒項目整體計劃的設定
| 序号 | 裡程碑點 | 裡成碑時間 | 階段性目标 |
| 1 | 立項通過 | 2月10日 | 項目立項通過，确定項目的傳遞範圍、整體計劃、品質目标、資源要求。 |
| 2 | 總體設計 計劃細化 | 3月15日 | 1、硬體總體設計完成，确定設計方案 2、項目計劃細化。 |
| 3 | 單闆回闆 | 4月7日 | 硬體詳細設計完成，單闆加工回闆，整機等關鍵配套回闆。 |
| 4 | 研發驗收 | 6月15日 | 産品研發階段測試驗證活動完成，品質問題全部解決。 |
| 5 | 客戶驗收 | 7月15日 | 裝置小批量傳遞，在客戶現成适用驗收，軟體功能優化。 |
2、分層細化項目計劃，跟随項目開展逐漸明晰項目計劃
立項完成後，整體目标已經明确，随着項目總體設計逐漸深入，對項目難度、關鍵風險也更加清楚了，這時候項目經理把硬體、整機、軟體三個團隊責任人召集在一起，分單闆硬體開發計劃、整機結構開發計劃、産品軟體開發計劃三個部分，共同讨論，細化項目計劃。
例如在硬體開發計劃裡，電源盒裡3塊PCB單闆的投闆回樣時間，單元測試完成時間，功能測試完成時間等，硬體改闆時間等進行細化。制定的計劃是否合理依賴三點，首先是通過參與設計并結合自己的經驗深入了解項目難度，接着要掂量團隊執行能力是否能達成目标表；另外，對和别的團隊依賴關系要琢磨透了，比如這個項目中強電控制闆試裝和整機驗證結果就影響5月中旬單闆改闆能否投出去，單闆硬體責任人就要把什麼時間必須完成試裝和測試的要求提明确，從整機工程師那裡拿一個承諾。
總結一下，對準整體計劃制定的目标，項目計劃需要通過集體讨論分層或分子產品進行細化，并随着項目的開展逐漸明晰。
3、找到計劃中的關鍵路徑，集中精力管理
硬體項目經理的精力是非常寶貴的，縱使你有三頭六臂，也很難把項目計劃中的每個細節都關注到，需要把有限的精力投入到最關鍵的地方。我們在這裡推薦的就是在計劃中标定出“關鍵路徑”，之是以關鍵就是這些事務或工作中耦合關系多、執行難度大、延期風險高，對項目達成目标影響較大的，因為關鍵，值得項目經理集中精力管理。
在智能電源盒項目裡，我們标定出兩個關鍵路徑。
關鍵路徑①：是整機設計和初樣驗證的，對這種外觀有定制要求，硬體內建度高，還有特殊環境适應性和安規要求的産品，整機設計、打樣、試裝問題解決一定要先于單闆驗證完成，把整機的問題先暴露出來。
關鍵路徑②：項目開展各種驗證後，要收集全發現的問題，完成單闆的“定稿”。越是接近硬體項目的收官階段，越是要冷靜，把問題和風險收集全，判斷項目的品質水準，完成整機、單闆BOM、單闆改闆等工作，進入最後的項目沖刺階段。
這些可能會影響項目成敗的關鍵事務在項目制定計劃時就要标定出來，項目執行階段特别關注，“特事特辦”，確定成功。
4、關注依賴關系，關注風險
智能電源盒的項目如火如荼的開展到5月第一周，整機試裝已經完成，單闆的調試和單元測試已經完成，經過硬體工程師内部對現階段測試結論的評審，結論是PCB1需要通過改闆解決發現硬體問題，PCB2、PC3兩塊模組單闆隻要優化BOM就能夠解決所有硬體問題，同時，整機試裝問題和EMC測試問題都已經在優化解決。現階段，隻要我們能保證PCB1順利改闆完成，落實PCB2和PCB3的單闆BOM優化，我們就有信心項目準時順利傳遞了，是以改闆成為這個階段最關鍵的工作，我們把主要的項目成員聚集到一起，再次去對齊計劃，確定最後的傳遞工作萬無一失。
| 序号 | 工作内容 | 完成時間 | 責任人 | 狀态 |
| 1 | 硬體驗查漏補缺，如智能電源子產品上強電控制闆預留的藍牙子產品、語音子產品驗證。 | 5月10日 | 老付 （硬體） | Open |
| 2 | 軟體功能相關測試查漏補缺，分析一下尚未完成內建驗證的軟體功能，那些和硬體相關，那些和 | 5月12日 | 小美 （軟體） | Open |
| 3 | 測試項評審，包括單元測試、整機測試、功能測試、軟體相關項測試全部投闆前的評審，全部發現的問題都已經解決。 | 5月12日 | 老付 （硬體） | Open |
| 4 | 新物料準備，如變壓器需要重新修改，解決已經發生的EMC問題，新變壓器的修改要求和首批物料的采購要求 | 5月13日 | 小明 （硬體） | Open |
| 5 | 物料清單優化，要把已經發現的問題上通過BOM修改優化。 | 5月13日 | 小明 （硬體） | Open |
| 6 | 原理圖/PCB改闆投闆：PCB1改闆投闆前做修改點集中評審，先核對是否所有修改點都已經落入PCB改闆，再分析修改點是否對已經完成驗證的功能、性能有影響。 | 5月14日 | 小明 （硬體） | Open |
| 7 | PCB改闆投闆後，優化鋼網，為改闆單闆彙報試制做準備。 | 5月17日 | 小時 （整機） | Open |
項目計劃的執行不會是一帆風順的，錯綜複雜的耦合關系會讓項目在等待中消耗時間，出乎意料的風險會讓延期措手不及，風險管理時項目執行中必要一環，在智能電源盒中通過一張風險管理表格，我們提早就開始預測項目風險，并提前準備應對措施。
智能電源盒中兩個風險管理的例子
| 序号 | 關鍵風險/依賴 | 規避措施 | 責任人 |
| 1 | 單闆物料缺乏，軟體、整機很多活動無法開展 | 1、提前穩定BOM，做好研發階段晶片備料。 2、單闆投闆後催料PCB加工，聯系生産資源，下線後空運送到研發。 | 小明 （硬體） |
| 2 | 單闆上市前要完成準入測試 | 1、預約認證機構資源，完成專業認證。 2、聯系客戶，約定時間進行客戶現場驗證。 | 小時 （整機） |
【措施五】跟蹤閉環
記住解決問題的思路，然後所有的活動，模闆，管理方法都要根據自己項目的實際情況進行制定和修改。
别人的火點不燃自己的燈。
在項目各個階段都需要進一步根據實際情況，細化近期計劃。否則階段内的計劃不完成，總體計劃注定完成不了。
沒有計劃萬萬不行，但辛苦制定好的計劃束之高閣更不行。堅定執行制定好的計劃，監督執行效果，對偏差及時變更，在項目傳遞過程應對變化不斷的重新整理，計劃要友善管理，
1、制定好的第一版計劃先要基線化，確定有據可依
制定好的計劃對團隊外是承諾，對團隊内是目标。充分讨論達成一緻後，要把這個達成一緻的計劃進行基線，比如标定好版本号，放到團隊檔案夾裡。這個基線完成後，團隊下一步的行為有據可依，如果計劃有變更，就說明變更原因，更新版本号。
2、計劃要監督執行，發現延期時要“喊出來”
計劃是團隊運作的行為依據，項目經理要盯着團隊成員的執行情況，如果有人延期了，要及時提醒他“嘿，你落後了”，也要提醒項目組其他成員“注意一下他的延期對你有沒有影響”。我們在項目中常常會陷于技術事務的處理，忽略了擡頭看目标，是以項目計劃及時監督和例行對齊在項目運作中就很重要，例如，可以利用項目周例會對齊進展，對于投闆這樣緊急關鍵的事務甚至可以每天早上站會花10分鐘對齊計劃，讓資訊快速傳遞。
3、計劃要趕得上變化
項目的中我們随時都要是應對變化，客戶需求變更了，關鍵技術問題遲遲解決不了，團隊關鍵成員離開了，項目費用不夠了，你要随時對這些變化保持“敏感”，而最危險的就是對變化視而不見，死闆的沿着固有路線執行。
已有的計劃給了我們方向感，也給了我們一個資源架構，當你意識到變化時，就要主動開始調整計劃。比如，如果某個子產品關鍵技術問題難以解決，就要重新審視一下，下一步工作事務中是不是有和這個子產品不耦合的，拿出來提前開展，不要讓局部事務延期的影響蔓延；如果團隊關鍵成員離開了，就要看他負責的事務是否能拆解到别的團隊成員裡，如果分解了這些事務就要根據工作量的情況和團隊成員的能力重新調整執行政策。
最後，計劃變化後要及時知會全團隊相關的成員，利用好周例會或每日站會，做好廣而告之“計劃調整了”。
4、資源保障是計劃能夠執行的依賴
計劃再完美，都是靠人來執行，項目中想要計劃走的下去就是把人力保障好，下圖中我們是智能電源和制定計劃時的人力估計，根據事務預估每個月需要投入多少人，如果老闆說“放心幹，咱們有人”，那這個計劃執行的成功率就高很多。
硬體項目還要額外關注費用，硬體單闆要錢，專業實驗的溫箱預定要錢，産品認證要求，項目每走一步都有花錢的地方，同樣，這個也需要你做好費用預算，留好費用。正所謂兵馬未動，糧草先行，資源都有了，你放手幹就行了。
遺留問題——勤跟蹤、要閉環
了解全流程開發，可以了解這本書
有沒有一本書讀後，相當于華為工作十年經驗？