код ковбоя в команді

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

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

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

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

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

Якщо припустити, що вона справді ефективна, і "джек усіх торгів" ...

Отримати її стиль. Розчешіть її. І - ізолюйте її.

Також ...

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

Найгірше, що ви могли зробити, - це накрутити її мотивацію.

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

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

Насправді - ця свобода - це єдине, чому я все ще працюю тут.

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

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

Рішення (ІМХО): протистояти їй безпосередньо. Звичайно, будьте дипломатичні та вдячні за внески, які вона робить (80 годин - це нерозумний робочий тиждень, і це не могло статися без неабиякої жертви в особистому житті).

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

Подумайте, щоб дати їй набагато більше роботи, тому їй не доведеться шукати вашу!

Чи можливо, що вона "заскакує і закінчує" тому, що решта команди рухається занадто повільно, або тому, що начальник попросив її?

Скільки цього неприємно від обходу, і скільки його просто "показують" більш плодовитим (не обов'язково кращим) кодером?

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

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

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

Робота швидше?

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

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

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

Це зазвичай називається командна робота - якщо вам не подобається напрямок, який вона взяла, в чому проблема?

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

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

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

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

У будь-якому випадку її найкращим ви почнете оцінювати себе спочатку. Оскільки ваші зусилля з " Справою " з нею можуть не працювати з керівництвом.

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

Ключові речі вискакують на мене:

• У неї є талант робити роботу швидше, ніж інші (ти нічого не мав на увазі, що її код поганий)

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

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

Почніть команду робити парне програмування.

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

По-друге, вона передаватиме знання (доки веде більше початківців розробників) і таким чином поширюватиме свої приголомшливі здібності на решту команди.

По-третє, вона зменшить величезний ризик, який вона наразі несе від вашого імені, так що більше одного члена команди знає, що вона знає.

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

По-п'яте, вона навчиться грати як частина команди . Цілком можливо, що демотивація, яку вона викликає, разом із дублюванням роботи інших членів команди, коштує дорожче, ніж вона виробляє. Продуктивність! = Ефективність.

По-шосте, якість коду, як правило, піднімається, коли пари розробників. Приємний побічний ефект.

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

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

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