你會項目管理嗎？

時間 2019-11-07

標籤項目管理简体版

原文原文鏈接

你會項目管理嗎？

第一節原始的開發流程程序員

1、需求調研與分析數據庫

客戶來了，領導和項目經理吹噓一番，項目就接下來了（這個時候什麼都能作，只要給錢，哈）。需求呢？只有客戶發來的一張紙：「咱們須要XX系統，要實現XX，XX功能」。沒有太長的調研過程，由於項目經理急着要全部人開工，客戶急着看到界面效果。分工，全部人開始查資料，寫需求分析。編程

通過兩三個周的集體努力吧，需求說明書出來了，也有了幾個簡單的界面原型。沒有每一個需求的細緻、深刻的溝通，客戶又看不懂專業的SRS（需求規格說明書），雖然在項目組內會有屢次的評審及修訂，那大都是本身揣摩的，不必定符合用戶要求，沒有評審的標準，由於沒人清楚用戶在想什麼，最搞笑的是，客戶雖然看不懂，但卻不認可本身看不懂。反正客戶想：「等大家作出來，看看不行再改，軟件嘛，又不是蓋樓。安全

」需求階段驗收「順利」經過。服務器

2、開發架構

到開發人員上場了！！併發

開發人員最願意幹的就是寫代碼，而不是慢慢悠悠地寫設計文檔，由於沒有成就感。若是這時候項目經理不約束，不加以控制，弄很差項目結束時你就看不到詳細設計！（^_^）沒有詳細設計，SRS是本身寫的，寫代碼的時候根本不用參照什麼，也沒什麼參照。很快，程序寫完了。。框架

作軟件最怕什麼？怕「新」。新手，新技術，新業務。若是隻點一項，項目仍是有保障的。若是項目中有那麼三兩我的這三項全點，很快寫出來的程序質量能好到哪去？你想去吧。函數

沒有正規的代碼評審，由於代碼太多了（十幾萬行？），問題也太多了，雖然不致於每行都有問題。技術好的慢慢看一遍吧，唉，通常作爲技術高手，容不得問題，看到就想改。這麼多代碼與問題，能看完改完嗎。這段時間，成爲技術高手的最忙期和普通開發人員的最閒期。工具

3、客戶體驗

這個時候由於軟件大致能用了，按照極限開發的理論，增長客戶體驗。客戶不懂SRS，不懂數據庫結構，不懂代碼，但這時候他看到界面了，懂了。。「原來這幫人忙來忙去，就作出來這麼個醜陋還總出錯的東西」，「界面很差看、用語不許確、操做不習慣、甚至流程根本不對嘛。。。」，問題全來了。

全部開發人員都在解決屬於本身的Bug，畢竟客戶提出來的，能不改嗎？

「早幹嗎去了，都快作完了，又改動這麼大？」

「上次不是早這樣改嗎？怎麼又改回去了？」

「前天客戶提出來的問題改了嗎？」「我看看代碼」

「這個地方爲何改爲這樣？基於什麼需求改的？」

。。。

在軟件開發出來的早期階段，關注點原本應該是功能走正常流程的正確性，如今咱們全盤關注，因此好累啊！客戶提出變動的時候，咱們沒記錄（或者說沒有全員理解的記錄），解決完了也沒記錄，因此每次都在回憶中理解和修改代碼。

開發、用戶提出需求、修改、變動、再修改。。。不少Bug，咱們本身甚至都懷疑本身的能力，怎麼界面打開就報錯？怎麼又執行不下去了？怎麼又有腳本錯誤？

4、系統測試

咱們以爲本身應該抓緊作內部測試，要否則客戶老提問題，這時更別說進度了。誰作測試呢？對系統熟悉的人作測試，測出問題誰修改？對系統不熟悉的人作測試，怎麼知道對仍是錯，又沒有標準。爲何沒標準，由於到如今爲止，客戶的需求大多還裝在客戶的腦殼裏，咱們哪一個文檔詳實地記錄了客戶的需求？

測吧，感受有問題就提出來，有問題就直接找相關的開發人員，抓緊解決。開發人員和測試人員都不肯定，這時應該找客戶確認，並且應該抓緊確認（因此我感受應該給項目經理報銷電話費，至少配個固定電話，呵）。有時感受本身的想法就對，就這麼定下來吧，改吧，最後可能才知道是錯的，或者有的功能都是多餘的。

