Аннотация
- Докладчик
- Мария Бондаренко
- Введение
В настоящее время в 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 не получается сыграть в настоящего менеджера («Делегируй или умри»), ибо вот, накапливаются критические знания, а их не так просто передать, как делегировать работу.
И это печально. Хотя я надеюсь на лучшее.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
