В ИТ много неугасающих дискуссий: микросервисы или монолит, доступный или открытый код. Еще один спор из этой же категории: должен ли руководитель разработки писать код?

Мы в Beeline Cloud решили обсудить различные мнения по этому поводу: программировать и тем самым поддерживать авторитет среди коллег или сосредоточиться на развитии команды? Разобрались, какие аргументы приводят сторонники и противники «управленцев-кодеров», а также сделали подборку книг для начинающих путь в роли руководителя разработки.

Мнение: менеджер должен засучить рукава и писать код

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

Достаточно распространено мнение: «Я думаю, что руководству не нужно сторониться кода, если оно ценит свой навык программирования. Тяжело управлять технической командой, когда ты работал с OSGi, а все уже используют Kubernetes». По этой причине некоторые компании делают участие в разработке обязательным требованием к тем, кто претендует на позиции управленцев в технических командах. Например, в Google, GitHub и Basecamp менеджеры инженерных команд продолжают регулярно коммитить и на собственном примере показывают, как следовать корпоративным стандартам. 

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

Еще один аргумент в пользу программирующего руководителя разработки — такой специалист «бустит» мораль коллектива. Еще в 2015 году специалисты из университета Ошкоша, Уорикского университета и Бизнес-школы Байеса провели исследование в попытке оценить, насколько уровень технических компетенций начальника влияет на настроения подчиненных. Они изучили порядка 27 тыс. записей из архива лонгитюдных исследований Бюро трудовой статистики США [цель их сбора — отслеживать жизненный путь американцев на протяжении десятилетий]. В выборку попали люди из разных сфер деятельности, в том числе представители технических профессий — программисты, системные аналитики и не только. В первую очередь исследователей интересовали ответы на вопросы вроде: «Ваш руководитель хорошо понимает суть рабочих задач?» или «Компетентен ли ваш начальник?». Затем команда сопоставила их с ответами на вопросы об общем ощущении от работы и выяснила, что критически важны тут именно технические навыки: тот факт, что начальник может сам взяться за сложную задачу, положительно сказывается на морали сотрудников.

Во многом образ программирующего управленца формирует общепринятые практики найма в индустрии. Отбирая кандидатов на руководящие позиции, рекрутеры часто обращают внимание на умение писать код. Технический директор Amazon Дэйв Андерсон посвятил этому целую статью: по его словам, в ряде крупных американских ИТ-компаний (Amazon, как отмечает автор, к их числу не относится) существует почти навязчивая установка: «программирование — обязательный навык для всех технических менеджеров». Неудивительно, что в подобной обстановке у руководителя разработки могут возникать опасения: если он перестанет кодить, команде не за что будет его уважать.

Другая точка зрения: у менеджеров есть дела поважнее

Среди разработчиков также встречается иное мнение: руководитель должен брать на себя задачи программистов только в крайних случаях, потому что у него есть более важные обязанности вроде непосредственного управления командой, оптимизации рабочих процессов, регулярных встреч и не только. Практикующие менеджеры инженерных команд часто говорят, что эти обязанности отнимают большую часть рабочего времени, поэтому на программирование ресурсов почти не остается. Даже в сравнительно компактной команде из 10–12 человек менеджер зачастую может уделить разработке не более 20% своего времени (понятно, что в больших командах и/или в крупных компаниях со множеством бюрократических процессов эта цифра будет еще меньше).

В той же Amazon, к примеру, предполагают, что руководитель разработки не должен писать код, а вместо этого ему следует заниматься менторством сотрудников и операционными задачами. А вышеупомянутый техдир Amazon Дэйв Андерсон вообще не считает программирование обязательным навыком для руководителей ИТ-команд — он убежден, что основные сложности у них (и, как следствие, у команды) связаны с тем, что: 1) менеджер не понимает потребности пользователей и 2) менеджер не умеет грамотно распределять время, усилия и ресурсы команды (и ни одна из этих проблем не связана напрямую с неумением руководителя писать грамотный код).

При этом, если менеджер не справляется с этими задачами, никакие его навыки программирования не спасут команду от сорванных сроков и проблем с продуктом. Неслучайно многие талантливые разработчики, вынужденно оказавшиеся на руководящих должностях, часто испытывают трудности: при всем их техническом «багаже», у них не хватает компетенций для эффективной управленческой работы. В итоге, по оценке Марселя Уикса, вице-президента по разработке в компании Figma, примерно половина программистов, которые заняли позицию руководителя разработки, возвращается к прошлым обязанностям.

