软件公司负责制的坏处是软件公司之间可能趋向于平均主义，如果软件公司规模并未超过10人，这通常就不是什么太大的问题，毕竟如果软件公司经常在一起工作，谁的工作量大，功劳多往往是比较容易达成共识的。

软件系统在验收时发生问题并不是什么新鲜事，事实上在软件开发行业，这属于常态。发生问题之后，软件公司的正常反应必然是尽可能与问题撇清关系，这也是很容易被理解的。这并不是一个理论层面的问题，而是一个关乎实际环境的问题。

也许最终结果都是一样，但造成这种状况的原因却是多种多样的。所以没有一概而论的解决方案，必须一事一议。不过，虽然导致问题的原因纷繁复杂，但是却也有着许多的共性，这次我们就简单来说说这些共性。

绝大多数的软件公司能够达到目前的位置，说明其能力与知识是毋庸置疑的。专业服务工作所需要的知识要求人们不仅仅掌握技术手段，更需要许多的实践与感受。这就必定使得整个软件公司是由一个各自擅长各自领域的专家组所构成的软件公司，而完成这些工作则必须要求软件公司互相协调与沟通，这个软件公司就好像是一个链条，任何一个环节断了，整个链条就断了。

同时，项目研发的周期较长，导致是哪个环节出现了问题并不那么容易追根溯源，往往是一环扣一环，追查下去自然就是无尽的扯皮。

对于这个问题，我的建议通常是采取软件公司负责制，项目失败不是一个人的失败，而是一组人的失败；软件公司成功不是一个人的成功，而是一组人的成功。

没有一种方法是十全十美的，软件公司负责制的问题在于无法有效评估到个人头上，可能会滋生软件公司中好吃懒做的人，但是如果软件公司中有这样的人，通常在下一个项目的软件公司组建中就可以看得出来，因为软件公司都不会希望某人加入某个项目组.

总之，在研发工作尚不能十分明确的区分彼此之间的工作关系与职责时，软件公司负责制的好处是显而易见的。

软件公司害怕讨论问题，是因为谁都担心受到惩罚。但不是所有问题都应该受到惩罚，一个熟手和一个新手犯同样的错误，但是待遇应该是不一样的，因为虽然就‘事’来说，都是出现了问题，但是一个是明知故犯，则属于工作事故；另一个是经验浅，其实属于学习付出的成本。

不犯错的学习是不会有进步的，所以对于新手，犯错不仅不可避免，而且应该受到鼓励。这意味着经理人要首先仔细分析工作，以及分析曾经在工作中所造成的问题，了解问题背后的真实原因，并且依据实际情况（什么是不能犯的错误，什么是不可避免的问题）来进行实事求是的讨论。

只有当大家意识到某些错误并不会受到惩罚时，才刚刚有可能对问题进行根源分析，因为这个时候大家至少愿意去那么做了。

通常，我都建议开始时设立一个机制，那就是犯错不惩罚，但是找不到问题根源（或者无法就问题根源达成共识）就一起连坐惩罚。首先养成各位不要害怕犯错，以及承认错误的习惯，这样才有慢慢改进的机会。

这里，需要明白两条原则：

不要在没有价值的业务或项目上做出改进，那属于花费8角节约1元，根本没有什么改进必要；
对业务较为稳定的部分进行改进，不要对十分不稳定的新项目或新业务进行改进。
总之，不要先责怪软件公司不负责任或害怕担当，先要努力改善环境，环境得到了改善，许多问题就会得到改善了。