Кроссдоменная координация. Как двигать огромные IT-проекты в огромной компании
Все знают, что в условиях большой компании очень сложно двигать крупные проекты к успеху. В таком проекте участвует много команд, каждая со своими интересами, приоритетами и особенностями, а общий объём работы — огромный.
Если вам интересно довольно простое решение этой задачи, проверенное опытом нескольких лет и многими десятками проектов в 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.
Руководитель проекта от Бизнеса
https://habr.com/ru/companies/ozontech/articles/766680/