Разбираемся с дедлайнами: больше никаких критических ситуаций

Перевод статьи Итамара Тернера-Трауринга «No more crunch time: the better way to meet your deadlines».

Важно балансировать междусроками выполнения работ и качеством

Успевать к дедлайнам, плывя в неспокойных водах, довольно сложно. С одной стороны, вы рискуете разбиться о скалы поздней доставки, а с другой – рискуете утонуть в водовороте технического долга и поломок софта.

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

Когда вам дают слишком много работы и недостаточно времени, вам нужно сказать своему начальнику «нет» и обсудить более подходящий набор условий. Но на что конкретно вам нужно упирать при этом?

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

Эта дилемма является ложной дихотомией. Качество это понятие относительное, зависящее от ситуации и функционала. Стандартные ответы тут не помогут.

Настоящее решение это поставить высокий приоритет работе, которая действительно важна в вашей конкретной ситуации, и игнорировать все остальное, отложив его на «после дедлайна». А это означает, что нужно отказывать – вашему начальству, вашим клиентам и самому себе.

Нет, весь код не может быть совершенным (но вот эта его часть должна быть нерушимой, как скала).

Нет, этот функционал не важен для достижения поставленных целей.

Нет, мы не можем «просто добавить одну деталь». Но если это действительно важно, то мы это сделаем.

Давайте рассмотрим два примера: задача будет одинаковой, но цели и реализации — различными.

Дедлайн №1: подними доходы или лишишься работы

Сроки имеют значение для целей бизнеса

Однажды я работал в стартапе, в котором возникла напряженка с деньгами: наш существовавший на тот момент бизнес не работал. К счастью, основатели выдвинули план спасения. Мы должны был опереться на новую, трендовую сферу – Docker только набирал обороты, – где мы могли бы создать что-то, что никто в то время еще не мог.

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

Как построить сложное, замысловатое ПО в сжатые сроки?

Нужно начать с определения целей.

Начните с целей

Нашей целью было продемонстрировать ключевой функционал, который был только у нашего софта. Мы решили сделать это, проводя пользователей по туториалу, где будет показываться, что мы предлагаем. Если пользователь будет впечатлен, значит, мы достигли успеха. Мы недвусмысленно сообщали пользователям, что наше ПО еще не может использоваться в реальности.

Базируясь на этой цели, мы сделали всю массу спецификаций:

  1. Продакшен-система должна была поддерживать параллельные операции, но у нашего туториала будет только один пользователь. Поэтому мы реализовали распределенную систему с CLI, в котором была связь по SSH с другим CLI.
  2. Продакшен система нуждалась в обработке ошибок, но наш туториал мог запускаться в контролируемой среде. Мы создали Vagrant конфиг, который запускал две виртуальные машины, и не забивали себе голову написанием кода по обработке ошибок для потерянных соединений, недоступных машин и т. д.
  3. Продакшен-система должна была быть обновляемой и поддерживаемой, но наш туториал должен был запускаться единожды. Так что мы не проводили большую часть модульных тестов, а вместо этого сфокусировались на ручном запуске туториала.

Вы можете сказать, что мы выбрали второй возможный вариант – наплевать на качество. Но ни одна из вещей, которые мы упустили, не имела отношения к нашим целям в тот период. Потратить время на «лучшие подходы», которые не имели отношения к нашей отдельно взятой ситуации, означало потратить это время впустую.

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

Расставляйте приоритеты относительно функционала в соответствии с целями

Даже при том, что мы все упростили, в конечном итоге, чтобы успеть к дедлайну, нам пришлось убрать кое-какие фичи. Как мы решили, что пропустить?

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

Отказ от какого-то функционала был достаточно приемлемым: идея была достаточно хороша, туториал был достаточно убедителен, а наш вице-президент по маркетингу был достаточно опытным, чтобы мы смогли собрать $12 миллионов финансирования, основываясь на этом немасштабируемом, неподдерживаемом куске ПО. А после первоначального релиза и его продвижения у нас было время реализовать оставшиеся функции.

Дедлайн №2: программа, готовая к выпуску в производство

Когда важнее качество

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

Но даже в этих условиях мы позаботились о расстановке приоритетов, основываясь на нашей цели. А целью теперь было получить пользователей для нашего продукта. Наш первоначальный прототип имел механизм хранения и передачи peer-to-peer и преобразовать его для продакшен-версии было нелегкой задачей. Поэтому мы сосредоточились на облачном хранилище, что было более простым решением.

И по мере приближения дедлайна мы отбрасывали менее важные функции. Мы определенно не сделали это идеально, например, одна из таких отброшенных нами функций была уже наполовину реализована. Было бы лучше вообще не браться за нее, поскольку она была не очень важна. Но в итоге мы достигли успеха: наш код был поддерживаемым, люди начали им пользоваться, а нам не пришлось делать доставку в последний момент.

Отсутствие универсальных решений

Нет никаких универсальных решений, которые работали бы везде. Нет легких ответов. Все, что вы можете сделать, это спросить «Почему?». Почему мы это делаем и почему это важно?

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

  1. Отбрасывайте функции, которые не служат вашим целям. Начинайте с самого важного функционала, на случай, если у вас не хватит времени сделать все намеченное.
  2. Пишите высококачественный код там, где это важно, и отказывайтесь от качества, где оно не имеет значения.
  3. Если у вас при всем этом все равно слишком много работы, время обсудить с вашим боссом или клиентом, чем они готовы поступиться.


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх