Привет, Хабр!
Я работаю директором проектов в РТК ИТ, уже больше семи лет в ИТ и занимаюсь запуском, развитием продуктов и проектов. За это время я не раз сталкивалась с ситуациями, когда из лучших побуждений принимаются решения, которые в итоге только усложняют работу команде и самому продакту.
В этой статье я собрала часть вредных советов для продактов — ошибки, с которыми сталкивалась в своей практике и которые видела у коллег: от бесконечных встреч и «срочных» задач без контекста, до размытых договорённостей и потери фокуса. Я разберу, почему такие решения кажутся удобными в моменте, к чему они приводят на практике и как можно действовать иначе.
На самом деле допускать ошибки не страшно, главное, как говорил мой папа, когда я получала двойку, «понять за что и как исправить»)
Даже при наличии всех правильных качеств продакт регулярно попадает в типовые ловушки, и именно о них дальше и пойдёт речь.
Так что читайте, комментируйте, делитесь и своими «вредными советами».
Вредный совет №1.
«Зови на встречу всех, ведь кто-то обязательно пригодится, а можно еще и на 8 утра, чтобы со свежей головой рассказали, чем занимаются»
Для понимания проблематики, давайте ответим себе на три вопроса и дальше в каждом вредном совете будем отталкиваться от них.
— Почему возникает желание так сделать?
Всё просто. Чтобы сократить множество взаимодействий, проще собрать всех сразу и распределить обязанности. Если позвать лидов команды на встречу, то можно сразу выяснить стоимость, сроки реализации. Бизнес попросить пояснить свои «хотелки» на всех и закрыть возникшие вопросы у коллег. Если позвать команду от внешней системы, то они смогут обозначить риски интеграций.
— Что происходит в итоге?
Чаще всего времени на такой большой встрече не хватает (а мы знаем, как у всех забиты календари и что больше, чем на час никого не соберешь, а иногда и 30 минут будет удачей). Все блоки реализации не понимают, зачем их позвали и что от них требуется. Все задают вопросы и непонятно, к кому они адресованы. Лиды команд тратят свое время непродуктивно, так как на подобной встрече мог бы присутствовать бизнес-аналитик, кто по итогу и будет оценивать требование в SP. Сам продакт выглядит некомпетентным в вопросе и не может донести нужную информацию до команды и внешней системе. И как итог, после встречи остаются вопросы: кто? что это вообще было? что надо?
— Какие последствия это имеет для команды и сроков?
С таких встреч чаще всего все уходят с недопониманием своих обязанностей. Мои коллеги чаще всего говорит «было интересно, но ничего не понятно». Выяснение дополнительных вопросов может затянуть процесс оценки и вам всё равно придется еще раз и не раз собраться. Команда тратит ресурсы на такие встречи, вместо спринтовых активностей, что как следствие может повлиять на кол-во SP в спринте или сдвиг сроков вывода релизов.
На самом деле «групповые» встречи имеют место быть, но мы стараемся исключать их из своей жизни. Как делаем мы:
1. После получения задачи от бизнеса, продакт изучает требование, задает свои вопросы заказчику или в комментариях к требованию или в личных сообщениях/встречах, просит по необходимости скрины системы, бизнес смысл, видение бизнеса, как должно это все работать, предлагает варианты решения.
2. Если продакту требуется консультация команды, то он встречается только с лидом анализа, не тратя время всей команды. Возможно подключение коллег из Центра компетенций по внешним системам, коллеги смогут сообщить требуется ли анализ или доработка на стороне внешней системы.
3. Требование понятно? Рассказываем его команде и фиксируем сроки оценки. Требование не понятно и ответы бизнеса не помогают зафиксировать договоренности — значит, мы собираем встречу между бизнесом/заказчиком и аналитиком. Задаем уточняющие вопросы, обсуждаем с заказчиком свое видение и предлагаем варианты решений, фиксируем все договоренности в требовании и протоколе, дальше берем задачу в оценку.
4. Если после ответов на вопросы по требованию продакт понимает, что реализация требует подключения команд из других блоков, то мы им пишем в кросс-командном чате о том, что пришло требование и краткую суть планируемой доработки. Их руководитель направления выделяет ответственного продакта и команду, которая ранее делала похожую задачу, интеграцию или процесс. Это помогает быстрее найти ответственного и обратиться, напрямую не тратя много время.
5. Назначается встреча с командами, продакт ответственный за требование рассказывает про требование. Команды задают вопросы или берут время на оценку и анализ.
Из нашего опыта: мы один раз собрали встречу на 30 человек — в итоге все разругались и не договорились ни о чем. Продакту писали во время встречи в личные сообщения вопросы «Зачем на встрече я?», «Почему вы не позвали других аналитиков?», «Я не заказчик, я просто создал требование», «Могли бы сами сначала разобраться» и т.д.
Нам пришлось провести отдельно с каждым блоком свою встречу, пояснить требования, процесс реализации и определить сроки и реперные точки, хоть мы уже и пожалели, что некоторых подключили)
Вредный совет №2.
«Затаись в задаче важной и про сроки умолчи, пусть разгадывают спеку, что поправили в ночи»
— Почему возникает желание так сделать?
Срочные задачи в бэклоге. Смена дат релиза и правка документации в разное время и разными командами. Аналитик не знает кто из анализа другой команды занимается задачей. Большой бэклог и нет кросс-командных чатов или встреч для синхронизации. После анализа согласованных спек вносятся дополнительные правки от бизнеса. Одна команда выводит доработки раньше другой. Ранняя доработка без анализа на стороне другой команды, разработка по спекам без полного анализа.
— Что происходит в итоге?
У одной команды задача в одном спринте, у другой по несогласованной синхронизации в другом спринте.
Ранее подтвержденные договоренности теряют свою силу, т.к. одна команда думает, что уже все разработано, а вторая еще вносит правки.
Сроки сдвигаются, возможно даже увеличивается стоимость работ по исправлению возникшей проблемы.
— Какие последствия это имеет для команды и сроков?
Сдвигаются задачи по спринтам и как следствие сроки по выводу требования.
Команда с РО в экстренном порядке начинает искать замену требования и ресурсы на исправление проблемы.
На самом деле внесение правок в ранее согласованную документацию возможно и довольно частое явление, главное, чтобы все были в одном информационном поле. Как делаем мы:
1. Понедельничные статусы по совместным задачам между командами
2. Ведение графика работ (анализ, тестирование, разработка, вывод в прод) в требовании
3. Если одна из команд вносит правки в спецификации или требования во время анализа и понимает, что есть влияние на работы другой команды, сразу пишет про внесенные правки аналитику или в кросс-командный чат. Это нужно, чтобы сразу подсветить правки всем заинтересованным коллегам.
4. Интеграционное тестирование поможет на последнем этапе также выявить проблему
Из нашего опыта: в одном из проектов у нас было 4 команды из разных часовых поясов и «поймать» коллег из Дальнего Востока было очень проблематично, сроки согласования документации и внесения новых правок затягивались. По итогу мы пропустили важную доработку, пришлось из гарантийного бюджета вносить новые правки и договариваться с бизнесом о новых сроках вывода доработки на продуктив.
Вредный совет №3.
«Добавь побольше задач в спринт, превышай SP, главное, чтобы бизнес был доволен»
— Почему возникает желание так сделать?
Тут несколько моментов по которым у РО появляется желание сделать сверх SP
1. Кажется, задача маленькой и ничего не стоит просто ее добавить, как доп. задачу
2. Срочная потребность бизнеса, инцидент, мелкая правка. Возможно даже давление авторитетом «президента компании»
3. Непонимание вместимости команды
4. Отсутствие планирования
5. Проблема с приоритизацией требований и договоренностей с бизнесом
6. Непонимание всего влияния на следующие спринты
— Что происходит в итоге?
Если убрать все человеческое понимание всего происходящего могут остаться факты:
1. Выгорание команды, они перерабатывают больше и больше. Задачи летят сверх того, что они запланировали на спринт.
2. Возможны выходы в выходные, это также влияет на загрузку команды
3. Недопонимание РО и команды, отсутствие совместного планирования
4. Сдвиги сроков следующих спринтов и сроков для важных задач бизнеса, который возможно и не знал про переносы
5. Ошибки. Команда может пропустить важные проверки, что впоследствии приведет к неработающему функционалу
6. Постоянные переносы задач по спринтам
— Какие последствия это имеет для команды и сроков?
На самом деле для меня самое важное это доверие и понимание того, что моя команда видит и знает, что я «шарю в этой теме». Если бездумно накидывать задачи, я потеряю это доверие.
Добавление задач сверх тоже распространенное явление. И вот что делаем мы:
1. Определяем приоритет задач, которые уже есть в спринте и вновь поступившей
2. Если требуется меняем приоритеты с бизнесом и согласовываем сдвиги сроков по спринтам
3. Делим задачи на срочные (что можно вывести хотфиксом) и на те, которые все же могут войти в дату вывода спринта
4. Смотрим на влияние текущего спринта, так как может поменяться дата вывода. Также смотрим, что будет со следующим спринтом и сможем ли мы сохранить сроки релиза 2 недели или надо увеличивать его или сокращать кол-во задач в спринте
5. Обсуждаем с лидом выход в выходные
6. Ищем ресурсы на новую задачу в смежных командах
7. Проверяем варианты с «костылем» для быстрого и безболезненного решения, которое потом можно поправить в спокойные сроки
8. Общаемся внутри команды и поясняем важность и необходимость сверхзадачи, чтобы команда тоже понимала влияние. Обсуждаем все сложности на ретро и принимаем командное решение, чтобы избежать такое в будущем.
И еще одно, самое важное, — это извиниться, что сейчас был такой непростой спринт и поблагодарить каждого за то, что они сделали в команде. Показать, что РО видит все, что они делают для проекта. Сложные ситуации показывают, как команда может быть с ними справляться, показывает целостность команды и лидерство РО и Лида, их совместную работу.
Из нашего опыта: была у нас в работе очень простая маленькая задача, которую мы взяли поверх основного спринта. Всего 3 SP, а по итогу правки затронули две смежные команды и два спринта правок. Задача казалась простой, но по итогу анализа появлялись дополнительные спецификации, интеграционные функции или процессы, которые требовалось так же править и проводить миграцию данных, чтобы конечным пользователям было удобно использовать функционал. Нервничали все: аналитик, продакт, лид, смежные команды, релиз менеджер, бизнес.
Тут я описала всего лишь три ситуации с которыми может столкнуться РО и его команда в работе. Если такой формат вам будет по душе, я поделюсь еще ситуациями из жизни нашего проекта и буду рада, если вы поделитесь в комментариях своими случаями и как вышли их них. Спасибо!
ссылка на оригинал статьи https://habr.com/ru/articles/1037424/