Разработка по Фибоначчи: как эффективно запустить качественный ИТ-продукт, выдержать сроки и оптимизировать бюджет

О том, что такое модель «продуктовой разработки по Фибоначчи» и как она помогает решить актуальные проблемы при работе над проектами.

Все заказчики по-своему похожи – их объединяет желание как можно быстрее получить готовый IT-продукт с понятной для пользователей ценностью, максимально оптимизировав ресурсы на его создание и желательно с наименьшим бюджетом. Чтобы предоставить нашим партнерам такую возможность, мы в Skolopendra придумали и успешно применяем модель “продуктовой разработки по Фибоначчи”. В этом материале мы бы хотели поделиться конкретной инструкцией, как с помощью этой системы продуктовые команды могут воплотить в жизнь самые сложные проекты и удовлетворить запросы самых требовательных заказчиков.

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

Как показывает общемировая практика, жизненный цикл современного IT-продукта составляет в среднем всего лишь три года. За это время необходимо не только быстро занять долю рынка, укрепить свои позиции и вернуть инвестиции, но и начать готовиться к новому технологическому рывку, потому что, как известно, за любым ростом идет спад, а значит, нужно успеть обновиться и остаться востребованным для пользователя. Именно поэтому уже на старте важно сделать так, чтобы в основе продукта лежала гибкая основа, позволяющая быстро проверять бизнес-гипотезы и в случае необходимости менять направление развития. Это важно еще и потому, что традиционно из всего бюджета лишь 10% идет непосредственно на разработку. Остальное уходит на дальнейшее сопровождение и развитие как непосредственно продукта, так и обеспечивающей его экосистемы. Поэтому чем больше доработок и ошибок выявляется на более поздних этапах, тем больше ресурсов (финансовых и временных) уйдет на их корректировку и доработку.

Аналогично это применяется у нас. Например, для первого года создания и развития ИТ-продукта “с нуля” мы применяем следующее: 1 месяц (BrainStorm) + 1 месяц (RoadMap) + 2 месяца (Alfa/MVP) + 3 месяца (Beta/Pilot) + 5 месяцев (Market Release).

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

Первый этап работы посвящен обсуждению стратегических вопросов по продукту или его существенно дорабатываемой функциональной части. Совместно с заказчиком мы проводим комплексное исследование, анализируя роли всех будущих пользователей. При этом проводится внутренний и максимально жесткий challenge идеи. Важно получить точный ответ на вопросы “почему такого продукта/функционала на рынке до сих пор нет?” и/или “как его сделать максимально конкурентным, полезным и безопасным?”. Потому что если ответ будет неудовлетворительным, есть риски попасть в удручающую статистику.

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

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

• общая пользовательская и техническая нагрузка на продуктовую экосистему и отдельные ее функциональные части (месяц/день/секунда/пиковая);
• требуемая инфраструктура, ее доступность и отказоустойчивость (собственный ЦОД, облако или гибрид);сбор, обработка и хранение персональных данных (152 ФЗ, GDPR или иные прямые локальные территориальные требования, а также требования и ограничения, связанные с предоставлением сервисов для граждан таких стран);
• юридические особенности ведения и лицензирования некоторых видов деятельности в России и иных странах присутствия, в том числе к наличию операционных депозитов; регуляторные требования (состав данных, сроки их хранения, уровни доступов к ним, регулярные выгрузки по требованию и т.д.);
• информационная и физическая безопасность, напрямую влияющая на репутацию и финансы (защита от проникновений злоумышленников, сохранность и целостность данных и охрана здоровья пользователей).

Основная задача на этом этапе: понять, насколько создаваемый ИТ-продукт реализуем в том виде, в котором его задумал заказчик, и с той ресурсной базой, которая есть в наличии и/или может быть привлечена извне на более поздних этапах.

В нашей практике были случаи, когда первоначальная идея перерабатывалась на 70-80% или вообще не бралась в работу. Это мы рассматриваем тоже как положительный результат – мы помогаем нашим заказчикам существенно экономить ресурсы и возвращаться с переосмысленной идеей или новым проектом.

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

• WEB-фронт (ЛК) для пользователей, а также административная панель;

  мобильное приложение (иногда несколько для разных ролей) или чат-боты;

