Как выстроить работу с кросс-продуктовыми фичами, чтобы не было мучительно больно: опыт команды VK WorkSpace
Работа с кросс-продуктовыми фичами — квест для стойких: отдельные команды, независимые регламенты, разные подходы и практики. Часто в таких ситуациях синхронизацию команд блокирует много факторов, что неизбежно влияет на скорость, качество разработки и поддержку кросс-продуктовых фич.
Меня зовут Таисия Толстунова, и на примере команды обеспечения качества продуктов в VK WorkSpace я расскажу, какие трудности могут возникнуть при работе с кросс-продуктовыми фичами и как минимизировать потенциальные проблемы.
Материал подготовлен по мотивам моего совместного доклада с Еленой Кореневой «Преодоление трудностей кросс-продуктового тестирования».
Кросс-продуктовые фичи
Кросс-продуктовая фича — сквозная функциональность, тесно интегрированная сразу в несколько продуктов. То есть такая функция может работать как в одном продукте, так и в нескольких, при этом может использоваться в нескольких продуктах сквозным образом. С точки зрения пользователей, это улучшает UX (User Experience, пользовательский опыт), поскольку в рамках экосистемы продуктов такие функции знакомы и понятны. С точки зрения разработчика, это упрощает администрирование и обновление фичи: внес изменение в одном месте — и апдейт раскатался на все продукты.
Мы активно используем кросс-продуктовые фичи в VK WorkSpace. VK WorkSpace — это коммуникационная платформа для бизнеса, которая включает в себя сервисы:
Благодаря реализации кросс-продуктовых фич в рамках VK WorkSpace для пользователей функциональность выглядит одинаково как при работе через приложение VK Teams, так и при работе в отдельном продукте (например, в корпоративной Почте).
Но реализация и тестирование таких фич — настоящий квест. Поскольку фича кросс-продуктовая, она затрагивает несколько продуктов и требует вовлечения специалистов из разных команд — это может спровоцировать не одну проблему.
Возможные проблемы и наш способ их решения
Два независимых коллектива — как две вращающиеся шестеренки. Поэтому неудивительно, что процесс синхронизации их работы без предварительной подготовки вряд ли будет гладким. Причем сложность такой наладки при увеличении количества команд, вовлеченных в работу с кросс-продуктовой фичей, растет нелинейно.
Потенциальных проблем, как и их предпосылок, может быть много. С некоторыми из них мы столкнулись и научились с ними справляться.
Координация
У нас было два продукта, которые ограниченно взаимодействовали в части авторизации. И однажды, прямо перед релизом, одна из команд принесла нам на тест фичу двухфакторной аутентификации, рассчитывая, что через неделю ее можно будет выкатить в прод. Но се ля ви: ничего в прод через неделю не попало.
Проблем оказалось несколько:
По фиче оказалось много координаторов. В итоге было непонятно, кто несет ответственность и к кому обращаться с вопросами.
Между командами не было налажено полноценное взаимодействие. Команды привыкли работать автономно. Не было коммуникаций достаточного уровня, чтобы договориться о нюансах реализации или уточнить отдельные аспекты. Проблема усугублялась долгими ответами соседней команды — иногда ответ даже на простой вопрос приходилось ждать день из-за низкого приоритета у одной из сторон.
Не было общедоступного статуса по задаче. Мы не могли понять, на каком этапе реализации фича сейчас и что с ней будет происходить: вся информация была локализована в рамках одной команды.
Чтобы решить эти проблемы и предупредить их появление в будущем, мы обратились к руководству и инициировали ряд организационных изменений. В результате:
Появился единый координатор. Это назначенный технический специалист, ответственный за всю фичу целиком по всем продуктам. Фактически он выступает единым источником истины, который знает все о фиче, этапах ее выполнения, возможных трудностях и других аспектах.
Статус по задаче стал общедоступным. Мы создали страницу, на которой собрана актуальная информация о задаче и этапах ее выполнения, что делает процесс работы с фичей прозрачным.
Введена практика регулярных встреч с привлечением ответственных по задачам. Это помогло нам наладить взаимодействие между командами и учитывать особенности работы каждой из них при планировании задач.
No shifting left
В кейсе с упомянутой функциональностью двухфакторной аутентификации проблема изначально была в том, что фичу нам принесли уже в готовом виде. Соответственно, все подробности реализации остались под капотом и вносить любые изменения было сложно, долго и дорого.
Для устранения подобных трудностей мы приняли решение активнее внедрять практики Shifting left. Теперь:
мы получаем требования до начала разработки:
потенциальные реализации обсуждаются с нами заранее:
соседние команды подключают нас к ознакомлению с документацией до начала реализации, ожидают от нас подтверждение об ознакомлении и отсутствии замечаний.
Это помогло предупредить ситуации, когда в препродакшен- или даже продакшен-окружение попадают фичи, требующие глобальной доработки или не удовлетворяющие нашим требованиям.
Архитектура
Изначально, до выстраивания полноценного кросс-продуктового взаимодействия, тестировщики не привлекались к разработке архитектуры кросс-продуктовой функциональности. Это было нашим упущением, поскольку тестировщики — носители уникальной экспертизы, которые кроме общих паттернов знают узкие места в продукте и могут подсветить потенциальные сложности в реализации еще на этапе ее проектирования.
Например, отсутствие практики привлечения тестировщиков однажды дало негативные последствия: при реализации в Календаре функции уведомлений о событиях мы не учли, что нужно привлечь еще одну команду. В результате функция работала через корпоративную Почту, но не была доступна через VK Teams. Причем проблема оказалась на стороне третьей команды, которую изначально не учли.
После анализа ситуации мы изменили подход: теперь тестировщики привлекаются к разработке архитектуры.
Чтобы сгладить привлечение дополнительных команд, уйти от проблем разных ценностей и отсутствия договоренностей о действиях, мы предварительно определили:
насколько детальной должна быть информация в чатах;
при каких ситуациях организовываются созвоны;
какие дополнительные действия нужны, чтобы достичь единой цели.
Чтобы сделать совместные действия более прозрачными и предсказуемыми, мы также постарались выработать общие Agile-практики именно для кросс-продуктового взаимодействия. Причем спектр таких практик мы не ограничиваем — применяем все, что хорошо себя показывает в реальных кейсах.
Техника
Каждая команда в компании — отдельный живой организм. Поэтому неудивительно, что внутри каждой бурлит своя жизнь: разные практики, доски, процессы и то, на какие этапы они разбиваются. Между командами может вообще не быть пересечений. Это не значит, что кто-то работает лучше соседей: каждый выбирает процесс так, чтобы закрывать потребности бизнеса, и это нормально. Более того, такая ситуация при выстраивании кросс-продуктового взаимодействия — это возможность обмениваться опытом и перенимать лучшее. Такой обмен опытом помогает налаживать коммуникацию и лучше понимать коллег. Но поиск компромиссов все равно нужен.
Например, мы обнаружили, что у нас разные процессы тестирования: некоторые команды тестируют на препродакшен-стендах, некоторые — на продакшен-стендах. При этом в контексте кросс-продуктовых фич нам было важно, чтобы тестирование проводилось даже раньше препродакшен-стендов: любые ошибки в таких реализациях важно устранять на как можно более ранних стадиях.
После взвешивания всех за и против мы пришли к единому мнению, что целесообразно вынесение интеграционного теста в отдельный этап. В итоге развернули отдельные стенды и договорились о временных точках тестирования. Таким образом мы получили дополнительный этап проверки на ранних стадиях, не нарушая привычных паттернов работы каждой из команд.
«Так исторически сложилось»
На стороне каждой из команд есть свои скелеты в шкафу. Иногда даже сами команды про них не знают. В свое время мы столкнулись с таким скелетом именно в рамках реализации упомянутой функциональности двухфакторной аутентификации.
Уже после теста и запуска в продакшен мы обнаружили, что некоторые телефонные номера просто нельзя было указать. В результате часть пользователей не могла выполнить требования двухфакторной авторизации.
Мы начали разбираться и выяснили, что проблема уходит корнями аж в 2013 год. Тогда была создана задача, запрещающая добавлять номера с определенным префиксом. И никто из команд, задействованных в работе с кросс-продуктовой фичей, не знал, что это за задача и чем была вызвана необходимость такой блокировки.
Фактически это был блокер, который существенно ограничивал нашу фичу. Осложняло ситуацию то, что это был древний костыль и никто не понимал, как его фикс повлияет на продукт в целом.
После предварительной аналитики мы смогли без последствий выдернуть этот костыль. Но чтобы больше не играть в русскую рулетку, мы начали вести общую базу старых и новых костылей, которые нужно учитывать при разработке.
Прозрачность результата
В работе с привлечением нескольких продуктовых команд важно, чтобы сроки и договоренности соблюдались, а текущий и последующие статусы задачи были очевидны и наглядны для всех участников. Чтобы обеспечить это, важно фиксировать все договоренности и процессы по кросс-продуктовой фиче, например с помощью Confluence и Jira. Должен быть единый источник знаний по фиче, доступный и известный каждому. Так можно в любой момент найти ответственного, отследить этапность, понять сроки выкатки в продакшен и не только.
Если нет четкого регламентирования, часть процессов неизбежно погружается в Black Box, а договоренности теряются или забываются, что в итоге негативно влияет на работоспособность кросс-продуктовой фичи.
Что в итоге: как жить с кросс-продуктовыми фичами
Работа с кросс-продуктовыми фичами всегда сродни движению по тернистой дороге. Но это не значит, что нужно отказываться от улучшения собственных продуктов и удобства пользователей в угоду собственному комфорту.
Можно выстроить процесс работы так, чтобы он был максимально удобным, прозрачным и понятным для всех участников.
Мы собрали свой опыт хождения по граблям в кучу и написали свои выводы:
Чем больше людей задействовано, тем больше риск столкнуться с проблемами координации. Поэтому без единого координатора не обойтись. Этот человек должен быть погружен во все детали процесса.
Когда только планируется разработка кросс-продуктовой фичи, нужно уже на первых этапах начинать взаимодействие с другими командами. О том, что можно просто сделать и принести готовое на согласование, стоит забыть. Иначе можно столкнуться с необходимостью долгой, сложной и дорогой доработкой фичи, а это никому не надо.
Не нужно пытаться привести команды к общим процессам. Достаточно наладить коммуникации и выработать простые правила взаимодействий в рамках кросс-продуктовой фичи. Это поможет исключить разногласия, несостыковки и другие трудности, влияющие на конечный продукт.
Нет команд без скелетов в шкафу. И если команда о них знает, лучше подсвечивать такие места, чтобы случайно не наткнуться на них при разработке кросс-продуктовой фичи. В нашем случае это легко решилось созданием общей базы данных.
Большинство трудностей на пути разработки кросс-продуктовых фич — организационные. Вы можете столкнуться со всеми, что перечислены в статье. Можете найти свои новые блестящие грабли. Или не столкнуться вовсе, если в вашей компании все, от руководителя до специалистов, будут понимать важность таких фич и почему для их реализации и поддержки нужны ресурсы.