測出來的問題怎麼管理的呢？郵件、口頭、MSN。別人再見到相似的問題或相關的問題如何處理呢？繼續走上面的流程，時間在流失，成本啊！

5、結局

寫代碼煩了，測試也作煩了，都在報怨「客戶爲何還不驗收完！？」

終於，全部人不堪重負，項目草草收尾。

結果是，領導報怨爲何用這麼長時間，花這麼人力物力；

客戶報怨不定期交付，質量又差，提問題讓修改吧，本身都煩了；

研發小組報怨太辛苦，加班又沒有加班費；

項目經理報怨這些人真不會幹活，質量差不說，態度還很差；

再而後，名聲愈來愈很差，能接到的項目少了，入不敷出，因而有人要降工資，有人就辭職走人，再而後：「怎麼和原來的公司同樣？」、「其實原來只要哪一個方面再作得好點，不至於今天這樣」。。。

第二節開發過程的改進

資本主義的生產性爲何高？由於有了社會分工。咱們也來把項目人員區分一下看看有什麼效果：

項目經理(PM)：咱們意義上的項目經理其它有兩個角色，項目管理和程序規劃經理。

負責資源調度、人員管理、進度控制、制定開發計劃、與客戶商定需求、

書寫需求設計文檔，需求變動管理、解決方案的編寫、項目實施等。

開發人員(Dev)：這個咱們最熟悉了，由於咱們都是開發人員，：）

編碼、寫詳細設計（寫不了詳細設計的，不要強壓，項目經理負責寫），作單元測試

測試人員(Tester)：這一直是咱們的軟肋，雖然咱們一直對外宣稱有專業的測試人員。。。

寫測試計劃、測試用例、根據項目經理的需求設計文檔作模塊和系統的驗證測試，還有其它的一些非功能測試，我不是專職測試的，誰明白那些壓力測試、冒煙測試、強化測試、容量測試、等等怎麼作，請告訴我！

以上是咱們你們都很是熟悉的人員體制，咱們的項目大致也是按這個體制進行的，可是咱們的職責清晰嗎？每一個人每一個階段具體要作什麼呢？有什麼制度或工具來保證上面的流程走下去嗎？爲何項目難以管理，進度都要依賴於項目經理的口頭或郵件督促？爲何項目中有人忙得要命，有人卻沒事作？

咱們來分析一下上面的開發過程當中有哪些最重要的問題：

1.沒有弄清楚用戶需求

需求，仍是需求！最讓開發人員痛苦的事情，真是生也爲它，死也爲它。有不少方法來描述需求，數據流圖、UML用例圖、時序圖，連開發人員看起來都比較費勁，客戶會理解它嗎？咱們是在做秀嗎？

建議使用客戶、開發人員、測試人員、領導都能看明白的方式來描述需求。客戶和開發人員明白，就會下降開發完還有大量不一致的地方；測試人員明白，就能知道測試的依據；領導明白，呵，若是老闆不明白，他就不知道這幫傢伙到底在幹嗎，是在真正幹活仍是在偷懶，到底工做量是大是小，軟件功能是複雜仍是簡單。老闆若是不明白，他在給預資源和時間上就會很謹慎，會到處設防。

有什麼好辦法呢？用戶提需求時東一句西一句，老是跟咱們程序員的嚴謹造成鮮明對比。如何和用戶一塊兒整理這亂亂的需求？

想讓人能從千絲萬縷中理出頭緒，因而腦圖軟件上場。把各個分支前因後果表現清楚。

到了描述某個節點的時候，PPT上手。一頁PPT想當於一個界面窗口。每頁PPT的圖形模仿了菜單、輸入框、按鈕。按鈕按下，還能夠跳轉到其它的PPT頁上，和軟件操做流程很是相似。

關於PPT的詳細描述，如字段、流程、特殊注意事項、特殊控制事項，都用word說明爲好。

遇到有報表功能的時候，用Excel把報表畫出來，讓程序員喜聞樂見。

這些需求從用戶的角度出發，不須要描述怎麼實現，什麼JavaScript、數據庫結構、框架等等都扔到一邊，它們最先也應該在概要設計裏面出現。如何寫好客戶需求，請看《寫好MRD的10種技巧》。

2.設計階段丟失

在沒有考慮清楚軟件功能如何實現以前，請勿開始敲代碼，Boy, Slowly, Slowly...

設計分爲概要設計和詳細設計

概要設計作什麼？

·分析系統架構

·從用戶需求中提煉業務功能，並轉化爲工做量差很少的功能點，獲得功能點列表

