硬件項目開發(fā)管理方案

硬件項目開發(fā)管理方案硬件項目開發(fā)管理方案硬件項目開發(fā)管理方案V:1.0精細整理，僅供參考硬件項目開發(fā)管理方案日期：20xx年X月硬件項目開發(fā)管理方案目錄編寫目的 2關鍵詞 2摘要 21. 項目管理概述 2. 項目的特性 2. 項目的生命周期 32. 實施分析 4. 項目申請 4. 可行性分析 4. 立項以及開發(fā)計劃 4. 總體設計（需求分析） 5. 詳細設計 5. 開發(fā)（實施） 6. 測試 6. 項目驗收 6. 項目結束 63. 文檔記錄 74. 項目沖突 7

引言編寫目的為了使公司的硬件開發(fā)便于管理、監(jiān)控和績效，因而要使其流程化、規(guī)范化，使其成為公司的長遠戰(zhàn)略發(fā)展中的良性節(jié)點。關鍵詞項目特性、項目生存周期、可行性分析、文檔記錄、約束力。摘要分析項目的特征，抓住中間的環(huán)節(jié)，同時結合公司現狀，有針對的提出實施辦法。項目管理概述為什么要進行項目管理如果所有的工程都是按照既定的計劃，然后在特定的時間節(jié)點處達到所需的成效，一切都在計劃管理的掌控當中，那就不需要項目管理了。但是實際情況并非單一任務獨占人力資源、硬件資源，項目管理就是要合理的調節(jié)好人力、物力、工時、財力以及其他影響因素之間的關系，然后使各個資源點分配合理，從而使得項目利益最大化。打個比方，實際上同一個人可能同時在多個項目上，就像CPU一樣，必須有個分時調度的規(guī)劃，這樣才不容易死機。項目管理者的角色就是為了讓各個資源點合理有序的被使用，讓項目的進展有條不紊、健康的發(fā)展并完結。項目管理就是要按時、低成本、高效地交付成果。一個好的項目管理者，能夠有效地評估和調節(jié)項目中人力、資源和工時之間的矛盾，進而提出調配規(guī)劃和解決方案。項目管理者要對新上任的項目進行調研，有一個宏觀的了解才能做出下一步的抉擇，調研的對象要包括：用戶需求、關聯廠商、人力資源、物質條件、財務預算等等。項目的特性項目是具有以下特性：目標性唯一性時間性資源有限性相關性（階段性）風險性可行性計劃性成效性項目的由來不是空穴來風，它的進程要受到如時間、資源、風險等相關因素影響。一個完整的項目，不能含糊不清，不能虎頭蛇尾；一個成功的項目，不能無限延期交付，不能耗費無度。項目的生命周期一個典型的項目生命周期：啟動、計劃、執(zhí)行、控制、收尾。如圖1-1：圖1-1典型的項目生命周期示意圖項目的生命周期是一個以投資和時間作為坐標的曲線示意圖，項目生命的每個環(huán)節(jié)都有它獨特的功效。當然項目不會憑空而來，要啟動得有緣由，就像一個商人通常是不會做虧本生意的。項目啟動之后，在結束前，無論哪個環(huán)節(jié)受到忽視，所造成的后果只有一個，即表現在圖1-1中為該曲線圍成的綠色區(qū)域變大——面積增加。換句話說，就是投資量加大與時間跨度增加，然而這兩個因素，哪一個增加也不是我們想要的。項目管理者，就是在有限的資源約束下，運用系統(tǒng)的觀點、方法和理論，對項目涉及的全部工作進行有效的管理，即從項目的投資決策開始到項目結束的全過程進行計劃、組織、指揮、協調、控制和評價，以實現項目的目標。而做項目管理的目的，反映在此曲線圖上，就是在能夠清楚的認識項目生命周期中投資和時間關系的基礎上，分析影響項目生命曲線的具體因素，找到關鍵的環(huán)節(jié)讓其曲線面積變小，從而達到最優(yōu)的結果，設法到一個成功的項目開發(fā)。我們公司內部的一些硬件開發(fā)的小項目，很多還都局限在“口頭項目”，在時間、資源、人力協調方面約束力很弱，經常出現項目一拖曠日持久、投入甚至沒有度量，很難被稱之為成功的開發(fā)項目。實施分析項目申請啟動一個硬件開發(fā)項目，原始的推動力會來自于很多方面，比如市場的需要，產品換代的需要，為了降低成本更新的需要，提高某方面能力的需要等等，所以作為一個硬件系統(tǒng)的設計者，要主動的去了解各個方面的需求，并且綜合起來，提出最合適的硬件解決方案。項目都是為了滿足特定的需要而產生的。一個好的提議，經過管理者的磋商討論、形勢分析，以及技術人員的分析研究，最終得到一個結論：執(zhí)行或放棄，還是把某一部分外包。在這里，管理者的決策好似啟明燈，技術人員的評定則是前行者的動力，兩者缺一不能達成最終目的。PS：外包情況，可行性分析的結果是肯定的，而目前自己的技術力量不夠，但是可以通過外包來達到要求，從而可以承接這個項目?？尚行苑治稣f明該硬件開發(fā)項目的實現在技術上、經濟上和社會因素上的可行性，評述為了合理地達到開發(fā)目標可供選擇的各種可能實施方案，說明并論證所選定實施方案的理由，最終以能夠確定是否需要立項開發(fā)。如果是對外項目，則要確認對方粗略需求框架，在公司內部進行較詳細的功能及需求描述，根據該分析進行判斷。風險評估是必要的，比如，我們承接一個項目，如果項目不能按時交付就要承擔一定的風險。比方說，由于外包部分的不能按時交付，導致我們的整體項目的交付延期，那么我們的風險和外包廠商之間的風險分擔，必須有平衡之處。當然風險的來源也是多種途徑的，不局限于某一特定約束。硬件開發(fā)在硬件項目的立案之前，技術可行性分析是關鍵，不能因為草率的決定，導致日后執(zhí)行之時才發(fā)現這樣那樣的問題，也就是說硬件技術是否真正可行，必須落實到詳細的需求和技術細節(jié)上。我們對這部份硬件開發(fā)前的評判不夠，為什么總有宣告失敗的開發(fā)，根源就在這里。立項以及開發(fā)計劃有了好的項目來源以及著實可行的因素分析，這些條件的滿足，得以達到立項的最基本要求。在雙方基本對上述需求、功能達成一致的情況下，甲乙雙方各自落實項目負責人，評估項目成本、收益、風險等諸多方面因素做出項目計劃書，并交付項目審批委員會審批。這里會涉及到財務、工程技術人員等，簽訂合同、立項。項目成立，要為硬件項目實施方案制訂出具體計劃，應該包括各部分工作的負責人員、開發(fā)的進度（總體設計、詳細設計）規(guī)劃、開發(fā)經費的預算、所需的其他資源等等。項目為什么要立案就是要產生一定的約束力，這樣才可能有好的監(jiān)督和自律作用。就像紀律和法律，紀律是制定給那些遵守紀律的人的，而法律則恰恰是制定給那些不遵守法律的人的。因為紀律里只規(guī)定可以做什么，而法律則規(guī)定了不可以做什么，并對違反法律的人做出相應的懲治條例。前者是以道德為準繩，后者則以律法為準繩，這樣就造成了約束力的強弱。目前公司里的一些“項目”，是很模糊的，沒有書面形式的立案，沒有明確的時間限度，也沒有對物質消耗的度量以及其他條件的約束等待。這樣就存在著兩個致命的缺點：沒過多的約束，效率可能會很低；工作積極性、熱情以及責任心很低。最好能對引入獎勵機制，不能給員工產生這樣的感覺：就是做項目與不做項目的收獲是一樣的，項目做得好與做的差收獲也是一樣的。這就是為什么需要有約束力的文件備案和項目的績效。沒有約束力，就不能有效的評判完成與否、好壞之分，最終導致效率低下；沒有績效，員工的積極性就被無形的打壓住了，自然什么工作積極性、責任心全部輕若浮塵?？傮w設計（需求分析）對所開發(fā)硬件的功能、性能、用戶界面及運行環(huán)境等做出詳細的說明，要有具體的技術說明文檔。它是在用戶與開發(fā)人員雙方對硬件需求取得共同理解并達成協議的條件下編寫的，也是實施開發(fā)工作的基礎。該需求應給出功能接口邏輯等的各項要求，為后續(xù)工作提供物理和電氣性能做好準備。概要實際階段的工作成果，它應說明功能分配、模塊劃分、輸入輸出以及接口設計、運行流程設計、數據信號形式設計等，為詳細設計提供基礎。相關部門的支持，比如涉及到與計算機通訊需要軟件部門幫忙制作測試軟件等。通過總體規(guī)劃，把所需的各項資源（不同技術的人力工時）理出清單，向上級申請審批。畢竟最底層負責硬件開發(fā)的工程師對軟件有所需求的時候，不可能也沒權利給軟件部門加載這樣一個軟件任務。為什么公司內部的一些任務，部門之間存在打乒乓球的現象，就是因為項目一確立就存在著含糊的部分。比如說開發(fā)硬件，需求誰負責給出，技術指標誰負責制定，執(zhí)行中誰負責監(jiān)控等等，這些責任都不是單方面的，有很多都是部門之間或者公司與客戶之間相互協商的，由項目負責人來權衡協調，項目的職責一定要明確。永遠不要去向不懂該項目的人要這要那——或者可以說是向那些項目不關聯、不牽扯的人和部門索取信息。舉例說公司內部DAU硬件部分信息，就應該向生產部硬件室咨詢，因為這是他們的職責所在；如果你去向集測室、系統(tǒng)室等去咨詢，很有可能是徒勞，而且即使有見解，正確性又如何考究呢一句話，總體設計就是要分工和責任明確。詳細設計在總體設計方案之后，按照技術說明書的需求，著重描述每一模塊是怎樣實現的，包括實現信號控制、處理、邏輯流程等，以功能和性能要求為最終目標，選擇適當的器件以及電氣接口。在詳細設計時要力求全面周到，畢竟這里是開版做PCB的參考依據。如果說標準都出現了錯誤，后果的嚴重性也就不言而喻了。在設計功能和調試驗證時，應做好調試中修改記錄文檔，以便在后續(xù)的定版之前有個完善、清晰的參考。不要為了之前已經確定了的東西，反復查詢耽誤不必要的工時。開發(fā)（實施）原理圖、PCB以及相關的程序設計，電路調試、功能驗證。作為一個硬件項目的開發(fā)流程中的環(huán)節(jié)，這個環(huán)節(jié)應該是最為重要的，因為這個環(huán)節(jié)是把想法轉化為實物的一個關卡，自然是要求最為詳細、設計力求縝密，盡可能少出錯甚至不出錯，因為這里是縮短開發(fā)周期的關鍵點，少一次修訂，就能節(jié)省很多寶貴的時間。測試硬件產品設計的功能完善后，在調試結束后，發(fā)布之前，需要進行上機測試，考機測試，以確保產品的硬性指標和質量。編寫用戶手冊，手冊里需要明確指出：如何使用、如何測試、調試的步驟和方法等。 值得注意的是，最好測試人員不能是開發(fā)人員，以避免當局者迷的情況，而且使用者更容易發(fā)現潛在的問題。通過測試，發(fā)現歸納問題，最好能以書面形式反饋給設計人員，然后改版修訂，并重復以上開發(fā)測試步驟，直到硬件完全合格才能進行以后步驟。項目驗收經測試合格后，進行項目驗收歸檔，發(fā)布定版后的相關文檔，包括原理圖、PCB版圖、成本核算、元器件清單以及程序和軟件的歸檔備案。最終版本的歸檔備案是必須的，這樣才能增加后續(xù)項目的歸宿性、可塑性和擴展性。我們公司有些硬件的可塑性不強，就是因為當初的檔案工作不夠完善。比方說DAU數字板的問題，之前硬件室試圖改造，就是因為備案的Pal器件邏輯是錯誤的（文檔備案非最終版本），導致假定該邏輯正確為前提的設計，出現了源頭錯誤，因而很難挽回失敗的結局。項目結束以文檔形式備案項目整體過程環(huán)節(jié)情況。項目總結，項目開發(fā)完成以后，應與項目實施計劃對照，總結實際執(zhí)行的情況，如進度、成果、資源利用、成本和投入的人力，此外，還需對開發(fā)工作做出評價，總結出經驗和教訓。文檔記錄在項目開發(fā)過程中，應該按要求編寫好不同階段的各種文檔，文檔編制要求具有針對性、精確性、清晰性、完整性、可追溯性。而我們公司的現狀就是：很多成熟的東西沒有流程式的、文檔記錄式的歸檔備案，以至某些不必要的流程，每個人都要走一遍，甚至每次都要反復走一個沒有意義的途徑。比方說，新員工入職，在各自職位上甚至連一個最基本的崗位培訓都沒有。這樣就導致一個結果，每人新人都是在自己摸索，前人的經驗不能有效的傳遞下來，而老員工的應急處理能力也就被局限于之他前遇到過的問題。遇到一個他沒遇到的問題（這里可能是那些根本算不上是新問題的問題），他就會和新員工一樣茫然，如果更老資歷的員工已經離職，那么如何處理問題就會變得很難，這就是為什么我們不能站在前人的肩膀上的原因——沒有備案的經驗總結。參看如下表3-1，這里只是示意性的參考。項目階段所需文檔說明項目說明項目來源背景等項目立案之前可行性分析報告市場調研、為滿足特定需要等技術調研報告技術可行性（此文檔可包含于可行性分析中）項目啟動審批以及說明項目立案、參與人員組成等立案開發(fā)初步計劃制定研發(fā)總體規(guī)劃其他部門的支持和需求項目牽扯軟件、預算開銷以及耗費（庫房）總體方案開發(fā)詳細方案原理圖等具體要求修訂記錄調試中發(fā)現新問題的修改備案記錄測試手段流程測試中發(fā)現新問題如何解決提交驗收測試驗收報告產品發(fā)布技