Письменные роли менеджера по разработке программного обеспечения [закрыто]

62

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

Как вы думаете, какова роль менеджера по разработке программного обеспечения?

Гравитон
источник
1
Отличное резюме, чтобы напомнить о том, что делает инженер-менеджер. Поместите его на свой рабочий стол и вернитесь к нему, если у вас возникли сомнения или вы столкнулись с трудностями при управлении своей командой.
JKK

Ответы:

100

Говоря как кто-то на работе (который также был разработчиком), я должен сделать следующее:

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

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

  • Планирование проектов и определение приоритетов конфликтов ресурсов, потребностей клиентов, вопросов поддержки и тому подобное. Я склонен быть человеком, который говорит, что этот клиент имеет приоритет над этим, или что эту ошибку нужно исправить, прежде чем она будет отправлена, но это может быть известной проблемой.

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

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

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

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

  • Делать всю администрацию и вещи, которые требует организация (и закон)

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

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

Джон Хопкинс
источник
3
Позднее +1 за отличный ответ я нашел полезным.
Дэн МакГрат
3
Это было добавлено в мой список «Чтение» с пометкой «снова и снова». Мудрые слова.
Эндрю Ашбахер
1
Я хотел бы немного поговорить о том, что вы сказали, а именно: «в общем, вы слишком прочны, чтобы оставаться в курсе долго». У меня немного другое представление о том, что такое менеджер по разработке, но в этом отношении я считаю, что менеджер по разработке должен как минимум знать о том, что является самым последним и самым лучшим, и понимать его на высоком уровне. Я первый, кто признает, что пить из пожарного рукава, не пролив ни капли, невозможно, но факт в том, что очень мало новых концепций, которые поражают нас в повседневной жизни.
Эрик Смит