·項目經理根據功能點的優先級，開始編寫概要設計說明書。

每一個功能點的概要設計應包括：

界面草圖或用PPT畫出來的示意圖

界面上每一個字段的說明（如默認值、不可爲空、輸入約束、等等）

業務流程，用文字或流程圖表示

運行要求，如易用性、安全性、性能、數據量、併發性等等

此時獲得的概要設計說明書，還缺乏表結構和對數據表的操做流程。可是不急，針對用戶的操做流程是否合乎需求？須要將這份文檔交由測試人員仔細審覈，測試人員根據需求分析的結果，逐項對比，保證設計的正確性、可測試性、完整性。

確認概要設計和用戶需求一致後，咱們開始設計數據操做流程。由經驗豐富的開發人員來全盤考慮，從性能、擴展性等方面，設計出可用的表結構、視圖和存儲過程。

有了表結構，就能夠在設計文檔中補充數據操做流程了。

詳細設計。。。詳細設計還須要設計什麼？應該由誰來寫？寫到什麼程度，函數接口級仍是僞碼級？不一樣的項目，不一樣水平的開發人員，應該區別對待。

3.代碼Review

項目經理並非一會兒把全部功能點的設計文檔全寫完。根據功能的優先級和關聯性，先寫重點功能及其關聯功能，寫出一個就能夠由開發人員編碼實現，在每一個開發人員都寫完一個模塊的代碼時，應該組織一次正規的代碼Review。

代碼Review能夠有多種方法：

·各人在本身的電腦上通讀代碼，發現問題記錄，而後彙總，開會討論，統一解決。（華爲就這樣，呵）

·各人先熟悉一下要評審代碼的基本流程，而後開Review會議，由開發者從頭逐行講解，每人均可以提出疑問，記錄並討論，統一解決。（NEC是這樣的，呵）

代碼Review有什好處呢？

·避免後續的開發出現同類問題：通過一次深刻細緻的講解，把常見問題都解決，後續犯同類問題的可能性大大下降；

·項目經理根據開發人員的代碼及反饋，在寫設計時會更有針對性

代碼Review造成文檔，並應該注意積累常見問題及解決方法，在全部項目中都適用的。

4.測試出的Bug處理流程

測試人員測出問題，交給相應開發人員解決，測試人員驗證是否修改。上述看似是Bug處理的最短路徑。

首先，測試人員發出的問題真的是問題嗎，由誰來確認？

還有，這個Bug是怎麼解決的？什麼時間解決的？

其餘人是否是還有可能犯一樣的Bug？

因爲沒有專門的工具或系統來記錄這些Bug是怎麼產生的，是怎麼解決的，給後續的開發和統計形成很大的難度。

換一個流程試試：

² 測試人員發現Bug，記錄到Bug管理系統中，須要記錄的數據有：操做步驟，輸入的數據，結果什麼樣，應該是什麼結果，責任人是誰（能夠直接寫項目經理）。。。

² 項目經理看到Bug列表以後，分析Bug是否須要解決，要讓誰解決，而後就能夠轉給相關開發人員

² 開發人員重現Bug，檢查代碼，修改，記錄緣由和如何修改的，而後轉給測試人員驗證。

² 測試人員驗證之後，關閉這個Bug。

有了Bug管理系統中的數據，上面的問題還存在嗎？

5.需求變動的流程

客戶發現問題或又提出新的變動，無論是電話仍是郵件，都應該詳細的記錄下來，而且應該是項目全員都應該知曉。

記錄了客戶新提出的需求或對原始需求的變動，包括需求提出人，提出時間，功能模塊名，客戶如今的版本號，需求描述等等。咱們在討論時就有據可查，客戶說不對時也有證據。就算是暫時不實現的需求，也能夠有備案，等後續系統升級時，就有針對性。

有了這些需求，要按期給領導一份，這代表你項目組的工做量，讓他看看你確實一直很辛苦地在工做，並且幹了這麼多活，並且這也能看出你工做的仔細負責態度。

建議每當客戶提出新的需求或變動時，都要開項目會議，把需求講明白，並使用上面提到的腦圖軟件+PPT+Word+Excel工具，把這個需求描述的清清楚楚。

6.項目經理權力分割

項目經理如今須要作這些事情：立項、需求調研、創建開發計劃、配置管理、編寫需求規格、編寫設計說明書、人員管理、控制進度、Bug分析和任務分派、與客戶溝通、向領導彙報、總結與分析、控制風險、客戶驗收、結項，甚至有時候還得寫大量代碼，還甚至寫測試用例、作測試、發佈版本。。。

