Блог Нетологии

Советы и обзоры для новых высот в карьере, бизнесе и жизни


Как не сорвать дедлайн при работе над технологическим продуктом? Чтобы выяснить это, мы перевели отличную статью «How to Deliver More Software Projects On Time» американского предпринимателя и инвестора Марка Сустера. Он занимается разработкой 25 лет, поэтому знает, в чем секрет.

У программистов есть старая шутка: «Сколько времени нужно, чтобы разработать софт? Ответ: Столько, сколько вы заложили на разработку». Не очень смешно, зато правдиво.

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

Работа без ограничений всегда превращается в исследовательский проект.

Время-функции

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

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

Мы живем в эпоху продуктоориентированных компаний. Подход перфекциониста к дизайну и функциональности идет вразрез с потребностью бизнеса быстрее выпустить продукт.

Найти равновесие помогает подход Lean Startup Эрика Риза и книга «Стартап: Настольная книга основателя» Стива Бланка и Боба Дорфа. Суть в том, чтобы как можно раньше выпустить версию продукта, получить обратную связь от заказчика и затем продолжать разработку — до тех пор, пока у продукта не появятся все необходимые функции и тот вид, о котором вы договаривались с заказчиком.

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

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

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

При этом нужно быть осторожным и не создавать искусственные авралы слишком часто. Рано или поздно это приведет к снижению продуктивности. Команда разработчиков не может вечно работать на износ ради конкурентоспособности компании.

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

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

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

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

Чтобы запуститься вовремя, нужно заранее решить, чем можно и чем нельзя пожертвовать.

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

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

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

Говоря о соотношении «время — функции», нельзя забывать про наличие еще одного измерения — ресурсы. Это очевидный третий угол проблемы. Существует масса проектов, в которых дополнительные ресурсы поднимут объем проделанной работы без изменения времени. А есть проекты, где нехватка ресурсов вынуждает сокращать функции или тратить больше времени.

Время-ресурсы-функции

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

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

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

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

Об авторе

перевела Мария Терминасова,
контент-менеджер «Нетологии»

comments powered by Disqus

Видеокурсы по маркетингу и менеджменту

Присоединяйтесь к нам в соцсетях!

Сообщите о предложении или проблеме