Как не слить бюджет, соблюсти сроки и объем работ: проектный треугольник при работе с подрядчиком
Приложение вышло точно в срок, все фичи на месте, да еще и сэкономили 20% бюджета. Идеально. Но любой стартапер знает, что так не бывает. Рассказываем, как проектный треугольник поможет не превратить релиз MVP в бардак.
Привет, меня зовут Светлана, я проджект-менеджер Purrweb — студии дизайна и разработки MVP для стартапов. Запуская приложение, продакты и руководители стартапов пытаются подружить три параметра: время, объем работ и стоимость. Это и есть проектный треугольник.
Когда в проекте участвует подрядчик, он может сохранить идеальный треугольник или исказить его до неузнаваемости. Как повезет =) Например, пообещает выкатить продукт за три копейки, но профакапит сроки. Чтобы предотвращать такие ситуации, нужно самому разбираться в проджект-менеджерской базе — так вы будете видеть косячного подрядчика насквозь и не потеряете контроль над проектом.
В этой статье я расскажу, как до старта проекта позаботиться о том, чтобы треугольник был сбалансирован, и как контролировать его, когда разработка уже идет полным ходом.
Как подстелить соломку и определить риски для треугольника до старта проекта
Залог сбалансированного треугольника — выбор подрядчика, который умеет «его готовить». Но бывают и такие, кто сольет бюджет или зафакапит сроки. Вычислить плохого подрядчика можно уже на первых встречах. По моему опыту, вот какие красные флаги показывают, что в проекте с вероятностью 99,99% что-то пойдет не так.
Скорее всего, изменится стоимость, если:
🚩 Подрядчик называет цену ниже рынка. Вряд ли у компании синдром самозванца: чаще это значит, что команда неопытная и, возможно, состоит из стажеров и джунов после онлайн-курсов. Возможно, за низкую цену ваше приложение поплатится качеством. Придется платить снова — уже другой команде.
🚩 С радостью берется за все задачи, не обсуждая бюджет. Соглашается на любые фичи и нововведения, не предупреждая, что на это может понадобиться больше денег или времени. Так бывает, если у подрядчика нет опыта работы с подобными проектами. В итоге в ходе проекта может потребоваться нехилая доплата.
🚩 Не обсуждает бюджет и не ищет способов его оптимизировать. Неопытный подрядчик потратит каждую копейку и не предложит вариантов, как сэкономить. Например, будет пилить механику для чата техподдержки с нуля, хотя есть менее затратные готовые решения.
Пострадают сроки, когда:
🚩 Отказывается от контрольных точек. Оправдывается, что не хочет тратить время на «ненужные встречи», но по факту избегает показа промежуточных результатов.
🚩 Не поясняет, почему команде нужно именно столько времени. Если исполнитель не может внятно расписать тайм-план для заказчика, ему и для своей команды разработки расписать его будет трудно, а это чревато задержками.
🚩 Не подсвечивает факторы, которые важны для соблюдения сроков. Например, не предупреждает, что нужно заложить время на подписание документов с сервисами или предоставление доступов.
Подрядчик не вывезет объем работ, если:
🚩 Юлит, когда делится кейсами. Говорит, что уже делал похожие продукты, но не делится деталями проектов. Возможно, исполнитель некомпетентен или в проектах всё шло не так уж гладко.
Самый красный флаг — когда подрядчик вообще не пользуется проектным треугольником и не знает, что такое матрица рисков. А знать это важно: ведь это только в идеальном проекте все стороны проектного треугольника равны и никогда не меняются. В реальной жизни так никогда не бывает.
В матрице рисков надо оценить, к какой стороне треугольника относится риск, насколько он вероятен и как повлияет на целевые показатели. И выбрать, где можно пойти на компромисс, а где нет. Например, если сроки являются главным приоритетом, — можно ли отказаться от части функций, чтобы успеть к дедлайну.
Кейс из практики
К нам в Purrweb обратились за сервисом для владельцев животных. С клиенткой установили срок в три месяца, а бюджет — в 30 000 $. При этом мы понимали, что если брать в работу все запросы заказчицы, количество работы сильно увеличится. Именно поэтому мы выписали все фичи, приоритизировали их, убрали то, что не влезает в бюджет и сроки, согласовали и только потом приступили к работе. Так мы выявили самую проблемную сторону треугольника — «Объем работ» — и избежали того, что у нас бы неминуемо увеличились сроки и бюджет проекта, если бы в работу взяли все фичи сразу.
Предугадать все риски на сто процентов, конечно, нельзя. Но вот о чем, по нашему опыту, забывают чаще всего.
Интеграция с сервисами. Стандартная практика: чтобы сэкономить бюджет, вы не разрабатываете собственные платежные системы, а добавляете в приложение уже готовые от банков. Но сторонние решения — это всегда риски. Например, в январе 2022 года мы прикрутили к MVP сервис авторизации auth0, а уже к весне он перестал работать в России: пришлось выкручиваться и писать код с нуля.
Юридические нюансы. Чтобы интегрировать платежную систему, нужно заключить с ней договор и перевести оплату. И тут могут возникнуть юридические сложности. Например, мы разрабатывали узбекское приложение — заказчик изначально хотел принимать в нем платежи российскими картами. Мы подсветили риски по срокам, и впоследствии они подтвердились: чтобы подписать договор с платежной системой, заказчику пришлось ехать в Россию и открывать там юрлицо.
Как контролировать стороны треугольника, если проект уже стартовал
При управлении проектом важно поймать момент, когда треугольник только начинает растягиваться. Для этого предусмотрите контрольные точки и обсудите их с подрядчиком. Расскажу, какие методы помогут присматривать за сторонами треугольника.
👉 Если важно не выйти за рамки бюджета. Попросите подрядчика вести все метрики проекта в таблице. Это поможет понять:
- за сколько часов планировали сделать фичу,
- сколько потратили по факту,
- на сколько процентов придерживаетесь календарного плана,
- на сколько процентов укладываетесь в бюджет.
Чтобы посчитать, попадаем ли в бюджет, мы используем метод освоенного объема (earned value management) — он объединяет теоретические и реальные данные по проекту. Основные параметры: утвержденный бюджет, фактическая и запланированная стоимость уже выполненных работ, выполнение плана, отклонение от расписания. Сопоставив все данные, видим, укладываемся ли в план и бюджет. И можем спрогнозировать, как будут расходоваться ресурсы дальше.
Метрики подрядчик должен вносить регулярно — например, по итогам спринта: в этом случае вы сможете сразу увидеть перерасход и принять меры. К примеру, пересмотреть приоритетность фич и отказаться от тех, что выходят за рамки реального бюджета.
👉 Если хотите часто корректировать фичи. Узнайте, какую методологию разработки использует подрядчик. По нашему опыту, удобнее всего поэтапно контролировать проект, если используются элементы гибкой методологии, например Scrum. В этом случае работа над проектом разделяется на короткие этапы (спринты) с четкими рамками — например, в две недели. Клиент может держать руку на пульсе и влиять на проект, так как есть много контрольных точек:
- Планирование спринта — команда выбирает приоритетные задачи на спринт, после выполнения которых будет готова определенная часть продукта. Подрядчик делает это самостоятельно, но всегда информирует клиента о том, что будет взято в разработку.
- Дейли — 15-минутная ежедневная встреча, где команда разработки обсуждает, что делала вчера и будет делать сегодня. Эта встреча проходит без клиента.
- Демо — презентация клиенту того, что сделано за спринт.
- Ретро — после спринта команда обсуждает, чего не хватило, какие были проблемы и что можно улучшить. Диалог строится в том числе на обратной связи от заказчика после демо, поэтому ему присутствовать на встрече не обязательно.
Каждый спринт несет в себе ценность. Даже если вы по каким-то причинам ушли от подрядчика или приостановили работу, часть проекта вы уже уносите с собой.
Мы в Purrweb миксуем несколько подходов сразу. В глобальном смысле мы используем каскадную модель, то есть делим всё на этапы: дизайн, техпроектирование, разработка, тестирование. Внутри этапов используем Scrum — разделяем процесс на спринты и каждые две недели демонстрируем заказчику часть продукта.
Также мы используем один из инструментов Канбан — доску, она помогает контролировать прогресс.
Коротко: что сделать, чтобы не развалить проектный треугольник
Чтобы удержать баланс в треугольнике, нужно правильно подготовиться к запуску, а после — регулярно контролировать прогресс.
До старта проекта:
- Не игнорируйте красные флаги на первых встречах с подрядчиком.
- Составьте матрицу рисков и определите самую проблемную сторону треугольника.
После старта проекта:
- Просите подрядчика вести все метрики проекта в таблице, чтобы держать руку на пульсе и при необходимости балансировать сторону треугольника, которая начинает расползаться. А посчитать, попадаете ли в бюджет, поможет метод освоенного объема.
- Работайте итерациями, постоянно отслеживая промежуточные результаты — например, с помощью Scrum. А с помощью контрольных точек вы сможете проверять, что уже сделано, и влиять на результат проекта.
Если хотите больше узнать о подходах стартапов к разработке и полезных фишках, которые помогают им в запуске проектов, подписывайтесь на наш телеграм-канал «Стартап-пикап». В нем мы делимся историями успеха, лайфхаками, факапами и трендами в мире стартапов.
А у вас были ситуации, когда проектный треугольник вышел из-под контроля? Поделитесь опытом, как с этим справлялись.
На фразе «Составьте матрицу рисков и определите самую проблемную сторону треугольника» вспомнила проект, где проблемными были все три стороны 🫠
проблемными были все три стороны - так это все проекты такие, просто некоторые не достаточно профессиональный чтобы их видеть, а некоторые слишком позитивны чтобы обращать на них внимание
Спросите лучше, были ли ситуации, когда проектный треугольник НЕ выходил из-под контроля. У вас такое было когда-нибудь? Я о таком ни от одной компании не слышал по крайней мере))
На самом деле в разработке MVP изменения всегда есть, но не всегда в отрицательную сторону. У нас бывали проекты, где получалось хорошо сэкономить без ущерба качеству.
Треугольник — это план, ориентир. Без него вся работа превратилась бы в неконтролируемое нечто. И тогда не было бы целевых показателей, с которыми можно сравнивать текущую ситуации и понимать:
– в нужном ли мы идем направлении;
– сколько еще до цели;
– по-прежнему ли важна эта цель.
Почему все не может быть как в идеальном мире 😭 Бюджет установлен, сроки не плывут, заказчики не требуют фигню)) Может как-то можно заранее создать такой треугольник, который не расползется или это нереально?
Минутка философии 🙂 Мир без изменений — это иллюзия. И тут важно поскорее принять тот факт, что изменения всегда будут. Поэтому идеальный треугольник в любом случае не получится сделать. Главное — вовремя реагировать на изменения, извлекать из них пользу для конечного продукта, а всё вредное отсекать.
Не совсем поняла, все эти метрики вы для себя ведете или прям заказчика за ручку по ним ведете и рассказываете, где что?