Думаю, кому-то из вас будет интересно, как организованы процессы развития IT-продуктов в Ozon.

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

Бывает полезно посмотреть на опыт конкретной компании и сравнить с тем, как это устроено у вас. Или прикинуть, насколько вам подходит такая организация, если рассматриваете Ozon как потенциального работодателя.

Вот вам взгляд изнутри, а именно – из той части IT, которая занимается автоматизацией логистики. 

Что для нас продукт?

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

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

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

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

Бизнес и IT

Создание и развитие продукта — всегда дело коллективное. Вовлечённых в этот процесс в логистике Ozon можно поделить на две категории:

• Первая отвечает за бизнес-эффект от IT-продукта (далее — бизнес)

• Вторая — за то, чтобы с помощью IT-продукта, этого бизнес-эффекта можно было достичь (далее — IT).

Другими словами, бизнес получает некую выгоду от использования IT-продукта, а IT — даёт ему инструменты для этого. 

Чтобы продукт получился хорошим и заработал (или сэкономил) много денег, партнёрство бизнеса и IT должно быть эффективным. Как минимум:

• IT-команда должна хорошо понимать бизнес: как устроены бизнес-процессы, какие у бизнеса проблемы, кто, где и как будет пользоваться продуктом. Бизнесу же важно хотя бы в общих чертах понимать, как устроена разработка продуктов, чтобы знать, как помочь IT на том или ином этапе.

• Разграничение ответственности: это когда каждая сторона занимается своим делом, и не пытается вмешиваться в деятельность другой. Бизнес считает, приумножает и экономит деньги, а IT — делает инструменты для этого.

• Доверие: IT-команда должна доверять бизнес-эффекту от внедрения новой фичи, который насчитал бизнес; в то же время бизнес должен доверять IT детали реализации фичи (главное — чтобы можно было достичь бизнес-эффекта). Но, конечно, никто не запрещает обеим сторонам задавать вопросы и предлагать что-то, касающееся и бизнес-эффекта, и деталей реализации.

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

Конечно, иногда бизнес приходит с решением вместо проблемы. В таких случаях мы сначала выясняем, какую задачу мы решаем. Надо ли говорить, что итоговое решение часто отличается от того, с которым пришли ?

Масштабирование: как с ним быть?

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

Но чтобы развивать такую махину, как Ozon, нужно много разных специалистов. В IT-подразделениях Ozon работают тысячи человек. А в IT логистики — более шести сотен.

Организовать такую большую команду — задача не из лёгких. Надо, чтобы все двигались в одну сторону, помогая друг другу, а не мешая. А ещё лучше — чтобы была синергия, которая приносит компании наибольшую выгоду.

Хочется просто классическим образом разделить всех на автономные кросс-функциональные команды, которые бы как можно более независимо двигались к общей цели. Каждая из команд даёт профит, который потом просто суммируется, — красота!

В реальности же всё не так просто.

В нашем случае логистика, или доставка — это цельный процесс, который состоит из этапов. Логистика начинается в момент появления скомплектованного заказа и заканчивается вручением посылки клиенту. На этом пути много этапов: комплектация, сортировка, объединение в грузы, отгрузка, приёмка в сортировочном центре, передача курьеру, выдача клиенту.

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

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

Кроме того, у логистики ещё есть централизованные функции, например маршрутизация грузопотока или отслеживание местоположения посылок.

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

Выделенная IT-команда, которая отвечает за развитие и поддержку какой-либо предметной области, у нас называется доменом (от англ. domain knowledge).

Домены бывают разного уровня (прямо как в DNS ????). Вся команда IT логистики — это тоже большой домен. И это первый уровень — самый высокий.

Далее команда IT логистики делится на домены поменьше, отвечающие за разные этапы или централизованные функции логистики. У нас есть такие домены, как Центральная логистика, Курьерская доставка, Маршрутизация, Управление транспортом и другие.

Когда же прекращается деление? Всё зависит от количества людей: примерно когда получается команда из пяти  — девяти человек. Думаю, вы помните, что это стандартная численность команд в Scrum. Но это в идеале. Частенько команды получаются больше. Меньше — редко.

