Как навести порядок в хаос-проекте

Неотлаженные процессы, путаница в задачах, команда, где все занимаются всем — обычное дело для стартапа или просто нового проекта. Страдают в таких условиях и продукт, и специалисты (даже если им самим кажется, что всё хорошо). Мы сейчас наводим порядок в одном из таких проектов и хотим на его примере показать, как выстроить работу и почему не всегда нужно слепо следовать методологиям и умным книгам.

Александр Фролков

Менеджер проектов

Когда пора наводить порядок?

Когда видите в проекте пункты из списка ниже:

• задачи приходят не в одну точку: с чем-то идут к тимлиду, с чем-то — сразу к разработчикам;
• задачи противоречат друг другу из-за того, что менеджеры не согласовывают их между собой или нет единого видения проекта;
• работа идёт в режиме «задача пришла — её надо решить»: нет чётких планов, непонятно, что команда будет делать завтра, через неделю, в следующем квартале;
• нет дедлайнов, часто звучит «сделайте в ближайшее время»;
• команда не понимает глобальной цели задач: к чему они ведут, что дадут;
• все объясняют и выполняют задачи по-своему.

У нашего проекта были все описанные выше сложности. Очень тяжело сделать какую-либо оценку пропускной способности команды: сколько задач определённого уровня сложности она может выполнить, в какой период. А разработчики, вместо того чтобы писать код, занимаются всем, вплоть до дискуссий с заказчиками.

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

Как избавиться от хаоса в проекте

Найти ответственного

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

Поэтому для начала хорошо бы найти менеджера, который возьмёт на себя часть ответственности: выстроит процессы по скраму, канбану, XP (или любой другой подходящей методологии), наладит связь с заказчиками, внедрит новые инструменты (ту же доску в Miro, например), назначит пару новых, нужных созвонов. И будет ходить и пушить команду, чтобы все планы и изменения внедрялись в работу, а не потонули в потоке задач через пару недель.

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

Найти проблемы

Не такой простой этап, как может показаться. Вроде команда есть, вроде работает, все чувствуют себя нормально. Ещё и метрики прилично выглядят. Какие у проекта могут быть проблемы?

Те, что вылезают посреди работы. Например, у разработчика закончились задачи — и он не знает, что делать дальше. Или разработчику прислали недостаточно вводных, и он выполнил задачу, «как понял». Я могу выделить несколько маркеров, которые показывают, что в проекте точно есть проблемы (даже если пока их не видно):

• на старте возникает очень много вопросов: «Как должен работать этот продукт?», «Что делает эта фича?», «Кто отвечает за этот проект?» и так далее;
• нет человека, у которого можно всё это спросить (или документации, в которой собраны ответы): Вася знает информацию по этой задаче, Петя по этой, а вот те артефакты, кажется, хранились на диске у Коли три месяца назад;
• нет человека, который собирает и распределяет задачи по сотрудникам;
• текучка кадров и психологическое состояние команды: если люди устали, выгорели, ничего не хотят — это показатель того, что в проекте что-то идёт не так.

Метрики не всегда маркер того, что на проекте всё хорошо. Они могут быть классными. Но благодаря не грамотно выстроенным процессам, а менеджеру с кнутом, который погоняет разработчиков.

Показать людям, что проблемы — это проблемы

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

Например, у нас на проекте в техлида с разных сторон летели задачи: наладить первое, реализовать второе, обсудить и согласовать третье. Он занимался немного не своей работой и был постоянно перегружен. Я пришёл, прямо спросил, нравится ли ему в такой обстановке, предложил забрать такой алгоритм:

• все задачи прилетают в меня, и я провожу бизнес-ревью;
• мы вместе с техлидом проводим техническое ревью;
• мы вместе с техлидом распределяем задачи по разработчикам.

Мы сделали объявление в общем канале, пожили так несколько недель. И снова вернулись к разговору с тимлидом, сравнили работу до и после. Он прочувствовал разницу и понял, что можно не тонуть в задачах.

Назначить созвоны

Они необходимы, чтобы команда понимала, что делает, и находила проблемы на раннем этапе.

В первую же неделю мы ввели дейлики — ежедневные короткие встречи, на которых обсуждаем, кто, что делает сейчас и что будет делать дальше. Обсуждаем вопросы, которые, возможно, успели скопиться. Я как проектный менеджер также стараюсь немного раскрепостить команду — задаю в начале встречи нерабочие вопросы: Как дела? Как выходные?

