5 подходов к продуктовой разработке

690

Павел Пестряков, руководитель проектной экспертизы по регуляторной отчетности департамента аналитических систем, R-Style Softlab

В рамках генеральной стратегии компании CTO или CIO формируют ИТ-стратегию, отвечающую основным направлениям деятельности компании. Поскольку ИТ-департамент должен поддерживать развивающиеся и меняющиеся бизнес-процессы, покрывать потребность в цифровизации, помогать в создании ценности и поддерживать развитие корпоративной культуры, задача управления ИТ в организации не такая простая, как может показаться на первый взгляд. Перед менеджментом компании встает вопрос: как организовать продуктовую разработку, чтобы ответить на все вызовы бизнес-заказчика?

Подход 1: доверим все вендору

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

Моновендорная стратегия ставит во главу угла решения одного производителя ПО и предполагает легкую интеграцию его продуктов между собой. Вендоры обещают настраиваемые под клиента дистрибутивные решения, простую поддержку и доработку любых изменений. В том числе реализуется понятное SLA (англ. Service Level Agreement — соглашение об уровне сервиса) на разных уровнях и, как следствие, уменьшаются затраты на собственное ИТ-подразделение. Все это за хорошую закупочную стоимость.

Однако платой за такую простоту будет:

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

Мультивендорная стратегия предполагает использование лучших на рынке (или наиболее подходящих для решения определенных задач клиента) решений по автоматизации. В данном случае компания становится независимой от производителя программного решения и при наличии соответствующих ресурсов может адаптировать их возможности под запросы бизнеса.

Минусы данного подхода также лежат на поверхности:

Затраты на встраивание решений в сложившуюся ИТ-инфраструктуру.
Затраты на интеграцию информационных систем.
Риски, связанные с обновлением ПО со стороны вендора (в ряде ситуаций доработки вендора могут конфликтовать с собственной разработкой).
Проблемы, связанные с закрытым кодом (некоторые доработки невозможно произвести самостоятельно из-за отсутствия доступа к исходному коду) или с необходимостью приобретения соответствующей лицензии.
Худшие (по сравнению с моновендорной стратегией) условия по закупкам.
Размытие зон ответственности.

Видя плюсы каждой из стратегий, компании сталкиваются с дилеммой (рис. 1): что делать, если вендор останется; что делать, если он уйдет? Слабые стороны каждой из стратегий неминуемо приведут читателя к мысли о том, что проще будет всю продуктовую разработку перенести in-house, то есть озадачить этим вопросом собственные ИТ-ресурсы.

Рис. 1. Дилемма инвестиций в сотрудников

Подход 2: сделаем все сами

Одним из несомненных плюсов внутренней разработки является контроль любых изменений. Равно как и сохранение экспертизы внутри компании.

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

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

Как измерить уровень зрелости, который будет понятен высшему руководству компании, описано в методологии COBIT (Control Objectives for Information and Related Technology). Методика измерения соответствует международному стандарту ISO/IEC 15504 «Информационные технологии — оценка процесса» и его российской адаптации ГОСТ Р ИСО/МЭК 15504-3-2009.

Оценка производится путем опроса менеджеров высшего и среднего звена. Аудитор или лицо внутри компании, осуществляющие аудит ИТ-процессов, использует опросник, в котором для каждого из уровня зрелости (от 0 «неполный процесс» до 5 «оптимизируемый процесс») выделяют критерии оценки (рис. 2). По каждому из критериев рассчитывается взвешенная оценка и определяется текущий уровень зрелости, который позволяет ответить на следующие вопросы:

Выполняются ли цели организации в рамках процесса, и как они достигаются?
Каковы текущие возможности процессов (объемы, производительность и т.д.)?
Есть ли возможности по улучшению процессов?
Существует ли в компании культура по улучшению процессов?

Рис. 2. Оценка зрелости ИТ-процессов по методологии COBIT 5. Источник: ISACA (Information Systems Audit and Control Association). 2012.

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

Однако некоторые организации частично или полностью ответственность за управление ИТ передают подрядчикам. Известной формой взаимоотношений является outsource.

Подход 3: отдадим на аутсорс

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

В рамках договора и связанных с ним документов перечисляется полный перечень выполняемых задач с указанием SLA и набором оценок эффективности (KPI — Key Performance Indicator) по предоставленным кадрам. В свою очередь, исполнитель по договору несет финансовую и юридическую ответственность за исполнение условий данного договора. Таким образом, минимизируются затраты на различные издержки, связанные с ИТ, а бизнес получает гибкую и ориентированную на решение его задач модель ИТ. Для менеджмента компании процесс управления ИТ в компании становится более прозрачным.

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

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

Подход 4: все спасет Agile

Последнее десятилетние ознаменовано повсеместным использованием гибких методологий разработки программных продуктов. На базе методологий появляются фреймворки. Иногда это фреймворки собственной разработки (например, как SBERgile).

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

Однако зачастую из виду упускается стоимость перехода к гибким методикам.

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

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

Можем точно сказать, что не все фреймворки одинаково полезны. Это прекрасно иллюстрирует подход, описанный в фреймворке LeSS.

Подход 5: откажемся от feature-teams

Основной принцип фреймворка LeSS (Large Scale Scrum) заключается в переходе от функциональных команд (то есть от классической гибкой модели с иерархической структурой команд в рамках одного продукта) к командам со сбалансированной экспертизой. На арену выходят универсальные команды, которые могут работать параллельно. Таким образом, планирование продуктовой разработки упрощается: любая команда может взять следующую задачу из бэклога и выполнить ее в рамках выбранного спринта.

Рис. 3. Составные части фреймворка LeSS. Источник: https://less.works/less/framework?preferred_lang=th

Основная задача методологии — использовать все плюсы гибкой и бережливой разработки для больших продуктовых групп. Потенциал методологии рассчитан на индустрии разработки программного обеспечения со сложной структурой и большим количеством вовлеченных ролей (разработчиков, дизайнеров, аналитиков и т.д.). На сегодняшний день фреймворк используется в таких компаниях, как, например, Huawei, «Додо Пицца», МТС, BMW Group, а также в ряде иностранных банков.

Совместная работа и координация команд для создания продукта высокого качества достигается не только возможностью команд писать код и тестировать результат: необходимы также знания и навыки по моделированию и архитектуре, дизайну UX/UI, основам бизнеса и многие другие.

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

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

Не всем компаниям удается правильно рассчитать баланс между затратами на поддержание своего Large Scale Scrum и выгодами от его реализации. Обычно для данных целей вводится управление портфелем продуктов и рыночные инструменты финансирования. Как, например, это реализовано в компании Activision Blizzard.

Вместо заключения

В ИТ, как и в любой постоянно меняющейся сфере, не существует «волшебной таблетки» (фреймворка, методики и т.д.) для решения всех задач и вызовов организации. Пользуясь выгодами от полной реализации одного из подходов, необходимо принять и негативные стороны. В отдельных случаях компании создают собственный фреймворк, являющийся адаптацией международных практик, что требует от компании больших затрат и ресурсов. И результат может быть получен не скоро. Наиболее грамотное решение — это выработать баланс между существующими на рынке подходами к разработке и развитию ИТ. Только так можно получать выгоды от их реализации и при этом минимизировать потери.