Управление

Как не срывать сроки и оправдывать ожидания

Валерия Прохорова — Арт-директор
Валерия Прохорова
Арт-директор

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

В Эдакс мы запускаем проекты вовремя, потому что следует принципу «ФФФ» — fix time, fix budget, flex scope. Рассмотрим подробнее.

Фиксированные сроки

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

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

  • Такие проекты могут не запуститься вообще.
  • Когда откладывается запуск проекта, мир не останавливается. Конкуренты выпускают новые продукты, сезон заканчивается, интерес потребителей меняется.
  • Незапущенный проект — потерянные деньги клиента. Эти две недели сайт мог бы работать и продавать.

Жертвовать сроками нельзя. К тому же, время — невосполнимый ресурс, который не купишь.

Фиксированный бюджет

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

В «ФФФ» решения по проекту принимаются исходя из того, что дополнительных денег, как и времени — нет. Бюджет фиксируется на определенную задачу и выход за его рамки невозможен.

Гибкая функциональность

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

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

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

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

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

Итерации короткие – пуски регулярные

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

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

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

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

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

Решение о флексе

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

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

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

Флекс легче понять и принять, чем кажется. В жизни мы часто принимаем решения «пофлексить»:

  • Семья запланировала сходить в любимый ресторан, но все столики оказались забронированы. Заказали еду на дом.
  • Компания решила осуществлять доставку товаров в другие города. Открыть офис и нанять курьеров возможности нет. Решили доставлять через партнерские пункт выдачи.
  • Свадебный ведущий заболел за день до торжества. На поиски нового времени не остаётся. Нашли готовый сценарий в интернете и попросили помощи у друзей и гостей.