項目經理的權力太大了，想作項目經理，但這麼多事，在有限的時間能作完嗎？能作好嗎？我以爲應該把項目經理分爲兩個，一主外，一主內。暫且稱爲項目經理和開發組長吧。

項目經理有如下職責：立項、需求調研、創建開發計劃（只定好大的時間點）、編寫需求規格、人員管理、Bug分析、與客戶溝通、總結與分析、控制風險、客戶驗收、結項

開發組長有如下職責：創建詳細開發計劃（具體到模塊）、編寫設計說明書、控制開發進度、Bug分析和任務分派、總結與分析，有時間的話，寫一些代碼。

項目經理主要從客戶的角度關注需求，從較高的層面關注項目進展，其它的都分下去吧，不然真夠累的。

發佈版本是誰的活呢？我認爲在小項目組內應該是測試人員。測試人員控制軟件的版本和發佈，由於每一個版本的質量由測試人員把關，他說能發佈才發，有問題能夠拒絕發佈。因爲版本號由測試人員統一來定，客戶的軟件出了問題，是哪一個版本的，便於定位。

版本號怎麼定義，你們能夠看一下微軟的一些軟件版本編號：8.5Release2 Build 3，這什麼意思，測試人員去研究。：）

7.開發任務的分配

某個任務何時給誰分配的，什麼時間作完的，出了多少問題。這涉及到項目經理和開發組長的兩個職能：總結與分析、控制開發進度。

總結是爲了給上級領導彙報工做、給客戶反映進展狀況；

分析是爲了發現規律，如什麼問題常常發生，誰常常犯錯，誰的進度老是趕不上，。。。，固然也是爲了控制開發進度。

實際上一個Excel表格就能記錄開發任務進展的全部數據。誰來維護這個開發任務表呢？開發組長仍是開發人員？

建議由開發組長列出功能，分配任務，規劃時間點，開發人員補充結束時間和當前情況，也能夠由開發組長主動詢問進度，更新到這個表格中。

8.功能點的優先級

若是系統劃分出來的功能點較多，超過50個，最好應該考慮分階段開發。

第一階段完成重要的業務功能，還須要儘可能保持系統的完整性，完成後就能夠作集成測試和發佈，這樣有利於提升你們的積極性和成就感。

第二階段完成應該包含的功能，須要從新計劃，因第一階段作完後，通常技術或業務能力都有較大的提高，這個階段應該比較短。

第三階段完成最好包含的功能，若是時間不容許，分到這個階段的功能點能夠暫時不實現，把精力集中到前兩個階段的成果上，保證質量。這些功能點能夠留到下一個版本中。

以前的項目雖然有對功能點的分級，但這個級別沒有對項目計劃的制定起到太大做用，並且功能點很是多，細分的話有一兩百個，致使每一個階段的時間特別長，每一個人都容易疲勞。

第三節 Bug管理系統有什麼好處？

一、創建起Bug記錄的統一平臺

Bug的一輩子和人的一輩子是同樣同樣的，從出生（建立）到成長（調查、解決），再到死亡（關閉）。也有的Bug沒有這個生命週期，還沒出生就歐了。。那它確定不會Bug

二、實現工做流程的自動化

計算機如此發達的今天，你還願意跑來跑去嗎？

三、知識積累

新老員工之間的差異在哪裏？我以爲很重要的一點就是老員工有解決各類Bug的方法。

某個單位來了一個新員工，只要管理員給他註冊一個賬號，給他一個口令，他本身上網就能夠看到符合他身份的權限範圍內的企業內部積累下來的各類知識，這樣就減小了不少培訓環節，並且可以使新員工迅速進步。

四、績效考覈

這一點很是重要，由於它關係到咱們的工資與獎金。但卻老是被不少項目經理忽略。來看看如何統計每一個人在項目中的工做量及工做質量吧。。。

項目成員主要歸項目經理來考覈，那就是要考覈開發人員和測試人員。（根據大部分中小IT企業，測試人員沒有獨立的小組或部門）

開發人員：開發了多少個功能點，共產生多少Bug，Bug的分佈狀況，對應了多少需求變動；

測試人員：測試了多少個功能點，有多少測試用例，測出多少Bug，測出Bug的重要程度；

若是沒有Bug管理工具，關於測試用例與Bug數量的統計這些相當重要的度量數據誰來計算？

