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

63

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

teamwork management

— Сентил Кумаран
источник

10

Какой процент от всех команд разработчиков программного обеспечения мог бы работать таким образом, не мешая эго и повесткам дня?

— Оз

30

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

— Апсиллеры

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

— комнат

2

Сравнительно недавнее письмо Рэндса вращается вокруг некоторых из этих проблем; Я даю это печать рекомендации. (Не говоря уже о том, что у него много других замечательных работ по менеджменту!)

— Яри Кейнянен

112

Я не вижу, как они в настоящее время увеличивают ценность и достаточно ли планирования встреч, бронирования мест и других административных функций для их роли?

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

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

— Telastyn
источник

4

И они будут намного лучше защищать зарплату / повышение.

— Джеффо

20

Очень +1. Время от времени мы получаем «утечки» через систему и небольшое представление о том, через что проходят наши менеджеры и особенно наш владелец продукта. Я не хочу иметь дело с этим ежедневно.

— Изката

1

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

— Сентил Кумаран

17

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

— Дэвид Наварре

5

Это снова и снова. Даже для технического менеджера это все еще большая часть их работы.

— Эрлз

36

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

Хороший менеджер - это голос вашей группы для всей компании.

— Майкл Браун
источник

4

Цитата Джоэля, вероятно, адаптирована отсюда?

— MarkJ

29

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

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

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

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

— hardmath
источник

6

Разработчики видят деревья. Их менеджеры видят лес.

— Дэвид Наварре

9

@DavidNavarre - нетехническим менеджерам ИМО трудно что-либо увидеть ...

— Вектор

13

@Vector: то, что вы, похоже, имеете в виду, это не нетехнические менеджеры, а некомпетентные менеджеры.

— Ли Райан

@Vector: Это напоминает PHB Дилберта , но я не думаю, что это то же самое, что нетехнический менеджер.

— hardthth

@hardmath - я понимаю :-) Ваш ответ действительно включен в то, что предоставил ОП, согласно редактированию. Суть, которую я пытаюсь сделать, заключается в том, что в технических вопросах они должны быть решительными. У меня есть некоторый горький опыт в этих вопросах ... «Немного знаний - опасная вещь» - я уверен, что вы поняли мой дрейф. Смотри мой ответ.

— Вектор

12

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

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

Тот факт, что кому-то не хватает таланта, навыков или знаний в области, не означает, что он не может идентифицировать тех, кто делает. Признание таланта - это талант.

— JeffO
источник

1

Кроме того, нетрадиционный менеджер доступен для удовлетворения потребностей команды вместо написания кода.

— Джеффо

1

«Наряду с другими упомянутыми преимуществами нетехнический менеджер может лучше принимать окончательные решения, когда эксперты находятся в тупике». Не эксперт имеет наименьшее количество информации по конкретной теме. Он может принять «сторону» только у того, кто обладает наибольшим опытом в этой области (или выбрать решение, которое он считает лучшим). Но это не значит, что его решение верное. Решение от менее опытного программиста может быть лучше, но неспециалист не мог этого знать. joelonsoftware.com/items/2006/08/08.html

— Кристиан П

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

— Стивен

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

— Кристиан П

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

— вектор

2

Достаточно ли планирования встреч, бронирования мест и другой административной работы для их роли?

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

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

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

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

— Вектор
источник

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

— bobo2000

@ bobo2000 - я упомянул MLB , а не спорт в целом.

— вектор

-1

По моему опыту, нетехнические менеджеры лучше всего подходят для этой роли, помимо того, что они добавляют ценность, избегая того, чтобы компании мешали работе разработчиков, они способствуют партнерству между разработчиками (потому что хорошо известно, что разработчики являются интровертами http://www.unwesen.de/ 2012/03/16 / introversion-производительность-работа-окружение / ), хорошие позволяют команде работать в своем ритме, но заботятся о видимости.

— cesarggf
источник

2

Ваш ответ будет более убедительным, если вы процитировали некоторые внешние ссылки или расширили свои принципы. Заявление cause it's well know[n]является слабой формой доказательств.