Кейс «Решение проблемы последнего процента»

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

• 1 день = 20%
• 2 день = 40%
• 3 день = … и тут исполнитель понимает, что он нихера ещё и половины работы не сделал, но пишет навскидку 55%
• 4 день = ы-ы-ы... 70% и в лучшем случае начинается торг за вменяемое увеличение сроков
• 5 день = 80%
• 6 день … 

Оставшиеся 20% могут длиться ещё 5 дней. А самый последний 1% - может длиться ещё 5 дней… И получается, что за первые 5 дней исполнитель «выполняет» 80% работы, за вторые 5 дней – ещё 19%, а за последние 5 дней – ещё 1%.

Знакомо? А какие могут быть решения данного кейса? Я знаю два:

1. Отчёт трудочасами (или трудоднями)

Это решение мы использовали с Вадимом Герей при внедрении систем управления проектами.

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

Проценты выполнения, в таком случае, высчитывает сама система (тот же Microsoft Project). А Вы, как проектный менеджер, уже с первых дней выполнения работы видите более-менее реальную картинку.

2. Отчёт по заранее заданным показателям

Это решение использует компания Dragon Oil. И в своё время у меня была задача адоптировать систему УП одной нашей компании под их требования.

Для начала, просто привожу выкопировку DragonOil-овского Scope of Work, а разбор полёта – внизу:

16.5 Шкалы продвижения РАБОТ (для измерения фактического продвижения РАБОТ)

Для каждого отдельного комплекса РАБОТ и единицы РАБОТЫ должен быть использован набор шкал для оценки фактического продвижения РАБОТ. Шкалы степени продвижения РАБОТ должны быть использованы для распределения весовых коэффициентов на всю временную протяженность РАБОТЫ. Фактическое продвижение РАБОТЫ должно всегда базироваться только на физическом приросте объема РАБОТЫ. Фактическое продвижение РАБОТЫ должно рассчитываться на нижнем уровне с использованием нескольких шкал продвижения РАБОТЫ, которые отличаются одна от другой в зависимости от типа РАБОТЫ.

Рабочее проектирование: Накопительные шкалы (по нарастанию) продвижения РАБОТ должны составляться с использованием контролируемых этапов физического прироста объема РАБОТЫ для каждого общего типа документов:

• Начало документа/чертежа - 5%
• Готовность/законченность к рассмотрению (в аспекте между направлениями) - 45%
• Выдача ЗАКАЗЧИКУ для рассмотрения/комментирования - 50%
• Утверждение для проекта/проектирования - 90%
• Утверждение для строительно-монтажных РАБОТ - 100%

Материально-техническое обеспечение: Накопительные шкалы (по нарастанию) продвижения РАБОТЫ должны быть установлены для отслеживания каждой позиции, начиная с этапа запроса и вплоть до доставки и приемки на месте производства РАБОТ:

• Подготовка запроса - 5%
• Выпущено для запроса - 10%
• Выдача заказа на закупку - 20%
• Утвержденные чертежи поставщиков - 25%
• Поставка с завода-изготовителя - 75%
• Доставка и таможенная очистка - 95%
• Доставка и приемка на месте производства РАБОТ - 100%

Строительно-монтажные РАБОТЫ: Накопительные шкалы (по нарастанию) продвижения РАБОТ должны быть установлены для отслеживания изготовления/монтажа до окончательного утверждения/приемки:

• Законченные рабочие чертежи - 5%
• Наличие поставленных материалов и изделий - 25%
• Завершение изготовления компонентов предварительного изготовления - 45%
• Монтаж - 90%
• Испытание и сдача в эксплуатацию - 95%
• Передача - 100%

Фактическое продвижение в выполнении РАБОТ, ни при каких условиях не может оцениваться соотнесением с количеством затраченных человеко-часов. Приведенные выше цифры по оценке продвижения РАБОТ предназначены только для определения хода РАБОТ и не могут использоваться для целей оплаты.

Разбор полётов:

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

3. Дробить задачи, сокращая их длительность

Это решение в FB-дискуссии предложил Стас Выщепан и подтвердил Константин Трунин.

Если речь об ИТ-проектах, то есть отличное решение кейса. Для каждой задачи единственный срок - сегодня (или даже "сделай сегодня и ниипет"), сделал или нет - неважно, в конце дня результат и следующая задача \ корректировка плана.

А если проект длинною в год; да, ещё и пара-тройка десятков ежедневно работающих исполнителей, то чтоб ПМ не "зашился" с декомпозицией задач до одного дня, необходимо использовать делегирование. А делегатов вполне может быть больше одного. Да, и нет смысла расписывать задачи на год вперед, неделя-две - более чем достаточно.

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

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

Но эффект получается потрясающий, вместо "готового на 90% результата", который неизвестно когда будет закончен, вы получаете объективную картину движения проекта.

4. Использовать подход CCPM

Это решение в LI-дискуссии предложил Сергей Потапов.

Проблема "последнего процента" заключается именно в том, что зачастую мы меряем не то. В нашем внедрении CCPM этой проблемы нет, вернее она видоизменена.

Но ключевой вопрос - "для чего нам нужны измерения?" Если выставить счет по "T&M", то действительно нужно мерять "сколько потрачено". Но приводит ли это к "успеху проекта"? Ведь все подходы измерения прогресса "сколько потрачено" направлены на то, чтобы максимально следовать попытке заглянуть в будущее в виде плана. А можем ли мы точно предсказать будущее? К счастью, нет. С этим и связано то, что реальное прохождение задачи всегда будет отличаться от запланированного. А это автоматически означает, что будут "быстрые 20%" и "медленный 1%".

Если важен результат, а не усилия по его достижению, то нужно мерять, сколько осталось до результата! Тогда, если бы исполнитель 5-дневной задачи отчитывался в конце каждого дня:
1-й день - мне осталось до завершения задачи 4 дня
2-й день - мне осталось до завершения задачи 3 дня
3-й день - мне осталось до завершения задачи 4 (!!!) дня...
и тут ПМ подошел бы к исполнителю и задал простой и естественный вопрос: "я вижу у тебя возникли проблемы. Как тебе помочь?"

А) ПМ бы узнал об объективных проблемах не "в последний день".
Б) с бОльшей вероятностью, подключились дополнительные силы и разрулили проблему вовремя.

Важно, сколько осталось до результата. Иначе "мы перепрыгнули пропасть на 99%" :)

5. Обрезание концов

Это решение в LI-дискуссии предложил Alexander Koropec.

На практике ещё применяется обрезание концов: если выполнение работы делает возможным начало следующей связанной работы, ставим 100%, а недостающие переносим на дефектную ведомость. Пример классический: подливка оборудования, небольшие ЖБ-опоры, и пр.
Собственно, метод давно известен в строительстве и специфичен именно для строительства: строительный поток организуется по работам одного типа. Выделяем хвосты в строительный поток, и в значительной степени проблема снимается.