Насколько менеджер отстает в изучении технологий?

насколько мы отстали от поезда технологий? :)На первый взгляд вопрос совсем непонятен.

«Как отстал? Да я же работаю с этими технологиями, у меня 10 программистов на .NET 4. Сейчас будем переходить на облачные вычисления на Azure. Это феерия технологий, cutting edge можно сказать!», воскликнет много менеджеров. Они же уверены, что они лидеры инноваций.

Недавно очень долго спорил со своим коллегой, пытаясь доказать то, что если он не пишет код, то теряет навыки программиста. Он в свою очередь отказывался верить в это. Спор был из разряда холивара, до хрипоты. Аргументы были нешуточные. Но после того как были потрачены несколько часов и изрядно опустошены запасы слов (и пива :)) мы пришли к выводу, что по настоящему ценным является навык работы. То есть не теоретические знания, а именно то, как мы умеем эти знания применить. После этого мы более подробно ушли в обсуждение навыка как такового.

Любой навык состоит из 3 составляющих: теория, действия и результат. Для программистов или тестеров это можно преобразовать в понятные для нас слова:

  • синтаксис и структура языка программирования или технологии
  • Среда разработки и ее инструменты
  • Применение языка и инструментария для решения конкретной задачи в конкретном проекте.

И вот теперь наш спор перешел в другую плоскость, которая оказалась очень продуктивной. В качестве примера мы взяли стандартную команду, где есть только программисты, тестировщики и ПМ (без необычных ролей).

На приобретение навыка работы с тем или иным языком программирования, в среднем, программист тратит 40 часов в неделю (это как минимум). Он тратит это время на все 3 составляющих этого навыка (теория, действие и результат).

А теперь давайте рассмотрим, сколько времени может тратить менеджер на этой технологии? Предположим, это будет 25% от общего времени, включая дополнительную нагрузку дома. Какую из составляющих навыка он будет развивать? Вероятнее всего только теорию, и в меньшей степени инструментарий. «Результат» (применение теории и инструментов) практически выпадает, и такой менеджер только наблюдает применение теории и инструментария в рамках проекта. То есть в итоге, максимум 10 часов в неделю на технологию, и то, в основном на ознакомление с принципами.

А больше времени менеджер не сможет тратить по следующим причинам:

  1. В проекте несколько технологий, и менеджеру надо хотя бы понимать, что означает каждая из них.
  2. Кроме разработки, есть еще и тестирование, дизайн, бизнес-аналитика. И каждые со своими теориями, инструментами и особенностями применений.
  3. Кто-то должен выполнять РАБОТУ МЕНЕДЖЕРА (коммуникации, документация, работа с Заказчиком…).

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

Из этого следует сразу несколько выводов:

  1. Или вы начинаете управлять и развиваться в этом, или продолжаете писать, являясь недо-менеджером. Если управляете и продолжаете выдавать технические решения, то вы становитесь недо-программистом. «Половинчатые» решения хороши только в случае небольшой команды. Также они применимы, как временное решение, когда менеджер вырос из опытного программиста на этом проекте.
  2. Если вы выбрали карьеру менеджера, то вам придется отдать технические решения тем людям, которые будут за это отвечать. Пытаясь сесть на 2 стула сразу, вы, вероятнее всего, не усидите ни на одном. Делегирование – это ваше все!
  3. «Качайте» навыки управления и коммуникаций, если вы ПМ.
  4. «А можно писать дома программы, и немножко на работе и при этом быть хорошим менеджером?». Да можно, смотри пункт 1 и вывод. :)

Вывод: ПМ рано или поздно отстает от мэйнстрима технологий и отстает от него НАВСЕГДА. Да-да, именно навсегда, так как пока вы будете догонять 1 технический навык, то в мире появится еще 5 и ваша же команда потратит на них в разы больше времени.

P.S. Когда перечитывал пост, то вдруг понял, что словосочетание «cutting edge» можно вполне заменить русским «ёшкин кот». По фонетике и смысловой нагрузке почти одно и то же :).

