泛读构建之法的三个问题

1、我在《构建之法》第一章看了这一段文字 （什么是好的软件？一些同学认为，所谓好软件，就是软件没有缺陷（Bug），所谓软件工程，就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有（Bug），软件团队的很多人都整天和Bug打交道，Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。），有这个问题 （Bug是越少越好吗？）。 我查了资料，有这些说法（根据逆反原理，假设一个bug都没有的项目，是否就说明该项目质量一定就很好呢？显然是不正确的，很大程度上说明这个测试团队的测试经验已经测试能力体现不到位。还有开发人员能力参差不齐，当发现某模块bug数越多，修改的bug越多，则引入新的bug就会越多，（非官方统计：修改3个bug，就会引入1个bug）那么这些新的bug发现的难度要比修改前发现bug要大的多。那其隐藏未发现的bug数量就越多，那么相应的模块质量也就越差。），根据我的实践，我得到这些经验（Bug自然是越少越好，Bug的数量对于软件的质量是很重要的）。 但是我还是不太懂，我的困惑是（Bug对于一个软件来说，是越多好还是越少好，如果Bug没有，软件就是相对比较基础简单的，但是Bug如果数量增加的话，又不是很好的可以控制，对于一个软件的质量来说是至关重要的）。
2、我在《构建之法》第八章看了这一段文字 （投入和回报不是一个线性的关系，有时投入根本看不到回报，另一方面，如果在质量上做到极致，达到高级工匠的水平，会对团队成员本身和用户产生巨大影响），有这个问题 （投入和回报应该是线性的关系，因为我觉得你投入的越多，就会有一定的相应的成果的）。 我查了资料，关于这方面没有一个确切的说法，根据我的实践，我得到这些经验，投入与回报因人而异，每个人的点都是不一样的。
3、我在《构建之法》第九章看了这一段文字 ：PM的核心要求是：根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。，有这个问题 （例如微软公司有几类的PM，那么PM之间若是产生了意见分歧，怎么办？是不是一个软件就会废了）。 我查了资料，有这些说法（其实多数情况下一个项目里面都只有产品经理，个人觉得这样比较好，虽然比较难，但就不存在多头领导了，搞那么多leader，把大家都弄晕了不说，还容易出现矛盾。），根据我的实践，我得到这些经验（PM之间还是要找一个互相理解的，最好还是一个人，如果软件的工程的工作量巨大，还是找一个相对口的人比较好点。