Такая неделимая автономная команда, отвечающая за свой кусок предметной области, — это домен самого низкого уровня. У нас в обиходе именно она называется доменом.

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

А что внутри домена?

Раз домен — самодостаточная IT-команда, то в ней должны быть все специалисты, которые нужны, чтобы развивать и поддерживать её предметную область без посторонней помощи.

Домен состоит из двух частей:

1. Продуктовой, которую представляет как минимум владелец продукта (product owner). Если предметная область велика и неделима, а одного владельца продукта мало, то продуктовая часть вырастает в небольшую команду под его лидерством. В ней могут быть продакт-менеджеры поменьше, проджект-менеджеры, системные и бизнес-аналитики, аналитики данных, дизайнеры и другие необходимые специалисты.

2. Технологической, к которой относятся разработчики и QA-инженеры, возглавляемые тимлидом. Технологическая часть может быть поделена на несколько команд (до четырёх), если домен большой. Каждая из таких команд обычно состоит из разработчиков, QA-инженеров и тимлида.

Взаимодействие частей

• Продуктовая часть домена отвечает на вопрос «ЧТО делаем?» — вплоть до мельчайших деталей. Её задача — глубоко и точно понять бизнес, прикинуть, как воплотить его желания в IT-системах, и в подробностях рассказать об этом представителям технологической части домена. А затем помочь довести разработку и тестирование до конца, проверив то, что получилось.

• Технологическая часть ответственна за ответ на вопрос «КАК делаем?». Это про архитектуру, технологии и процессы разработки софта, применяемые для достижения целей бизнеса.

Продуктовая и технологическая части домена очень тесно связаны и сильно зависят друг от друга. Естественно, оба вопроса — «Что делаем?» и «Как делаем?» — они всегда обсуждают вместе. И все решения по ним обоим, фактически являются коллективными. Ведь обычно именно так и принимаются лучшие решения.

Тогда зачем такое разделение? Дело в компетенциях и распределении ответственности.

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

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

А кто отвечает за решение, тот его и принимает.

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

Взаимодействие доменов

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

Как же устроено взаимодействие доменов? Приведу несколько упрощённых примеров.

Совместный проект

Логистические продукты в основном развиваются в рамках общих проектов разного размера, поэтому домены чаще всего взаимодействуют друг с другом в рамках таких проектов. Здесь я не буду вдаваться в подробности того, как устроено проектное управление в Ozon, — это тема для отдельной статьи. Сам проект как бы распадается на домены. Можно сказать, что каждый домен ведёт свой подпроект в рамках общего. Также представители домена выполняют в проекте роль экспертов в своей предметной области.

Участники проекта от каждого домена объединяются в рабочую группу под началом того, кто ведёт проект. В отличие от домена, который является постоянной командой, рабочая группа — это временная команда на период работы над проектом. Чаще всего от домена свой кусок большого проекта ведёт кто-то из продуктовой части. Участники рабочей группы делают свои части проекта, постоянно синхронизируясь (встречи, переписка и т. д.), совместно тестируя и внедряя изменения в продуктах.

Поддержка продуктов

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

Обычно контактной точкой домена по умолчанию является product owner. Что касается ответов на вопросы, то у каждого домена для этого обычно есть свой чат по предметной области в Mattermost (open source-заменитель Slack), либо в MS Teams. У нас приветствуется обсуждение вопросов в общих чатах, а не в личной переписке.

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

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

Также у каждого домена есть свой Jira-проект (иногда и несколько) и место в Confluence для документации.

Работа с инцидентами и проблемами

Каждый домен отвечает за один или несколько продуктов, которые реализованы в виде сервисов либо какой-то логики в монолите (да-да, он у нас пока есть, хотя постепенно распиливается на микросервисы).

Основная тяжесть борьбы с инцидентами ложится на технологическую часть домена.

У нас есть достаточно развитые и выверенные процедуры эскалации инцидентов.

В итоге, поскольку все мы сильно связаны, чаще всего инцидент устраняют совместно несколько доменов.Так же вместе они принимают меры для того, чтобы он не повторился.

