вторник, 21 июня 2016 г.

Должен ли менеджер кодить?

DISCLAIMER: данные размышления в значительной степени относятся к менеджерам продуктовых компаний и, как мне кажется, менее применимы к миру аутсорса.

clip_image002

Я уже не раз встречаю мнение о том, что не зависимо от уровня, менеджер в софтверной компании должен оставаться hands on и продолжать кодить (*). Мысль эта несколько необычна, поскольку первое, чему приходится научиться любому начинающему менеджеру в области софтостроения – это как раз-таки, отказаться от этого самого кодирования.

(*) Об этом не раз писал Joe Duffy в постах и твитах, а также Michael Lopp в своей книге “Managing Humans”.

Как и в многих других вещах, ответ на вопрос «Кодить или нет?» несколько сложнее, чем может показаться и не подразумевает бинарной логики в ответе – «да» или «нет».

Почему нужно перестать кодить?

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

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

Активное вмешательство менеджера в детали работы команды имеет ряд негативных последствий:

  • Микроменеджмент.
    Слишком детальное вникание в задачу приводит к микроменеджменту: «Ой, а почему эта задача занимает 3 дня? Я б ее сделал за 2 часа!». «Да ну, а чего это ты тут всего два класса, тут стратегия с синглтоном в декораторе нужны!». «Я поговорил с заказчиком и нам нужно сделать апишку, через которую мы выставим наружу парсинг данных. Для этого нужен метод, который будет принимать строку и возвращать XDocument, а в случае невавлидных данных бросать CustomArgumentExcception.». Все эти советы могут быть полезны, но они подавляют инициативу и переводят общения из русла «проблема-решения» в «решение-кривое решение».
    Хороший менеджер понимает, что с разными сотрудниками нужно говорить на «разном уровне абстракции». Для неопытного человека лучше декомпозировать задачу самостоятельно, а для матерого или около того специалиста, лучше лишь описать задачу и дать ему возможность самостоятельно прийти к решению (которое можно и нужно провалидировать, но свое собственное решение навязывать не стоит).
  • Подавление инициативы.
    Вместо того, чтобы дать команде ошибаться, вы решаете проблему самостоятельно. Да, это решит проблему сейчас, но будет губительным для команды за пределами текущего спринта. Ошибки – это лучший способ познания и попытка оградить от них команду является глупой затеей.
    Даже если сейчас менеджер является самым опытным, он вряд ли сможет принимать решение за всех членов команды, да и просто статистически, все они не могут быть правильными.
  • Совмещать две роли очень сложно.
    Кодирование и менеджмент требуют разного режима работы мозга. Менеджер должен одновременно держать в голове множество вещей: «Потереть с Василием о его проблемах на следующем one-on-one», «Оповестить моего менеджера о возможных задержках в сроках», «Узнать, в чем проблема с текущим релизом у QA-менеджера», «Решить проблему с освещением, которое перенесли уже 4 раза», «Навести порядок с багами» и т.п.
    В процессе разработки фичи используется другой режим работы мозга: нужно погрузиться в одну задачу и думать ее до посинения. Попытка совместить эти два режима работы обычно приводит к плачевным результатам, в результате код, который выходит из-под пера менеджера дурно пахнет, а задачи, которые лежат непосредственно на нем никуда не двигаются.
    Очень хорошо проблемы совмещения заметны по многим тим-лидам, которые зачастую выполняют часть менеджерской работы с множеством митингов, и пытаются браться за сложные задачи на проекте. Обычно выходит плохо и там, и там.

Почему нужно продолжать кодить?

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

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

