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

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

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

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

Вся суть проектного треугольника в одном меме

Как подстелить соломку и определить риски для треугольника до старта проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так может выглядеть шапка матрицы рисков в гугл-таблице

Кейс из практики

К нам в Purrweb обратились за сервисом для владельцев животных. С клиенткой установили срок в три месяца, а бюджет — в 30 000 $. При этом мы понимали, что если брать в работу все запросы заказчицы, количество работы сильно увеличится. Именно поэтому мы выписали все фичи, приоритизировали их, убрали то, что не влезает в бюджет и сроки, согласовали и только потом приступили к работе. Так мы выявили самую проблемную сторону треугольника — «Объем работ» — и избежали того, что у нас бы неминуемо увеличились сроки и бюджет проекта, если бы в работу взяли все фичи сразу.

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

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

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

Как контролировать стороны треугольника, если проект уже стартовал

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

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

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

Так выглядит наша таблица с метриками — в любой момент можно увидеть реальную картину происходящего и дать заказчику актуальную информацию

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

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

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

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

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

Мы в Purrweb миксуем несколько подходов сразу. В глобальном смысле мы используем каскадную модель, то есть делим всё на этапы: дизайн, техпроектирование, разработка, тестирование. Внутри этапов используем Scrum — разделяем процесс на спринты и каждые две недели демонстрируем заказчику часть продукта.  

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

Инсайты из мира разработки и экспертный взгляд на цифровые продукты в нашем Telegram-канале Стартап-пикап.

Подписаться

Коротко: что сделать, чтобы не развалить проектный  треугольник

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

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

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

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

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

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