如何管理好开发团队

相关推荐

如何管理好开发团队

在任何人的职业生涯中，第一次接受管理职位任命都是一个重大事件，因为它标志着从“做事的人”到“使事情完成的人”的转变。

Builder AU从一个在管理开发者方面拥有丰富经验的专家小组那里寻求建议。

Phil Blythe——Magitek公司首席技术官，该公司主要针对分布式系统、分布式安全、网格应用平台和加密市场。他具有15个的IT业从业经验，管理一个由大约30名资深开发者组成的使用灵活开发工具的团队。

Jamie Danckert——Quest Software公司Oracle Monitoring for Foglight开发团队主管。他在一年半前开始接受这个职位。Danckert的团队主要开发Oracle 数据库的Foglight代理、Oracle电子商务套件和微软的SQL Server。Foglight是Quest公司的监控工具。

Lee Davis——AdvaTel公司软件开发团队主管。他在2000年以程序员的身份加入该公司，于2015年提升为团队主管。他参与了QMC（呼叫中心报告）和PhoneEasy（办公室电话系统PC控制）产品的开发工作。

Jim Katsos——Quest Software公司领域专家。他已在Quest Software公司工作8年，最初是一名低级开发人员。他在过去四年任技术团队主管，但最近成为一名Oracle和SQL Server领域专家，并曾从事过Oracle Schema Manager、Spotlight on Oracle和Spotlight on SQL Server方面的工作。

Mark Smith——MYOB公司开发者经理。他拥有15年的软件开发经验，在HP （数据库报告）、NEC（SD H监控和管理软件）和Victorian TAB（实时投注系统）工作过。他在NEC第一次担任项目领导与管理职务。

如何实现过渡？

应该严肃对待进入团队领导层这个过程。

“小心谨慎最关键，”Blythe说。他指出软件开发主要与决策有关，升入管理层需要你反思其他人的决策过程。除非他们极有天赋，否则团队成员总会犯错误，所以你需要建立发现错误的生产过程。

因此，在你担任第一份管理工作之前，首先与在生产过程（包括建立和修改它）方面经验丰富的导师型人物共事会大有好处，因为这种经历可为你提供遵照的范例，Blythe指出。从领导小型项目和团队起步也会有帮助，Katsos说。一开始就管理大型项目会面临更大的挑战。

Davis 警告说：“优秀的程序员并不一定会是优秀的经理，因为他们需要考虑的问题不同。”Smith称：“这是一个以人为中心的职位，但人们往往遗漏这一点。”虽然你在技术设计方面具有一定的权威，但你的主要责任是管理人员和赶上最终期限。“对人们来说，这是一个重大的转变。”Smith评说道。

在AdvaTel公司实习——例如以程序员身份参加销售和营销会议——确实让Davis受益匪浅，但Davis指出，制定一个结构化的发展计划（可能包括正式的培训过程）可能是一种优势：“那是我想要拥有的事物。”

使优秀程序员成为优秀经理的品质

程序员是概念性的思考者，这也是成为经理的一个必要品质，但Smith也承认，一些程序员的思考方式比其他人更为抽象。有必要关注细节（如制订标准时），但为细节而心神不宁则是一种错误。

一些新上任的团队主管非常重视技术问题，由于他可能比较专制，这样做并不理想——一般来讲，代码开发团队在更加共享性的环境中工作会有更佳表现。

Blythe建议把管理工作看作是一种新技术：你需要时间来学习。“不要希望你一开始就能学会，”他补充说。

如果领导者是一名技术专家型官员，而不是一位沟通者，那么团队和组织都得挣扎着求生存。虽然一些人发现很难学会开放和民-主化，但人事管理技巧可以通过正规培训来传授（MYOB使用Software Educa tion提供的一个课程）。要成为一名高效的团队领袖，你需要喜欢和人打交道，并通过与他们沟通来传达自己的观点。

两种角色在意识上的差异

你不再是一名程序员，Smith指出，因此你不能把全部精力花在编程或设计上。因为你乐于编程，这可能诱使你逃避新的人员管理工作，因而造成风险。

“成功的人[团队领导]了解人们的动机，”Blythe说。但Katsos指出，保持团队的快乐情绪会大大提高他们按时交付一款优良产品的机会。

