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

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

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

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

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

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

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

31 голос | спросил 4 revs, 2 users 100%
NickC
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

17 ответов


30

Не вращать.

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

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

  1. Знает, как делегировать.
  2. Контролируется.
  3. Является опытным разработчиком.

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
11

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
6

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
5

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
4

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
3

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
2

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
2

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

Схемы Org редко отражают то, как люди работают на самом деле. Особенно идеализированные карты, такие как «плоская команда».

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
2

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
1

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
1
  1. Вы можете выбрать кого-то из своей команды, чтобы вести свою команду.
  2. Ваш босс может нанять другого опытного человека, чтобы заняться этой позицией.

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
1

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
1

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
0

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
0

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
0

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53
-1

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

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

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

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132