Привет, я Саша Тян. Работаю деливери менеджером в Каруне. А ещё — моя фамилия настоящая, да, это не аниме. В названии статьи тоже нет ошибки: я расскажу об одной регулярной встрече, которую мы внедрили и сделали счастливее и продактов, и разработчиков.
Из ХЗ сделать ТЗ
Возможно, вы сталкивались с классической историей: поговорили с заказчиком о задаче, всем всё понятно. Начали работать — и началось: "А я думал, это и так ясно" или "Я ожидал, что ты это опишешь точнее".
Начинается круговорот вопросов, переделок, а главное — неоправданных ожиданий и недовольств.
В Каруне происходила похожая ситуация. Компания стремительно расширялась, проекты росли, стало много продакт менеджеров, ещё больше разработчиков, и ещё больше задач, которые требовали грамотных решений.
Процесс был таким: часть продактов формулировала задачу самостоятельно, звала на встречу тех разработчиков, которых считала будущими исполнителями, чтобы обсудить предстоящий таск. Ещё часть продактов готовила требования и разбиралась с вопросами от разработчиков уже в процессе производства.
Последствия такого подхода:
Куча хаотичных встреч в календаре разработчиков, и свободный слот найти крайне сложно.
Ситуации, когда забыли позвать нужного специалиста.
Разрыв контекста между командами, работающими над задачей.
Подводные камни, найденные в процессе разработки.
Недовольство команд к качеству ТЗ ("Я ничего не понял").
Недовольство продуктовой команды из-за фидбека к качеству ТЗ ("Я же всё описал").
Недовольство стейкхолдеров и топ-менеджмента от долгого ожидания задач.
Все берут задачу в работу, она сырая, все сердятся. Месяц разработки превращается в три, пока все разбираются и пытаются понять, что к чему. Нужно было навести порядок и сделать работу для всех комфортной.
С чего началось движение на встречу?
Вместе с коллегой мы решили собрать фидбек от продактов по работе с производственным департаментом. Большая часть опрошенных сообщила, что основная боль в работе — непредсказуемость завершения задачи. Пожеланием было — больше общаться с командами разработчиков.
“Всё классно”, говорили ребята, “но постоянно обидно от того, что не все технические моменты обсудили и поняли”.
Мы поговорили с инженерами, и они сказали: “Вот бы к нам менеджеры заранее пришли и вместе с нами бы обсудили, в чём проблема, и что можно сделать. Мы бы подсказали, кто нужен, чтобы всё решить. Давайте обсуждать вместе”.
Мы провели основательную ретроспективу, чтобы найти опции по решению проблем. Спрашивали у техлидов и тимлидов: что, по их мнению, чувствует продакт, когда он приходит с задачей и реально хочет сделать хорошо, ищет помощи, но не может полноценно объяснить, что именно ему нужно с технической точки зрения? И мы поняли, что все мыслят в этой ситуации в схожем направлении. Всем хочется заранее знать: суть задачи, какую проблему хотим закрыть через её решение, и всех потенциальных участников.
Мнение ребят из технического департамента было таким: долгая разработка зачастую — следствие плохо проработанной задачи. Команды не знают планов на будущее, не могут предусмотреть что-то, чтобы помочь продактам с новыми задачами. И потому одной из опций по решению этой проблемы стало создание встречи с продуктовой командой по планам и проработке задач.
Всем хотелось встречаться и обсуждать. Как — никто не понимал.
Как собрать кучу людей — всех продактов и инженеров — в одной точке, чтобы они просто поговорили о том, что и как лучше сделать, чтобы все были в курсе предстоящих тасков, и не было суеты?
Первым дело нужно было решить это:
Определиться, на каком этапе разработки должна быть встреча.
Сколько таких встреч должно быть.
Кто должен на них присутствовать.
Сколько задач обсуждать.
Вместе с деливери менеджерами и CPO мы пришли к следующему:
Нужны встречи на этапе, когда идея продакта согласована с топ-менеджментом и нуждается в исследовании разработчиками или иными специалистами (у нас этот этап называется Fine Tuning).
Встречи нужны раз в неделю (у нас по четвергам).
Обсуждаем 4 задачи.
На каждую задачу выделяем 30 минут.
На встречу зовём тех разработчиков, которым задача будет интересна, или кто работал с похожей ранее.
Любой может спокойно уйти со встречи, если понял, что задача к нему не относится.
Итого: заменить кучу несистемных встреч одной системной. Раз в неделю должно быть 4 встречи, длительностью 30 минут каждая. Специалисты приходят, если задача относится к ним. А если не относится, не приходят. Продакты назвали такую встречу по-скрамовски PBR (Product Backlog Refinement или Груминг бэклога).
Мы шли к этому решению месяц.
Организационные моменты
Я анонсировала идею разработчикам — они, разумеется, не были довольны затеей с какой-то встречей длиной в 2 часа. Им и без того некогда кодить, нормально обсуждать дела с командой и просто пива выпить вместе. Но таки дали встрече шанс, когда услышали, что она дробится на 30-минутные слоты, и по факту может занять всего полчаса их времени, а то и меньше.
Для внедрения встречи нужен был список задач продактов на обсуждение, инструмент оповещения команд и плейсхолдер в календаре со всеми лидами и продакт командой, чтобы никто не забыл.
Продакт команда придумала голосование в своём чате, куда выносила приоритетные задачи. По итогам голосования я писала анонс в чат разработчиков. Те, к кому относилась задача, ставили плюсы, и этих людей надо было звать на встречу. В комментариях к посту мне могли сообщить, что "здесь нужно позвать ещё админов, нужна будет их консультация" или "тут точно нужен дизайнер". Так мы сразу стали собирать всех, кого нужно.
Четверговый PBR Fine Tuning
План проведения получасовой встречи:
5 минут продакт питчит свою идею. Рассказывает, в чём замес и проблема. Инженеры слушают. Если вдруг кто-то замечает, что нет того, кому всё это тоже может быть важно и интересно — экстренно зовём. Все к этому готовы, это не проблема.
20 минут команда обсуждает задачу, задаёт вопросы, предлагает варианты решений, озвучивает риски. Если продакт чего-то не знает — открыто признаёт и гарантирует, что разберётся в вопросе и в следующий раз придёт с решением.
5 минут на резюме встречи: фиксирование договорённостей, открытых вопросов, вариантов решений, рисков.
Моей задачей было следить, чтобы все эти пункты соблюдались, и встреча не превращалась в чтение документации или в обсуждение уже придуманного решения.
Поначалу всё шло очень тяжело, потому что продактам было не понятно, что нужно рассказывать, разработчики не понимали, зачем они тут. Дело пошло, когда продакты начали рассказывать о своих идеях, подсвечивать риски и задавать вопросы, разработчики объясняли и уточняли бизнес нюансы. Были и ситуации, когда оказывалось, что позвали не всех, и в моменте звали специалистов, чтобы узнать мнение и риски с других сторон. Так постепенно эта встреча стала открытой для любого стейкхолдера, любого специалиста из любого отдела.
Бывали ситуации, когда продакты приходили обсуждать реализацию вместо описания проблемы, которую нужно решить. Из-за этого разработчики задавали вопрос: “А для чего мы тут собрались, если уже всё решили?”. Однажды мы потратили почти всю встречу, когда в конце узнали, что мы обсуждали неудобное решение, но разработчики не понимали, для чего. В конце кто-то задал вопрос: “А какую проблему мы хотим решить?”. И после этого вопроса за последние 7 минут началось обсуждение. За это время мы поняли важное:
Снова нужно нести эту задачу на обсуждение, чтобы понять, как решить проблему бизнеса,
20 минут было потрачено впустую.
Это послужило нам хорошим кейсом: мы стали учиться обсуждать не реализацию, а проблему, и какими способами можно её решить.
Уже через месяц встречи стали регулярными. На них обсудили большое количество задач, где требовалась консультация инженеров. Разработчики уточняли цели, накидывали кейсы. Продакты советовались, каким образом реализовать фичу быстрее, сокращали на месте скоуп работ, договаривались об итерациях. Дополнительно инженеры попросили заранее сообщать агенду (какую проблему хотят решать в задаче). Теперь в зависимости от агенды они могли заранее сказать, точно ли нужен будет специалист из другого отдела или нет. Также могли заранее посмотреть, не было ли у нас похожего технического решения, не была ли реализована уже та логика, которая требуется бизнесу, но в другом виде, не сталкивались ли мы с подобной проблемой ранее, и так далее.
Чуть позже на этих встречах начали обсуждать вопросы по задачам “To Do” и “In Progress”. Однажды на PBR не было ни одной задачи в статусе Fine Tuning, и я предложила продуктам принести на встречу задачи, которые находится в этих статусах, где есть вопросы.
Суть встречи осталась той же: продакт должен объяснить проблему текущей задачи и обозначить это в агенде. Таким образом он не отвлекал специалистов от текущей работы хаотичными встречами или тонной переписок в личке. Если в задаче со временем поменялись условия, и она поменяла статус, продакт мог прийти с агендой “поменялись бизнес требования из-за ситуации на рынке” и вновь начать обсуждение по задаче, никого не отвлекая по отдельности.
Ещё через время продакт команда предложила обсуждать инциденты на этой же встрече.
Хэппи Энд
PBR существует у нас в Каруне уже больше полугода.
Все привыкли к таймингу: теперь за полчаса мы успеваем обсудить самое основное, не уходя в технические детали. Теперь разработчики заранее знают, какие фичи прорабатывает продакт команда. Теперь продакты еженедельно консультируются с инженерами по своим задачам.
Теперь нет разрыва контекста и недовольств. Нет ситуаций, когда разработчикам нужно изобрести решение, которое, возможно, придётся переделать много раз, потому что кто-то друг друга не понял. Теперь нет недовольств. Нет очереди из ста задач на обсуждение.
Теперь есть: обозначенная проблема, варианты решения, понятные цели и чёткое представление, что делать дальше. Нет стен — есть мосты. И всё это началось с движения на встречу.