4. КОМАНДЫ ЦИФРОВЫХ ПРОЕКТОВ:

ПРАКТИКИ ФОРМИРОВАНИЯ СОСТАВА
По данным исследований компании Ward Howell, в сегодняшних условиях, когда происходит интенсивное цифровое развитие во всех отраслях экономики, значительно повышаются требования к скорости вывода новых ИТ-продуктов на рынок. Необходимость быстро реагировать на ситуацию и экспериментировать зачастую делает неэффективным распределение процесса разработки ИС и услуг между разными функциональными подразделениями. Поэтому в государственных организациях часто создается орган управления — единый центр управления и принятия решений (наподобие управляющего проектного офиса), который несет всю ответственность за получение результата проекта и его дальнейшее развитие, для этого в его распоряжении должны быть все необходимые ресурсы и компетенции. Такой единый центр допустим как в ФОИВ, так и в подведомственных организациях, чаще всего органы управления выполняют функции, представленные в предыдущем параграфе в направлении «Развитие цифровых продуктов и управление процессами» (см. раздел 3). Выбор такой модели ускоряет разработку, улучшает коммуникации между участниками и делает процесс координации задач и отслеживание статуса их выполнения эффективнее. Безусловно, подразделения ЦТ реализуют параллельно несколько проектов, у них есть несколько команд, отвечающих за создание и развитие различных ИС, услуг в рамках решения масштабных задач, достижения стратегических целей цифровой трансформации ФОИВ.
Органы государственного управления только вступают на путь цифровой трансформации, приглашают высококвалифицированных специалистов из коммерческого сектора, благодаря их участию в работе осваивают модель организационного устройства команд цифровых проектов. Таким образом, происходит миграция организационных моделей из бизнеса в госсектор.
Опыт крупных корпораций, бизнес-организаций, а также системных интеграторов дает большое количество кейсов по организации структур команд цифровых проектов. В зависимости от сложности, масштаба и приоритетности ИС, услуги, уровня зрелости, финансовых возможностей и управленческого подхода, а также множества иных факторов определяются роли и формируются структуры команд цифровых проектов.
Рассмотрим примеры состава команд цифровых проектов в коммерческом и государственном секторах.

4.1 Команды цифровых проектов: опыт коммерческих организаций

С целью соблюсти определенные положения внутренних политик компаний о закрытии внутренней информации в описании кейсов команд проектов не указывается принадлежность к конкретной компании, представляется только их сфера деятельности.
Команда проекта
«Разработки веб-сайта компании»
Финансовая сфера
Результат проекта:
сайт компании, который содержит полную информацию о компании-владельце, услугах/продукции, событиях в жизни компании. На сайте представлены различные функциональные инструменты для работы с контентом (поиск и фильтры, календари событий, фотогалереи, корпоративный блог, форумы). Сайт интегрирован с внутренними ИС компании (CRM, бухгалтерскими системами и др.), содержит закрытые разделы для различных групп пользователей (сотрудников, контрагентов и пр.).
Состав команды:
сотрудники компании — 14 чел., внешние подрядчики для реализации отдельных компонентов — 2 чел. (рисунок 16).
Рисунок 16. Структура команды проекта
Особенности:
  • Дизайнер интерфейсов (UX-, UI-дизайнер), SMM-маркетологи, контент-менеджер являются сотрудниками управления маркетинга компании.
  • Функции руководителя проекта выполняет владелец продукта.
  • Роль финансового аналитика неспецифична для подобных команд и является особенностью данного проекта.
Команда проекта
«Разработка и настройка личного кабинета клиента: веб- и мобильное приложения»
Телекоммуникации
Результат проекта:
полнофункциональный личный кабинет на сайте организации, который удобен в мобильном приложении и интуитивно прост в пользовании. Административный интерфейс для сотрудников организации позволяет: рассылать уведомления, получать и обрабатывать заявки, создавать группы пользователей, помогать клиентам с решением технических вопросов.
Состав команды:
сотрудники организации — 29 чел., внешний эксперт по безопасности информации — 1 чел. (рисунок 17).
Рисунок 17. Структура команды проекта
Особенности:
  • Владельцы продуктов делятся по двум направлениям (мобильное приложение и веб-версия личного кабинета).
  • Роли исследователя данных (Data-scientist) и архитектора централизованы.
  • Чтобы добиться высокого уровня безопасности приложения, привлекли независимого эксперта в сфере безопасности цифровых данных.
Команда проекта
«Разработка мобильных инструментов»
Торговля
Результат проекта:
разработаны мобильные инструменты (мобильное приложение iOS, мобильное приложение на базе Android и система клиент-серверного взаимодействия (API)).
Состав команды:
работали три продуктовые команды по 6−7 человек. Каждая команда разрабатывала отдельный мобильный инструмент (продукт), но при этом все инструменты были связаны между собой контентом. Пример состава одной из команд показан на рисунке 18.
Рисунок 18. Структура команды проекта
Особенности:

При управлении проектом использовался метод Scrum, что позволило сделать разработку прозрачной и понятной для всех участников:

  • планировались двухнедельные спринты с четко определенным результатом;
  • ежедневно Scrum-мастер обсуждал идеи и ход проекта с командой разработчиков;
  • команда демонстрировала результат раз в две недели на готовых сборках;
  • Scrum-мастер проводил ежемесячные ретроспективы, чтобы команда работала эффективнее и качественнее.
Команда проекта
«Внедрение корпоративного хранилища данных»
Производственная сфера
Результат проекта:
корпоративное хранилище данных — организованный массив данных предприятия, который хранят и обрабатывают в едином аппаратно-программном комплексе. Последний обеспечивает быстрый доступ к оперативной и исторической информации, многомерный анализ данных (KPI по различным измерениям), получение прогнозов и статистики в разрезе согласованной нормативно-справочной информации.
Состав команды:
сотрудники организации-заказчика — 7 чел., сотрудники организации-исполнителя — 9 чел. (рисунок 19).
Рисунок 19. Структура команды проекта
Особенности:
  • Бизнес-аналитик обеспечивает двустороннюю взаимосвязь между предметными экспертами (функциональными специалистами) заказчика и IT-специалистами исполнителя. Для этого он выполняет сбор требований, их обработку, документирование и передачу специалистам исполнителя, доводит полученные результаты до представителей заказчика.

  • Специалист по моделям данных является архитектором модели данных, формирует концептуальную и логическую модели данных, участвует в формировании физической модели данных.
CRM — Customer Relationship Management — система управления взаимоотношениями с клиентами.
iOS — мобильная операционная система для смартфонов, электронных планшетов, носимых проигрывателей и некоторых других устройств, разрабатываемая и выпускаемая американской компанией Apple.
Android — операционная система для смартфонов, планшетов, электронных книг, цифровых проигрывателей, наручных часов, фитнес-браслетов, игровых приставок, ноутбуков, нетбуков, смартбуков, очков Google Glass, телевизоров и других устройств.
API (Application Programming Interface – программный интерфейс приложений) — технология взаимодействия программных систем (обмена данными).
KPI (key performance indicators)— ключевые показатели эффективности.