Организация эффективной совместной гибридной команды заказчика и подрядчика

Зачем бизнесу нужен ИТ-подрядчик?

На этот вопрос у нас сразу несколько ответов:

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

• Обеспечение непрерывной поставки результата.

• Современные технологии в основе продукта и компетенция профессиональной разработки. То есть выбранная архитектура, платформы и инструменты, технологический стек должны быть уровня Enterprise, максимально open-source, иметь поддержку и быть гибкими, масштабируемыми и поддерживаться «своими» специалистами, без обязательного привлечения уникальных подрядчиков.

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

Исходя из этих предпосылок, мы рекомендуем создавать единую команду, в которой выделяются «Core team», т.е. специалисты со стороны клиента, и Production team с нашей стороны.

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

Вариант 1. Минимальный

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

Вариант 2. Средний

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

Вариант 3. Полная команда

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

Со стратегической точки зрения это означает, что на горизонте 3-5 лет вы как клиент получаете полностью погруженную команду в собственный большой продукт и можете развивать его дальше собственными силами. И, как бы странно это ни звучало, мы не против, а очень даже поддерживаем такое решение. Для нас это означает, что продукт реально работает, приносит ощутимую пользу, а наши знания и наш ресурс вы можете использовать на новых продуктах и новых идеях. Именно так долгосрочное сотрудничество дает взаимные конкурентные преимущества.

Области совместной работы

Мы выделяем 7 областей, в которых необходимо обозначить совместную работу:

1. Командообразование и команда
2. Организация инфраструктуры разработки
3. Формирование стратегии и планирование ее реализации
4. Выстраивание процессов аналитики
5. Выстраивание процессов разработки, тестирования
6. Управление командой
7. Техническая поддержка

Давайте пробежимся по этим пунктам:

1) Как создать команду и заставить ее работать как единое целое

• Планирование конфигурации команды.

Необходимо определиться, кто нужен по ролям: кто в какой мере принимает решение на стратегическом и оперативном уровне. 

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

• Выстраивание прозрачной коммуникации, процессов и рабочих взаимоотношений.

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

• План развития команды и вопросы наставничества.

Мы периодически собираем от клиентов обратную связь, структурируем ее в конкретные требования к soft & hard skills наших сотрудников и протягиваем через внутренние встречи и задачи развития. При желании мы можем выдавать и встречную конструктивную обратную связь. Плюс в рамках такого сотрудничества идет рождение ценных, так называемых T-shape специалистов. То есть широкого профиля, с глубоким погружением в одну или несколько областей. К примеру, на старте проекта знание доменной (отраслевой) экспертизы, конечно, чаще в головах специалистов клиента. А вот решение нестандартных задач, типа высоконагруженных вычислений или стабильной работы микросервисного приложения в геораспределенных кластерах – у нас.

• Уточнение методологии и параметров работы.

Мы работаем по принципам Agile двухнедельными спринтами, которые заканчиваются демонстрацией результата бизнес-заказчику, а работа с ветками построена по TBD (Trunk Based Development) и для тестирования и выката используется собственная платформа Feature Toggles. Но мы можем работать и с другими инструментами.

• Онбординг.

Тут проще – обычно онбординг тоже разделен между Core командой и Production. Каждый рассказывает ту часть, в которой он особенно силен и может ответить на любой вопрос.

2) Инфраструктура команды и инфраструктура продукта

На этом этапе необходимо продумать несколько ключевых моментов:

• Организация рабочего места.

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

• Инструменты коммуникаций

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

• Организация учета времени

И вы, и мы учитываем использование ресурсов. Мы учитываем каждый час на каждой производственной и даже непроизводственной задаче наших сотрудников. У нас всё ведется в TFS (Azure DevOps), потом интегрируется в Project Server, а оттуда уже выгружаются в учетные системы. У нас выделены отдельные области (space) и коллекции (collections) под каждого заказчика и доступ к ним жестко контролируется. А системы трекинга задач и базы знаний синхронизируются в обе стороны автоматизированными средствами.

• Настройка системы управления задачами

Здесь мы проговариваем иерархию задач, статусы, назначение задач, движение по статусам, отчетность и т.д.

• Проектная область для совместной работы и хранения документации

Обычно это TFS Wiki или Confluence для общих описаний. А вот требования к реализации задач мы храним непосредственно в задачах (PBI). Это позволяет в одном месте получить всю информацию для реализации и проверки результата непосредственно из описания.

• Информационная безопасность в разработке и в продукте

 Область, связанная с организационными вещами – выдача прав доступа, хранение информации и т.д., инструментальными – статическая проверка кода и динамическая проверка решений, настройка quality gates и т.д. Где и как хранятся исходные коды и как они обновляются у вас и у нас. Обычно и тут работают синхронизаторы, которые заливают любые обновления сразу к вам в момент, как их залили в master-ветку.

• Настройка окружений и конвейера CI\CD

Где и какие окружения будут настроены и как код будет собираться и доставляться на них. Обычно Dev и Test окружения расположены на наших локальных серверах и кластерах, а окружения UAT и Prod – в инфраструктуре заказчика.

• Настройка логирования, мониторинга и алертинга

Что и как будет логироваться, что нужно видеть в мониторинге, как будет организован алертинг и какие линии поддержки будут на него реагировать. Тут чаще всего обсуждаются не код и не реализация логов, а бизнесовые и технические метрики, их расчет, историчность, динамика и что они показывают для PO и бизнес-заказчика. Это всё фиксируется в виде отдельных PBI, по которым потом идет штатная работа разработчиков, DevOps и Support специалистов.

3) Формирование стратегии и планирование ее реализации

