Блоги сообщества аналитиков

Наткнулся на интересную презентацию "Эффективное сочетание компетенций в IT: Project Manager + Business Analyst", Мария Бондаренко, SPMConf-2011.

Да, действительно встречал много случаев, когда Аналитик становится менеджером проекта (ПМ), и выполняет две эти функции и даже был сам в такой роле.

Мое отношение к такой роли (Аналитик-ПМ) двоякое:

• С одной стороны иногда это даже необходимо
• С другой стороны на полноценном проекте один человек совмещать эти две роли не может

Рассмотрим плюсы и минусы данной роли.

Плюсы:

Я достаточно много и активно работаю, так что постов для блога, увы, получается не слишком много. Однако перед 8 марта я был и выступал на конференции Agile Days и на предшествовавшие ей тренинге Хенрика Книберга и сейчас публикую отчеты об этих событиях - как обычно, в базе знаний UML2

• Тренинг Книберга по Agile
• AgileDays-2011

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

Итак, кейс. Вы поговорили с заказчиком по телефону, обсудив некоторый вопрос и вроде пришли к решению. Потому - зафиксировали соглашение документом и запросили подтверждение. Ну и, поскольку особых разногласий не было, а дело вроде срочное - сразу начали действовать, то есть запустилии в работу. А через пару дней - приходит ответ, мысли котором сильно отличаются от того, что устно согласовали.

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

Но, с другой стороны, таких лидеров очень мало. Поэтому строить фирму базируясь на том, что в ней будут именно такие руководители команд - достаточно наивно. Соответственно, разумные люди строят фирмы по-другому. Неразумные, кстати, тоже. Поэтому в реальной жизни можно обходиться гораздо более скромными усилиями, достигнув того же эффекта. А вот об этом там не написано.

Я (и не только) часто задаю вопрос - Почему каждый ИТ проект уникален и почему их нельзя делать как на конвеере?

И вот я наверное нашел ответ на этот вопрос....

ИТ-проект - это по сути сложная Система со своим множеством элементов и взаимоствязей между ними. А вот, что нам сулит такая сложная Система: