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

Так пусть говорят что делают

В первую очередь, такая ситуация лишает вас рычагов управления — непонятно, как на проекте скажутся те или иные действия, непонятно какие управленческие решения нужно принимать и как их потом внедрять. И первое, что приходит в голову — давайте всех остановим и заставим объяснять каждый свой шаг, докладывать о каждом действии, давайте каждое утро и каждый вечер будем проводить миттинг и подробно разбирать каждый вздох. К чему это приведет? К парализации всего процесса. У вас и так много задач и мало ресурсов, а тут вы еще грузите команду непосильной ношей отчетности. Что же делать?

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

Шучу, конечно. Это как раз не поможет точно. Тем более, что виноватых может и не быть вовсе. Любые процессы имеют тенденцию деградировать — это их общее фундаментальное свойство. Если вы настроили какую-то систему, а потом отпустили рычаги управления и оставили вариться в своем соку, то рано или поздно, но все вернется к хаосу. Это энтропия, которая всегда растет.

Более того, желание найти виноватого есть не только у вас. Если спросите свою команду, то у каждого есть объяснение — плохой предыдущий руководитель; плохой бэкенд/фронтэнд/дизайн — ничего не успевают; ужасно сложный проект за очень мало денег, поэтому ни на что не хватает. И любая из этих убежденностей, не зависимо от того, полностью она высосана из пальца или имеет под собой какую-то основу, портит ваши процессы еще больше. Отбросить контекст в один момент не получится. О том, как над этим работать, поговорим в другой раз.

С чего начать?

Начните с поиска того процесса в проекте, который и так происходит и оставляет следы. Например, это могут быть пул-реквесты для команды разработки — они происходят и так, а в Гитхабе/Гитлабе/Битбакете есть все инструменты, чтобы видеть сколько их выставлено, сколько открыто и сколько прошло. В других ситуациях, это могут быть новые макеты, которые появляются. Или тест-кейсы. Методы АПИ, если они заносятся в Постман/Сваггер. Любой из этих процессов можно достаточно просто привязать к прогрессу — попросить выбрать какой-то нейминг, чтобы вы понимали что это за реквест/метод/макет/кейс. Можно на первом этапе перейти на язык этих метрик — «когда ты сделаешь пул-реквест» вместо «когда будет готова такая-то фича».

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

Окунитесь в проект

Второй метод, который я предлагаю — нырнуть с головой в какую-то задачу. Прямо закатать рукава и взяться запилить фичу. Не обязательно самому и в одиночку — можно в паре с разработчиком/дизайнером. Но обязательно поучаствовать в каждом этапе. Смысл этого упражнения совсем не в том, чтобы ускорить проект за счет личного вклада. А в том, чтобы пройти самому по всему процессу и понять, как можно с наименьшими затратами сделать результат очевидным. Часто оказывается, что коммиты/ветки/реквесты/макеты/кейсы легко привязываются к задачам. И вот уже у нас есть шанс из предыдущего состояния «слежу, за чем могу» перейти к отслеживанию задач.

Дробите задачи

Идеальная задача занимает суммарно от 2-х до 6-ти часов. Но при этом имеет самоценность и видимый результат. Это не так мало, чтобы потонуть в потоке, ведь получается что в неделю один человек делает около десятка задач такого размера — это количество вполне может поместиться в “оперативной памяти”. Ну а команда из пяти-семи человек вполне сможет пройтись по списку недельных задач за час в формате «что-как-когда-какой результат».

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

Упростите митинги

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

• Введите регламент. Он должен быть реалистичным и вам придется следить за его выполнением
• Автоматизируйте сбор необходимо информации ко встрече. Например, настройте отдельную доску в Джира куда автоматом будет собираться вся информация, нужная на созвоне
• Если вопросы, которые вы будете задавать требуют обдумывания, то вышлите их адресно и заранее. По возможности, вместе с вопросом пришлите заготовку ответа — так исполнителю будет проще понять чего вы от него хотите
• Не допускайте споров

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