Примечание переводчика ГЛ.
- Тони Риццо – профессиональный консультант, занимается налаживанием сложных, непрерывных, мульти-проектных систем на основе ТОС и, теперь, Lean Project Planning. Пишет статьи и, иногда, заметки, позволяющие облегчить первоначальное знакомство с некоторыми сложными вопросами управления.
- Переводить английские заголовки – врагу не пожелаешь. Особенно, когда подряд более 2 существительных (герундиев) или в начале идёт прилагательное, а затем 2 и больше существительных. Смысл же статьи указал сам Тони в подзаголовке. То же и о переводе Lean Project Planning. Можно, как «Экономичное планирование проектов», а можно – «Планирование экономичных проектов». И то, и другое грамматически верно, да и по смыслу тоже. С одной стороны, создаётся рациональный, эффективный МЕТОД, ПРОЦЕСС планирования, с другой – результатом применения этого метода является Эффективный, экономичный ПРОЕКТ. Если судить по содержанию, то статья вообще должна называться «Создание экономичного процесса экономичного планирования экономичных проектов». Уф!
| |
Теперь читайте и составляйте собственное мнение. В нескольких местах я долго разбирался с тем, кто – кому – что. Если будут сомнения – обсудим.
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 вопросов, - продолжает он.