По данным Ассоциации РУССОФТ, совокупная чистая прибыль софтверных компаний в 2025 году сократилась. Для независимых разработчиков главным вызовом стала не динамика спроса, а экономика проектов. Расходы растут быстрее доходов, а инвесторы требуют понятной и быстрой отдачи. За счет чего можно развиваться в таких условиях?

На вопросы «БИТа» отвечают эксперты компаний

Дмитрий Лившин,
генеральный директор, САЙБЕР Бизнес Консалтинг

«Проект, который нельзя нарезать на несколько MVP с измеримым результатом на каждом шаге, я сегодня в работу не беру, поскольку в режиме жесткой экономии ими становится трудно управлять»

1. Раньше проект защищали красивой идеей и прогнозом выручки, сегодня этого мало. Первым делом я смотрю на юнит-экономику, то есть на экономику (затраты против отдачи) от одной транзакции или одного обслуженного клиента. Если экономика не сходится, то масштабирование будет множить убыток, и никакой рост спроса не спасет.

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

Третий — стратегическая необходимость. Есть проекты, которые должны быть сделаны, чтобы соблюсти требования регулятора или удержать ключевого клиента, и прямой прибыли там нет. Это честнее считать отдельно.

Четвертый критерий, чисто практический — возможность разбить большую перспективную идею на короткие подпроекты с проверяемыми гипотезами. Проект, который нельзя нарезать на несколько MVP с измеримым результатом на каждом шаге, я сегодня в работу не беру, поскольку в режиме жесткой экономии ими становится трудно управлять.

2. Показательный случай — клиентский портал для крупного вендора ИБ-продуктов. Проект изначально рождался в муках, запуск мы согласовывали восемь месяцев, три раза он мог закрыться под лозунгом «дорого и непонятно зачем». Спасли не эмоции, а тщательная декомпозиция. Мы разбили разработку портала на семь этапов, каждый должен был подтвердить свою продуктовую гипотезу. Для каждого отдельно просчитали юнит-экономику и инвестиции в MVP с горизонтом в год.

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

3. Самая «мутная» статья — общая инфраструктура, которую делят между собой несколько команд. Я называю такие статьи расходом черными ящиками. По виду это одна жирная строка расходов, например, общий кластер Kubernetes, платформа мониторинга, коммунальные базы данных или очереди и шины. А внутри у них живёт половина деятельности компании, и понять, какой проект сколько реально затратил без раздельного учета и хорошо выстроенной системы внутренних аллокаций почти невозможно.

Облачная нагрузка вообще коварна тем, что растет незаметно: тестовые среды забывают выключить, старые снимки и бэкапы копятся, зарезервированные мощности простаивают.

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

4. Реально результат обычно дают три инструмента. Первый — FinOps как рабочая культура, а не как трендовое слово. Смысл в том, чтобы сделать облачные и инфраструктурные расходы видимыми и привязать их к бизнес-метрикам по каждому из проектов. Даже базовая гигиена типа остановки простаивающих сред, чистки бэкапов, перехода на подходящие типы ресурсов — дает экономию порядка 15–20% почти с места.

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

Третий — продуманный переход на open source, особенно там, где раньше платили за импортное ПО и его поддержку. Но на это нужно смотреть честно: open source не бесплатен, вы меняете лицензионные платежи на затраты на компетенции, развертывание и сопровождение.

Для государственных и окологосударственных заказчиков, для которых зарубежные сервисы фактически закрыты, мы разворачиваем такие решения в их собственном контуре, на длинном горизонте выходит дешевле и предсказуемее.

Аутсорс тоже используем, но точечно, как способ не держать в штате редкие компетенции под разовые задачи. Заменять им ядро продуктовой команды я бы не советовал: управляемость теряется быстрее, чем ощущается экономия.

5. Главная ошибка — идти в разработку, не посчитав юнит-экономику, в надежде, что финансирование будет всегда. В прежние тучные годы это сходило с рук, но сегодня именно такие проекты первыми идут под нож.

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

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

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

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

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

Если всё сказанное суммировать, то выживает не тот, кто больше вложил, а тот, кто лучше заранее просчитал экономику и грамотно выстроил управление проектом.

