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

- В каких ситуациях вы бывали, когда попадали в ловушку становления микроменеджером?

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

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

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

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

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

Мне нравится совет Джоэла о Command and Conquer и The Herd of Coconuts :

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

• каждое решение принимает человек, обладающий наибольшим количеством информации.

• управление крайне плоское. В идеале у менеджеров просто нет времени, чтобы залезть в свои отчеты. Возможно, вам будет интересно прочитать о заводе GE в Северной Каролине , на котором работает 170 сотрудников, и все они подчиняются непосредственно директору завода.

Избегайте управления «Командуй и властвуй» или «Бей и беги», если только в вашей команде разработчиков нет «Кокосового стада». Другими словами, менеджер должен оставить разработчиков в покое .

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

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

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

Задавая вопросы, команда принимает свои собственные решения, и они чувствуют, что у них есть пространство и право собственности в своей области. Они не чувствуют, что ими управляют на микроуровне.

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

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

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

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

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

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

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

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

Если вы говорите людям , как что-то делать в дополнение к тому , что делать, вы управляете на микроуровне.

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

Лучшая стратегия — понять, что микроуправление никому не выгодно.

Лучший способ избавиться от микроменеджмента — просто остановиться. Легче сказать, чем сделать, но если вы хотите стать успешным менеджером в долгосрочной перспективе, это то, что вам нужно. Будьте готовы, если ваши люди привыкли к тому, что вы вмешиваетесь, чтобы убрать их беспорядок, они могут несколько раз упасть лицом вниз, потому что вы научили их не заботиться о себе. Пусть убирают за собой. Только так они разовьют в себе необходимые вам навыки. Если они не могут этого сделать, наймите кого-нибудь другого. Это краткосрочная боль для долгосрочной выгоды. Ваша семья оценит, когда вас не заставят работать по 70 часов в неделю из-за того, что вы не обучили свою команду должным образом.

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

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

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

Кроме того, хорошо иметь дату регистрации, чтобы можно было измерить прогресс в достижении цели.

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

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

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

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

Микроуправление является индикатором проблем в планировании качества . Вам не удалось институционализировать четкие цели в области качества. Вот почему очень часто вам приходится вмешиваться и снова обсуждать их.

Как только вы видите необходимость обсуждать «что неправильно, а что правильно» в технических решениях, принимаемых инженерами – возвращайтесь к задачам качества. Они указаны в письменной форме? Действительно ли они объективны?

Еще немного о микроменеджменте: http://www.yegor256.com/2015/09/22/micromanagement.html

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

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

Джерри Вайнберг написал

«Управление, сделанное правильно, - очень тяжелая работа».

Он был абсолютно прав. Я бы прочитал его книгу « Конгруэнтное управление командами ».

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

Надеюсь это поможет.

Признание проблемы — первый шаг.

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

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

Признание проблемы, а затем понимание ее первопричины позволит вам увидеть разницу.

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

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

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

Опять же, как руководитель проекта, вы должны руководить, а не делать.

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

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

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

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

Меня зовут Дана, и я работаю менеджером проекта в цифровой студии. У меня есть 3-летний опыт работы в этой области, в котором я помог создать несколько веб-приложений и мобильных приложений.

Вот мои ответы, надеюсь поможет:

В каких ситуациях вы были, когда вы попали в ловушку становления микро-менеджером?

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

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

Доверься своей команде! Возложите на них ответственность за выполнение задачи — каждый будет стараться вести себя наилучшим образом, если будет знать, что клиент видит их работу напрямую, а вас нет рядом, чтобы ее подчистить. Они обязательно все проверят дважды и будут более осведомлены о качестве дизайна/кода, который они производят. Будьте терпеливы, они тоже придут к правильным выводам, даже если медленнее вас :). И, возможно, они удивят вас и придумают еще лучшие решения! Просто убедитесь, что вы четко и ясно изложили требования, дайте точные и четкие спецификации для начала. Затем просто «проверьте, чего вы ожидаете» и дайте конструктивный отзыв. Позволяя вашей команде совершать ошибки и учиться на них, вы также позволяете им расти и становиться все более и более уверенными в себе.