На самом деле, по своей сути — это пункт номер 0. Работа над концепцией начинается еще до формирования полноценной команды. Именно на нулевом этапе рождается концепция продукта, основные подходы, целевые бизнес-результаты, прорабатывается дорожная карта, выделяется MVP, делаются предварительные оценки и формируется примерный бюджет проекта. Именно на нулевом этапе появляются люди, которые будут определять будущее продукта и как он будет создан – ключевые специалисты в Core и в Production командах.

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

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

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

Подробнее об услуге "Концепция и архитектура решения" мы рассказали на отдельном лендинге.

4) Аналитика

Может, звучит немного странно, но мы выделяем ее для отдельного обсуждения.

Наш опыт подсказывает, что чем лучше бизнес-аналитики работают в Core команде, тем эффективнее работает вся команда в целом. Аналитики на вашей стороне близко к бизнес-заказчику и знают многое того, что передается наставничеством, но трудно поддается описанию в виде формализованных документов.

В рамках аналитики в первую очередь выделяются:

• Формирование пользовательских сценариев. Совместно.

• Сбор и анализ бизнес-требований. Обычно на стороне Core team.

• Системная аналитика. Обычно на стороне Production team.

• Требования к постановке задач на разработку. Production team.

• Процесс согласования и изменения требований. Совместно.

Цель аналитики не описать область, чтоб было понятно. Цель аналитики – поставить задачу разработчику так, чтобы у него не возникало вопросов что делать и как убедиться, что сделанное работает как надо бизнес-заказчику. 

Кстати, про виды аналитики и как она влияет на продукт рассказали тут. 

5) Разработка и тестирование

В этой части мы обсуждаем на старте следующие пункты:

• Работа по TBD

• Проектирование и разработка архитектуры продукта

• Декомпозиция и оценка задач

• Распределение задач по команде

• Работа с фиче «тоглами»

• Внедрение и контроль стандарта разработки (Code Style)

• Процесс код ревью

• Технология и контроль покрытия unit test

• Архитектурный контроль

• Работа с техническим долгом

• Тестирование и качество продукта.

• Функциональное, нефункциональное тестирование, автоматизированное и в какой части.

• Проработка стратегии, подходов для обеспечения качества при прозрачном управлении ресурсами.

Обычно в этой части мы сходимся на 80-90% сразу или клиент согласен взять наши стандарты и подходы, когда мы все покажем и расскажем. Оставшиеся 10-20% обычно связаны с корпоративными требованиям, принятыми в больших корпорациях, когда те или иные решения необходимо провести более-менее формально и зафиксировать том или ином полуофициальном виде. Ничего не имеем против такого подхода и подстраиваемся под каждого клиента.

6) Управление

В управлении командой принимают участие 2 человека – product owner со стороны Core team заказчика и project manager со стороны Production team TE. И они не противоречат, а дополняют друг друга.

Задача продакт оуенера – держать фокус в разработке продукта на нужный результат для бизнес-заказчика и решение любых вопросов внутри компании. Плюс - управление приоритетами и планирование спринтов с точки зрения бизнес-результата

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

О чем надо подумать и что надо проговорить:

1. Ведение бэклога продукта
2. Планирование спринтов, релизов
3. Управление рисками и ожиданиями 
4. Контроль и влияние на продуктовые и проектные метрики.
5. Настройка инструментов управление и контроля за процессами и результатами команды 
6. Настройка продуктовой аналитики 
7. Командообразующие мероприятия 
8. Обучение методологиям работы

Это совместная работа продакт оунера, проджект менеджера и в некоторых моментах – тимлидов с обеих сторон.

7) Техническая поддержка

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

Цель этого пункта – бесшовное сопровождение решения и проактивный мониторинг и реагирование на проблемы до того, как пользователь осознал проблему и обратился в поддержку. А если обратился, то получил быстрый и качественный сервис.

Заключение

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

Есть, конечно, и некоторые нюансы. К примеру, проведение демо результатов спринта или этапа. Бизнес-заказчику обычно показывает проджект-менеджер из Production команды. А вот презентацию топ-менеджерам или совету директоров с защитой концепции, бюджетов и всего необходимого – это уже продакт-оунер. Но на его результат также работает вся команда и любой нужный для этого специалист.

Возникает резонный вопрос – а не размывается ли ответственность при таком подходе?

Ведь обычные взаимоотношения «заказчик-подрядчик» подразумевают контракт, гарантию и контроль через описанные в контракте документы?

 На самом деле – нет. Не размывается. И даже более.

1) Вся работа с нами все равно ведется на основе подписанного Time & Material договора. Мы также несем гарантийные обязательства и бесплатно исправляем ошибки, которые произвели наши специалисты, а ваши нашли на промышленном окружении.

2) Мы передаем исходный код, права на интеллектуальную собственность, гарантируем отсутствие закладок и полные проверки с нашей стороны и с вашей специалистами по информационной безопасности. Часто решения, которые мы создаем, проверяются сторонними специалистами. Бывает, что и нас привлекают на создание или анализ тех или иных решений – у нас есть опыт и соответствующие сертификаты ФСТЭК и ФСБ.

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

4) Взаимная передача компетенций и удачных практик. Мы учимся у вас, вы учитесь у нас, а все невзгоды и проблемы, связанные с продуктом, мы проходим вместе. Такое тоже бывает. Но намного чаще мы вместе радуемся успеху, выраженному в конкретных цифрах и отзывах конечных пользователей.

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

Приходите с идеей, и мы вместе создадим один из лучших продуктов на рынке. Мы делали это не раз в разных областях и сделаем это с вами.