Как структурировать команду разработчиков

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

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

• Пусть младшие разработчики отчитываются перед старшими. Это сокращает время, затрачиваемое на разработку лучшими специалистами.
• Разделите команду по программному продукту, например, разработчики 1-6 работают в интрасети и 7-11 работают на внешних сайтах, причем каждый раздел имеет нового руководителя группы (возможно, новое описание работы с большей ответственностью за управление / наставничество / обучение, чем у нынешних старших разработчиков) ). Это добавляет искусственные бункеры и может затруднить работу «разработчика интранета» для работы на внешнем веб-сайте, если я этого захочу.
• Сохраняйте структуру плоской и добавляйте управленческую поддержку в форме менеджеров проектов / администраторов команд, чтобы снять напряжение. Это не решает проблему, так как команда не может расти так вечно.

Есть ли стандартный способ решения этой проблемы, который мне не хватает?

Если нет, то как другие из вас решили эту проблему?

Несколько быстрых мыслей:

• Подкоманды - хорошая идея: 11 прямых отчетов без какой-либо структуры слишком велики для работоспособной команды (у вас не будет достаточно времени для прямого обучения, а встречи с таким большим количеством людей, как правило, будут непродуктивными).
• Подумайте о том, чтобы отделить операции от разработки - это немного другой набор навыков, и их прерывание из-за операционных проблем в течение всего дня может серьезно повредить производительности разработки проектов.
• В результате первых двух пунктов, я думаю, у вас должно быть, возможно, 3 подгруппы - Интранет, Внешние сайты и Операции. Операторы будут заниматься всеми ежедневными проблемами / исправлениями и т. Д., В то время как две команды разработчиков сосредоточатся на предоставлении новых проектов / ценности для бизнеса.
• Цикл людей между командами на регулярной основе. Это может быть случайным (например, когда люди проверяют код в другой подгруппе), для проекта или на постоянной основе. Но убедитесь, что вы понимаете, что командные роли будут меняться всякий раз, когда есть потребность в бизнесе - никто не "вечно" владеет определенной ролью.
• Не добавляйте больше менеджеров / администраторов - это верный способ снизить общую эффективность / производительность ваших команд. Попросите самого опытного человека в каждой подгруппе сыграть командную / тренерскую роль. Удостоверьтесь, что они видят здесь свою роль в качестве коучинга и в достижении успеха всей команды, и убедитесь, что они оснащены для того, чтобы вести себя таким образом, а не действовать как «менеджер задач».
• Ваша роль должна быть направлена ​​на управление внешними заинтересованными сторонами, расстановку приоритетов ресурсов / задач в группе и выполнение функций «главного тренера». Вам нужно будет справляться с периодически возникающими проблемами в подгруппах, но в целом вы должны побуждать их решать проблемы самостоятельно, не обращаясь к вам.
• Если вы очень техничны, вы также можете сыграть роль архитектора / дизайнера. Если нет, найдите кого-то, кто может, в команде или в другом месте .....

Кроме того, всегда стоит идти и (пере) читать Agile Manifesto , и особенно двенадцать принципов .

Эта структура будет в основном depend on project specifications

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

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

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

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

• Менеджер проекта, который вел графики, отвечал за требования и согласования, а также общался. Все пунктирные линии тоже отчитывались перед этим человеком. Специалист по документации (который иногда был также премьер-министром, но только когда экспертиза позволяла).
• Сочетание 1-3 разработчиков или старших разработчиков, в зависимости от потребностей проекта.
• Младший разработчик, когда доступно.
• Кто-то назначен из пула QA.
• Специалист по инфраструктуре (роль, часто выполняемая менеджером, так как он также имел солидную компетенцию SA).

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

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

Чтобы процитировать статью в вашем контексте:

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

Фактическая структура управления / HR не имеет отношения к этому.

Есть ли стандартный способ решения этой проблемы, который мне не хватает?

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

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

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

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

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

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