Но то легенда. Если вы когда-нибудь имели дело с ремонтом или строительством, то понимаете, о чём речь. На старте имеем понятную задачу с очевидным результатом: положить новый паркет взамен старого скрипучего, заменить сливную арматуру в бачке унитаза или пробурить скважину на дачном участке.

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

IT-проекты живут в той же парадигме: на пути к результату почти наверняка будут непредвиденные препятствия.

Последние годы много говорят о том, что мы живём в vuca-мире. Концепция vuca утверждает, что для мира вокруг характерна нестабильность (volatility), неопределённость (uncertainty), сложность (complexity) и неоднозначность (ambiguity).

Соблазнительное заблуждение владельца проекта в том, что всё можно предусмотреть на старте. Планирование — всему голова, говорят мудрые. Мол, мы разложим проект на атомы, поймём, что нужно делать — и зафиксируем объём работ до последнего гвоздя. Договоримся, сколько времени понадобится на каждый гвоздь — и установим железный срок. Ну а там и стоимость посчитать не проблема — зацементируем и её.

Эту оптимистичную картинку будущего проекта можно показать в виде равностороннего треугольника. Стороны проектного треугольника отражают три составляющие проекта: деньги (budget), время (time) и объём работ (scope).

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

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

Что происходит, когда новый риск встаёт на пути проекта? Чтобы не допустить краха, приходится менять одну из сторон проектного треугольника:

• Budget. Вложить в проект дополнительные деньги.

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

• Time. Перенести срок запуска проекта.

Команда в исходном составе должна поднажать и за этот «овертайм» допилить продукт с запланированным изначально функционалом.

• Scope. Сократить объём работ.

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

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

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

Принцип неподвижности двух составляющих проекта и подвижности третьей в проджект-менеджменте называют подходом FFF — fixed/fixed/flexible или fix/fix/flex.

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

Иван Петрович руководит компанией по производству и установке пластиковых окон. На одном ивенте коллеги по цеху подсказали: «Сейчас бизнес делают через приложения, а сайт твой устарел 10 лет назад».

«Наверно, не врут, — размышлял Иван Петрович, расхаживая по залу. — Дела в компании с каждым годом идут всё хуже, конкуренты наступают на пятки… Нужно меняться».

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

Через месяц работы выяснилось, что разработка калькулятора в приложении сложнее, чем казалось на старте. Внутренние информационные системы Ивана Петровича были совершенно не готовы к интеграции в ландшафт нового решения, ориентированного на клиентов. При этом бюджет у Ивана Петровича был серьёзно ограничен, и вводить в проект дополнительные средства не представлялось возможным. Budget fixed.

Выход 1: Можно было отложить дату релиза ещё на месяц, и за это время команда успела бы доработать информационные системы в компании Ивана Петровича, а также допилить калькулятор. Budget fixed, scope fixed, time flexible.

Выход 2: Иван Петрович мог выпустить приложение без калькулятора вовсе. Команда в первоначальном составе успела бы подготовить приложение к запланированному сроку. Budget опять же fixed, time fixed, scope flexible.

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

Запуск назначили на 1 декабря. Сдвигать дату, разумеется, было уже некуда — горячий сезон, на кону 70 % годовой выручки компании. Time fixed.

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

Решение 1. Конструктор можно было запустить без фичи выбора музыкантов, ведь возможность конфигурировать все оставшиеся части по-прежнему ценны для клиента. Time fixed, budget fixed, scope flexible.

Решение 2. За дополнительные деньги компания могла договориться с подрядчиком и экстренно вывести в проект дополнительных специалистов по интеграции. Time fixed, scope fixed, budget flexible.

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

Ребята провели опрос, нужна ли пользователям фича отслеживания курьера. Большинство респондентов ответили, что это повышает доверие к сервису.

На тестах выяснилось, что карта передвижений не отображается в 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) даст возможность проверить гипотезу и даже начать получать прибыль.