挨踢项目求生法则（1）—— 团队建设篇，某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现，领导要追究责任人，于是大家开始踢皮球……

[张传波]

摘要：

知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。


什么叫挨踢项目？

IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！


由“踢皮球”事件想到的

事件回放：
某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现。经检查，发现测试的版本不是部署的版本，不知道为什么老版本部署给客户了。领导要追究责任，于是大家各有说法：
开发人员说：我是按要求打标签的，没有问题。
测试人员说：我是在提交区中取版本来测试的，我没有出错。
实施人员说：我是按照开发给我的版本去部署的，我没有过失。
最后终于有人说：是之前已经离职的某某弄错版本号导致的。

该事件暴露了很多问题，但我想说的是团队建设的问题，没有任何一个人首先从自己身上找原因，第一反应就是推卸责任！

唐僧四师徒西天取经，如果每个人都是这样，不是自己内斗死，就是被妖怪吃掉！优秀的团队能“自动”解决很多问题，如何才能打造良好的团队文化呢？


良好团队文化的源泉是什么？

良好团队文化的根本其实就是老板的管理思想了，不同的管理思想，老板会设计不同的部门规划和考核办法。
有朋友提到他的Boss喜欢工厂化管理，硬生生将员工分成两类人，设成两个部门。一个部门叫设计部门，负责需求和设计；一个部门叫实施部门，负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单，实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法，如果实施部门不能按时按质完成工单，则会影响考核；如果设计部门的工单被实施部门退回，则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生，以前完成一个工作很简单的，现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚，实施部门认为已经按照这些文档完成工作，或者是认为这些文档说得不够具体，要退单。当文档主要用来任务交接的时候，文档就会变成茶几上的杯具！
还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核，同样只不过是杯具的另一种形式而已。
软件研发活动是人类复杂的高级智力活动，是需要team work的活动。如果明白这个道理，如果懂软件开发，就不会设计出这些傻瓜的管理措施，将软件研发团队的每个人变成机械人、卸责人。研发团队中的每一个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家！


作为Team Leader应该怎样做？

Boss的想法我们无法控制，虽然无法从根本上改变公司的部门设计和考核制度，但作为Team Leader来说，在能力范围内还是可以做很多事情的。Team Leader应尊重每一位Team Member，平等地对待他们，充分发挥他们的潜力，给予足够的支持和成长空间等。对大家好，大家是知道的，将来会给你带来更大的回报。

下面一些法则供你参考。


法则1：一荣俱荣，一损俱损

项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成，每位成员在自己专业领域内发挥主导作用，并可以为项目的成功提出非自己领域内的建议。最终的项目成果是各位专业人士共同努力的结果，所有人对最终成功承担同等的责任。
如果系统部署后，系统出现了一个严重缺陷，请问谁应该负责？
项目经理？测试？开发？……
都不是，而是项目组全体都要负责！
软件中某个功能做得很炫很好用，请问谁应该受到表扬？
项目奖励发下来了，请问谁可以分到这份奖励？
以上问题相信你应该有答案了！
项目组全体是共同承担连带责任的，要死一起输死，要活一起活。如果项目组中有人受罚，有人会得到好处，这个Team是很难团结和有战斗力的。


法则2：让 Team Member 当家作主

项目组中难免有部分成员是新手，经验和水平不足，某些工作可能一时不能胜任。而我们往往迫于项目进度压力，某些任务就会直接安排给他做，不让他提出自己的想法和见解。而我们这些接受了中国式教育的人，不少人喜欢以“接受任务”的方式来工作，而不是主动迎接挑战。于是有时候你可能遇到一些成员会跟你说“今天工作已经完成！”“我按照任务要求来做的，我没有错！”之类的活活会气死你的说话。
不要剥夺项目成员当家做主的机会，应相信每位成员在他的专业领域内都是专家，在他的专业范围内，他可以说了算！只要满足项目的大框架，只要出发点是为了项目成功，那么这段代码应该怎样写、这个功能点应该如何测试等之类的决定，完全可以交给Team Member来做主！项目成员可能一时没有魄力独立做决定，可能担心犯错误，没关系，要多多鼓励他！犯错不可怕，因为还有“法则3：鼓励犯错！”


法则3：鼓励犯错！

少做少错，不做不错。如果犯错误会受到惩罚的话，那么前面八个字就会应验！
犯错几种情况：
1.经常挑战高难度工作，犯错是难免的。
2.做一些之前没有经验的工作，犯错也是难免的。
3.犯一些低级错误。
4.犯一些之前曾经犯过的完全可以避免的错误。
对于情况1、2，绝对是需要鼓励的！对于情况3、4，要帮助他避免这类的错误。
软件研发工作大部分是高难度和复杂的，加上进度压力大，犯错是不可避免的，如何在总结中前进。一个在工作中从来不犯错的人，他不是神，他应该是那种“少做少错，不做不错”的人，或者是专挑低难度工作的人，你喜欢这样的人？


法则4：言传身教

曾经见到这样的一些领导，当下属有问题求助时，他会板起脸孔，摆出领导的样子，然后说：你自己不会解决问题吗？你应该自己列出解决方案后才来找我！
我赞同领导不应该帮下属解决所有问题，有些问题应该由下属自己搞定，但下属是不可能搞定所有问题的，有些问题超出能力范围和职责范围，作为领导就应该出手。
作为Team Leader，应着重帮助Member养成良好的工作习惯和工作方法。中国式教育培养出来的学生，可能会喜欢直接得到答案，而不求工作方法。这个中国式教育的错，就只能由我们来补了。


法则5：挡住骚扰团队的外来干扰

Team Leader应当住来组团队外部的干扰，让团队可以专心工作。挡住麻烦是Leader的职责之一，而不要因为嫌麻烦，而让你的Member去处理这些麻烦。