除了指导和管理你的团队，重要的是，你还需要与内部顾客（例如营销、QA或设计部门的关键人物）建立关系，帮助自己养成一种大局观。关注组织的政治策略也会提醒你公司即将发生的重大转变。

Katsos对这个观点有更深入的理解，他认为你需要了解整个项目生命周期。除了编程以外，你还要承担QA、文件资料和其它方面的一些责任，即使你的团队并不负责这些任务。

“不要指望减少工作时间，这是肯定的，”Danckert警告说：“甚至你在度假的时候也必须做出决策，最好是参与进来，而不是接受你不希望的决定。”

时间管理

对任何拥有一定自主权的人来说，时间管理都十分重要，因为他们需要了解如何组织他们的工作时间，但一个团队领袖必须努力平衡这个角色的管理和实践时间。

专家小组一致认为你需要分配时间进行管理工作；但在如何分配时间方面，他们并没有达成统一意见。一些人支持首先开始做管理工作，其他人则更倾向于将整天的时间分成小的时间块。

“我给自己不属于关键路径上的[技术]任务，”因为一名团队领袖需要能够在必要时完成管理任务，Katsos表示。

重要的是，必须保证没有人会陷入困境，Blythe说——如果任何任务用了两天以上的时间，你应该坐下来与相关人员进行讨论，找出出现的问题。

Katsos 喜欢把大型项目分成小块：如果某件工作预计要一年时间完成，他可能会将它按月进行划分，并让开发人员估计他们完成最开始一部分需要的时间，然后开始执行项目，并将进度与估计进行跟踪比较。只是“不要太过于依赖估计”——如果有任何工作偏离正轨，你应该尽可能早地处理它，Katsos建议。

同时管理自己和其他人的代码

虽然Smith提到制定标准（编码标准、单元测试、清单等）和检查工作以符合法规监管的重要性，但他承认：“我从来没有发现这个[任务]有任何真正令人满意的地方。”Davis特别指出，代码文件资料必须达到标准，否则将来维护的时候会花费不必要的时间。

尽管同辈审查有助于维护标准，但Smith表示，你必须让团队成员报告他们正在进行的工作（记得给它确定时间块），并由你来指出任何缺陷。Scott Meyer的《Effective C++》之类的书籍可能有助于这种讨论，Smith建议。

Smith也建议在一些事情上取得共识。例如，进行代码团体审查（匿名进行，除非参与的程序员充分公开接受批评）可能会在优秀和糟糕代码方面达成一致，为我们提供可接受的范例，如变量命名，或使用矢量而非数组。

Davis指出，即使两个人的贡献并没有直接相关的地方，也要保证各方紧密合作，这点很重要。例如，建立安装器的员工必须要有顺利完成这项工作所需的全部信息。如果团队成员并没有朝着同一个前提工作，团队领袖完成这方面的工作就会更加困难。

赢得团队的尊敬

Blythe说：“[和你的团队成员]一起工作能够获得尊敬。他们需要至少把你当作一名同辈。”因此你必须能够说明你也会做编码工作，例如在问题出现时提供帮助。Magitek要求经理和他们的下属一样会编码，“我也依照同样的原则”，Blythe讲。

至于是否有必要这样做，Smith还不敢肯定，但他表示你应该参与研讨会、阅读文献资料、并与员工交流，以便至少在概念上跟上技术改变的步伐。

最重要的一件事情是，你必须保持团队对你的信任。这意味着你必须做到开放、透明、合理和平等地对待每个人。尤其不能厚此薄彼，Davis劝告说。Smith 也同意这一点，并警告说：“没有什么事情能够比这更能削弱你的领导地位”。Katsos表示，在分配特殊任务时必须记住这一点。

当你收到机密信息时，保守秘密但不要向团队撒谎。如果因为这样的问题面对团队的质疑，Smith建议坚持说：“对不起，现在无可奉告。”

记住，你的一部分权威源自同辈和上级对你的尊敬。“至少要获得[团队成员中]年长者和你的经理的尊敬，”Katsos建议道。

其它获得尊敬的建议包括建立有助于人们取得提高、保持一致、并避免微观管理的过程。

