开发经理是个工作压力比较大的职位。作为“中间人”，你需要在管理层、客户、销售 、开发人员等多种角色之间周旋。没人会注意你的工作做得有多好：一切都运转顺利，工作进展得波澜 不惊，所有人都各得所需。但如果事情失败了，不论什么原因，可都是你的错。
要成为一名成功的开发经理，秘诀就是管理好期望，第一步就是确保所有人都理解你的职能。你和 你工作相关的人，都要对开发经理的期许达成一致。
我看过很多开发经理的招聘信息，但我都不太赞同上面的描述。有一个要求深入了解大量编程语言 和环境，还有一个要求66%的时间进行编程（为什么不直接写三分之二？），还有一些要求有PMO认证， 类似的要求不一而足。我承认开发经理的职能是有点儿模糊不清，但像这样的招聘信息让我觉得发布这 些职位的公司并没有真正思考过开发经理的职能。这种情况对公司和受雇的人来说都后患无穷。
作为开发经理，你要承担很多责任，但重要的是发布产品。你的目标是采取所有必要的措施，确保 能把产品交付给客户或市场。要做到这一点，你需要确保开发团队能尽可能高效地工作，而且要确保他 们有明确的目标（无论是短期的还是长期的），扫除阻碍他们工作的一切障碍。从最初的项目范围，到 在客户网站上部署产品，每一步都是你的职责。你可以（而且应该）尽量把事情委派给下属去做，但你 要检查事情是否和你预期的一样，如果不是可要自己投入。
项目范围界定
作为开发经理，你需要知道如何界定项目的范围。根据你所在组织的情况以及你和外部群组的协作 方式，这可能是你工作的重要组成部分。如果你经常承担、负责第三方的项目，那你应该知道如何对 RFP（需求建议书）作出回应，包括交付物、时间表和预算等。即便你只做内部项目，没有正式的文档 系统，你也应该养成为每个项目写一份项目范围说明书的习惯。另外，如果你从事的是敏捷开发，这些 文档就要随着项目的进展持续维护和更新。
“总置顶”项目
这是项目范围界定的一部分，但它应该单独说明一下。我听大家谈论过“总置顶”项目 ，这类项目不需要预算和时间表。这可是错误的！如果弄不清楚成本和交付物对这些“总置顶 ”项目有怎样的依赖，那可能会扼杀你的团队，因为这些“总置顶”项目会拖延进度 、消耗其他工作需要的资源。你承担的每个项目至少都要有一个内部成本和一个交付物。你要和其他利 益相关方一起协商你所承担的一切。
管理关系
记住，你是“中间人”，任何失败都是你的错，即使失败原因是你无法控制的事情。你 需要和参与的人保持良好、开放的关系。
你不仅要让你的直接上司了解情况，还要让他的上司和同级别的人知道。此外，你也要让项目的其 他利益相关人了解项目情况。确保他们都在“消息圈里”，能定期获得状态更新，清楚你的 团队正在做什么。
谁处理客户关系？这些人可是除了老板之外你最需要知道的人。他们能管理客户期望、处理投诉（ 真实的或想象出来的）、与客户保持联系。另一方面，他们能让你苦不堪言，没和你核对就给客户许诺 ，提交不必要的Bug报告，缠着你按不切实际的时间表执行，诸如此类。
了解你的团队，他们到公司有多久了？每个人分别有什么优势和劣势？谁能和他们协作得比较好？ 他们有多忙？留意他们的生日、纪念日等等……虽然都是些细枝末节的事情，但意义却非 同小可。
确保管理人员知道你在做什么，并能看到你的进度，这样他们才会满意。沟通和可视化是关键所在 。我用过各种各样的工具，让管理人员始终能了解状态、发现更多信息。使用程序工具箱、公告板、白 板及任何你能想到的工具，以便他们了解最新信息。
如果利益相关者了解你和你的团队遇到的挑战，那他们可能会少提一些不切实际的期望。我说的是 他们可能会少提，而不是绝不会提。有些管理者永远不会明白为什么事情不能“运转”。这 种情况下你可能得重新找个工作了。
项目计划
只要你不是在大型项目里，一般都不需要单独的项目经理。对小型或中型项目，以及使用敏捷方法 的项目来说，你可以担任项目经理的角色、承担相应的责任。但开发经理并不是经过认证的项目经理。 抛开传统项目管理和敏捷开发之间的争论不谈，开发经理和项目经理的关注点一直都有冲突。作为开发 经理，你的工作是尽可能完成所有的事情，项目经理的工作则是确定什么时候能完成哪些内容。你必须 要在两个出发点之间做好平衡。如果你的项目足够大，需要专业的项目经理或Scrum Master，那就给你 的团队找一个，不要尝试着亲自扮演这个角色。不过，不论是瀑布模型还是敏捷过程，你都应该确保项 目计划是处于活动状态的，要持续更新、跟踪进度。
过程控制
这是工作里另一个关键的部分。不论你用的是敏捷方法还是瀑布方法，你都要掌控过程，让事情遵 守流程。记住，交付是你的本职所在，任何影响交付的事情都需要你最优先处理。
你采用的开发过程是什么？是何种形式的？如果大家说它是“敏捷”过程，那就检查它 是否真的敏捷（我保留着一张很方便查看的敏捷宣言海报，提醒自己遵循敏捷原则）。你的过程如何得 以改进？不存在完美的系统，要不断寻求改进过程的方法。我们已经做了很多工作来应对Bug的Root Cause分析，但更多时候却是过程有缺陷，导致设计不好、代码糟糕，或者误解了客户的需求，以至于 产品不能发布。
委托他人是件好事，但你必须跟进、确保事情都完成了。伟大的想法往往因为没人检查处理结果而 在执行中失败。我接管过好几个项目，接手前都是各个方面都不错，唯独执行不好导致一塌糊涂。
最后，你需要向各个利益相关人报告基于确切度量数据的状态。所以要用对阅读报告的人来说有意 义的方式衡量、总结过程。根据你组织的情况确定报告频率（每天、每周或根据需要）。要明确报告的 频率、格式和内容。注意阅读报告的人和他们期望的详细程度，并达到这一目标。所有这些会让你的报 告清晰、明确、易读。这会减少误解报告的人，但并不意味着能消除误读。读报告的人有很多事情要做 ，可能只会略读一下，或者按他们的方式理解，所以你要准备好澄清和解释，不过听起来可不能是在为 自己辩解。
技术
我多次在工作职位上看见过这个要求。有些公司要求开发经理深入掌握特定领域的知识。作为开发 经理，你并不是技术专家！把这个要求留给高级开发人员和首席开发人员吧。你应该熟悉现有的技术， 了解新的和即将推出的技术，但不要让自己成为专家，这会耗费大量时间、从其他任务上转移你的注意 力。你要非常了解团队正在使用的工具，看团队成员是否在有效地使用它们，还要知道团队何时会在知 识面上出现缺口，但你不应该是“去填补”的那个人。你必须放手，委托团队的高级开发人 员去掌握空缺的知识。
开发
这也是一个你需要熟悉，但不必是专家的领域。伟大的程序员能写出最好的代码，不过通常会是个 糟糕的管理者。你要能区分好代码和坏代码，还应该相信你的团队负责人。你可以在关键时刻亲自投入 、接手一些开发任务，但别忘了要有大局观、要聚焦于项目的完成。可不能好几天都埋头编程，忘了自 己的工作。