是見到結(jié)果就完事了，要將代碼打印出來，相關(guān)人員對代碼的整個實現(xiàn)過程進行評價，提出修改建議，代碼修改后，需要再審，也是通過以后才能提交入代碼庫，進行代碼的組裝。
當時認為日本的方法太浪費時間和人力了，對技術(shù)人員個人的能力估計的太低，怎么能提高工作效率吶?？墒擒浖|(zhì)量問題的頻繁出現(xiàn)，是我們不斷的認識到，開始浪費一些時間和人力，控制好每個細節(jié)的質(zhì)量，就是省去了許多時候為解決質(zhì)量問題而進行的新的時間和人力的支出。省去了大量的軟件后期的質(zhì)量維護費用。總的來看是核算的。為提高項目的質(zhì)量，降低成本，必須從項目的開始就要做好質(zhì)量的控制工作。
3、項目范圍管理理論解決了項目開始需求不清的問題
需求管理是項目范圍管理中的問題，這是因為它實際上是開發(fā)過程中的所有管理原則的先決條件。只有在開發(fā)的目標被清楚明白地表述和理解的情況下，軟件開發(fā)才能以一種有計劃的有序的方式進行。實際上，沒有文檔化的需求，在開發(fā)工作完成前后都很有可能發(fā)生產(chǎn)品與要求的偏離。計劃、追蹤、配置管理以及軟件質(zhì)量保證這些在其他關(guān)鍵過程中涉及的原則，都是從一個穩(wěn)定的基礎(chǔ)開始的，那就是文檔化的需求基線。
什么需求?需求是指“分配給軟件的系統(tǒng)需求”，或者更簡潔地說，“分配需求”。這些需求有可能是技術(shù)方面的(比如：功能和性能需求)，也有可能是非技術(shù)方面的(比如：發(fā)布日期，開支限度)。
區(qū)分開需求管理和軟件需求分析是很重要的。一旦分配需求被文檔化，并且被所有受影響部門(客戶，系統(tǒng)工程，軟件工程)通過，需求管理的基本工作就完成了，所剩下的就是管理變更而已。沒有證據(jù)證明分配需求本身就可以十分清楚完整的作為軟件開發(fā)的全部基礎(chǔ)。事實上，通常它們不是。
優(yōu)化和精確描述需求，填補漏洞，將含義表達得更清楚是軟件需求分析要做的，分析的結(jié)果被稱為“軟件需求“。這樣，作為需求管理的輸出的分配需求實際上就成了軟件需求分析的輸入。需求管理遠遠先于軟件開發(fā)的技術(shù)行動，而軟件需求分析則是關(guān)鍵開發(fā)技術(shù)行為的第一步。
從這里的描述看來，需求管理的活動簡直太簡單，太基礎(chǔ)了，顯然沒有哪個軟件開發(fā)組織會不有效的進行著這種活動。問題經(jīng)常出在企業(yè)對透明度的懼怕?？蛻粲X得保持需求含糊不清，松散或者無正式文件能夠給他們更多的機會去說：“那并不是我所要的，那并不是我認為的需求的含義”。文檔化清晰的需求可能迫使用戶在系統(tǒng)滿足了文檔化的需求但沒有滿足實際需要的情況下，為開始變更負責。相似地，開發(fā)人員覺得含糊不清，松散或者無正式文件的需求能給他們更大的余地，允許他們與預算和進度盡可能地接近，然后說：“這就是我們所認為的需求的含義，如果你需要其他的什么東西，你必須另外付出代價?！蔽臋n化清晰的需求會迫使開發(fā)者承擔滿足這些需求的義務，并使他們暴露于開支、進度評估不準確的風險之下。
這樣一來，盡管客戶與開發(fā)人員的利益動機相對，但他們卻走到了一起。每一方都認為他們在保護自己的利益，鞏固自己討價還價的地位，但是事實上每一方都在走向?qū)淼氖蜖幊?，為項目埋下了一刻定時炸彈。
4、項目時間管理理論指導我們在項目管理中怎樣抓主要矛盾
以前進行項目管理時，是根據(jù)經(jīng)驗和每個人的工作特點，進行項目的分工的，軟件項目基本是按照需求分析，概要設(shè)計，詳細設(shè)計，代碼編程，調(diào)試和測試，用戶驗收等幾個主要過程來進行的。但將項目分工更加細化，每個小過程的時間估算是多少，整個項目可以最短用多少時間來完成，怎樣合理安排人員，怎樣抓項目中的關(guān)鍵環(huán)節(jié)等等，這些都沒有進行過量化的分析和管理。
項目