Станислав Пятецкий,
директор по развитию ИТ-интегратора AWG

«Мы ушли от дорогих enterprise-коробок. Компания перешла на проверенный Open Source и собственные инструменты вместо закупки множества тяжелых готовых лицензионных решений. Они решают конкретные задачи без переплаты за лишний функционал»

1. Сейчас мы беремся за проект, только если он прошел четыре этапа оценки.

Первая — маржинальность. Мы установили планку в 30–35% и отказались от низкодоходных контрактов ради оборота. Каждый проект должен давать понятный вклад в EBITDA, иначе в нём просто нет смысла.

Вторая — загрузка команды. Мы не стартуем, пока у специалистов нет готовых задач. Держим этот показатель на уровне 75–80%. Если команда сидит и ждет, пока «что-то появится», экономика ИТ-интегратора быстро уходит в минус.

Третий этап — скорость проверки гипотезы. Заказчики и инвесторы устали от долгих обещаний. Поэтому мы оцениваем, способна ли команды выдать проверяемый бизнес-результат за 4–6 недель. Если предпроектная фаза затягивается без готового кода — финансирование замораживается.

Четвертый — AI-экономика. Еще до старта мы считаем, сколько рутины в аналитике и проектировании заберут на себя ИИ-агенты. Это помогает снизить себестоимость аналитики на 20–30%
и сразу зафиксировать целевую маржу.

2. Когда бюджеты на проекты урезали, фаза аналитики и проектирования при создании новых продуктов оказалась первой, которую хотели заморозить. Бизнес требовал быстрых PoC и понятной отдачи, а классический Discovery-процесс растягивался на месяцы и забирал значительную часть бюджета.

Мы отстояли этот этап и пересобрали его за счет полного пересмотра методологии Discovery под формат AI-Native. В основном качество любого IT-продукта и реальные сроки запуска зависят именно от этой зоны. Речь не о том, чтобы просто раздать аналитикам подписки на нейросети. Мы полностью перестроили сам процесс— от сбора требований и проектирования CJM до автоматической генерации спецификаций и системных гипотез с помощью мультиагентных ИИ-систем.

Аргумент, который убедил заказчиков и руководство: теперь проверяемый PoC теперь собирается за считанные недели вместо 2–3 месяцев. При этом себестоимость этапа падает на 20–30%, а основные архитектурные риски снимаются ещё на старте.

3. Больше всего средств нам сэкономила смена подхода к инфраструктуре и процессам.

Мы ушли от дорогих enterprise-коробок. Компания перешла на проверенный Open Source и собственные инструменты вместо закупки множества тяжелых готовых лицензионных решений. Они решают конкретные задачи без переплаты за лишний функционал.

К тому же, мы внедрили ИИ во все ключевые процессы, и в первую очередь в Discovery. Так мы смогли отказаться большого количества стороннего софта, который были вынуждены покупать раньше. Наконец, мы пересмотрели саму команду. Перестали держать «людей-функций» и бенч. Продукт и сервисы собираются под конкретного клиента по модели PTaaS (Product Teams as a Service) с жестким контролем загрузки команды выше 75–80%, чтобы не платить за простой.

Светлана Степаненко,
частная консалтинговая практика, ex-CFO

«Главная ошибка в экономике ИТ-проекта — масштабировать до того, как сошлась экономика одной единицы. Умножение отрицательного числа на объем дает только большее отрицательное число»

1. Как оцениваю целесообразность нового проекта. Три вопроса, и все три — до бюджета.

Первый вопрос: какой срок окупаемости и укладывается ли он в горизонт, на котором мы вообще что-то понимаем про рынок. Сегодня это два-три квартала. Расчет на три года — это не расчет, это литература.

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

Третий вопрос: обратимость. Сколько стоит остановить это через квартал. Если ответ «мы уже не сможем», проект дороже, чем в смете.

И жесткое требование к формулировке: кто конкретно, с именем и должностью, перестанет делать что-то руками или начнет продавать больше. Если названо «повышение эффективности» — эффекта не будет.

2. Как защитить проект от закрытия. Работает единственный аргумент: не «проект принесет», а «сколько стоит его не делать». Пока вы обещаете будущий выигрыш, вы конкурируете с чужими обещаниями. Как только вы показываете уже текущие потери, разговор меняется — эти деньги компания теряет прямо сейчас, при любом решении.

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

