千方百计，工程经理的工作很容易； 获取需要完成任务的列表，按优先级排序，然后开始清理直到完成。 进行一点期望管理和计划，您就完成了。 特别是在当今的敏捷世界中，预计规划期限不会很长。 但是，一旦我们开始解压缩这些任务，画面就会变得更加复杂。 今天，我想介绍一下工程经理职位的优先顺序。 具体来说，我想深入研究可比性和排序的概念。
有一个隐含的假设，即工程任务是可比较的，并且如果不是完全有序的任务，则属于部分有序任务的一部分。 同事或经理问过您多少次经理； “现在您的头等大事是什么？”，答案是两次或多次而不是一次。 这不是失败或没有优先次序，而是表明软件工程团队的待办事项充其量只是部分顺序，并且通常许多任务根本不可比。 如果被推动，您可能可以选择其中一项任务，因此可以绝对优先考虑。 但是，在您的脑海中，您仍然知道您已经尽快完成了这些任务，否则许多事情将开始崩溃。 我认为我们需要明确地理解某些任务是不可比拟的，并计划应对这种情况。
比较任务的困难有两个主要来源：
首先，为您的团队制定多个独立目标。 例如，我目前在Wealthsimple的团队负责开发软件，其中包括：为Wealthsimple客户准备税务报表，审计报告，存储和显示所有交易数据。 其中一些任务是相互可比的。 例如，我们可能需要比较支持新的纳税报表类型所需的工作优先级与自动化审核报告所需的工作优先级。 在这种情况下，我们可以看到截止日期，前一年的明年第一季度和下一次审核的日期。 但是，您如何比较纳税报表的工作和新功能，以更好地向客户公开交易数据？ 如果您使用截止日期作为指导指标，那么税务工作将始终获胜，因为UI工作没有明确的截止日期。 如果您使用客户满意度，参与度等作为衡量指标，则UI工作将获胜。 （除了纳税申报日的前两天，用户实际上在乎纳税申报表）。
第二，内部和外部目标之间的争论。 也可以从重要性与紧迫性或功能与技术债务的角度来理解这一点。 外部各方将始终在乎会立即产生影响的功能。 在团队内部，您将相对更加重视可扩展的运营改进和缓解。 例如，如何在12个月内（当用户群扩大一倍时）优先考虑重新架构数据管道以支持现有功能，功能工作与自动化如何提高运营效率。 我们宁愿担心我们的系统崩溃之前的扩展问题。 但是，自动化将使我们有更多时间专注于大型系统的重新设计。 同样，如果没有正在进行的功能工作，我们可能永远也不会获得2倍或更多的用户增长。 我认为在这些任务之间尝试严格排序是愚蠢的事情。 我们可以提出一些复杂的度量标准来订购这些任务，但是基于该度量标准的计划将在完成之前就被抛在一边。
相反，我建议最高职能的团队将是多极的。 至少每个团队都应该有一个领导者专注于外部交付物，第二个领导者专注于确定技术方向并关注技术债务。 几个较大的组织，例如亚马逊和电子艺术公司（EA），已经与工程经理和技术产品经理（TPM）组成了团队。 在没有人力资源的小型组织中，这两个职位的TPM角色都可以交给高级工程师。 但是，在后一种情况下，重要的是要使工程师和工程经理明确地期望对工程师的额外期望。 此外，必须赋予工程师执行长期技术愿景的自由和资源。
进一步概括，如果我们希望团队执行并交付多个独立的工作流，则每个流必须具有其拥护者/所有者或直接负责的个人（DRI）。 项目计划和技术设计只是团队的两个交付成果。 如果团队负责多个功能，则规划和设计这些功能中的每个功能都是其自己的交付物。 这些可交付成果的子集可以分配给团队的所有或许多成员。 一旦团队成长并需要拆分，DRI将成为未来自然的工程经理。 此外，DRI可以专注于子系统或项目的长期愿景，因为工程经理需要密切关注团队的外部可交付成果，依赖性和短期效率。
这种思维模型将团队从领导者和追随者过渡到负责不同交付成果的同事：项目规划，技术远景，教练，沟通和团队文化，以应对团队执行的每个工作流。 在真正优秀的团队中，工程经理的角色应该仅仅是管理外部沟通，管理文化和团队成员之间的协调。 在这样的团队中，团队中每个成员，从最低级到最高级别，都将至少有一个或两个领域专门负责结果。