Плюсы и минусы доменной структуры

Автономность и независимость

Мне кажется, это один из основных плюсов.

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

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

Глубокая экспертиза команды в предметной области

Тоже очень важный плюс. 

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

Экспертиза позволяет быстро и эффективно решать проблемы бизнеса на своём участке, развивая продукты.

Зона ответственности домена определяется границами его предметной области. При чётко определённых границах довольно просто понять, какая команда что делает. Также несложно определить точки интеграции.

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

Хороший результат достигается при регулярном пересмотре границ. Так можно нащупать оптимальное для текущей ситуации разделение ответственности. 

Вообще умение быстро передвигать границы в ответ на изменения в бизнесе — сильное преимущество. 

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

Бонусом является то, что сработавшаяся постоянная команда более эффективна, чем временная. Команде достаточно один раз пройти этапы развития по модели Такмана, чтобы достичь более высокой производительности и наращивать экспертизу.

И даже если получается так, что какую-то предметную область развивать больше не нужно, команда может взять на себя ответственность за другую область. Меняется сфера ответственности и название домена, а состав команды остаётся прежним.

Сложность деления на домены

Можно отнести к минусам.

Гораздо проще поделить большую IT-команду на ресурсные отделы: разработки, аналитики, тестирования и так далее.

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

Чаще всего деление происходит методом проб и ошибок. То есть выдвигается гипотеза, что разделиться надо именно так, обсуждается и проверяется на практике. 

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

Интеграция доменов — это тоже не просто

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

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

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

Управление доменом

Фактически в домене царит двоевластие: им управляют продуктовая и технологическая ветви власти. В этом случае решения получаются выверенными, поскольку принимаются коллективно и путём аргументации, а не приказов.

Обратная сторона в том, что принимаются такие решения не быстро — особенно если домен новый и его команда ещё не прошла все стадии притирки. Принятие решения происходит через обсуждения и споры. И это при наличии простого принципа разделения ответственности в виде «Что делаем?» и «Как делаем?», который описан выше. 

Баланса власти достичь непросто. Иногда случаются конфликты. А бывает, что и команды приходится реорганизовывать. Частенько бывает так, что одна ветвь подавляет другую. 

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

Управление несколькими доменами

Делать это качественно — весьма нетривиальная задача. 

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

От такого руководителя критически зависит правильное деление на домены. Но проблема в том, что такие руководители с одновременно хорошо развитыми продуктовыми и технологическими навыками - встречаются редко. Обычно есть явный перекос либо в сторону продуктового опыта (эдакий Head of Product), либо в сторону технического (эдакий Head of Development).

В Ozon чаще имеет место быть в разной степени выраженный перекос в технологическую сторону. Руководителем часто становится «выросший» тимлид одной из команд разработки. Как следствие — перекос и внутри домена: не хватает продуктовой экспертизы, что сказывается на качестве продуктов.

Хорошей альтернативой является то же самое двоевластие, что и внутри доменов, на уровнях выше. В такой схеме у владельцев продуктов есть свой «продуктовый» руководитель, а у тимлидов команд разработки — свой «технологический». Это позволяет устранить перекос и сбалансировать власть, что в итоге ведёт к принятию выверенных решений в части развития продуктов (хотя они и принимаются медленнее). 

Такая структура используется в IT логистики (и ещё в некоторых подразделениях), но только на первом, наддоменном, уровне. А далее всё равно руководитель один. 

Выводы

Хороша ли описанная выше модель организации продуктовых IT-команд? Сложно ответить однозначно. 

В пользу того, что она действительно неплохо работает, говорит тот факт, что примерно в таком виде эта структура существует больше трёх лет, постепенно совершенствуясь. Более того, за эти годы IT-команды Ozon численно выросли в три  — пять раз. А это подтверждает способность оргструктуры к масштабированию.

Однако такая модель, конечно, не лишена недостатков, главные из которых перечислены в предыдущем разделе.

Вероятно у вас всё организовано лучше. Интересно было бы почитать.