Независимое франчайзинг проектов: почему крупным программным компаниям следует выделять инновации, а не уничтожать их

      TL;DRКрупные программные компании регулярно создают внутренние инструменты, которые оказываются ценными, а затем позволяют им приходить в упадок, когда приоритеты меняются. Роберт Браунштейн предлагает «независимое франчайзинг проектов»: позволить инженерам, наиболее близким к проверенному внутреннему инструменту, выделить его в автономное предприятие, при этом материнская компания выступает в роли первого клиента и партнера по лицензированию. Данные PwC показывают, что 42% генеральных директоров опасаются, что они не трансформируются достаточно быстро; Deloitte предупреждает, что «тонкие» конкуренты, ориентированные на ИИ, снижают минимальные затраты на программное обеспечение.

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

      Время имеет значение. В опросе PwC среди генеральных директоров 2026 года 42% руководителей заявили, что их главная проблема заключается в том, трансформируются ли они достаточно быстро, чтобы успевать за технологическими изменениями, в то время как 29% сомневались в том, достаточно ли их инновационные возможности. Тем не менее, связанный анализ PwC показал, что, хотя половина генеральных директоров считает инновации центральными для стратегии, только 8% существенно внедрили как минимум 5 из 6 практик, связанных с их поддержкой. Отрасли не хватает амбиций. Ей не хватает прочных структур для реализации многообещающей работы в условиях изменения приоритетов.

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

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

      Эта проблема становится все более актуальной по мере изменения экономики программного обеспечения. Прогноз Deloitte на 2026 год для глобальной индустрии программного обеспечения говорит о том, что создание программного обеспечения становится быстрее и дешевле, в то время как «тонкие» конкуренты, ориентированные на ИИ, оказывают давление на устоявшиеся компании. Однако более быстрое производство не создает долгосрочной собственности. Оно может просто помочь организациям производить больше проектов, которые позже будут конкурировать за обслуживание.

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

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

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

      Эта модель должна быть избирательной. Компания не должна выделять свой основной продукт, стратегически чувствительную инфраструктуру или программное обеспечение, которое нельзя безопасно отделить от защищенных данных и систем. Также предпринимательство не должно становиться вежливым ярлыком для передачи корпоративного риска сотрудникам без финансирования, прав или реалистичной клиентской базы. Опрос EY среди технологических лидеров в Ирландии в 2026 году показал, что 36% указали на нехватку талантов, а примерно 30% указали на ограничения бюджета как на ключевые проблемы. Выделение не решит ни одну из этих проблем, если оно начнется с недостаточной численности и недостаточного капитала.

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

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