泛讀構建之法的三個問題

一、我在《構建之法》第一章看了這一段文字 （什麼是好的軟件？一些同窗認爲，所謂好軟件，就是軟件沒有缺陷（Bug），所謂軟件工程，就是把軟件中的Bug都消滅掉的過程。這的確是抓住了軟件工程的一個要素。和軟件打交道的專業人士都知道軟件有（Bug），軟件團隊的不少人都成天和Bug打交道，Bug的多少能夠直接衡量一個軟件的開發效率、用戶滿意度、可靠性和可維護性。），有這個問題 （Bug是越少越好嗎？）。 我查了資料，有這些說法（根據逆反原理，假設一個bug都沒有的項目，是否就說明該項目質量必定就很好呢？顯然是不正確的，很大程度上說明這個測試團隊的測試經驗已經測試能力體現不到位。還有開發人員能力良莠不齊，當發現某模塊bug數越多，修改的bug越多，則引入新的bug就會越多，（非官方統計：修改3個bug，就會引入1個bug）那麼這些新的bug發現的難度要比修改前發現bug要大的多。那其隱藏未發現的bug數量就越多，那麼相應的模塊質量也就越差。），根據個人實踐，我獲得這些經驗（Bug天然是越少越好，Bug的數量對於軟件的質量是很重要的）。 可是我仍是不太懂，個人困惑是（Bug對於一個軟件來講，是越多好仍是越少好，若是Bug沒有，軟件就是相對比較基礎簡單的，可是Bug若是數量增長的話，又不是很好的能夠控制，對於一個軟件的質量來講是相當重要的）。
二、我在《構建之法》第八章看了這一段文字 （投入和回報不是一個線性的關係，有時投入根本看不到回報，另外一方面，若是在質量上作到極致，達到高級工匠的水平，會對團隊成員自己和用戶產生巨大影響），有這個問題 （投入和回報應該是線性的關係，由於我以爲你投入的越多，就會有必定的相應的成果的）。 我查了資料，關於這方面沒有一個確切的說法，根據個人實踐，我獲得這些經驗，投入與回報因人而異，每一個人的點都是不同的。
三、我在《構建之法》第九章看了這一段文字 ：PM的核心要求是：根據市場和用戶需求，協調各部門資源，正確地把握產品定位和方向，解決用戶的痛點，持續優化產品。，有這個問題 （例如微軟公司有幾類的PM，那麼PM之間如果產生了意見分歧，怎麼辦？是否是一個軟件就會廢了）。 我查了資料，有這些說法（其實多數狀況下一個項目裏面都只有產品經理，我的以爲這樣比較好，雖然比較難，但就不存在多頭領導了，搞那麼多leader，把你們都弄暈了不說，還容易出現矛盾。），根據個人實踐，我獲得這些經驗（PM之間仍是要找一個互相理解的，最好仍是一我的，若是軟件的工程的工做量巨大，仍是找一個相對口的人比較好點。