How To Burn $6,540 a Week: Indecision and Software Development | Rob Walling

How To Burn $6,540 a Week: Indecision and Software Development

Как сжигать $6 540 в неделю: нерешительность и разработка софта

Indecision is a slow and painful death to both productivity and job satisfaction. A recent survey (pdf) found that three of the six main obstacles people face in performing their jobs are tied to decision making.

Нерешительность — это медленная и мучительная смерть и для продуктивности, и для удовлетворённости работой. Недавний опрос (pdf) показал, что три из шести главных препятствий, с которыми люди сталкиваются на работе, связаны с принятием решений.

The sad part is that indecision is a management strategy for some (quite a few, according to this study which states “90% of Australians work in a negative workplace culture of blame, indecision and conformity.” We can only assume the numbers are similar around the world.)

Грустно то, что для некоторых (и, судя по этому исследованию, для очень многих) нерешительность — это управленческая стратегия: «90% австралийцев работают в негативной корпоративной культуре обвинений, нерешительности и конформизма». Можно лишь предположить, что цифры по всему миру сопоставимы.

In software development there are two kinds of indecision: developer and non-developer. Non-developers can be managers, internal users, marketing, or your CEO; whoever has a say in how your software will be built. For the sake of this article we’re going to look at non-developer indecision, and we’re going to refer to it, for ease of readability, as “management indecision.”

В разработке софта есть два вида нерешительности: разработческая и неразработческая. К неразработчикам относятся менеджеры, внутренние пользователи, маркетинг или ваш CEO — все, кто имеет голос в том, как будет построен ваш софт. В рамках этой статьи мы рассмотрим именно нерешительность не-разработчиков и для краткости будем называть её «управленческой нерешительностью».

How Indecision Kills Productivity

Как нерешительность убивает продуктивность

What is the impact of management indecision on software development?

Каково влияние управленческой нерешительности на разработку софта?

One study examined the disruptions caused by technology and resource failures in the workplace. They grouped the disruptions into two types: simple disruptions, and what they call “agenda benders.” Agenda benders “create a period of uncertainty and indecision, during which any existing plans are suspended; replanning may become difficult if not impossible. [Agenda benders] can, at worst, cause the entire day’s agenda to be abandoned, and at the very least, will leave it seriously bent out of shape.”

Одно исследование рассматривало нарушения рабочего процесса, вызванные сбоями технологий и ресурсов. Все нарушения авторы разделили на два типа: простые сбои и так называемые «agenda benders» («ломатели планов»). Agenda benders «создают период неопределённости и нерешительности, в течение которого любые существующие планы приостанавливаются; перепланирование становится сложным, если вообще возможным. В худшем случае [agenda benders] могут привести к полному отказу от запланированного на день, а в лучшем — серьёзно его исказят».

The study goes on to say:

Далее в исследовании говорится:

“[When an agenda bender strikes] not only does she switch from doing high-priority tasks to filling in time with relative trivia, but she has no idea when her workstation will revive and must replan her day without adequate information. This uncertainty ultimately contributes to her inability to complete the ‘write specs’ plan. Agenda benders appear to arise through a loss or breakdown of essential resources, for a period of significant but unpredictable length. Sometimes the missing resource is a person, e.g., a colleague who cannot be found for a vital meeting.” Or, I would add, information that cannot be obtained in a timely manner.

«[Когда срабатывает agenda bender,] сотрудница не только переключается с высокоприоритетных задач на заполнение времени относительной мелочёвкой — она ещё и не имеет представления, когда её рабочая станция снова заработает, и вынуждена перестраивать день без достаточной информации. Эта неопределённость в конечном счёте мешает ей выполнить план “написать спеки”. Agenda benders, судя по всему, возникают из-за потери или поломки ключевых ресурсов на значительный, но непредсказуемый срок. Иногда отсутствующий ресурс — это человек, например коллега, которого не удаётся найти для важной встречи». Или, добавлю я, информация, которую не удаётся получить вовремя.

That being said, the impact of indecision is a potentially serious disruption to the development process due to a number of causes:

Тем не менее влияние нерешительности — это потенциально серьёзный сбой в процессе разработки, обусловленный рядом причин:

Склонность большинства людей замирать перед вопросом, на который у них нет всей нужной информации (описано в книге How Would You Move Mount Fuji?). Усилия, которые требуются, чтобы пометить пробел и вернуться к нему, когда решение наконец принято. Психологическое истощение от ощущения, что ты строишь хорошо спроектированное приложение, дырявое от того, что никто не закрывает пробелы решениями.

Why Developers Hate Indecision

Почему разработчики ненавидят нерешительность

If you’re a developer you know the frustration of not having the answers you need to keep working. You’ve probably experienced this more than you care to remember:

Если вы разработчик, вам знакомо раздражение от того, что у вас нет ответов, нужных для продолжения работы. Скорее всего, вы переживали это чаще, чем хотели бы помнить:

You start working on a new page, script, design, data model, etc… and realize the spec you’ve been given doesn’t have enough information for you to do your job. You walk over to your manager’s desk in search of an answer but he’s working on another issue and you have to wait.

Вы начинаете новую страницу, скрипт, дизайн, модель данных и т. д. — и понимаете, что в спеке, которую вам дали, не хватает информации, чтобы вы могли делать свою работу. Вы идёте к столу менеджера за ответом, но он занят другой задачей, и вам приходится ждать.

You trudge back to your cube, realizing your deadline is not budging, but unable to continue your work until you have an answer. Your stress begins to increase and you resort to one of two things: sending an email and sitting on your hands until you get an answer (but looking busy, of course), or making the call yourself and living with the consequences. Either way your productivity is hammered and you’re now feeling the stress of having one more loose end on your mind.

Вы плетётесь обратно в свой кубик, понимая, что дедлайн не сдвигается, но продолжать работу без ответа невозможно. Стресс нарастает, и вы прибегаете к одной из двух вещей: отправляете письмо и сидите, сложа руки, в ожидании ответа (делая вид, что заняты, разумеется), либо принимаете решение сами и живёте с последствиями. В любом случае ваша продуктивность катастрофически падает, и теперь у вас в голове ещё один незакрытый хвост.

“Surveys frequently rank managerial indecision as one of the top office torments, even above issues like low pay.” (source)

«Опросы регулярно ставят управленческую нерешительность в число главных офисных мучений — даже выше, чем низкая зарплата». (источник)

So why is it that no ones seems to make decisions?

Так почему же никто не принимает решений?

Most of the time your question is a lower priority than the other tasks on a manager’s plate. Other times it’s due to corporate politics; no one wants to be responsible for a bad decision on a UI that doesn’t work for the Accounting team simply because he made a hasty decision and didn’t ask the accounting team what they wanted.

Чаще всего ваш вопрос имеет более низкий приоритет, чем другие задачи в очереди у менеджера. В других случаях дело в корпоративной политике: никто не хочет нести ответственность за неудачное решение по UI, который не подойдёт бухгалтерии, только потому, что менеджер поторопился и не спросил их, чего они хотят.

I genuinely believe that the majority or managers, internal users and yes, even CEOs, are not intentionally trying to see how much stress you can take before your head implodes. For better or worse, this is just one of the realities of working in a corporate environment.

Я искренне верю, что большинство менеджеров, внутренних пользователей и да, даже CEO, не пытаются специально проверить, сколько стресса вы выдержите, прежде чем у вас взорвётся голова. К худу или к добру, это просто одна из реалий работы в корпоративной среде.

Why Managers Should Hate Indecision: The True Cost

Почему менеджерам стоит ненавидеть нерешительность: реальная цена

Summary so far: indecision is bad. It’s so bad, in fact, I maintain that most of the time a poor decision is better than no decision at all. This doesn’t hold true when launching nuclear missiles, performing heart surgery, or making software architecture decisions, but in most common software development scenarios it does. Let’s look at an example:

Краткое резюме: нерешительность — это плохо. Настолько плохо, что я утверждаю: в большинстве случаев плохое решение лучше, чем никакого. Это не работает, когда речь о запуске ядерных ракет, операциях на сердце или архитектурных решениях в софте, но в большинстве обычных сценариев разработки — работает. Рассмотрим пример:

Developer: “The spec doesn’t say if we should show all products on this page, or only enabled products. What should I do?”

Разработчик: «В спеке не сказано, должны ли мы показывать на этой странице все продукты или только включённые. Что делать?»

Manager: “Let’s call a meeting. We’ll get the four key people together, discuss it and come up with an answer. The soonest everyone can meet is next week.”

Менеджер: «Давай соберём встречу. Соберём четырёх ключевых людей, обсудим и придумаем ответ. Самое раннее, когда все смогут — на следующей неделе».

Developer: “But this is the core of the page. I need a decision to finish it.”

Разработчик: «Но это же ядро страницы. Мне нужно решение, чтобы её доделать».

Manager: “Well, then, put it on hold and move on to something else.”

Менеджер: «Ну, тогда отложи это и переключайся на что-то другое».

Now let’s examine the impact this has on the developer’s productivity and, ultimately, cost.

Теперь посмотрим, как это сказывается на продуктивности разработчика и, в конечном счёте, на издержках.

[Note: I know this next section will elicit a slew of comments like “Developers don’t make that much/little,” or “It would never take 2 hours to shift to another task.” In the end I decided that a practical example, even one that requires some subjectivity, is such a helpful part of this discussion that it’s worth including.]

[Замечание: я знаю, что следующий раздел вызовет волну комментариев вроде «Разработчики столько не получают/получают больше» или «Переключиться на другую задачу никогда не занимает 2 часа». В итоге я решил, что практический пример, пусть и с долей субъективности, настолько полезен для разговора, что его стоит привести.]

To begin, the average salary of a Mid-level software developer in Los Angeles is $88,750 (Robert Half’s 2006 Salary Guide). With burden and overhead of 65% (this includes your benefits, employer’s portion of your social security and unemployment, the lights over your head, your phone, computer, software licenses and parking space) it comes out to around $146k, or just over $70 per hour (based on 2080 hours per year). A company employing a software developer making $88,750 pays approximately $70 for each hour they work, are sick, or on paid vacation.

Итак, средняя зарплата мидл-разработчика в Лос-Анджелесе — $88 750 (Robert Half’s 2006 Salary Guide). С накладными расходами в 65% (сюда входят бенефиты, доля работодателя в социальном страховании и налоге по безработице, освещение над вашей головой, телефон, компьютер, лицензии на софт и место на парковке) выходит около $146 тыс., или чуть больше $70 в час (при 2080 часах в год). Компания, нанимающая разработчика на $88 750, платит примерно $70 за каждый час, который тот работает, болеет или находится в оплачиваемом отпуске.

In our example above, the first thing the developer has to do is participate in the meeting. Elapsed time: 1 hour (more if she has to prepare for the meeting). Cost: $70.

В нашем примере выше разработчику сначала придётся поучаствовать во встрече. Затраченное время: 1 час (больше, если нужно подготовиться). Стоимость: $70.

Next, she has to stop what she’s doing, add this to her to do list and come back to it in a week. Elapsed time: 2 hours to shift gears into another task then try to remember what she was doing when she comes back. Cost: $140.

Затем ей нужно прерваться, добавить задачу в список дел и вернуться к ней через неделю. Затраченное время: 2 часа на переключение в другую задачу и попытку вспомнить, где остановилась, когда возвращается обратно. Стоимость: $140.

After returning to the task after a week the developer is more likely to introduce additional bugs because of forgotten loose ends and a lack of familiarity with the code. Since “bug rates” per line of code varies widely this is difficult to measure. Let’s say that on an average day five bugs would show up in QA, but due to the disjointed nature of her development she introduces two additional bugs. The average cost to fix a bug based on this case study (careful, it’s a PDF) is $200. 2 x $200 = Cost: $400.