了解你的下属。Smith建议与下属举行一系列一对一的会谈，讨论他们当前的责任和目标，背景和规划。即使你已经认识某个人，但你的新工作改变了这种关系。这样可以帮助你适当地分配任务，做好管理工作。定期与下属进行单独会谈，这时你“将日常工作放在一边”，讨论业绩、渴望与目标，并检查你们的工作。

时间管理非常重要。这适用于你（分配时间进行管理工作）和你的整个团队（保持项目运转）。Smith指出，你需要立即了解谁会一直向你通告他们的进度，谁会等待你发问。“告诉我你现在进行到哪了？”这样的问题通常会得到更有针对性的回答。记住，你必须能够回答外界提出的关于项目状况的问题。

准备做出决策。“任何决策都好过没有决定，”Blythe说，因为优柔寡断可能会使项目陷入瘫痪。“犹豫不决是最糟糕的情形。”

选择一个开发过程并坚持实行。Katsos认为你需要让大家接受选择的过程，然后推动并执行这个过程。

管理工作是一项新技能，接受这一点。“领导你的团队是一个艰难的学习过程，”Smith说。因此你必须参加培训、阅读有关生产过程和管理方面的书籍，等等。 Davis建议你阅读J Hank Rainwater所著的“Herding Cats: A Primer for Pro grammers Who Lead Programmers”——“这本书很不错”。关注生产过程而非技术问题改善了团队的效率和效力，Blythe说。他还提到，如果你确定了合适的标准，就不必处理代码改变而引发的争论。

新经理面临的五大陷阱

不要尝试去做太多技术性的工作。Blythe指出，你不应该自己动手修复一段代码，而让下属坐在一旁看着，特别是当他们都是编程高手时更不能这样。一般你会有一定的编码责任，但如Katsos所说，它们应该是关键路径以外的工作。

不要高高在上。Blythe认为，走进办公室并声称你的权威的做法“后患无穷”。让下属做他们的工作，虽然如果你不了解他们，这样做可能有点困难， Katsos表示。有时候你需要提供特别指导，例如确保及时修复一个特殊的漏洞，以满足公司确定的最终期限。但你要设定目标、规程和最终期限，然后让团队完成编码工作。同时，让更多年长员工帮助他们的晚辈。Danckert的一句话很好地说明了这一点：信任你的开发人员，但准备在必要时扶他们一把。

不要指望每个人都同意你的做法，如果事实确实如此，不要为此感到心烦，Katsos警告说。记住，你因为优秀才得到提升，同时找出办法解决这类冲突。“尽可能以专业的方式处理这个问题…你必须遵照范例来领导，”Katsos说。但如果你的领导方式与团队现有的惯例不同，试图立即彻底改变可不明智：“我看到许多人遭到失败。”

不要忽视大局：你肩负着满足公司需求的责任。不要一下子就直接进行开发，Katsos建议：“首先做出规划很重要。”

如何管理好基础架构和开发团队两个阵营 2015-10-29 11:16 | #2楼

有时好象IT分-裂成了两个敌对的阵营。一边是致力于稳定性的基础架构工程师，他们要保护自己的环境。另一边是开发者，他们经常努力去发现独特的、更棒的方法来达到他们的目标。这两个阵营之间的斗争是如此的激烈，以至于连最忙碌的经理都开始注意到这点。

一个失败的项目

我参加的第一个大项目是帮助一个学校把一个基本财务信息系统从一个平台移到另一个平台上。我作为基础架构小组的解决问题专家以及配置专家。这个应用很陈旧，开发团队还面临着升级它，以符合该学校目前以及将来的需求的挑战。

事情的919 开始很正常。我们架起了自己的服务器，配置路由器，并在搭建IP子网络中找到了乐趣。当基础架构团队忙于进行稳定性测试的时候，开发者们却退到他们满是灰尘的房间和黑暗的角落里去。他们在深夜工作。

该项目进行了一个月以后，这两个团队除了在我们每周的例会之外，就已经不说话了。进行了两个月的时候，这些周例会也开始变味了。基础架构团队进行最后的配置并完成了基本的稳定性测试。开发团队每周到我们这来，带来新的变化，补丁和他们想放在服务器上的程序。

