• Скотт Беркун: должны ли менеджеры уметь писать код?

    Posted on April 16th, 2010 Александр Орлов 1 comment

    Разговоры о том, должен ли менеджер уметь писать код, ведутся двести пятьдесят лет. Действительно, такое ощущение, что они начались еще до того, как появился код, программисты и менеджеры. :)

    На эту тему даже разгорелось оживленное обсуждение в мастер-группе Happy PM. И как пошутили там ребята, это обсуждение прочел Скотт Беркун и ответил в своем блоге. :) И добавить к Скотту особенно и нечего. Хорошо написано. Женя Коломыдцев, с которым мы познакомились недавно в Омске, взял и перевел эту статью За что Жене, конечно, большооое спасибо!

    Должны ли менеджеры уметь писать код?

    Автор: Скотт Беркун

    Перевод: Евгений Коломыдцев

    Я часто вижу, как люди, работающие в техническом секторе, например, команды разработчиков, спорят на эту тему. В бытность мою в Microsoft мы все время об этом спорили, в особенности, должны ли уметь программировать люди, работающие на позиции Program Manager (менеджеры проектов в небольших группах). К сожалению, никто и никогда не исследовал вопрос, влияет ли умение программировать на успешность человека как менеджера.

    Вкратце, это зависит от того, что входит в ваши обязанности менеджера. Если вы занимаетесь только тем, что управляете разработчиками ПО, вам лучше уметь программировать и иметь опыт работы программистом. Отнесем таких менеджеров к категории А. Если вы входите в эту категорию, лишь небольшая часть вашего времени (5-20%) должна уходить на написание кода, и чем больше ваша команда, тем меньше времени у вас должно уходить на код.

    Если же вы ­- босс, ваша основная задача – делать то, что отдельные программисты делать не могут. Вести политическую борьбу, чем не может заниматься другой член команды. Отстаивать новые инициативы и направления. Разрешать некрасивые конфликты. Консультировать. Заниматься организацией тренингов, выбивать бюджет, повышать квалификацию своих сотрудников и находить новых – чтобы команда не переставала расти в количестве и профессионально.

    Менеджеры, выросшие из программистов, печально известны тем, что, сохраняя первоначальные профессиональные навыки, полностью пренебрегают большей частью обязанностей, о которых не забывает хороший менеджер. Технический сектор заполнен такими людьми. И это прискорбно. Во многих случаях, на их месте лучше бы оказаться людям категории Б.

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

    • Есть ли между вами и командой взаимное доверие? Речь не о том, как это доверие заслужить, но ответьте на простой вопрос: доверяют ли вам программисты? Они могут вам либо доверять, либо не доверять, и неважно, насколько вы сильны в программировании. Если вы защищаете своих программистов, помогаете им работать эффективно, помогаете им избегать скучных совещаний и других глупых занятий, вы завоюете их доверие. Доверяя вам, они будут вести себя как ваши партнеры и союзники, что поможет обеим сторонам раскрыться и работать в полную силу, независимо от ваших знаний. Как ни странно, часто доверие можно заслужить, вскрывая обман, или, чтобы не создавать конфликта, задавая уместные, умные, неприятные вопросы, которые могут показать, что вы не только понимаете, о чем речь, но вы проявляете искренний интерес. С другой стороны, как лидер, вы должны проявить доверие первым и отказаться от желания контролировать каждый шаг работы, которую вы не понимаете. Иногда можно просто оставить программистов в покое, после того, как вы вместе с ними достигли кристально четкого понимания задач и согласовали сроки их выполнения, и это может стать примером удивительно эффективного стиля управления.
    • Способны ли вы распознавать ложь? В разговоре с подчиненным, когда он заявляет, что поставленная задача сложна, зачастую приходится мысленно прикидывать, что задача а) действительно сложна; б) он не знает, как проще ее выполнить; или в) он просто не хочет этим заниматься. Хороший лидер достаточно компетентен в понимании компромиссов и знает, как устроено программное обеспечение, чтобы вовремя задать пару неприятных вопросов, а то и вскрыть чей-нибудь блеф.
    • Воспринимаете ли вы моральное состояние команды? Моральное состояние не сводится к одним лишь специальным мероприятиям. Кто-то должен понимать, что мотивирует команду разработчиков. Что их вдохновляет, и что подавляет. Возможно, я знаю больше о программировании, чем сотня программистов, которые на меня работают, но если мне не важно, что они чувствуют по отношению к работе, если я не способен их стимулировать, не помогаю им понять, что работа, которую мы делаем, важна, к чему мои знания программирования? Они бесполезны. Лидер, который способен понять, мотивировать, воодушевлять, убеждать, или иногда просто развеселить команду, вносит свой особый вклад, который вряд ли внесет кто-то еще.
    • Понимаете ли вы принципы программирования? Многим бы не помешало пройти краткий курс «Программирование для менеджеров». Есть принципы, которые действительно важны: производительность, объекты, проблемы, связанные со спецификациями, API, основы тестирования, и т.д., и для их понимания не требуются глубокие познания в программировании. Даже немного знаний о том, как работать с HTML/CSS, Flash, или макросами в Excel, преподанных должным образом, могут дать чувство понимания применяемых принципов, и это именно то, что нужно. Не обязательно самому быть технарем, чтобы говорить с технарями и понимать их язык.
    • Можете ли вы помочь программистам принимать верные решения? Самое верное решение – всегда принимать верные решения. Человек в роли лидера (будь то президент, начальник или родитель) часто попадает в ситуации, когда он не являются экспертами, но вынужден работать с экспертами в какой-то области, кто знает намного больше его самого. Есть род мастерства, особый коммуникативный и мыслительный навык, который помогает максимально использовать способности эксперта в принятии решения. Попробуйте задать разработчику два простых вопроса: 1) попросите назвать 3-4 варианта решения проблемы; и 2) попросите назвать плюсы и минусы каждого решения. Это направит разговор в нужное русло, и зачастую верное решение само всплывает на поверхность в ходе обсуждения. Сам факт того, что его слушают, когда программист объясняет разницу между вариантами решения, заставляет его лучше обдумывать решение, в то время как лидер получает важную информацию о контексте задачи, плюсах и минусах того или иного решения, без необходимости самому становиться экспертом во всех этих вопросах. Менеджерам нет нужды быть экспертами – им нужно уметь извлекать практическую пользу из общения с экспертами в любой области. Другими словами, речь идет о своего рода помощи, хотя многие не захотят признавать, что секрет успешного лидерства скрыт в чем то, что настолько завязано на эмоциональном общении людей.
    • Можете ли вы позволить разработчикам помочь вам в принятии верных решений? Часто случается, что описанный подход взаимен. Способны ли вы воспринимать идеи по дизайну, маркетингу или менеджменту от команды разработчиков? Точно так же, как у вас есть представление о том, чем должны заниматься программисты, у них есть свое видение того, чем занимаетесь вы. Еще один способ быстро завоевать доверие – дать им увидеть, что их предложения или обратная связь находят у вас отклик, что к ним прислушиваются, и их отношение к вам изменится.
    • Можете ли вы представить работу программистов в выгодном свете перед другими людьми? Еще одна функция лидера – докладывать о проделанной командой работе, показывать эту работу посторонним. В такой ситуации, скорее всего, придется отвечать на вопросы, касающиеся технической стороны дела, и лидер должен уметь ответить хотя бы на часть из них. Обычно, если лидер вовлечен в принятие решений и понимает учитываемые компромиссы, он сможет ответить на большинство вопросов о проделанной работе. Если лидер этого сделать не сможет, и ему приходится всегда окружать себя программистами, чтобы не попасть впросак, его ценность для команды сомнительна.

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

    Оговорка: Разумеется, ничто не мешает человеку быть отличным программистом и успешным лидером одновременно. Такие люди существуют. Но их встретишь нечасто. А скольких за свою карьеру встречали вы?

     

    One response to “Скотт Беркун: должны ли менеджеры уметь писать код?”

    1. [...] что и обсуждать. Скотт Беркун достаточно подробно раскрыл тему, [...]

    Leave a reply

    You must be logged in to post a comment.