Груминг как ринг: как аналитику выжить в битве за продукт

Что такое груминг

Груминг — это встреча по проработке будущих задач.

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

В груминге участвует вся команда, но главный фасилитатор тут именно аналитик.

На текущем проекте такие встречи у нас проходят раз в неделю и длятся примерно по часу. Полная проработка одной задачи занимает в среднем две‑три недели и выглядит примерно так:

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

Результат: зафиксированные и согласованные с клиентом требования.

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

Результат: утверждённые требования и дизайн, готовые к передаче в разработку.

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

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

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

• Аналитик и дизайнер приносят идеи, бизнес-контекст и договоренности с клиентом.
• Разработка — понимание системы, технических ограничений и потенциальных рисков.

Это уже само по себе поле для дискуссий. И это хорошо.

Конфронтация — это нормально

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

Аналитик представил требования → команда согласилась без вопросов → клиент согласовал все и с первого раза → дизайнер реализовал в макетах → разработка забрала в работу и реализовала один в один → все счастливы 🥰

Но мы живем не в идеально мире. И так работать не будет никогда.

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

Разработка увидит, что клиент придумал что‑то технически нереализуемое. Аналитик заметит, что дизайнер упустил требование из документа. Дизайнер подсветит, что сценарий использования вообще не продуман. Для этого на груминге и нужно живое обсуждение с вовлечением каждого — чтобы нестыковки всплыли здесь, а не в процессе разработки.

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

1. Технические ограничения не позволяют сделать так, как хочет бизнес (или придумал в макетах дизайнер).
2. У участников разные взгляды на то, как реализовать ту или иную функциональность.
3. Команда не понимает бизнес-ценность фичи и не видит смысла в своих больших усилиях по ее реализации.

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

Раунд первый: битва за реализуемость

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

И тут важно охватить три фактора. 

Фактор 1: главная цель — зачем это вообще нужно

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

Задача аналитика: ещё на встрече с клиентом разобраться в цели со всех сторон — кто будет использовать фичу, как и какую пользу получит. Чтобы на груминге уверенно отвечать на вопросы команды и защищать ценность идеи.

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

Фактор 2: как это будет работать в нашей платформе

Вот здесь и начинается битва. По этому пункту у разработчиков всегда появляются вопросы, и это правильно. Идея может оказаться сложной в реализации или вообще невозможной, затрагивать другие части системы, требовать дополнительных исследований — все это надо обсуждать. 
Важный момент! Если разработка говорит «мы не можем это сделать», на этом вопрос не закрывается. Я, как аналитик, должна выяснить, что именно это означает:

• Почему не можем?
• А если будет больше времени — сможем?
• Что можно поменять, чтобы все-таки сделать?
• Если так не сможем сделать, то как сможем, чтобы цели достичь?

Когда задаешь такие вопросы, запускается дискуссия, появляются новые идеи, нестандартные решения и альтернативные варианты. В 9 случаях из 10 оказывается, что то, что было сделать невозможно, все-таки возможно. Просто в другом виде ;)

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

В таких ситуация для меня главное не ответ «да, можем сделать» или «нет, так не получится», а понимание причин. Причины могут быть в сроках, в деньгах, в логике. Если позиция аргументирована достойно — это повод честно задуматься: правильную ли реализацию мы выбрали? И поискать другие подходы. Из личных наблюдений еще: хорошая команда обычно не просто говорит «невозможно», а сама предлагает более простые пути к той же цели. Я не раз оказывался в ситуации, когда предлагал что‑то сложное, а команда говорила: «А давай возьмём вот эту библиотеку — получится похоже, но в десять раз быстрее.

Фактор 3: дальнейшие планы на масштабирование

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

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

Итог раунда: валидация решения

Начинающий аналитик в какой‑то момент может поймать себя на мысли: ну почему разработка вечно говорит «не можем»?! Тут важно понять, что команда отказывается не из вредности, а потому что реально не может. Детская позиция здесь — «не волнует, делайте». Взрослая — запустить дискуссию, найти альтернативный путь и всё равно достичь бизнес-цели, пусть и другим способом.

Да, итоговое решение может сильно отличаться от первоначального. Да, его придется согласовывать с клиентом. Но если аналитик внимательно провалидировал результат и понял, что решение (пусть и другое) всё равно помогает достичь цели, значит всё ОК. Несем на согласование клиенту! 

