Чи хороша чи погана ідея обертання головного розробника?

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

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

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

Це гарна ідея? Чому або чому ні?

Майте на увазі, що це означає, що всі розробники - Усі розробники хороші, але не обов'язково однаково підходять до керівництва.

А якщо це не так , то як я рекомендую уникати такого підходу, не здаючись, що це лише з корисливих причин?

Не обертайтеся.

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

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

1. Знає, як делегувати.
2. Контролює.
3. Є досвідченим розробником.

Він є єдиним джерелом для решти колективу, який повинен шукати та звертатися за порадою. Він також є посередником між керівництвом вищого рівня та основною командою розвитку. Я не знаю жодної управлінської команди, яка б любила мати справу зі змінами (якщо тільки вони не викликають цього).

Якщо ви справді найкраще підходите до посади, це знали б усі. Кожен би знав це (наприклад, керівництво вищого рівня, ваш товариш по команді тощо). Заявіть, що ви не вважаєте, що обертання позиції варто (якщо ви вірите в це). Потім сідайте і нехай вони роблять призначення - утримайтеся від відмови від імені або будь-якого виду самореклами, оскільки це зробить вас непрофесійними

Провідним розробником є ​​дві частини:

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

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

Це не обов'язково погана ідея, якщо задіяні розробники задіяні та (в ідеалі) спроможні.

У мене виникають проблеми з пошуком посилань на це (але я продовжую шукати), але якщо я пригадую правильно, деякі спритні компанії роблять це - вони змінюють назву "команда веде" або кожну ітерацію, або в інший попередній час періоду. Це сприяє залученню розробника і надає кожному шанс зробити деяку частину управління командою / зовнішньої комунікації без постійного переміщення розробника на розвиток цієї ролі.

Деякі недоліки включають потенційну втрату інформації (це можна пом'якшити різними способами) та вищий потенціал для "поганого" керівництва. Також може бути важко підтримувати бачення / напрямок для команди. Однак, якщо всі стоять на борту з таким підходом, і члени команди є обізнаними та зацікавленими в тому, щоб така система працювала, це може бути вагомим.

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

Поворот головного розробника на основі часу - погана ідея.

Всі - хороший розробник, це не означає, що кожен є хорошим лідером. І той, хто хороший лідер, не означає, що він підходить для лідера цієї програми.

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

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

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

Технічне керівництво - це добре, але якщо ви спробуєте і повернути їх, ви можете виявити, що вам було краще без одного.

Я думаю, спочатку потрібно визначити, яка роль цієї людини, більше, ніж хто це робить і на скільки часу.

Вам також потрібно визначити, чи це суттєво змінить спосіб роботи решти вашої роботи та чи зменшить її ефективність. Наявність однієї особи повинна "затверджувати" кожен рядок вашого коду, а не будь-яка однорангова робота, що може мати серйозний ефект.

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

Я б хотів зробити ставку, що, хоча команда нібито нерівна, серед них вже є лідер, і вони всі це вже знають.

Org-графіки рідко відображають, як люди насправді працюють. Особливо ідеалізовані діаграми на кшталт "плоска команда".

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

Крім того, оскільки ви згадали, що менеджер не технічний, ця людина може все-таки керувати процесом RSA та полегшувати зв'язок. Ви також можете призначити певну малу та середню підприємницьку організацію як проект на основі проекту, щоб сприяти спрощенню та формуванню їхніх індивідуальних наборів навичок.

Чому команда розробників не голосує анонімно? Я б застосував переважне голосування.

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

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

Як підказує ваше запитання, вся команда несе відповідальність за прийняття рішень, я б запропонував вам зберегти це так само. Однак для спілкування та звітування перед органами, які знаходяться поза командою, ви можете обрати координатора команди з команди в команді. Його / її відповідальність включатиме все, що не є технічним. З усіх технічних аспектів команда повинна сидіти та обговорювати так само, як ви зараз. Яке б рішення ви не приймали, воно буде повідомлено зовнішньому світу за допомогою ординатора . Цю позицію можна легко обертати за часом.

Іншим підходом може бути створення провідного розробника на основі рівня досвіду> досвіду роботи в одному проекті> досвіду в одній компанії. І якщо є потреба, положення можна повертати по фазі на фазу. В ідеалі кожен етап розвитку має свій набір вимог та результатів, над якими можна планувати та працювати над міні-проектом. Маючи різний вивід для кожної фази, мінімізували б майже всі негативні наслідки обертання.

Замість того щоб мати головного розробника, який обертається, майте керівника проекту, що обертається, когось, хто має найбільше знань та розуміння, щоб отримати проект x до завершення.

Провідний розробник, як правило, є просуванням, і його слід заробляти.

Але щоб допомогти тренувати та розвивати навички лідерства, поверніть, хто відповідає за різні проекти, а потім чітко оцініть, наскільки добре вони чи ні.

Повинен бути керівник команди так само, як є капітан на досить великому кораблі.

Якщо менеджер не виконує та не може виконати цю роль, для її заповнення повинен бути призначений один із розробників.

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

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

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

Іноді бути лідером - це скоріше тяжка відповідальність, ніж щось інше. Хтось МОЖЕ взяти на себе відповідальність за вибір, так працює суспільство, коли ніхто інший не хоче цього робити.

Те, що команда хоче повернути лідера, може означати, що всі відчувають, що можуть взяти на себе відповідальність за те, що вони роблять, і вони не хочуть нікого віддавати перевагу, і, здається, це добре: немає важких почуттів, і всі бажають команді успіху.

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

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

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

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