Стивен Кови и крайний срок

32e415_ussr0381

Я не летчик, и терпеть не могу слово «крайний». Вопрос «Мужчина, вы крайний?» вызывает во мне острый приступ языкового пуризма с выбросом желчи в голосовой аппарат: «Я последний, мадам!».

Но есть и вполне литературные варианты употребление слова «крайний». Например, «крайний цинизм». Или «крайний срок». О сроке и поговорим.

Планерка. Директор ставит задачу, и спрашивает: «Сколько времени Вам понадобится для ее решения?». «Недели две», отвечает исполнитель. «Хорошо, через две недели доложите». Все, переходим к следующему вопросу.

Заносим поставленную задачу в компьютер для контроля. Outlook, Jira, Bitrix24, другой любимый task tracker  – не важно. Вводим название и описание задачи, ставим срок – 26 мартобря. Готово.  Смотрим свойства этой задачи:

мартобря

Все вроде правильно. У каждой задачи обязательно должны быть ответственный, даты начала и окончания. Так нас учил великий Стивен Кови. Не поставил ручками начало – по умолчанию программа подставит сегодняшний день. И когда исполнитель начнет выполнять задачу, он обязан изменить ее статус на значение «В работе». А закончив – поменять готовность на 100%, иначе система задолбает его предупреждениями. Если задача длинная – положено выставлять процент готовности по мере выполнения.

Беда наступает тогда, когда мы свой ежедневный опыт по системе Get Things Done переносим в управление проектами.

Планируем график проекта. Заносим задачи, выставляем даты начала и окончания. Здесь надеяться на начало по умолчанию уже нельзя – не могут все задачи начаться в первый день проекта. Поэтому мы указываем связи между задачами. Получаем красивую диаграмму Гантта (обязательно через два «т», я ведь пурист). 

Далее присваиваем все задачи ресурсам. Закончив, радостно нажимаем волшебную кнопку «Устранить конфликт ресурсов». Опа!

Получили полную фигню. Задачи, как стая бешеных черепах, ломанулись в сторону окончания проекта.

Почему – мы знаем. Любая система управления проектами считает, что длительность задачи – это разность между датами окончания и начала.  И предполагает  по умолчанию, что все отведенное для задачи время исполнитель будет заниматься только этой задачей. Одной. То есть:

Плановые Трудозатраты = Плановая Длительность

Но ведь в большинстве случаев это не так! Как правило, в списке «Что надо сделать» у исполнителя висит несколько задач. С разными приоритетами. А приоритеты еще и периодически меняются – «Бросай все, срочно занимайся вот этим!».

Системы управления проектами предлагают справляться с этой проблемой через установку Процента загрузки ресурса. Длительность задачи – 5 дней, запланированный процент  загрузки – 20%. Перевожу на русский – «Тут работы на день, но у тебя есть неделя, чтобы это сделать».

Помогает ли такой подход предвидеть конфликт за ресурс заранее? Нет, и еще раз нет. Система считает, что исполнитель будет размазывать все работы тонким слоем на весь отведенный им срок. Это неэффективно. Никто так и не делает – и Стивен Кови не велит.

Я уверен – система планирования задач по датам начала и окончания изначально порочна. Это я не сам придумал, это я у Голдратта вычитал в книге «Критическая цепь». Но мой опыт управления проектами это подтверждает.

И в текущей работе по методу Get Things Done, и в управлении проектами надо планировать:

  • Возможную дату начала работы (зависит от готовности предшествующих задач)
  • Трудозатраты (делая реалистичную оценку, без преувеличений)
  • Крайний срок выполнения

Какие выгоды мы получаем при таком планировании задач?

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

Во-вторых, мы получим неискаженную статистику и можем накапливать опыт оценки трудозатрат. Я напомню, в распространенных task tracker’ах фиксируется время выполнения задачи от «взято в работу» до «выполнено». И неважно, сколько еще других задач исполнитель успел сделать за этот период времени.

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

И наконец, нам станет легче выполнять завет не только Стивена Кови, но и наших родителей: «Взялся за работу – доделай ее до конца».

Дмитрий Привольнев

Vera Via Strategy Consultants

Привольнев Д.А

Подружитесь с нами в соцсетях

Фёдор Рагин

Анастасия Сербинова
Яндекс.Метрика