软件经理基本素质  

是什么造就一个优秀的软件经理？  

作者：Mark I. Himelstein     翻译：tianxinet（胖猴）－－最近致力于研究、介绍一些“最佳实践” 

多数软件经理并非一开始就是经理，而是作为一个开发者开始他们的职业生涯。  

作者简介：Mark是一个在软件行业有25年经验的软件管理顾问。 

-------------------------------------------------------------------------------- 

译者注： 
执行力、沟通，多数软件经理都不会忽视这两个问题，有关注未必就已经做的很好，那么怎样考查呢？文中给出了一些参考，有经验的软件经理其实完全可以自己给出一些问题来进行考查，只需要不时静下心来理一下。 
授权，很多软件经理的反应可能是“这是大团队的事，我的团队很小，不需要授权”。这是错误的。 

-------------------------------------------------------------------------------- 

多数软件经理作为一个开发者开始他们的职业生涯。他们或者有一些抱负、一些公认的良好管理素质，或者“在正确的时间待在正确的地方”，我认识的软件经理没有一个是通过培训成为经理的。 

经理们为多个对象服务：顾客、公司、他们自己的经理、他们的雇员、以及他们自己――并且每个人都想告诉你什么是一个（他们认为的）好经理，你得平衡这些费神的事。 

例如，当我为Sun公司面试一份“running Solaris Engineering”的工作时，我问参加面试者他们对成功有什么想法，我得到的（比较少见的）答案是如果他们被更好的管理，就会成功。 

那么迄今为止我们得到的：你不是，或者可能不是瞄准这样一份工作－－有太多的或者不知道想要什么，或者什么都想要的上司。（因为你希望更好的被管理） 

执行力（Execution）  

这里有10个可以让你评定自己执行力等级的问题： 

1.你有顾客的需求吗？ 

2.你有一个核准的预算吗？ 

3.你有一个核准的roadmap吗？ 

4.你有一个核准的进度表吗？ 

5.你在及时交付你的产品吗？ 

6.你以适时的方式雇用开发者吗？ 

7.你的团队有能力处理变化吗？ 

8.你有能力让你的团队关注并抵御变化吗？ 

9.你的顾客在交付的产品上遇到大量质量问题吗？ 

10.你和你的团队定期估量怎样把你们的工作做的更好，去发现提高的方法了吗？ 

有人曾经问过我，当管理者要求一些不合理的或不可能的事情时他们应该怎么做。我的答案有两部分：首先你必须确定管理者是见多识广的，并且理解这些要求是不合理的或不可能的；第二，你必须决定你是否能够拒绝。如果你不能，那么你需要检查一下自己的职业选择。 

当答案的第二部分或更戏剧性的答案抓住你的注意力的时候，是答案的第一部分引导我们到下一个基本技巧――沟通（communication） 

沟通（Communication）  

作为一个经理，你必须和你服务的每一个人沟通。对每一个影响你和你的团队的事件，你都应该考虑和谁以及怎样沟通，无论它是积极的还是消极的。 

你也必须用不同的方法和不同的人（及状况）进行沟通。例如，你可能向你上司的上司做正式的陈述，但是更多的向你的直接领导做非正式的报告。或者你可能email协议书给你的同级，但是需要面对面的向你的开发者解释协议书的原则和含义。 

这里有10个可以让你评定自己沟通能力的问题： 

1.你的团队理解公司的战略吗？ 

2.你的团队理解工程的roadmap吗？ 

3.你的团队理解roadmap怎样和战略相接吗？ 

4.你定期的与你的团队开会或email沟通吗？ 

5.你团队的成员愿意告诉你坏消息吗？ 

6.在从其他人那里听到之前，你从你自己的团队那里听到关于你的团队的信息了吗？ 

7.你团队的成员以有礼貌的（尊重的）方式互相沟通，以及与公司的其他人沟通了吗？ 

8.在你的上司来问你之前你把情况提供给他/她了吗？ 

9.公司的其他人知道你的团队正在做以及实现什么吗？ 

10. 你以积极的方式沟通吗？ 

怎样沟通与沟通本身一样重要。你讲话的态度、对沟通对象的尊重、身体语言与声音的变化、措辞都影响到你能否沟通的好。玩世不恭、讽刺和消极性都会消除掉你可能通过沟通得到的所有好处。 

与开发者不同，你工组的一大部分是与人们交互。你必须沟通，你也必须展示你怎样对待你的团队和同僚。 

授权（Empowerment）  

你不能自己做所有的事，你必须发展一个能培养下一个经理、leader的组织，一个能够集中精力、创新、成功的组织。 

你应该与你的团队沟通需求、工作去制定计划，然后让他们执行这些计划。如果你（总是亲自）下命令并且“事必亲躬”，你的团队不会成功。他们必须有“主人翁(ownership)”的感觉，只有你能让他们有“主人翁(ownership)”的感觉。 

这儿有10个授权的问题： 

1.你的团队花精力制定进度表了吗？ 

2.你避免过细管理了吗？ 

3.你委托任务并且让你的报告没有干涉的进行下去了吗？ 

4.你让你的下属弄清楚他们应该负责什么了吗？ 

5.你给你的下属提供领导机会了吗？ 

6.你的团队在处理问题中有紧迫感吗？ 

7.你给你的下属设置清晰的角色和职责了吗？ 

8.在回家度周末前，你的团队的所有成员知道每星期他们应该完成什么吗？ 

9.你的开发者理解（经理的）责任和过细管理的区别吗？ 

10. 你的开发者认为你们的组织有积极的工作环境吗？ 

授权也需要有责任，如果你没有检查和权衡的来委托，你和你的团队可能永远完不成目标。许多开发者把（经理的）任何责任都当作过细的管理，你必须纠正他们这种观念。 

这儿有一些你正在过细管理的征兆： 

·   忽视先前意见一致的报告，更频繁的过问情况 

·   为错过交付发火 

·   经常改变工作分配 

·   控制执行而不是需求 

你必须给人们一个在积极环境下工作的机会，你需要把问题看作只是一件需要去解决的事情，你需要创造信任以便你在过问情况时得到实情。授权也意味着让你的下属制定自己的进度表，当你为一次发布设定了目标，你必须调整发布的内容目标、发布的时间目标，以及手中资源的不一致。 

在制定进度表时你总是有4件事可以调整――资源、功能规格、日期和质量。如果每次在计划一次发布时，为了安排日期你都回头做同样的事，你的公司可能失去平衡。例如： 

·   如果拿掉太多的功能，你将得不到一个有竞争力的产品 

·   如果你添加太多的功能，你不能安排好日期 

·   如果过于忽略质量，你将得到不好的声誉 

·   如果你一直等到产品完美，你将错过市场 

·   如果你安排工程师总是加班，他们将耗尽精力 

·   如果你加入太多的资源，你将缺少金钱 

·   如果你延误进度表，这会为销售团队制造困难，并且可能错过市场。 

当你正确地定义你的产品或一次发布并且积极开发，但没有可完成的进度表，你可能发现阻力。这个行业习惯于不合理的进度表和不合理的目标，许多人可能认为你的团队没有在努力工作。（所以合理的进度表是必须的） 

通过创建能够长期服务的团队和产品，公司和顾客是很好服务的。你应该是敢作敢为的，并且要求你的开发者做到最好，但你不能把他们作为资源滥用。 

结束语 

显然，这里提出的每一个问题都可能派生更多的问题，花点时间回答它们，并且聪明地管理它们。