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

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

Меня зовут Татьяна Егорова, я руковожу департаментом управления знаниями и технической документации в Лукоморье. У нас много продуктов и над каждым работает отдельная команда. У каждой свои пользователи, дорожная карта и сроки, так что вопрос «как сделать, чтобы они не разъехались в разные стороны» встал перед нами давно. Ответ, к которому мы в итоге пришли, звучит так: аналитик делает свою задачу и тратит ещё десять процентов внимания на то, чтобы не сломать задачу соседа.

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

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

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

Другая история из той же серии. Команда добавила новый элемент на главный экран своего приложения: функция полезная, требования проработаны, релиз состоялся. Соседняя команда узнала об изменении после выхода в прод. С точки зрения первой команды всё прошло по процессу, а вот с точки зрения экосистемы в клиентском пути появился разрыв.

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

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

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

Что за десять процентов

Формулировка появилась у нас на одном из ретро и прижилась, потому что честно описывает объём усилий. Мы не просим аналитика брать на себя чужую ответственность, погружаться в соседний продукт или согласовывать каждую строчку требований со всеми командами. Нужно просто потратить примерно десятую часть внимания на вопрос «кого ещё это касается».

На практике эти десять процентов складываются из нескольких вопросов, которые нужно успеть себе задать до начала разработки. 

• Затрагивает ли новая функция соседние продукты?

• Не существует ли уже похожего решения где-то рядом?

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

• Нужно ли заранее предупредить другие команды?

• Какие договорённости стоит зафиксировать, чтобы через полгода их не пришлось изобретать заново?

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

Почему это работа аналитика

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

Здесь резонно спросить: разве за это не отвечают дизайнеры, архитекторы и Product Owner? Отвечают, каждый за свою часть. Дизайнер держит визуальную целостность, архитектор отвечает за технические решения, PO за ценность и развитие продукта. Аналитик стоит в точке пересечения всех трёх областей и обычно первым замечает, что новая логика вот-вот порвёт существующую связь между элементами экосистемы.

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

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

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

Куда мы вложили правило 10%

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

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

Процесс 1. Декомпозиция, или давайте сначала поймём, где функция должна жить

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

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

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

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

Процесс 2. Согласование, или нам нужно подумать о влиянии изменений до релиза

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

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

Процесс 3. Трассировка, или давайте разберёмся, за какую ниточку мы тянем

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

Приведу пример из нашей практики. У нас есть приложение Яга Задачи — это система управления проектами и таск-трекер, которым мы сами пользуемся уже давно.

Допустим, команда меняет логику работы сущности в Яга Задачи. Изнутри изменение выглядит небольшим, но если эта сущность используется где-то ещё, сразу появляются вопросы: что зависит от текущего поведения, какие требования придётся обновить, кого предупредить, нужна ли обратная совместимость?

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

Процесс 4. Версионирование, или помним, почему система работает именно так

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

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

Мы ведём требования в системе Яга Статьи — это наша собственная система управления знаниями и ведения документации. Все страницы в ней версионируются автоматически. Но в дополнение к этому мы фиксируем важные моменты отдельными строчками: дата изменения, причина (грумминг, изменение требований заказчика, изменение API контрагента и т.д.). В этом случае поднять историю «почему требования к интеграции поменялись» — значительно проще.

Рутина, которая не даёт сэкономить 10%

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

Мы пользуемся своими продуктами

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

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

Дальше эта привычка начинает работать на экосистему. Сотрудник читает требования на доработку смежного продукта Яга Статьи, видит знакомые три точки и автоматически ждёт знакомой реакции. Если на макете открывается другой сценарий, вопрос возникает сам собой: почему один и тот же элемент ведёт себя непривычно.

С виджетами для Яга Аналитика (наша BI-система с дашбордами и метриками) на главном экране Яга Задачи та же логика. Аналитик, который сам каждый день работает в приложении, видит, что уже стоит на рабочем столе, где новому виджету будет удобно и какие сценарии перегружать нельзя. Он смотрит на макет глазами автора требований и глазами человека, который завтра будет этим пользоваться.

В шаблоне требований у нас есть поле «Влияние на продукт X»

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

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

Представим, что команда приложения Око хочет добавить на главный экран Яги своего ИИ-агента. Для Око это новая полезная функция. Главный экран при этом часть продукта Яга Задачи, поэтому его аналитики должны узнать о планах заранее. Останавливать изменение никто не станет, но им нужно понять, где встанет новый элемент, не конфликтует ли он с текущими сценариями и как учесть его в будущих требованиях. 

Мы собираем штурмы с другими командами до того, как начать делать

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

Приведу пример. При разработке модуля «Согласование» для Яга Задачи мы вспомнили, что похожие функции есть в Яга Статьи, и сразу подумали, можно ли взять готовое. Разобрали сценарии и поняли: несмотря на одинаковое название, процессы разные, объединять их не нужно. Зато по ходу обсуждения нашли другое пересечение: механизм работы с таблицами в текстовых полях удалось забрать из Яга Статьи целиком. В итоге решение не пришлось писать с нуля, пользовательский сценарий остался знакомым, а у команд появился общий подход.

Лиды аналитиков регулярно встречаются 

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

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

У нас общий онбординг

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

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

Что бывает, когда договорённость осталась на словах

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

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

Десять процентов внимания в тот раз потратили ровно там, где надо. Проиграли мы на том, что договорённость осталась в разговоре и никуда не попала. С тех пор вопрос «нужно ли что-то зафиксировать» стоит в чек-листе отдельным пунктом.

Десять процентов начинаются со знакомства людей

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

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

И здесь многое упирается в обычные человеческие отношения. Если аналитик из соседней команды остаётся для тебя незнакомым именем в задаче, написать ему «кажется, здесь есть несостыковка, давай посмотрим вместе» может быть психологически трудно. Страшно показаться некомпетентным или отвлечь перегруженного человека. С коллегой, с которым уже был опыт совместной работы, такой разговор начинается гораздо проще.

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

Наш расширенный чек-лист перед проработкой новой функции

В заключение

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

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

А как это устроено у вас? Особенно интересны истории про то, как соседняя команда узнавала о вашем релизе из чата поддержки.