破坏开发人员生产力的12大事情

 

`

Top 12 Things That Destroy Developer Productivity

A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how to increase a team’s productivity. But before you focus your energy trying to increase their productivity, you might first want to consider what’s destroying it, to have a sound base on which you can build. Unfortunately, even though Peopleware was published almost 30 years ago, we see lots of teams suffering from huge productivity loss in some (negatively) remarkable ways!

No one expects a programmer to get work done without access to a computer, but there are many companies that expect programmers to get work done without access to their mind. This is equally unrealistic.

So let’s deep dive into our list of 12 things that prevent your developers from getting “into the zone” and being productive. I will try to prioritize this list from most to least impactful. Feel free to comment!

If you’re wondering if all this is worth the investment, just consider the developer’s salaries. Even 10% more productivity is a LOT!

1) Interruptions & Meetings

Interruptions are the top productivity killer for developers, in my mind. Developers can’t easily go back to where they were right before an interruption. They need to get into the mindset for development and then slowly trace back to where they left off. This can easily take more than 30 minutes. And the more interruptions, the more frustration, the less quality work, the more bugs — and it goes on.

“The more times you trip me up while I’m trying to get started — the longer between each time I’m going to try. If you fill my morning with interruptions — don’t be surprised when the day is unproductive.” A developer on Reddit

What about meetings? The only difference between a meeting and an interruption is that a meeting is a planned interruption, which makes it even worse. Developers can’t progress on a task if they know that they will have an interruption while working on it. So if they have a meeting in one or two hours, they will not be able to progress on anything, as most engineering tasks take more time.

As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in.”

How can this be avoided? This part is well documented; you have no excuse. Hold short status meetings at the very start of the day or just before lunch, for example, to avoid unnecessary interruptions.

2) Micro-management

Of the different types of managers, micro-managers might be the worst in terms of the developers’ productivity. Sure, micro-managers tend to have more meetings and unplanned interruptions. But it’s not only that. They show a lack of trust, and by doing so, you feel they constantly undermine your skills and your ability to get things done. Any motivation a developer had between interruptions will be just gone at that point. The impact goes beyond productivity. Micro-managers might be the first reason for developers to leave, or at the very least, to change teams.

3) Vagueness

There are many ways to illustrate vagueness. Bug reports like “It’s broken, fix it!” don’t have enough information for developers to work off of. By the way, having a bug report template can help in that case.

Or unclear specification on a feature, in which case developers will start implementing what feels right to them, before they have to start again from scratch once the manager better details the expected behavior.

Unclear prioritization also belongs in this category. The time that a developer spends wondering if they are working on the right task can so easily be avoided. And if ever they get a comment from the manager asking why they worked on this particular task (while priorities were not defined)…well, you get it — a lot of frustration…

4) Seagull Management

Have you ever heard of it? It happens when managers are totally uninvolved in the work, but… they just swoop down once in a while to shit all over everything. “This is wrong, and this, and this looks bad,” etc., before flying away again. I have to admit I loved the image, but unfortunately, this happens more often than we would like it to. This behavior is deeply frustrating to developers; they won’t be able to get back in the zone in the next few hours, and sometimes not even for days.

5) Credit Greediness

Have you ever had a manager or other developer who took all the credit for the work you have done in the past weeks? Developers value competence above all. Taking the credit for someone else is taking the other’s competence for yourself and removing it from him or her. This is pretty high up on my list, as I feel it creates so much tension that it just destroys the whole developers’ productivity for quite a while.

6) Environment — Noises, Motion, Workspace Design…

This might seem strange to non-programmers, but the environment in which developers work has an important impact on their activities. For instance, having some white noise — loud AC, hearing cars and trucks roll by — helps them focus better. That’s why so many of us put headsets on! I actually just discovered RainyMood — really great 👍!

Similarly, if the workspace is designed to have as much motion as possible, that won’t help them focus! Or having the desktop computer screens oriented in such a way that they are highly visible to the managers…well, that creates some extra stress and even more opportunities to be interrupted.

7) Scope Creepiness

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled.

Scope creep turns relatively simple requests into horribly complex and time-consuming monsters! And most of the time it happens during development! For instance, for a simple feature:
 Version 1 (before implementation): feature is “Show a map of the location”
 Version 2 (when version 1 almost finished): feature is changed to “Show a 3D map of the location”
 Version 3 (when version 2 almost finished): feature again changed to “Show a 3D map of the location that the user can fly through”

8) Product Definition Process

So this one might seem strange at first glance, but is actually pretty easy to understand. If a product team defines its team’s priorities without ever validating (through customer feedback or any other means) the interest of the corresponding features, and the developers see that most features are eventually just not used, they will feel that what they do is useless and will lose their motivation. We all want to feel impactful, and that may be even more important to developers!

9) Lack of Consideration to Technical Debt

Technical debt is a deliberate decision to implement not-the-best solution or write not-the-best code to release software faster. Taking on some technical debt is inevitable and can increase speed in software development in the short run. However, in the long run, it contributes to system complexity, which slows the developers down. Non-programmers often underestimate the loss of productivity and are tempted to always move forward, and that becomes an issue.
 But if refactoring is never part of the priorities, it will not only impact productivity but also product quality.

10) Tool Multiplicity & Hardware

Developers use many tools to program, push and merge their code every day. The more automation, the better. It goes without saying that if you use “ancient” tools, this will impact your productivity. Similarly, having a big screen vs only a laptop can have an impact. Given the cost of hardware and the developer’s salary, having just a 5% productivity gain is definitely worth any investment on that point! Just give the tools and hardware that your developer team prefers (individually for hardware, but as a group for the tools).

11) “How” Documentation

When learning how to code, we were told to comment early and often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers incorrectly interpret this to mean that they must comment every single line of code, which is why we often see code like this (from Jeff Atwood’s post on “Coding Without Comments”):

r = n / 2; // Set r to n divided by 2

// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)

}

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it. If there were a bug in the program and you stumbled across this code, you wouldn’t know where to begin.

12) Impossibly Tight Deadlines

This last one is linked to the tendency of managers to ask developers for estimates, then push them to lower those estimates as much as possible, and then magically consider them as deadlines! Managers will even consider that, as the developers themselves “decided” on the estimate, they committed to the deadlines, and therefore the deadlines should be considered valid enough to be shared to upper management.

 

 

 

Not surprisingly, developers feel that those deadlines are unreasonable and arbitrarily tight; this creates tension and an inability to focus.

How are all those things unique to developers?
 If you look at all 12 things, they are actually pretty common to most other project-based jobs. It’s just that the impact of each of these is even more important for developers, as they need deep focus to progress on their tasks.

If you recognize some points mentioned above within your company, it might be interesting to address them with your developers. Talk to them; find out if these are an issue and how it can be resolved. Whatever they say, the most important thing is to trust their feedback and insights. And while today’s technology is very different from 30 years ago, the lesson is still the same. You can’t ignore the human factor when you consider team productivity. Iterate on your processes, environment and work habits with your team, and let them guide you on how to have the highest productivity and impact.

Before you go…

Did you find the article interesting? Please holding down the 👏 to say “thanks” and help others find it! 
If you are interested in articles about engineering and product leadership, productivity and how to scale a team, subscribe to our newsletter!

https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190?ref=hackernoon.com

 

~

 

很多文章讨论了技术主管和工程经理的角色。我们经常遇到的一个常见主题是如何提高团队的生产力。但是，在集中精力尝试提高生产率之前，您可能首先需要考虑破坏它的因素，以便为您提供可靠的基础。不幸的是，即使Peopleware发布于30年前，我们仍然看到许多团队以某些（负面）显着的方式遭受巨大的生产力损失！

没有人期望程序员无需访问计算机就可以完成工作，但是有许多公司希望程序员无需理会它们就可以完成工作。这同样是不现实的。

因此，让我们深入了解我们的12项清单，这些清单可防止您的开发人员“陷入困境”并提高工作效率。我将尝试从影响最大到影响最小的问题来排列此列表的优先级。随时发表评论！

如果您想知道这一切是否值得投资，请考虑开发人员的薪水。生产率甚至提高了10％！

1）中断与会议

在我看来，中断是开发人员的最大生产力杀手。开发人员无法轻松地回到中断之前的位置。他们需要进入开发的思维定势，然后慢慢追溯到他们离开的地方。这很容易耗时30分钟以上。而且，中断次数越多，挫折感就越多，工作质量越差，漏洞也就越多。 “在我尝试入门时，您绊倒我的次数越多-每次尝试之间的时间就越长。如果您在打扰我的早晨时感到不安-the当一天没有生产力时，请不要感到惊讶。” Reddit上的开发人员 会议呢？会议和中断之间的唯一区别是，会议是计划中的中断，这使情况变得更糟。如果开发人员知道自己在执行任务时会受到干扰，则他们将无法完成任务。因此，如果他们在一两个小时内开会，他们将无法进行任何事情，因为大多数工程任务需要花费更多时间。 就像保罗·格雷厄姆（Paul Graham）所说：“一次会议可以将整个下午分为两部分，整个下午都非常小，以至于很难做任何事情。” 如何避免这种情况？这部分有据可查；你没有任何借口。例如，在一天的开始或午餐前举行简短的状态会议，以避免不必要的干扰。

 

2）微观管理

在不同类型的经理中，就开发人员的生产力而言，微观经理可能是最差的。当然，微观经理往往会举行更多会议，并计划外打扰。不仅如此。他们表现出缺乏信任，因此，您会感到他们不断破坏您的技能和完成工作的能力。此时，开发人员在中断之间产生的任何动力都将消失。影响不只是生产力。微观经理可能是开发人员离开或至少改变团队的首要原因。

 

3）模糊性

有很多方法可以说明模糊性。错误报告，例如“它坏了，请修复！”没有足够的信息供开发人员使用。顺便说一句，在这种情况下，具有错误报告模板可以为您提供帮助。 或对功能的规格不明确，在这种情况下，一旦经理更好地详细说明了预期的行为，开发人员将开始实施对他们而言合适的感觉，然后他们必须从头开始。 不清楚的优先级也属于此类别。可以很容易地避免开发人员花时间思考他们是否在执行正确的任务。而且，如果他们从经理那里得到评论，问他们为什么要从事这个特定​​任务（而未定义优先级）……那么，您就明白了……-很沮丧……

 

4）海鸥管理

你听说过吗？当管理人员完全不参与工作时，就会发生这种情况，但是……他们只是不时地俯冲下来，把所有事情都搞砸了。 “这是错的，现在看起来很糟，”等，然后又飞走了。我必须承认我喜欢这张照片，但是不幸的是，这种情况发生的次数比我们希望的要多。这种行为使开发人员深感沮丧。他们将在接下来的几个小时内无法返回该区域，有时甚至连几天都无法返回。 5）信用贪婪 您是否曾经有一位经理或其他开发人员将您过去几周所做的工作全部归功于您？开发商最看重能力。为别人效劳是您自己的能力，并将其从他或她身上删除。这在我的清单上名列前茅，因为我觉得它造成了很大的压力，甚至在相当长的一段时间内破坏了整个开发人员的工作效率。

 

 

6）环境—噪声，运动，工作区设计…

 

对于非程序员来说，这似乎很奇怪，但是开发人员工作的环境对其活动有重要影响。例如，有一些白噪声-交流声很大，聆听汽车和卡车的声—帮助他们更好地集中注意力。这就是为什么我们很多人戴上耳机的原因！我实际上只是发现了RainyMood，“真的很棒”！

同样，如果工作区被设计为具有尽可能多的运动，那将无法帮助他们集中精力！或者将桌面计算机屏幕的方向设置为经理可以高度看到它们的方式……那么，这会产生一些额外的压力，甚至带来更多被打断的机会。

~

7）范围蠕变

项目管理中的范围蠕变（也称为焦点蠕变，需求蠕变，特征蠕变，有时还包括厨房水槽综合症）是指项目范围内不受控制的更改。当未正确定义，记录或控制项目范围时，可能会发生这种情况。

范围爬行将相对简单的请求变成了极其复杂且耗时的怪物！而且大部分时间都是在开发过程中发生的！

例如，对于一个简单的功能：

版本1（实施之前）：功能为“显示位置地图”
版本2（版本1即将完成时）：功能更改为“显示位置的3D地图”
版本3（版本2即将完成时）：功能再次更改为“显示用户可以飞过的位置的3D地图”

 

8）产品定义过程

因此，乍一看，这似乎很奇怪，但实际上很容易理解。如果产品团队在没有验证（通过客户反馈或任何其他方式）相应功能的利益的情况下定义其团队的优先级，并且开发人员看到大多数功能最终都未被使用，他们会觉得他们所做的事情是无用的，并且会失去动力。我们都希望感到有影响力，这对开发人员而言可能更重要！

 

9）缺乏对技术债务的考虑

技术债务是实施非最佳解决方案或编写非最佳代码以更快地发布软件的故意决定。承担一些技术债务是不可避免的，并且可以在短期内提高软件开发的速度。但是，从长远来看，它会增加系统的复杂性，从而降低开发人员的速度。非程序员通常会低估生产力的损失，并倾向于始终前进，这成为一个问题。 但是，如果重构从来都不是优先事项，它将不仅影响生产率，而且还会影响产品质量。

 

 

10）工具多样性和硬件

开发人员每天使用许多工具来编程，推送和合并他们的代码。自动化程度越高，效果越好。不用说，如果您使用“古老”的工具，这将影响您的生产率。同样，大屏幕而不是笔记本电脑会产生影响。考虑到硬件成本和开发人员的薪水，在这一点上，仅将5％的生产率提高绝对值得任何投资！只需提供开发人员团队喜欢的工具和硬件即可（对于硬件，单独地，但对于工具，则是一组）。 11）“如何”文档 在学习编码方法时，我们被告知要提早并经常发表评论。想法是，评论太多而不是评论太多。不幸的是，许多程序员错误地认为这意味着他们必须注释每一行代码，这就是为什么我们经常看到这样的代码的原因（摘自Jeff Atwood的“无注释编码”文章）： r = n / 2; //将r设置为n除以2 //当r —（n / r）大于t时循环（abs（r —（n / r））> t）{r = 0.5 *（r +（n / r））; //将r设置为r +（n / r）的一半 } 您知道这段代码的作用吗？我也不。问题是，尽管有很多注释描述了代码的作用，但是却没有描述其原因的注释。如果程序中有错误，而您偶然发现了这段代码，您将不知道从哪里开始。

 

12）截止日期不可能太紧

这最后一个与管理人员倾向于向开发人员索要估计值，然后促使他们尽可能降低这些估计值，然后将其神奇地视为截止日期联系在一起！经理们甚至会认为，当开发人员自己“决定”估算时，他们会遵守截止日期，因此，截止日期应被视为足够有效，可以与高层管理人员共享。

不足为奇的是，开发人员认为这些截止日期是不合理的并且任意紧迫。这会造成紧张感和无法专注。

这些东西对开发人员来说如何独特？ 如果您查看全部12项内容，它们实际上对于大多数其他基于项目的工作来说是很常见的。只是对于开发人员而言，每一项的影响都更为重要，因为他们需要深入关注才能完成任务。

如果您认识到公司内部的上述几点，那么与开发人员联系可能会很有趣。与他们交谈;找出这些是否是一个问题以及如何解决。无论他们说什么，最重要的是信任他们的反馈和见解。尽管当今的技术与30年前有很大的不同，但教训仍然是相同的。考虑团队生产力时，您不能忽略人为因素。与团队一起迭代您的流程，环境和工作习惯，并让他们指导您如何获得最高的生产力和影响力。

 

 

 

~

 扩展阅读：

 

如果你曾在一家高速增长的软件工程公司待过，你可能会听过类似这样的一段对话，是关于技术债务的：

张三：“如果我们只做 X 的话，那么我们可以更快地交付……”
李四：“说得挺有道理的嘛，那你为什么还不去做呢？”
张三：“哎！我们要做这么多功能，哪有时间啊，根本做不过来。”

或者是类似这样的评论：

“我们真的需要这么做。我们应该停止所有的功能开发工作，直到解决这个问题为止。”

对于这种情况，我一直持观望态度。当我站在李四的立场来看，解决问题几乎总是合乎逻辑的，但并不总是能得到所需的支持！
那么，问题究竟在哪儿呢？为什么偿还技术债务明明是一个很明显且合理的举措，但是却很难说服大家来做呢？

1，我们对技术债务的定义正确吗？

“技术债务” （Technical Debt 或 Tech Debt），这一古老的流行语通常被当成一个包罗万象的术语，用来描述我们希望我们所构建或正在开发软件更好的东西。由于在开发早期阶段所做的一些捷径或权衡，软件通常并不会达到预期的状态。

凡是被贴上技术债务标签的东西，几乎都是软件的非功能性更改。比如，重构代码来消除全局代码，从而支持依赖项输入、修复（或添加）测试、改进文档、甚至让测试套件在 CI 中运行，或者最终实现部署的自动化之类的事情。

因为这些东西都不是功能性的改变，也不会改变软件的行为，所以对客户来说，这些改进他们很可能看不到。因此，如果客户并不会看到你在这个技术债务上所耗费的时间以及软件的任何变化，那你提交的价值又在哪儿呢？又为什么要在技术债务上投入时间呢？

2，如何向别人阐述解决技术债务的价值？

向客户阐述解决技术债务的商业价值，是获得解决债务所需时间的关键。
通常来说，人都会抱有一种固定思维模式（ “我们也想解决这个问题啊，但我们没有得到允许去解决这个问题呀” ）。记住，在任何组织中，人们都会作出决策，决策是关于权衡的，是可以受到影响、被推翻或改变。更重要的是，组织也在不断变化，昨天做出的决策方式，到明天可能就行不通了！

如果说沟通价值是关键，那么技术债务的偿还价值应该如何沟通呢？对于这一问题，没有一个放之四海而皆准的答案：但我写下本文的初衷是勾勒出这么一个框架，帮助产品团队或工程团队对问题进行分类、时间分配，并明确为什么每段时间都应根据它将提供的价值进行适当的调整。

我希望本文勾勒出的框架能够帮助你与利益相关者保持一致，让你能够更有效地沟通价值，并让你最终解决你一直想解决的技术债务问题。

3，解决技术债务的最简单方法

“解决问题的最简单方法就是否认它的存在。”——Isaac Asimov
当我们遇到技术债务问题时，要先问问自己：这里真的有问题吗？很可能不值得付出，除非：

• 它提高了产出的速度或质量。例如，重做这个构建配置将使我们的交付时间缩短一半，使部署频率增加一倍。
• 延误导致高昂的代价，造成工期紧迫。例如，如果我们现在不解决这个问题的话，将直接影响客户、利润或者是收入。
  如果它不是我上面说的这两种情况中的一种，最好是直接忽略它。

 

4，将所有工作进行分类

在组织的每个计划阶段，无论你的计划节奏或持续时间是怎样的，都应该能够将所有工作进行分类或分配到以下四个方面之一：

• 功能改进：提供客户看得到或用得到的功能改变。通常情况下，产品经理 / 所有者会根据研究和客户的意见，对如何优先考虑这方面的优先级进行深入研究。示例：新颖的新功能。
• 计划工作：更大范围工作的一部分，是在团队之外 / 组织内部进行的，通常由项目经理协调，将你的团队列为该工作计划的依赖者。示例：全平台本地化 / 国际化工作。
• 交付能力：以可量化的方式提高交付速度或产出质量。示例：将部署过程自动化，以便更快 / 更频繁地将代码从主干 / 主分支投入到生产环境中。
• 计划外工作：当延误会导致高昂的代价，且造成工期紧迫时，你应优先考虑这项工作，并立即解决问题，或者是与其他所有正在进行的事情一起解决，而不是将它们推迟到你的积压工作中或未来的周期，包括 bug、客户支持请求、生产事故等。示例：影响 20% 的客户的生产停工。
  通过将工作归类到这四个方面中，沟通工作的价值应该会变得更容易，并且腾出时间来处理技术债务问题也会变得更容易。

请注意，上述分类应该适用于整个积压工作，而不仅仅是技术债务问题，因为将时间分配给技术债务问题就意味着不能将时间分配给其他工作了。还要注意的是，技术债务可能会被归类为交付能力或计划外工作。

5，规划的层次结构

前面我提到的 “在每个阶段” 是有原因的：能够在组织层次之间用一致的词汇进行沟通，有助于影响解决技术债务问题的投资决策。
许多科技公司采用的模式是，每个小组、团队或 “双披萨” 团队往往负责管理受组织层次影响的积压工作。如果你的组织是这样运作的，那么让决策层了解这一框架将有助于你在术语、逻辑和论证上保持一致。
译注：“双披萨”团队是指遵循两个披萨原则的团队。两个披萨原则最早是由亚马逊 CEO 贝索斯提出的，他认为如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。因为人数过多的项目会议将不利于决策的形成，而让一个小团队在一起做项目、开会讨论，则更有利于达成共识，并能够有效促进企业内部的创新。亚马逊内部有所谓的 “双披萨” 团队，指的是团队的人数相当于可以吃掉 2 个披萨，这种组织理论非常知名。“双披萨” 团队得名的由来，是因为团队的成员很少，只有 6-10 人，用两张披萨就能喂饱他们。“双披萨” 团队最重要的不是规模，而是它的 “适度职责”。它相当于为一个部门的损益负责，可以让团队保持专注、负上责任。在一些案例中，“适度职责” 本身就是为损益负责，例如，如果我是 SEM（ 搜索引擎优化）团队的一员，我的职责就是通过赞助链接提高营收，获得更多利润，降低点击的成本。一旦获得批准，团队就可以相对自治的执行，将 “适度职责” 最大化，它们可以寻找创新战略，然后将战略作为内部优先之事对待。一些工程师，搭配一个或者两个技术产品经理，配一个设计师，他们直接向 “双披萨” 团队的主管报告；在团队之间没有必要协作，他们可以独立在各部门间行动，将工作完成。这种模式让亚马逊在增长的同时保持敏捷和创新。

 

6，无法分类的技术债务问题

与任何模型或框架一样，也存在不适合其结构的极端情况。乍一看，你可能无法忽略某个问题，但又不能将其分类为交付能力或计划外工作。请不要在第一眼看到问题时就放弃：督促自己找到一种方法，通过稍微深入地研究问题的细节（或与同行、中小企业进行合作），将这些问题合理地归结为其中之一。如果在第二次尝试后仍然不适合，那也没有关系。
“这个代码很难测试。” —— 这是那些令人感到棘手的场景中的一个例子，在这种场景下，可能很难直接忽略它，或者说你不清楚如何对它进行分类。遇到这种情况，我建议采用以下方法：
对你的代码做一些小规模的、渐进式的改进，不要试图花时间来解决 “大爆炸式” 项目。
每个拉取请求（Pull Request）都应该改进你的代码、改进你的测试，并提高测试覆盖率（或者至少不能退步！）。CI 系统中的质量检验甚至可以强制执行一些规则，例如不允许测试覆盖率下降超过 X%，并且要求最低覆盖率为 Y%。
如果这看起来不是一个易于处理的方法，那么你可能需要找到一种方法来重新定义问题，以便将问题分解成更小的 “块” ，也许其中一些部分可以被忽略，一些部分可以被分类，还有一些部分可以用上面提到的即用即付（PAYG）方法来处理。

 

7，合理分配时间

一旦你将工作分类到四个方面之一之后，下一步就是 “切馅饼” 或者为每个方面分配估计的时间。
这四个方面的时间分配如下：
40% 时间用于功能改进；
10% 时间用于计划工作；
20% 时间用于交付能力；
30% 时间用于计划外工作。

 

8，确定正确的时间分配比例
下面是我成功使用过的一个方法：从确定数字开始，与利益相关者一起审查，然后在适当的地方进行调整。
如果没有利益相关的参与，就无法成功确定时间分配比例，这主要是因为这些比例通常是可以协商的，但也涉及许多决策，因此需要进行权衡。
你应该按什么顺序来确定数字？
 1) 第一个要确定数字的是 计划外工作；

这不应该是你自己决定的事情，而应该以你所掌握的数据为基础，这些数据可以让你能够推断出对未来一段时间的预期。例如，如果你在做季度计划，你可能会看前一个季度所花费的时间，以及（特别是受季节性影响的企业）上一年同一季度所花费的时间。如果利益相关者试图就这一数字进行协商，请向他们介绍你是如何确定这一数字的，并帮助他们了解你的实际情况。

 2) 要确定的第二个数字是 交付能力。

为什么呢？基于上述框架，我们希望从一个有目标、但有基础的数字开始。每个人都应该有减少计划外工作的动力，而交付能力就是实现这一目标的重点。如果你的计划外工作 “太大” （每个企业的容忍度不同），请考虑增加你的交付能力时间分配，直到该数字变得可接受为止。如果你下调了这一数字，请确保已与利益相关者就此沟通并进行权衡。
建议：Google SRE 一书中关于 “拥抱风险” 主题在识别企业内部的风险承受能力方面有一些很好的想法，这可能有助于确定分配多少时间给交付能力这方面。虽然对某些团队或组织来说，使用错误预算可能是一个非常有效的选择，但同意一个管理错误预算和实施或测量 SLO 的系统本身往往是一个挑战。我在本文中介绍的框架时间分配或许有些重叠，但在某些方面可能提供了一种分配时间的替代路径，以解决一些质量或可靠性问题，否则这些问题将使用错误预算来解决。

 3) 要确定的第三个数字是 计划工作。

这些要求通常来自其他团队或业务部门，有的要求比较好商量。试着根据你认为接下来的时间必须要做的事情来确定这方面的时间分配。
要确定的最后一个数字是 功能改进。此时，你已经确定了分配时间，因为你这时候处理的是剩余的百分比。你可能听说过 “价值流” 这个术语，团队的活动应该以满足客户的要求为目标。这方面通常是最主要的，它直接解决的是你的客户想 “看到” 的东西。如果这方面的时间分配对于你认为需要交付的价值而言过小，以至于不能满足你的客户在新功能交付方面的期望，我们将很快为这一方面提供更多的时间分配。

一旦完成每个方面的初始时间分配，你将需要考虑如何根据与利益相关者的讨论对此进行调整，在这个框架内有两个 “杠杆” 可供考虑：
  a.交付能力工作应该减少计划外工作。
  b.计划工作影响功能改进工作。

①减少计划外工作
理想情况下，任何分类为交付能力的工作都会减少下一个计划周期或工作节奏的计划外工作量。
建议：请阅读 Nicole Forsgren 博士、Jez Humble 和 Gene Kim 所著的《加速》（Accelerate）一书——这是一本关于衡量和思考如何提高软件交付能力的优秀指南，里面有关于软件交付能力的优秀定义，以及 4 个关键指标，即交付周期、部署频率、平均恢复时间（Mean Time To Restore，MTTR）和变更失败率。
交付能力可能会在两方面影响计划外工作：
交付能力工作应降低平均恢复时间。即使计划外工作方面中的 bug 或问题的数量没有减少，解决它们所需的时间也应该减少，从而减少分配给计划外工作方面所需的总时间。
交付能力工作应提高产出质量，从而降低变更失败率。理想情况下，我们希望看到导致计划外工作方面的问题能随着时间的推移而减少，而提高产出质量（在正确性、可靠性、性能、安全性等方面）恰恰可以做到这一点。根据具体情况，有时优先考虑平均恢复时间，而不是降低变更失败率的做法是有意义的，例如，如果恢复能力需要几天的时间，而故障的数量很少，但却保持不变，那么在选择减少平均恢复时间并更快地解决这些未来问题之前，你可能会为客户提供更多的价值，因为停机或 bug 的持续时间可能比数量的影响更大。我们的目的是利用这两个变量，但要根据客户的价值来构建决策过程。
②计划工作的影响
我认为，计划工作和功能改进之间的平衡是一种分配杠杆。通过与计划的利益相关者合作，有时你可以推迟或重新分配你的团队被要求做的工作 —— 只要这个决定的理由清楚地表达出来，并且这些利益相关者也同意进行出这样的权衡。
计划通常是由多个项目、团队和依赖项组成的庞大而复杂的工作。重要是要保持平衡，所以你要预料到 “阻击者”，避免成为其他团队的 “阻击者”。项目经理或高层很容易要求你的团队提前完成相关工作，但从你的角度来看，将工作推迟一周 / 月 / 季度可能意味着你分配时间改变的方式，以及最终你的团队能够为客户带来的价值存在着巨大的差异。
考虑到计划外工作在某种程度上是固定的，而降低计划外工作的杠杆很大程度上就是交付性能 —— 当你试图找到更多时间分配给功能改进时，我建议与计划利益相关者合作，允许你减少对计划工作的分配时间。你应该能够做到这一点，通过解释你时间分配的原因，以及为什么你认为对你的客户来说，推迟他们的请求是最好的事情。
由于这个杠杆的结构方式，他们所做的权衡实际上是将价值传递给特定于你产品的客户，而不是致力于进行更大的创新。

③最大化分配时间

一旦你的团队完成了将待办事项分类到这四个方面中的一个，并为每个方面分配了一定比例的工作时间，你如何才能真正执行呢？
每个团队都是不同的：团队规模、经验水平、任期 / 专业知识等因素都会影响到谁负责什么工作的决定。
然而，在分配给团队的时间时，有一些事情是你应该考虑的，那就是个人之间的时间分配：
团队中每个人都应该有为客户提供价值的能力。
团队中的每个人都应该拥有产出的质量。这包括正确性、可靠性、性能、安全性等。
让中小企业继续专注于一个领域只会掩盖或延缓风险和成本：例如，如果团队中有人不在 / 生病 / 不能上岗，则会造成业务连续性的缺乏现象；当他们辞职时，可能会造成的知识转移成本等等。
有时候，你可能会为了让事情快速完成，而权衡将风险推迟，这不是不可以，但你应该确保团队或利益相关者能够意识到这一点，并就这个决定保持一致。

 

9，衡 量

如果你确实考虑采用本文提到的这个框架，我强烈建议你在开始之前考虑一下如何衡量自己的具体情况。比如，如果你使用的是像 Jira 这样的问题跟踪器，那么可以考虑添加一个字段或标签，以便使你能够将问题分配到四个方面中的一个。
在你的下一个周期或冲刺阶段之前，你应该能够快速报告你的预期分解是什么，在这个周期结束之后，你应该能够分析你的表现如何。这里经常被问到的一个问题是，是否要跟踪问题的总数，或者估算时间、工作量等等的总和？这实际上要取决于你团队的工作方式，以及你认为什么样的努力会带来更好的回报。不要追求一个完美的系统，只需选择一个你认为能够提供足够实用的东西即可，让你知道自己是如何跟踪的。
标记并跟踪你在每个方面的进展情况，这一做法对计划外工作特别有用，你可以以每周期一次更有规律的节奏进行观察，是否对周期产生了比预期更大或更小的影响。

 

10，持续改进
组织、团队或积压工作都会发生变化，因此你的计划和时间分配的方法也应该有所变化。使用持续改进的思维方式，让衡量或数据驱动的决策成为你工作方式的一部分，类似计划或冲刺回顾之类的惯例，将会帮助你更好地改进时间分配。

 

`