Гибкие методологии и почему ваша команда дерьмово работает

Сразу оговорюсь, что я не scrum-мастер, agile-коуч, kanban-проповедник или waterfall-ментор. Так что я не буду углубляться в отдельные направления и терминологию, буду допускать допущения и максимально все упрощать, за что сразу прошу прощения у тру экспертов.

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

Гибкие методологии и почему ваша команда дерьмово работает

Сегодня в меню

Бэклог. Что это, как формируется и кто за него отвечает
Спринты и их планирование
PBR’ы, а также когда и для чего они нужны
Ретроспективы и как их проводить
Почему вам вообще это все нужно
Котлетки с пюрешкой

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

Что должно быть для бэклога (в идеале)

Стратегия продукта/компании (куда идем, какую ЦА охватываем, на какие рынки выходим, с какими конкурентами конкурируем). Стретегию формируете не вы и у вас ее скорее всего не будет, так что на ней можно не зацикливаться
Роадмэп продукта. Он формируется на основе стратегии и должен ответить на вопрос, каким образом мы собираемся захватить рынок, одолеть конкурентов и привлечь новую ЦА. Если стратегии у вас нет, то можно самостоятельно изучить что б такого можно хорошего сделать. Это может быть новая фича или раздел, интеграция со сторонним сервисом или просто усовершенствование текущего функционала
Роадмэп подразумевает в себе задачи (что мы хотим сделать) и время (когда мы хотим это сделать), соответственно, нужна приоритизация. Механизм выставление приоритетов может быть и очень простым (потому что я так решил) и очень сложным, с расчетами, исследованиями и аналитической аргументацией. Выбирайте тот вариант, который осилите
У задач должно быть описание, а если команда большая или продукт сложный, то еще аналитика и макеты. Здесь стоит учитывать, что чем выше по приоритету задача, тем детальней и точнее она должна быть описана, а задачи, которые вот-вот попадут в спринт, должны быть кристально понятны всем исполнителям без исключения
В идеале под весь этот процесс должны быть настроены исследования, чтобы понимать, что хотят пользователи и как именно улучшать продукт, а также метрики, чтобы понимать сделали мы по итогу лучше или хуже. Две эти вещи очень-очень важны для продуктовой разработки, но не играют большой роли для построения процессов, так что вы, возможно, не будете знать куда вы идете, но зато будете идти быстро и не будете хромать на обе ноги, а это уже хорошо

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

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

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

Чтобы спринты работали как надо, нужно

Планировать спринт заранее. Если я правильно помню, то по правилам скрама на планирование отводится 10% всего рабочего времени, так что и вам жалеть время не стоит. Чем точнее вы будете оценивать задачи и планировать спринты, тем больше будете успевать в перспективе. Так что потраченные на планирование 5-7, а то и 10 часов окупятся, зуб даю.
Не впихивать невпихуемое. Задачи, которые вы планируете на спринт, должны помещаться туда целиком и выполняться до конца. Если изначальная задача ну никак не влезает в спринт - разбейте ее на задачи поменьше

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

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

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

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

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

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

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

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

Небольшой бонус и пара советов из личного опыта

Если вы хорошо планируете спринты, но вам все портят рандомные влеты, то закладывайте на них время при планировании следующих спринтов
Составьте себе расписание для планирований, ретроспектив, дейликов и прочего и придерживайтесь его. Сделайте их своими ритуалами, не работайте стихийно
При планировании спринта учитывайте загрузку каждого подразделения, а не всей команды в целом. Старайтесь не допускать ситуаций, когда у вас фронты загружены на 10%, а бэки на 110%. Это не совсем по скраму, но проще и эффективней
Для комфортной передачи задач из этапа в этап подготовьте DOR’ы и DOD’ы. Составьте их все вместе, чтобы каждому было удобно. Если не знаете что это
Найдите скрам-мастера. Хороший скрам-мастер принесет больше пользы чем еще один разраб и стоить, скорее всего, будет дешевле
Если вы продакт-менеджер, вовлекайте в процесс работы над бэклогом аналитиков и дизайнеров как можно больше, так шанс на положительный результат в разы выше
Оценка результатов. Здесь я не увидел для себя принципиальной разницы, как, когда и каким составом оценивать результат проделанной работы. Так что решайте сами и действуйте по обстоятельствам
Не беспокойтесь, если первое время все будет идти через жопу, это нормально
Не закапывайтесь в абстракциях, идеологиях и принципах, а просто начните. Помните про принцип Парето: «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»

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

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

А если серьезно, то команда будет работать быстрее и слаженнее, на контроль выполнения задач будет уходить в разы меньше времени, будет проще отчитываться о своих результатах и наглядней видеть прогресс развития продукта. Разрабы будут меньше вонять, реже будут приходить с тупыми вопросами, реже придется отвечать перед начальством за факапы и… НУ ЧТО МНЕ ЕЩЕ НУЖНО СКАЗАТЬ, ЧТОБЫ ВЫ УСЛЫШАЛИ? АЛО! ЭТО НЕСЛОЖНО, Я САМ ПРОВЕРЯЛ!

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

Ах, да, чуть не забыл!