[译]写程序更快、更好、更便宜的艺术

原文

没有人想延迟交付时间、超出预算。没有一个开发人员会在早上醒来的时候想"我今天要做搞一些垃圾代码。我如何才能增加、耗费雇主更多的钱？"。尽管如此，还是有许多的软件项目进行的不是很好。总是有来自各方面的压力，让我们不得不更快的编写代码。因此，如果我们在一家软件公司，应该怎么作呢？怎样才能在保证代码质量的前提下做的更快？

尽管有超过50年的历史，无数的方法论、建议、书籍，IT项目还是会面临失败。
—Susan Moore

商业、生意是解决客户的痛点的

要开始一个成功的生意，首先要找到客户的痛点。然后提供方法解决客户的痛点，以此来换取金钱。例如，人们发现学编程很难。那么写书或者开班来教编程就是一个市场。有些人不喜欢他们自己的外观。那么健身、美容、化妆品就是一个市场。商业的价值就在于解决客户的通点。因此，如果客户相信我们能解决他们的痛点，那么他们就很乐意付钱给我们。

在软件行业，软件就是我们提供的可解决客户痛点的产品。软件行业的关键在于软件开发。

当然不是说软件开发是软件行业唯一的有价值的活动。例如，如果没人知道我们产品的存在，我们的软件产品就变得一文不值。因此销售和市场活动是必不可少的。我们应该确定我们的产品真正的解决了客户的痛点，否则我们就是在浪费我们的时间。因此市场调查很关键。市场、销售、市场调查、用户体验这些都非常重要。这些活动的目标的偶是：了解人群。这些活动只是计划和承诺了客户价值。软件开发活动在能将这些计划很承诺转为一个产品。

如果能理解“产品”、“设计”、“开发”都是同一个事情的不同视角，那么就能做的更好。
— Greg Veen

减少对业务影响的时间

“了解客户”是一个持续发生的活动。随之，我们会越来越了解我们要解决什么问题。我开始设计一个更好的解决方案。因此我们也需要修改我们的软件产品。为了做到这些，我们需要一个敏捷的开发团队，能快速交付价值、响应变化。这是软件开发时间的核心目标。

因此，有一个敏捷的开发团队很重要。但是，如何才能有一个敏捷开发团队呢？你是否：

• 付给开发很高的工资？
• 给开发人员买速度快的，昂贵的电脑？
• 只要他们想，让他们去参加任何开发、技术会议？

如果你想保持一个开发敏捷的开发团队，你应该好好想想上面的每一条。更快的电脑、好的技术会议会提高开发者的生产力。这项投资是值得的。但这些是关于如何维持、留住好的开发。那么如何建立一个敏捷团队呢。

So if the answer is not giving developers whatever they want, what do we do then? 很简单，去问开发。在正确的时间用正确的方法问他们。The thing to understand about developers is that they tend to be natural problem solvers. 好的开发者喜欢他们的工作。因为他们喜欢整天去解决复杂的问题，并且以此来获取回报。好的开发沉迷于接受复杂的挑战，找到优美的解决方案。但是，很多组织使得开发者去聚焦于错误的问题。

聚焦于错误的问题

为何会发生这种事情？这是因为我们将开发和客户隔离开来了。随着项目越来越大，我们引入了项目管理者，和业务分析师。引入这些人，基于一个很好的理由，开发者没法完成所有的事情。软件项目非常复杂。编码已经很复杂了，但是更复杂的在于决定开发什么，计划开发的阶段，开发计划，与客户建立联系。开发者对于编码已经够头痛的了，因此我们需要额外的人来帮助他们。

但是，当这些人成为了开发和外部联系的接口的时候，会发生什么呢？项目管理者和业务分析和外部的利益相关者进行沟通。项目管理者专注于项目的交付，项目管理者像管理层进行汇报。那么管理者关心什么呢？

• 还要花多少钱？
• 还要花多长时间？
• 为什么要花这么多钱？
• 为什么项目会延迟？
• 为什么还没完成？
• 项目延迟一天要花多少钱？

