Мешают ли разработке Scrum-мастера, проджекты, продакты, маркетологи и прочие менеджеры? Или нет

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

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

Мнения про «буллщит» возникли не на пустом месте. Большинству, если не всем, разработчикам приходилось пережить по крайней мере одного ужасного менеджера, который всё испортил.

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

Я работал в крупной ИТ-компании. И чтобы достучаться до кого-то из другой команды, мне нужно было пройти иерархическую цепочку: сначала прийти к менеджеру, потом к директору, через день или неделю я получал электронное письмо с ответом. Это необязательный процесс, никто даже не решил, что должно быть устроено так, но из-за иерархии так сложилась корпоративная культура.

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

Разработчики: «Перерабатываешь? Слишком много разных обязанностей? Не можешь писать достаточно кода? Нет сплочённости в команде? Типичные ошибки руководителя, попробуй поискать работу на другой должности».

Разработчики: «Нас, как разработчиков ПО, недооценивают! Люди обращают на нас внимание только тогда, когда что-то идёт не так!»

Также разработчики: «Менеджеры такие бесполезные, LMAO».

Я работаю на своей нынешней работе уже 12 лет. Первые три года у меня не было менеджера. Затем я перешёл в отдел разработки, где у меня был так себе менеджер. Он «сгорел» через несколько лет.

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

Но в итоге его уволили, а другого разработчика в команде повысили до менеджера. Он тоже был хорош — ставил задачи и доверял нам работу. Но в итоге и он уволился.

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

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

Я работал в компании, где не было менеджеров по продуктам, Scrum-мастеров и прочих сотрудников, которых многие разработчики считают бесполезными. Были только отдел продаж, разработка ПО и гендиректор, перед которым все отчитывались. Это самая худшая работа, которая у меня когда-либо была.

Разработчики развиваются без вмешательства злых менеджеров и невежественных руководителей. Потрясающе! Идеальная среда для гениального начинающего инженера! Звучит как рай, верно? Это не так. Это был полный хаос.

Никто не знал, что они должны делать и какие стоят приоритеты. Кто-то из отдела продаж сбегал вниз и говорил: «Я только что продал A крупному клиенту! Вам нужно создать A сейчас!». И все шли кодить A. Затем приходил гендиректор и спрашивал: «Почему вы не делаете B? Мне лично нужен B, пожалуйста, покажите результаты! И любые изменения в продукте теперь должны быть лично одобрены мной».

Тест Джоэла составил 0 баллов из 12. Поскольку это была просто команда программистов, ни у кого не было времени написать спецификацию или составить план сборки/выпуска продукта. Это же отвратительные задачи, которыми занимаются глупые руководители и менеджеры.

Не было поддержки клиентов. Если у клиента ломалось ПО, некому было его поддержать — разработчики отправляли все жалобы гендиректору. Тот просто сошёл с ума.

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

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

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

Обычные менеджеры не ухудшали и не улучшали производительность, просто делали своё дело, путь и часто незаметное для меня. Но в конце концов, счастье — это реальность минус ожидания.

Закон Старджона: 90% чего угодно на свете — дерьмо. Это относится и к менеджерам, и к инженерам. Разверните свои аргументы и спросите, что, если хорошим менеджерам приходится иметь дело с дрянными инженерами, потому что их тоже много?

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

Если каждый будет проецировать свои страхи, мы увязнем, делая пессимистичные предположения. Будем скучать по «хорошим» сотрудникам, ослеплённые идеями, обобщающими людей и их роли. Если мы не остановимся и не увидим хорошее, то утянем вниз команду.