Проверка джедайских техник
Стоит ли проджекту читать «Джедайские техники» Максима Дорофеева и какие приёмы из книги могут стать полезными в проектной работе.
«Джедайские техники» Максима Дорофеева вышли в 2017 году, и я прочитала эту книжку практически сразу. Мне довелось перелопатить немало профессиональной литературы, но не каждая книга задержалась в памяти. Всё-таки оперативка у проджекта неплохо справляется с дедлайнами и чужими обязательствами, но для остальной информации ресурсы выделяются по остаточному принципу.
Некоторые идеи Дорофеева я помню до сих пор. Книга посвящена личной эффективности, но отдельные принципы вполне применимы в управлении проектами. Ниже опишу какие из них полезны, где заканчиваются джедайские техники и начинается обычная работа PM.
Мыслетопливо команды
Одна из центральных идей Дорофеева — мыслетопливо, ограниченный ресурс для осознанной умственной работы. На проекте его расходуют не только сложные задачи, но и плохо организованные процессы.
Например, разработчик третий раз уточняет требования, аналитик повторно объясняет согласованную логику, а менеджер снова пересказывает клиенту итоги встречи. Все заняты, но время уходит на восстановление информации. Поэтому стоит проверить, где фиксируются решения, кто отвечает за актуальность требований и почему команда постоянно возвращается к одним вопросам. Иногда хорошая документация экономит больше часов, чем очередная попытка ускорить разработку.
Задача должна быть понятной
Один из полезных принципов книги — формулировать задачи через конкретные действия. Для проектного управления этого недостаточно, но начинать стоит именно с ясности. «Доделать интеграцию» или «разобраться с авторизацией», конечно, прекрасные формулировки, если хочется потом полчаса выяснять, что имелось в виду. Нормальная постановка предполагает ожидаемый результат, необходимые вводные и критерии готовности. Например, вместо «проверить интеграцию» = перечислить сценарии тестирования, указать, где фиксировать ошибки и какой результат считается приемлемым.
При этом принцип ближайшего действия из книги не заменяет декомпозицию и техническое задание. Для сложного функционала всё равно придётся оценивать объём, зависимости и ограничения. Зато конкретные формулировки существенно сокращают количество уточнений.
Приоритеты не ускоряют разработку
У Дорофеева есть знакомое до боли наблюдение:
Можно назначить срок, определить приоритет, сообщить о важности, но нередко это больше влияет на наличие и интенсивность угрызений совести исполнителя, а не на сроки или вероятность выполнения задачи.
В проектах такое встречается регулярно. Менеджер назначает высокий приоритет, ставит дедлайн на завтра и рассчитывает, что задача каким-то образом ускорится. Но новый статус не освобождает разработчику время и не отменяет текущие обязательства. Поэтому срочные запросы требуют пересмотра загрузки и последовательности работ. Иногда приходится сдвигать менее важные задачи, договариваться с клиентом или честно признавать, что предложенный срок нереалистичен. Особенно если «срочно» — единственное обоснование приоритета.
Незавершённые вопросы
В книге часто говорится о том, что нужно фиксировать обязательства и регулярно проверять их исполнение. Для PM это напрямую связано с управлением зависимостями.
Клиент согласовывает макеты, подрядчик готовит доступы, разработчик оценивает изменения. Если всё это просто висит в статусе ожидания, контролировать практически нечего. У каждого вопроса должны быть ответственный, ожидаемое действие и контрольная дата. А при влиянии на сроки уже понятный порядок эскалации. То же касается встреч. После обсуждения фиксируем решения и следующие шаги, назначаем ответственных. Иначе следующий созвон вполне может начаться с повторного обсуждения предыдущего. Очень продуктивно.
Где джедайство заканчивается
При всей полезности чтива, методы оттуда не заменяют проектное управление. Дорофеев помогает работать с информацией, задачами и обязательствами, но планирование ресурсов, бюджетирование, управление рисками и изменениями остаются за пределами этих приёмов. Не советую превращать каждый совет в обязательный корпоративный регламент. Если команда нормально справляется с задачами, внедрять дополнительные процедуры ради соответствия методике довольно бессмысленно. Иногда достаточно изменить формулировку задачи или договориться, где фиксировать решения, вместо того чтобы перестраивать весь рабочий процесс.
На мой взгляд, проджектам «Джедайские техники» читать стоит. Особенно если в проектах задачи возвращаются на уточнение, а одни и те же вопросы обсуждаются по нескольку раз.
Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.