Вот несколько моментов, почему стоит подумать о поддержании навыков кодирования хотя бы на базовом уровне:

  • Говорить с командой на одном языке.
    Актуальные технические навыки позволяют говорить с командой на одном языке. Даже если какие-то тонкости будут не понятны, то базовые знания позволят понять проблему в общих чертах: «Мы тут боремся с утечками памяти в .NET приложении и стараемся уменьшить время жизни объектов, чтобы они не переживали нулевое поколение». «Мы изначально выбрали изменяемые структуры данных, а теперь отгребаем проблемы в многопоточной среде. Нам нужно сделать неизменяемый фасад, но до этого измерить memory footprint новой версии».
  • Быть частью команды.
    Иногда полезно дать понять команде, что менеджер еще могёт закатать рукава и пофиксить багу. Технари уважают технарей и плохо относятся к руководителям, которые окончательно оторвались от мира разработки. Спускаясь иногда с менеджерских небес на землю позволит менеджеру лучше понять проблемы команды: насколько эффективны инструменты, какие есть проблемы с CI-сервером, что не так с дизайном и покрытием тестами.
    Подобное понимание может изменить отношение к задачам без видимого результата, которые до этого казались бессмысленными, ибо не приносили пользу «заказчику» или «бизнесу».
  • Улучшать процессы исходя из современного понимания технологий.
    Технологии не стоят на месте, а вместе с ними развиваются и процессы. Все эти devops-ы, микросервисы, облака и тучи, все это меняет то, как выглядит процесс разработки. Менеджер должен понимать, как все это влияет на жизнь разработчиков и быть с индустрией хотя бы чутка на одной волне.
  • Декомпозиция задач по стыкам компонентов.
    Помимо кодинга, менеджеру полезно понимать немного в дизайне и архитектуре. Это нужно для того, чтобы задача была разбита по швам системы, а не была ровно размазанна по всем компонентам. И хотя иногда именно cross-cutting изменения полезны, важно, чтобы это происходило осознанно, а не по воле случая.

Итого?

У менеджера есть куча своих задач и он никогда не сможет выполнять работу наравне с разработчиками. Более того, подобные попытки приведут к плачевным последствиям из-за нехватки времени и обилия других задач.

Но другая крайность – тоже дело плохое. Для эффективного управления программистами нужно понимать не только предметную область (что тема отдельного разговора), но и технологии, хотя бы на базовом уровне. В идеале, менеджер должен иметь возможность закатать рукава и пофиксить простую багу, знать как собрать систему и понимать архитектуру на базовом уровне, чтобы иметь возможность распределять задачи вменяемым образом.

Можно взять пример Джо Даффи, который будучи директором по разработке продолжает радовать техническими постами и явно увлекается новыми технологиями.

