Хочу разобрать ситуацию, в которой маржа начала уходить не из-за одного большого решения, а из-за накопления вполне нормальных рабочих действий. Речь про заказную разработку ПО. Часть решений типовые, часть кастомные. Рост не был случайным: усилили контент, стабилизировали входящий поток, улучшили конверсию воронки, подключили партнёрские каналы. За несколько месяцев количество проектов выросло на 25–30%. Команда изначально работала с загрузкой около 80% - оставляли буфер под внедрение, форс-мажоры и нормальную операционную устойчивость. После роста загрузка ушла в 90–95%. Формально это выглядело как эффективное использование ресурсов. Проектов стало больше, выручка росла, а прибыль почти не двигалась. Иногда даже проседала. Первое объяснение было очевидным: ошибки оценки или перерасход в разработке. Но цифры этого не подтверждали - по основному пулу отклонения держались в пределах 10–15%. Проблема оказалась глубже. Парадокс 1. Рост приходит не тем, чем ты хочешь Когда усиливаешь поток, ожидаешь рост крупных, понятных сделок. На практике первыми растут мелкие проекты. Они быстрее проходят воронку, проще продаются и создают ощущение, что рост пошёл. Но появляется управленческий тупик: отказаться - тормозить рост, брать как есть - менять экономику бизнеса. Парадокс 2. Мелкие проекты легче продать, но дороже обслуживать На уровне воронки они выглядят идеально: короткий цикл сделки, хорошая конверсия. Но если смотреть через unit-экономику, картина другая. Чтобы закрыть одинаковую выручку, мелкие проекты требуют в 1.5–2 раза больше времени продаж и пресейла. А после продажи начинается внедрение, где независимо от чека клиенту всё равно нужно объяснить, настроить, проверить и довести до результата. Эти действия почти не масштабируются вместе со стоимостью проекта. Парадокс 3. Проблема не появилась, она перестала скрываться Все эти доработки, дополнительные вопросы и “быстро доделать” были и раньше. Но при загрузке 70–80% система это переваривала. Когда буфер исчез, те же действия начали создавать очередь, сдвигать сроки и увеличивать фактическую себестоимость. Парадокс 4. Нельзя просто ждать только крупных клиентов Самый очевидный ответ - брать только крупные проекты. На практике рынок не даёт такой роскоши. План по выручке никуда не исчезает. Рост идёт через тот поток, который приходит. Что изменили Перестали считать “средний проект” и разложили поток по сегментам. Посчитали экономику каждого: продажа, разработка, внедрение, поддержка. Разница в маржинальности между сегментами доходила до 15–20 п.п. После этого поменяли правила: для мелких проектов ограничили итерации внедрения и кастомизацию, продажи перестали быть просто общим расходом, менеджеры начали жёстче квалифицировать клиентов внедрение выделили как отдельный этап с понятной экономикой, всё, что выходило за рамки, либо планировалось отдельно, либо продавалось отдельно Это сократило количество “бесконечных доведений”, ускорило запуск и снизило зависшие хвосты. Главный вывод оказался простым, проблема была не в росте и не в клиентах. Проблема была в том, что при росте мы продолжали одинаково работать с проектами с разной экономикой. Пока объём был меньше, это работало. С ростом, перестало.