Есть и другие распространенные мнения: «Хороший менеджер не должен стоять на "критическом пути"» и «Если вы будете браться за ключевые задачи, при этом отвлекаясь на управленческие дела, работа команды начнет проседать». Но «программировать» — не обязательно означает «стоять на критическом пути и блокировать работу остальной команды». Антон Зайдес, технический руководитель и основатель блога для руководителей разработки, прошел путь от «программирующего» менеджера к «не программирующему». И он отмечает: если у управленца (вопреки обстоятельствам) все же есть время и желание писать код, найдутся задачи, за решение которых команда будет благодарна. Они могут быть связаны с правкой залежавшихся в бэклоге багов, устранением технического долга: «Или мое любимое: автоматизация процессов, раздражающих инженеров». Примером может быть разработка чат-бота для быстрого извлечения информации из внутренней базы знаний.

Если в компании нет жесткой позиции касательно того, должен ли менеджер инженерной команды программировать, важным фактором остается личное отношение к процессу. Если разработка приносит удовольствие, нет смысла от нее отказываться. И, напротив, продолжать писать код через силу едва ли оправданно — удовольствие от работы играет не последнюю роль в достижении результатов, как личных, так и командных. Уже не раз доказано, что оно повышает мотивацию, продуктивность, снижает стресс и, как следствие, управлять коллективом становится проще.

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

Что почитать начинающим руководителям разработки

> Управление разработкой для всех нас (Engineering Management for the Rest of Us). Эту книгу написала Сара Драснер, у нее за плечами десять лет опыта работы на позициях от лида до вице-президента разработки в компаниях разного масштаба — вплоть до Microsoft. Как говорит автор, она написала такую книгу, какая пригодилась бы ей самой в начале управленческого пути: «Кажется, что есть миллионы статей о программировании, но профессии руководителя разработки посвящена лишь горстка материалов. Почему? Довольно сложно говорить о том, что включает в себя работу с людьми, ведь поведение людей недетерминировано».

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

> Искусство управления разработкой (The Art of Engineering Management). Свободно распространяемая книга, которую написал менеджер с более чем десятилетним опытом работы. Он руководил разработчиками как в стартапах, так и в крупных компаниях — например, в Wildlife Studios [входит в топ-10 крупнейших разработчиков мобильных игр].

Книга ориентирована на специалистов, которые только встают на путь управленца. Автор начинает с основ и дает самую базу, потому что «роль и задачи руководителя разработки могут сильно отличаться от компании к компании». Например, он разбирает ключевые задачи, подходы к управлению процессами, дает рекомендации. Правда, стоит отметить, что работа над книгой еще не завершена, и многие главы до сих пор не дописаны.

> Как управлять эффективными инженерными командами (Leading Effective Engineering Teams). Это книга Эдди Османи, который больше десяти лет проработал менеджером в Chrome. Она будет полезна руководителям инженерных команд, желающим «подтянуть» навыки организации процессов в коллективах любых масштабов.

Многие идеи, изложенные в книге, построены на выводах, сделанных в ходе анализа результатов работы проектов Oxygen и Aristotle. Эти инициативы были запущены в Google с целью выявить качества «идеального» менеджера и характеристики эффективной команды (компания проводила опросы, оценивала ключевые показатели эффективности, анализировала интервью коллег — в том числе, покидавших компанию).

Среди тем: ошибки, которые чаще всего совершают на должности руководителя разработки, как создать доверительную атмосферу внутри команды, помочь сотрудникам развиваться, подсветить работу коллег на корпоративном уровне (все это с примерами из практики автора).

Beeline Cloud — разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

Что еще почитать в нашем блоге на Хабре:

• Выходные — для развития: Пара открытых книг и ресурсов для (глубокого) погружения в инженерию данных

• Карьерный буст в новом году: читаем научно-техническую литературу эффективно — инструменты и советы ученых

• Вакансия Шредингера? Зачем компании размещают «ненастоящие» объявления о работе — причины и признаки «призраков»

• Визитка вместо резюме? Симуляция жидкости, мини-игры и другие проекты для самопрезентации на печатных платах