Отчет Стаса Фомина о SPMConf-2011
Эффективное сочетание компетенций в IT
Хороший доклад на важную, постоянно рефлексируемую мной тему — что есть достойный менеджер, какие полезные компетенции у него могут быть. Да, я презираю менеджеров без полезных проекту или компании компетенций. Нет, я не считаю функции «контроля», «планирования» и «коммуникации» достаточными, чтобы этим занимался человек, обладающий властью, принимающий решения, но не умеющий больше ничего — не рубящий ни в разработке, ни в архитектуре, ни в предметной области и не в тестировании.
А ведь это серьезный тренд, — универсальные менеджеры проектов и даже проектные офисы, которым пофиг, чем управлять. Да, скорее всего они просрут все полимеры, возможно спецы сожмут зубы, и сделают проект несмотря на их менеджмент, после чего будет, как обычно, «наказание невиновных и награждение непричастных». Т.е. роговолосый менеджер из Dilbert™-а еще ничего — он достаточно безобиден, и даже позитивен. Но обычно, они умеют кое-что еще, и в россии это получило название «эффективных менеджеров» — абсолютно не понимающих ничего, эффективно доводящих положенный объект до ручки, да максимизируя собственное благосостояние, но — мастерство не пропьешь, обычно с ужасным КПД. При этом не забыв попить крови из попавших в подчинение людей.
В среднем по больнице, в IT это не так плохо, ибо мобильность специалистов выше, чем на каких нибудь крепостных градообразующих заводах, но все равно, тлетворное влияние общей ситуации неизбежно.
Всей этой фигне — эффективному самопродвижению идиотов, есть научное объяснение — RuPedia:Эффект_Даннинга_—_Крюгера, означающему только, что у умных есть совесть и самокритика… а у остальных этого почему-то не хватает
Есть активное движение в менеджеры, людей плохо разбирающихся в индустрии (зачем терять хорошего программиста-QA-аналитика делая его менеджером? → давайте сделаем менеджера из неудачника тестировщика, хренового кодера, или вообще гуманитария. У них же лучше с «коммуникацией», «дисциплиной» и «эмпатией», они выучат PMBOK без ворчания, они будут носить пиджак и галстук как влитые (настоящий разработчик ведь этого не сможет — это мешает печатать, дышать и думать), они не моргнув глазом переведут все, людей, пространство и время в деньги, получать ROI и поделят на KPI → нефизичность и бессмысленность цифр не будет их раздражать. Ну а дальше — нет проблем, включаем режим автопилота — «Делегируй или умри», и получаем PROFIT!.
Это напоминает мне историю, как в ЦАГИ решали техническую проблему — «трещали» крылья у разрабатываемой модели бомбадировщика. Как они не модифицировали модель, в крыльях была точка сбора напряжений, где возникала трещина и мгновенный разлом. Решили просто — в этой точке высверлили большую дырку, и заткнули резиновой пробкой.
Мне все это активно не нравится. Я глубоко убежден, что «аджайл» возник не в последнюю очередь для того, чтобы убрать людей с бессмысленных мест, и подвинуть в стороны, где есть производственный труд. Убрать «классического менеджера», заменив его продукт-менеджером, который «бизнес-аналитик» по определению, самоорганизованной командой, и набором механических-автоматизированных тулзов, для эффективной коммуникации, контроля, мониторинга и т.п. Таким образом устраняется уязвимая точка отказа и блокировки — «менеджер классический».
И вот, в этом докладе Мария, из старой школы разработчиков — судя по упомянутому шестикилобайтному ассемблерному фракталу Марс (1992 год, если мне не изменяет память), говорит совершенно разумную вещь, что, например, PMу не мешало бы иметь полезную компетенцию. Например, в предметной области, и даже быть ведущим аналитиком. Особенное если у вас не адовый проект с сотнями разработчиков, а как у всех нормальных людей — небольшие команды, разбирающиеся со своим фронтом работ.
И тут показательна реакция зала:
- Тут же нашлись люди,
- упрекнувшие в недостаточном знании Книги™ (пиэмбока), с намеком — может ты и BA, но не настоящий PM.
- намекнувшие, что это «партизанщина», а настоящих проектов-то (уровня дивизии и армии), автор-то и не видел.
- Отдельно нашлись пожаловшиеся, что в режиме PM+BA не получается сыграть в настоящего менеджера («Делегируй или умри»), ибо вот, накапливаются критические знания, а их не так просто передать, как делегировать работу.
И это печально. Хотя я надеюсь на лучшее.
Руководитель проекта – жизнь до и после найма
О. Очень рекомендую к просмотру. Это «путь классического менеджера», причем у докладчика в анамнезе опыт работы в госорганизациях. Все кратко, сконцентрировано и открытым текстом.
Очень бесстыдные простые метафоры:
- Цель (нанятого менеджера)
- проникнуть в улей с медом.
- Стратегия
- показать, что ты «пчела», а не «медведь» (привет ПЖиВ!)
- Средства
-
- повышать свое визибилити,
- ассоциировать с себя с достижениями,
- прикрывать задницу на случай фейлов.
- Артефакты
-
- Удобный универсальный инструмент — «матрица рисков». «Наукообразно» составить и раскрасить — раз плюнуть. Зато так удобно «прикрыть зад», ведь заранее можно показать, что это был все равно «нерешаемый» проект. А если проект, несмотря на нанесенный вами вклад все равно будет сделан — очков и бонусов будет сильно больше.
- Отчеты.
- Куча документов — единственному продукту, судя по рассказу докладчика, производимому менеджерами.
- Это «экономические обоснования» (РоИ-КэПэИ).
- Процессы! Момент истины: «поставленный процесс — это когда дорогой персонал можно заменить дешевым! … → PROFIT!!!»[1].
В общем, все это одна из квинтессенций «универсальных эффективных менеджеров». Не знаю, как они в остальных областях, вернее знаю, как в остальных, но может хоть в консалтинге, где надо производить только нафиг никому не нужные бумажки, это самое то.… Ну и все такое в общем духе.
Главное — храни меня Тьюринг от таких менеджеров и организаций.
Цифры в помощь
Доклад несколько абстрактно-обзорный, содержательно комментировать не буду, хотя порекомендую на тему метрик с инженерным обоснованием посмотреть Скрамомер и канбанометр (Максим Дорофеев, AgileKitchen, 2011-12-17).
А вот о чем я не могу молчать: Докладчики! Не используйте Prezi! Уже года три как все наигрались и поняли, что:
- в этом нет смысла → свистелки-перделки-крутилки, это все только элементы шума, которого так не любят грамотные люди. Ведь даже слайд-переходы в некотором смысле моветон («нас держат за лохов?»), хотя это еще более менее фильтруется мозгом как баннеры в инете, но «кручение-верчение» реально выносит мозг.
- Идея, что «zoom»-переходы помогут вам рассказать структурированную историю — имхо, фейл. Ни разу не видел, чтобы это работало.
- Ну и выступают все обычно с скомпилированной версией, которая на чужих компьютерах ОЧЕНЬ высоковероятно даст какой-нибудь глюк. Не в первый раз уже такое вижу. Кстати, веб-версия prezi обычно надежней, и тут надо было при первых синдромах (а по-уму, на этапе проверки, в перерыве), переключаться и использовать веб-презентацию.
Единственный плюс — централизованное хранение, но все это такая фигня, по сравнению с удобством S5 на MediaWiki.
Почему наезжаю? Потому что докладчик решил, что его prezi-глюки обусловлены моим скринкастером и вырубил его в процессе выступления. А презентация была набита детальными графиками и таблицами, которые хрен прочитаешь с камеры. Мне пришлось сильно излишне возится — отдельно прогнать презентацию и записать кривопопадающий скринкаст, плюс лишние трудозатраты с монтажем. Не бросил, ибо не пропадать же труду докладчика и видеооператоров.
- ↑ Только в минимально интеллектуальной сфере это не работает. А иногда и убивает. Только что посмотрел 4 сезона Breaking Bad, там наркомафия очень хотела оптимизировать издержки и заменить эксперта-повара дешевыми чуваками, работающими по процессу. Казалось бы тут фиксированный процесс — реально. Но ой как не вышло.... А в разработка — даже не химия, технологии меняются постоянно!
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.