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

В комментариях к записи о высокоэффективных коммандах Алексей очень настойчиво :) предложил мне сформулировать свои мысли по поводу всех этих “новомодных” западных методологий и того, как применять их в действительности.

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

Что такое стартап? Это бизнес-проект. Инновационная компания, ограниченная в ресурсах, которая хочет создать некий уникальный продукт.

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

Но очень часто человеку нужна помощь и поддержка - и в этом случае вам нужны единомышленники. Вот сейчас, когда написал это слово - “единомышленники”, подумал о том, как интересно оно устроено. Сравните его, например, со словом “сотрудники”. Есть разница, не правда ли?

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

Так вот, есть идея, есть желание сделать продукт, который кому-то по-настоящему нужен. И теперь вы должны этой идеей как бы “заразить” других - именно так работает лидерство. У стартапа должна быть “миссия”, “видение”. Да и у большой компании тоже, конечно. Только она должна идти изнутри, а не создаваться за деньги велеречивыми консультантами.

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

И еще: если можно это себе позволить, то нужно выбирать к себе в проект (или стартап) только тех сотрудников, которые нравятся чем-нибудь, помимо их профессиональных навыков. И когда берешь сотрудника на работу (в проект), нужно понять, ради чего он к тебе идет? Можешь ли ты дать ему то, что ему нужно? Может ли он принести пользу проекту?

Ну что, пока хватит, пожалуй. Жду ваших комментариев и замечаний.

Услышав новость о том, что 4-ая версия PMBOK будет опубликована в конце 2008 года, и что сейчас можно скачать черновой вариант нового PMBOK (если хотите это сделать, поспешите - доступ открыт до 22 марта), решил почитать комментарии западных менеджеров проектов по поводу новой версии.

Итак, Майк Гриффитс пишет о том, что в четвертом издании  PMBOK больше внимания уделено итеративным жизненным циклам проекта (привет гибким методологиям).

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

Тем , кого заинтересовала данная тема, настоятельно рекомендую прочесть дискуссию о противопоставлении PMBOK и Agile на gannthead.com.

Майк Грифитс, специалист по гибким методологиям, опубликовал в своем блоге excel-шаблон для оценки качества сотрудничества внутри команды проекта. Шаблон был разработан Edgardo Gonzalez, и базируется на основе данных из книги “Collaboration Explained“.

Нажмите на изображение, чтобы скачать шаблон в формате xls.

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

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

Итак, перечислим признаки высокоэффективной команды:

1. Самоорганизация

Самоорганизуемая команда, а не “административно-командная”

2. Возможность принятия решений

Команда обладает возможностью обсуждать, оценивать и принимать решения, а не просто исполняет решения, диктуемые извне

3. Уверенность в вИдении и успехе

Участники команды понимают цели проекта, и верят в то, что они, как команда могут решить любую проблему и достичь целей проекта

4. Преданность участников команде 

Участники команды стремятся достичь успеха как команда, а не индивидуального успеха любой ценой

5. Доверие участников

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

6. Коллективное принятие решений

Участники команды занимаются принятием решений, а не следуют авторитарной воле других

7. Единодушие

Участники команды делятся своими мнениями и их мнение учитывается при принятии окончательного решения.

8. Конструктивные споры

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

Во время поисков дополнительной информации о корпоративном стандарте об управлении проектами, нашел сайт консалтинговой компании iTeam.

На их сайте есть раздел “Проектное управление”, в котором есть много (на данный момент - 150) статей по УП.

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

В комментариях к карте уловок “Черной риторики” Бредемайера у нас развернулась дискуссия о применимости всех этих трюков в реальной жизни.

Есть замечательная английская пословица - “Honesty is the best policy”, с которой я согласен на 100%. Она работает всегда, и в управлении проектами тоже. Только те, кто честно и открыто общаются со всеми членами проектной команды,  могут стать настоящими лидерами и руководителями проектной команды. Поэтому может возникнуть вопрос - зачем же Бредемайер написал свою книгу, а я рисовал ее конспект?

Дело в том, что любой проект предполагает  существование конфликта интересов - исполнителя, заказчика, рядовых сотрудников, и т.д. Работа менеджера проекта и заключается в том, чтобы сбалансировать все эти интересы, попытаться прийти к некой “золотой середине”. И когда человек действует в такой агрессивной среде, он должен быть соответствующим образом подготовлен.

Он должен понимать, что по-настоящему нужно спонсору проекта. Он должен понимать, какова доля правды в словах исполнителя о том, что “это несложная работа, я ее за недельку легко сделаю”.

И если он, используя свой опыт и экспертные знания, вырабатывает некое решение, то он должен быть готов грамотно отстаивать его на совещании. Он должен грамотно ставить вопросы, и видеть насквозь те уловки, которые используются против него. “Кто предупрежден, тот вооружен”, помните?

Поэтому, несмотря на столь устрашающее название, “Черная риторика” не предлагает вам поступаться своей моралью и гнуть свою линию во что бы то ни стало, но вы должны быть готовы к тому, что против вас применят какой-нибудь словесный трюк.

Надеюсь, что ничего не упустил. Буду рад дополнительным комментариям.