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

by Valery
Loading...

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

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

«ФФФ» — принцип управления проектом, сформулированный в компании «37 сигналов». В оригинале — fix time, fix budget, flex scope

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

Принцип строится на главной мысли — дата запуска никогда не сдвигается. От времени зависит целесообразность всего проекта. Кажется безобидным — оттянуть срок на две недели, если команда что-то не успевает или клиент никуда не торопится. Но при добавлении времени проект заражается «фичеризмом».

Фичеризм  — бесконтрольное желание изменять проект или добавлять новые функции

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

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

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

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

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

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

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

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

Пофлексить — от анлийского «flex scope», принять решение о гибкости

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

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

Упростить — не значит сделать хуже

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

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

Репутация важнее скорости

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

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

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

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

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

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

Джейсон Фрайд, Давид Хейнемейер Ханссон, Мэттью Линдерман «Getting Real»

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

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

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

Решение о способе флекса принимается вместе с клиентом

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

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

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