25 комментариев:

  1. Ну это актуально для менеджера первого звена - тимлида, техлида, архитектора. Дальше - уже совсем не актуально, так как нужно думать более глобально и масштабнее.
    + Часто сталкиваешься с ситуацией когда менеджер пишет код используя явно устаревшие подходы и технологии просто потому что ему уже тяжело уганяться за "молодежью".

    ОтветитьУдалить
    Ответы
    1. Василий, я могу привести примеры из индустрии. Скотт Гаттри написал MVC будучи уже очень высоко. Тот же Хансельман, Даффи, Дон Бокс (да, он впоряде как технарь).

      ИМХО, в этом вся сложность: нужно уметь думать масштабно, но уметь скатываться до мелких подробностей, которые могут повлиять на картину в целом.

      Удалить
    2. Согласен с Василием. У нас менеджером сделали человека, который не был лучшим программистом и частенько делает ошибки при проектировании кода (code design). Помимо работы он очень редко пытается поднять свою квалификацию как программист. Но тем не менее он настаивает что хочет продолжать программировать. Как по мне если он уже избрал путь менеджера и не готов заниматься самообучением вне рабочее время, то дела его программистические будут становить только хуже с каждыи годом. Лучше уже нового сотрудника нанять на его место, чем за ним потом переписывать код или же делать по много итераций код-ревью.
      Я бы согласился с Сергеем, если программист-менеджер очень толковый и постоянно повышает свою квалификацию работая над своими собственными проектами вне рабочего времени.

      Удалить
    3. Хорошее дополнение. Просто хочу напомнить, что я против полноценного коддинга менеджера. Я за поддержание навыков.

      Удалить
  2. Интересная статья, спасибо!
    Есть правда вопросы насчет зон ответственности "менеджера" и разработчиков - эта грань сильно размыта и отличается в разных компаниях, ведь бывают разные подходы. Кажется, соответственно от этого и зависит кол-во и качество кода "менеджера" и требуемых от него знаний технологий и глубины познаний того или иного ЯП.

    ОтветитьУдалить
    Ответы
    1. Да, эту тему я не раскрывал, что могло привести к неоднозначному трактованию статьи:)

      Удалить
  3. Хорошая и очень правильная статья. В далекие 90-е, когда я сам стал начальником отдела ИТ, продолжал кодить, т.к. программист в отделе был я один ;), но со временем, когда отдел стал больше и появились другие программисты, перестал кодить "на продакшн", т.к. просто даже времени порой не хватало.
    Не перестал по счастью "кодить" для собственного удовольствия, так и выучил С# в свое время., чему несказанно рад, так как сейчас живу в Германии и работаю чисто программистом на C#. И вот здесь вижу обратную ситуацию. Шеф порой продолжает кодить, но лучше бы он этого не делал :(. Про ООП знает чисто понаслышке, любитель создания классов-богов по несколько тысяч строк, написания SQL запросов с кучей джойнов, юнионов и группированием (в свое время был администратором баз данных) и прочее, и прочее. Когда он начинает что-то кодить, я готов его убить, потому что все это дерьмо я за ним потом переделываю, т.к. работать с этим просто невозможно. По счастью, в последнее время делает это все меньше и меньше, чему я очень рад.

    ОтветитьУдалить
    Ответы
    1. Сергей, спасибо за дополнение.

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

      Удалить
  4. Sergey, Сможете посоветовать книгу бывшему* программисту, который только начал исполняет роль менеджера.
    Спасибо!

    ОтветитьУдалить
    Ответы
    1. @Alisher: а в какой области книга нужна? В области кодинга или менеджмента?

      Удалить
    2. В области менеджмента. Спасибо.

      Удалить
    3. Сейчас несколько книг навскидку:
      "Мифический человеко-месяц" Фредерика Брукса
      "Человеческий фактор" ДеМарко и Листера
      "Managing Humans" Michael Lopp
      "IT-проекты. Фронтовые очерки" Джо Мараско
      "Как пасти котов" Ханк Рейнвоттер
      "Остаться в живых. Руководство для менеджера программных проектов" Стив Макконнелл

      Удалить
    4. А как же "Джоэл о программировании?" Это лучшая книга для начинающего менеджера. Ну и из более современного "Management 3.0" и "Открывая организации будущего". Последние ближе к философии ценностям, но куда сейчас без этого?

      Удалить
  5. +1, присоединяюсь. Также нахожусь в «переходном возрасте» и до некоторых вещей, которые описаны в статье, пришлось дойти своим путем. Буду благодарен, если порекомендуете литературу/статьи.
    На мой взгляд, микроменеджмент и подавление инициативы на начальном этапе возникает из-за желания контролировать все процессы в команде. Первое чему нужно научиться – делегировать работу другим, четко определяя границы задачи. Если необходимо проконтролировать решение – гораздо продуктивнее будет предварительно обсудить задачу с разработчиком и совместно выработать решение. Людям свойственно отторжение чужих идей и более увлеченная/качественная реализация своих; если у члена команды нет уверенности в своих идеях, то обсуждение с руководителем и ее принятие, пусть и с корректировками, дает чувство движения в правильном направлении.
    Совмещать две роли сложно, но у этой монеты есть и вторая сторона: одинаковые задачи приедаются со временем. Разработчику надоедает код, менеджеру надоедает решать задачи команды и хочется «закатав рукава показать класс». На мой взгляд, возможность отвлечься от менеджмента и выполнить таск/пофиксить баг определённо полезно влияет на продуктивность в управлении. Это конечно, относится к тому случаю, когда менеджер хочет быть и разработчиком тоже.
    Также, важная задача менеджера, пишущего код – сделать себя членом команды и получать фидбек от других ее членов наравне. Это тонкий момент, т.к. можно потерять авторитет, но ИМХО, руководитель должен быть либо более опытный, либо принять тот факт, что менеджер из него лучше, чем программист. В последнем случае нужно выявить достаточно опытного члена команды и позволить ему верифицировать код руководителя. Случай, когда менеджер пишет говнокод и все боятся ему об этом сказать – наихудший.
    Помимо написания кода, есть и другие механизмы, позволяющие руководителю быть в контексте кода, например, ревью, введение в контекст проекта новых членов и т.д. Что думаете на этот счет?

    ОтветитьУдалить
    Ответы
    1. Александр, о какой литературе/статьях идет речь? Кодерских или менеджерских?

      > Что думаете на этот счет?
      Примеры валидные, даже очень.

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

      Отличное дополнение!

      Удалить
    2. для менеджеров из числа программистов :)

      Удалить
  6. У нас первая крайность, и это меня сильно огорчает. Устал уже объяснять всем, что подобное неприемлемо, нужна золотая середина. Отличная статья, как раз ссылка будет под рукой, это на будущее.

    ОтветитьУдалить
  7. Очень часто упоминая руководителя путают техлида, линейного руководителя, менеджера проекта, менеджера среднего звена. Все должны заниматься своим делом. Техлид и линейный руководитель должны кодить, чтобы говорить с разработчиками на одном языке. Да и задач связанных с тем что можно назвать менеджерской работой у них, как правило, не очень много. Менеджер проекта и менеджер среднего звена в рабочее время кодить не должны. А вот кто чем из них занимается в свободное время это исключительно их дело. Когда я много кодил на работе, желания покодить в свободное время было не очень много. Сейчас когда код я пишу достаточно редко, в свободное время поковыряться с какими-нибудь прикольными новыми штуками за удовольствие. Опять же, зайдешь на форум с вопросами по программированию, поотвечаешь, поднимишь свой скил. И новичкам полезно и тебе.

    ОтветитьУдалить
  8. Интересно было бы услышать еще мнение о движении в сторону не тимлида\менеджера проектов, а техлида\архитектора.
    Для последнего, думаю, ситуация сохраняется по аспектам:
    1) Делегирование задач
    2) Уменьшение времени чистого кодинга на сам проект. Вытекает из предыдущего пункта
    Но:
    1) В случае техлида/архитектора нужно сохранять высокий уровень тех.знаний, думаю, понятно почему
    2) В противоположность менеджерской работе большая часть активности будет уделена высокоуровневому проектированию систем, слежением за новыми платформами,технологиями

    ОтветитьУдалить
  9. Все правильно. Если экономить на техлидах и архитекторах. Только тогда будет:
    — Кто открыл на внешку API для просмотра логов нашего сервака?
    — Не я. Я просто сказал девам, что у заказчика так видел.
    — А я подумал, что он сказал нам сделать так же. Я и сделал.
    — Так кто виноват?
    — А хз. Давайте тестировщика накажем.

    А кодит пиэм в свободное время или на барабанах играет — это его личное дело. Лучшие манагеры, с которыми мне приходилось работать, не кодили вообще. Никогда.

    ОтветитьУдалить
  10. Для архитекоров-лидов есть собственная ниша для разработки: скрипты к системе управления проектами.
    Текущие баги, таски по неделям, простаивающие задачи, статус критических тасков... С одной стороны - никак не Rocket Science, с другой - постоянно поручать эту работу кому-то еще - дольше времени уйдет на объяснения и поддержку.
    Из той же серии - управление релизами. Самому держать систему необязательно, но контролировать происходящее - вполне.

    ОтветитьУдалить
  11. Этот комментарий был удален автором.

    ОтветитьУдалить
  12. Писать код в своем проекте? Сильно зависит. Считаю что лиду/архитектору про программирование забывать нельзя.
    В последнее время у меня выработалась нелюбовь к менджерам проектов. Технических решений они не принимают, бизнес решений тоже. Что он тогда делает? Работает прокси информатором и оговаривает сроки? Работает вместо лида с командой? Считаю что менеджер проекта появляется там где слаба бизнес сторона или техническая.
    Идеальной считаю связку бизнес продукт оунер/технический продукт оунер.
    Бизнес оунер - эксперт в том как используется продукт и что можно еще сделать, второй знает как это сконструировать максимально эффективно.
    Допускаю что менджер проектов может быть толкьо в больших компаниях, когда он выполняет роль даминистратора - принеси подай, пойди на ... не мешай.
    Вендору позвонить, сходить попинать другую команду, какие-то аккаунты завести и т.д, ексельнички заполнить и т.д.

    ОтветитьУдалить
  13. Имхо, необходимость выбора между менеджментом и разработкой - это вредное заблуждение. Это как выбор между здоровьем и богатством. Правильнее выбрать оба варианта.

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

    ОтветитьУдалить
    Ответы
    1. Ну, я бы не сказал, что приведенный выбор аналогичен выбору между здоровьем и богатством:). Менеджерская работа требует новых навыков и знаний. Поддержания себя в программистской форме также требует времени и усилий. Приходится выбирать, куда "инвестировать" себя и свое время.

      Можно попробовать делать и то и другое, но есть все шансы остаться ни с чем:)

      Удалить