Раунд второй: битва за дизайн

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

И здесь на первый план у нас выходят двое — дизайнер и аналитик. У каждого их них своя роль в этом раунде:

• Аналитик валидирует макеты на соответствие требованиям. По сути, защищает идею клиента.
• Дизайнер следит за пользовательским опытом и целостностью дизайн-системы. То есть, защищает пользователей. 

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

На этом этапе у команды обычно возникают два типа вопросов:

Технические вопросы

Можем ли заменить сложный компонент на более простой? Поддерживает ли используемая библиотека такое поведение?

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

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

Эстетические вопросы

А эти цвета точно хорошо сочетаются? А этот элемент не должен быть выше? А это точно будет интуитивно понятно пользователям?

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

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

У нас примерно такая же логика действий в ситуациях с улучшательством (это и про дизайн, и про техническую реализацию). Кто‑то говорит «а давайте сделаем ещё лучше», и понеслась… Проблема в том, что очень сложно оценить КПД этого всего, особенно когда горят сроки. Поэтому мой подход таков: большинство предложений — в бэклог, рассмотрим позже. Но если вся команда настойчиво говорит «точно надо делать так, а не иначе» — я доверяю их экспертизе.

Главное правило второго раунда: не подменяй чужую роль

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

• Разработка не диктует дизайнеру, как рисовать. 
• Аналитик не переделывает макеты.
• Дизайнер не игнорирует технические ограничения.

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

Финальный раунд: битва с боссом (клиентом)

Два раунда позади. Команда поспорила (конструктивно, конечно же), нашла лучшее решение, дизайнер его визуализировал. Теперь всё это нужно принести клиенту и защитить.

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

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

Как всё это пройдет, зависит о того, с каким типом клиентов мы работаем. 

Адепт ТЗ

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

Что поможет: макеты с явной привязкой к требованиям, чтобы было видно, что каждый пункт ТЗ либо реализован, либо заменён чем‑то равноценным. Причем, лучше, чтобы технические причины изменений объяснял разработчик, а не аналитик с его слов. И главное — показать, что бизнес-цель достигается, пусть и другим путём.

Клиент-визуал

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

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

А что, если клиент меняет требования прямо на встрече?

Такое бывает. То, что клиент представил в своей голове (или зафиксировал в ТЗ), на макетах выглядеть может совсем иначе. Отсюда и изменения.

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

Если же изменения масштабные, здесь имеет смысл включиться в разговор ПМ-у. Его задача — объяснить клиенту, что масштабные правки на этом этапе означают ещё два раунда проработки и, соответственно, увеличение сроков реализации. А соблюдение сроков и бюджетов как раз в зоне ответственности ПМ-а. Как показывает практика, когда клиент понимает прямую связь между правками и сроками, аппетиты к изменениям заметно уменьшаются.

Что помогает аналитику пройти все раунды груминга

Если вы дочитали до этого места, значит, груминг больше не кажется вам «встречей по задачам, на которой все срутся». И надеюсь, что конфронтация на нём теперь тоже не пугает. Потому что если правильно с ней работать, никакого конфликта по сути и нет. А есть конструктивное обсуждение, где каждый может быть с чем‑то не согласен. Но это не баг, а фича — старт работы по поиску лучшего решения для каждого конкретного случая.

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

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

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

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

Отказ принимать «не можем» как финальный ответ. Задаю вопросы, направляю разработку на размышление, запускаю мозговой штурм. Часто за «невозможно» прячется «сложно» или «нужно больше времени». И тогда нужно просто вместе наштурмить альтернативное решение поставленной задачи.

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

Смелость подсветить дизайнеру, если макеты не совпадают с требованиями. Человеческий фактор никто не отменял. Дизайнер мог просто не заметить какое‑то требование. А я его составляла, и отследить его адекватную реализацию — моя задача.

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

Скажу честно: я груминги не очень люблю. Наверное, потому что провожу их слишком часто, и эмоционально они уже поднадоели. Но я точно знаю, что если их не проводить, возникнут проблемы. Это как уборка в доме: не обязательно убираться каждый день, но если этого не делать регулярно, раз в какой‑то период придётся долго и мучительно разгребать Авгиевы конюшни. Мы работаем короткими недельными спринтами и проводим груминги максимально часто. Главный профит — скорость и стоимость. И самое важное: мы всегда понимаем, где находимся по проекту.

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