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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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