软件经理基本素质
程序员文章站
2022-04-02 13:38:12
...
软件经理基本素质
是什么造就一个优秀的软件经理？
作者：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件事可以调整――资源、功能规格、日期和质量。如果每次在计划一次发布时，为了安排日期你都回头做同样的事，你的公司可能失去平衡。例如：
· 如果拿掉太多的功能，你将得不到一个有竞争力的产品
· 如果你添加太多的功能，你不能安排好日期
· 如果过于忽略质量，你将得到不好的声誉
· 如果你一直等到产品完美，你将错过市场
· 如果你安排工程师总是加班，他们将耗尽精力
· 如果你加入太多的资源，你将缺少金钱
· 如果你延误进度表，这会为销售团队制造困难，并且可能错过市场。
当你正确地定义你的产品或一次发布并且积极开发，但没有可完成的进度表，你可能发现阻力。这个行业习惯于不合理的进度表和不合理的目标，许多人可能认为你的团队没有在努力工作。（所以合理的进度表是必须的）
通过创建能够长期服务的团队和产品，公司和顾客是很好服务的。你应该是敢作敢为的，并且要求你的开发者做到最好，但你不能把他们作为资源滥用。
结束语
显然，这里提出的每一个问题都可能派生更多的问题，花点时间回答它们，并且聪明地管理它们。
是什么造就一个优秀的软件经理？
作者：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件事可以调整――资源、功能规格、日期和质量。如果每次在计划一次发布时，为了安排日期你都回头做同样的事，你的公司可能失去平衡。例如：
· 如果拿掉太多的功能，你将得不到一个有竞争力的产品
· 如果你添加太多的功能，你不能安排好日期
· 如果过于忽略质量，你将得到不好的声誉
· 如果你一直等到产品完美，你将错过市场
· 如果你安排工程师总是加班，他们将耗尽精力
· 如果你加入太多的资源，你将缺少金钱
· 如果你延误进度表，这会为销售团队制造困难，并且可能错过市场。
当你正确地定义你的产品或一次发布并且积极开发，但没有可完成的进度表，你可能发现阻力。这个行业习惯于不合理的进度表和不合理的目标，许多人可能认为你的团队没有在努力工作。（所以合理的进度表是必须的）
通过创建能够长期服务的团队和产品，公司和顾客是很好服务的。你应该是敢作敢为的，并且要求你的开发者做到最好，但你不能把他们作为资源滥用。
结束语
显然，这里提出的每一个问题都可能派生更多的问题，花点时间回答它们，并且聪明地管理它们。
上一篇： 多服务器运维管理 日常运维好帮手
下一篇： ruby 标准类型总结