Хотя компании, возможно, уже признали важность программного обеспечения, они по-прежнему склонны рассматривать программное обеспечение как возможность, которую они могут "прикрутить" к существующиму бизнесу.
И что приходится делать? Развивать софтверный бизнес, то есть создавать подразделение или бизнес-единицу, которые будут заниматься разработкой программного обеспечения. Но не получится подойти к развитию софтверного бизнеса на тех же корпоративных подходах и технологиях, что и традиционный бизнес. Но так не получится - чтобы развить софтверный бизнес, необходимы фундаментальные изменения, связанные с различным набором навыков, практикой, лидерством и организационной структурой.
Выделяют три архетипа компаний, переходящих от традиционной бизнес-модели к бизнес-модели программного обеспечения.
Первый архетип. Программное обеспечение - в основе бизнеса, стратегия развития бизнеса базируется на программном обеспечении, операционная модель смещается в сторону программного обеспечения. Например, один ведущий глобальный банк понял, что для того, чтобы реагировать на потребности финтех-компаний и меняющиеся ожидания клиентов, ему необходимо стать цифровым банком.
Второй архетип. Запуск нового бизнеса по разработке программного обеспечения. Этот архетип может начать генерировать новые доходы, а сам бизнес по разработке программного обеспечения может стать доминирующими.
Третий архетип. Компания имеет программное обеспечение, разработанное для внутреннего использования и решает превратить некоторые программные решения в товар и вывести на рынок.
Некоторые компании следуют нескольким архетипам, если у них есть возможности и достаточный рыночный спрос.
Но не все так просто. Только 7% рынка программного обеспечения приходится на нетехнологические компании. Остальную долю рынка держат софтверные профессиональные компании.
Поэтому трудно компанией-разработчиком программного обеспечения. McKensey предлагает шесть принципов, которые должны сопровождать успешную попытку стать компанией-разработчиком программного обеспечения.
Придерживаться культуры разработки программного обеспечения.
Требуется создать культуру, которая глубоко ценит творчество и мастерство инженеров, лидерство, ориентированность на клиента. Руководящая команда должна обладать глубокое понимание бизнес-моделей и технологии программного обеспечения.
Лидерство
От одной трети до половины руководящего состава должны быть экспертами в программном обеспечении. Это может потребовать изменения состава руководящей команды. Совет диреторов должен иметь как минимум двух директоров с опытом работы с программным обеспечением, отслеживать прогресс конкретных ключевых показателей эффективности программного обеспечения. Также потребуется обучать и менеджеров среднего звена. Это означает базовые тренинги, посещение стартапов. Эффективное обучение и обретение опыта требует налаживания отношений и тесного взаимодействия с компаниями-разработчиками программного обеспечения.
Коммуникация
Стратегия, ценностное предложение и прогресс программного бизнеса должны сообщаться последовательно. Одна из задач состоит в том, чтобы сделать это таким образом, чтобы сделать приоритетным бизнес программного обеспечения, сохраняя при этом основной бизнес и его сотрудников, работающих и чувствующих себя ценными.
Не менее важно знать, как идут дела у других компаний, какие используются технологии и каковы затраты ресурсов, труда и квалификации.
Инвестиции
Компании, чей бизнес - программное обеспечение, требуют постоянных инвестиций. Большинству новых предприятий необходимо реинвестировать в среднем от 25 до 35 процентов доходов в течение трех-пяти лет, прежде чем они начнут приносить прибыль. Также требуются значительные операционные расходы, потому многие компании обращаются к поглощениям. Во многих случаях одно крупное приобретение является ключом к ускорению развития бизнеса, ориентированного на программное обеспечение.
Инвестируйте в менеджеров по программным продуктам
Вы не можете создавать программные продукты мирового класса без менеджеров программных продуктов мирового класса. Они превращают творческую силу инженеров и дизайнеров в выигрышные программные продукты и услуги. Они привносят сквозную ответственность, а в некоторых случаях даже полную ответственность за прибыли и убытки конкретного продукта. В мире технологий господство и важность продакт-менеджеров хорошо известны. Но немногие нетехнологические компании возлагают на них соответствующие обязанности или влияние. Это большая ошибка.
Две ключевые характеристики отличного менеджера по продукту:
- Такие менеджеры зациклены на данных об использовании программного продукта и используют все доступные и недоступные данные: от знания клиентов, информирования о продвижении согласно дорожной карты создания программного продукта до принятия решений о выводе продукта из эксплуатации, а также в содействии пользователям деле быстрого извлечения выгод от использования клиентом программного продукта. Продукт-менеджеры проводят активные полевые испытания и эксперименты для получения нужных данных о том, как улучшать продукт.
- У отличного менеджера по продукту прекрасное «чувство продукта», точно так же, как у лучшего тренера лошадей есть «чувство лошади». Основываясь на многолетнем опыте и мышлении, не ограниченном нормами, успешные продакт-менеджеры обладают интуитивной способностью понимать, как технологии могут решить проблему клиента по-новому. Они привлекают дизайнеров, инженеров и специалистов по обработке и анализу данных на ранней стадии формирования идей и задействуют широкий спектр нестандартного мышления.
Автономные команды, гибкая архитектура для достижения высоких результатов
Хорошая разработка программного обеспечения не может развиваться в иерархической организации. Крайне важно предоставить продуктовым командам автономию для экспериментов, опробования новых технологий и разработки собственных решений. Все начинается с предоставления менеджерам по продукту свободы и ответственности, чтобы они могли руководить своими межфункциональными командами так, как они считают нужным. Эта автономия может поддерживаться ключевыми механизмами (такими как цели и ключевые показатели) для обеспечения ответственности за результаты и автоматизированными функциями (такими как тестирование), которые не только ускоряют разработку, но и устанавливают барьеры для ограничения риска.
Чтобы команды разработчиков могли работать автономно, им нужна гибкая техническая архитектура. Основные компоненты этой архитектуры включают API, которые могут получать доступ к базовым данным, алгоритмам и процессам в устаревших системах; набор микросервисов (по сути автономных единиц кода, которые выполняют определенную функцию), которые являются модульными и подключаются к API, устраняя зависимости, которые досаждают устаревшим системам, где изменение одной части кода обычно требует множественных изменений в других; и общая платформа данных, которая объединяет разрозненные источники данных в единый доступный пул, к которому разработчики могут легко получить доступ.
Экосистема в деле разработки программного обеспечения
Экосистема программного обеспечения объединяет независимые технологические компании, от 30 до 40 миллионов штатных и независимых разработчиков. Компании-разработчики программного обеспечения все чаще нуждаются в доступе к широкой экосистеме, чтобы получить доступ к талантам, что необходимо для конкуренции.
Приобретение или доступ к разработчикам программного обеспечения, взращивание их и преобретение ими отличного опыта имеет решающее значение для победы. Ведущие компании подключаются к этой экосистеме разработчиков с помощью двух стратегий.
- Присоединение к существующей экосистеме. В широкой программной экосистеме есть множество бурно развивающихся подсистем, управляемых ведущими поставщиками программных услуг, которые вложили огромные средства в расширение возможностей и услуг своих платформ. Почти все лидеры говорят, что присоединение к существующим экосистемам — отличный способ получить доступ к опыту ведущих разработчиков.
- Создание внутренней экосистемы. Разработка собственной программной экосистемы либо на основе партнерства с клиентами, либо с другими поставщиками или разработчиками программного обеспечения.
Создание возможности выхода на рынок программного обеспечения
Продажа программного обеспечения сильно отличается от продажи других продуктов. Большинство компаний, не занимающихся программным обеспечением, продают по принципу «затраты плюс цена», ориентируясь, например, на маржу. Но поскольку программное обеспечение имеет низкие предельные издержки (после разработки), ценообразование должно основываться на ценности, которую программное обеспечение создает для клиента.
Еще одно отличие: продажа программного обеспечения требует более глубокого взаимодействия с клиентом. Это сообщения обновлений, отслеживания того, как клиенты используют программное обеспечение, предоставление технических экспертов, которые могут научить клиентов, как использовать программное обеспечение. Возможно для продаж придется привлекать извне ветеранов в деле продаж программного обеспечения.
Поиск и сохранение талантов
Конкуренция за лучшие технические таланты в настоящее время является жесткой. Компаниям легче нанимать лучших специалистов, если они имеют привлекательную миссию, предоставляют разработчикам работу, которая позволяет разработчикам развивать ключевые навыки в области программного обеспечения, .
Компаниям, стремящимся привлечь таланты в области программного обеспечения, вероятно, придется переосмыслить свои методы найма.
Но компании часто недооценивают опыт сотрудников, что приводит к серьезным проблемам с удержанием. Лучшие инженеры-программисты, например, хотят автономии, хотят иметь возможности для роста и развития своих навыков.
Опыт разработчиков может быть настолько важен, что компания использует панель инструментов для отслеживания оценок удовлетворенности разработчиков.
Источник
McKinsey Quarterly
Every company is a software company: Six ‘must dos’ to succeed
December 13, 2022
https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/every-company-is-a-software-company-six-must-dos-to-succeed
Комментариев нет:
Отправить комментарий