问题驱动开发

保持-saasy-black-ogimage.jpeg

弄清楚要做什么是高级技术角色的重要组成部分。高级工程师和工程经理经常难以定义技术路线图。原因包括：

很少有关于如何做到这一点的行业培训
优先考虑经过专门挑选和培训以具有说服力的专业产品经理可能会令人畏惧
一些组织希望 PM 负责团队中的所有优先级，这使得工程路线图的所有权不明确

很多时候，良好的技术视野会让人觉得它必须是上天的恩赐或者是你与生俱来的技能。事实上，良好的技术愿景往往是对少量数据进行非常简单而无聊的审查。

技术路线图开发的一个简单手册是问题驱动开发。简而言之，这意味着您在修复出现问题的基础上制定技术路线图。这听起来很简单，但它可以非常有力量。

发展没有问题

EM/高级工程师在制定路线图时的经典首次尝试是询问人们他们认为团队应该做什么。这通常以悲伤告终，因为：

如果没有时间思考，人们就会给出错误的答案。
人们过度关注权威人士的意见。 “总建筑师说这是个好主意！”他们确实这么做了，但他们说是在 2 分钟的聊天之后，而不是在深入了解项目和路线图之后。
人们提供解决方案，而不是要解决的问题。

你会得到一个类似的列表：

将我们的库版本升级到下一个小版本
将 Foo 类重构为可组合的
尝试 X 的新热门 SaaS 事物

隐含的“我们应该这样做，因为它解决了 X 问题”消失了。三个冲刺之后，人们开始抽象地讨论解决方案，而不记得他们最初为什么这样做。

这种方法的主要缺点是它没有捕获和解决最大的问题。

当你确定解决方案的优先顺序时，一旦每个人都同意你的想法，你的工作就完成了。您可以多年来对解决方案进行优先排序并有效执行，而无需解决问题。

当你确定问题的优先顺序时，你会优先解决你实际遇到的问题。你不可能多年来优先考虑问题并有效执行而不解决你的问题。

顿悟时刻是这样的：你所做的一切都应该是为了解决问题。让您的团队针对您遇到的最大问题进行协调。根据解决这些问题得出您的技术路线图。定期重新检查您的问题列表以确保其仍然准确。

好吧，如果你要解决问题，你必须弄清楚它们住在哪里。大多数软件团队都存在以下问题：

页数
SLO 违规
在项目/任务上浪费时间
开发中浪费时间（例如CD速度慢）
应用警报
成本
变革失败

这些故障存储库是可审核的，您可以根据它们直接构建问题的优先级列表。在构建技术路线图时，您最终可能会得到如下结果：

我们得到的页面太多了。其中80%是WizBang服务。我们需要将其降至 0。
我们将 12% 的时间花在手动任务上，我们认为通过一个月的工作可以将其减少 50%。
SLO 非常好，无需任何工作。

从这里，您可以找出您认为可以解决这些问题的解决方案。这听起来很简单，但却是弄清楚该做什么的有效方法。

问题驱动的发展：技术债务

众所周知，科技债务优先顺序在行业中充满挑战且充满挑战。造成这种情况的一个主要原因是工程师们不太善于解释为什么技术债务很重要。另一个因素是，PM 经常需要 PM 级别的优先级研究来确定产品工作的优先级，这是不公平的。然后，团队会进行争斗，并获得基于百分比的技术债务分配，从而不必相互打交道。

无论如何，工程师应该更好地对技术债务推理进行合理的尽职调查，例如：

课程很糟糕，这会导致什么问题？
问题是很难编码。
好吧，这有多大问题？
你是什么意思？
除了它很恶心之外，我们还浪费了多少时间。
好吧，我们每两年才改变一次。
好吧，那么值得花一个月的时间进行重构吗？
不，但是另一个文件也有同样的问题，我们每周都会修改它，并且它的更改失败率非常高。
好吧，让我们解决这个问题。

如果您将事情视为解决问题并相信它可以完成，那么很快您就可以了解有关浪费时间、失败率和问题变化频率的技术债务原则。

当人们在代码库的该领域编写其他工作时，就应该解决常规规模的技术债务。但是，如果您要求团队花时间确定工作范围并确定工作优先级，那么您应该至少有少量数据来支持您的主张。在我以这种方式真正研究其价值之前，我经常发现自己对一笔科技债务抱有很高的信念。

问题驱动开发：总结

问题驱动开发是一个听起来很简单的理论。但我看到许多工程师和工程经理都在努力弄清楚该怎么做。我还见过更多的情况，没有一个框架可以对那些喜欢无法解决问题的解决方案的高级工程师说不。

接下来的一些步骤：

如果您发现自己需要制定技术路线图 – 找到问题，找出最大的问题，并制定解决计划。
如果您是一名初级工程师，想要致力于自己的倡导和愿景，请看看您的团队的问题出在哪里。不要盯着一类代码而哀叹缺乏设计模式。这就是一个问题所在。相反，请查看托管证明优先级合理的行为模式的存储库。
如果您是一名 EM，希望您的团队拥有更多远见，请揭露并向他们介绍您所遇到的问题。我记得在一家大型科技公司工作时，我从未对我的团队面临的问题有过全面的了解。如果你只向人们展示门票，那么当你的团队里都是买票的人时，请不要哭泣。
无论您是谁，请始终让您的团队了解您正在做的事情的原因。一旦你忽视了问题，你肯定也忽视了解决方案。

问题驱动开发：附录

问题驱动开发基本上只是代用品产品管理。然而，具有讽刺意味的是，PM 可能会在问题驱动开发方面犯错误。客户的问题通常更难获取信息，并且需要很长时间才能收集。与此同时，您的竞争对手可能都拥有一项您所没有的明显有价值的功能。在这种情况下，您不应该花费大量时间研究问题只是为了找到竞争对手都有的解决方案。在以后的文章中将详细介绍这一点。大家保持 SaaSy！

原文： https://staysaasy.com/engineering/2024/12/17/problem-driven-development.html