Теория демо-версий: Как дедлайны делают разработчиков несчастными

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

• Сроки врут
• Сложности в оценке сроков
• Почему мы так часто ошибаемся с оценкой сроков. И иногда очень сильно
• Так и зачем тогда это все?
• Клиент подписал с вами контракт
• Отчеты перед инвестором
• Фиксированные сроки сдачи проекта
• Закон Брукса
• Решение для проблемы оценки сроков
• Натыкаясь на подводные камни

Это адаптированный перевод статьи Demos Over Deadlines, повествование ведется от лица автора — Эрика Эллиотта. Он сооснователь онлайн-школы программирования и опытный разработчик, который пишет на JavaScript. При этом он еще написал несколько книг и работал с BBC, Adobe, Wall Street Journal.

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

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

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

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

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

Сроки врут

Чаще всего сроки и дедлайны врут. В 2012 году CNN проанализировал топ-50 проектов на Kickstarter и обнаружил, что 85% из них запустились позже назначенного срока. Другое исследование под названием «Почему сроки срываются? Эмпирическое исследование причин задержки запуска программных продуктов» было опубликовано научным журналом IEEE. В нем исследователи обнаружили, что в среднем реальные сроки сдачи проекта отличаются от прогнозируемых на 36% (данные на основании изучения дедлайнов в 72 проектах).

Сложности в оценке сроков

Прежде, чем мы мы начнем, попробуйте ответить на вопрос — сколько пчел в обычном улье? Ответьте пожалуйста без использования гугла, и запишите свой ответ на бумажке.

Почему мы так часто ошибаемся с оценкой сроков. И иногда очень сильно

• Фичеризм, также известный как синдром кухонной раковины — когда в проект решают добавить незапланированные на старте продукты.
• Terra Incognita. Разработка программного обеспечения — всегда путешествие в неизвестное. Мы делаем то, что никто до нас не делал, и узнаем о новых API, новых протоколах, создаем новые компоненты с нуля, а иногда мимоходом решаем проблемы, которые никто до нас не решал. Процесс разработки — это кроличья нора, но почему-то это не мешает нам чересчур оптимистично оценивать сроки проекта.
• Не учитываем все задачи. Отладка, интеграция, написание тестов, написание новых тестов, сборка и пересборка. Все эти задачи требуют кучи времени, но мы не учитываем это при постановке дедлайна.
• Библиотеки. Когда возникает проблема с подключенной библиотекой (а она обязательно возникает), и тогда у команды остается два варианта — связаться с авторами библиотеки или с нуля разрабатывать альтернативу. То и другое занимает кучу времени.
• Жизнь. В жизни всякое бывает: больничные, отпуска, свадьбы, дети. Такое не запланируешь.

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

Чтобы что-то оценить, нам нужны данные о том, какие задачи требуется выполнить и сколько времени занимает каждая из них в отдельности. Но если мы создаем что-то новое, то у нас таких данных нет.

Читайте также: Чему мидлы и сеньоры могут научиться на Хекслете: девять направлений

Иногда работа ускоряется: например, когда мы выпускаем новую версию уже знакомого продукта. Но бывает и наоборот, проект задерживается — например из-за того, что мы вводим в проект нового разработчика и надо дать ему время на адаптацию.

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

Так и зачем тогда это все?

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

Клиент подписал с вами контракт

Клиент хочет заказать клон TikTok и спрашивает, сколько времени займет работа. Честный ответ тут один:

«Чтобы точно сказать, сколько времени займет работа, нам нужно узнать полный список функций, которые должны быть в приложении. И мы не узнаем точный список, пока не погрузимся в проект».

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

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

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

Отчеты перед инвестором

Одна из самых больших проблем в разработке программного обеспечения состоит в том, что люди делят шкуру неубитого медведя. В мире стартапов это нормально — просить деньги за несуществующий продукт. Чтобы убедить инвестора дать денег, стартап обещает использовать систему майлстоунов: компания достигает цели за n месяцев, а инвестор дает новый мешок денег. Потом новая цель и новый мешок.

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

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

Но бывают и такие инвесторы, которые настаивают на том, чтобы у проекта были фиксированные сроки. Я бы советовал просто избегать таких партнеров. Я придумал универсальную формулировку на тот случай, если инвестор спросит, почему вы не хотите ставить дедлайны:

