Является ли ротация ведущего разработчика хорошей или плохой идеей?

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

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

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

Это хорошая идея? Почему или почему нет?

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

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

Не вращайся.

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

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

1. Умеет делегировать.
2. Находится под контролем.
3. Является опытным разработчиком.

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

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

Ведущий разработчик состоит из двух частей:

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

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

Это не обязательно плохая идея, при условии, что разработчики вовлечены и (в идеале) способны.

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

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

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

Ротация ведущего разработчика на основе времени - плохая идея.

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

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

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

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

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

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

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

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

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

Организационные диаграммы редко отражают, как на самом деле работают люди. Особенно идеализированные графики вроде «плоской команды».

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

Кроме того, поскольку вы упомянули, что менеджер нетехнический, этот человек все еще может управлять процессом RSA и облегчать связь. Вы также можете назначить конкретное МСП в качестве лидера для каждого проекта в отдельности, чтобы помочь в упрощении и формировании их индивидуальных навыков.

Почему команда разработчиков не голосует анонимно? Я бы использовал льготное голосование.

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

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

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

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

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

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

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

Там должен быть лидер команды так же, как капитан на достаточно большом корабле.

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

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

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

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

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

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

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

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

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

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