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

Этап 1: Выделить ключевые результаты

Что собой представляет «ключевое достижение» (КД)? Это результат, который продвинет вас вперед по проекту. Чаще всего, это:

1. Создание чего-то готового к использованию, например, другой командой (командой заказчика) или пользователями. Ключевое здесь — это готовое к использованию. Отсылаю к исчерпывающему материалу о том, что значит «сделать» (кстати, абсолютный мастрид, который когда-то перевернул мой взгляд на мир).
2. Снятие блокировки, которая мешает запустить другие работы. Блокировка может быть технической — нет доступов для подрядчика, не может приступить к работе, но не только. Например, блокировать прогресс может принятие какого-то важного поворотного решения, отсутствие ресурсов и т. д.

Лучше выбирать КД на довольно краткий горизонт: неделя или две, потому что это позволяет удерживать ритм движения вперед. На более далеких горизонтах поддерживать фокус гораздо сложнее.

Возьмем пример КД:

Функционал модуля расчетов передан заказчику в тестирование.

Этап 2: Спланировать

Последовательность примерно такая:

1. Сформулировать критерии готовности для каждого из КД. В эджайле это называется definition of done (DoD). Признак хорошего ДоД — при прочтении его у вас рисуется в голове картинка.
2. Согласовать эти критерии с ключевыми заинтересованными лицами, например с командой, которой вы передаете результат. Лучше всего — когда это делается на совместной сессии планирования.
3. Сформулировать открытые вопросы, без решения которых невозможно достичь этих результатов.
4. Накидать задачи для достижения КД и решения открытых вопросов.
5. Распределить сроки и ответственность.
6. Запланировать встречи на неделю. Один из распространенных факапов, кстати: забыть о том, что календарь ключевых людей может быть забит на несколько дней вперед. Тысячу раз так факапил(((
7. Идти фигачить, хватит уже планировать.

В нашем примере ДоД может быть таким (иллюстративно):

Функционал модуля расчетов передан заказчику в тестирование.

1. Функционал протестирован и перенесен на прод

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

3. У пользователей забито время в календаре, когда они будут тестировать (согласовано с их руководителем)

4. Поставлено демо

Я специально выбрал этот пример, потому что часто РП забывают, что накатить функционал мало, надо еще и передать его в тестирование/ в эксплуатацию. Но, на самом деле, можно вычеркнуть ИТ и аналогично описать разработку документов, запуск продаж и т. д.

Этап 3: Сфокусироваться

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

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

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

Система должна позволять:

1. Легко отделить ключевые результаты от задач по их исполнению, например, быстрым фильтром или разными представлениями. Чтобы посмотреть ключевые результаты на неделю должно уйти не больше 20 секунд.
2. Легко (меньше 30 секунд на доступ к этой информации) посмотреть только задачи, относящиеся к одному ключевому результату. При этом должны быть наглядно показаны: сроки, ответственные, и статус этих задач. Выполненные задачи не болтаются вперемешку с актуальными. Можно оценить отклонение от плана или понять, что член команды сигнализирует о проблеме.
3. (Желательно) Можно посмотреть задачи, сгруппированные по ключевым результатам.
4. (Желательно) Легко посмотреть только задачи, относящиеся хоть к какому-либо ключевому результату, или не относящиеся. Очень прочищает мозги, когда включаешь этот фильтр и понимаешь, что 60% задач не ведут тебя к конкретному результату. Что-то сродни сдвигу парадигмы.

Естественно, есть и остальные требования к системе, что она должна быть удобна, функциональна и пр.

Забегая вперед, скажу, что можно настроить такую систему:

• В Джире, правда с п.2 будет проблема: потребуется доп. плагин (кому надо — пишите, скажу название).
• В гуглдоке или в экселе. С определенной долей кривизны и ограничениями юзабилити, но тем не менее. Самый бюджетный и «быстрорастворимый» вариант.
• В Ноушене. В Ноушене хорошо получается, на моем Бусти есть шаблон. Опять же, пишите.
• В Coda.io. Не самая пока известная система, но очень мощная. Правда, конкретно работа с ключевыми результатами мне нравится меньше, чем в Ноушене. У меня на Бусти есть шаблон.

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

Да, кстати — подписывайтесь на меня в Телеге, если еще не.

Под «регулярным управленческим совещанием» я имею в виду встречи типа планерок, стендапов, управляющих комитетов и т. д. Цель такого совещания — рассмотреть четко определенный круг вопросов и принять по ним управленческие решения. При этом вопросы относятся к достижению целей в управляемом периметре.

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

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

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

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

Другой пример. На планерке обсуждаем календарный план проекта. Зависли где-то посередине на спорном вопросе. Совещание заканчивается, участники говорят: «Сорри, убегаю на следующее совещание». Мы не обсудили половину плана, а там как раз отклонения. Решение по ним откладывается до следующей планерки, потому что у всех график плотный, никого посреди недели не выдернешь.

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

Придерживаться регулярной повестки мне очень помогала типовая повестка в виде чек-листа на гугл формах.

В чем прикол:

1. Содержит все координационные вопросы, ничего не забудешь. Кажется мелочью, но когда тебя с утра перед встречей уже успел нагрузить заказчик возмущенными комментариями по поводу вчерашнего релиза, это очень помогает.
2. Не надо вспоминать, что надо обсудить. Больше «мыслетоплива» остается на содержательные задачи. Также можно запилить ссылку на относящиеся к вопросу системы/разделы, и это просто удобно.
3. Делегируема: любой член команды может проводить стендап.
4. Содержит опыт команды: дополняется по итогам всех «факапов».

Сегодня расскажу про одну очень простую, но невероятно эффективную технику «сделывания» дел в организации.

Она настолько элементарна, что вы можете отмахнуться от нее: неужели это может работать? Дайте ей шанс, и вы удивитесь, насколько такие простые решения могут быть эффективны.

Начну с одного сценария, затем посмотрим, как этот прием работает в других вариантах.

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

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

Почему это работает?

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

Неочевидный бонус этого приема: в общении с людьми вы не просите их выполнить задачу. Вы просите их всего лишь дать актуальный статус, какой бы он ни был. Это сильно меняет ваш разговор с ответственными, ведь если вы просите сделать задачу, есть куча отмазок: загрузка по основному виду деятельности, «обязательно сделаю сегодня вечером» каждый день, и т. д. Но когда вы просите просто дать статус, это можно сделать или мгновенно, или очень быстро (если вы рассылаете отчетик). При этом у вас железобетонная, очень справедливая аргументация: «Чувак, я понимаю, что ты очень занят. Нет вопросов. Мне надо всего лишь собрать статус, ведь я отвечаю за эту задачу».

А там уже включается социальная психология. Кроме того, сводный отчет легко эскалировать: это факты, а не «все козлы, я не виноват, что все просрочивается». Вы можете даже помогать ответственным: «О, парень, у тебя что-то все красное уже вторую неделю. Вижу, ты завален. Давай я помогу тебе занести руководству мысль, что ты перегружен...» Главное, говорите это искренне, без злорадства ;)

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

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