Третий: принести не выигрыш, а разброс — худший, базовый, и лучший сценарий. Руководство закрывает проекты не из-за плохих цифр, а из-за подозрения, что цифры нарисованы.

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

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

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

4. Что реально дало результат. Пересмотр портфеля. Самая скучная мера и самая действенная: новый проект входит только вместо другого, а не в дополнение. Пока портфель растет, любая экономия внутри проектов — косметика. Это первое.

Второе — переход к стоимости за единицу: сколько стоит одна сборка, один отчет, одно обращение. Общая сумма расходов ничего не объясняет, стоимость единицы объясняет все.

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

5. Ошибки, от которых предостерегу. Считать разработку без поддержки. Первый год после выпуска обычно сопоставим по стоимости с самой разработкой.

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

Экономить на измерении. Проект, который нельзя посчитать, невозможно защитить — его закроют первым.

И главное: масштабировать до того, как сошлась экономика одной единицы. Умножение отрицательного числа на объем дает только большее отрицательное число.

Дмитрий Исаков,
основатель и генеральный директор инвестиционной платформы Lender Invest

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

1. Мы видим цену денег каждый день: на площадке они стоят 23–25% годовых. Причем это не абстракция из макрообзора, а ставка, по которой заёмщик реально платит, а инвестор реально получает.

Отсюда первый критерий. Внутренний проект с доходностью ниже этой планки означает, что мы выдали заём сами себе по ставке хуже рыночной. Ключевые 14% тут ориентир слабый, мы фондируемся не по ним.

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

Третий критерий — что проект делает с оборотным капиталом. Отсрочка в 90 дней при нашей стоимости денег обходится примерно в 6% суммы проекта, и этой строки в смете обычно нет вовсе.

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

Дальше ошибка не остаётся внутри управленческого учёта. Часть внутреннего ФОТ уходит в капитализацию, ложится на баланс нематериальным активом и возвращается амортизацией на три-пять лет вперёд. Кривая разноска одного квартала искажает отчётность нескольких лет.

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

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

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

Простой пример с января ставка страховых взносов для аккредитованных ИТ-компаний выросла с 7,6%
до 15%. Команда из десяти разработчиков с фондом 300 тысяч на человека подорожала на 2,7 млн рублей в год, при том, что зарплаты в первом полугодии росли медленнее инфляции. Подписанные в 2025-м контракты стали убыточными сами, без единой правки скоупа.

И третья, на мой взгляд, часто недооцененная ошибка : отсутствие права остановиться. Условие выхода описывают, когда бюджет освоен на 80%, а описывать его надо до старта. Признать ошибку на 3 млн часто дешевле, чем на 30.

Евгений Осьминин,
директор по развитию и цифровой трансформации РДТЕХ, лидер аналитического проекта Монитор технологий

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

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

Жесткая привязка к ROI в условиях неопределённости ИТ-рынка может оценивать как нецелесообразные — сложные высокотехнологичные R&D-проекты, потому что их ценность проявляется не в виде сиюминутной прибыли, а в виде способности компании выживать и расти в новой реальности.

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

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

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

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

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

3. Самая непрозрачная статья ИТ-бюджета — это целый класс «затрат на преодоление неопределенности». По мнению ряда экспертов в 2026 году, в среднем, такие затраты могут составлять до 50% бюджета. Для снижения этой доли, необходимо вводить дополнительные механизмы контроля и ряд правил, которых придерживаться.

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

По мнению респондентов исследования «Монитор технологий», по итогам 2025 года, более 20% респондентов указали на снижение клиенториентированности со стороны отечественных вендоров в угоду государственной повестке и мнениям их ключевых инвесторов.

Отдельно стоит рассмотреть риски, связанные с использованием Open Source, как в момент разработки, так и эксплуатации продукта. Также плохо поддаются прогнозированию затраты, связанные с расходом облачного трафика и затраты на ИИ-агентов, которые могут вырасти экспоненциально уже на этапах тестирования и отладки отдельных компонент.

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

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

