软件开发团队建设思路谈

开发 项目管理
什么样的软件开发团队出什么样的产品,今天我们要讲讲软件团队的建设思路,同时谈谈为什么我们叫挨踢项目团队。

  什么叫挨踢项目?

  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://www.cnblogs.com/umlonline/archive/2011/11/07/2236116.html

【编辑推荐】

  1. 项目经理不该给客户做烂好人
  2. 项目经理不可不知的“三边六拍”
  3. 项目经理谈如何应付对日软件开发的危机
  4. 百炼成钢 真正的软件项目经理是怎么炼成的
  5. 利用Maven进行开发过程管理
责任编辑:彭凡 来源: 博客园
相关推荐

2012-02-02 15:04:02

软件开发

2018-07-03 15:29:00

2014-01-16 14:06:18

软件开发团队管理

2021-08-24 09:00:00

开发软件框架

2012-11-06 09:28:25

微软云计算公有云

2020-07-09 14:44:10

开发技能团队

2011-09-09 09:18:43

软件开发团队

2019-07-01 16:14:29

开发者技能工具

2022-05-31 17:38:05

亚马逊科技

2011-07-19 09:11:04

项目

2021-08-25 09:00:00

开发软件数据

2022-11-07 16:42:35

KPI软件开发团队

2011-06-27 10:45:06

BattleheartAndroid游戏开发

2022-09-03 08:06:44

测试开发DevOps

2011-09-01 09:57:54

对日软件开发

2011-06-08 00:09:30

RationalInnovate 20软件开发

2016-04-25 11:37:10

开发团队问题

2023-07-29 13:17:53

AI模型

2012-06-18 09:34:14

2020-06-24 11:21:47

软件开发面试
点赞
收藏

51CTO技术栈公众号