这也是可以理解的，项目管理者变得越来越聚焦于预测。他们计划、估算。他们想知道发生了什么，什么时候发生的。预测和衡量让他们在向管理层报告的时候看上去是胜任工作的。因此项目管理者想开发者要预计花费的时间，报告和deadline。因此，开发者也开始聚焦在deadline、报告和估计上了。开发者聚焦于此以使项目管理者开心。

问题是估计和预测是一个不可能解决的问题。每当开发者开始一个新的任务时，他们要面对是一个令人难受的现实。这些任务可能隐藏了了一个巨大的复杂性。我们希望任务是简单的，但通常不是这样。

Hofstadter定律: 要花的时间总是比你预想的要长，即使你考虑到了Hofstadter定律。
—Douglas Hofstadter

有这么一个场景：一个项目管理者问一个缺乏经验的开发要一个估计的时间。缺乏经验的开发给了一个他觉得合理的预估时间。项目管理者转身就把这个预估做成了一个deadline和计划。一个好的项目管理者为了安全起见甚至会在开发给的预估时间上在加那么一点。 不可避免的事情发生了 - 项目要延期了。因此开发者开始工作更长的时间。但是更长的工作时间意味着开发者会越来越疲劳。他们开始犯更多的错误。这还不够，即使这样项目还是延迟了。项目管理者要求知道是什么耗费了这么多少时间。因此饱受折磨的开发开始偷工减料了。这样下去，项目于不仅延期了，而且满是bug。

这样会带来负价值。也许这个延期的，满是bug的产品还是能解决客户的一些痛点。但是bug带来了新的痛点，而且需要时间去修复bug。客户不再有信心我们有能力帮助他。他们不愿再付钱给我们。每个人都失败了。

有经验的开发者不去预估要花多长时间。想象下，项目管理者问一个有经验的开发要预估时间。开发会给出一个听起来长的荒唐的时间。但长的还不至于公司马上取消这个项目。项目管理者下一步就是跑过来商量了“这个预估超出了我们希望的时间。有没有可能我们可以缩短一些？”开发问“你们想缩短多长时间？”项目管理者给出了一个数字。开发摸摸下巴说：“时间很紧啊，我们看看能做些什么。我们应该减少一些需求，只做一些基础的功能。” 这时项目管理者会评估减少多少需求，并且能看起来还是胜任的。但是，即使在这种情况下霍夫施塔特定律还是会发生。

预估是软件开发中不可避免的一个问题。不幸的是，人们以为开发一个新软件和建一栋房子，修一辆车是一样的，是可以给出一个准确的预估时间的。
—Steve Smith

我们偷工减料，提供低质量的代码，为了在deadline之前完成工作。我们假设我们之后会回头来修复这些问题。但是“之后”从来不会到来。我们已经落后于下一个阶段，因为我们必须回头去修改bug。我们写的是一些脆弱的，硬编码的代码，这些不适合于快速修改。一旦陷入这种循环，开发者聚焦的不再是解决客户的痛点。你们聚焦在了下面这些事：

• 怎样尽可能快的"完成"这个功能？
• 怎样才能尽可能的不去触碰这些低质量的代码？因为一旦碰了，可能会出现更多问题。
• How can I eke out one tiny piece of code that I’m proud of amongst this giant steamy pile of technical debt?
• 如果像人们证明我的决定是有道理的，他们不知道我做了什么，也不知道这个有多复杂？
• 当客户开始抱怨我没有时间去修复的bug的时候，我怎么去责怪别人？
• 如何在简历下写下一些流行词，以此去到一个不混乱的公司工作？

没有开发想延迟交付，和写满是bug的软件。但是我们对开发施加压力，要一个更短的预估时间。开发通常都会服从，因为他想取悦别人。很快开发就会陷入困境，因为他们的预估是错误的。因此他们的在交付的压力下，开始工作更长时间，偷工减料。他们妥协于代码质量，因为每个人都在问“开发完了吗？” 没人是开心的，软件还是会延迟并且充满bug。

我认识的开发会尽力做的最好。但是他们还是会陷入困境。他们太想"快"了。因此，他们现在聚焦在了错误的事情上。他们聚焦于生存。 当你快饿死的时候，你很难聚焦于为退休存点钱。当你在一个延迟的项目中一周工作7天的时候，你很难去规划如何做的更聪明。因此首先要认识到想要更快是要投入的。需要财务、时间和情感上面的投入。