誰來證實你的水平高呢？若是沒有數據，就沒人信服，更不會讓領導重視。

誰來證實你的工做量？若是咱們每週給領導看一下咱們本週開發了多少功能，對應了多少需求變動，解決了多少Bug。。。

領導還認爲咱們天天都在那裝作很忙嗎？要求加薪的時候咱們要用數聽說話，而不是「累死累活」、「加班加點」、「沒功勞有苦勞」。。。

還有一點我不得不說，項目進度和質量取決於誰呢？想一下木桶原理。。。應該是水平最低的那個吧。怎麼找到這麼關鍵的人，在開發過程當中給予更多的關注呢？

第四節需求管理、開發任務管理、Bug管理三者的關係

需求管理是對客戶提出的需求進行維護，有新需求，有變動，有是否已實現。。。

開發任務管理是開發組長給開發人員分配的，有新分配的任務，有任務的狀態，也可能有任務的轉發。。。

Bug管理是測試人員提給開發人員的，有新Bug，有Bug的狀態，有Bug是如何解決的過程。

三者有共同點，固然也有部分不同的信息，有沒有辦法使用同一套系統來管理這三塊內容呢？有不少公司已經這麼作了，哈。。。具作怎麼作，讓咱們一塊兒來慢慢研究吧。

這三個管理工具你還不想用起來嗎？再給你個想用的理由：

咱們作開發的，倒底幹了多少，中間出了多少問題，客戶提了多少需求變動，這些領導關注嗎？他不關注，只要項目合同簽下來，款項能結回來，別的領導是不會在乎的。他們最關心的是：怎麼還沒作完？何時能作完？是否是這些開發人員成天瞎搗騰，欺負他不懂編程序糊型他？因此領導對開發人員都不太信任，疑神疑鬼，也不給主動漲工資。誰要是能常常籤個單子回來，就會有大把獎金。作爲開發人員，其實最辛苦，又不能拿着代碼作爲成果給領導看。因此咱們須要能明確報告開發人員倒底作了些什麼，到底作的程序如何，但願領導能放心，能看到研發人員的工做辛苦和努力，漲薪水的時候纔會向咱們傾斜。：）

第五節咱們倒底須要什麼？

咱們一直在追求CMM，一直宣稱以CMM3的流程來開發項目，實際作到了嗎？如何作好項目管理，如何作好需求調研，如何改善產品質量，如何調整和老闆的關係，如何提升員工的工做能力和工做積極性。一大堆問題擺在面前，引入自動化測試也很差用，引入版本管理也很差用，引入日清日畢也很差用，到底一個團隊該如何管理呢？也看了CMMI、RUP的書，但不解決問題。

也許咱們須要想，就咱們目前能擁有的權力和資源，咱們如何一點點改進？

各成員的主要職責

再次複習一下項目團隊中各個角色的主要職責：

項目經理：立項、解決方案的編寫、需求調研、創建開發計劃（只定好大的時間點）、

編寫需求規格、人員管理、Bug分析、與客戶溝通、需求變動管理、

總結與分析、控制風險、客戶驗收、結項

項目經理需求很高的技術水平嗎？你看呢。。

項目經理是客戶與研發小組，領導與研發小組之間的窗口。

每週的週報是必要的，讓客戶和領導都明白當前的狀態。

要常常學習客戶所處的行業知識，總結一些需求調研技巧和溝通技巧。

開發組長：參與評審項目經理寫的需求規格，創建詳細開發計劃（具體到模塊）、

編寫設計說明書、控制開發進度、Bug分析和任務分派、總結與分析，

有時間的話，寫一些代碼

是項目經理和開發人員，測試人員和開發人員之間的窗口。

開發人員不該該脫離開發組長單獨行動。

開發組長作的是是從業務到實現的轉化，因此須要開發組長對業務和開發

都有着較深的掌握。

開發人員：參與評審項目經理寫的需求規格，評審開發組長寫的設計文檔，

根據詳細設計編寫代碼，單元測試，修改Bug

測試人員：參與評審項目經理寫的需求規格，評審開發組長寫的設計文檔，

寫測試用例，執行測試，提出Bug，驗證Bug，彙總測試情況、

軟件版本的管理、軟件的發佈、兼配置管理

平常學習各類測試方法

其實還遺漏了兩個重要角色：美工和文案，算了，公司沒有，並且成本也不低，每一個成員都努力吧。

作爲須要常常與客戶及時溝通的項目經理，如下工具必備：

