902
Как принцип FFF помогает управлять проектом в условиях неопределенности
Но то легенда. Если вы когда-нибудь имели дело с ремонтом или строительством, то понимаете, о чём речь. На старте имеем понятную задачу с очевидным результатом: положить новый паркет взамен старого скрипучего, заменить сливную арматуру в бачке унитаза или пробурить скважину на дачном участке.
Вот только в статье профильного сайта ничего не сказано о том, что делать, если под старым паркетом обнаруживается оргалит, который в свою очередь скрывает электропровода неясного назначения. В инструкции к сантехнической арматуре описаны 4 простых шага по установке, и ни слова о том, сколько трудов и времени потребует спиливание заржавевших соединительных болтов. А начиная бурить скважину, вы не знаете об огромном камне на глубине 4 метров аккуратно по вертикали бурения.
IT-проекты живут в той же парадигме: на пути к результату почти наверняка будут непредвиденные препятствия.
VUCA-мир и проектный треугольник
Последние годы много говорят о том, что мы живём в vuca-мире. Концепция vuca утверждает, что для мира вокруг характерна нестабильность (volatility), неопределённость (uncertainty), сложность (complexity) и неоднозначность (ambiguity).
Любой IT-проект существует в условиях этих самых VUCA. Только вместо ржавчины или камня ему готовы противостоять 100500 других непредвиденных обстоятельств.
Судите сами: исследование Deloitte показывает, что 60 % компаний сталкиваются с провалом проектов. 44 % проектов не реализуются в установленные сроки, не укладываются в бюджет или не соответствуют требованиям к качеству. 15 % проектов не соответствуют ни одному из указанных критериев либо вообще закрываются.
Соблазнительное заблуждение владельца проекта в том, что всё можно предусмотреть на старте. Планирование — всему голова, говорят мудрые. Мол, мы разложим проект на атомы, поймём, что нужно делать — и зафиксируем объём работ до последнего гвоздя. Договоримся, сколько времени понадобится на каждый гвоздь — и установим железный срок. Ну а там и стоимость посчитать не проблема — зацементируем и её.
Эту оптимистичную картинку будущего проекта можно показать в виде равностороннего треугольника. Стороны проектного треугольника отражают три составляющие проекта: деньги (budget), время (time) и объём работ (scope).
Равносторонним он остаётся ровно до момента появления условного «камня», то есть риска. В случае с разработкой цифрового продукта такими камнями может стать смена проджект-менеджера на любой стороне, особенности архитектуры систем, недостаток квалификации разработчика или дизайнера и даже потерянное сообщение в чате.
Что происходит, когда новый риск встаёт на пути проекта? Чтобы не допустить краха, приходится менять одну из сторон проектного треугольника:
✅ Budget. Вложить в проект дополнительные деньги.
Это, например, позволит экстренно привлечь к работе новых специалистов. И тогда есть шанс сдать продукт с задуманным функционалом к оговоренной дате.
✅ Time. Перенести срок запуска проекта.
Команда в исходном составе должна поднажать и за этот «овертайм» допилить продукт с запланированным изначально функционалом.
✅ Scope. Сократить объём работ.
Очевидно за счёт отказа от части функций продукта. В таком случае нет нужды наращивать ресурсы команды и сдвигать дедлайн, но в релиз уходит версия продукта с набором возможностей меньше, чем было запланировано.
Корректировка одного из параметров — это нормально, и не худшее, что может произойти. Бывает и так, что «ползут» все стороны треугольника. Изменения во всех трёх составляющих — крайне нежелательный сценарий, поскольку проект сильно теряет в прогнозируемости и управляемости. Это тот момент, когда проект нужно брать на короткий поводок.
Чтобы повысить степень определённости, а риски снизить, в проектном менеджменте принято фиксировать две любые составляющие проекта, а третью оставлять гибкой.
Принцип неподвижности двух составляющих проекта и подвижности третьей в проджект-менеджменте называют подходом FFF — fixed/fixed/flexible или fix/fix/flex.
Истории о бизнесе
Давайте на примерах из бизнеса посмотрим, как камни разного происхождения заставляют предпринимателей фиксировать и «флексить» стороны проектного треугольника.
История 1. Про неподвижные деньги aka Budget fixed.
Иван Петрович руководит компанией по производству и установке пластиковых окон. На одном ивенте коллеги по цеху подсказали: «Сейчас бизнес делают через приложения, а сайт твой устарел 10 лет назад».
«Наверно, не врут, — размышлял Иван Петрович, расхаживая по залу. — Дела в компании с каждым годом идут всё хуже, конкуренты наступают на пятки… Нужно меняться».
После бессонной ночи раздумий и трёх разговоров с Ольгой из бухгалтерии Иван Петрович решил обратиться в компанию, которая разрабатывает мобильные приложения. Фишкой должен был стать калькулятор расчёта стоимости изготовления и монтажа окон с учётом всех возможных размеров, цветовых решений и наборов фурнитуры. Включая нестандартные.
Где камень?
Через месяц работы выяснилось, что разработка калькулятора в приложении сложнее, чем казалось на старте. Внутренние информационные системы Ивана Петровича были совершенно не готовы к интеграции в ландшафт нового решения, ориентированного на клиентов. При этом бюджет у Ивана Петровича был серьёзно ограничен, и вводить в проект дополнительные средства не представлялось возможным. Budget fixed.
Что делать?
Выход 1: Можно было отложить дату релиза ещё на месяц, и за это время команда успела бы доработать информационные системы в компании Ивана Петровича, а также допилить калькулятор. Budget fixed, scope fixed, time flexible.
Выход 2: Иван Петрович мог выпустить приложение без калькулятора вовсе. Команда в первоначальном составе успела бы подготовить приложение к запланированному сроку. Budget опять же fixed, time fixed, scope flexible.
История 2. Про железные сроки aka Time fixed.
Компания — организатор праздников решила запустить специальный сервис — конструктор корпоратива. Инструмент должен был помочь заказчику выбрать концепцию праздника, площадь и оформление помещения, примерное меню — то есть смоделировать корпоратив в режиме онлайн и сориентироваться в стоимости. Продакт-оунер также предусмотрел в функционале конструктора возможность выбрать группу или диджея, который бы отвечал за музыкальное сопровождение праздника.
Запуск назначили на 1 декабря.
Сдвигать дату, разумеется, было уже некуда — горячий сезон, на кону 70 % годовой выручки компании. Time fixed.
Где камень?
По ходу в задумке обнаружилось слабое место: музыкантов под Новый год вечно не хватает. Выбранная группа часто оказывалась уже забронирована, а конструктор об этом не знал. Чтобы предлагать пользователю группы и диджеев, свободных на текущий момент, нужно было подключать дополнительную интеграцию базы данных с актуальной информацией.
Что делать?
Решение 1. Конструктор можно было запустить без фичи выбора музыкантов, ведь возможность конфигурировать все оставшиеся части по-прежнему ценны для клиента. Time fixed, budget fixed, scope flexible.
Решение 2. За дополнительные деньги компания могла договориться с подрядчиком и экстренно вывести в проект дополнительных специалистов по интеграции. Time fixed, scope fixed, budget flexible.
История 3. Про незаменимые фичи aka Scope fixed.
Лусинэ и Юра решили запустить сервис доставки подарков. Приложение позволяло собрать набор из цветов, игрушки, конфет, открытки и тут же заказать доставку адресату. Ключевыми фишками решили сделать доставку за час и возможность в режиме реального времени отслеживать движение курьера с подарками.
Ребята провели опрос, нужна ли пользователям фича отслеживания курьера. Большинство респондентов ответили, что это повышает доверие к сервису.
Где камень?
На тестах выяснилось, что карта передвижений не отображается в Android-версии приложения. Быстро найти и устранить причину не удалось — разработкой занимались начинающие специалисты, однокурсники Юры. Поскольку Лусинэ и Юра верили, что эта опция будет отличать их от конкурентов — решили не запускать приложение без неё. Scope Fixed.
Что делать?
Решение 1. Можно было привлечь ещё одного, более опытного разработчика и увеличить стоимость проекта, но уложиться в срок и запустить приложение с трекингом курьера. Scope Fixed, Time fixed, Budget Flexible.
Решение 2. Можно было продлить оговоренные сроки. Вероятно, разработчики смогли бы обнаружить баг и запустить полностью готовый сервис позднее. Scope Fixed, Budget fixed, Time Flexible.
Вернитесь к любой из историй выше и увидите, что любой проект легко раскладывается на три ингредиента — бюджет, сроки и скоуп работ. В каждой ситуации предприниматели фиксировали одну из сторон проектного треугольника как приоритетную. Из двух оставшихся можно было зафиксировать лишь одну. Третьей стороной же приходилось жертвовать — «флексить».
Всегда ли приоритетная сторона настолько очевидно приоритетна? Как вообще выбирать, что в проекте фиксировать, а что «флексить»?
Что флексить? Что фиксировать?
Общая практика проектной работы показывает, что если в проекте что-то пошло не по плану — лучше всего флексить скоуп, то есть уменьшать запланированный объём работ.
Не откладывайте срок запуска — это ваша возможность сразу же получить обратную связь от рынка. Не вкладывайте лишние деньги — они пригодятся. Проанализируйте продукт и найдите, от чего пока можно отказаться. Обычно при внимательном изучении выясняется, что продукт выполняет свою глобальную задачу даже без части функций. Нарастить их вы сможете в следующих версиях (итерациях).
Этот принцип сформулировал Джейсон Фрайд, основатель 37Signals (позднее Basecamp), в книжке-манифесте Getting Real . Вольный перевод — наш:
«Найдите то, что действительно важно для вашего продукта. Определите набор фич, без которых нет смысла запускать продукт. Они-то и должны уйти в первый релиз».
В Getting Real упакованы принципы разработки, дизайна, маркетинга, которые помогли 37Signals запустить 5 успешных веб-приложений и разработать фреймворк Ruby on Rails. Вся команда состояла из 7 человек, живущих в 7 разных часовых поясах. «Это не руководство и не инструкция, — предупреждают авторы. — Это книга идей». Рекомендуем прочитать — книжка легко читается и доступна бесплатно.
Чем раньше у вас будет MVP (Minimum Viable Product, минимально жизнеспособный продукт) — тем скорее вы проверите свою маркетинговую гипотезу или даже начнёте получать благодаря нему заявки и прибыль.
Давайте вернёмся к нашим предпринимателям и поможем им пересмотреть скоуп их проектов.
● Ивану Петровичу стоит запустить приложение с простой версией калькулятора для расчёта окон типовых размеров, стандартного белого цвета и с минимальным набором фурнитуры. Всё равно большая часть заказов будет именно на такие окна.
Для расчёта нестандартных вариантов можно пока предлагать консультацию специалиста и выезд замерщиков на объект — эти услуги и так есть. Инструмент будет работать и приносить деньги. А их можно вложить в доработку калькулятора.
● Королям вечеринок можно легко отказаться от опции выбора музыкантов. Продукт и без неё несёт пользу: разгружает отдел продаж и помогает потенциальным клиентам. А заказывать музыку можно пока и «в ручном режиме».
● Лусинэ и Юре не стоит зацикливаться на функции трекинга курьеров. Возможно, это хорошая гипотеза, которую ещё предстоит проверить. Но запустить сервис можно и без неё, и стартап начнёт получать заказы и зарабатывать деньги. Когда разработчики решат проблему с картой — добавят и её.
Закрепим основное
1. Независимо от сложности, любой проект имеет три основных компонента: деньги, время и объём работ.
2. Любой проект развивается в условиях нестабильности, неопределённости, сложности и неоднозначности, и всегда нужно быть готовым к тому, что работа пойдёт вразрез с изначальным планом.
3. Это не значит, что не нужно планировать. Конечно, нужно. Но следует быть готовым к изменениям по ходу проекта и следить за планом.
4. Крайне трудно с самого начала зафиксировать все три компонента проекта. Когда на пути проекта возникают препятствия, нужно корректировать («флексить») одну из его составляющих: деньги, время или объём работ.
5. Флексить лучше скоуп работ. Сфокусируйтесь на главной задаче продукта, а украшения оставьте для последующих версий. Минимально жизнеспособный продукт (MVP) даст возможность проверить гипотезу и даже начать получать прибыль.
