「技术债」遗留的技术债务问题怎么解决?( 三 )


合理分配时间
一旦你将工作分类到四个方面之一之后 , 下一步就是 “切馅饼” 或者为每个方面分配估计的时间 。 这四个方面的时间分配如下:40% 时间用于功能改进;10% 时间用于计划工作;20% 时间用于交付能力;30% 时间用于计划外工作 。 确定正确的时间分配比例下面是我成功使用过的一个方法:从确定数字开始 , 与利益相关者一起审查 , 然后在适当的地方进行调整 。 如果没有利益相关的参与 , 就无法成功确定时间分配比例 , 这主要是因为这些比例通常是可以协商的 , 但也涉及许多决策 , 因此需要进行权衡 。 你应该按什么顺序来确定数字?第一个要确定数字的是 计划外工作;这不应该是你自己决定的事情 , 而应该以你所掌握的数据为基础 , 这些数据可以让你能够推断出对未来一段时间的预期 。 例如 , 如果你在做季度计划 , 你可能会看前一个季度所花费的时间 , 以及(特别是受季节性影响的企业)上一年同一季度所花费的时间 。 如果利益相关者试图就这一数字进行协商 , 请向他们介绍你是如何确定这一数字的 , 并帮助他们了解你的实际情况 。 要确定的第二个数字是 交付能力 。 为什么呢?基于上述框架 , 我们希望从一个有目标、但有基础的数字开始 。 每个人都应该有减少计划外工作的动力 , 而交付能力就是实现这一目标的重点 。 如果你的计划外工作 “太大” (每个企业的容忍度不同) , 请考虑增加你的交付能力时间分配 , 直到该数字变得可接受为止 。 如果你下调了这一数字 , 请确保已与利益相关者就此沟通并进行权衡 。 建议:Google SRE 一书中关于 “拥抱风险” 主题在识别企业内部的风险承受能力方面有一些很好的想法 , 这可能有助于确定分配多少时间给交付能力这方面 。 虽然对某些团队或组织来说 , 使用错误预算可能是一个非常有效的选择 , 但同意一个管理错误预算和实施或测量 SLO 的系统本身往往是一个挑战 。 我在本文中介绍的框架时间分配或许有些重叠 , 但在某些方面可能提供了一种分配时间的替代路径 , 以解决一些质量或可靠性问题 , 否则这些问题将使用错误预算来解决 。 要确定的第三个数字是 计划工作 。 这些要求通常来自其他团队或业务部门 , 有的要求比较好商量 。 试着根据你认为接下来的时间必须要做的事情来确定这方面的时间分配 。 要确定的最后一个数字是 功能改进 。 此时 , 你已经确定了分配时间 , 因为你这时候处理的是剩余的百分比 。 你可能听说过 “价值流” 这个术语 , 团队的活动应该以满足客户的要求为目标 。 这方面通常是最主要的 , 它直接解决的是你的客户想 “看到” 的东西 。 如果这方面的时间分配对于你认为需要交付的价值而言过小 , 以至于不能满足你的客户在新功能交付方面的期望 , 我们将很快为这一方面提供更多的时间分配 。 一旦完成每个方面的初始时间分配 , 你将需要考虑如何根据与利益相关者的讨论对此进行调整 , 在这个框架内有两个 “杠杆” 可供考虑:交付能力工作应该减少计划外工作 。 计划工作影响功能改进工作 。 减少计划外工作理想情况下 , 任何分类为交付能力的工作都会减少下一个计划周期或工作节奏的计划外工作量 。 建议:请阅读 Nicole Forsgren 博士、Jez Humble 和 Gene Kim 所著的《加速》(Accelerate)一书——这是一本关于衡量和思考如何提高软件交付能力的优秀指南 , 里面有关于软件交付能力的优秀定义 , 以及 4 个关键指标 , 即交付周期、部署频率、平均恢复时间(Mean Time To Restore , MTTR)和变更失败率 。 交付能力可能会在两方面影响计划外工作:交付能力工作应降低平均恢复时间 。 即使计划外工作方面中的 bug 或问题的数量没有减少 , 解决它们所需的时间也应该减少 , 从而减少分配给计划外工作方面所需的总时间 。 交付能力工作应提高产出质量 , 从而降低变更失败率 。 理想情况下 , 我们希望看到导致计划外工作方面的问题能随着时间的推移而减少 , 而提高产出质量(在正确性、可靠性、性能、安全性等方面)恰恰可以做到这一点 。 根据具体情况 , 有时优先考虑平均恢复时间 , 而不是降低变更失败率的做法是有意义的 , 例如 , 如果恢复能力需要几天的时间 , 而故障的数量很少 , 但却保持不变 , 那么在选择减少平均恢复时间并更快地解决这些未来问题之前 , 你可能会为客户提供更多的价值 , 因为停机或 bug 的持续时间可能比数量的影响更大 。 我们的目的是利用这两个变量 , 但要根据客户的价值来构建决策过程 。 计划工作的影响我认为 , 计划工作和功能改进之间的平衡是一种分配杠杆 。 通过与计划的利益相关者合作 , 有时你可以推迟或重新分配你的团队被要求做的工作 —— 只要这个决定的理由清楚地表达出来 , 并且这些利益相关者也同意进行出这样的权衡 。 计划通常是由多个项目、团队和依赖项组成的庞大而复杂的工作 。 重要是要保持平衡 , 所以你要预料到 “阻击者” , 避免成为其他团队的 “阻击者” 。 项目经理或高层很容易要求你的团队提前完成相关工作 , 但从你的角度来看 , 将工作推迟一周 / 月 / 季度可能意味着你分配时间改变的方式 , 以及最终你的团队能够为客户带来的价值存在着巨大的差异 。 考虑到计划外工作在某种程度上是固定的 , 而降低计划外工作的杠杆很大程度上就是交付性能 —— 当你试图找到更多时间分配给功能改进时 , 我建议与计划利益相关者合作 , 允许你减少对计划工作的分配时间 。 你应该能够做到这一点 , 通过解释你时间分配的原因 , 以及为什么你认为对你的客户来说 , 推迟他们的请求是最好的事情 。 由于这个杠杆的结构方式 , 他们所做的权衡实际上是将价值传递给特定于你产品的客户 , 而不是致力于进行更大的创新 。


推荐阅读