当软件验收出现些问题时，开发团队相互推诿扯皮，如何改进？

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

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

【A】 理不清的团队责任

绝大多数的项目经理能够达到目前的位置，说明其能力与知识是毋庸置疑的。一名制造公司的生产部门主管往往能够理解本部门绝大多数的制造过程、工作及流程，但是一名研发部门的经理却很有可能仅仅是比较了解市场与客户，他可能并不了解技术，更甭提实现的具体工作过程及采取的技术手段了。

上述现象是专业服务类工作的典型状况，专业服务工作所需要的知识要求人们不仅仅掌握技术手段，更需要许多的实践与感受。这就必定使得整个团队是由一个各自擅长各自领域的专家组所构成的团队，而完成这些工作则必须要求团队成员互相协调与沟通，这个团队就好像是一个链条，任何一个环节断了，整个链条就断了。

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

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

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

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

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

【B】 事和做事要区分

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

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

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

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

【C】 凡事搞清楚问题背后的原因，并且进行持续改进

C是最最重要的，但是也是最最困难的，所以通常不容易做到。在IT行业，许多的问题就算真的了解了背后的原因，但是由于客观环境的限制也什么都解决不了。

但是，不能解决不代表就不该去了解清楚，心理明明白白是很重要的，因为环境会变化，我们至少要为可能到来的环境变化做好准备。所以，花费时间去努力了解现象背后的原因，无论怎么提及都是不过分的。

这里，需要明白3个原则：

•  花费时间，假设总是要做的，但是不要轻易下结论；
•  如果找不到好的解决方案，心里明白嘴上却要装糊涂；
•  不断的将收集到的信息与分析的结果，反馈给团队成员，供他们讨论与理解（反馈最重要）。

通常，一旦有了基本的对于原因的分析与理解，就可以开始持续改进了，持续改进本身并不复杂，但是难在选择开始改进的地方，这里有两条原则：

•  不要在没有价值的业务或项目上做出改进，那属于花费8角节约1元，根本没有什么改进必要；
•  对业务较为稳定的部分进行改进，不要对十分不稳定的新项目或新业务进行改进。

总之，不要先责怪团队成员不负责任或害怕担当，先要努力改善环境，环境得到了改善，许多问题就会得到改善了。