Автор: Tony Ryzzo
Перевод: Георгий Лейбович
Источник: http://deming.ru/TehnUpr/TonRiz.htm
Примечание переводчика ГЛ.
|
 |
Lean Project Planning
Создание эффективных планов проектов
- Я попробовала применить к этому проекту метод логических деревьев, - заявила Салли, руководитель проекта нашего клиента. - Я измучилась, пытаясь преобразовать всё это в план проекта. - И сообщает мне, - У меня так ничего и не получилось.
Я поражён. Мы затратили целый день, обучая Салли и её коллег тому, как строить логические деревья. Я был уверен, что им не составит труда превратить эту информацию в полезный план проекта. К счастью, Салли быстро меняет тему, оставляя мне решать эту загадку.
Несколько позже, вместо того, чтобы латать процесс, кажущийся менее, чем удовлетворительным, я решаю начать с самого начала. Мне необходимо найти процесс, обеспечивающий всю необходимую информацию, автоматически исключающий ненеобходимые действия и простой в изучении и использовании. Ещё более существенно, это должен быть надёжный процесс. То есть, качество результата его работы должно быть существенно независящим от пользователя. Разные люди, пользуясь одним и тем же процессом и подавая одно и то же на вход, должны прийти к одинаковому плану проекта.
Легко увидеть, почему ненеобходимые действия попадают в планы проектов. Люди: инженеры, разработчики софта, исследователи, почти все те, кто обычно участвует в планировании, - делают это, внося описания предполагаемых работ в последовательности их реального выполнения. «Я делаю это; я делаю то; а я делаю ещё и это». Именно этот поток описаний работ в последовательности их реального выполнения и вносит в план ненужные, исторически привычные действия. Напротив, мой процесс должен давать lean (экономичный) план, избавленный от ненеобходимых действий. Он должен также давать законченный план, предотвращающий переделку и ненеобходимые задержки.
Но, если процесс планирования, являющийся истино lean (экономичным), должен привести к успеху, требуемые от проекта результаты (deliverables) должны быть определены ДО начала планирования. А здесь есть ставшее притчей затруднение. От многие менеджеров проектов требуют планировать проекты задолго до того, как опредделены требуемые результаты (deliverables). Другие, вроде Салли, регулярно жалуются, что требования (deliverables) к их проекту часто переопределяются. Ясно, что менеджмент и, даже, потребители должны вовлекаться до начала планирования проекта. Если планирование должно стать процессом, тогда, как и в случае прочих процессов, должны быть сформулированы все необходимые входные данные (inputs). Без необходимых данных приложима поговорка: сор на входе - сор на выходе (что съел, тем и ... - прим ГЛ).
Интересно, наш метод реализации задачи улучшается. Обдумывая процесс планирования, я обнаруживаю ещё одно действие, которое менеджмент должен предпринять при выполнении этой работы.
Ну, хорошо! Пора работать над процессом планирования. Считаем, что менеджмент выполнил свою работу, и у менеджера проекта и команды проекта есть полный список проектной спецификации (deliverables). Что теперь? Или, ближе к делу, что сперва, или это что в конце? Я запутался.
- Слушаю,- отвечает Гилберт Скотт на мой телефонный звонок.
Мы познакомились с Гилбертом, учась в колледже. Сейчас он работает аналитиком в Малтико, поставщике сетевого оборудования. Эта должность аналитика предприятия существенно отличается от предыдущей технической работой. Сейчас Гилберт поддерживает прогностическую модель мульти-проектной системы самой Малтико.
Обычно, две головы лучше, когда одна начинает буксовать. Гилберт всегда охотно помогает, давая мне возможность обсудить с ним проблемы. Уверен, что он снова поможет.
- Привет, это я!- говорю я, уверенный, что он узнает мой голос. - Мне нужна твоя голова, найдёшь минуту?
- Конечно,- отвечает он, как обычно. - О чём ты хочешь поговорить?
- Я пытаюсь разобраться с процессом планирования проектов,- говорю я. - Это должен быть процесс планирования в обратную сторону. Но ещё он должен быть простым в употреблении. Интересует?- спрашиваю я.
- Уверен, что да,- отвечает Гилберт. - Нам нужен хороший процесс планирования для своих собственных проектов. Без хороших планов трудно поддерживать наши мульти-проектные модели. Но нашим людям не всегда удаётся свести воедино хорошие планы проектов, - добавляет он.
- У меня та же проблема. У нас в конференц-зале менеджер проекта с командой. У них с собой список требований (deliverables), для выполнения которых они планируют проект.- говорю я. И спрашиваю, - Что первое должен сделать менеджер проекта?
- Это просто, - говорит Гилберт. - Руководитель проекта должен быть уверен, что все понимают требования к результатам проекта одинаково.
Гилберт прав. Первый шаг - ясность. У всех должно быть одинаковое понимание целей проекта. В противном случае, они все потянут в разных направлениях. Но я в сомнениях, что принять за начальную точку. Имеющееся пока явно не помогает увидеть удачный процесс.
- Я согласен,- говорю я Гилберту. - Но давай предположим, что мы находимся посередине процесса планирования. Я хочу описать обычный набор шагов, процесс, который можно использовать для построения каждой части плана проекта. Затем мы можем заняться тем, как начать и закончить процесс,- объясняю я.
- Хорошо. Скажем, мы - два разработчика. Предположим, я работаю на предшествующем этапе. А ты работаешь на последующем, после меня,- говорит Гилберт, рисуя несколько отличную, но более подходящую картину. - Я пока не знаю, какова моя задача, правильно?
Он продолжает, не дав мне ответить.
Какой вопрос первым приходит мне в голову? - озадаченно спрашивает Гилберт.
- Что это! - отзываюсь я. - Первое, что тебе нужно знать, это то, что же я от тебя ожидаю. В противном случае у тебя нет ни малейшего шанса выполнить правильную работу и дать мне то, что мне нужно для моей части проекта, - заключаю я.
- Хорошо. Итак, менеджеру проекта необходимо быть уверенным, что у меня есть ответ на вопрос «Что это?» (то есть, список требований к Гилберту от Тони - прим. ГЛ). В этом есть смысл, - замечает Гилберт. - «Это» описывает моё требование к тебе (сообщить твой запрос - прим. ГЛ), своего рода kanban, - добавляет он.
- Затем руководителю проекта нужно знать, что ты планируешь делать для выполнения моих требований к твоей части проекта (deliverables), не так ли? - спрашиваю я, направляя разговор.
- Принято,- хмыкает Гилберт.
- Тогда следующий вопрос «Какова твоя задача», который превращается в описание задачи для софта управления проектом, - добавляю я.
- Мне кажется, что мы что-то пропустили, - говорит Гилберт.
- Что же это?
- После вопроса «Что это», руководителю проекта нужно знать, кто это обеспечивает, - корректно замечает он.
- Ты прав! - соглашаюсь я. - Менеджеру проекта нужно знать, какой ресурс получает канбан и вырабатывает требование (deliverable).
Чёткое мышление Гилберта просто неоценимо.
- Ты считаешь, что людям действительно следует обмениваться канбан-картами? - спрашиваю я.
- Ну, пожалуй нет! - отвечает Гилберт. - Эквивалентом обмена канбан мог бы быть разговор в кабинете планирования во время планирования проекта, - продолжает он. - Важным является общение между ресурсами. Но если обязать, чтобы разработчики приготовили, скажем, на листке Post-It заметки с описанием того, что им нужно на входе, ну что же, это было бы неплохо, - заключает он.
- Мне это нравится, - сообщаю я. - Это сильно продвинет улучшение общения между разработчикам, ибо в проблемах общения и заложено большинство неприятностей проектов, - с готовностью подтверждаю я. - Используя листки Post-It по аналогии с канбан-картами, менеджер проекта может задокументировать каждую потребность разработчиков непосредственно во время создания плана.
- Таким образом, у нас есть три вопроса: «Что это?», «Кто это выполнит?», «В чём состоит её/его процесс?» - суммирует Гилберт. - Кстати, поставщик на входе и описание процесса этого поставщика должны быть на разных листках Post-It, - констатирует он, и добавляет - Это кусочки информации о процессе, не входная информация.
- Нужно ли нам использовать различные цвета?- спрашиваю я. - Что, если взять белые листки Post-It для входов/выходов и жёлтые - для информации о процессе? - предлагаю я.
- Интересно, - соглашается Гилберт.
- Я думаю, что могу предложить следующий вопрос,- заявляю я. - «Какие ещё существенные вклады тебе нужны от других участников проекта?» - говорю я уверенно.
- Это имеет смысл, - соглашается Гилберт. - Если ресурсу нужны входные данные от других, то он и должен их определить (описать). Другими словами, он и отвечает за точное определение своих kanban карт - заключает Гилберт.
- На белом листке Post-It,- добавляю я.
- А следующий вопрос должен обеспечить проверку на достаточность, - предлагает Гилберт.
Гилберт попал в цель. Слишком часто мы с ним встречаем планы проектов, в которых выпущены недели или месяцы действий ряда людей. Такие проекты всегда опаздывают, так как необходимые вклады в проект, нужные позднее в проекте, не определены до тех пор, пока они кому-либо не понадобятся. В этот момент уже слишком поздно. Простой тест на достаточность в процессе планирования выявит, вероятно, те вклады, которые вовсе не очевидны.
Мне нравится этот подход из пяти вопросов. Но я не уверен, что у нас уже есть все необходимые вопросы.
- Я не вполне удовлетворён третьим вопросом,-- говорю я. - Если мы просим разработчика описать процесс, нам предстоит получить в высшей степени детальное описание процесса. План проекта станет слишком уж детальным, чтобы им можно было воспользоваться, - замечаю я.
- Я думаю, что ты прав,- соглашается Гилберт. - И поэтому, описание задачи, которое мы получим в ответ на вопрос, в действительности несущественно. Это только метка, которая нужна для софта управления проектом. Это могло бы быть что угодно, - отмечает он. - Всё, что нам действительно нужно, это простое описание задания, а не детальный список,- продолжает он. - Я думаю, я знаю, как быть. Давай спросим о последнем важном деле, которое совершает разработчик для выполнения требований. Тогда мы сфокусируем мысли разработчика на конце процесса и избежим чрезмерной детализации,- добавляет он.
- Мне это нравится, - говорю я.
- Итак, у нас есть 5 вопросов, - замечает Гилберт. - И процесс планирования состоит из вопросов и ответов на эти 5 вопросов, - продолжает он.
- Каково это требование (deliverable)? ( Белый листок)
- Кто обеспечивает выполнение этого требования (deliverable)? (Жёлтый листок)
- Какое последнее существенное действие он/она (имеется в виду разработчик - прим. ГЛ) выполнял(а)? (Тоже жёлтый листок)
- Какой осязаемый вклад (в его часть плана проекта - прим.ГЛ) ему/ей нужен от других? (Каждый на отдельном белом листке)
- Являются ли эти вклады достаточными? (Для обнаружения пропущенного вклада, входной информации).
- А когда мы прекратим задавать эти 5 вопросов? - это уже его собственный вопрос. - Как мы узнаем, что мы уже закончили?
Я задумываюсь, и затем меня осеняет.
- Это просто,- говорю я Гилберту. - Когда мы добираемся до разработчика, который может создать самый первый вклад без дополнительных вкладов от кого-то ещё, тогда мы в конце пути, - говорю я.
Гилберт немедленно меня поправляет, - Нет. Мы в самом начале пути, - говорит он.
- Это так, - соглашаюсь я. - Мы в начальной точке плана. Мы в точке, которая связывает настоящее с будущим, - выпаливаю я с воодушевлением. - Именно это и делает план проекта, не так ли? - и я продолжаю, не дав Гилберту ответить. - План проекта является последовательностью логических шагов, связывающих настоящее с желаемым будущим. Мы следуем ему и создаём нечто, что не существует в настоящем, но должно появиться при реализации плана, - заканчиваю я удовлетворённо.
- Ух ты! - восклицает Гилберт. - Мне нравится. У меня приближается заседание по планированию. Я сообщю тебе, как оно протекает, - обещает он. - Но как мне всё это назвать? - спрашивает он.
- Этот подход устраняет излишние, ненеобходимые работы,- начинаю я, - и создаёт полные планы проектов, избегающие дорогостоящих задержек выполнения, вызванных неустановленными при планировании вкладами в проект, - добавляю я. - Это Lean Project Planning - говорю я уверенно.
- Lean Project Planning, - повторяет Гилберт. - Это название может прилипнуть. Я сообщу тебе, как это примут.
Дорогой читатель:
Lean Project Planning является первым шагом на пути своевременного выполнения любого проекта. Lean Project Planning процесс отслеживает поток информации о потребностях потребителя в направлении от потребителя через всю компанию - производителя. В таком варианте процесс достигает ряда очень желательных результатов, устраняя при этом различные источники лишних затрат усилий, времени и денег.
Во-первых, Процесс Lean Project Planning начинается с осуществления живого общения между всеми участниками проекта. Во-вторых, процесс определяет команду проекта и задачи её членов. В-третьих, стимулируя членов команды ясно определить существенные требуемые вклады, этот процесс способствует установлению действительно живого общения. Наконец, Процесс Lean Project Planning вводит проверку на достаточность, которая часто выявляет неучтённы вклады, отсутствие которых не обнаружилось бы в проекте, пока не было бы уже поздно. Таким образом, процесс Lean Project Planning позволяет избегать напрасных усилий, обеспечивая включение в проект только необходимые действия. Процесс также устраняет ненеобходимые задержки, определяя более полно существенные вклады для каждой задачи проекта.
Процесс Lean Project Planning суммируется в 5 вопросах:
1. Каков этот deliverable (что требуется от каждой стадии проекта - прим. ГЛ)?
2. Кто обеспечивает выполнение этого требования (deliverable) (какая стадия, этап, - прим. ГЛ)?
3. Каково последнее существенное действие, выполняемое им/ей (то есть, четко определить окончание этапа - прим ГЛ)?
4. Каковы существенные вклады, нужные ей/ему от других (то есть, что требуется на входе - прим. ГЛ)?
5. Являются ли эти существенные вклады достаточными?
Каждый, кто гогда-либо изучал или применял процесс Lean Project Planning, был более чем удовлетворён его эффективностью. Качество этих планов проектов было превосходным и эти планы не имели неприятных сюрпризов. Работа команд этих проектов, несомненно, улучшилась от лучшего планирования.
Сердечно Ваш
Тони Риццо