• ядро системы (Back-End CORE);

• интеграции с внешними сервисами и/или внутренними системами заказчика (источники и потребители информации);
• включение во внешние экосистемы (например, голосовые помощники и умные дома) и т.д.

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

На втором этапе прорабатываются тактические вопросы реализации IT-продукта.

У этого этапа есть несколько направлений работ, которые ложатся в основу будущего продукта:

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

• проводится R&D – техническое исследование и базовые проверки реализуемости и трудоемкости выбранных векторов разработки;
• настраивается серверная инфраструктура и запускаются необходимые сервисы;
• внедряется инструментарий для создания продукта (средства ведения разработки, накопления экспертизы, сохранение истории создания).

Но основная задача – проработка UI/UX. То есть создается максимально полная визуализация будущего ИТ-продукта. В современном мире UI/UX является фактической заменой детальных и быстро устаревающих ТЗ, поскольку решает сразу три важных задачи – наглядно демонстрирует внешний вид и функциональность для заказчика до старта ресурсоемкой разработки, позволяет более правильно разбить проект на этапы вывода (не разрушая целостности каждого этапа) и является пошаговой инструкцией для продуктовой команды.

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

Результатом этапа является RoadMap (план работ) с финализированными бизнес-требованиями и итоговым BackLog-ом (списком задач) с плановой трудоемкостью и согласованными приоритетами. На основе этой информации мы утверждаем необходимый состав продуктовой команды и оценочный бюджет на реализацию и переходим к разработке.

Основная цель этого двухмесячного этапа – подготовка гибкой платформы будущего продукта. В нее входит:

• настройка стендовой инфраструктуры и элементов деплоя для осуществления разработки;

• реализация управляющего ядра системы и создание основного пользовательского функционала продукта в версии Alpha (MVP).

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

На этом этапе мы работаем по классике Agile и со спринтами (каждая итерация длится от 7 до 14 дней). Объединенная продуктовая команда проводит ежедневные внутренние встречи на 15-30 минут, на которых обсуждает результаты и распределяет новые задачи из утвержденного BackLog в соответствии с их приоритетом. В процессе также выявляются потенциальные и реальные риски, собирается пул вопросов к проработке, в том числе к заказчику, с которым проводятся конф-коллы три раза в неделю для синхронизации. Через каждые 2-4 спринта проводится демонстрация текущих результатов разработки для управления ожиданиями заказчика. По итогу отчетного периода клиенту передаются код, накопленная экспертиза и иные проектные артефакты в соответствии с поставленными задачами.

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

Результатом этапа является гибкий Alpha-прототип будущего продукта. На следующем шаге он передается на внутреннее тестирование заказчику и ограниченному ряду пользователей (часто участникам продуктовой команды). Очень важно как можно быстрее получить живой опыт работы с продуктом, чтобы подтвердить или скорректировать созданный ранее BackLog перед выходом на рынок с реальными пользователями.

На этом этапе создание продукта распараллеливается. Пока основная команда работает над Beta-версией (задачи второго приоритета, монетизация и элементы онбординга), в течении 2-4 недель продолжается сбор замечаний и предложений от пользователей Alpha-версии. По факту обработки полученной обратной связи производится корректировка состава или изменение приоритетов задач в BackLog’е разработки.

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

Результатом этапа также является полноценная стендовая инфраструктура, разделенная на три части. Первая, DEV, отвечает за разработку продукта и первичное тестирование. Вторая, PrePROD, используется для проверки подготовленных обновлений и предварительного пользовательского тестирования. А третья, PROD, используется для боевой версии продукта. Далее проводится настройка эксплуатационных и обеспечивающих служб и систем, мониторинг основных процессов и вопросов инфобезопасности. Продукт готов к полноценному выходу в рынок.

Наша практика показывает, что подобная авторская методология “разработки продуктов по Фибоначчи” (1+1+2+3) в части последовательности, продолжительности и состава активностей гарантирует оптимальное соотношение параметров прозрачность/результат/ресурсоемкость. Благодаря этому оптимизируется бюджет проекта, существенно облегчается работа продуктовой команды и управление ожиданиями заказчика. А это является необходимым базисом для успешного создания и продвижения IT-решения на рынке.