Нужен ли команде разработчиков менеджер?

Задний план:

В настоящее время я работаю в команде из четырех человек: 1 менеджер, 1 старший разработчик и 2 разработчика. Мы выполняем ряд индивидуальных внутренних систем / проектов (например, 6-8 недель) для организации, насчитывающей около 3500 сотрудников, а также все обслуживание и поддержку, необходимые для систем, которые были созданы ранее. Нас недостаточно для того, чтобы выполнять всю работу, которая может оказаться на нашем пути - мы недоукомплектованы. Руководство признает это, но бюджетные ограничения ограничивают нашу способность привлекать в команду дополнительных членов (даже если мы возвращаем зарплату в виде сбережений).

Изменение

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

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

Я думаю, последний вопрос:

Можно ли запустить команду разработчиков без менеджера? У вас был опыт этого? И что может пойти не так / может принести пользу нам?

В идеале я хотел бы «увидеть свет» и преимущества такого поведения или придумать аргументы против этого.

Чем больше рисков, тем больше вам нужно «воздушное прикрытие». Это то, что действительно должен обеспечить менеджер. Пока команда выполняет работу, менеджер должен следить за тем, чтобы ничто не мешало команде достичь целей команды. Будь то изменение графика, вмешательство команды и торгового персонала, или просто обеспечение того, чтобы команде платили вовремя и чтобы кофемашина оставалась в рабочем состоянии. Действительно отличный менеджер позволяет команде функционировать почти так, как если бы менеджера там не было.

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

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

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

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

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

Простой ответ на ваш вопрос - да, как указали другие люди.

Более полный, но более сложный ответ на ваш вопрос:

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

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

Другие вещи, на которые следует обращать внимание (поскольку в этом много психологии) - это когда руководство сообщает вам плохие новости, но смешивается в какой-то шутке, возможно, упоминает проблему напрямую, а может и нет, но из-за этого невозможно поставить ее под сомнение ( это тонкая и умная техника). Другой, на который стоит обратить внимание, - это 3-часовая встреча, на которой вам представляется план, а в 2 часа 55 минут спрашивают ваше мнение.

Будьте осторожны с управлением, которое «говорит» правильные вещи, в отличие от управления, которое «делает» правильные вещи.

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

Я согласен с ответами выше, но есть важное соображение.

«Менеджер» - это должность, но с точки зрения ролей , менеджер - это тот, кто имеет определенные обязанности . Независимо от того, каковы эти обязанности, переговоры с CxO, составление отчетов, управление отпусками или даже заполнение кофемашины - вашей команде нужен кто-то, кто за это отвечает.

Профи - это может быть один из вас, и это может стать большим стимулом для его / ее карьеры. Остальная часть команды получит кого-то, кто не «назначен сверху», но кто-то, кто глубоко понимает потребности команды.
Конечно, не забывайте договариваться, сколько времени она потратит на управленческие задачи, и что остается для того, что она делала раньше.

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

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

В настоящее время я работаю в небольшой команде без менеджера. Маленькая компания Это работает хорошо.

Ваш пробег может варьироваться.

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

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

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

Сказав, что кто-то старший, кто может повысить ценность, всегда помогает. Даже генеральный директор подотчетен команде менеджеров (совету директоров).

Мои 2 цента ...

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

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

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

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

краткий ответ: да, это может.

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

Может быть, вам нужно объединить свою команду разработчиков с другой, есть ли у вас команда тестировщиков> Было бы лучше использовать один и тот же менеджер для обоих, сохраняя полуавтономную команду разработчиков?

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

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

Хорошо это или плохо, но похоже, что вам нужен тренер игрока. Тот, кто может как управлять командой, так и выступать в ней. В группе из 4 это, безусловно, возможно. В группе из 8 или 10 это не будет. Задача состоит в определении того, кто должен быть этим тренером игрока. По умолчанию это делает вас лучшим программистом, но вы обязательно хотите связать их с администратором? Нет точного и быстрого ответа, кроме как сказать, что высокопроизводительные организации находят способы не заставлять всех своих лучших техников становиться менеджерами.

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

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

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

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

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

• Нужен ли вам кто-то, кто имеет полномочия разрешать споры между членами команды и держать команду сосредоточенной на своевременном выполнении качественной работы?
• Или вам нужен кто-то, чтобы обеспечить прикрытие с воздуха, как указано в верхнем ответе? Управлять графиками, определять приоритеты, вмешиваться между высшим руководством и командой и т. Д.

Так тебе это нужно? Могут ли люди на тех должностях, которые вы отметили, сделать это для вас? Если так, то ты в порядке. Если нет, вы, вероятно, движетесь к катастрофе.

Источник: личный опыт групповых проектов и управляемых и неуправляемых команд.

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

Как отметил С.Робинс, если все члены команды хорошо дисциплинированы, то размещение менеджера может оказаться здесь ненужным узким местом. Некоторые из небольших компаний, в которых я работал, имеют ограничения в области рабочей силы (из-за бюджетных ограничений и других причин), и, следовательно, они стремятся объединить группу из нескольких новичков / юниоров в единую команду, где один парень стоит над ними, управляя ими. ,

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

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

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

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

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

1. Все инженеры отчитываются перед инженером. Инженер-менеджер - это исключительно техническая и функциональная роль, требующая привлечения большего числа подразделений. Эта роль эквивалентна владельцу продукта.
2. Менеджер проекта является отдельной ролью, похожей на мастера схватки, и обычно является подрядчиком в течение фиксированного времени (от 12 месяцев до 18 месяцев, без продления контракта)
3. Менеджер проекта - Scrum Master - полностью отвечает за нефункциональную и неинженерную деятельность

Это сработало замечательно, так как команда разработчиков фокусируется на инженерных аспектах, бизнес-аналитики / владельцы продуктов фокусируются на бизнес-аспектах. Менеджер проекта отвечает за отслеживание задач, отчетность и другие типичные обязанности Scrum Master.

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

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

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

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