法则6：全力维护团队利益

某部门的员工的薪金近年来很少得到提升，原因是该部门经理对外是好好先生，每年都不会主动积极为部门争取加薪的预算，总是被别的部门抢去预算。
某项目出了问题，老板找来项目经理，说要找人负责任，否则不好向客户交代。以下三个选择你会选哪个？
A.该问题确实主要是因为某Member导致的，所有他来负责是应该的。
B.这是团队的责任，要全体负责。
C.尽管是主要因为某人出错导致的，但作为PM的我应该负主要责任。
作为一个Team Leader，无论任何情况下都不应该“出卖”自己的Member，应该自己一力承担！回头你可以关起门来，批评这位犯错的Member。


法则7：我们是一个人

法则7是最重要的，其实只要能做到“我们是一个人”，其他法则自然就做到了。你不会和自己的左手作对的，右脚不会和左手打架，你的身体哪一部分受伤，你都会觉得疼，一个人的手脚动作是很容易协调的。如果我们团队能凝聚在一起，达到“我们是一个人”的效果，那么我们将战无不胜！


本文来自我的博客，欢迎拍砖！
http://blog.csdn.net/fireball1975/


作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
www.umlonline.org创办人

[以专业开发人员为伍]

“法则1：一荣俱荣，一损俱损” 看到这个标题，我就知道你是什么人了。我要是你老板，你可能是我利用来打压真正有才能的开发人员的工具，或者当所有其它开发人员都是初学者时你可以用来忽悠他们，但是肯定不能帮我做出好产品来。 搞这种，容易回避真正的问题诊断技术和彻底改变现状的本事，整天拿一点行政上的东西说事。

[以专业开发人员为伍]

我可以告诉你一个法则“如果经过研究，结果不是有一个人负主要责任，那么老板应该把责任全都揽过来！”

[以专业开发人员为伍]

对于这里所说的“鼓励犯错”，我觉得层次也不高。 “犯错”和“犯错”是完全不同的概念，有的人没有搞懂什么叫做“鼓励犯错”，就一个劲地给“犯错”找借口了。 例如我们在蹦极之前先检查好保护装备，这不是鼓励我们不带装备就从高山往下跳。测试绝对不是无头苍蝇一般地“鼓励犯错”，而是在安全的范围内首先得到条件反射，好进行反应。绝对不是简单地鼓励犯错，而是有计划有预谋地“假装犯错”，以便侦察出最近的安全范围。 极限编程绝对不是简单地鼓励犯错。

[张传波]

引用 1 楼 sp1234 的回复:

“法则1：一荣俱荣，一损俱损” 看到这个标题，我就知道你是什么人了。我要是你老板，你可能是我利用来打压真正有才能的开发人员的工具，或者当所有其它开发人员都是初学者时你可以用来忽悠他们，但是肯定不能帮我做出好产品来。 搞这种，容易回避真正的问题诊断技术和彻底改变现状的本事，整天拿一点行政上的东西说事。

欢迎对文章内容发表见解，但一看标题就知道我是什么人的话，我只能说你太抬举我了！ 无论如何，谢谢你的意见！

[张传波]

引用 3 楼 sp1234 的回复:

对于这里所说的“鼓励犯错”，我觉得层次也不高。 “犯错”和“犯错”是完全不同的概念，有的人没有搞懂什么叫做“鼓励犯错”，就一个劲地给“犯错”找借口了。 例如我们在蹦极之前先检查好保护装备，这不是鼓励我们不带装备就从高山往下跳。测试绝对不是无头苍蝇一般地“鼓励犯错”，而是在安全的范围内首先得到条件反射，好进行反应。绝对不是简单地鼓励犯错，而是有计划有预谋地“假装犯错”，以便侦察出最近的安全范围。 极限编程绝对不是简单地鼓励犯错。

我觉得我想说的和你所说的是两回事，你上述所说的我都支持，但与我文中所表达的是两回事。 但只要你是认真看过这个帖子后发表的任何想法，我都欢迎！ 再次谢谢你的意见！

[cyc123007512]

[anhao98]

引用 楼主 u010825142 的回复:

良好团队文化的源泉是什么？ 良好团队文化的根本其实就是老板的管理思想了，不同的管理思想，老板会设计不同的部门规划和考核办法。 有朋友提到他的Boss喜欢工厂化管理，硬生生将员工分成两类人，设成两个部门。一个部门叫设计部门，负责需求和设计；一个部门叫实施部门，负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单，实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法，如果实施部门不能按时按质完成工单，则会影响考核；如果设计部门的工单被实施部门退回，则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生，以前完成一个工作很简单的，现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚，实施部门认为已经按照这些文档完成工作，或者是认为这些文档说得不够具体，要退单。当文档主要用来任务交接的时候，文档就会变成茶几上的杯具！ 还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核，同样只不过是杯具的另一种形式而已。

我觉得分部门和量化考核指标本身没太大问题。部门扯皮的地方是管理需要改进的地方，比如增加评审、审核环节，达成一致，才能使各部分相互促进。量化指标在研发中确实不太好用，但量化也是一种趋势，只是还找不到好的方法。 对几个法则我觉的很好，有些也在尝试

[对酒当歌今夕何夕]

项目有问题，项目经理 死去哪里了？ 自己站出来挨踢啊 只要不是低级问题，永远不要直接怪一线开发测试 要尝试总结流程 方法 ，如果是人的问题 说道底还是管理问题 所以项目经理要出来顶缸

[zz962]

现有发版本的规则是什么？谁负责发版本？ 如果是规则有问题就改进规则，如果是执行的问题也要考虑为什么会出现执行错误。 犯错在所难免，改进是重点，但如果老是犯同一个错误，再启动追责程序不迟