Суть в двух словах
Крупные софтверные компании регулярно создают внутренние инструменты, которые доказывают свою ценность, но затем забрасывают их при смене приоритетов. Роберт Браунстейн предлагает концепцию «франчайзинга независимых проектов»: позволить инженерам, работавшим над проверенным внутренним продуктом, выделить его в автономное предприятие, где материнская компания выступает в роли первого клиента и лицензионного партнера. Данные PwC показывают, что 42% генеральных директоров опасаются недостаточной скорости трансформации; компания Deloitte предупреждает, что гибкие ИИ-конкуренты снижают порог затрат на разработку ПО.
Инновации обычно погибают не из-за неудачи эксперимента. Они умирают тогда, когда исчезает ответственный за них владелец. Крупные софтверные компании могут создать вспомогательный инструмент, доказать его эффективность в решении реальной проблемы и все равно лишить его внимания, как только руководство переключает команду на флагманский продукт или следующую срочную задачу. Мой тезис прост: когда полезный внутренний проект больше не вписывается в корпоративную дорожную карту, компаниям стоит рассмотреть возможность предоставить ему независимость, прежде чем просто забросить его.
Тайминг имеет решающее значение. Согласно опросу главных исполнительных директоров PwC за 2026 год, 42% руководителей заявили, что их больше всего беспокоит вопрос, достаточно ли быстро они трансформируются, чтобы поспевать за технологическими изменениями, в то время как 29% усомнились в достаточности своего инновационного потенциала. Тем не менее, в сопутствующем исследовании PwC отмечается: хотя половина CEO считают инновации основой своей стратегии, лишь 8% существенно внедрили хотя бы 5 из 6 практик, связанных с их поддержкой. Индустрии не занимать амбиций. Ей не хватает надежных механизмов, позволяющих доводить перспективные разработки до конца в условиях смены приоритетов.
Инженерам ПО эта схема хорошо знакома. Компания решает, что ей необходима определенная функциональность, назначает людей на ее создание и формирует вокруг работы рабочий импульс. Месяцы спустя проект объявляется «достаточно готовым». Инженеры переходят на другие задачи, но отчеты об ошибках, проблемы безопасности, требования к интеграции и запросы на новые функции никуда не деваются. Эту повторяющуюся цикличность я называю «хаосом инициатив» (initiative thrash): команды нарабатывают контекст и убежденность в ценности продукта, а затем теряют и то, и другое с появлением новой директивы.
Убытки не ограничиваются исходным бюджетом на разработку. По моему опыту, инженеры продолжают нести ответственность за риски кода, на улучшение которого им больше не выделяют времени. Когда они уходят, их институциональные знания уходят вместе с ними. Следующей команде приходится заново восстанавливать старые решения, обходить стороной запущенную архитектуру или переписывать то, что она не может уверенно поддерживать. Таким образом, формально завершенный проект может превратиться в перманентную организационную проблему.
Эта проблема становится все более острой по мере изменения экономики разработки ПО. В обзоре глобальной индустрии программного обеспечения Deloitte за 2026 год отмечается, что создание софта становится быстрее и дешевле, в то время как бережливые ИИ-ориентированные конкуренты оказывают давление на устоявшиеся компании. Однако ускорение производства не порождает долгосрочную ответственность. Оно может лишь помочь организациям штамповать больше проектов, которые впоследствии будут конкурировать за ресурсы на их поддержку.
Я предлагаю промежуточный путь между тем, чтобы держать все внутри компании, и полным закрытием проектов: франчайзинг независимых проектов. Я не имею в виду классическую розничную франшизу. Речь идет о том, чтобы позволить сотрудникам, ближе всего стоящим к перспективной непрофильной разработке, создать вокруг нее небольшое независимое предприятие. Материнская компания может стать якорным заказчиком, сохранить за собой лицензию или миноритарную экономическую долю, а также предоставить ограниченное финансирование на переходный период. Новая структура получит свободу обслуживать других клиентов и создавать долговечный продукт, а не одноразовую внутреннюю функцию.
Такой подход позволяет снизить риски для обеих сторон. Материнская компания избегает долгосрочных обязательств по отношению к непроверенному продукту. Стартап получает проверенного первого клиента, опытных инженеров и задачу, актуальность которой уже подтверждена на практике. Если спрос не возникнет, эксперимент останется локальным. Если продукт окажется успешным, родительская структура сможет продолжить его лицензирование, углубить партнерство, выкупить его или вернуть технологию обратно внутрь компании. Независимость становится механизмом проверки, а не ритуалом увольнения.
Мой собственный переход из корпоративной разработки ПО в сферу создания независимых продуктов изменил мой взгляд на эту проблему. Теперь я разрабатываю и тестирую продукты самостоятельно, включая браузерные графические инструменты. Без корпоративных приоритетов, меняющих вектор моей работы каждые несколько месяцев, я могу исследовать одну и ту же техническую проблему через призму разных продуктов и клиентов. Такая преемственность не гарантирует успех. Но она делает накопление опыта кумулятивным, поскольку люди, получающие обратную связь, остаются ответственными за то, во что код превратится дальше.
Эту модель следует применять избирательно. Компания не должна выделять в отдельный бизнес свой флагманский продукт, стратегически чувствительную инфраструктуру или программное обеспечение, которое невозможно безопасно отделить от защищенных данных и систем. Предпринимательство также не должно становиться благовидным предлогом для перекладывания корпоративных рисков на плечи сотрудников без финансирования, юридических прав или реалистичной клиентской базы. Опрос технических лидеров в Ирландии, проведенный EY в 2026 году, показал, что 36% респондентов назвали нехватку кадров, а около 30% — бюджетные ограничения ключевыми проблемами. Спин-офф не решит ни одну из этих проблем, если он запускается с дефицитом персонала и недофинансированием.
Прежде чем одобрить выделение проекта, руководители должны потребовать доказательства спроса за пределами единственного внутреннего спонсора, наличие преданного своему делу технического владельца, четкие границы интеллектуальной собственности и данных, соглашение о поддержке, этапы финансирования и согласованный план свертывания проекта. Команда должна четко понимать, чем она владеет. Головная компания должна знать, чем она может пользоваться. Обе стороны должны осознавать, что произойдет, если рынок ответит отказом.
Крупные софтверные компании продолжают задаваться вопросом, как сохранить инновации внутри корпорации. Этот вопрос может оказаться слишком узким. Им следует спрашивать о том, как дать хорошей идее достаточно автономии, времени и подотчетной ответственности, чтобы доказать свое право на существование на рынке. Главный риск корпоративных инноваций заключается вовсе не в том, что каждый эксперимент может провалиться. Риск в том, что перспективной разработке никогда не позволят стать настоящим экспериментом.
Опубликовано 26 августа 2026 - 01:07 Наверх
