Тайминг проекта и соблюдение дедлайнов

Денис Гордиенко, директор Bright Mobile о том, как уложиться в дедлайн, если всё пропало.

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

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

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

Срыв дедлайнов на рынке разработки сайтов и мобильных приложений это, к сожалению, стабильность.

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

На самом деле от этого никто не застрахован. К примеру, в штате 10 программистов, один заболел — выработка на 10% снижается. А если какая-то эпидемия и 4 разработчика разом заболели — это 60% выработка по проектам.

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

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

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

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

Про последний пункт материал далее.

В свое время на канале “Темная сторона” Аркадий Морейнис написал, что план работ на 6 месяцев можно выполнить за 6 недель. Это не значит что программист будет работать 24 часа в сутки, это значит что мы упрощаем требования за счет исключения не принципиального функционала.

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

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

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

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

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

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

Видел несколько примеров подобного применения. Сделали проект “коротким” способом, запустили его на рынок, накачали трафиком и не стали делать то, что задумали в начале.

Можно любой функционал так или иначе упростить. Вопрос на сколько упростить? Насколько, на сколько ужат срок реализации проекта.

Приведённые примеры выглядят, как «сделать по-хуже» лишь бы соблюсти дедлайн. Упрощение так и воспринимается. Именно поэтому, очень часто принимается решение, либо о переносе дедлайна, либо об увеличении бюджета.