Если же говорить более приземленно, то в такой отрасли, как "управление проектами", "управление" весит 80%, а "проектами" -  20%. В поисках новых источников информации об УП нужно читать не только многочисленные Bodies of Knowledge (PMBOK, SWEBOK и т.д.), но и такие "традиционные" ;) менеджерские книги, как "Искусство войны" Сунь-Цзы, "И-цзин",  "Дао дэ цзин", "Хагакурэ".

Кроме восточных мудрецов, есть чему учиться у людей, которые имеют практический опыт управления другими людьми. И здесь, как ни странно, нужно обратить внимание на деятельность гильд-лидеров  и рейд-лидеров в таких онлайн-играх, как World of Warcraft, Battlefield и так далее. В такой компании ,как Geek Squad (хорошая статья о компании) , сотни сотрудников вместе играют в онлайн-игры. И именно в этой среде происходит тот самый тим-билдинг, нетворкинг, обмен экспертными знаниями, формирование лидерских качеств и т.д. 

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

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

Материалы для дальнейшего изучения:

http://news.cnet.com/8301-10784_3-6048770-7.html

http://joi.ito.com/weblog/2006/03/13/leadership-in-w.html

http://ericgonzalez.wordpress.com/2008/04/03/warcraft-school-of-management/

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

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

В ходе интервью используется два основных вида вопросов, которые необходимо использовать по очереди:

• Открытые вопросы. Позволяют заказчику рассказать все, что ему хочется, например, "Опишите процесс закупки продукции" или "Какие особенности необходимо учесть?" и т.п.
• Закрытые вопросы. Идеально подходят для выяснения деталей, требуют ответа "Да", "Нет" или односложного ответа. Например, "В процессе закупки данного вида товаров участвует только заместитель отдела?" или "Каков объем выпускаемой продукции в месяц?".

При составлении списка вопросов для интервью нужно также готовить уточняющие (drill-down) вопросы, то есть те, которые вытекают из ответов заказчика. Вы получите намного больше пользы от интервью, если к каждому основному вопросу заранее подготовите 3-4 уточняющих. Кроме того, нужно обязательно исходить из того, что уточняющих вопросов много не бывает и задавать их до тех пор, пока у вас не появится необходимая ясность по изучаемой теме.

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

1. Вопросы о данных.
   Необходимы для получения конкретных данных о проекте (как то историческая информация, аналитические обзоры).
   Пример: "Какие формы отчетов используются в кадровом делопроизводстве?"
2. Вопросы о лучшем и худшем.
   Нужны для определения крайних ограничений в сознании заказчика. Позволяют понять, какие преимущества и достижения являются для заказчика наиболее важными, и чего он очень стремится избежать. Также помогают понять, по каким критериям заказчик оценивает успешность проекта.
   Пример: "Назовите самую лучшую черту поставщика вашего основного сырья?", "Что вам больше всего не нравится в работе вашей IT-службы?"
3. Вопросы об определении проблем (defining pain).
   Нужны для того, чтобы заказчик поделился с вами своими проблемами, тем, что мешает ему и вызывает наибольшие сложности. Нужно очень внимательно слушать ответы на такие вопросы, и концентрироваться на решении озвученных проблем, потому что заказчик, безусловно, ожидает избавления от этих проблем. Постарайтесь понять, что являлось источником проблемы, чтобы предложенное вами решение устраняло источник и использовалось клиентом, а не пылилось на полке.
   Пример: "С какими проблемами вы сталкивались при закупке материалов?", "Как вы оцениваете финансовые потери от данной проблемы?".
4. Ситуационные вопросы.
   Опишите как вы понимаете некий сценарий или случай использования, и уточните у заказчика, верно ли вы все изложили. Такие вопросы очень хорошо подходят для уточнения трудно формализуемых критериев. В них часто используется конструкция "Что, если".
   Пример: "Если бы проект окупился в течении 2 лет, вы бы считали это успехом?", "Что, если уровень неснижаемых остатков на складах будет слишком мал?", "Представьте, что ключевой сотрудник уволился. Наши действия?"

• Видео с международной конференции "Управление ИТ-проектами"
• Видео с международной конференции "PM Days 2008"

Ну а в качестве бонуса советую почитать отзыв о семинаре "Управление безнадежными проектами" Эдварда Йордона  (или просто посмотреть презентацию семинара)

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

Когда речь заходит об инструментах, которые доступны аналитику в его нелегком труде по извлечению требований из окружающих, в первую очередь говорят об интервью. Обычно не вопросы задают не просто так, а с учетом определенных процедур, таких, как "5 Почему", "SMART" целеполагание, "Случаи использования" (Use cases).

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

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

Если же говорить о некой общей процедуре сбора требований, то она может быть изображена следующим образом:

Основные принципы, которые помогут провести интервью с пользой, следующие:

• Заложите подходящий фундамент. Нужно обязательно объяснить, что к интервью надо отнестись серьезно, подготовиться и составить список вопросов, провести вводную лекцию о формате проведения интервью.
• Создайте спокойную атмосферу. Вам не нужно сражаться с заказчиком или убеждать его в чем-то. Вам нужно выяснить, чего он хочет.  Если будете слишком жестки, то заказчик больше не захочет с вами встречаться. Найдите золотую середину - не слишком наседайте, но и не забывайте о процедурах проведения интервью.
• Делайте пометки и записывайте комментарии. Это полезно, чтобы вспомнить затем, о чем именно шла речь. Это убеждает заказчика в серьезности мероприятия и вашего отношения к его ответам. Если у вас бывает много типовых проектов, подготовьте шаблоны интервью. Прислушивайтесь к фразам, которые заказчик повторяет несколько раз - они заслуживают уточнения и детализации.
•  Помогайте собеседнику. Это означает, что своими комментариями вы должны показать заказчику, что понимаете, куда он клонит. Это и интонации, и мимика, и уточняющие вопросы.
• Детали, детали, детали. Хорошее интервью - детальное интервью. Не торопитесь, лучше копнуть глубже сейчас, чем быть шокированным в конце проекта. Взгляните на проект глазами заказчика. Помните, что вам придется рассказывать о требованиях вашей команде, подумайте, что они бы спросили.

В следующей части статьи о сборе требований речь пойдет о правильной постановке правильных вопросов. С удовольствием включу в данную запись советы своих читателей.

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

• Peace of Mind (заметки о визуализации, MindManager, и других графических инструментах)
• The MindMapping Software Blog - описание инструментов для рисования карт, в том числе и онлайновых
• Applications of MindManager - большое количество статей о том, как применять MindManager
• MindMapping Everywhere - теория и практика составления карт, автор рисует от руки
• Study Matrix Blog - большие и интересные карты

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

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

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

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) - яркие: цели должны вдохновлять. Если цель вызывает у вас зевоту - плохо дело. А вот если вы обдумываете цель даже, когда обедаете, значит, она вас увлекла.

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

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