打破循环

早前，我建议向开发者请教如何减少交付时间。但是，当开发者在 ‘catch up’模式时，我们不可能从他们那得到好的回复。当我们进入到这种环境，然后说"我们怎样才能更快？"，可能会得到下面两种回复：

1. 用火烧了它。“我们需要离开两年，从头重写所有的东西。”当开发被技术债务淹没的时候会发生这种情况。也许有点道理，但是我们没有预算去这么做。市场也不会等着我们重建。
2. 愤怒。 “我们已经够快了。我不信你通过半个小时的头脑风暴就能解决这个复杂的问题！” 当开发被强迫产生低质量的代码时会发生这种情况。当客户抱怨bug的时候，他们认为他们受到了谴责。他们有理由愤怒。这种心态下的开发者不会帮助我们，除非我们能认真倾听他们。他们需要知道我们了解他们的担忧。我们也需要展示，我们对待变化是认真的。

上面两种开发所关心的都是对的，但是他们是向内聚焦。我们想创建一种环境以此来减少交付时间。如果开发者是这种心态，那么对减少交付时间没有任何帮助。Step zero is to show that we’re serious about changing things. That will usually involve finding some way to reduce pressure. Even if it’s only temporary.

But even then, unless something changes, developers will still be inward-focussed. They will have plenty of ideas on how to improve what they’re doing. Some of them might be great ideas. But there’s a lot of risk. We need the developers to focus on minimising lead time to business impact. We need to get their focus off dealing with internal pressures. We need to expose them to customer pain.

向开发者暴露出客户的痛点

So, how then do you expose developers to customer pain? Plenty of other people have written at length on this, so I will only skim the surface. Here are three ideas in order of least-effective to most-effective:

1. Get developers to use the product they’re making as part of their day-to-day work. In the industry, this is known as drinking your own champagne or eating your own dog food. The advantage of doing this is that it turns developers into users of the product. So any glaring bugs or issues will now cause pain for the developers too. The problem with this approach is that developers aren’t typical users (most of the time). The way developers use software is often different from most customers. So, while this may help developers fix major bugs, it may not provide great insight into typical use cases. Also, this is not always practical. For example, imagine we’re producing a SaaS product for dental hygienists. It may be difficult to for developers to integrate thisinto their daily workflow.

2. Get developers to do rotations on support teams. A better approach is to encourage developers to take part in some kind of support roster for the product. (They may need quite strong encouragement.) This way developers get to experience customer pain first-hand. So, as they answer phone calls and email (or tweets, or whatever) customers tell them about problems. If developers do this long enough then they will also start to observe patterns of common issues. They’ll see things that come up over and over again. Not having to hear that same complaint again makes a good motivator to fix usability issues. Unfortunately, people rarely contact support to tell you what’s working well. So the feedback is somewhat biased.

3. Get developers to sit with and watch people using the software on a regular basis. This is the most inconvenient option as it requires the most organisation. But it is also likely to bring the best results. With this approach, developers get to see how real people use the software in real life to do real stuff. They get to see the good, the bad, and the ugly.

Doing these kinds of things with consistency is hard work. It takes effort and organisation. And most developers will have a natural disinclination for it. I feel awkward writing this because I don’t do this as often as I ought. But I believe it’s worth the effort.

Exposing developers to customer pain is an exercise of deliberate effort to overcome cognitive bias. Which is a long way of saying “it’s a way to learn some humility.” We developers are prone to think we’re clever. And many developers are clever. But we don’t know everything. Maybe I’ve finally figured out how monadic bind operations relate to functional composition. That’s great, but it doesn’t mean I know a thing about what our customers are facing as they use our software every day. Exposing myself to customer pain reminds me of how little I really know.

以我的经验，越是隔离开发人员，最后的产品越是糟糕。许多团队有一层商业分析，他们认为他们的工作就是将开发和用户隔离开了，这种做法非常糟糕。开发者不知道客户是谁，是非常糟糕的。
—Jeff Atwood