软件开发组的团队精神

软件开发组的团队精神

总听到大家在讲团队精神，那么团队到底是什么？

团队就是一小群有互补技能，为了一个共同的目标而相互支持的人。对于一个团队来说，最基本的是要有一个清楚的目标。

志同道合

是什么原因使大家组成一个团队？一个目标。对于球队来说，这个目标是进球得分，从而战胜对方；对于项目组来说，是在限期内完成项目；对于软件开发组来说，是保质保量推出产品。

这样说似乎很简单，作为一个软件开发组长，事实上你是否非常明了你的团队的目标了？比如说，我们组的目标是：在2001年9月30日之前按软件需求书完成WPX-XP的开发。在这个目标里，有没有考虑到软件测试的时间？如果公司预计在十月份进行产品发布，那么明确的目标应该是：在2001年9月30日之前按软件需求书完成WPX-XP所有的开发与测试。作为组长的你已经将这个目标谙熟于心，下一步便是让每一个组员都明确这个目标。这样，整个团队的目标才能统一清晰。

团队发展

团队发展大致分为形成，不满，解析和行动(Forming，Storming，Norming，Performing)四个阶段。

在形成阶段，作为组长，你不仅要让每个组员都明确团队目标，而且要让他们明确自己在实现目标中的职责。在团队发展的过程中，难免会遇到各种各样的问题。这时候组员相互推卸责任，情绪消极。这就是团队发展中必经的一个过程，不满阶段。只要在适当的时候将组员引导到积极的解决问题上，便能使团队更有作为。在团队发展的第三阶段，解析阶段，组员们达成共同的解决方案。团队便进入高效的行动阶段。团队发展可能在这四个阶段之间反复。明确的目标，相互信任与支持最终能使团队进入并停留在行动阶段。

因才施教(SituationalLeadership)

任何时间，出于任何原因，个人影响另一个人或团体的行为便是领导。领导的一贯方式形成了领导风格。

领导的行为有两种：指导和支持。指导行为包括：告诉组员做什么，怎么做；定义组员的角色；定义组员间的关系；为组员建立目标；为组员作决定等等。这是一种单向的交流方式。支持行为包括：表扬和鼓励组员；打开双向交流的渠道；增加组员的责任范围；增加组员介入设定他们目标的程度等等。这是一种双向的交流方式。在我们的团队中，按照态度和能力大致可以分为四类人：成熟度技能，能力与知识主动性与信心

R1没有没有

R2没有有

R3有没有

R4有有对于这四种成熟度的组员采用相应的领导方式才能最大程度地发挥组员的主观能动性。

如图所示，根据指导和支持行为的多少，领导风格也可以分为四种：

领导风格指导行为支持行为

S1:教导多少

S2:推销多多

S3:参与少多

S4:委派少少

从图中还可以看出，对于R1->R4的组员，应相对应地采用S1->S4的领导风格。当S刚进入公司作第一个Internet项目时，S既不熟悉Servlet,JSP也不熟悉Javascript，S因此毫无信心(R1)。组长D让S作一些已有样本的程序块的编码，并指导他阅读入门书籍(S1)。一个月后，S对JSP和Javascript有了大致的了解，加上S原有的C++和HTML的经验，S非常有信心能做好编程工作(R2)。组长D看到S的进步，便将独立的功能块交给S去做，并花时间和S讨论具体的作法，并对S的程序定时检查(CodeReview)，及时发现解决程序中的问题(S2)。[NextPage]经过一段时间的共同努力，S完全掌握了Internet项目前后台编程技巧，有了多个项目的经验，并通过了UML的培训，组长D便让S担任新项目的设计工作。S毫无作好设计的把握(R3)，他将自己的设计想法和D讨论，D肯定和支持S的想法，并鼓励S做好设计(S3)。S就这样成长为优秀的设计师，为公司承接了多个项目(R4)。这时的S需要更多授权来开展工作(S4)。在评判一个人的成熟度是R1还是R4时，针对给定的任务是很重要的。我们经常看到优秀的程序员被提拔为开发组长。对于这位程序员来说，他的编程水准是R4，而管理水准可能只有R1。在如何管理组员方面，你便要使用S1来对他进行指导了。另一原则是，如果你不确认组员的成熟度，请先试用上一标准。例如，你不确定S是处在R2还是R3，先试用S3；如果S不能胜任，再改为S2。

循循善诱(Coaching)

循循善诱的指导方式适用于上述的四种领导风格。指导的目标只有一个，就是将组员培养成R4，从而更好地完成工作。

以下是循循善诱五步曲：

尽量让组员来确立目标。

发现与建议，让组员来谈问题的背景和他建议的解决方法。

因为你在这方面更有经验，你可能会发现组员的想法没有你的好，甚至很可笑。其实，在你解释组员想法的不可行之处时，你也灌输了自己的思考方式。适当地分享自己的经验会起到很好的效果。

和组员一起制定行动计划。

授权组员以完成计划。

定时和组员一起审查计划的执行情况。

循循善诱的指导方式的重点在于“问”而不是“答”，“听”而不是“说”，“授权”而不是“指导”。这更多的体现了你的思想方式，而不仅仅是领导技巧。信任他人是领导的根本。小组会议

在小组会议上，你和你的组员们“传递”信息，意见，问题，解决方案，工作计划等等等等。如果你和你的组员们不能成功和有效地“传递”，团队就没有战斗力。

在开会前，先要问自己四个问题：

会议的目标是什么？

通常有五种会议：规划会，传达信息会，解决问题会，决议会，建立关系会(如庆功会)。

邀请哪些人参加？

你怎样知道会议是否成功？

高效会议的基本步骤是什么？

准时开会，回顾会议议程，控制每个议程的时间，控制讨论不要走题，作会议记录，总结结果并分派工作，准时散会

我们通常都想避免会议过多的错误，但对于你的开发组来说，会议过少也会影响组内的交流。

在小组会议上，作为组长的你主要是明确会议目标，控制议程。“听”多于“说”才能打开双向交流的渠道。出于各种各样的原因，有些人不愿意在会议或公众场合发言。你可以在会前提醒他，星期五将要在小组会上讨论GUI设计的问题，希望能听到他的方案或想法。

团队精神

真正的团队精神从哪里来？我们通常最欠缺的是下面两点：

尊重与信任

你是否尊重与信任每一个组员，相信他们的能力，支持他们的做法？

你的开发组是否使用VisualSourceSafe层层地管理程序，以至于刚入门的小S只能看到他自己的那一小块代码？

你是否愿意和组员共享你的设计和程序？

你是否将所有的电脑都面对走廊以便监视组员们是否在玩游戏，看私人Email？正所谓“用人不疑，疑人不用”，如果没有基本的尊重与信任，哪里来的凝聚力，何谓团队精神？如果小S能看到其他人的程序，看到你是怎样处理相似的问题，这是他最好的提高自己的方法。小S提高的越快，对团队的贡献就越大。小S如果能和你共享一个目标，不需要你的监视，小S也会尽力为团队的目标多做贡献。鼓励和支持个人成长

支持组员的自我发展，给他们的发展提供空间，鼓励开放的