Так, мы избавились от ситуаций, когда у разработчика заканчиваются задачи, и ему уже нечем будет заняться завтра. А ещё начали налаживать более тесные связи внутри команды (не сразу, но ребята стали лучше узнавать друг друга, перестали бояться и стесняться).

Спустя некоторое время у нас появились ретро. Обычно мы проводим их через спринт, потому что (для более частых созвонов не успеваем собирать темы). На них мы собираем мысли по проекту, обсуждаем их, корректируем, находим новые задачи и назначаем ответственных за них.

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

Добавить визуализацию

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

В итоге получилась большая доска с кучей карточек.

Часть канбан-доски, которой мы раньше пользовались

Это — первая схема релиза на доске Miro

Скрам-доска, которую мы сейчас используем

Так стало понятно, через сколько мы, допустим, выпустим кусочек продукта. К какому числу завершится конкретный этап разработки. Кто за какие задачи отвечает и у кого какая нагрузка.

Поначалу мы работали в основном по принципам канбана, потому что ещё не хватало тесной связи с бизнесом, расстановки задач по приоритетам для бизнеса — важных вещей для внедрения того же скрама.

Найти узкие места и дособрать команду

Тестировщика в команде изначально не было: ребята писали и проверяли код, техлид проводил ревью. К тому же не было ни документации, ни CJM, ни расписанных бизнес-процессов. То есть очень сложно понять, как продукты работают — и как следствие было бы сложно внедрить тестирование.

Но у нас появился новый проект — такой же неописанный. Мы решили сделать его тренировочным: перестроить процессы и внедрить тестировщика (чтобы он в конце стал полноценным членом команды). И затем уже спокойно декомпозировать новые процессы на старые проекты (по аналогии создать документацию для них).

Я как проектный менеджер взял документацию на себя: описывал все требования проекта, обновлял их сразу, как только приходят изменения. И сейчас нас достаточно просто спросить о документации. И получишь паспорт проекта, ссылки на ключевые артефакты, полное описание требований, UserStory.

Ребята, когда поработали с тестировщиком, поняли всю его «полезность»: он находил и передавал ошибки, контролировал качество продукта, пока разработчики занимались новым кодом. И продукт выходил с минимальным количеством багов (а если они выпадали, что виноват оказывался уже не разработчик).

Добавить спринты

Два месяца мы поработали в таком режиме, отлаживали процессы. И после ребята сами предложили перейти на спринтовую систему — им самим было интересно попробовать новое.

Мы создали скрам-доску в Jira, добавили столбцы, которые использовали в канбане (на дейликах они оказались очень полезными: мы движемся по приоритету, открывая стори, и пониманием какая из задач на каком этапе и что с ней происходит).

Параллельно договорились с бизнесом о регулярных встречах по планированию спринта и выставлению приоритетности задач. И теперь бизнес чётко понимает, что будет готово в ближайший спринт. Наконец, внедрили квартальное планирование — так, команда начала понимать, какие цели и задачи нужно реализовать. И добавили ретро спринтов, о котором говорили выше.

Таким образом, проект стал управляемым. Мы стали понимать, что будет готово, в какое время, сможем ли взять больше задач — или уже достаточно загружены. Разобрались, сколько весит задача, какие планы, сколько мы сможем сделать в этом квартале.

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

Послушать свою команду

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

Например, мы вместе решили, что пора перейти к спринтам. Вместе пришли к скрамбану, взяв из скрама и канбана подходящее для себя. Теперь вместе решили попробовать оценивать задачи по числам Фибоначчи

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

И что получится?

Напомню, что было на старте:

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

А теперь мы движемся в понятном направлении, знаем, что будем делать в течение нескольких кварталов, знаем приоритеты задач, умеем делать оценки задач. Задачи приходят в одну точку входа, имеют понятные требования, отлажен процесс тестирования. Работа над улучшениями теперь вошла в повседневность, и ребята не стесняются делиться своими мыслями. И сама команда стала более сплочённой.

На текущий момент мы реализовали практически всё, что хотели. Не хватает пока описанных схем бизнес-процессов и CJM. Далее по такому же формату мы опишем старые продукты.

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