双方的脾气都开始爆发。从我们的角度看，我们不理解为什么开发者们不能接受我们为他们测试的，所有的伟大的事情。对于他们来说，这些开发者不能理解我们为什么如此顽固。他们只是想要帮助客户。

一天下午，事情发展到了顶端。一个开发者走进测试实验室，在桌上放了一个软件，并宣布要我们在当天安装并测试这个软件。我告诉他我们要在别的时间来进行这件事--也许是下个月的某个时候，我有我的方法。他很不高兴。事情从那个时候开始就有些失去控制了。我们面对面地站着，向对方大声嚷嚷。

我们的客户协调人刚巧在我们两个扭打在一起的时候走进这个房间。他关上门出去了。两个小时以后，

思科服务器是杰作还是无奈之举？

那个开发者和我都被踢出了那个项目。但是，在我们走了以后，那个项目里的两个团队之间的情况没有任何改善。事实上，情况越来越糟，最后导致了整个项目的失败。

发生了什么？

除了我自己的不够职业的行为，这个项目还受到一个根本问题的困扰。基础架构和开发者这两个团队之间的关系制造了大量的紧张气氛。我的大声嚷嚷和那个开发者的失态只是表象，而不是问题的实质。辨认出并理解这个问题成了我在等待下一个新项目的时候关注的焦点。

在回顾了我们从事的工作类型之后，我认识到基础架构和开发对于世界持有相矛盾的看法。这种矛盾不可避免地导致了两个团队之间的战争。

基础架构团队关注的是能力和风险管理。他们的目标通常包括诸如“快速配置”，“没有麻烦的安装”以及“快速的问题解决方案”等内容。经理们通过检查当机时间和问题解决方法来衡量基础架构。为了达到这些目标，有天赋的基础架构人员努力创造稳定，低风险，高可管理性的环境。当变化让他们难以达到目标的时候，他们就会有些抗拒风险。

程序员们则有着完全不同的文化。他们的目标包括解决商业问题，改造现有的程序来解决新的问题，并思考新技术的可行性。衡量他们的标准是他们能够成功承担风险的能力和愿望。风险越大，他们能解决的问题越大，他们就越有成绩。

这种讨厌风险/喜欢风险的不同态度解释了我每天从基础架构和开发团队那里听到的评论。基础架构团队通常把程序员们看成是肆意妄为的牛仔。程序员把基础架构团队当作是庸俗古板的人，并抱怨说他们总是整天忧心忡忡。这两者之间的矛盾是显而易见的，所以这个问题就不是我们怎样才能阻止这两者间的战争，而是我们如何才能利用它，并从中获得最大的收益。

利用紧张

从实践的角度，我们不能够改变这两个团队之间的紧张气氛。冒险者和反对风险的人总是会起冲突。但是还是有可能利用这些不同的观点并让他们能够在理智的环境中一起工作。

最简单的办法是指定两个团队中最外向，喜好交际的人作为同另一个团队的“联络者”。联络者参加对方团队的会议，学习去了解对方想要什么以及对方如何处理问题。这在两个团队之间创建了一点相互的理解。同时保证了他们之间非正式的沟通。

一个更复杂的方法是建立基本变化管理。建立起一套可以接受的方法和时间让两个团队坐在一起讨论变化。在这个会议之外，建立一些非正式的头脑风暴会议来让两边关键的人表达自己的意见。在正式会议沉闷的气氛之外，非正式的交流使两个团队能够建立共同的目标。

快速前进

几年以后，我发现自己再次参加了一个项目，该项目中也包含了大型的开发同基础架构团队。当敌对的阵营开始形成的时候，我利用自己作为高级基础架构管理人员的身份，建立了一个变化管理流程。在第一次会议上，开发者们对基础架构人员进行了嘲笑和抨击。会议结束后，我同软件团队和我身份相似的一个人进行了一个走廊会晤。我们同意作为另一个团队的联系人。虽然这样做花费了我不少时间，我从参加开发会议获得的预先警告和信息让变化管理流程顺畅进行。这个系统也帮助开发者们认识到并不是所有的基础架构团队的成员都仅仅是想妨碍他们的工作。那个扮演联系人角色的开发人员也告诉他们的人基础架构团队所需要处理的风险，以及为什么我们那么反感突然的变化。

【如何管理好开发团队】相关文章：