软件开发中等待反馈的成本
4.75/5 (3投票s)
您知道发现一个 bug 3 周后修复它比当天修复要花费多少时间吗？
让我们想象一下，你的工作就是写电子邮件。
你所在的公司有一项政策，所有高管的公开邮件都必须由头脑清晰、训练有素的人来撰写。那个人就是你。
它的工作原理如下
- 你将从高管那里收到关于邮件内容的现场简报。
- 你回到办公室写邮件。如果出现问题，你可以打电话给高管，通常能立即得到答复。
- 写完后，你把邮件交给高管，两人一起修改，直到都满意为止。
整个过程大约需要半小时到几个小时。
这似乎还可以。甚至可能有点意思，对吧？
现在，想象一种不同的工作方式
唯一的区别是，你不确定何时能得到反馈或批准。可能立即就能得到，也可能需要几周时间。
因为不知道需要多长时间，所以你开始处理下一项任务。你可能同时处理的不是 1 封邮件，而是 20 封、30 封，甚至更多。
这是完全相同的工作，输入也相同，但感觉却更加麻烦，也更没意思，不是吗？
好吧，不幸的是，这就是大多数开发人员的工作方式
在这个例子中，我们假设没有中间人（项目经理、分析师……）通过他们传递所有沟通，他们会加入自己的想法，从而使信息变得模糊。
作为一名开发人员，我经常发现，需要很长时间才能得到反馈或答复，这非常令人沮丧。
你开始着手某件事。你遇到了障碍，需要反馈。因为你不知道何时能得到答复，所以你暂时搁置任务，转而处理下一项。
但是等等，客户也有同样的沮丧！
是的，我经历过：几年来，我一直在另一边工作，指导承包商/自由职业者为我们的组织开发定制软件。
给开发人员提供详尽的反馈，结果两周后才收到进一步的问题，这同样令人恼火。这些问题通常本可以轻易得到解答，但两周后，我几乎不记得当时是怎么回事了！
当然，还有更好的方式来浪费我的时间！
工程师的解决方案是什么？
让我们使用一个工具来管理所有这些“在制品”，包括状态、标记、截止日期、源代码集成、自定义字段、负责人、报告、里程碑等等。
这通常是不必要的过度复杂化，却被视为标准做法。
“事情就是这么做的！”
确实存在需要这种工作方式的情况。
但是，大多数软件项目其实相当简单，并不需要这些“解决方案”。
根本原因仍然存在：接收反馈的时间太长。作为人类，我们无法暂时将积累的理解——我们的“掌握力”——存储在某个地方，直到我们再次需要它。
那么，替代方案是什么？
我们都很忙，不能在有人需要我们时就放下手头的工作。但如果我们能呢？
如果我们能同时处理 2-3 个任务呢？
如果我们不需要工具（除了一个基本的待办事项列表）来管理所有任务的进度呢？
如果我们能与客户就几个任务从头到尾进行密集合作呢？并且在这些任务真正完全完成之前不开始新任务呢？
我为什么问这些问题？因为这可以节省时间、金钱和精力！
这是几种任务/项目管理框架的核心要素之一，这些框架建议在所谓的“冲刺”（sprints）期间专注于有限数量的任务，或者限制“在制品”（WIP limit）。
经常提倡。很少实践。
而且，确实没有人要求你立刻放下一切来回答每个问题；只是不要让事情永远拖延下去。
我们真的在等待反馈中浪费这么多时间吗？
在加利福尼亚的 Palm 公司（第一款 PDA 的制造商）进行了一项研究。这项研究衡量了开发人员修复一个延迟三周发现的 bug 比在同一天发现的 bug 所花费的时间要长多少。
那么，你认为这会花费多少倍的时间？
大约二十四倍，无论任务是大是小。
你是不是也惊掉了下巴？我最初的猜测是 5-10 倍，这应该足以激励任何人认真考虑一下。
但是，无休止地等待反馈并不是导致在制品数量爆炸的唯一原因！
它还包括
- 分析和开发之间的延迟
- 开发和测试之间的延迟（如果您使用测试人员）
- 开发人员阅读测试人员反馈并对其采取行动之间的延迟
- 等待某事的批准或签核
- …
那么，我们该如何解决这个问题？
嗯，写出来并不难！ ;-)
以下是我的建议，无论您处于什么角色，它们都应该有效
- 争取让每个人都参与进来。将本文链接发送给他们。或者将《Scrum 书》的摘录发送给他们；作者比我有名一些，所以可能效果更好！ ;-)
- 以身作则：当天或至少在 24 小时内提供反馈和回答问题。
- 明确表示您会尽快提供反馈。积极要求您合作的每个人（包括客户和经理）也这样做。必要时进行跟进。很多人会一直拖延，直到他们注意到你一直在跟进。
而且，如果您的角色允许
- 尝试让（必要/所需）的每个人同时处理大致相同的任务。
- 尝试限制任务数量和“在制品”。强制执行 WIP 限制。
- 减少中间人数量。他们通常没有真正的目的，除了巩固或翻译信息。开发人员的沟通往往过于技术化。我仍然会犯这个错误。但我相信你可以学会以更非技术性的、人性化的方式进行沟通。倾听真正被说出的话，并尝试用同样的语言在同一水平上做出回应。
我认为直接的沟通渠道总是更好的，因为它提高了彼此学习的可能性。
但我是个开发人员。我不能随便要求客户的关注！
你不是要求立即关注；你只是要求不要等待很长时间才能得到答复。
我知道这对很多开发人员来说不是标准的工作方式：主动而不是被动，主动沟通而不是处理下一个用户故事或 bug。我无意居高临下。我是在分享我自己的经验，我犯过的错误，以及失败和成功的项目经验。
这可能是成为“10 倍工程师”的（众多）步骤之一，并表明你掌控全局并关心项目。
记住，所有与你合作的非技术人员对软件开发知之甚少。
引导和教育他们如何优化流程、节省时间和金钱，这并没有什么不对。谁会反对呢？（当然，除非你的时间是按小时计费的。） ;-)
…… 如果你收到来自多个来源的、相互矛盾的反馈，甚至与你自己的意见相悖，该怎么办？
不过，“委员会式设计”是另一个话题了。