Смотрели фильм «Люди в чёрном»? В нём множество запоминающихся реплик и моментов, смешных и поучительных. В одной из сцен агенты попали в затруднительную ситуацию и не могли понять, какой следующий шаг в расследовании им нужно сделать. Тогда один сказал, что нужно съесть пирог, он поможет.
Меня зовут Сергей Иванов, я из «ВКонтакте для бизнеса», и сегодня предлагаю вам присесть поудобнее и съесть пирог вместе со мной. В процессе мы постараемся вместе разобраться со следующими вопросами:
Что такое планы, откуда они к нам приходят и почему меняются?
Существует ли идеальный процесс планирования?
Какая роль тимлида в этом процессе?
Можно ли отказаться от новых задач и как это сделать?
Как нам помогают гибкие методологии и какие инструменты нам доступны?
Планы и планирование
Откуда приходят планы?
Планы бывают разного уровня. Самые верхнеуровневые я бы назвал стратегией. В большинстве случаев проработка и рождение стратегии продукта происходит на уровне CPO и директоров. Множество факторов влияет на представление о том, куда необходимо двигаться. Много умов задействовано в этом процессе, и только благодаря прозорливости и инициативности наших лидеров мы понимаем, что нам делать и куда двигаться. Считайте, что сверху сидит генератор мыслей или стартапов, который умеет представить стратегию инвесторам. Однако в некоторых случаях инициатива может исходить из команды, тогда она поднимается наверх для оценки, а затем возвращается для проработки и согласования.
То есть на уровне технических и продуктовых команд и управления командами нам задают вектор, видение конечной цели, очерчивают круг нашей ответственности, и начинается работа: ваша команда вместе с продакт-менеджером берётся за разработку, эпики, спринты, итерации, декомпозиции и т. д.
Идеальный процесс планирования: миф или реальность
Как спланировать всё идеально, чтобы всё шло в срок и по плану? Для этого у нас есть определённые структуры и ответственные:
продакт-менеджеры;
аналитики;
архитекторы;
разработчики;
тестировщики;
тимлиды.
Что же, на мой взгляд, является идеальным процессом планирования?
Я считаю, что это процесс, в котором имеются люди для всех необходимых ролей, которые компетентны, действуют прозрачно, обеспечивают высокий уровень коммуникации, выполняют свою работу вовремя и качественно. Звучит просто, не так ли?
Вот он, идеальный процесс:
Продакт-менеджер приносит защищённый, описанный эпик, декомпозированный на понятные и короткие пользовательские сценарии, выстроенные в цепочку и уложенные в примерные слоты по кварталам.
Дизайнер выверяет и утверждает все макеты.
Аналитик прикладывает показатели: текущие и предполагаемые, которые мы будем отслеживать на протяжении всего цикла разработки. Поясняет, какие события нужны и важны на всех этапах, подтверждает корректность всех гипотез.
Команда разработки оценивает сложность:
4.1. Архитекторы предоставляют своё видение реализации с учётом особенностей текущей архитектуры и планируют изменения при поддержке команды.
4.2. Разработчики составляют техническую декомпозицию историй.
4.3. Инженеры по тестированию описывают сценарии.
Каждый раз мы следуем этому алгоритму и кажется, что идеальный процесс — это не миф! Конечно, вы можете добавить ещё ряд важных, на ваш взгляд, этапов, всё зависит от конкретного проекта. Нам нужна лишь почва для размышлений о том, насколько всё сложно и сколько людей задействовано в этом процессе.
Что может влиять на процесс?
Люди могут ошибаться.
Люди могут чего-то не знать, это нормально.
Сотрудник — человек, а не робот, он может столкнуться с выгоранием, спадом продуктивности.
Отсутствие структурности, нарушение процедур и соглашений.
Что происходит, если это влияет на процесс? Тогда мы начинаем «лагать», и это отражается на процессе. Можно ли с этим что-то сделать?
Вы можете заметить, что в вышеописанном «идеальном» процессе не была указана зона ответственности тимлида. Значит, пора поговорить об этой роли.
Возможности тимлида при планировании
Прежде чем говорить о роли тимлида в планировании, следует объяснить, кто такой тимлид в нашем контексте. Это действительно важно, так как механики работы у разных команд могут отличаться. Мне понравилось определение, которое дала одна из моих коллег, я воспользуюсь им. Под тимлидом будем понимать человека, который является линейным руководителем команды разработки. Можно углубиться и начать перечислять возможные карты-матрицы ролей и обязанностей тимлида в разных компаниях при разных подходах, но это отдельная тема для беседы. Так или иначе, у 90% ролей, где есть слова «лид», «руководитель», в обязанностях есть слово «планирование», поэтому и тимлид должен уметь планировать.
Давайте попробуем разобраться, а что же может сделать тимлид, благодаря чему он может положительно влиять на процесс планирования? Ожидается, что:
Тимлид знает про команду: их компетенции, настроение, вовлечённость и прочее.
Тимлид знает, как может завершиться работа в худшем, среднем и лучшем случае.
Тимлид знает, где у его команды проходит граница компетенций и когда нужно искать ресурсы или помощь вовне.
Тимлид контролирует все этапы планирования: вовлекает команду и привлекает внешние ресурсы на каждом из этапов, фиксирует договорённости.
Список можно продолжить, и для каждого из вас он может быть в какой-то степени уникальным.
Какой мы можем сделать вывод? У тимлида есть широкий спектр возможностей, как положительно повлиять на процесс планирования. Однако, как всегда, есть нюансы, как же всё происходит на самом деле. Иногда приходилось слышать такое: «Нашу команду не слушают, нам ставят нереальные сроки, мы не можем нормально спланировать, мы тут выгораем». Бизнес не слушает тимлида? Значит, вы недостаточно убедительны! А как действовать убедительно и эффективно? Давайте разбираться.
Неубедительным, а следовательно неэффективным вы можете быть из-за недостатка информации. Почему так происходит?
Вы не знаете свою команду: вы не погружены в людей, не понимаете степень их выгорания.
Вы не знаете аналитику своей команды: не измеряете lead time, velocity, не анализируете задачи в разрезе категорий сложности. Многое зависит от вашего текущего процесса, но суть всегда такая: нужно уметь подтверждать свою гипотезу реальными числами.
Вы не знаете или не понимаете границы компетенций членов команды, то есть не понимаете, в какой ситуации нужно идти за ресурсами, или просто систематически делаете это в последний момент. Может, у вас, наоборот, слишком много какого-то ресурса и вы не делитесь им (посмотрите, возможно, рядом с вами коллега, которому нужна помощь).
Встречи, которые вы проводите, скучны, не имеют цели. Люди, которые приходят на встречу, не вовлечены. Не все вопросы решаются, тратится много ресурсов впустую, нужны повторные встречи.
Результаты договорённостей не фиксируются, единый источник правды не определён, информация теряется.
Давайте рассмотрим пример. Кто из вас проводит встречи по такому плану?
Ставит цели, которые необходимо достичь, на каждую встречу, где присутствует команда.
Рассылает материалы для подготовки ко встрече заранее.
Управляет встречей и двигает команду к результату (к достижению целей встречи), привлекая всех к обсуждению.
Фиксирует результаты встречи в общедоступном месте.
Скорее всего, на ваших командных встречах:
Один-два человека всегда самые активные.
Есть тот, кто практически всегда молчит на любой встрече.
Есть те, кто на встречах постоянно с выключенной камерой (если идёт речь об онлайн-встречах).
Повестка дня размазана, конкретные цели не заданы:
сегодня грумим новый продукт;
сегодня обсудим процесс планирования;
В конце непонятно, какой результат и где его можно найти позже.
Вы можете сказать, что такое усложнение не нужно. Но в данном контексте речь идёт об эффективности. А что такое эффективность? Для меня это в какой-то мере структурность и системность во всём: в процессах, общении, решении задач.
Представьте, что существует идеальный алгоритм. Если вы его знаете, но делаете по-своему, взяв лучшее — это хорошо. Если вы его знаете, но делаете вопреки — это странно. Если вы не знаете его, не ищете, а просто делаете по-своему, потому что вам так нравится, так сложилось — это глупо.
У любого процесса должна быть структура, которая состоит из элементов со своей внутренней структурой. Если смотреть на процесс планирования как на сеть взаимодействующих ролей, участвующих в процессе, то мы увидим, что сбой одного из элементов влияет на остальные.
Тимлид тоже является элементом структуры, который работает по определённому алгоритму. Как он может повлиять на процесс планирования? Быть последовательным в своих действиях и процессах, чтобы информация, которой он обладает, была весома и убедительна.
Вернёмся к нашим темам и обсудим то, что выбивает нас из мира идеальных процессов, мешает нам правильно планировать: про резко меняющиеся цели или внезапные задачи — «влёты».
Как сказать «нет» новым задачам (спойлер: никак)
Как правильно сказать «нет» внезапным задачам? Правда в том, что не мы выбираем, какие задачи нам делать. Мы не делаем свой проект, а решаем проблемы бизнеса. Мы не можем сказать «нет», потому что должны зарабатывать деньги и приносить пользу.
Так вот, правильный ответ на этот вопрос: «Да, мы никак не можем сказать таким задачам нет, но...». Как правильно говорить «да, но…»? Если у вас есть вся необходимая информация, то в нужный момент времени вы можете понять, как что-то новое повлияет на текущий план, может ли в целом быть рассмотрено и при каких условиях. Вы можете договориться, оперируя фактами относительно текущего положения, и выбрать с бизнесом наилучший взаимовыгодный вариант. Если же у вас нет столь подробной информации, то в глазах бизнеса вы можете выглядеть неубедительно. Может показаться, что вы что-то скрываете, недоговариваете, привираете для личной выгоды. В результате у вас создастся впечатление, что на вас давят и перегружают работой, а это приводит к выгоранию. Но ведь мы этого не хотим, правда?
Повторю свой тезис: мы сами являемся причинами наших бед, всё в наших руках, нужно использовать все инструменты и информацию, чтобы убедительно ВЛИЯТЬ на то, на что мы способны повлиять.
Всегда нужно быть готовыми, что могут прилетать задачи, могут меняться цели или наступить ситуация неопределённости, в которой необходимо будет так же эффективно действовать.
Гибкие методики и тайм-менеджмент команды
Множество современных компаний работают по гибким Agile-методикам. Большинство гибких методик нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов — итераций. Каждая итерация сама по себе выглядит как программный проект в миниатюре и содержит все задачи, необходимые для мини-прироста функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
Хотя отдельной итерации, как правило, недостаточно для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску к концу каждой итерации. По окончании каждой итерации команда пересматривает приоритеты разработки.
Разница в подходах Scrum и Kanban
Хочется слегка затронуть тему Scrum- и Kanban-методов. Есть множество определений и статей, сравнивающих или критикующих их. Мы не будем этим заниматься, нам важно разобраться, как ими пользоваться.
Фреймворк Scrum стоит применять в продуктовой разработке для того, чтобы чаще и быстрее тестировать новые версии продукта и корректировать вектор разработки на основе обратной связи. Работает в условиях неопределённости. Чтобы начать работать по Scrum, нужно сначала создать кроссфункциональную команду и обеспечить её необходимыми ролями: владельцем продукта и Scrum-мастером. Далее необходимо запустить спринты, в течение которых команда создаст кусочек ценности, а вы покажете его заинтересованным лицам и протестируете на пользователях.
Kanban-метод применим для улучшения любых процессов: продуктов и проектов, в том числе при прогнозируемом результате. Он формирует предсказуемый и управляемый поток создания ценности. Kanban позволяет начать с того, что есть сейчас, и не требует создавать условия для его использования на начальном этапе. Возьмите существующий процесс, визуализируйте все задачи и начните потихоньку управлять ими. По ходу действия решайте, что стоит изменить.
Важный момент: не всегда уместно сравнивать Scrum и Kanban, так как Scrum — это фреймворк, а Kanban — это инструмент. Они вполне могут использоваться вместе, дополняя друг друга.
Как правильно имитировать Agile?
Я могу с большой степенью уверенности сказать так: если вы пытаетесь что-то применить, но делаете это не в точности так, как сказано в инструкции, то результат будет отличаться, но необязательно в худшую сторону.
У нас используется подход, который собирает в себе только то, что нужно конкретным командам. Чтобы быть эффективными, мы привносим что-то осознанно и с пониманием того, как это может помочь нам. Тимлиду нужно сосредоточиться не на карго-культе, а на том, что нужно адаптировать, как переиспользовать практики под текущие нужды, и в каждый момент времени задавать себе вопрос: «А эффективно ли всё то, что я делаю, можно ли что-то изменить?»
Чтобы подробнее разобраться в том, как внедрять и работать с Agile, можно почитать эту статью.
Полезные инструменты
Давайте поговорим про полезные инструменты, которые становятся доступны в Agile. Для меня это те инструменты, которые помогают нам следить за разного рода показателями, то есть использовать метрики, которые снимаются в процессе применения этих методологий, чтобы отвечать на вопросы, проверять гипотезы и реагировать.
За чем должен следить тимлид в команде?
Ответ простой: за метриками!
За какими метриками?
Зависит от того, какую информацию мы ищем. В общем случае мы должны воспользоваться числами, чтобы увидеть и отловить недостатки, а не понять на подсознательном уровне, что что-то идёт не так. Они покажут наши лаги, дадут почву для размышлений и анализа. Какие же числа могут быть полезны и показательны? Метрики бывают совершенно разными в зависимости от команды: размер бэклога, размер техдолга, количество багов после релиза и др.
В разных методиках предлагаются разные варианты:
В случае со Scrum — это Velocity: величина, отражающая количество работы, которое Scrum-команда может выполнить за один спринт.
В случае с Kanban — это Lead Time: время от прохождения бизнес-задачей точки принятия обязательств до перехода через точку отдачи обязательств. Чем меньше это время, тем эффективнее рабочий процесс. При этом отдельные этапы могут быть недозагружены целиком, но весь процесс будет работать быстрее.
Подробнее про метрики Scrum и Kanban можно почитать в этой статье 10+ летней давности (хотя актуальности она не потеряла).
Какие инструменты помогут «читать» показатели команд:
Burndown’ы спринта, эпика.
Контрольная диаграмма (Control Chart).
Диаграмма Ганта.
Очень хорошо, если вы уже умеете читать эти графики, строить гипотезы и анализировать. Всё это поможет погружаться в процессы внутри команды и понимать их, реагировать не просто на уровне чуйки, а с помощью цифр.
Думаю, что на первом шаге вам будет вполне достаточно стороннего инструмента, например, Jira или Kaiten. Есть те, кто пилит под себя инструменты, дашборды и прочее. Вам решать, как действовать.
Заключение
Я предлагаю попробовать ответить на вопрос: «Что делать, когда не понимаешь, насколько хорошо команда работает и можно ли сделать что-то лучше?».
Чётко определить цели и задачи команды. Необходимо понимать, что каждый член команды имеет определённую роль, уровень компетенций в этой роли и задачи. Совокупность этой информации может помочь понять, как действовать правильно в тот или иной момент.
Необходимо учитывать и то, какие ресурсы используются командой. Есть ли необходимость в дополнительных ресурсах? Можно ли эффективнее использовать существующие ресурсы?
Стоит проанализировать процесс работы команды. Какие проблемы возникают на разных этапах работы? Следует начать работать с метриками команды. Есть ли у вас инструмент и статистика? Помогает ли это вам определять проблемы? Позволяет ли следить в динамике за показателями? Что вы делаете, чтобы решить эти проблемы?
И, наконец, не стоит забывать о коммуникации в команде. Насколько эффективно взаимодействуют её члены? Можно ли улучшить коммуникацию? Где цепочка коммуникаций нарушается и договорённости не соблюдаются, что является причиной этого?
Помните, что важен не только результат, но и процесс работы команды.
Надеюсь, что у вас появились новые мысли и идеи, а это значит, что пирог сработал. Если нет, не стоит переживать, попробуйте съесть ещё, и, я уверен, решение появится!
