Думаю, многие согласятся с тем, что у нас очень много хороших IT специалистов. И даже наше образование, а также политические, экономические и другие факторы не сильно могут помешать стать хорошим IT специалистом при наличии желания. Но вот с менеджерами в сфере IT не всё так хорошо…
Под IT менеджерами я имею в виду тимлидов, руководителей проектов, начальников отделов, скрам мастеров, лайн менеджеров и т.д. С топ менеджментом дела выглядят получше, так как их либо присылают из-за бугра, либо это представители редкого вида управленцев-технарей, которые иногда водятся в дикой IT среде.
Какими свойствами должен обладать хороший менеджер? Во-первых, он должен уметь коммуницировать с различными людьми, а также ими руководить. Во-вторых, быть хорошо подкованным в смежных областях — психологии, экономике, юриспруденции, разбираться в таких вопросах, как мотивация, моральный риск, оценка рисков, спрос-предложение, трудовое законодательство, международное право, интеллектуальная собственность.
Эти предметы номинально преподают в технических университетах, но их количество и качество стремятся к нулю. Таким образом, университетское образование никак не решает вопрос воспитания IT менеджеров.
Так где же брать IT менеджеров? Из смежных областей менеджеров не возьмешь — у них банально не хватит квалификации.
Остается единственный вариант — выращивать менеджеров из разработчиков. А это имеет несколько проблем, одна из которых — нужно менять мышление.
У менеджеров и программистов есть очень важное отличие в мышлении: программист нацелен на процесс — для него является важным создать изящную архитектуру, написать идеальный код с комментариями, придумать хитрую систему плагинов и писать на новых (или любимых) технологиях. Менеджер, в свою очередь, нацелен (должен быть нацелен) на результат — готовый продукт в обозначенные сроки и бюджет. При этом красота кода отходит на второй (я бы даже сказал, на предпоследний) план. Из-за этого несоответствия не редки проблемы между менеджерами и разработчиками.
Проблема в том, что изменить мышление за день или неделю невозможно. По экспертным оценкам, процесс транформации мышления занимает от полугода до четырёх лет.
И вот тут кроется одна из главных проблем. Средняя продолжительность работы IT специалиста в одной компании — 1.5-2 года. Поэтому компании могут быть практически на 100% уверены, что разработчик не будет работать в их компании, когда закончится процесс его обучения. Таким образом, нет смысла и начинать его учить…
Вторая проблема в том, что редкий разработчик будет смотреть наперед на 3-4 года и станет планировать своё менеджерское будущее… без внешнего вмешательства. К сожалению, HR больше обеспокоены, как захантить очередного джависта и закупить новую партию печенек, чтобы хотя бы эти не разбежались.
Также нужно помнить, что хорошим менеджером может стать далеко не каждый технарь. Схема «сегодня — лучший разработчик, завтра — хороший менеджер» не работает. Можно потерять хорошего разработчика и получить плохого менеджера. Экономический эффект от этого даже не стоит начинать считать.
Лучший момент для начала трансформации разработчика в менеджера — middle уровень. В это время нужно начинать читать специализированную литературу (а не только литературу по технологиям). Лучше всего начать с Peopleware Тимоти Лестера и «Джоэл о программировании» Джоэла Спольски. А дальше по списку.
Работа менеджера строится на управлении людьми. Проблема в следующем: чтобы стать хорошим IT специалистом, нужен лишь компьютер, интернет и желание; хорошим менеджером без практики стать вряд ли получится.
Еще один момент, которые многие упускают. В любых ситуациях за всё, что происходит в команде разработчиков, ответственность должен нести менеджер (руководитель).
Еще раз повторюсь: за все косяки в команде должен отвечать менеджер.
В век скрама и гибких методологий ответственность размазывается среди членов команды, руководителей и заказчиком, то есть отсутствует персональная ответственность. Не нужно говорить, что это очень выгодно компаниям и самим разработчикам.
Пример из жизни: как-то задал вопрос своему менеджеру, кто возьмет на себя ответственность за нереальную оценку, отсутствие квалифицированных кадров и внедренную методологию управления под названием scrumно. На что получил удивленный ответ: все. При персональной ответственности за свою работу ничего подобного бы ни было. Думаю, не нужно говорить, что проект с треском провалился, и никто при этом не понёс персональное наказание.
Понимать и нести персональную ответственность за себя и своих подчиненных — это одно и самых важных свойств хорошего менеджера.
Кстати, есть еще один побочный эффект: из-за, не побоюсь этого слова, тупых менеджеров некоторые нормальные специалисты меняют место работы, а некоторые начинают склоняться к мысли, что лучше вообще работать без менеджеров (статьи на подобную тематику легко можно отыскать в интернете).
Далеко ходить не надо: в одной компании я и мои коллеги в течение нескольких месяцев скрывали реальное положение дел от менеджера, чтобы он не дай бог не вмешался в процесс разработки и не похерил всё то, что без его участия отлично работало.
Также несколько раз наблюдал ситуацию, когда менеджеры через некоторое время отказывались от своих должностей и обратно превращались в разработчиков. Причин несколько: рост зарплаты, как правило, незначительный (если вообще есть), а обязанностей и головной боли — на порядок больше.
К тому же ситуация, когда разработчик зарабатывает больше своего менеджера, — не редкость в IT компаниях, хотя в других сферах такое случается крайне редко. Этим также можно объяснить нежелание многих технарей превращаться в менеджеров.
Менеджер должен обладать харизмой, иметь огромное количество знаний, быть авторитетом для своих подчиненных. Всё это нужно умножить на техническую подкованность. У вас уже работают такие люди? Ваша задача — сделать всё, чтобы их не заполучили ваши конкуретны.
А разработчикам нужно заранее ответить себе на вопрос, хотят ли они в будущем стать менеджерами, и если ответ положительный — начать к этому готовиться за несколько лет.
Под IT менеджерами я имею в виду тимлидов, руководителей проектов, начальников отделов, скрам мастеров, лайн менеджеров и т.д. С топ менеджментом дела выглядят получше, так как их либо присылают из-за бугра, либо это представители редкого вида управленцев-технарей, которые иногда водятся в дикой IT среде.
Образование
Какими свойствами должен обладать хороший менеджер? Во-первых, он должен уметь коммуницировать с различными людьми, а также ими руководить. Во-вторых, быть хорошо подкованным в смежных областях — психологии, экономике, юриспруденции, разбираться в таких вопросах, как мотивация, моральный риск, оценка рисков, спрос-предложение, трудовое законодательство, международное право, интеллектуальная собственность.
Эти предметы номинально преподают в технических университетах, но их количество и качество стремятся к нулю. Таким образом, университетское образование никак не решает вопрос воспитания IT менеджеров.
Так где же брать IT менеджеров? Из смежных областей менеджеров не возьмешь — у них банально не хватит квалификации.
Остается единственный вариант — выращивать менеджеров из разработчиков. А это имеет несколько проблем, одна из которых — нужно менять мышление.
Мышление
У менеджеров и программистов есть очень важное отличие в мышлении: программист нацелен на процесс — для него является важным создать изящную архитектуру, написать идеальный код с комментариями, придумать хитрую систему плагинов и писать на новых (или любимых) технологиях. Менеджер, в свою очередь, нацелен (должен быть нацелен) на результат — готовый продукт в обозначенные сроки и бюджет. При этом красота кода отходит на второй (я бы даже сказал, на предпоследний) план. Из-за этого несоответствия не редки проблемы между менеджерами и разработчиками.
Проблема в том, что изменить мышление за день или неделю невозможно. По экспертным оценкам, процесс транформации мышления занимает от полугода до четырёх лет.
И вот тут кроется одна из главных проблем. Средняя продолжительность работы IT специалиста в одной компании — 1.5-2 года. Поэтому компании могут быть практически на 100% уверены, что разработчик не будет работать в их компании, когда закончится процесс его обучения. Таким образом, нет смысла и начинать его учить…
Вторая проблема в том, что редкий разработчик будет смотреть наперед на 3-4 года и станет планировать своё менеджерское будущее… без внешнего вмешательства. К сожалению, HR больше обеспокоены, как захантить очередного джависта и закупить новую партию печенек, чтобы хотя бы эти не разбежались.
Также нужно помнить, что хорошим менеджером может стать далеко не каждый технарь. Схема «сегодня — лучший разработчик, завтра — хороший менеджер» не работает. Можно потерять хорошего разработчика и получить плохого менеджера. Экономический эффект от этого даже не стоит начинать считать.
Лучший момент для начала трансформации разработчика в менеджера — middle уровень. В это время нужно начинать читать специализированную литературу (а не только литературу по технологиям). Лучше всего начать с Peopleware Тимоти Лестера и «Джоэл о программировании» Джоэла Спольски. А дальше по списку.
Практика
Работа менеджера строится на управлении людьми. Проблема в следующем: чтобы стать хорошим IT специалистом, нужен лишь компьютер, интернет и желание; хорошим менеджером без практики стать вряд ли получится.
Ответственность
Еще один момент, которые многие упускают. В любых ситуациях за всё, что происходит в команде разработчиков, ответственность должен нести менеджер (руководитель).
Еще раз повторюсь: за все косяки в команде должен отвечать менеджер.
В век скрама и гибких методологий ответственность размазывается среди членов команды, руководителей и заказчиком, то есть отсутствует персональная ответственность. Не нужно говорить, что это очень выгодно компаниям и самим разработчикам.
Пример из жизни: как-то задал вопрос своему менеджеру, кто возьмет на себя ответственность за нереальную оценку, отсутствие квалифицированных кадров и внедренную методологию управления под названием scrumно. На что получил удивленный ответ: все. При персональной ответственности за свою работу ничего подобного бы ни было. Думаю, не нужно говорить, что проект с треском провалился, и никто при этом не понёс персональное наказание.
Понимать и нести персональную ответственность за себя и своих подчиненных — это одно и самых важных свойств хорошего менеджера.
Кстати, есть еще один побочный эффект: из-за, не побоюсь этого слова, тупых менеджеров некоторые нормальные специалисты меняют место работы, а некоторые начинают склоняться к мысли, что лучше вообще работать без менеджеров (статьи на подобную тематику легко можно отыскать в интернете).
Далеко ходить не надо: в одной компании я и мои коллеги в течение нескольких месяцев скрывали реальное положение дел от менеджера, чтобы он не дай бог не вмешался в процесс разработки и не похерил всё то, что без его участия отлично работало.
Также несколько раз наблюдал ситуацию, когда менеджеры через некоторое время отказывались от своих должностей и обратно превращались в разработчиков. Причин несколько: рост зарплаты, как правило, незначительный (если вообще есть), а обязанностей и головной боли — на порядок больше.
К тому же ситуация, когда разработчик зарабатывает больше своего менеджера, — не редкость в IT компаниях, хотя в других сферах такое случается крайне редко. Этим также можно объяснить нежелание многих технарей превращаться в менеджеров.
Вместо заключения
Менеджер должен обладать харизмой, иметь огромное количество знаний, быть авторитетом для своих подчиненных. Всё это нужно умножить на техническую подкованность. У вас уже работают такие люди? Ваша задача — сделать всё, чтобы их не заполучили ваши конкуретны.
А разработчикам нужно заранее ответить себе на вопрос, хотят ли они в будущем стать менеджерами, и если ответ положительный — начать к этому готовиться за несколько лет.
