Demos Over Deadlines 演示重于期限
图片：烟雾艺术立方体到烟雾 — MattysFlicks — (CC BY 2.0)
This post is part of the Managing Software series.
本文是《软件管理》系列的一部分。
< Previous < 上一页
As an engineer, I served on many teams: some very efficient and functional, some less so. One predictive factor in the health of the development teams was time pressure. Too much time pressure inevitably led to burnout, poor morale, poor employee retention, and poor team performance.
作为一名工程师，我曾服务于多个团队：有些非常高效且运作良好，有些则不尽如人意。开发团队健康状况的一个预测因素是时间压力。过大的时间压力不可避免地会导致倦怠、士气低落、员工留存率低以及团队表现不佳。
As an engineering leader, I try hard to balance two competing goals: Ship quickly, but avoid putting too much time pressure on the team. I prefer to give the team clear priorities and then get out of the way while they execute. That said, one of the goals I set for teams is to frequently demo newly built features. If there are no new features to show off, there is nothing to demo. By focusing on demos instead of deadlines, we turn what was a source of stress (time pressure) into a fun game or challenge (demo cool new stuff).
作为一名工程领导者，我努力平衡两个相互竞争的目标：快速交付，同时避免给团队施加过多的时间压力。我倾向于为团队明确优先级，然后在他们执行时退居幕后。话虽如此，我为团队设定的目标之一是频繁展示新构建的功能。如果没有新功能可展示，也就没有演示的内容。通过专注于演示而非截止日期，我们将原本的压力源（时间压力）转化为一种有趣的游戏或挑战（展示酷炫的新东西）。
Since switching to demos over deadlines, I’ve noticed remarkable changes on the teams I’ve built. Developers take a deeper sense of pride in the features they’re building. They get credit and recognition for producing great work. They get to feel the appreciation of the rest of the company on demo day as coworkers applaud the new demos.
自从转向以演示而非截止日期为导向后，我注意到我所组建的团队发生了显著变化。开发者们对他们构建的功能产生了更深的自豪感。他们因产出优秀工作而获得赞誉和认可。在演示日，当同事们为新的演示鼓掌时，他们能感受到公司其他成员的赞赏。
But to really understand the power of the demos over deadlines approach, first we need a deeper understanding of what is so wrong with deadlines, and at the heart of it is one key problem: It’s impossible to accurately estimate software completion.
但要真正理解“演示优先于截止日期”方法的力量，首先我们需要更深入地了解截止日期的问题所在，其核心是一个关键问题：准确估计软件完成时间是不可能的。
Software Estimates Lie 软件估算不可靠
Most engineering estimates are lies. In 2012, CNN looked at the top 50 Kickstarter projects and found that 85% of them shipped late. “Why Is Software Late? An Empirical Study of Reasons for Delay in Software Development” published in IEEE Transactions on Software Engineering found an average effort overrun of 36% in their survey of 72 software projects.
大多数工程估算都是谎言。2012 年，CNN 调查了 Kickstarter 上前 50 个项目，发现其中 85%的项目交付延迟。发表在《IEEE 软件工程汇刊》上的“为什么软件会延迟？软件开发延迟原因的实证研究”在对 72 个软件项目的调查中发现，平均工作量超支了 36%。
Estimation Challenge 估算挑战
Before we get into this, forget about search engines and virtual assistants, and try to estimate off the top of your head the average number of bees in a colony. Write down your answer now.
在我们深入探讨之前，暂且抛开搜索引擎和虚拟助手，试着凭直觉估算一下一个蜂群中蜜蜂的平均数量。现在就把你的答案写下来。
Why are software estimates usually wrong (commonly by orders of magnitude)?
为什么软件估算通常不准确（通常误差很大）？
- Scope creep — new features were added, pushing out the ship date.
范围蔓延——新增了功能，导致发布日期推迟。 - Undiscovered scope/complexity. Software development is an exploration. We’re doing something we’ve never done before and in the process we’re discovering new APIs, new protocols, engineering new components from scratch, and occasionally solving a problem that nobody has ever solved before. This is not trivial work, but when we estimate, we trivialize it. We almost always underestimate the scope and complexity of the problem.
未发现的范畴/复杂性。软件开发是一种探索。我们正在做以前从未做过的事情，在这个过程中，我们发现了新的 API、新的协议，从零开始设计新的组件，偶尔还会解决一个以前没有人解决过的问题。这不是一项简单的工作，但当我们进行估算时，我们却将其简单化了。我们几乎总是低估了问题的范围和复杂性。 - Developers think about how long it will take them to implement something, not how long it will take to implement, test, integrate, deliver, fix, retest, and redeploy before it’s finally done. The difference in the two values is orders of magnitude.
开发者们考虑的是实现某个功能所需的时间，而不是从实现、测试、集成、交付、修复、再测试到最终重新部署完成所需的时间。这两者之间的差异是数量级的。 - Upstream/library vendor issues. Software developers often find bugs in the components they use and need to work with upstream developers to get the problems fixed — or fork the project and take on unplanned maintenance costs.
上游/库供应商问题。软件开发人员经常在他们使用的组件中发现错误，需要与上游开发人员合作以解决问题——或者分叉项目并承担计划外的维护成本。 - Life happens. Key people get sick, have accidents, get married, have babies, etc. There’s no planning for these things.
生活充满变数。关键人物可能会生病、遭遇意外、结婚、生子等等。这些事情无法事先规划。
Estimates are worthless lies because software almost by definition is something that has never been built before — it’s digital, so if it had been built before, you could just install it and use it.
估算毫无价值，纯属谎言，因为软件几乎从定义上讲就是前所未建之物——它是数字化的，如果之前已经构建过，你只需安装并使用即可。
Proper estimation requires a thorough understanding of the work involved, and a good record of the average time it takes to complete each task, but if you’ve never built a thing before, you have no idea how long it will take. Even if you have, you have no idea how long it will take. If you are personally building the next one, presumably you’ll be faster the second time around. If somebody else is building it, you may have had existing knowledge that the next developer will have to discover, so they might take longer. Different people complete the same task on different timelines. You could estimate by asking three developers to time themselves while they complete the task and then average the time, but you can probably see the problem with that approach.
准确的估算需要对所涉及的工作有透彻的理解，并且对完成每项任务所需的平均时间有良好的记录，但如果你之前从未构建过任何东西，你根本不知道需要多长时间。即使你有经验，你也不知道需要多长时间。如果你亲自构建下一个，可能第二次会更快。如果是别人构建，你可能拥有现有知识，而下一个开发者需要去发现，所以他们可能会花更长时间。不同的人完成相同的任务所需的时间不同。你可以通过让三位开发者在完成任务时计时，然后取平均时间来估算，但你可能已经看出这种方法的问题所在。
Why Estimate? 为什么要估算？
The forces that drive us to estimate often feel insurmountable and unavoidable. A customer wants to know how much it will cost to build something for them. An investor wants to ensure that their money isn’t going to waste, and you need to keep investors happy so you don’t run out of money. You have to ship something before Christmas. Let’s take a look at each scenario and discover whether or not are deadlines are real or imaginary.
推动我们进行估算的力量常常显得不可逾越且不可避免。客户想知道为他们构建某样东西需要多少成本。投资者希望确保他们的资金不会白白浪费，而你需要让投资者满意，以免资金耗尽。你必须在圣诞节前交付某些东西。让我们逐一审视这些场景，看看这些截止日期是真实存在的还是虚构的。
Customer Hired You on Contract
客户以合同形式雇佣了您
A customer is planning to hire you on contract, and wants to know how much it will cost to clone TikTok before starting. The only valid answer to that question is, “that depends on the full scope of the features, and we won’t know that until we’ve done a lot of work.”
一位客户计划以合同形式雇佣您，并希望在开始之前了解克隆 TikTok 的成本。对于这个问题，唯一有效的回答是：“这取决于功能的完整范围，在我们完成大量工作之前，我们无法确定。”
Instead of giving the customer a number, show them other apps you’ve built. Provide some testimonials from other people who have confidence in your work, and then tell them you’ll dedicate a certain amount of resources to the project for a certain cost per month. Don’t charge for the product delivery. Charge for the time, and then work with the customer over time to control scope and cost and make sure it fits in their budget. Meet regularly to discuss priorities, report on progress, and show demos of the newly completed features.
与其给客户一个数字，不如展示你构建的其他应用。提供一些对你工作有信心的人的推荐信，然后告诉他们你将每月投入一定数量的资源到项目中，以一定的成本。不要对产品交付收费。按时间收费，然后与客户长期合作，控制范围和成本，确保它符合他们的预算。定期会面讨论优先级，报告进度，并展示新完成功能的演示。
One great bonus of this approach is that it reduces risk for both you and your customer. If you work for a month and discover that the project is way more complex than the customer envisioned, you can work together to adjust the scope so that it fits better with their business needs.
这种方法的一大好处是，它降低了您和客户的风险。如果您工作了一个月后发现项目比客户预想的要复杂得多，您可以一起调整范围，使其更符合他们的业务需求。
Investor Milestones 投资者里程碑
One of the biggest problems with software is that people are making commitments to deliver future software. In the startup world, people are trying to raise funds to build a business with software that hasn’t been created yet. In their investor pitch decks, they promise milestone deliverables. If we can hit targets a, b, and c within 18 months, we get a follow-on investment and we live to code another day.
软件最大的问题之一在于，人们常常承诺交付未来的软件。在创业领域，人们试图筹集资金，以尚未开发出的软件为基础建立业务。在他们的投资者推介材料中，他们承诺里程碑式的交付成果。如果我们能在 18 个月内达成目标 a、b 和 c，就能获得后续投资，继续生存下去，编写更多的代码。
In lieu of deadlines, we recommend undated milestone targets. Do spell out high level goals you’d like to achieve. Don’t attach them to specific dates. We can’t see the future, and opportunities and priorities change. By leaving dates off of your milestones, you’ll have the flexibility to focus on what’s most important right now, and that can provide better value for both your business and your investors. And since there are no dates, there is no point at which your business is considered a failure by investors unless you set priorities wrong and run out of money. As long as you’re alive and kicking and producing good work, your investors will be happy.
我们建议采用无具体日期的里程碑目标，而非设定截止期限。请明确阐述您希望实现的高层次目标，但不要将其与特定日期挂钩。我们无法预知未来，机遇和优先级也会发生变化。通过不在里程碑上标注日期，您将拥有灵活性，专注于当前最重要的事项，从而为您的业务和投资者创造更大价值。由于没有设定日期，除非您优先级设置错误且资金耗尽，否则投资者不会认为您的业务失败。只要您保持活力、积极进取并产出优秀成果，投资者就会感到满意。
For investors, traction trumps everything. If you let them know an even better opportunity has come up and you’re delivering on that, as long as you do it, and as long as it adds substantial and obvious value to your business, they’re going to be thrilled.
对于投资者而言，市场吸引力胜过一切。如果你能让他们知道一个更佳的机会已经出现，并且你正在实现这一目标，只要你做到了，并且这为你的业务带来了显著且明显的价值，他们将会非常兴奋。
If you are talking to an investor who’s insisting on delivery dates, keep looking until you find one who trusts you with the timeline. If they ask, tell them “we prefer demos over deadlines. So far we’ve delivered a, b, and last week we shipped c. Let me show you how it works.”
如果你正在与一位坚持要求交付日期的投资者交谈，继续寻找，直到找到一位信任你时间安排的投资者。如果他们问起，告诉他们“我们更倾向于展示而非截止日期。到目前为止，我们已经交付了 a、b，上周我们还发布了 c。让我向你展示它是如何工作的。”
Dive into the demo and show off the cool new feature instead of getting bogged down in when the next one will ship. If you keep features scoped small enough to ship something cool every few weeks, you’ll have a new demo to show off next time you meet, and they’ll see you making continuous progress.
深入演示，展示酷炫的新功能，而不是纠结于下一个功能何时发布。如果你将功能范围控制得足够小，每隔几周就能发布一些很酷的东西，那么下次见面时你就会有新的演示可以展示，他们会看到你在不断取得进展。
Planned Ship Dates 计划发货日期
Companies also announce new products in advance of their ship date. Here’s the easy but not always possible solution: Don’t do that. Don’t announce products before they’re ready to ship and you’ll never be tempted to push hard and cut corners to meet an imaginary, self-imposed deadline.
公司也会在产品发货日期之前宣布新产品。这里有一个简单但并不总是可行的解决方案：不要这样做。不要在产品准备发货之前宣布它们，这样你就永远不会为了满足一个虚构的、自我设定的截止日期而被迫拼命赶工和偷工减料。
Sometimes companies use early announcements to encourage customers to wait for your product rather than purchase from a competitor. For example, at the time of writing, both Playstation and Microsoft Xbox have announced that they will have new consoles in time for the holidays. If one had announced and the other hadn’t, people might have made plans to switch camps.
有时公司会利用早期公告来鼓励客户等待你的产品，而不是从竞争对手那里购买。例如，在撰写本文时，Playstation 和微软 Xbox 都已宣布将在假期前推出新主机。如果一方宣布而另一方没有，人们可能会计划转投阵营。
This is a risky move unless:
这是一个冒险的举动，除非：
- You have a well established relationship with the vendors you depend on and you’re certain they can deliver for you.
您与所依赖的供应商建立了稳固的关系，并且确信他们能够为您提供所需。 - You have a well established process and a track record with great insights into the timing of the components that will go into the product. (This is very rare in software due to lack of repeatable production).
您拥有一个完善的流程和良好的记录，对产品中各组件的时机把握有着深刻的见解。（这在软件领域非常罕见，因为缺乏可重复的生产过程）。 - Design is complete or almost complete, allowing for most of the product scope to be already discovered and accounted for.
设计已完成或接近完成，使得产品范围的大部分已被发现并考虑在内。 - You have some flexibility and can cut scope to meet the deadline, even if the deadline was “next month” instead of “6 months from now”.
你有一些灵活性，可以削减范围以赶上截止日期，即使截止日期是“下个月”而不是“从现在起的 6 个月”。
Ship dates frequently backfire when delivery dates are missed, leading to PR problems that can have a negative financial impact. For example, as I write this, a recent headline reads, “Shares Tank After the Firm Warns on Profits and Delays Three Big Games.”
发布日期经常在错过交付日期时适得其反，导致公关问题，可能对财务产生负面影响。例如，在我撰写此文时，最近一则头条新闻写道：“公司警告利润下滑并推迟三款大型游戏发布后，股价暴跌。”
Now, the bad news. While it is possible for well established companies with pre-existing vendor relationships to achieve those goals, almost none of that is ever true for software, for all the reasons already described.
现在，坏消息来了。虽然对于已经建立稳固供应商关系的成熟公司来说，实现这些目标是可能的，但由于之前描述的所有原因，这些几乎都不适用于软件领域。
That said, you can predict whether or not you will hit a specific delivery date as the work involved nears completion, if you’re paying special attention to the scope and moving low-priority items into follow up deliverables after the launch date. If you want to get a software product finished by a specific date, you need to be able to scale back the scope.
尽管如此，随着工作接近尾声，如果你特别关注范围并将低优先级项目移至发布后的后续交付中，你可以预测是否能赶上特定的交付日期。如果你想在特定日期前完成软件产品，你需要能够缩减范围。
Brooks’s Law 布鲁克斯法则
“Adding manpower to a late software project makes it later.”
“向一个已经延误的软件项目增加人力只会使其更加延误。”
You may have heard of Brooks’s Law: Adding manpower to a late software project makes it later.
你可能听说过布鲁克斯法则：向一个已经延期的软件项目增加人力只会让它更加延期。
Some explanations of the phenomenon include:
对这一现象的一些解释包括：
- New software developers require time to ramp up on any substantial application. Plan for 2–3 months before the developer can approach the average productivity of other members on the team. In the process of ramping up, new developers will have lots of questions about the project that only the early developers can answer, distracting your most productive people from their primary work on the project.
新加入的软件开发人员需要时间来熟悉任何大型应用程序。预计需要 2-3 个月的时间，开发人员才能接近团队其他成员的平均生产力水平。在熟悉过程中，新开发人员会对项目提出许多问题，只有早期开发人员才能解答，这会分散你团队中最具生产力的人员在项目上的主要工作精力。 - New developers often make mistakes that developers more familiar with the project and each component’s requirements would not have made, leading to an increase in rework.
新开发者常犯的错误，熟悉项目和每个组件要求的开发者通常不会犯，这导致了返工的增加。 - Communication overhead increases exponentially with each new developer on the project, leading to a combinatorial explosion of communication complexity and reduced visibility. For example, each new developer might open several direct-messaging channels with other project developers. Developers may decide they need to break out into meetings to coordinate, opening up several new sub-group communication channels, and so on. The more developers you have on the team, the harder it is to coordinate work on that team.
随着项目中每增加一名新开发者，沟通开销呈指数级增长，导致沟通复杂性的组合爆炸和可见性降低。例如，每位新开发者可能会与其他项目开发者开启多个直接消息渠道。开发者们可能认为需要召开会议来协调工作，从而开启多个新的子群组沟通渠道，以此类推。团队中的开发者越多，协调团队工作就越困难。 - The hardest part of software development isn’t writing the code. It’s decomposing complex problems into individually solvable, smaller problems. It’s often very difficult to break a task down into smaller pieces that individual developers can work on safely without getting in each other’s way. As Brooks points out: “nine women can’t make a baby in one month.”
软件开发中最难的部分不是编写代码，而是将复杂问题分解为可单独解决的较小问题。将任务拆分为各个开发者可以安全地独立工作而不互相干扰的小块，通常非常困难。正如布鲁克斯所指出的：“九位女性无法在一个月内生出一个婴儿。”
Additionally, you must be aware that software development projects progress more slowly the closer you get to delivery, as evidenced by this real month over month progress graph. Notice the contrast between the big jumps in the first couple months and the much smaller jumps later on in delivery:
此外，您必须意识到，软件开发项目越接近交付，进展速度就越慢，这一点可以从这个实际的月度进展图中看出。请注意前几个月的大幅进展与后期交付阶段的小幅进展之间的对比：
实际月度进展图表。
“Nine women can’t make a baby in one month.”
“九个女人也不能在一个月内生出一个孩子。”
Estimation Challenge: Solution
估算挑战：解决方案
When I asked you to write down your estimate for the number of bees in a colony, did you write down questions? We don’t really have all the information we need to make an estimate, do we? What are we trying to count, exactly?
当我让你写下你对一个蜂群中蜜蜂数量的估计时，你写下了问题吗？我们确实没有做出估计所需的全部信息，对吧？我们到底在试图计算什么？
- Are we talking about the number of bees who participate in a colony during the course of the total life of the colony?
我们讨论的是在整个蜂群生命周期中参与蜂群的蜜蜂数量吗？ - The total for a full year?
一整年的总数？ - The average number actually in a beehive at a particular point in time?
特定时间点蜂箱内实际的平均蜜蜂数量？ - Are the numbers different for different geographies?
不同地理区域的数字是否不同？
Did you provide a range, or a specific number? Most software developers will give you a specific number when you ask them for an estimate, trading accuracy for precision, but measured software engineering task timelines fall onto a power law curve with a very wide range. Nobody consistently delivers a feature “in one day” or “in about 2 weeks”.
你提供的是一个范围还是一个具体数字？大多数软件开发者在被要求估算时，会给出一个具体数字，以精确度换取准确性，但经过测量的软件工程任务时间线遵循幂律曲线，范围非常广泛。没有人能始终如一地在“一天内”或“大约两周内”交付一个功能。
Discovering Hidden Complexity
发现隐藏的复杂性
Most software engineers, when pressed, will provide an estimate, even knowing that they don’t know everything they need to know to do so accurately. What’s their average ticket velocity? Do they know? How many tickets will they need to complete to do the job? Have they sat down and figured out all the components they’ll need to build and tasks they’ll need to complete? Have they rated the complexity of each task and broken them down into all the necessary sub-tasks to achieve a reasonable estimate?
大多数软件工程师在被催促时，都会给出一个估算，即使他们知道自己并不完全了解准确估算所需的所有信息。他们的平均工单处理速度是多少？他们知道吗？完成这项工作需要处理多少张工单？他们是否坐下来仔细思考过需要构建的所有组件和需要完成的所有任务？他们是否评估了每项任务的复杂性，并将其分解为所有必要的子任务，以便得出一个合理的估算？
The truth is that the process of doing that breakdown is a big chunk of the process of designing a software application, and it works best if discovery and implementation progress incrementally, rather than all design up-front because design intentions are often at odds with the technical realities we discover when we begin to implement the design in code.
事实上，进行这种分解的过程是设计软件应用程序过程中的重要部分，而且如果发现和实现能够逐步推进，而不是一次性完成所有设计，效果会更好。因为设计意图往往与我们在开始用代码实现设计时发现的技术现实相冲突。
Everything in software development is composition: The process of breaking large, complex problems down into smaller, independently solvable problems, and then composing those solutions. The hardest part isn’t building and assembling those component solutions. It’s breaking down the problems correctly and designing the interfaces that the components will use to compose together and communicate.
软件开发中的一切都是组合：将庞大、复杂的问题分解为更小、可独立解决的问题，然后将这些解决方案组合起来的过程。最困难的部分不是构建和组装这些组件解决方案，而是正确地分解问题，并设计组件之间用于组合和通信的接口。
In other words, you can’t accurately predict software completion dates without actually performing a substantial amount of the software engineering work.
换句话说，如果不实际执行大量的软件工程工作，就无法准确预测软件的完成日期。
Even if you’re measuring historical velocity and applying those velocity measurements to the number of currently open issues in the project, as you work on the project, many of the current issues will be split into many more issues as the work progresses and additional complexity is discovered. Real issue burn-down charts are not straight lines or smooth curves. They look more like stock tickers with random, unpredictable up and down movements as scope is uncovered and items are completed.
即使你测量了历史速度并将这些速度测量应用于项目中当前开放的问题数量，随着你在项目中的工作进展，许多当前问题会随着工作的推进和额外复杂性的发现而被拆分成更多问题。真正的问题燃尽图并不是直线或平滑曲线。它们看起来更像是股票行情，随着范围的揭示和项目的完成，呈现出随机且不可预测的上下波动。
真实的软件燃尽图。圆点代表该时间点的未解决问题数量。
It tends to grow at the beginning of a project until it hits a fairly steady range (dependent on the complexity and number of developers working on the project) and then moves mostly sideways with occasional sharp up and down spurts, until you reach 70% — 90%, and then it starts to average noticeably downwards.
它往往在项目初期增长，直到达到一个相对稳定的范围（取决于项目的复杂性和开发人员的数量），然后大部分时间横向移动，偶尔会有急剧的上下波动，直到达到 70%到 90%，之后开始明显呈下降趋势。
Honeybee colonies are typically home to 10k to 80k bees.
蜂群通常由 1 万到 8 万只蜜蜂组成。
- If you guessed a number less than that range, you lose. You’ve missed your deadline. Game over.
如果你猜的数字小于这个范围，你就输了。你已经错过了截止日期。游戏结束。 - If you guessed a number above that range, your boss figures out your game (under promise, over deliver) and starts cutting your estimates in half for public product announcements. You miss a deadline set by the marketing team in response. You lose.
如果你猜的数字超出了那个范围，你的老板会识破你的把戏（承诺少，交付多），并开始将你对公开产品发布的预估时间减半。结果，你错过了营销团队为此设定的截止日期。你输了。 - If you guessed a range and your top number is below 10k, you lose.
如果你猜了一个范围，而你的最高数字低于 1 万，你就输了。 - If you guessed a fixed number inside the range, subtract the difference between your guess and 45,000 and multiply by -1. That’s your score. Congratulations! You didn’t lose. But you didn’t exactly win, either.
如果你猜的是范围内的一个固定数字，用你的猜测减去 45,000，再乘以-1，这就是你的得分。恭喜！你没有输。但你也没有真正赢。 - If you guessed a range with both numbers in the range, congratulations! You get one point.
如果你猜中了一个包含两个数字的范围，恭喜你！你得一分。
What’s the solution to the seemingly impossible challenge of software estimation? Don’t do it.
软件估算这一看似不可能的挑战的解决方案是什么？不要去做。
The keys to freeing yourself from estimation lies are simple:
摆脱估算谎言的关键很简单：
- Demos over deadlines. 演示重于截止日期。
- Control scope. 控制范围。
- Set priorities. 设定优先级。
If you need a deadline or you have an imposed budget, don’t try to cram every feature into the given timeline. Instead, design the system to be modular and easy to adapt to changing scope, and then adjust the scope as needed. This requires careful coordination with the product teams and stakeholders to identify what the real priorities should be. Solve the problems in order of priority. Mercilessly cut lower priority features out of the project.
如果你有截止日期或预算限制，不要试图将所有功能都塞进给定的时间表。相反，设计系统时要使其模块化且易于适应变化的需求范围，然后根据需要调整范围。这需要与产品团队和利益相关者仔细协调，以确定真正的优先级。按优先级顺序解决问题。无情地将低优先级的功能从项目中剔除。
Instead of trying to push more work through the clogged delivery pipeline, clear the clog by reducing the amount of work that needs to fit through the pipeline.
与其试图通过堵塞的交付管道推送更多工作，不如通过减少需要通过管道的工作量来清除堵塞。
If you have a fixed budget, learn how to trim your big software dreams down to a lean MVP. Cut the fat. Watch your burn down charts and your month-over-month progress chart, and make sure you’re not giving your team more work than they can get done without cutting corners.
如果你有固定的预算，学会如何将宏大的软件梦想精简为一个精益的 MVP。削减冗余。密切关注你的燃尽图和月度进展图，确保没有给团队分配超出他们能力范围的工作，同时避免偷工减料。
The result of applying demos over deadlines is a happier, more productive development team that will never ship late again.
在截止日期上应用演示的结果是一个更快乐、更高效的开发团队，他们将永远不会再延迟交付。
Next Steps 下一步
DevAnywhere.io offers 1:1 mentorship to software leaders on a variety of topics including:
DevAnywhere.io 为软件领导者提供一对一的指导，涵盖多种主题，包括：
- Strategy 策略
- Team building, hiring, and onboarding
团队建设、招聘与入职 - Cultivating healthy development culture
培养健康的开发文化 - Effective software development process
高效的软件开发流程 - Continuous discovery and continuous delivery
持续发现与持续交付 - Managing software quality
管理软件质量 - Budgets and compensation 预算与薪酬
- Conflict resolution 冲突解决
- Technical debt 技术债务
Ask us about our leadership track where we help everyone from aspiring tech leads to CEOs understand how to effectively manage software teams, and follow us on Twitter.
向我们咨询我们的领导力发展路径，我们帮助从有志成为技术主管到 CEO 的每个人理解如何有效管理软件团队，并在 Twitter 上关注我们。
Eric Elliott is a tech product and platform advisor, author of “Composing Software”, cofounder of EricElliottJS.com and DevAnywhere.io, and dev team mentor. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.
埃里克·埃利奥特（Eric Elliott）是一位技术产品和平台顾问，《编写软件》一书的作者，EricElliottJS.com 和 DevAnywhere.io 的联合创始人，以及开发团队导师。他曾为 Adobe Systems、尊巴健身、《华尔街日报》、ESPN、BBC 等公司以及包括亚瑟小子、弗兰克·奥申、金属乐队在内的顶级音乐艺术家贡献过软件体验。
He enjoys a remote lifestyle with the most beautiful woman in the world.
他享受着与世界上最美丽的女人一起的远程生活方式。