Возвращаясь к задаче через неделю, разработчик с большей вероятностью внесёт дополнительные баги — из-за забытых хвостов и потерянного знакомства с кодом. Поскольку «частота багов» на строку кода сильно варьируется, точно измерить это сложно. Допустим, в обычный день в QA вылезают 5 багов, а из-за разорванной разработки она добавляет ещё 2. Средняя стоимость исправления одного бага по этому кейс-стади (осторожно, PDF) — $200. 2 × $200 = Стоимость: $400.

Finally, she now has another item cluttering her task list, she’s frustrated she can’t complete her work, she’s lost respect for her manager because he won’t make a decision, frustrated with her company for having to gather four people to decide how a single screen works, and she’s concerned she’s not going to remember all the details when she has to come back to the page in a week. Due to stress her productivity degrades 10% for the next 2 days. 16 hours x .10 = 1.6 hours = Cost: $112.

Наконец, у неё в списке задач теперь висит ещё один пункт, она раздражена тем, что не может закончить работу, потеряла уважение к менеджеру, который не может принять решение, бесится на компанию за то, что приходится собирать четверых людей, чтобы решить, как работает один экран, и волнуется, что через неделю не вспомнит всех деталей. Из-за стресса её продуктивность снижается на 10% в течение следующих 2 дней. 16 часов × 0,10 = 1,6 часа = Стоимость: $112.

Total loss due to indecision: $70 + $140 + $400 + $112 = Total Cost: $822.

Итого потери из-за нерешительности: $70 + $140 + $400 + $112 = Общая стоимость: $822.

But wait, there are two other alternatives to this story.

Но погодите, есть ещё два альтернативных сценария.

One is that the manager makes a decision, and it’s the right one. In this case no additional time or money is wasted. Cost: $0.

Первый — менеджер принимает решение, и оно правильное. В этом случае не теряется ни время, ни деньги. Стоимость: $0.

The other alternative is that the manager makes the wrong decision. He sends an email to the parties involved indicating how they’ve decided to proceed, and finds out they screwed up. The developer has to go back and re-work the page after she’s completed it. Elapsed time: difficult to know, but assuming it’s a standard page we’re safe with an estimate of 6 hours. Cost: $420.

Второй — менеджер принимает неверное решение. Он рассылает участникам письмо с описанием выбранного подхода, и выясняется, что они напортачили. Разработчику приходится возвращаться и переделывать страницу уже после того, как она была закончена. Затраченное время: точно сказать трудно, но для типовой страницы можно смело прикинуть 6 часов. Стоимость: $420.

“Making a decision is a clear winner!” you think. But it gets worse.

«Принимать решения — явный победитель!» — подумаете вы. Но дальше будет хуже.

These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week. If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

Такие развилки возникают в ходе разработки постоянно. Допустим, у нас 5 разработчиков на проекте, и на всех набирается 10 таких ситуаций в неделю. Если бы обезьяна бросала монетку, она угадывала бы правильный ответ в половине случаев. Дадим менеджеру фору и допустим, что он угадывает в 60% случаев. В 6 случаях из 10 мы выходим в ноль, в остальных 4 теряем по $420 — итого $1 680 в неделю.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Если же мы вообще не принимаем решений, мы теряем 10 × $822 — всего $8 220 в неделю.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

Повторю ещё раз: тотальная нерешительность стоит $8 220 в неделю; принятие решений (включая плохие) — $1 680 в неделю. Разница составляет $6 540 в неделю.

One approach will cost you almost five times as much as the other. Give that a few minutes to sink in.

Один подход обойдётся вам почти в пять раз дороже другого. Дайте этой мысли пару минут, чтобы уложиться.

Trying to Fix Things

Пытаемся всё починить

Now that we’ve likened indecision to kicking puppies, terrorism and weapons of mass destruction, we’ve decided it’s bad for developers and for the company, and we’ve blamed everyone but the developer, what can someone do to move things along when the brakes are locked?