Технический специалист, который работает сейчас строго по ТЗ, полученного от бизнеса и который не аллоцирует, например, стоимость API-вызовов на возможности бюджета, практически гарантированно обеспечит неконкурентоспособную стоимость проекта.

4. Особенности новой реальности таковы, что сейчас неправильно говорить о некоем инструменте или «волшебной кнопке», которые сразу решат все проблемы и оптимизируют затраты.

Так, раньше все было понятно: внедрим FinOps — сэкономим на облаках, перейдем на Open Source — не будем платить за лицензии, оптимизируем портфель — облегчим бюджет, возьмем людей на аутсорс — сэкономим на кадрах и т.д.

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

5. Мир очень сильно изменился, и в некоторых направлениях проекты, в классических ранее экономических категориях, оценить сложно или даже невозможно. Поэтому наиболее частая ошибка новичков — мышление старыми категориями и подходами. Можно порекомендовать в этой связи — рассматривать не «затраты», а «инвестиции».

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

Также важно своевременно останавливать проекты, которые не приводят к утверждённым промежуточным результатам или отклоняются от заданных параметров.

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

Леонид Дегтярев,
директор по информационным технологиям ГК X-Com

«Главный совет — не бойтесь и не стесняйтесь использовать разные методы оценки сроков реализации задач. Любой исполнитель всегда склонен к недооценке возможных сроков и трудоёмкости»

1. Основные финансовые аспекты для нас — это баланс между полезностью любой выполненной доработки и затратами, совершёнными на её воспроизведение, и последующим экономическим эффектом.

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

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

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

2. Мы стараемся подходить к запуску каждого проекта осознанно. То есть, в согласовании с бизнесом: чтобы бизнес изначально либо был генератором этой идеи, либо плотно участвовал в её обсуждении на разных уровнях. В том числе по части экономической эффективности и тех эффектов, которые мы получим после реализации. Поэтому, прямо-таки спасать большие проекты, наверное, нам в последнее время не приходилось.

Но за свою практику, да, безусловно, я проходил случаи, когда были начинания, которые стартовали при одном менеджменте, а потом приходила другая команда и задавала вопрос: «А что это вы тут делаете?». Такое происходило не один раз и не два. И в таких случаях мы досконально «раскладывали» цифры, экономику, технические выкладки для того, чтобы бизнес понимал, в чем смысл проекта и в чем будет заключаться удобство его результатов для компании.

Многие наши проекты завязаны в том числе и на наших покупателей и клиентов, и нужно иной раз посмотреть на тот клиентский путь, который эти пользователи могут проходить. При этом, возможно, эта аудитория является не прямыми, а косвенными пользователями наших продуктов. То есть ряд вещей надо объяснять через наших сотрудников — почему выбрано то или иное решение. И безусловно, снимать обратную связь.

3. Статья расходов в бюджете ИТ-проекта, которая является наименее прозрачной и ею сложнее всего управлять — это, пожалуй, фонд оплаты труда. С одной стороны, при его расчете исходят из загрузки специалиста, но она не всегда репрезентативна, потому что дело не только всегда в затраченном времени, а в компетенциях. Бывает так, что есть постоянный сотрудник, который задействуется только раз или два в месяц, но без его уникальной компетенции не решить определенные задачи.

4. Я стараюсь держать баланс в вечном споре что лучше — оперсорс, аутсорс, инхаус, и так далее. Часть наших команд находится внутри компании, а часть — на аутсорсе. При этом все команды взаимодействуют между собой. Физически они практически не пересекаются, но при этом сотрудничают как коллеги, с оглядкой на эффективность друг друга. Таким образом, получается «корзина» из разных ресурсов, которые решают задачи, отвечают за те или иные части работы.

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

В общем, необходимо выстраивать баланс. Когда загрузка по проектам по разработке падает, внешние команды теряют внутренние объемы. Да, приходится сохранять в каком-то объеме ФОТ, но это позволяет проявлять оперативную манёвренность при высокой загрузке и закрывать потребности бизнеса в реализации задач. Конечно, при этом мы понимаем, что внешние ресурсы всегда дороже: там заложена прибыль того подрядчика, который сам является владельцем этих ресурсов, которые он нам, по сути, продаёт.

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

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

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

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