Отчет Стаса Фомина о SPMConf-2011

Подстраницы (3) →

Эффективное сочетание компетенций в IT

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

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

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

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

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

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

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

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

---

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

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

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

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

Руководитель проекта – жизнь до и после найма

О. Очень рекомендую к просмотру. Это «путь классического менеджера», причем у докладчика в анамнезе опыт работы в госорганизациях. Все кратко, сконцентрировано и открытым текстом.

Очень бесстыдные простые метафоры:

Цель (нанятого менеджера)

проникнуть в улей с медом.

Стратегия

показать, что ты «пчела», а не «медведь» (привет ПЖиВ!)

Средства

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

Артефакты

• Удобный универсальный инструмент — «матрица рисков». «Наукообразно» составить и раскрасить — раз плюнуть. Зато так удобно «прикрыть зад», ведь заранее можно показать, что это был все равно «нерешаемый» проект. А если проект, несмотря на нанесенный вами вклад все равно будет сделан — очков и бонусов будет сильно больше.
• Отчеты.
• Куча документов — единственному продукту, судя по рассказу докладчика, производимому менеджерами.
• Это «экономические обоснования» (РоИ-КэПэИ).
• Процессы! Момент истины: «поставленный процесс — это когда дорогой персонал можно заменить дешевым! … → PROFIT!!!».

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

Главное — храни меня Тьюринг от таких менеджеров и организаций.

Цифры в помощь

Доклад несколько абстрактно-обзорный, содержательно комментировать не буду, хотя порекомендую на тему метрик с инженерным обоснованием посмотреть Скрамомер и канбанометр (Максим Дорофеев, AgileKitchen, 2011-12-17).

А вот о чем я не могу молчать: Докладчики! Не используйте Prezi! Уже года три как все наигрались и поняли, что:

• в этом нет смысла → свистелки-перделки-крутилки, это все только элементы шума, которого так не любят грамотные люди. Ведь даже слайд-переходы в некотором смысле моветон («нас держат за лохов?»), хотя это еще более менее фильтруется мозгом как баннеры в инете, но «кручение-верчение» реально выносит мозг.
• Идея, что «zoom»-переходы помогут вам рассказать структурированную историю — имхо, фейл. Ни разу не видел, чтобы это работало.
• Ну и выступают все обычно с скомпилированной версией, которая на чужих компьютерах ОЧЕНЬ высоковероятно даст какой-нибудь глюк. Не в первый раз уже такое вижу. Кстати, веб-версия prezi обычно надежней, и тут надо было при первых синдромах (а по-уму, на этапе проверки, в перерыве), переключаться и использовать веб-презентацию.

Единственный плюс — централизованное хранение, но все это такая фигня, по сравнению с удобством S5 на MediaWiki.

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

---

---

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