在任何人的职业生涯中,第一次接受管理职位任命都是一个重大事件,因为它标志着从“做事的人”到“使事情完成的人”的转变。
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年以程序员的身份加入该公司,于2005年提升为团队主管。他参与了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(SDH监控和管理软件)和Victorian TAB(实时投注系统)工作过。他在NEC第一次担任项目领导与管理职务。
如何实现过渡?
应该严肃对待进入团队领导层这个过程。
“小心谨慎最关键,”Blythe说。他指出软件开发主要与决策有关,升入管理层需要你反思其他人的决策过程。除非他们极有天赋,否则团队成员总会犯错误,所以你需要建立发现错误的生产过程。
因此,在你担任第一份管理工作之前,首先与在生产过程(包括建立和修改它)方面经验丰富的导师型人物共事会大有好处,因为这种经历可为你提供遵照的范例,Blythe指出。从领导小型项目和团队起步也会有帮助,Katsos说。一开始就管理大型项目会面临更大的挑战。
Davis 警告说:“优秀的程序员并不一定会是优秀的经理,因为他们需要考虑的问题不同。”Smith称:“这是一个以人为中心的职位,但人们往往遗漏这一点。”虽然你在技术设计方面具有一定的权威,但你的主要责任是管理人员和赶上最终期限。“对人们来说,这是一个重大的转变。”Smith评说道。
在AdvaTel公司实习——例如以程序员身份参加销售和营销会议——确实让Davis受益匪浅,但Davis指出,制定一个结构化的发展计划(可能包括正式的培训过程)可能是一种优势:“那是我想要拥有的事物。”
使优秀程序员成为优秀经理的品质
程序员是概念性的思考者,这也是成为经理的一个必要品质,但Smith也承认,一些程序员的思考方式比其他人更为抽象。有必要关注细节(如制订标准时),但为细节而心神不宁则是一种错误。
一些新上任的团队主管非常重视技术问题,由于他可能比较专制,这样做并不理想——一般来讲,代码开发团队在更加共享性的环境中工作会有更佳表现。
Blythe建议把管理工作看作是一种新技术:你需要时间来学习。“不要希望你一开始就能学会,”他补充说。
如果领导者是一名技术专家型官员,而不是一位沟通者,那么团队和组织都得挣扎着求生存。虽然一些人发现很难学会开放和民主化,但人事管理技巧可以通过正规培训来传授(MYOB使用Software Education提供的一个课程)。要成为一名高效的团队领袖,你需要喜欢和人打交道,并通过与他们沟通来传达自己的观点。
两种角色在意识上的差异
你不再是一名程序员,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 Programmers Who Lead Programmers”——“这本书很不错”。关注生产过程而非技术问题改善了团队的效率和效力,Blythe说。他还提到,如果你确定了合适的标准,就不必处理代码改变而引发的争论。
新经理面临的五大陷阱
不要尝试去做太多技术性的工作。Blythe指出,你不应该自己动手修复一段代码,而让下属坐在一旁看着,特别是当他们都是编程高手时更不能这样。一般你会有一定的编码责任,但如Katsos所说,它们应该是关键路径以外的工作。
不要高高在上。Blythe认为,走进办公室并声称你的权威的做法“后患无穷”。让下属做他们的工作,虽然如果你不了解他们,这样做可能有点困难, Katsos表示。有时候你需要提供特别指导,例如确保及时修复一个特殊的漏洞,以满足公司确定的最终期限。但你要设定目标、规程和最终期限,然后让团队完成编码工作。同时,让更多年长员工帮助他们的晚辈。Danckert的一句话很好地说明了这一点:信任你的开发人员,但准备在必要时扶他们一把。
不要指望每个人都同意你的做法,如果事实确实如此,不要为此感到心烦,Katsos警告说。记住,你因为优秀才得到提升,同时找出办法解决这类冲突。“尽可能以专业的方式处理这个问题…你必须遵照范例来领导,”Katsos说。但如果你的领导方式与团队现有的惯例不同,试图立即彻底改变可不明智:“我看到许多人遭到失败。”
不要忽视大局:你肩负着满足公司需求的责任。
不要一下子就直接进行开发,Katsos建议:“首先做出规划很重要。” (zdnet)
联系客服