Дедлайны могут подорвать работу даже самой сильной команды разработчиков. В работе по дедлайнам существует несколько альтернатив, одна из них — теория про демо-версии. Подробно рассказываем, что это такое и как внедрить эту практику в вашу разработку.
Это адаптированный перевод статьи Demos Over Deadlines, повествование ведется от лица автора — Эрика Эллиотта. Он сооснователь онлайн-школы программирования и опытный разработчик, который пишет на JavaScript. При этом он еще написал несколько книг и работал с BBC, Adobe, Wall Street Journal.
За свою карьеру я видел всякие команды — эффективные, и не очень. По моим наблюдениям, только один фактор позволяет предсказать успех команды разработчиков — как она работает под внешним давлением. Если на разработчика слишком сильно давить — он начнет страдать от выгорания, и даже может уволиться.
Как опытный руководитель, я стараюсь держать баланс между двумя конфликтующими целями. Первая цель — как можно быстрее выпустить продукт. Вторая цель — не перенапрягать команду сроками. Чтобы добиться обеих целей, я обычно расставляю команде приоритеты, после чего отхожу в сторону и просто не мешаю людям делать свою работу.
Но это еще не все. Когда команда добавляет новую фичу, она обязана показать ее демо-версию. Привязки к срокам нет: если показывать нечего, разработчики ничего и не показывают. Получается, что мы фокусируемся не на сроках, а на том, чтобы добавить фичу и показать ее. Если бы мы фокусировались на сроках — а они, признаем честно, обычно совершенно нереалистичные — то все страдали бы от лишнего стресса. Но когда перед командой стоит задача показать демо, разработчики ощущают не стресс, а азарт.
По крайней мере так показывает мой опыт работы. Я вижу, что с фокусом на демо-версиях фичи команда чаще испытывает гордость за проделанную работу, а еще радуется тому, что ее труд замечают и ценят. Еще бы — ведь у нас в компании остальные сотрудники аплодируют ребятам каждый раз, когда те показывают новую фичу.
Но чтобы по-настоящему оценить пользу такого подхода, нам нужно глубже взглянуть на явление дедлайнов и их ключевую проблему: невозможно точно оценить сроки работы над программным обеспечением.
Чаще всего сроки и дедлайны врут. В 2012 году CNN проанализировал топ-50 проектов на Kickstarter и обнаружил, что 85% из них запустились позже назначенного срока. Другое исследование под названием «Почему сроки срываются? Эмпирическое исследование причин задержки запуска программных продуктов» было опубликовано научным журналом IEEE. В нем исследователи обнаружили, что в среднем реальные сроки сдачи проекта отличаются от прогнозируемых на 36% (данные на основании изучения дедлайнов в 72 проектах).
Прежде, чем мы мы начнем, попробуйте ответить на вопрос — сколько пчел в обычном улье? Ответьте пожалуйста без использования гугла, и запишите свой ответ на бумажке.
Поэтому я говорю, что оценка сроков — это беззастенчивая ложь. Ведь мы пытаемся оценить новый программный продукт, то есть что-то совершенно новое, таящее в себе море нюансов и подводных камней.
Чтобы что-то оценить, нам нужны данные о том, какие задачи требуется выполнить и сколько времени занимает каждая из них в отдельности. Но если мы создаем что-то новое, то у нас таких данных нет.
Читайте также: Чему мидлы и сеньоры могут научиться на Хекслете: девять направлений
Иногда работа ускоряется: например, когда мы выпускаем новую версию уже знакомого продукта. Но бывает и наоборот, проект задерживается — например из-за того, что мы вводим в проект нового разработчика и надо дать ему время на адаптацию.
Переменных слишком много. Даже если каждый сотрудник будет сам высчитывать свое среднее время работы над каждой задачей, нам это не поможет.
Силы, которые заставляют нас ставить дедлайны, кажутся непреодолимыми. Клиент хочет знать, во сколько ему обойдется проект. Инвестор в свою очередь должен убедиться, что его деньги не пустят на ветер. И вам тоже очень важно угодить инвестору, иначе работать будет не на что. И вот, вам нужно что-то показать к началу следующего года. Но это реальный дедлайн или плод нашего воображения? Давайте рассмотрим конкретный пример.
Клиент хочет заказать клон TikTok и спрашивает, сколько времени займет работа. Честный ответ тут один:
«Чтобы точно сказать, сколько времени займет работа, нам нужно узнать полный список функций, которые должны быть в приложении. И мы не узнаем точный список, пока не погрузимся в проект».
Вместо того, чтобы соблазнять клиента нереалистичными сроками, покажите ему свое портфолио. Дайте почитать отзывы прошлых клиентов. А потом предложите такую сделку: за определенную сумму вы выделяете определенное количество ресурсов на работу над его проектом.
То есть не надо просить деньги за готовый продукт. Намного эффективнее просить оплату за время работы над проектом. А уже потом тщательно контролировать объем работы, чтобы не выйти за рамки бюджета. Для этого регулярно проводите встречи и обсуждайте приоритеты в работе над проектом. Показывайте демо-версию каждый раз, когда у приложения появилась новая функция.
Я люблю этот подход за то, что риск провала уменьшается для обеих сторон. Допустим, вы поработали месяц и понимаете, что недооценили сложность проекта — тогда обсудите это с клиентом. Определите, какие функции приложения действительно решают бизнес-задачи, а какие — нет. Откажитесь от всего лишнего.
Одна из самых больших проблем в разработке программного обеспечения состоит в том, что люди делят шкуру неубитого медведя. В мире стартапов это нормально — просить деньги за несуществующий продукт. Чтобы убедить инвестора дать денег, стартап обещает использовать систему майлстоунов: компания достигает цели за n месяцев, а инвестор дает новый мешок денег. Потом новая цель и новый мешок.
Я бы советовал отказаться от датированных майлстоунов. Амбициозные цели — это хорошо, но не привязывайте их выполнение к конкретным срокам. Никто из нас не умеет предсказывать будущее, наши ресурсы и приоритеты часто меняются. Когда вы планируете майлстоуны без конкретных дат, вы оставляете себе возможность проявлять гибкость, а гибкость — это хорошо и для разработчиков, и для бизнеса.
Хотя бы потому что весь проект не отменяют только потому, что вы неправильно оценили сроки. В стратегии, которую я предлагаю, от разработчиков требуется только хорошо работать и показывать результаты своей работы. Конечно, всегда есть риски: например, вы плохо расставили приоритеты и потратили все деньги. Однако в этом случае гнев инвестора хотя бы оправдан.
Но бывают и такие инвесторы, которые настаивают на том, чтобы у проекта были фиксированные сроки. Я бы советовал просто избегать таких партнеров. Я придумал универсальную формулировку на тот случай, если инвестор спросит, почему вы не хотите ставить дедлайны:
«Мы предпочитаем показывать демо-версии продукта вместо того, чтобы строить работу вокруг дедлайнов. Так мы поступили с продуктом A и B, а недавно вот выпустили приложение C. Давайте я его вам покажу».
Покажите демо-версию продукта и похвастайтесь тем, какую классную фичу вы добавили, вместо того, чтобы жаловаться, как вас достали нереалистичные сроки. Если вы избегаете фичеризма, то вероятно, что новые демо будут появляться каждые несколько недель. А это значит, что при каждой встрече с инвестором вы сможете показывать ему что-нибудь новенькое.
Компании часто анонсируют новые продукты задолго до их выпуска. Я придумал легкое, но не универсальное решение: просто не надо так делать. Не надо анонсировать продукты до того, как они будут готовы к запуску. Тогда у вас не будет аврала перед сдачей, и не придется срезать углы. Вообще, как правило, разработчики срезают углы только ради того, чтобы достичь воображаемого дедлайна. Но вред, который наносит такой подход, совсем не воображаемый, а вполне реальный.
Компании используют ранние анонсы для того, чтобы клиенты дождались их продукта, вместо того, чтобы купить аналог у конкурента уже сейчас.
Ранний анонс — очень опасная игра. В нее можно играть, только если
Если вы не успеете запустить продукт к анонсированной дате, то у PR-отдела будут крупные неприятности, и это не говоря уже о финансовых расходах. Так что в итоге да, компании с надежными партнерами и эффективным процессом производства могут позволить себе ранние анонсы. Но большинство IT-компаний не могут этим похвастаться и должны их избегать. Если вы устанавливаете дедлайн, убедитесь, что сможете поменять приоритеты на случай спешки. Занимайтесь задачами с низким приоритетом уже после запуска продукта.
«Добавление рабочей силы на поздних стадиях разработки продукта обычно затягивает его выпуск».
Возможно, вы слышали об этом законе раньше. Если углубиться в этот вопрос, мы узнаем еще кое-что:
Надо также помнить, что заключительные этапы проекта сжирают больше всего времени. Вот на этом графике из реального проекта заметно, какой прогресс мы делали в первые месяцы, и как замедлились в последующие:
Помните, я просил вас примерно прикинуть количество пчел в улье? Я понимаю, что вы не располагаете фактами, чтобы сделать точную оценку. Да и что именно мы пытаемся посчитать?
В вашем ответе был численный диапазон или конкретное число? Забавно, что разработчики называют конкретные числа при оценках, предпочитая конкретику точности, однако когда их просишь назвать сроки, их ответы очень размытые. Никто не согласится сделать фичу за один день или за две недели.
Большинство разработчиков смогут назвать какие-то сроки, если надавить на них. Однако все понимают, что эти сроки взяты с потолка. Кто знает, сколько времени займет один тикет? А сколько тикетов надо, чтобы закончить проект? А кто-то знает вообще реальный список всех задач, которые надо выполнить для запуска проекта?
Правда в том, что процесс оценки сложности — это часть разработки программного обеспечения. То есть вы сможете точно оценить сложность, только с головой нырнув в разработку. Делайте оценку постепенно, в процессе разработки проекта, но не перед его началом.
Читайте также: Что такое холивар: 6 ярких примеров из мира технологий и разработки
В своей книге «Построение приложений» я пишу о том, что всё в программировании так или иначе связано с построением систем. Мы берем задачу и делим ее на части, как правило на независимые и удобные для работы — и это тоже является построением системы.
Реализовать части системы и собрать их вместе — это не самое сложное. Самое сложное — это создать интерфейс, который будет обеспечивать хорошую связь этих частей внутри системы. Как это сделать? Надо продумать, на какие именно части разделить систему.
Это нешуточный объем работы, и его необходимо сделать в самом начале разработки. Только после этого мы можем оценить сложность проекта, и в конечном итоге обозначить какие-то сроки.
Даже если вы измерили среднюю скорость работы над задачей, нельзя предполагать, что вы будете выполнять новые задачи с одинаковой скоростью. За любой задачей может скрываться несколько подзадач, что автоматически делает наши расчеты неверными.
Посмотрите на график ниже, он показывает количество открытых issues в конкретный момент времени. Если бы скорость работы было так просто рассчитать, то число задач просто бы снижалось со временем. Но нет, график ниже напоминает график цен на акции: он ломаный, непредсказуемый.
В самом начале число issues большое, потом это число стабилизируется в определенном диапазоне. Он может меняться, если меняется сложность задачи или количество разработчиков в команде. Примерно с середины проекта количество задач непредсказуемо колеблется и только в самом конце существенно снижается.
Кстати, в обычном улье от 10 тыс. до 80 тыс. пчел.
Ну и какое же решение я предлагаю для проблемы оценки сроков? Просто не оценивайте точно сроки.
Вот ключевые шаги для отказа от дедлайнов:
Если вам надо поставить дедлайн, или у вас ограниченный бюджет, то не пытайтесь добавить все фичи. Вместо этого стройте приложение из независимых компонентов, чтобы ничего не сломалось, если вдруг вы откажетесь от реализации каких-то функций. Это очень важно — построить приложение так, чтобы можно было безболезненно сократить круг задач. Чтобы этого добиться, требуется очень хороший уровень коммуникации как внутри продуктовой команды, так и со стейкхолдерами.
Я призываю вас использовать демо-версии вместо дедлайнов, потому что от этого ваша команда будет счастливее и продуктивнее. Ирония в том, что отказавшись от дедлайна, вы больше никогда не будете срывать сроки.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях