«Нам нужны методы статистики для оценки сроков проектов» (Фрагмент главы «Улитки против геморроя или метод "5-почему?»)

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

Ссылка на диаграмму к этому разделу.

— Мы видели твой доклад на конференции о том, как при помощи статистики предсказывать сроки завершения проектов и нам такое нужно. Сможешь нам помочь?
— Я с удовольствием, но почему вы решили, что вам нужны статистические методы оценки проектов?
— Видишь ли, мы ни один проект вовремя выполнить не можем…

«Вовремя» - качественное наречие, для которого мы ищем операциональное определение, то есть описание операции / теста / процедуры, при помощи которых можно убедиться в наличии или отсутствии свойства, описываемого этим наречием.
В данном случае понятно, что «вовремя» - это в «заранее установленное время». И здесь мы сталкиваемся с пассивным залогом, который прячет настоящего субъекта. Поэтому сразу переходим к прояснению этого момента:
— А кто в вашем случае определяет то «вовремя», в которое вы должны завершить проект?
— Мы же и определяем. Поэтому-то я и говорю, что нам нужны правильные методы оценки. Ладно, если бы сроки сверху спускались (хм… опять пассивный залог), а то ведь нет. К нам приходит проект (ага… сам…), мы сами его оцениваем и потом в оценку не попадаем.

Пока не будем работать с пассивным залогом и с тем, как абстрактная сущность «проект» обрела субъектность и пришла к нам. Не это здесь важно, давайте обратим внимание на «не попасть в оценку». В данном случае это интерпретация, интересно, каких фактов?.. Кому-то может показаться, что попал или нет в оценку – это самый что ни на есть факт, но…

— Не попадать в оценку можно по-разному…

Консультант взял лист бумаги и нарисовал две мишени в виде концентрических окружностей.

— Можно так, — изобразил на левой мишени точки вокруг центра, — а можно и так.

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

— И там и там не попали, но, как в том анекдоте, есть нюанс. Какой случай больше похож на ваш?

— Не очень понимаю, как тут провести параллель с проектами, - сказал клиент.
— Я хочу уточнить, как именно вы не попадаете в оценку? Бывает такое, что оценили проект и закончили его раньше, чем оценили?
— Шутишь, что ли?! Нет конечно.
— То есть, у вас ошибка всегда в большую строну? Всегда же?
— Знаешь, если бы у нас была ошибка в меньшую сторону, мы бы не жаловались. Наверное, мы бы вообще это за ошибку не считали.

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

— Определенно внизу.
— Понятно. Наивный подход в этом случае – умножить оценки на поправочный коэффициент, но, что-то мне подсказывает, вы такое уже делали. Возможно, не один раз.
— Всё так. Как в анекдоте, что хороший менеджер всегда умножает оценки программистов на пи пополам. Мы, наверное, приближаемся уже к целому пи а кое-где даже к пи в квадрате.
— Но всё равно не помогает?
— Нет.
— А вы не следили, в какой мере не помогает? По мере увеличения вашего поправочного коэффициента, у вас начинали появляться проекты, завершенные раньше срока?
— Что-то не припомню. Может, что-то и было, но кардинально ситуация не изменилась, конечно.
— Ага, то есть, скорее всего мы тут с вами играем в догонялки: вы увеличиваете оценку, оценка начинает влиять на то, как вы выполняете проект. Влияет, как вы понимаете, не лучшим образом, и в итоге у вас получается самопродалбывающийся прогноз…
— Может, самосбывающийся?
— Нет… Самопродалбывающийся. Вы продолбаете сроки, на какой бы коэффициент их ни умножили.

Было видно, что эта фраза задела руководителя отделя разработки. Да, конечно же пассивный залог смягчает формулировку. Скажи: «сроки будут продолбаны» и ты уже несчастная жертва суровых обстоятельств, а не ответственный за это всё субъект…

— И что нам с этим делать?
— Хорошо. Давай сейчас зафиксируем промежуточную точку, вы сами оцениваете проекты, называете сроки завершения, а потом опаздываете. И здесь есть две составляющие: либо вы как-то не так оцениваете, в чем лично у меня есть сомнения, либо вы как-то не так выполняете проекты. Если бы с выполнением проектов не было проблем, вы бы довольно быстро подобрали поправочный коэффициент и даже если бы продолжали оценивать проекты не точно, начали бы наблюдать ранние завершения, а не только срывы сроков.

— А как мы можем не так выполнять проекты?
— Хороший вопрос. Давайте пойдем по правой ветви этой диаграммы и спросим себя: «Почему мы не следуем заранее составленному плану»? Например, как гипотеза - в самом начале проекта вы работает не так интенсивно. И чем больше у вас запаса по времени, тем менее интенсивно вы работаете.
— Ну нет, это не правда. У нас тут постоянно все работают на пределе. По всем проектам. У нас же постоянно что-то горит.
— По всем проектам… А как часто у вас бывает, что один и тот же человек задействован более, чем в одном проекте?
— Мы считаем, что над каждым проектом должна работать выделенная команда...

Клиенты часто говорят о своих убеждениях так, что их бывает очень легко спутать с реальностью. «Мы считаем, что Х» далеко не всегда говорит о том, что Х действительно имеет место. В этом случае хотя бы была подсказка – фраза «мы считаем». Иногда говорят проще: «Над каждым проектом работает одна команда». И тут как бы простор для формулировки – это описание конечного видения? Светлой мечты? Или повседневной реальности? Будьте готовы уточнять эти моменты.

— Вы считаете? А сейчас как у вас происходит?
— Мы внедряем подход проектных команд…
— Но не везде пока внедрили, да?...
— Ну да, не везде пока.
— А в каких конкретно проектах уже удалось это внедрить?
— Да… по большому счету пока мало где…
— То есть, вы пока только начали?
— Да, только начали.

Нормально. Такое бывает. Как дела? Почти готово. А какое состояние на текущий момент? Скоро начнём. Но мы не руководство, не будем заострять на этом свое внимание и пойдем дальше.

— Я правильно понял, что человек, назначенный на один проект часто может заниматься задачами по другим проектам? Либо вместо основного проекта, либо параллельно с основным.
— Ну, конечно. Бывает так что его основной проект пока не горит, а в другом проекте пожар. И тогда часть команды переключается с одного проекта на другой.

«Часть команды переключается»… Опять пассивный залог и опять не понятен субъект.

—Команда сама переключается? Или это кто-то конкретно принимает решение о том, что нужно перебросить часть команды с проекта на проект?
— Хорошо, я принимаю такое решение. Мне кажется это решение очевидным, когда один проект «горит», а другой «не горит».

Зафиксируем это на диаграмме:

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

1. Какие наблюдаемые явления легли в основу этой интерпретации,
2. На сколько сам процесс интерпретации корректен. Или, как говорят психотерапевты, адаптивен, то есть, не мешает ли он нам достигать наших целей?

— А что значит «проект горит»?
— Ну... горит – это когда мы видим, что точно не успеваем текущим составом уложиться в срок.
— Хорошо, а что тогда «не горит»?
— Ну это когда наоборот.

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

— А вот тут давай по подробнее. Что значит «наоборот»? Это когда вы видите, что успеваете? Или когда вы не видите, что не успеваете? Чувствуете разницу?
— Пока не особо…
— Вот я и говорю – не торопись, чую, это здесь ключевой момент. Если я не вижу, что я не успеваю, это еще не означает, что я успеваю. Если я не вижу причины, почему мы опаздываем это может означать, что я опаздываю, просто по причине, которую увижу позже.
— То есть, я уже опаздываю, но ещё этого не вижу?..
— Именно!
— Погоди! Ведь, может получиться так, что на горящий проект мы перекидываем людей из проекта, который ещё не горит, но уже тлеет?.. Или даже горит еще сильнее, но мы этого не видим?..
— Давай пока такое не будем исключать. Поэтому-то и надо разобраться, что значит «проект горит» и «проект не горит». Вот пример. Если прошло 20% сроков, а сделано всего 10% работы – этот проект горит?
— То есть, на 90% работы у нас осталось 80% времени?.. Да как-то не похоже, что горит. Мы в принципе первую половину времени проекта особо не заморачиваемся с его контролем, так как других проблем навалом. А вот когда половину проекта надо выполнить за четверть оставшегося срока… Вот это уже точно – «горит».

** Звуки сверчков **

— Интересно… Вас в этих примерах ничего не напрягает?
— Ээээ… Нет. А должно?
— Ну вот есть первый проект: прошло 20% времени и сделано 10% работы. Есть второй проект: прошло 75% времени, а сделано 50% работы.
— И что?...
— Давай покажу на графике.

— Смотри, тут видно, что оба проекта опаздывают, но Проект А, в котором прошло 20% времени, но сделали 10% работы опаздывает больше, чем проект В, в котором на половину работы осталось четверть времени. Давай даже продолжим ось времени и посмотрим, когда мы сможем выполнить 100% работы по каждому из проектов:

— Так понятнее?
— Понятнее…

Консультант продолжает:
— Почему же мы тогда считаем, что «горит» Проект B, а не проект A?
— Ну… Это… Как бы там времени много ещё… Но, погоди… Мы же знаем, что команда работает не с постоянной скоростью, и может ускориться и всё такое… Все же и оценка в проекте не точная, и эти 10% выполненной работы могут быть и не 10%, а 7% или 15%... Сам же говорил, что в любых цифрах есть погрешность. И на сколько это будет корректно экстраполировать данные прошлого на будущее?...
— Погрешность есть, это правда. Здесь мы имеем две конкурирующие гипотезы (это подробнее разбирается в разделе 4.6): «проект уже опаздывает» и «проект не опаздывает». В пользу первой у нас есть пусть не точные, но количественные данные, полученные в ходе реальной работы реальной команды. А в пользу второй гипотезы у нас есть что?... Аргумент, что команда ускорится более, чем в два раза плюс надежда на чудо?
— …надежда на чудо... тяжелый вздох, полный сожаления
— А во втором проекте времени мало и надежды на чудо уже нет. Поэтому и приходится отвлекать людей с других проектов, в том числе и тех, которые уже сейчас находятся в менее выгодном положении. В итоге команда А проявляет героизм, чтобы уменьшенным составом не провалить проект окончательно, а в команде В проявляют героизм, чтобы быстро включить новых людей и они успели окупить затраты на свое вкатывание. В общем, да, все при деле, всё горит и у всех есть возможность совершить подвиг…
— Да как так-то?! И что можно с этим сделать?..

Было видно, что руководитель разработки серьезно задумался и по всей видимости, он начал подозревать, что долгое время пытался устранять последствия проблем, которые сам же и создал…

После небольшой паузы консультант продолжил:
— Что ж, давай сейчас изобразим те логические связи, которые удалось выявить. Мы поняли, что одна из причин того, что вы не следуете своим же планам – это руководитель разработки, перекидывающий людей из проекта в проект.
— Но не только же поэтому, у нас и клиенты часто изменения вкидывают, и менеджеры проектов тоже ошибаются!
— Конечно, это тоже важно и эти утверждения займут свои места на нашей диаграмме. Здесь, конечно же проблема сложная и не будет одной ветви, которая является единственной причиной всему плохому. Мы увидим куст причин, каждая ветка которого вносит свой вклад.

Здесь уже консультант осознанно ушел в обезличенные утверждения, чтобы не усугублять чувство вины руководителя разработки:

— Смотри, мы же понимаем, что руководитель разработки не просто так перекидывает людей из проекта в проект. Дело в том, что некоторые проекты выбиваются из плана, а руководитель старается минимизировать количество проектов с сорванными сроками. То есть, если бы проекты из плана не выбивались или руководителю было бы все равно на то, сколько проектов выбьется из графика, то никого никуда перекидывать и не надо было. Так?
— Да, так. А что это за ветки слева?
— Это я зафиксировал дополнительные условия того, что приходится перекидывать людей с проекта на проект. Первое – это то, что ты считаешь это корректирующим действием по умолчанию
— Ну нет же, я же перед тем, как принять решение перекинуть людей ещё… Ну это… Ну да… А что там за второе условие?
— А второе условие – это то, что у вас все люди заняты в других проектах и нет никого в резерве.
— Конечно, меня же за резервы генеральный вые… строго спросит.
— Понятно, мы не будем пока туда идти и анализировать причины, я просто хочу обозначить, что надежда на устранение исходной проблемы может скрываться и в глубине этих веток.

— Но мы пойдем вглубь другой ветки, про то, почему команды некоторых проектов выбиваются из плана. Это же основной триггер к переводу части команды с проекта на проект? По каким причинам команды отклоняются от графика?
— Над этим мы уже думали и выделили три основных группы причин. Первая — это клиенты вносят новые требования. Точнее, для нас это новые требования, но они считают, что это мы не доработали и должны были учесть в самом начале. Вторая группа причин – это мы не учли какую-то часть работы, а третья – мы думали, что будем работать быстрее, чем работаем по факту.
— Прекрасно, давай так и изобразим.

— И да, ты правильно заметил, что это группы причин. В каждый из этих стикеров входят еще масса других стикеров. Но давай сконцентрируемся на чем-то одном. Как думаешь, какая самая частая причина того, что фактическая скорость команды оказывается ниже расчётной?
— Я перекинул людей в другой проект… Из проекта, где нет проблем в проект, где проблемы есть.
— Давай уточним: ты перекинул людей из проекта, в котором не видишь проблем, в проект, где видишь проблемы. А где эти проблемы есть на самом деле…
— Хорошо-хорошо, не сыпь мне соль на рану. Согласен… Я могу случайно взять людей с проекта, где проблемы есть, но я их не вижу и перекинуть на проект, где проблемы менее серьезные, но уже заметные.
— Именно. Но ты же делаешь это не просто так, не из любви к искусству, так сказать.
— Определенно не из любви к искусству.
— Я помню твою фразу: «Первую половину времени мы не заморачиваемся с контролем проекта». Из-за веры в чудеса или еще по какой-то причине мы даже не смотрим на индикаторы неприятностей на ранних этапах проекта. На тех этапах, когда исправить проблемы можно еще относительно дешево. И мне кажется, что таким образом мы можем включить цикл обратной связи: видишь проблемы – перекидываешь людей. Из-за игнорирования индикаторов проблем в проектах на ранних этапах ты берешь людей оттуда и там эти проблемы усугубляешь, а через некоторое время людей приходится перекидывать уже туда, с проектов, которые недавно начали…

— По-моему нам еще пока рано заниматься статистическими методами… Можно я возьму паузу подумать, мне кажется, некоторые проблемы я смогу решить более простыми методами… Хотя кого я обманываю, более простыми методами я смогу перестать создавать проблемы…
_________________
Текущая структура третьей книги