基于主题的时间管理——消除软件管理中的压力

作为一名经理，您会收到大量工作，在许多情况下，工作量超出了您或团队所能承受的范围。这些涌入的工作需要定期进行分类和评估，以确定它们是否重要并继续符合团队的目标，或者是否应该停止或避免。

软件开发经理的目标是什么？

• 按时交付
• 维护团队健康
• 维护产品（或代码库）健康
• 为团队的未来做准备
• 分类传入的工作/沟通风险（即建立合理的工作量）

这与我们在上一篇文章中确立的管理主题非常吻合：客户服务/体验、成长、卓越、愿景和交付。

任何符合上述类别之一的事情都很重要，换句话说，与您的团队应该做的事情一致。

艾森豪威尔原则——有效时间管理

艾森豪威尔建议我们持续关注重要的事情，而不仅仅是紧急的事情。紧急的工作只是被要求（或到期）立即完成的工作。就我而言，我喜欢用“一致”这个词代替“重要”，因为毕竟，做不重要的事情有什么意义呢？

那么，什么是“一致”的工作呢？当工作符合以下类别之一时，它就是一致的：

• 上述管理主题之一
• 您的可交付成果之一（是的，这与主题中的最后一项重复，但值得单独指出，因为这些通常有与之相关的截止日期）
• 您的老板关心的事情——在您决定某事不值得做之前，请考虑如果那项工作没有完成，您的老板会怎么想：来自营销部门的临时请求，其他团队要求清理旧记录等。如果您的老板不关心是否取消这项工作，您可能不需要担心去做它。

示例场景：根据上图，在完成崩溃和关键功能之后，您会处理哪些项目？营销部门一直在向您询问有多少花哨的新设备正在生产中使用，产品部门想知道开发一个目前不在路线图上的新功能需要多长时间，您也一直在收到来自另一个团队关于一些错误归档记录的定期电子邮件，该团队希望完成他们的笔记。

工作顺序：1、2、3、4

如果您遵循艾森豪威尔原则，您将首先处理一致的项目1，然后是2，然后是次要的项目3，然后是4。是的，这意味着提高您的构建时间比其他团队的最后一刻的临时请求更重要。改进常常因为截止日期而被忽视，但如果我们允许自己定期改进，我们将能够获得比原始投资更大的回报，从而使团队在这个过程中更快、更强大。

我还建议甚至不要记录象限4中的项目，因为如果它们既不一致也不紧急，谁会在乎它们是否完成呢？您已经有足够多的事情要做。

注意：关于优先级划分以及分配专门时间进行工作的好处，请参阅Chuck Greb的精彩演讲（来自Droidcon NY 2019），该演讲实时完美地阐释了这一时间管理原则。有关避免拖延这些艰巨任务的技巧，请阅读Bartek Franek的文章：番茄工作法或“吃掉那只青蛙”技术。

礼貌地说“不”

防止范围蔓延对于保持团队按计划进行至关重要。压力来自各个方面，当被问及我们是否可以增加“仅仅一个”项目时，很容易就答应。学会礼貌地推迟或至少提醒请求是范围蔓延，有时可能是按时交付与否的关键区别。

这在很大程度上取决于您与请求者的关系以及所请求的内容。每家公司在这个问题上都有自己的症结。在许多情况下，根本不回应是不恰当的。让人们知道您目前没有时间处理某个特定的请求，而不是让他们悬而未决，这是公平的。直接说“不”也可能不是一个选择。您还需要体谅对方，让他们知道您不是在忽略他们，只是目前与您的首要任务冲突，可以在完成这些工作之后再考虑。很容易让他们稍后再来核实。

一些示例

• 当产品经理或项目经理要求额外工作时，您可以询问可以删除哪些工作来适应新的请求（在冲刺/敏捷环境中非常典型）。新工作不是免费的，您不能在不付出任何代价的情况下，不断地从团队中榨取更多工作。询问哪些可以推迟。如果没有，也许这个请求现在不需要。
• 如果它是来自另一个团队的请求，并且与您的团队目标不符，那么这项工作可以协调到一个可交付成果中，这样至少这项工作可以按计划进行，而不是作为意外的临时请求。检查为什么会要求您做与团队目标不符的工作也可能是有益的。
• 如果保持文档或状态更新是一个问题，也许可以通过某种方式自动化或提高流程效率，这样就不再需要那些额外的清理工作了。

持续识别并分配所有工作的象限

艾森豪威尔有一句名言：“计划毫无价值，但规划却是一切”。对我来说，这意味着定期对传入的任务进行分类，这样您就不会仅仅因为它们是最新而陷入不重要的事情中。

当一天中新工作进来时，弄清楚它需要进入哪个象限，并相应地放置它。当您有时间时，您就会处理它。这可以防止您仅仅跳到最新最亮眼的新功能或任务上。在开始工作之前，请考虑它的重要性以及您的老板是否会关心它。

为您的收藏笔记工具（Joplin是一款很棒的跨平台工具）中需要关注的每个主要主题设置一个列表非常有用，并在每个主要关注区域中为每个象限设置一个条目（同样，跳过第四个——因为谁真正在乎呢？）。就我而言，我会在一天中从数字1开始向下扫描此列表，以确保我按计划进行。

定期自省

您的老板想知道两件主要的事情：您的可交付成果是什么，以及您在实现这些可交付成果方面做得如何（即您的风险）。从每周开始时，掌握您的可交付成果情况：如果存在障碍，那么找出它们何时会被解除；如果及时的工作到期，那么估计何时完成；如果您依赖于另一个团队，那么他们何时会完成他们的工作？始终要求一个日期，如果无法提供，那么请询问您应该何时再次核实。立即设置一个日历提醒，以便在该特定时间进行跟进并相应地更新计划。如果您的老板始终了解情况，那么这将被视为积极主动，您将收到更少的更新请求。宁可分享太多信息。

团队健康状况如何？大家喜欢自己的工作吗？不知道？进行一次健康检查回顾，以确定团队的感受，并利用这些反馈进行改进。但必须具体，像“会议太多”这样笼统的说法帮助不大。是哪个会议？可以精简、异步进行吗？您是否与所有下属定期进行一对一会议（我更喜欢隔周进行，但个体会有差异，有些人可能根本不想见面——让团队告诉您他们的偏好）。

您支持的产品如何？表现如何？如果是面向最终用户的产品，客户反馈告诉您什么？如果产品支持另一个团队，请向他们征求反馈，了解他们希望改进什么。否则，产品和营销团队可以在这方面提供很大帮助，以了解客户需求是否得到满足以及存在哪些差距。如果崩溃率太高或性能太慢，请创建工单来解决它们并将这些工作放入待办事项列表。

展望未来，有哪些更大的趋势？是否有某些功能经常被请求，未来可以更容易实现？是否有任何迫在眉睫的技术更新需求？这里没有简单的答案，请依靠您的工程师。引导他们思考未来有什么可以帮助他们更容易地进行开发，并让他们能够付诸行动。