Рентабельность проекта часто теряется по разным причинам. Даже на простых проектах возникают ситуации, которые рушат расчеты и приводят к снижению окупаемости. А если проект сложный — это задача «со звездочкой».
Меня зовут Оксана Лозинская, я руководитель проектов в департаменте Логистика в «КОРУС Консалтинг». На примере именно такого проекта «со звездочкой» расскажу, как, несмотря на большое количество сложностей, мне удалось добиться рентабельности в 35%.
В материале:
Проект и его особенности
Почему рентабельность — это непросто
Что негативно влияет на рентабельность и как с этим работать
Как усилить управление рентабельностью — личные лайфхаки
Клиент, проект и задача
Однажды к нам обратилась логистическая компания и попросила провести аудит работы подрядчиков, которые занимались автоматизацией системы управления перевозками: маршруты, загрузка транспорта, статусы доставок. До этого все процессы были оформлены в Excel. Готовые решения на рынке были, но клиент мечтал о собственном — эдакой эксельке на стероидах.
Судьба у проекта была непростой: первая попытка провалилась, для второй привлекли сразу двух подрядчиков, которые работали параллельно. Особых успехов они не добились, поэтому клиент захотел получить независимую экспертизу и по рекомендации обратился в КОРУС.
Мы изучили проект, выявили основные сложности. В основном они касались нехватки аналитики у обоих подрядчиков, отсутствия ясности, чего именно хочет клиент (а тот, в свою очередь, был очень недоступным человеком). Ресурсы расходовались неэффективно, сроки, понятное дело, тоже съезжали.
После того как представили свой отчет заказчику, он сразу уволил одного из подрядчиков и предложил нам лидировать проект. Было неожиданно, но мы согласились.
С чем мы зашли в проект:
Получили неплохое по сравнению с предшественниками представление, что это за проект, какие сложности нас ожидают. Разумеется, предусмотрели не все.
Не стали сразу кидаться в разработку, сначала согласовали концепт продукта с заказчиком.
Взяли в проект одного из прежних подрядчиков — они на тот момент закрыли больший объем бэкенда, так что их участие было очень полезным.
Проект, включая разработку и опытную эксплуатацию, длился 10 месяцев с января по октябрь 2025 года. Мы разработали 8 блоков интерфейса, веб, мобильную версию и планшет, реализовали мультиязычность на английском и русском.
Завершили проект вовремя, без овертаймов, преодолели кучу сложностей и вышли с рентабельностью в 35%.
Теоретическое отступление про рентабельность
В среднем в проекты закладывают рентабельность в 20–30% процентов. Это считается нормой, а достижение таких цифр — хорошим результатом. Разумеется, завершить проект с прибылью намереваются все, но довольно часто фактическая рентабельность оказывается сильно ниже запланированной, и экономика проекта уходит в минус.
Случается это чаще всего потому, что проджект-менеджеры рассчитывают рентабельность всего два раза: в начале и в конце. В результате проекты, часто с виду успешные — клиентские задачи закрыты, даже в сроки уложились — оказываются убыточными для самой компании.
Что негативно влияет на рентабельность и как этим управлять
Есть факторы, которые способны сильно навредить рентабельности. О них и о том, как ими управлять, расскажу на примере нашего проекта.
Поверхностная оценка проекта на старте
Если сейлз продал проект за 5 копеек, исправить это практически невозможно. Только если заложить убытки в будущий контракт. Поэтому важно выделять время на оценку проекта на пресейле. Да, это затраты. Но если проект вы выиграете, время, потраченное на пресейл-аналитику, заложите в скоуп.
Нам повезло, наш аудит помог разобраться в специфике проекта и сформировать адекватный бюджет.
Недостаточно прозрачный бюджет
Это следующая ступень, на которой «спотыкается» рентабельность. Бюджет может быть сформирован на основании неточных задач. Например, в ТЗ есть требование — реализовать отправку уведомлений пользователям. С таким описанием у вас могут попросить реализацию email, push-уведомлений, СМС-уведомлений и сообщений в мессенджер, а бюджет вы рассчитали только на email. Отстоять свою позицию и вспоминать, о чем была речь и кто как понял задачу, бесполезно — придется столкнуться с затратами, которые вы в оценку не закладывали.
Поэтому важны прозрачные и четкие формулировки, на основании которых вы сами будете понимать, что именно вам предстоит сделать и какие ресурсы для этого потребуются.
В нашем случае мы до старта проекта раскидали всю разработку на спринты, прописали часы всех специалистов, добавили эти затраты в ТЗ, разъяснили все заказчику и согласовали бюджет. Так мы добились максимальной прозрачности.
На наших статус-встречах иногда могли появляться идеи дополнительных работ от клиента, тогда мы показывали заказчику, на что выделены ресурсы, и объясняли, что новые работы придется делать за счет согласованных, либо увеличивать бюджет.
Размытый скоуп
Ситуация, когда сам клиент не знает, чего хочет или просто не может это корректно сформулировать. В итоге результат разработки может сильно отличаться от клиентских ожиданий — придется что-то переделывать.
Чтобы такого не случилось, мы:
Не брали в работу «размытые» формулировки. Разбирались до тех пор, пока и нам, и клиенту не было понятно, что именно ожидается.
Например, заказчик попросил реализовать дополнительный функционал — добавить должности через UI. Изначально мы закладывали реализацию только через Базу данных. Начали задавать дополнительные вопросы. У кого должны быть права на добавление: у пользователей или администраторов? Какие обязательные поля должны быть, и нужна ли их валидация? Добавление должно быть доступно только через веб- или через мобильную/планшетную версию?
В результате у нас появлялись понятные, четкие требования к новой функциональности, на основании которых мы могли рассчитать будущую загрузку.
Фиксировали в ЧТЗ/Confluence детализированное описание задачи. Затем согласовывали его как минимум с руководителем проекта заказчика.
Некачественная коммуникация с заказчиком
Проблемы возникают, если этой коммуникации нет совсем или вы не знаете, чего на самом деле хочет клиент, не можете нормально выяснить требования и управлять ожиданиями — а это вообще основная задача менеджера. Ситуация усложняется, если определяет концепт и принимает финальные решения вечно недоступный собственник. Так было и у нас.
Чтобы облегчить себе жизни, мы:
Попросили выделить человека со стороны заказчика, который будет согласовывать вопросы, необходимые для продвижения по проекту.
Добивались внимания собственника: периодически собирались и ехали в Москву лично встретиться с заказчиком.
Проводили регулярные статусы с рабочей группой. Подробно и терпеливо объясняли, что успели сделать и что планируем, спрашивали, все ли их устраивает, не хотят ли они что-то поменять. Это помогало нам выравниваться по проекту, быть на одной волне и быстро управлять изменениями и ожиданиями.
Есть и другая крайность — чрезмерная коммуникация. С этим мы тоже столкнулись. Ответственное лицо со стороны клиента не имел опыта в ИТ, но очень всем интересовался: предлагал созвоны, просил разъяснения по каким-то вопросам.
Мы не стали ограничивать коммуникацию. В какой-то момент сели и объяснили ему, как все работает, ответили на базовые вопросы, вовлекали в обсуждения и принятие решений.
Это снизило количество «хаотичных» запросов и повысило качество взаимодействия.
Несбалансированная команда
Случается, что на проект собирают дорогую команду, где час аналитика стоит 10 000 тысяч рублей, а он в основном занят решением задач, с которыми бы справился джун. Или, наоборот — берут джунов, которые все делают медленно и с ошибками. Важен баланс.
В наш проект мы взяли ребят с разным опытом и квалификацией, вместе с тимлидом разделили команду на мини-группы по 2-3 человека. Каждая группа отвечала за полноценную реализацию фичи от и до. Далее тимлид распределял декомпозированные задачи на группу, исходя из опыта и уровня каждого. Внутри мини-групп коллеги уже могли «обмениваться» задачами, если кто-то хотел попробовать выполнить более сложные.
Такая конфигурация помогала успешно и быстро продвигаться в разработке, коллеги «подтягивали» друг друга, обмениваясь опытом.
Иногда случается, что кто-то не справляется с задачами — в этом случае важно не тянуть время, а разбираться с проблемой. За эти 10 месяцев мне приходилось увольнять людей с проекта по разным причинам: кому-то просто было неинтересно, а кому-то действительно не хватало экспертизы.
Что помогает решиться на изменения:
Переводить задержки в деньги. Когда вы увидите, что день просрочки стоит 200 тысяч рублей, решение о замене принимается быстрее.
Заранее высказывать специалисту ожидания от качества и темпов его работы, определять срок на исправление ошибок, снимать с проекта, если прогресса не произошло.
Еще важно помнить: команда заказчика — такая же часть команды, как и ваша, и ею нужно управлять. В противном случае клиент будет тормозить проект — не из-за сопротивления, а из-за непонимания.
Чтобы такого не произошло, мы:
Объясняли базовые принципы работы проекта: зачем нужны статусы, встречи, сроки, приоритизация.
Договаривались о правилах взаимодействия, фиксировали зоны ответственности.
Говорили на понятном бизнесу языке.
Благодаря этому команда заказчика лучше понимала происходящие процессы, эффективнее с нами взаимодействовала и выполняла свою часть работы.
Проблемная коммуникация в команде
От качества коммуникации зависит, насколько слаженно вы будете продвигаться по проекту. Внутренние коммуникации у нас были неплохими. Большая часть команды из КОРУСа, мы привыкли давать обратную связь, сигнализировать, если что-то идет не так. Помогала также практика регулярных ретро, на которых мы обсуждали проблемы и придумывали решения. Но у нас еще была команда, которую мы заменили, взяв проект на себя. И вот с этими людьми, которые были недовольны, нам и предстояло взаимодействовать.
Основные проблемы, с которыми столкнулись:
срывы сроков релизов;
игнорирование коммуникаций;
накал страстей между командами.
Чтобы выровняться, мы поговорили с тимлидом, объяснив ситуацию и её важность. Когда это не сработало, предупредили, что обратимся к подрядчику для регулирования. Это помогло — коллеги включились.
Далее мы еще раз распределили зоны ответственности, зафиксировали договоренности и сроки, а также старались поддерживать дружеский формат общения и заводили small-talk.
По сути, сработали разговоры с учетом мотивов и эмоций, плюс рычаги влияния. Приходится признать: иногда конструктивные беседы не помогают.
Отсутствие регулярного ведения экономики проекта
Тоже одна из самых «больных» точек — про бюджет забывают сразу после старта. Цифры едут, но за этим никто не следит.
Что мы делали:
Каждые две недели актуализировали план. Приходилось очень часто перемещать, менять местами спринты или блоки, актуализировать Jira на основании этих изменений. Да, работа затратная, кропотливая. Но это помогает понять, что происходит на самом спринте, в каком состоянии ваш итоговый бюджет.
Актуализируя фактические затраты, сравнивали их с планируемыми. Смотрели, где выбиваемся.
Проводили еженедельный статус с заказчиком, где также показывали расходование бюджета.
Давали возможность заказчику совместно «управлять» бюджетом. Если появлялись новые требования, предлагали заменить ими равнозначные задачи из текущего скоупа, объясняли подробно, что входит в стоимость и состав работ.
Все изменения по скоупу/бюджету фиксировали в отчете руководителя проекта.
Что особенно помогло сдать такой важный проект в срок, без овертайма и с рентабельностью в 35%
Дальше расскажу, что оказалось критически важным для нашего кейса.
Хорошая оценка и грамотно составленное ТЗ
Если экспертизы не хватает, просите помощи у более опытных коллег. Точности оценки на новом проекте сразу достичь сложно — это нормально. Ненормально, если вы примете это как данность и не станете ничего с этим делать.
Помогают ретроспективы, на которых команда разбирает задачи, которые сильно вышли за рамки предварительных оценок. Еще очень полезно просить оценить работы сотрудников, а не спускать цифры сверху. Так оценка становится точнее, а сами сотрудники включеннее.
Вдохновляющий факт — на старте проекта большинство наших оценок были «мимо», а к финалу разработчики научились на 90% определять затраты по проекту.
Включенная команда
Если бюджет начинает «ехать», важно не оставаться с этим один на один, а идти к команде. На нашем проекте со сложными ситуациями мы разбирались вместе и приходили к классным идеям оптимизации, до которых я одна бы не дошла.
Заказчику тоже нужно все доносить и говорить на языке стоимости работ, опираться на понятные метрики.
Простые регламенты
Я говорю не о многостраничных гайдах, которые никто не читает, а о документах на 3-4 страницы, включая титульник.
Например, вы проговорили с заказчиком порядок ввода решения в промышленную эксплуатацию, может зафиксировали что-то в протоколе встречи или отправили договоренности в почту. Но кто потом будет искать эти письма? И все ли вы в них учли? Когда придет время вывода в эксплуатацию, половина участников встречи забудет о договоренностях и взятых на себя обязательствах. А регламент помогает зафиксировать процесс, участников, зоны ответственности.
У нас были документы, которые мы готовили регулярно. Например, отчет руководителя проекта, который я делала каждый две недели и прописывала ключевые изменения, состояние бюджета, затраченные ресурсы.
Регламенты для команды мы создавали в Confluence. Большинство из них касались описания зон ответственности, порядка подготовки ТЗ, формата постановки задач.
Мы проводили встречи, на которых обсуждали все важные моменты для формирования таких гайдов. В течение двух недель смотрели, что работает, а что нет, и вносили корректировки при необходимости.
Ценность таких регламентов высокая:
Все придерживаются единообразия при постановке, выполнении, сдаче задач.
Если что-то забылось, всегда можно посмотреть в регламент, не нужно отвлекать коллег, что-то придумывать самому;
Команда подписывает согласие с регламентом, если человек от процесса по каким-то причинам отходит, его легко к нему вернуть.
Все документы мы создавали сообща, и это были «живые», рабочие гайды, а не спущенные сверху правила. Такой подход сильно повышал вовлеченность и ответственность.
Стремление научить работать заказчика
Уверена, что вы часто сталкиваетесь с тем, что клиент не хочет или не может по каким-то причинам выполнить свою часть работы, и вам приходится ее делать за него. Как следствие — вы тратите больше ресурсов и денег.
Хорошая новость — клиента действительно можно научить работать, если понять его мотивацию и сделать его соучастником процесса, а не контролером.
У нас на проекте среди согласующих лиц был мужчина, который никогда в жизни в разработке не участвовал. В какой-то момент у нас появилась задача — нужно было развернуть сервер на клиентской стороне. Задачу передали заказчику, заказчик сказал «ок». Мы ждем, сервер не разворачивают. Оказалось, что он просто не знал, как выстроить процесс: к кому идти, какие задачи поставить. Переспрашивать — стыдно. Тогда я объяснила все простым языком, что делать и куда идти, он быстро все организовал.
Разумеется, это частный случай. Но главное — разговаривать, разбираться в мотивации заказчиков, делать их полноценными участниками процесса. Понимание ценности и важности вклада реально мотивирует людей.
Вывод
Рентабельность — это не результат удачи, а следствие системного подхода. Чтобы ею управлять и держать в запланированных рамках, нужна регулярная работа — с бюджетом, скоупом, командой и заказчиком.
Когда проект сложный, а вводных много, результат особенно ценен. В нашем случае рентабельность в 35% стала следствием точной оценки, прозрачных договоренностей, регулярного контроля и умения вовремя включать нужные рычаги.
Вывод простой: не пускайте экономику на самотек, инвестируйте время в управление ресурсами, изменениями, коммуникациями — и тогда даже непростой проект удастся довести до отличного финансового результата.
