Как не слить бюджет, соблюсти сроки и объем работ: проектный треугольник при работе с подрядчиком

Приложение вышло точно в срок, все фичи на месте, да еще и сэкономили 20% бюджета. Идеально. Но любой стартапер знает, что так не бывает. Рассказываем, как проектный треугольник поможет не превратить релиз MVP в бардак.

Привет, меня зовут Светлана, я проджект-менеджер Purrweb — студии дизайна и разработки MVP для стартапов. Запуская приложение, продакты и руководители стартапов пытаются подружить три параметра: время, объем работ и стоимость. Это и есть проектный треугольник.

Когда в проекте участвует подрядчик, он может сохранить идеальный треугольник или исказить его до неузнаваемости. Как повезет =) Например, пообещает выкатить продукт за три копейки, но профакапит сроки. Чтобы предотвращать такие ситуации, нужно самому разбираться в проджект-менеджерской базе — так вы будете видеть косячного подрядчика насквозь и не потеряете контроль над проектом.

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

Залог сбалансированного треугольника — выбор подрядчика, который умеет «его готовить». Но бывают и такие, кто сольет бюджет или зафакапит сроки. Вычислить плохого подрядчика можно уже на первых встречах. По моему опыту, вот какие красные флаги показывают, что в проекте с вероятностью 99,99% что-то пойдет не так.

Скорее всего, изменится стоимость, если:

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

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

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

Пострадают сроки, когда:

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

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

🚩 Не подсвечивает факторы, которые важны для соблюдения сроков. Например, не предупреждает, что нужно заложить время на подписание документов с сервисами или предоставление доступов.

Подрядчик не вывезет объем работ, если:

🚩 Юлит, когда делится кейсами. Говорит, что уже делал похожие продукты, но не делится деталями проектов. Возможно, исполнитель некомпетентен или в проектах всё шло не так уж гладко.

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

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

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

Интеграция с сервисами. Стандартная практика: чтобы сэкономить бюджет, вы не разрабатываете собственные платежные системы, а добавляете в приложение уже готовые от банков. Но сторонние решения — это всегда риски. Например, в январе 2022 года мы прикрутили к MVP сервис авторизации auth0, а уже к весне он перестал работать в России: пришлось выкручиваться и писать код с нуля.

Юридические нюансы. Чтобы интегрировать платежную систему, нужно заключить с ней договор и перевести оплату. И тут могут возникнуть юридические сложности. Например, мы разрабатывали узбекское приложение — заказчик изначально хотел принимать в нем платежи российскими картами. Мы подсветили риски по срокам, и впоследствии они подтвердились: чтобы подписать договор с платежной системой, заказчику пришлось ехать в Россию и открывать там юрлицо.

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

👉 Если важно не выйти за рамки бюджета. Попросите подрядчика вести все метрики проекта в таблице. Это поможет понять:

• за сколько часов планировали сделать фичу,
• сколько потратили по факту,
• на сколько процентов придерживаетесь календарного плана,
• на сколько процентов укладываетесь в бюджет.

Чтобы посчитать, попадаем ли в бюджет, мы используем метод освоенного объема (earned value management) — он объединяет теоретические и реальные данные по проекту. Основные параметры: утвержденный бюджет, фактическая и запланированная стоимость уже выполненных работ, выполнение плана, отклонение от расписания. Сопоставив все данные, видим, укладываемся ли в план и бюджет. И можем спрогнозировать, как будут расходоваться ресурсы дальше.

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

👉 Если хотите часто корректировать фичи. Узнайте, какую методологию разработки использует подрядчик. По нашему опыту, удобнее всего поэтапно контролировать проект, если используются элементы гибкой методологии, например Scrum. В этом случае работа над проектом разделяется на короткие этапы (спринты) с четкими рамками — например, в две недели. Клиент может держать руку на пульсе и влиять на проект, так как есть много контрольных точек:

1. Планирование спринта — команда выбирает приоритетные задачи на спринт, после выполнения которых будет готова определенная часть продукта. Подрядчик делает это самостоятельно, но всегда информирует клиента о том, что будет взято в разработку.
2. Дейли — 15-минутная ежедневная встреча, где команда разработки обсуждает, что делала вчера и будет делать сегодня. Эта встреча проходит без клиента.
3. Демо — презентация клиенту того, что сделано за спринт.
4. Ретро — после спринта команда обсуждает, чего не хватило, какие были проблемы и что можно улучшить. Диалог строится в том числе на обратной связи от заказчика после демо, поэтому ему присутствовать на встрече не обязательно.

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

Чтобы удержать баланс в треугольнике, нужно правильно подготовиться к запуску, а после — регулярно контролировать прогресс.

До старта проекта:

• Не игнорируйте красные флаги на первых встречах с подрядчиком.
• Составьте матрицу рисков и определите самую проблемную сторону треугольника.

После старта проекта:

• Просите подрядчика вести все метрики проекта в таблице, чтобы держать руку на пульсе и при необходимости балансировать сторону треугольника, которая начинает расползаться. А посчитать, попадаете ли в бюджет, поможет метод освоенного объема.
• Работайте итерациями, постоянно отслеживая промежуточные результаты — например, с помощью Scrum. А с помощью контрольных точек вы сможете проверять, что уже сделано, и влиять на результат проекта.

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

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