Гибкие методологии и почему ваша команда дерьмово работает
Сразу оговорюсь, что я не scrum-мастер, agile-коуч, kanban-проповедник или waterfall-ментор. Так что я не буду углубляться в отдельные направления и терминологию, буду допускать допущения и максимально все упрощать, за что сразу прошу прощения у тру экспертов.
Технически, выстроить процессы в команде — ультрапростая и примитивная задача, с которой справится кто угодно. Никакого креатива не требуется, никаких додумываний и изобретений велосипедов. Достаточно придерживаться основных принципов, чего никто почему-то не делает
Сегодня в меню
- Бэклог. Что это, как формируется и кто за него отвечает
- Спринты и их планирование
- PBR’ы, а также когда и для чего они нужны
- Ретроспективы и как их проводить
- Почему вам вообще это все нужно
- Котлетки с пюрешкой
Бэклог
В первую очередь — это приоритезированный список задач по продукту. С ним команда и должна будет в итоге работать.
Что должно быть для бэклога (в идеале)
- Стратегия продукта/компании (куда идем, какую ЦА охватываем, на какие рынки выходим, с какими конкурентами конкурируем). Стретегию формируете не вы и у вас ее скорее всего не будет, так что на ней можно не зацикливаться
- Роадмэп продукта. Он формируется на основе стратегии и должен ответить на вопрос, каким образом мы собираемся захватить рынок, одолеть конкурентов и привлечь новую ЦА. Если стратегии у вас нет, то можно самостоятельно изучить что б такого можно хорошего сделать. Это может быть новая фича или раздел, интеграция со сторонним сервисом или просто усовершенствование текущего функционала
- Роадмэп подразумевает в себе задачи (что мы хотим сделать) и время (когда мы хотим это сделать), соответственно, нужна приоритизация. Механизм выставление приоритетов может быть и очень простым (потому что я так решил) и очень сложным, с расчетами, исследованиями и аналитической аргументацией. Выбирайте тот вариант, который осилите
- У задач должно быть описание, а если команда большая или продукт сложный, то еще аналитика и макеты. Здесь стоит учитывать, что чем выше по приоритету задача, тем детальней и точнее она должна быть описана, а задачи, которые вот-вот попадут в спринт, должны быть кристально понятны всем исполнителям без исключения
- В идеале под весь этот процесс должны быть настроены исследования, чтобы понимать, что хотят пользователи и как именно улучшать продукт, а также метрики, чтобы понимать сделали мы по итогу лучше или хуже. Две эти вещи очень-очень важны для продуктовой разработки, но не играют большой роли для построения процессов, так что вы, возможно, не будете знать куда вы идете, но зато будете идти быстро и не будете хромать на обе ноги, а это уже хорошо
Также, нужно понимать, что за бэклог отвечает продакт-менеджер. Именно он в первую очередь должен быть заинтересован в его составлении и исполнении, а помогают ему в этом аналитики и дизайнеры.
Вся подготовительная работа по описанию задач, составлению аналитики и отрисовке макетов — тоже работа. Ее нужно учитывать в процессах, закладывать время, планировать и тд.
Спринты.
Спринты, в сухом остатке, — это просто отрезки времени, на которые делится работа команды. В общем-то все. Нужны они в первую очередь для того, чтобы команда не теряла ощущение времени закапываясь по уши в конструирование космических кораблей, а также для более наглядного отслеживания прогресса.
Чтобы спринты работали как надо, нужно
- Планировать спринт заранее. Если я правильно помню, то по правилам скрама на планирование отводится 10% всего рабочего времени, так что и вам жалеть время не стоит. Чем точнее вы будете оценивать задачи и планировать спринты, тем больше будете успевать в перспективе. Так что потраченные на планирование 5-7, а то и 10 часов окупятся, зуб даю.
- Не впихивать невпихуемое. Задачи, которые вы планируете на спринт, должны помещаться туда целиком и выполняться до конца. Если изначальная задача ну никак не влезает в спринт - разбейте ее на задачи поменьше
- Проводить дейлики/стендапы. Не ленитесь собираться командой на 10-15 минут каждый день, чтобы обмениваться новостями. Самый простой способ — рассказать, что делал вчера и что планируешь делать сегодня. Таким образом получится избежать глухого телефона и просранного времени в процессе работы над задачами. Не разглагольствуйте слишком много и не выносите на обсуждение ничего лишнего, для этого лучше выделить отдельное время
А главное, помните, что спринты - это вотчина команды, а не менеджера, поэтому разработчики должны отстаивать адекватные планы, а дейлики не должны превращаться в отчетность для руководителя. Менеджера не особо касается, что там и как происходит на внутренней кухне, ему достаточно просто фасилитировать.
Ретроспективы
Это хороший способ собрать фидбэк с команды и провести разбор полетов. Проводится ретроспектива в конце каждого спринта. Инструмент очень простой и действенный. Отвечает за его организацию и проведение продакт-менеджер или скрам-мастер команды.
Чтобы нормально провести ретроспективу надо
- Собрать (не у команды, а) командой обратную связь в двух категориях «что было хорошо» и «что нужно улучшить». Не стесняйтесь говорить, что думаете, но и хамить и оскорблять коллег не стоит. Старайтесь сделать так, чтобы высказался каждый, будьте дружелюбны
- Убедиться общим решением, что выписанные вами проблемы или хорошие практики действительно имеют место быть, а не являются субъективщиной или галлюцинацией
- По каждому тезису в каждой категории нужно принять решение, нужно и можно ли что-то с этим делать. Если это хорошая практика, то ее можно развить и поддержать, а если плохая, то избавиться от нее или сократить ее влияние
- По тем тезисам, которые требуют от вас активных действий нужно провести мозговой штурм и придумать план действий - как решить проблему или закрепить хороший результат
- По итогу у вас получится список «фоновых» задач, которые помогут улучшить работу вашей команды. Для этих задач нужно обговорить сроки и ответственных, чтобы вся ретроспектива не прошла в пустую
- Следующую ретроспективу нужно начинать именно с обсуждения задач, которые вы определили на предыдущей ретроспективе, чтобы сверить статусы и оценить прогресс
В общем прекращайте ныть, закатывать истерики и вонять на созвонах и в чатах, лучше решайте все проблемы именно на ретро. А еще задачи, которые вы сформировали после ретроспективы не имеют отношение к бэклогу продукта, так что идут фоном, не встревая в основной процесс разработки.
PBR
По-нашему «уточнение бэклога продукта», а именно - созвоны, которые проводятся во время спринтов для уточнения (тут внимательно) будущих задач. Как я писал ранее, задачи, которые вот-вот отправятся в спринт, должны быть кристально понятны всем исполнителям, поэтому технически или логически сложные задачи лучше обсуждать заранее, чтобы срок их исполнения можно было оценить, а сами задачи запланировать в спринт не обосравшись.
Если вы ожидали тут списка, то его не будет. Все что нужно - это раз в какое-то время собираться с командой на небольшие созвон и разбирать задачи из бэклога на предмет понятности и полноты описания. Из важного стоит отметить, что эти созвоны проводятся в интересах продакт-менеджера, поэтому именно он должен приносить задачи на разбор, отвечать на вопросы и проявлять инициативу.
Небольшой бонус и пара советов из личного опыта
- Если вы хорошо планируете спринты, но вам все портят рандомные влеты, то закладывайте на них время при планировании следующих спринтов
- Составьте себе расписание для планирований, ретроспектив, дейликов и прочего и придерживайтесь его. Сделайте их своими ритуалами, не работайте стихийно
- При планировании спринта учитывайте загрузку каждого подразделения, а не всей команды в целом. Старайтесь не допускать ситуаций, когда у вас фронты загружены на 10%, а бэки на 110%. Это не совсем по скраму, но проще и эффективней
- Для комфортной передачи задач из этапа в этап подготовьте DOR’ы и DOD’ы. Составьте их все вместе, чтобы каждому было удобно. Если не знаете что это
- Найдите скрам-мастера. Хороший скрам-мастер принесет больше пользы чем еще один разраб и стоить, скорее всего, будет дешевле
- Если вы продакт-менеджер, вовлекайте в процесс работы над бэклогом аналитиков и дизайнеров как можно больше, так шанс на положительный результат в разы выше
- Оценка результатов. Здесь я не увидел для себя принципиальной разницы, как, когда и каким составом оценивать результат проделанной работы. Так что решайте сами и действуйте по обстоятельствам
- Не беспокойтесь, если первое время все будет идти через жопу, это нормально
- Не закапывайтесь в абстракциях, идеологиях и принципах, а просто начните. Помните про принцип Парето: «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»
Зачем вам это надо
На самом деле для рядовых работяг по типу нас с тобой это очевидно нужно, чтобы нормально выполнять свою работу, а не жить в ебаном хаосе, так что я тут даже комментировать не буду.
Зачем это нужно продакт-менеджеру? Чтобы такие работяги как мы нормально делали свою работу, а не жили в ебаном хаосе. Ну пожалуйста…
А если серьезно, то команда будет работать быстрее и слаженнее, на контроль выполнения задач будет уходить в разы меньше времени, будет проще отчитываться о своих результатах и наглядней видеть прогресс развития продукта. Разрабы будут меньше вонять, реже будут приходить с тупыми вопросами, реже придется отвечать перед начальством за факапы и… НУ ЧТО МНЕ ЕЩЕ НУЖНО СКАЗАТЬ, ЧТОБЫ ВЫ УСЛЫШАЛИ? АЛО! ЭТО НЕСЛОЖНО, Я САМ ПРОВЕРЯЛ!
А еще, кстати, процессы являются хорошим маркером на собеседовании. Если потенциальный работодатель не может нормально и структурировано рассказать о том, как устроены процессы в команде, а на вопросы о внутренних флоу ты слышишь в ответ только «Эээ… Ну эта… У нас там… Спринты двухнедельные и атмосфера стартапа», то будь готов к работе в хаосе. Удачи!
Ах, да, чуть не забыл!