Теперь, когда мы уравняли нерешительность с пинанием щенков, терроризмом и оружием массового поражения, признали, что это плохо и для разработчиков, и для компании, и свалили вину на всех, кроме самого разработчика, — что же можно сделать, чтобы сдвинуть процесс с мёртвой точки?

Here are three alternatives:

Вот три варианта:

Облегчить кому-то принятие решения. «Подстеречь» лиц, принимающих решения. Форсировать решение.

Making it Easy

Облегчаем задачу

We can blame the managers all we want, but the bottom line is that leading a team is hard. As a former manager (who’s back in development by choice), the most common task I performed was making fast decisions with incomplete information. The not very surprising point is that the exact same situation that exhausts developers and kills productivity is the most difficult job of a manager, and the easiest to screw up.

Можно сколько угодно винить менеджеров, но в сухом остатке руководить командой — сложно. Как бывший менеджер (вернувшийся в разработку по собственному выбору), я могу сказать: самой частой задачей было принимать быстрые решения при неполной информации. Не очень удивительный вывод: ровно та же ситуация, которая выматывает разработчиков и убивает продуктивность, — это самая сложная и самая лёгкая для провала часть менеджерской работы.

The one thing I found most helpful when forced to make decisions without adequate information was to hear problems and solutions.

Что мне больше всего помогало, когда приходилось принимать решения без достаточной информации, — это слышать сразу и проблему, и решения.

Here’s what I never wanted to hear from one of my developers: “Oh my gosh, we didn’t think that people would want to view the results on the blah blah page and now we don’t know what to do. Aaaah! We’re all gonna die!”

Вот чего я никогда не хотел слышать от своих разработчиков: «О боже, мы не подумали, что людям захочется смотреть результаты на бла-бла-странице, и теперь не знаем, что делать. А-а-а! Мы все умрём!»

Here’s what I wanted to hear: “We didn’t think that people would want to view the results on the blah blah page. At this point we have two options: add the results grid, which is the right way to do it, and will take 2 days, or hack in a temporary table which will take 4 hours. Based on the schedule and where we are with out other tasks I think we should .”

А вот что я хотел слышать: «Мы не учли, что людям захочется смотреть результаты на бла-бла-странице. На данный момент у нас два варианта: добавить таблицу результатов — правильный путь, займёт 2 дня, — или захардкодить временную таблицу за 4 часа. Исходя из расписания и того, где мы по другим задачам, я думаю, что нам стоит сделать <правильный/быстрый вариант>».

What did the second developer just do? He gave me our best options. He turned this problem into a decision-making process, not a fact finding mission where I had to do recon to figure out the 10 possible approaches. Right away we could discuss pros and cons and make a decision quickly instead of wasting time back at the starting line. In this scenario I would likely suggest additional options, but starting with a base of 2 or 3 is a fabulous head start over the first developer, and makes me more likely to take the few minutes required to make the decision, rather than the 20 minutes needed for the first developer’s approach.

Что только что сделал второй разработчик? Он дал мне лучшие варианты. Он превратил проблему в процесс принятия решения, а не в разведмиссию, в которой мне самому пришлось бы выискивать 10 возможных подходов. Мы сразу можем обсудить плюсы и минусы и быстро принять решение, вместо того чтобы тратить время на старте. В такой ситуации я, скорее всего, предложу дополнительные варианты, но иметь базу из 2–3 — это фантастическое преимущество по сравнению с первым разработчиком, и это повышает шанс, что я потрачу пару минут на решение, а не 20 минут, которые потребовал бы подход первого.

“Ambushing” the Decision Makers

«Подстерегаем» лиц, принимающих решения

This one is simple; if you need three people to make a decision, find out if they’re going to be in the same place at the same time and drop by. Or, better yet, have one of them walk with you to find the other two. Creating an impromptu meeting will only work with people who have serious buy-in to see your work succeed, or who are close to you in the org chart.

Здесь всё просто: если для решения нужны три человека, узнайте, окажутся ли они в одном месте в одно время, и зайдите туда. А ещё лучше — пусть один из них пройдёт с вами и поможет найти двух других. Импровизированная встреча сработает только с людьми, реально заинтересованными в успехе вашей работы, или с теми, кто близок к вам в оргструктуре.