郵件、MSN、QQ（客戶大多喜歡QQ）、固話。咱公司封QQ、不配備固定電話，唉，惋惜了兩種好工具。腦圖軟件、PPT、Word、Excel，寫需求規格必備！作爲項目經理，你寫的需求得讓全部人明白，因此把開發相關的事交給開發組長，努力把需求寫明白，寫清楚吧；需求管理工具。記錄需求是基於什麼提出的，爲何變動，是否已反應在產品中等等。

開發組長鬚要的工具很少，總結起來就兩個模板和一套系統：開發任務分配模板、概要和詳細設計模板、Bug管理系統。

開發人員越專心越好，因此一套IDE集成開發環境，一套CVS/VSS足矣。

測試人員最經常使用的就是Bug管理系統，寫測試用例用它，執行測試記錄Bug用它，彙總測試情況還用它。

人力配備

項目經理 1

開發組長 1 + （1-3）名開發人員作爲一組

測試人員 1

開發組長除管理開發人員的進度和任務分配外，還有可能本身也參與一部分代碼的編寫。因此最多隻能管理兩三名開發人員。若是項目規模較大，參與的人較多，就要配備不止一個這樣的小組，那項目經理的職責還須要有協調各個開發小組。測試人員根據規模不一樣，可配備一到兩名。

作一個項目就是這樣，打的就是一個配合。

第六節質量與時間成本

有人問了，把人力這麼一分，實際寫代碼的人少了好幾個，開發速度不就大下降了嗎？這套方法有實用性嗎？那麼咱們來分析一下開發質量與速度或者說時間成本的關係。

幾乎全部人都但願咱們作項目時，質量又好，速度又快。

傳統的觀點認爲：功能、質量、成本是鐵三角的關係，在功能不變的狀況下，不可能在提升質量的同時下降開發成本。

可是咱們想想，咱們在開發過程當中，原本想以犧牲質量來加快速度的時候，文檔不寫了，該記錄的不記了，該評審的和統計分析的也不作了，結果反而花了更多的時間，項目一拖再拖，質量也犧牲了。

把每一步都作好，從開發的前期來看，花的時間可能比別人多，但從整個任務來看，反而有可能以別人幾倍的速度完成。

可是作到什麼程序纔算好呢？是否追求完美？那固然不可能，若是一個軟件沒有Bug，那它確定沒有任何功能，也沒有任何價值。因此必須找到一箇中間質量點，低於這個質量點，想犧牲質量來趕進度，只會拔苗助長，質量越低耗時越長，高於這個質量點，想提升質量就得增長成本。

圖1.時間和質量的關係

如上圖所示，咱們必須找到一個合適的中間質量點，不一樣類型的項目，不一樣行業的項目，中間質量點應該是不一樣的。

精確的質量點，咱們找不到，因此只能肯定一個小的範圍。中間質量點在項目中體現爲何呢？不知道你們是否記得在華爲作項目時每一個階段驗收時的質量目標。咱們不該該爲了達到質量目標而去調整評審結果，去故意把提示性的問題改成通常性問題，反過來也不對^_^。若是咱們的文檔或產品沒有達到這個質量目標，差距還較大的話，極有可能會影響開發進度，即便投入了大量人力，仍是挽回不了拖期的結果。

咱們應該根據不一樣的行業，和不一樣類型的軟件，根據開發經驗和數據，得出咱們本身的質量目標。航空航天類的系統要求比較嚴格，每一個階段的質量都應達到95%以上吧，企業管理類的85%就不錯了。若是平時不注重積累，沒有評審和Bug的記錄，咱們何時才能總結出質量目標呢，怎麼判斷是否能夠進行下一階段了呢？

第七節除此以外

除了上面的體制創建和各階段的工做方法，我但願可以造成如下幾個簡單的工做習慣：

1.每日彙總

天天下午5：00，由開發組長統計開發人員的進度，詢問遇到的問題，更新工做任務表；

2.晨會制度

天天早上，項目全員開會，大約只用十分鐘時間

² 項目經理說一下昨天有沒有變動，說一下當前的整體情況，須要注意什麼問題；

² 開發組長說一下開發人員的任務安排，本身設計說明書的進度；

² 每一個開發人員說明一下本身負責模塊的開發狀況，何時結束，有沒有困難，是否須要代碼評審，須要什麼支持，如缺乏外部接口。。。

² 測試人員說一下測試用例的編寫狀況，測試狀況，遇到什麼問題

3.周總結