Nov 15th, 2010
  1. Перевод “cutting edge” в точку. Посмеялся от души :))

  2. PMP
    Nov 16th, 2010 at 12:13 | #2

    Вот почему у нас сложился стереотип о том, что ПМ – это обязательно бывший девелопер, тестер и т.д.? Доходит до того, что в некоторых компаниях “ПМ должен кодить, тестить”. Давайте бухгалтера, который в вашей компании работает, обяжем кодить – он ведь в айти компании работает. По этой же логике HR должен кодить – тоже ведь с айтишниками общается! К какому маразму мы в итоге придем?

    Видите ли, проблема сегодня заключается в том, что в украинских реалиях ПМ (как и системный аналитик) считается чуть ли гуманитарным придатком девелопера. Большинство работодателей категорически не хотят признавать проджект менеджмент отдельной профессий. Поэтому ПМами назначают зачастую людей, умеющих программировать на Java (или на чем угодно), но абсолютно некомпетентных в управлении проектом. Ведь проджект менеджмент сам по себе уже мультизадачный – PM BOK все достаточно четко описывает, – чем именно должен заниматься ПМ. Некоторые даже не подозревают о его существовании. Потому и провальных проектов у нас так много – вместо того, чтоб осуществлять scope, time, cost, quality, integration, HR, risk, procurement, communication management применительно к процессу разработки, ПМ выполняет совершенно несвойственные задачи: разрабатывает требования вместо системного аналитика, описывает архитектуру вместо архитектора, программирует вместо девелопера – что является нарушением базовых принципов менеджмента. Т.е. “сам делаю, и сам контролирую”. Кроме того, это все совершенно отдельные области знаний. Т.е. пытаются скрестить ужа с ежом. Жирафа с бегемотом. Экономят на всем. Потому что “зачем платить зарплату аналитику, архитектору если ПМ ничего не делает – пусть он этим займется!”. Часто в таких проектах вообще нет сроков. Это то, с чем пытается бороться PMI – бессрочные проекты, “ПМ-аналитик-архитектор-девелопер-тестер”. Но пока, видимо, безуспешно… Согласно статистики того же PMI 80% проектов проектами не являются.

    Что касается карьеры, в частности – требования в отношении конкретных технологий программирования… Вот смотрите. Если требуется опыт Java, уточняйте заранее – зачем? Java просто как опыт программирования, или для того, чтоб разрабатывать приложения на Java? Если второе – им точно не ПМ нужен, а тим-лидер. А проектом в таких организациях управляет на самом деле заказчик, который сидит в соседней комнате (частая ситуация), ну или удаленно. И управляет как умеет (чаще всего – не умеет). Если же первое – требуется любой опыт разработки – то уточните, почему именно Java? Если Вы не будете программировать? И если Ваш следующий проект будет не Java, а например, С++, PHP и пр. – то что, нужно Вас увольнять и нанимать ПМа С++? Это БРЕД.

    Не все ПМы знают, что ЕСТЬ другие методологии, кроме аджайла! И вообще, что есть другие проекты, кроме софта – и научные, и медицинские, и образовательные, спортивные, строительные, и много других. Кто-то вообще интересуется – а как в других проектах/отраслях? а вдруг что-то интересное/новое для себя узнаю?
    Никто! Потому что Java девелопер управляет проектом Java в качестве тимлидера, называясь при этом ПМом (“проект ведь на Java!”), и он абсолютно уверен – это и есть проджект менеджмент! Вы задайте такому “специалисту” вопрос – например, что есть Input или Output того или иного процесса? какие артефакты? стратегии работы с рисками? Да он будет полчаса искать ответ в базах данных или в джаве! Потому что у человека сформировано искаженное представление о професси ПМа. Работал он с тим-лидером, который по ошибке назывался ПМом.

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

    А для того, чтобы, например, внедрить процесс или методологию, нужно чтоб это было интересно руководству компании. А владельцам бизнеса это неинтересно сегодня – большинство из них устраивает то положение дел, которое есть. Если хотя бы один проект завершился успехом по “старому наезженному процессу”, то о новшествах и слышать не хотят! Но бороться, безусловно, нужно – показывать на презентациях преимущества изменений, – в чем выиграет компания, увеличится ли прибыль и т.д.

    А знания, которые предлагает PMI, универсальны – их применяют в совершенно РАЗНЫХ проектах. Тот же PM BOK является базой, основой – в нем ведь нет привязки конкретно к программированию, строительству или еще чему-то. Это, на мой взгляд, скорее область знаний (по определению), хотя и методологией PM BOK тоже считают. Просто на эту базу накладывается процесс в зависимости от специфики отрасли. Есть альтернативы PM BOK – тот же Prince, в котором, впрочем, ПМу отводится несколько другая роль. Но суть не в этом. Сегодня процесс есть в каждой компании, но нет БАЗЫ, на которой основан этот процесс! Процесс ради процесса! Это то, о чем я ранее писал – нет понимания того, ЧТО есть проект. О каких проектах идет речь, если нет сроков, нарушены принципы коммуникации, проектом пытается управлять (и отвечать за результат) ВСЯ команда, а не ПМ?

    Тенденции сегодня отнюдь не радужные. Мы вот описываем проблему. А как ее решать? За профессию нужно бороться! Потому что лет через 10 проектами будет управлять кто угодно и как угодно. А бороться может, на мой взгляд каждый на своем рабочем месте – предлагать идеи, экспериментировать, показывать преимущества. Поставьте, например, вопрос перед своими работодателями – если один человек может сделать ВСЕ, то зачем вообще команда проекта? Может, лучше пусть каждый занимается своим делом? Согласен с тем, что не в каждой структуре требуется ПМ, и это зависит от объема и целей проекта. Но тогда тим-лидер должен называться тим-лидером, а не ПМом. Системный аналитик – аналитиком, а не ПМом. И т.д. Тогда все станет на свои места. Также важна сертификация – PMP, PgMP, RMP и т.д. – это увеличит количество единомышленников. А значит, будет меньше глупости. И есть надежда у нашей профессии.

  3. Nov 16th, 2010 at 13:38 | #3

    to PMP
    Я почти полностью с вами согласен. Да, реалии нашей жизни таковы, что люди не всегда понимают, что такое управление проектами. Пост то как раз этому и посвящен. Если ты уже решил стать менеджером, то нужно быть хорошим менеджером, а не пытаться сидеть на 3х стульях одновременно. Пример с Java и переходом на С++ или РНР как раз отлично это иллюстрирует.
    То, что необходимо обучение и расширение кругозора как управленца – это 100%.

    Я вот только с одним комментарием позволю себе несогласиться. Менеджерское Счастье – не в знании Input и Output-ов разных процессов согласно ПМБоК. Я лично собеседовал десятки людей, которые назубок знают ПМБок (почти рифма :)), а управлять командой и собой не умеют. Счастье – умение применять то, что необходимо в конкретном проекте.

  4. PMP
    Nov 16th, 2010 at 14:01 | #4

    2 Сергей

    Input и Output я просто в качестве примера привел. И я не утверждаю, что в этом счастье. Мой посыл был в том, что профессия нивелируется – никому не нужны знания менеджмента, тем более образование, ПМ выполняет любую работу, занимаясь ЧУТЬ-ЧУТЬ управлением проекта (!).

    “Если ты уже решил стать менеджером, то нужно быть хорошим менеджером, а не пытаться сидеть на 3х стульях” – именно.

    Но уверены ли вы, что в компании, в которой вы работаете, все обстоит именно так? Я ради интереса зашел на сайт GL, в раздел “вакансии” – “менеджмент”, – встречаются (не везде!) требования наподобие: 4+ years extensive programming experience in .NET, software architecture, system analysis и т.д., и обязанности – разработка спецификаций и пр., архитектуры.

    Повторюсь – это отдельные вакансии. В основном, требования достаточно адекватные, что внушает оптимизм. Но разве это не противоречит тому, о чем мы с вами здесь говорим? Если стирается грань между Пмом и тимлидом/архитектором? Или может, нужно все своими именами называть?

  5. Nov 16th, 2010 at 15:30 | #5

    to PMP

    4+ years extensive programming experience in .NET, software architecture, system analysis и т.д., и обязанности – разработка спецификаций и пр., архитектуры.

    ИМХО, я считаю, что опыт работы программистом или тестером – это большой плюс. Потому что будешь управлять зная внутреннюю структуру процессов.
    Посмотрите на японцев (таже Toyota) у них нет менеджеров “со стороны”. Все свои – выращенные с самых низов. Знают все уровни процессов. И эти люди делают самые качественные продукты в мире. Это только пример :)
    Еще в моей жизни был пример, когда пришел ХОРОШИЙ PM из другой области (телекоммуникации) и не смог управлять проектом, просто потому, что не понимает, как работает “девелоперская кухня”.

  6. PMP
    Nov 16th, 2010 at 16:25 | #6

    “ИМХО, я считаю, что опыт работы программистом или тестером – это большой плюс. Потому что будешь управлять зная внутреннюю структуру процессов.”
    —————————-

    В том-то и дело, что ЗНАТЬ и РАБОТАТЬ вещи разные. Ведь требуется именно работать. Неплохо, что вы знаете и умеете разрабатывать требования, описывать дизайн-элементы, тестировать и работать с базами данных. Но если вы ПМ, и одновременно выполняете еще все перечисленные задачи, то должны понимать, что повышаете риски в проекте в разы.

    Потом, для того, чтобы знать структуру процессов, обязательно для этого быть девелопером или тестером? И что, по-вашему, является определяющим фактором – опыт разработки девелопера, или опыт ведения успешных проектов по разработке софта ПМа?

    Я на собеседованиях всегда отдавал предпочтение кандидатам, которые, во-первых, обладали базовыми знаниями – что такое проект и проджект менеджмент, кто такие stakeholders, PRA, Lessons Learned, Critical Path, как УПРАВЛЯТЬ требованиями, ожиданиями и т.д. – ну это пример, во-вторых, знали процесс разработки/поддержки программных подуктов – могли бы описать этапы в тех же Agile, RUP, OPM3, ITIL, в-третьих, имели опыт управления проектами, знали, для чего требуется та или иная документация, владели бы ПМ-инструментами, тот же MS Project и др.

    Это в качестве примера.
    Но мне не приходило в голову принимать решение в пользу PHP девелопера (какой бы он ни был синиор), потому что в проекте используется PHP. Когда спрашиваешь об опыте управления, оказывается – все они были тим-лидерами, тест-аналитиками. Отсюда и представление у них о профессии однобокое.

    Приходилось наблюдать следующее: люди с опытом разработки или тестинга более сосредоточены как раз на отдельных технологиях и процессах, чем на управлении проекта в целом. Пытались участвовать в кодинге, копались в базах данных, тестили чего-то там сами. Что, безусловно, нарушало процесс управления, делало его необъективным. Часто такие “многостаночники” заводили проект в тупик, потратив бюджет. Т.е. задачи перед данными специалистами ставились совершенно другие. И непонимание ними того, что управление проектом – совершенно другая сфера, приводило к проблемам. Хотя и тренинги проводились. И митинги на эту тему. Не доходило. Вернее, доходило с трудом. Потому что “руки тянутся” покодить, потестить. В итоге пришел к тому, что разработчики и пр. МОГУТ быть руководителями. Но необязательно должны. Потому как не в технологиях дело.

    Я всегда сделаю выбор в пользу кандидата с опытом управления (не тим-лидера, я ведь не тим-лидера ищу), или, как минимум, понимания этой специальности. Потому что кандидат с опытом тестера знаком с процессом только в своей специфической сфере, и девелопер точно так же знаком с процессом только в разрезе своих обязанностей. А нужен опыт РУКОВОДИТЕЛЯ ВСЕГО этого процесса, а не отдельных его этапов. А если нет кандидата с опытом управления (что маловероятно), то, возможно, присмотрюсь к аналитикам, архитекторам, тим-лидерам – но их ведь обучать придется, и они должны быть с этим согласны. Но людей ведь нанимают, чтоб решать конкретные проблемы уже сейчас – не все могут тратить время и средства на обучение. Проще взять готового спеца.

    Но где люди, достойные такой власти? Обладающие такой квалификацией? Их все время пытаются вытеснить с рынка. Потому что “.NET, C++, Perl, ORACLE…….” – вот где ищут причины провала проектов…

    Если выбирать не из кого, и в компании только “доморощенные” сотрудники, то это часто приводит к застою в процессах управления, – новые люди со своим, возможно, уникальным опытом могли бы “освежить” ситуацию. Хоть это и не просто (я об этом писал выше) – на собеседованиях все говорят о том, что, мол, – очень положительно относимся к инновациям и т.д. В процессе обнаруживается обратное. Ничего не хотят менять, “потому, что все привыкли”.

  7. Андрей Эйдельман
    Nov 25th, 2010 at 21:18 | #7

    Несколько опоздал к дискуссии… :)

    Вот еще одно мнение на тему “должен ли менеджер писать код”:

    http://www.randsinrepose.com/archives/2007/02/07/technicality.html

    Из своего опыта: во всех виденных мной успешных проектах, которыми управляли менеджеры без опыта программирования, всегда был технический лидер, который находился в очень тесном контакте с менеджером и всячески ему помогал. Технический лидер мог называться по разному – senior dev, tech lead, team lead, etc.

Leave a comment