Все знают, что в условиях большой компании очень сложно двигать крупные проекты к успеху. В таком проекте участвует много команд, каждая со своими интересами, приоритетами и особенностями, а общий объём работы — огромный.
Если вам интересно довольно простое решение этой задачи, проверенное опытом нескольких лет и многими десятками проектов в Ozon, — смело читайте дальше!
Немного пояснений вначале
В прошлой статье я писал, что продуктовая разработка в Ozon построена на взаимодействии доменов. Буду здесь использовать термины «домен» и «Бизнес», про которые там рассказано подробно.
Но если не читали, тогда вот:
Домен — выделенная IT-команда, которая отвечает за развитие и поддержку какой-либо предметной области, у нас называется доменом (от англ. domain knowledge).
Бизнес — все подразделения Ozon, которые напрямую отвечают за бизнес-ценность от IT-продуктов. То есть, по-простому, за деньги, которые зарабатываются или экономятся. IT-домены же отвечают за инструменты, применяя которые, Бизнес получает нужный бизнес-эффект.
Предположим, Бизнес задумал новый грандиозный проект и хочет от IT-команды Ozon очередную порцию автоматизации. Но команда IT — очень большая. Надо понять, кто и как будет участвовать. То есть, чтобы получить результат — надо разобраться в хитросплетении доменов. Очевидно, IT-команда должна помочь заказчикам от Бизнеса.
Кросс-доменный проект
Большой проект, в котором участвует много IT-доменов, мы предсказуемо называем кросс-доменным проектом. А раз проект большой, то его должен кто-то координировать. В теории это мог бы быть руководитель проекта от Бизнеса, но в силу масштаба это крайне затруднительно.
Ведь Бизнес не настолько хорошо знает устройство систем и процессов IT-команд, чтобы эффективно тянуть проект вперёд, обходя подводные камни. Надеяться на то, что IT как-нибудь сами договорятся и всё сделают — тоже наивно, поскольку очень много участников, у которых свои приоритеты.
Кроме того, опять же в силу масштаба проекта надо координировать команды Бизнеса. А где же тут ещё на IT найти время?
И вот тут в дело вступает специальная роль — кросс-доменный координатор.
Координатор кросс-доменного проекта
На первый взгляд, всё просто: появляется человек из IT, который помогает Бизнесу и указывает всем вовлечённым в проект IT-доменам правильное направление к критериям успеха.
Но на самом деле — это очень непростая роль.
Начнём с вопроса: а когда же у проекта появляется координатор от IT? Насколько большим должен быть такой проект?
Мы считаем, что имеет какой-либо смысл «официально» назначать координатора, если проект затрагивает от трёх и более доменов.
Конечно, фактически всегда кто-то будет координировать такой проект и возьмёт на себя эту роль. Например, представитель домена, от которого Бизнес ждёт финального результата. В таком случае обычно просто договориться, какой проект «ведущий», а какой — «ведомый». Другими словами, координирует тот, у кого конечный результат, приносящий ценность.
Другое дело, когда в проекте участвует пара-тройка десятков доменов из разных департаментов IT. А такое бывает нередко.
Как координатор помогает успеху проекта ?
Логично предположить, что в целом координатор отвечает за помощь Бизнесу в успехе проекта. Давайте разберемся, как именно.
Любой проект начинается с какой-то идеи. Бизнес на то и Бизнес, чтобы генерировать идеи. Опытный кросс-доменный координатор сначала выяснит у Бизнеса в подробностях, почему идея достойна реализации. Попросит показать, как это посчитали и задаст прочие неудобные вопросы. Потому что не хочется вкладывать множество усилий IT в проект, в эффекте от которого есть сомнения.
Далее, если есть намерение идею реализовать, Бизнесу надо провести немалую аналитическую работу по описанию изменений в бизнес-процессах, которые надо сделать, чтобы добиться критериев успеха проекта.
Но нередко Бизнес приходит за помощью к IT, когда понятна только идея проекта и нет даже критериев успеха. Ну что ж, приходится действовать в условиях неопределенности и совместно с Бизнесом проделывать эту работу. Как ни странно, обычно так даже быстрее, чем если бы Бизнес рисовал красивые схемы, не понимая ограничений в IT-системах, а потом бы их совместно переделывали.
Кросс-доменный координатор в этом случае выступает «голосом от IT», помогая сформулировать критерии приемки, ограничения и прикинуть масштабы изменений в бизнес-процессах и IT-системах.
Так или иначе, с какой-то попытки на свет появляются более-менее годные артефакты в виде схем, диаграмм, текстовых описаний и так далее.Становится понятно, из чего именно состоит проект.
Далее нужно прикинуть, какие домены нужно включить в проект, чтобы получить желаемые Бизнесом изменения. Кросс-доменный координатор помогает руководителю проекта от Бизнеса это осознать. Далее они вместе рассказывают о проекте и отвечают на вопросы со стороны представителей доменов (обычно это владельцы продуктов). Вырисовывается ещё более понятная картина.
Но есть проблема: у всех доменов куча работы, к ним с разных сторон приходят с множеством проектов. Следовательно, им надо понять приоритеты этих проектов относительно друг друга, чтобы решить, на что тратить драгоценное время.
В Ozon существует своя система приоритизации проектов в разрезе доменов, которая достойна отдельного рассказа. Если совсем кратко, то у каждого домена существует регулярная встреча, где происходит битва за приоритеты проектов между заказчиками от Бизнеса. Её у нас именуют «ТехКом» (сокращение от Технический комитет).
Задача кросс-доменного координатора — привести руководителя проекта от Бизнеса за ручку на ТехКом каждого вовлеченного в проект домена и помочь с деталями, чтобы проект смог получить нужный приоритет.
При этом, сам кросс-доменный координатор сражаться за приоритет не может, поскольку не отвечает за бизнес-эффект, то есть за деньги. А следовательно, не может на равных говорить с другими интересантами от Бизнеса на языке бизнес-метрик. Это задача руководителя проекта от Бизнеса. Когда проект получил приоритет на ТехКоме, расслабляться не стоит: ведь его могут потеснить на следующем?. Поэтому кросс-доменный координатор старается не пропускать ни одного ТехКома, чтобы этого не случилось.
А ещё иногда вдруг выясняется, что в проекте не обойтись без какого-то нового домена, вот и приходится снова бежать и приоритизировать.
В целом координатору важно приоритизировать проект так, чтобы он синхронно двигался во всех доменах с определенной скоростью, и никто никого не блокировал. А это — целое искусство.
После успешной приоритизации уже можно составить верхнеуровневый план проекта. Кросс-доменный координатор ведёт такой план совместно с руководителем проекта от Бизнеса до самого завершения проекта. Даже если проект получил самый высокий приоритет во всех доменах, этого недостаточно, чтобы началась эффективная совместная работа множества команд.
Нужно наладить коммуникацию между IT-доменами и Бизнесом. И это тоже задача кросс-доменного координатора от IT. При этом за коммуникацию между командами от Бизнеса отвечает руководитель проекта от Бизнеса, поскольку знает специфику гораздо лучше.
Чтобы наладить коммуникацию, кросс-доменный координатор проводит кросс-командные встречи, как регулярные — по статусам, так и разовые — по конкретным вопросам; инициирует и модерирует обсуждение в чатах; делает анонсы; следит за артефактами в Jira; базой знаний в wiki и так далее.
Кросс-доменный координатор — главная точка контакта от IT по проекту. Координатор понимает, что именно делает для проекта каждый домен, что делается по проекту сейчас, озвучивает прогнозы по срокам. Поможет ответить на любой вопрос, даже если сам не знает ответ, призвав на помощь тех, кто знает. Управляет ожиданиями Бизнеса от IT.
Часто бывает так, что сроки, когда проект даст результаты, слишком велики. Кросс-доменный координатор — как раз тот человек, который поможет найти оптимальное решение в этой ситуации, понимая объемы и суть доработок в системах. Например, проект можно разбить на этапы, завершив каждый из которых, IT принесёт Бизнесу часть той ценности, какую даёт проект целиком.
Совместно с руководителем проекта от Бизнеса координатор работает с рисками, подсвечивая те, что в плоскости IT. В случае, если риск реализовался, — эскалирует всем, кто может помочь, и сам оказывает помощь в поиске наилучшего решения со стороны IT.
Когда домены готовы к общему тестированию, кросс-доменный координатор совместно с представителями доменов планирует сценарии тестирования и координирует дальнейший процесс. Как только становится понятно, что доработки доменов скоро можно внедрять, — планирует процесс внедрения.
Обычно непосредственно участвует в ключевых точках внедрения (у нас в логистике это непростой и растянутый во времени процесс), планируя дальнейшие шаги и помогая решать проблемы здесь и сейчас.
И даже после внедрения работа кросс-доменного координатора не закончена: ведь надо какое-то время мониторить, как изменения в рамках проекта повлияли на бизнес-процессы. А также — устранить недостатки либо запланировать их устранение (а это могут быть уже новые проекты).
Кроме того, координатор помогает Бизнесу оценить бизнес-эффект от внедрения, договорившись с IT о создании инструментов для этого (отчёты, графики).
Просуммировав сказанное выше, давайте попробуем очертить зону ответственности координатора, доменов и Бизнеса, используя матрицу RACI.
Руководитель проекта от Бизнеса | Кросс-доменный координатор | Домены | |
Валидация идеи проекта, подсчёт бизнес-эффекта | AR | C | - |
Бизнес-аналитика | AR | C | R |
Валидация состава проекта, критериев приёмки, ограничений со стороны IT | C | A | R |
Приоритизация проекта в домене | AR | C | C |
Составление и ведение плана IT-проекта | I | A | R |
Построение коммуникации между Бизнесом и IT | R | A | R |
Построение коммуникации внутри Бизнеса | AR | I | - |
Построение коммуникации внутри IT | I | A | R |
Управление ожиданиями Бизнеса от IT | I | A | R |
Управление IT-рисками проекта | I | A | R |
Системная аналитика | - | C | AR |
Разработка по проекту | - | I | AR |
Общее тестирование | I | A | R |
Приёмка функционала | A | C | C |
Внедрение | A | C | R |
Мониторинг и сопровождение после внедрения | A | C | R |
Оценка бизнес-эффекта от внедрения | AR | C | I |
В общем, выходит, что кросс-доменный координатор — весьма полезный человек.
И если вы — Бизнес, и у вас большой кросс-доменный проект, у вас должно появиться желание получить координатора от IT :)
Вот как это можно сделать у нас в Ozon.
Всё относительно просто: надо прийти в любой IT-домен, а лучше — в наиболее вам знакомый, рассказать о проекте и попросить помочь с координацией.
Возможно даже такое, что тот же владелец продукта посчитает проект сильно интересным для развития продукта домена и сам вызовется быть координатором.
Если нет — то подскажет, где лучше поискать координатора, либо эскалирует этот вопрос большому начальству уровня CTO или директора департамента и вернётся с ответом.
По моему опыту, координировать кросс-доменные проекты людям интересно, потому что почти в каждом случае есть серьезные новые вызовы их профессиональным компетенциям. И многие вызываются даже без эскалации.
Координатор или руководитель проекта ?
Как-то всё описанное выше похоже на роль обычного руководителя проекта, не правда ли? Однако есть важные отличия.
Дело в том, что структура IT-команд в Ozon базируется на относительной автономности, самостоятельности команд. При такой модели в идеале кросс-доменных проектов вообще не должно быть.
Делает себе каждый домен полезные фичи независимо от других, и все довольны. Но на практике почти невозможно разделить IT на полностью независимые команды, о чём я писал в уже упомянутой статье.
Каждый домен ведёт свой «автономный» портфель проектов, в котором есть как локальные для домена проекты, так и части кросс-доменных.При этом у каждого проекта внутри домена всегда есть тот, кто за него отвечает. То есть, по сути, руководитель небольшого проекта. Чаще всего это даже не человек в выделенной роли проджекта, а владелец продукта, аналитик или тимлид разработчиков.
Выходит, в кросс-доменном проекте принимают участие столько менеджеров IT-проектов, сколько вовлечено доменов.
Таким образом, получается, что кросс-доменный координатор координирует даже не проект, а программу проектов. То есть набор взаимосвязанных проектов, направленных на достижение общей цели.
Также здесь важно поговорить о роли этих самых менеджеров IT-проектов от доменов, участвующих в кросс-доменном проекте.
Дело в том, что наш подход к проектному управлению основывается на высокой вовлечённости и проактивности доменов. Другими словами, от доменов ожидается, что они стремятся сделать всё возможное, чтобы добиться общей цели, и берут на себя как можно больше ответственности.
Например, если одному домену надо о чём-то договориться с другим, они пытаются договориться без привлечения координатора, а потом рассказать всем об этой договоренности, поскольку она может повлиять и на другие домены.
Конечно, не всегда это работает идеально, но чаще — срабатывает.
Следовательно, помощь кросс-доменного координатора нужна только в некоторых случаях, а чаще домены всё делают сами.
Вот и получается, что это, скорее, координация, а не управление программой проектов в обычном понимании.
Кто может исполнять эту роль ?
В целом это сильно зависит от масштаба проекта, набора вовлеченных доменов, важности проекта и других подробностей.
Попробую описать в общих чертах, что должен знать и уметь человек, подходящий на роль кросс-доменного координатора:
Обладать широкой экспертизой в том, какие IT-системы есть в Ozon и как они между собой взаимодействуют. Необязательно всё знать досконально (таких людей практически не существует), но важно иметь хотя бы общее представление о том, что происходит с момента появления покупателя на сайте Ozon до момента получения им посылки с заказом. Также очень полезно обладать экспертизой поглубже на каком-то конкретном участке этого процесса.
Владеть глубокой экспертизой в предметной области какого-либо домена, а лучше — в нескольких. В том числе для того, чтобы быстро и достаточно глубоко погрузиться в проблемы других доменов, если это будет нужно.
Иметь опыт ведения кросс-доменных проектов. Сначала — хотя бы небольших, где участвует мало доменов. Тут стандартно: чем сложнее и масштабнее проекты — тем ценнее опыт.
Быть технически подкованным, чтобы говорить со всеми вовлеченными в проект IT-шниками на одном языке и глубоко понимать, как архитектурно будет реализован проект.
Уметь поддерживать интерес к проекту со стороны IT-доменов и Бизнеса. Возможно, неочевидный пункт. Но совершенно необходимый, чтобы проект довести до конца. Для этого понадобятся проактивность, способность довольно глубоко вовлекаться в проект и гореть им.
Вырисовывается портрет специалиста весьма высокой квалификации.
И это, на мой взгляд, основное слабое место подхода: качество координации сильно зависит от уровня квалификации координатора.
Сильных координаторов всегда не хватает. Но можно и нужно развивать необходимые компетенции.
В IT логистики чаще всего роль кросс-доменного координатора берёт на себя владелец продукта одного из доменов. Причем — из числа наиболее опытных и квалифицированных. Поскольку именно такой человек обладает достаточными компетенциями, чтобы справиться со всеми сложностями кросс-доменной координации.
Обычно координатор вполне предсказуемо выбирается из домена, который наиболее вовлечён в проект, либо находится в конце цепочки по созданию ценности.
Другие нюансы роли
По моему опыту, лучше всего с ролью кросс-доменного координатора справляются не выделенные для этой цели на полную ставку люди, а те, кто совмещает координацию с работой внутри одного из доменов, участвующих в проекте.
Причиной этого я вижу пункт про глубокую экспертизу в предметной области, а также понимание того, как устроен домен внутри. В этом случае гораздо легче погрузиться в проблемы доменов, чтобы помочь их разрешить. Поэтому в Ozon роль кросс-доменного координатора чаще исполняют по совместительству.
Прошлый опыт работы внутри других доменов тоже очень полезен, но может со временем устареть, поскольку всё быстро меняется.
Важно сохранять здоровый баланс в части контроля над кросс-доменным проектом: не пускаться в микроменеджмент, а оставаться именно координатором.
На управление кросс-доменным проектом в классическом понимании, а уж тем более на управление проектами доменов, обычно просто нет времени.
Но даже если бы было, так не стоит делать по другим, более важным причинам:
во-первых, появляется бутылочное горлышко. Если координатор перегружен, или, того хуже, заболеет — это немедленно превращается в проблему для всего проекта;
во-вторых, есть последствие похуже: в долгосрочной перспективе это воспитывает несамостоятельность доменов. Значит, в какой-то момент даже для небольшого кросс-доменного проекта может потребоваться свой микроменеджер, а для большого — целая команда проджектов на полную ставку.
Из этого следует очень важное правило успеха:
Кросс-доменный координатор должен стремиться делегировать любую возможную работу доменам.
Тогда получится совмещать кросс-доменный проект с развитием внутри своего домена или доменов. А домены-участники воспитают в себе ещё большую самостоятельность.
К тому же координатор сможет найти себе замену почти без ущерба для проекта, если, например, уходит в отпуск.
В то же время нельзя вести проект поверхностно, только спрашивая сроки, проводя встречи и рисуя презентации, иначе просто лишишься контроля.
Как вы можете догадаться, это распространённая проблема и у нас, ведь соблазн велик.
Критически важно вовремя замечать проблемы и решать их. Вот для этого и нужен богатый и разносторонний опыт, а также достаточно глубокое погружение.
Подведём итоги
Что сложнее: вести проект в классическом смысле или вот так вот координировать ?
По моему мнению, координировать сложнее. В этом случае надо в очень большой степени полагаться на вовлечённые домены, при этом сохраняя контроль над проектом.
Также надо помнить, что кросс-доменный проект — скорее, программа проектов, а не проект. А программой управлять сложнее, в принципе.
Как мне кажется, подход к ведению больших проектов в виде кросс-доменной координации — довольно простое и надёжное решение, требующее минимума дополнительных ресурсов.
Разумеется, есть более зрелые подходы: например, фреймворки масштабирования Agile. Но они уже сложнее во внедрении и поддержке.
А как вы двигаете огромные проекты?