«Мы предпочитаем показывать демо-версии продукта вместо того, чтобы строить работу вокруг дедлайнов. Так мы поступили с продуктом A и B, а недавно вот выпустили приложение C. Давайте я его вам покажу».

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

Фиксированные сроки сдачи проекта

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

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

Ранний анонс — очень опасная игра. В нее можно играть, только если

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

Если вы не успеете запустить продукт к анонсированной дате, то у PR-отдела будут крупные неприятности, и это не говоря уже о финансовых расходах. Так что в итоге да, компании с надежными партнерами и эффективным процессом производства могут позволить себе ранние анонсы. Но большинство IT-компаний не могут этим похвастаться и должны их избегать. Если вы устанавливаете дедлайн, убедитесь, что сможете поменять приоритеты на случай спешки. Занимайтесь задачами с низким приоритетом уже после запуска продукта.

Закон Брукса

«Добавление рабочей силы на поздних стадиях разработки продукта обычно затягивает его выпуск».

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

1. Новым разработчикам нужно время на то, чтобы включиться в проект. Это как минимум 2-3 месяца перед тем, как программист сможет стать полноценным членом команды. И помните о том, что все остальные разработчики будут работать над самим проектом меньше, ведь они будут отвлекаться на обучение новичка.
2. Новички делают много ошибок. А эти ошибки еще кому-то переделывать, что тоже занимает время.
3. С ростом количества сотрудников растут и затраты на коммуникацию. Чем больше разработчиков — тем больше каналов коммуникации: чатов, тредов, созвонов. А чем больше каналов, тем ниже прозрачность проекта и тем он становится сложнее. Да и в общем координировать работу большой команды довольно сложно.
4. Написание кода — это не самая сложная часть разработки. Самое сложное — декомпозировать процесс создания продукта на маленькие задачки. Если команда слишком большая, задач на всех будет просто не хватать, разработчики начнут делить одну и ту же задачу и мешаться друг другу.

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

Решение для проблемы оценки сроков

Помните, я просил вас примерно прикинуть количество пчел в улье? Я понимаю, что вы не располагаете фактами, чтобы сделать точную оценку. Да и что именно мы пытаемся посчитать?

• Мы считаем число пчел, которые участвуют в жизни колонии на протяжении всего времени существования конкретной колонии?
• Мы считаем количество пчел, которые живут в улье за год?
• Мы считаем среднее количество пчел, которые находятся в улье прямо сейчас?
• Меняется ли количество пчел в зависимости от географического положения улья и времени года?

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

Натыкаясь на подводные камни

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

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

Читайте также: Что такое холивар: 6 ярких примеров из мира технологий и разработки

В своей книге «Построение приложений» я пишу о том, что всё в программировании так или иначе связано с построением систем. Мы берем задачу и делим ее на части, как правило на независимые и удобные для работы — и это тоже является построением системы.

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

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

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

Посмотрите на график ниже, он показывает количество открытых issues в конкретный момент времени. Если бы скорость работы было так просто рассчитать, то число задач просто бы снижалось со временем. Но нет, график ниже напоминает график цен на акции: он ломаный, непредсказуемый.

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

Кстати, в обычном улье от 10 тыс. до 80 тыс. пчел.

• Если вы назвали число, которое меньше 10 тыс. — вы проиграли. Будем считать, что вы сорвали сроки. Game over
• Если вы назвали число больше 80 тыс., то управление сроками берет на себя ваш босс. Он считает, что вы себя недооцениваете, а потому объявляет анонс продукта на срок вдвое меньший, чем вы бы того хотели. А вы в ответ срываете новый срок сдачи. Вы снова проиграли
• Если ваш ответ тоже был диапазоном, но наименьшее число меньше 10 тыс. — вы тоже проиграли
• Если ваш ответ был конкретным числом и вы попали в диапазон, то сделайте следующее, чтобы вычислить свои баллы. Вычислите разницу между вашим числом и 45 тыс., а потом умножьте результат на -1. Вот ваши баллы, поздравляю! Вы как бы не проиграли, но и выигрышем это назвать сложно.
• Если вы назвали точное количество пчел в улье, используя диапазон, поздравляю с победой.

Ну и какое же решение я предлагаю для проблемы оценки сроков? Просто не оценивайте точно сроки.

Вот ключевые шаги для отказа от дедлайнов:

• Выпускайте демо-версии продукта
• Избегайте фичеризма
• Расставляйте приоритеты

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

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

Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях