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

Текущая версия на 23:15, 6 апреля 2012

Аннотация

Докладчик

Мария Бондаренко

Введение

В настоящее время в IT сообществе немаловажным является вопрос эффективного подбора персонала. В данном докладе рассматривается один из аспектов данного вопроса – а именно, возможность и необходимость сочетания роли менеджера-аналитика (PMBA).

Тезисы

• Какие проблемы могут возникнуть, если менеджер проектов не обладает компетенциями аналитика, и, наоборот, аналитик – компетенциями менеджера
• Для каких проектов такое сочетание наиболее оптимально
• Руководитель проектов и бизнес аналитик – точки соприкосновения и разделение ответственности
• Ключевые факторы успеха проектов, на которые влияет менеджер-аналитик
• Необходимые личностные характеристики менеджера-аналитика и как их развивать
• Ключевые знания и навыки менеджера-аналитика и их применение на различных этапах проектов
• Базовые инструменты менеджера-аналитика (то, что есть под рукой, vs специализированное ПО)
• Пошаговый план действий, как стать менеджером-аналитиком в IT

Видео

Оцените доклад «Эффективное сочетание компетенций в IT: Project Manager + Business Analyst (Мария Бондаренко, SPMConf-2011)»:

•  Отлично!
•  Хорошо.
•  Нормально…
•  Не очень :(
•  Просто хочу узнать результаты.

Слайды

Примечания и отзывы

…А потом послушал Марию Бондаренко – смелый доклад о сопряжении роли ПМ и бизнес-аналитика (тема чрезвычайно близкая мне и вызвавшая бурное оживление в зале). Мария, к тому же, представляла и новый проект pm-ba.ru за развитием которого я решил следить с большим интересом.

©

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

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

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

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

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

Плюсы:

• Менеджер проекта больше в курсе темы проекта и может более эффективно работать с Заказчиком и своей группой
• Менеджер сразу может оценить запросы Заказчика и вопросы своей группы
• Меньшие затраты на проект

Минусы:

• Полноценно собирать, анализировать и писать требования он просто не успевает
• Если успевает полноценно работать с требованиями, то сразу проваливается сам менеджмент проекта
• Переработки
• Не может учавстовать в нескольких проектах

Поэтому Аналитик-ПМ может эффективно ИМХО работать только на следующих проектах:

• Предпроектное обследование
• Небольшой проект с несколькими исполнителями
• Является ведущим аналитиком, принимает участие в сборе требований и ревьюировании конечных документов

©

⚓

Эффективное сочетание компетенций в IT: Project Manager + Business Analyst (Мария Бондаренко, SPMConf-2011)

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

А ведь это серьезный тренд, — универсальные менеджеры проектов и даже проектные офисы, которым пофиг, чем управлять. Да, скорее всего они просрут все полимеры, возможно спецы сожмут зубы, и сделают проект несмотря на их менеджмент, после чего будет, как обычно, «наказание невиновных и награждение непричастных». Т.е. роговолосый менеджер из Dilbert™-а еще ничего — он достаточно безобиден, и даже позитивен. Но обычно, они умеют кое-что еще, и в россии это получило название «эффективных менеджеров» — абсолютно не понимающих ничего, эффективно доводящих положенный объект до ручки, да максимизируя собственное благосостояние, но — мастерство не пропьешь, обычно с ужасным КПД. При этом не забыв попить крови из попавших в подчинение людей.

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

Всей этой фигне — эффективному самопродвижению идиотов, есть научное объяснение — RuPedia:Эффект_Даннинга_—_Крюгера, означающему только, что у умных есть совесть и самокритика… а у остальных этого почему-то не хватает

Есть активное движение в менеджеры, людей плохо разбирающихся в индустрии (зачем терять хорошего программиста-QA-аналитика делая его менеджером? → давайте сделаем менеджера из неудачника тестировщика, хренового кодера, или вообще гуманитария. У них же лучше с «коммуникацией», «дисциплиной» и «эмпатией», они выучат PMBOK без ворчания, они будут носить пиджак и галстук как влитые (настоящий разработчик ведь этого не сможет — это мешает печатать, дышать и думать), они не моргнув глазом переведут все, людей, пространство и время в деньги, получать ROI и поделят на KPI → нефизичность и бессмысленность цифр не будет их раздражать. Ну а дальше — нет проблем, включаем режим автопилота — «Делегируй или умри», и получаем PROFIT!.

Это напоминает мне историю, как в ЦАГИ решали техническую проблему — «трещали» крылья у разрабатываемой модели бомбадировщика. Как они не модифицировали модель, в крыльях была точка сбора напряжений, где возникала трещина и мгновенный разлом. Решили просто — в этой точке высверлили большую дырку, и заткнули резиновой пробкой.

Мне все это активно не нравится. Я глубоко убежден, что «аджайл» возник не в последнюю очередь для того, чтобы убрать людей с бессмысленных мест, и подвинуть в стороны, где есть производственный труд. Убрать «классического менеджера», заменив его продукт-менеджером, который «бизнес-аналитик» по определению, самоорганизованной командой, и набором механических-автоматизированных тулзов, для эффективной коммуникации, контроля, мониторинга и т.п. Таким образом устраняется уязвимая точка отказа и блокировки — «менеджер классический».

---

И вот, в этом докладе Мария, из старой школы разработчиков — судя по упомянутому шестикилобайтному ассемблерному фракталу Марс (1992 год, если мне не изменяет память), говорит совершенно разумную вещь, что, например, PMу не мешало бы иметь полезную компетенцию. Например, в предметной области, и даже быть ведущим аналитиком. Особенное если у вас не адовый проект с сотнями разработчиков, а как у всех нормальных людей — небольшие команды, разбирающиеся со своим фронтом работ.

И тут показательна реакция зала:

• Тут же нашлись люди,
  • упрекнувшие в недостаточном знании Книги™ (пиэмбока), с намеком — может ты и BA, но не настоящий PM.
  • намекнувшие, что это «партизанщина», а настоящих проектов-то (уровня дивизии и армии), автор-то и не видел.
• Отдельно нашлись пожаловшиеся, что в режиме PM+BA не получается сыграть в настоящего менеджера («Делегируй или умри»), ибо вот, накапливаются критические знания, а их не так просто передать, как делегировать работу.

И это печально. Хотя я надеюсь на лучшее.

Отчет Стаса Фомина о SPMConf-2011/Эффективное сочетание компетенций в IT