關(guān)于兩者之間的關(guān)系，我是這樣理解的。質(zhì)量是我們的根本要求，離開(kāi)了質(zhì)量其它就不用談了。效率則是提高質(zhì)量的關(guān)鍵。項目開(kāi)發(fā)總是受到進(jìn)度、人力等各方面資 源的限制，只有效率提高了，才可以取得最好的質(zhì)量。離開(kāi)質(zhì)量這個(gè)根本空談效率是沒(méi)有意義的，沒(méi)有好的效果，效率只會(huì )是一種浪費。

　　那么什么是高質(zhì)量，它的標準是怎么樣？以下幾點(diǎn)應該可以作為一種標準

　　缺陷率低

　　代碼的結構良好，可重用性、擴展性好

　　代碼的可讀性強，易于維護

　　豐富的維護手段，可維護強

　　目前項目組中存在那些不足呢？大概有以下幾個(gè)方面

　　一些模塊的封裝性不好，與其它模塊耦合度比較大，這導致代碼的可移植性不好。

　　軟件的維護手段不夠，出了問(wèn)題很難定位。

　　資產(chǎn)管理做的不好，以前積累的技術(shù)輸出沒(méi)有專(zhuān)門(mén)的管理，時(shí)間久了就流失了。需要的時(shí)候也很難找到。

　　小特性開(kāi)發(fā)后，沒(méi)有相應的功能和設計說(shuō)明文檔，不便于其它人員了解特性。

　　其它產(chǎn)品發(fā)現和解決的問(wèn)題，沒(méi)有及時(shí)同步過(guò)來(lái)。

　　分析設計過(guò)程中，方案討論、檢視的投入不夠。導致特性開(kāi)發(fā)的設計不夠好。

　　一些工作改進(jìn)的思考

　　為什么要強調特性設計文檔？沒(méi)有設計文檔，開(kāi)發(fā)人員的設計思想就無(wú)法傳承。后繼的開(kāi)發(fā)人員通過(guò)代碼很難完全理解前人的設計。那么開(kāi)始設計好的結構就很可能被破壞。其人開(kāi)發(fā)人員不容易維護。

　　還需要調試和維護指導書(shū)。特性開(kāi)發(fā)人員自己在調試和問(wèn)題定位的過(guò)程中，會(huì )形成一些調試方法和定位問(wèn)題的思路。這對于特性的維護是很重要的。目前這部分的知識還沒(méi)有能夠記錄下來(lái)�？梢酝ㄟ^(guò)調試和維護指導書(shū)的形式將這部分的知識記錄下來(lái)。

　　在目前的特性開(kāi)發(fā)流程中，具體開(kāi)發(fā)人員由于受能力和知識的限制，在設計中常常無(wú)法考慮的很周全，只注意到了功能的設計，忽視模塊化、兼 容性、擴展性方面的考慮。項目組有經(jīng)驗開(kāi)發(fā)人員的經(jīng)驗的能力不能為這些特性開(kāi)發(fā)做出足夠的貢獻。一方面是由于受時(shí)間的限制，無(wú)法投入足夠的精力。另一方 面，所提出的建議無(wú)法對特性開(kāi)發(fā)人員產(chǎn)生約束。為解決這個(gè)問(wèn)題，可以考慮在開(kāi)發(fā)流程中增加一個(gè)環(huán)節，來(lái)專(zhuān)門(mén)檢查設計的模塊化、兼容性、擴展性�？梢宰鲆粋�(gè) checklist，只有全部通過(guò)了，這個(gè)設計才可以通過(guò)。

　　為什么我們的根因分析總是流于形式？大部分問(wèn)題的根因還是會(huì )歸根于項目組日常管理工作的不到位。如檢視投入不足，受技能水平的限制等。解決這樣問(wèn)題的關(guān)鍵還在于改善項目組的日常管理工作，否則，同樣的問(wèn)題還是會(huì )發(fā)生。

　　資產(chǎn)的管理也是一項比較重要的工作。一方面要輸出各種文檔，另一方面要加強對文檔的管理�，F在存在的問(wèn)題是，隨著(zhù)時(shí)間遷移、組織結構的變化證這些文檔資產(chǎn)漸漸的遺失了，相關(guān)的開(kāi)發(fā)人員不知道這些文檔的存在，更不用說(shuō)去找了。

　　提高質(zhì)量和效率或許都可以看作是一個(gè)目標，一個(gè)結果。重要的還是要關(guān)注項目運行的過(guò)程，既包括開(kāi)發(fā)的過(guò)程，也包括日常工作的過(guò)程。對項目經(jīng)理來(lái)說(shuō)， 一個(gè)特定問(wèn)題的解決常常并不困難。而項目經(jīng)理面對的往往是一堆的問(wèn)題，這些問(wèn)題放在一起，就會(huì )變得紛繁復雜。項目經(jīng)理的資源又總是有限的。如何找到關(guān)鍵問(wèn) 題，并將改善工作有效的落實(shí)下去，才是需要一些智慧的。