Управление проектами в картинках

Одна из самых интересных и практичных частей книги Бредемайера - о том, как не дать себя обидеть в разговоре.

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

 Ссылка на карту в формате mmap

В 20 веке Сакичи Тойода придумал интересный способ выяснения истинной причины проблемы: пять раз подряд задать вопрос "Почему?" Теперь этот метод стал частью методологии Six Sigma, и вообще очень известен.

Легче всего продемонстировать этот метод на примере. У вас есть проблема - много возвратов товара от клиента. Поехали:

1. Почему клиенты возвращают товар? Ответ: 90% возвратов из-за дефектов во внешнем виде.
2. Почему возникают дефекты во внешнем виде? Ответ: Дефекты возникают при упаковке товара перед отправкой.
3. Почему возникают дефекты при упаковке? Ответ: потому что их упаковывают неправильно.
4. Почему упаковывают неправильно? Ответ: Потому что они не знают, как правильно упаковывать.
5. Почему нет описания правильного способа упаковки? Ответ: потому что это знал один специалист, и он уволился.

Таким образом, стало ясно, что нужно написать инструкцию по правильной упаковке и научить упаковщиков.

Метод часто подвергается критике, и среди критических замечаний можно выделить следующие:

1. Недостаточно просто спросить "почему?". Нужно задать правильный вопрос, потому что на неправильный вопрос невозможно дать правильного ответа.
2. У всякого следствия может быть несколько причин. Когда вы начинаете разматывать цепочку "почему", вы идете только по одной ветке, и не обязательно, что эта ветка приведет вас к истинной причине проблемы.
3. Когда вы задаете вопрос "Почему?" и отвечаете на него, вы исходите только из своих знаний. Таким образом, если причина лежит вне вашей компетенции, метод не работает.

Для углубленного изучения критики метода предлагаю прочесть статью "What’s wrong with 5-Whys?"

Если у кого-то есть положительный опыт использования данного метода или, наоборот, негативный - милости прошу в комментарии.

Как известно, инструмент должен быть настолько простым, насколько это возможно, но не проще.

Денис Москвин поделился своим простым средством для контроля проекта: таблица в Гугл Докс.

Перескажу в нескольких словах его способ:

1. Проект уже спланирован.
2. В Гугл Докс создается таблица с общим доступом для всех членов команды.
3. По горизонтали отложены кейсы (бизнес-сценарии), по вертикали - подзадачи этого кейса.
4. Красные прямоугольники - то, что еще не сделано.
5. Разработчик сам выбирает, что он делает, и меняет цвет прямоугольника на желтый, указывает свой прогресс (в процентах).
6. Зеленый прямоугольник - завершенная задача.

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

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

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

Если нет цели, то получаем то самое "движение есть, а прогресса нет", что чаще всего бесполезно и печально.

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

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

Первым в очереди на рассмотрение, безусловно, является метод SMART.  Авторство приписывают Питеру Друкеру, гуру менеджмента.

В принципе, ничего особенного в этой теории нет - пять английских букв, удобно запоминать. Хорошие универсальные принципы, из который потом выросла такая теория, как Management by Objectives  и т.п.

Для более глубокого погружения в тему SMART целей очень рекомендую ознакомиться со статьей Keys to smart goal setting. Статья сопровождается красочной и большой ментальной картой, и не смотря на сильный крен в сторону личного целеполагания, заслуживает изучения.

Например, упоминается аббревиатура SMARTFORME, которая добавляет еще пять принципов:

• F (Focused) - сфокусированные: все цели должны быть взаимосвязаны и подчинены достижению некой общей укрупненной цели. Не распыляйтесь.
• O (Optimistic) - оптимистичные: вы ведь хотите достичь чего-нибудь хорошего, верно?
• R (Ready) - готовы к достижению: не ставьте перед собой целей, которые очень сильно зависят от других людей и обстоятельств, которые вы не контролируете. Вы должны быть готовы начать работать над своими целями прямо сейчас.
• M (Meaningful) - наполненные смыслом: они должны иметь для вас значение. Они должны приносить пользу. Бессмысленные цели трудно достичь, да и зачем?
• E (Exciting) - яркие: цели должны вдохновлять. Если цель вызывает у вас зевоту - плохо дело. А вот если вы обдумываете цель даже, когда обедаете, значит, она вас увлекла.

Для того, чтобы познакомиться с общей идеей CCPM (Critical Chain Project Management), нужно обязательно прочесть книгу автора - Элияху Голдрата. Она написана как художественное произведение, а не как учебник, и по-настоящему заставляет проникнуться идеей. Я попробовал сделать конспект книги в виде mindmap (щелкните на рисунок, чтобы увидеть полноразмерную карту).

Конспект книги “Критическая цепь” Голдрата в формате mmap

Попробуйте его рассмотреть - поможет ли он вам понять основные мысли книги?