One other way is to try the ol’ “drop by one and call the other” trick (this works best when you only need two people’s agreement). There’s no rule that specifies you have to wait until everyone’s in a meeting to make a decision (although this is likely the culture if you work at a big company). There are significant limitations to this approach, however, such as a lack of thorough discussion, visual aids, or a white board. If the topic is complex you are likely to receive blank stares and a look that says “I’ll see you at our meeting next week.”

Ещё один способ — старый приём «зайти к одному и позвонить другому» (работает лучше всего, когда нужно согласие только двух человек). Никакого правила, что решения можно принимать только когда все собрались на встрече, не существует (хотя в крупных компаниях такая культура обычно сложилась). У этого подхода, однако, есть серьёзные ограничения: нет полноценной дискуссии, визуальных материалов, маркерной доски. Если тема сложная, в ответ вы, скорее всего, получите пустые взгляды и выражение лица «увидимся на встрече на следующей неделе».

Forcing a Decision

Форсируем решение

The third tool I’ve found useful is to force a decision. The phrase “We have to make a decision now or we’re going to lose x hours of time.” carries some weight with decision makers. Sure, they may put you off, but make a note that you said this and mention it again (as tactfully as possible) once the damage is done. Do this enough and someone may actually start listening to you.

Третий инструмент, который я нашёл полезным, — форсировать решение. Фраза «Нам нужно принять решение сейчас, иначе мы потеряем X часов» имеет некоторый вес для тех, кто решает. Да, они могут отмахнуться — но запишите, что вы это говорили, и тактично напомните об этом, когда ущерб уже нанесён. Сделайте так несколько раз, и кто-нибудь, возможно, реально начнёт вас слушать.

It’s possible no one will listen to you, even after repeated warnings. In this case you have one of two choices: escalate the problem to your manager, your manager’s manager, the CEO, or whoever you think can address it, or think long and hard about how much your company really wants its software projects to succeed. If nothing changes after your best efforts, then you have little choice but to keep fighting, accept it, or move on.

Не исключено, что вас никто не услышит даже после многократных предупреждений. В этом случае у вас два варианта: эскалировать проблему своему менеджеру, его менеджеру, CEO — кому угодно, кто, по вашему мнению, способен её решить, — или серьёзно задуматься о том, насколько ваша компания на самом деле хочет, чтобы её софтверные проекты были успешны. Если после всех ваших усилий ничего не меняется, у вас остаётся немного вариантов: продолжать бороться, смириться или уйти.

The other way to force a decision is to make the decision yourself and do the work. People are less likely to change something that’s already been written. This is a back-handed way of getting things done, but it both makes your point and accomplishes something during the time you’re waiting. As with the other approaches, use this one with caution or you may find yourself pissing off the wrong people.

Второй способ форсировать решение — принять решение самому и сделать работу. Люди реже меняют то, что уже написано. Это обходной способ продвигать дело, но он одновременно подчёркивает вашу точку зрения и позволяет хоть что-то сделать за время ожидания. Как и с другими подходами, используйте его с осторожностью, иначе можно обозлить не тех людей.

The Wrap Up

Подведём итог

Indecision hurts productivity, job satisfaction, and the bottom line, and eliminating it should be on everyone’s agenda. Managers will likely be motivated by cost and morale; developers by the desire to meet their deadlines and avoid frustration.

Нерешительность бьёт по продуктивности, удовлетворённости работой и прибыли, и борьба с ней должна стоять в повестке у всех. Менеджеров, скорее всего, замотивируют издержки и моральный климат, разработчиков — желание уложиться в сроки и избежать раздражения.

Either way, we’re in the same boat. Hopefully someone will decide to steer.

Так или иначе, мы в одной лодке. Будем надеяться, что кто-нибудь решит ею порулить.

Thanks to Mike Taber for reading a draft of this article.

Спасибо Mike Taber за то, что прочитал черновик этой статьи.