Як керувати розробником, який має погані навички спілкування


52

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

  • Робота з командами DBA / Unix / Network / Loadbalance за різними завданнями
  • Розміщення та управління замовленнями на обладнання та інфраструктуру в різних регіонах
  • Запуск тестів, які ще не перенесені на CI
  • Аналіз
  • Підтримка / Розслідування

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

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

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

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

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


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

12
Як він показав погані навички спілкування? Не вписуючись у вашу форму?
Джеймс

5
@EvanPlaice Знову ж, що з атакою "особистої проблеми"? Я говорив у запитанні "Справедливо сказати, що розробники воліли б кодувати". Можливо, це речення було недостатньо зрозумілим і викликало сумніви, тому дозвольте мені уточнити - я розмовляв із дияволами окремо, і вони сказали мені, що їм подобається працювати над завданнями програмування більше, ніж над іншими завданнями. Якби це не було, я, чесно кажучи, не потребував би ставити це питання.
djcredo

2
@djcredo Я не мав на увазі це як напад. Я кажу, я думаю, ви задаєте неправильне запитання. Прагнення зробити речі більш рівними відповідно до ваших особистих стандартів «ідеальної» команди - це накладення вашої волі на колектив. Люди, особливо талановиті програмісти (читають із сильною волею), не люблять гратися. Якщо, як ви кажете, ви працюєте з кваліфікованими / талановитими людьми, тоді підхід зверху вниз може дати відсіч. Замість того, щоб вирішити для команди, чому б не запитати їх безпосередньо, що потрібно змінити, щоб краще забезпечити спілкування між командою.
Еван Плейс

6
Чому "вирізати собі нішу" - це погано? Ви хочете, щоб найкращий нейрохірург міг вийняти пухлину мозку, і найкращий кардіолог, який ви зможете виправити розширену аорту, чи ви хочете того самого хлопця, який добре в обох сферах, але не відмінний в тому, щоб робити обидві речі для ви?
GordonM

Відповіді:


77

Це здається, що ви докладаєте занадто багато зусиль для того, щоб добре округлити людей і недостатньо зусиль, щоб мати добре округлу команду .

Немає нічого поганого в тому, щоб бути добрим у чомусь - насправді саме тому його найняли! Ви повинні бути вдячні за те, щоб почати когось, хто добре програмує.

Ви заявили:

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

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

Як менеджер, не ваша робота - переконатися в тому, що всі «добре заокруглені». Ваша робота - переконатися, що s *** закінчиться. І ти цього не робиш. Насправді, ви прийняття рішень, які зупинка речі від отримання зроблено.

Яку б проблему ви не мали, вам потрібно її подолати - ви робите свою команду менш продуктивною.


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

8
@JasonHolland, є різниця між "хорошим" і "хорошим". Поки він достатньо хороший, немає жодних причин піднімати це питання. Офіс серйозно розглядає можливість пошкодити продуктивність своєї команди, тому що не вважає її "справедливою". (Нагадайте ще раз, хто сказав, що світ справедливий?)
riwalk

14
@ ДжейсонХолланд, офіцер також сказав: "Якщо я продовжуватиму надавати йому більше роботи з програмування, я знаю, що це буде зроблено швидше ..." Це говорить про те, що цього хлопця потрібно програмувати. Оп має чіп на плечі, і ось у цьому справжня проблема.
riwalk

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

10
@ Stargazer712, "У оператора є чіп на плечі, і ось тут справжня проблема". Це може бути правдою, але погляньте на це з точки зору "середніх" програмістів, які переводяться на завдання непрограмування через одного хлопця, який має "вище середнього рівня" навичок програмування. Я б заперечував, що цей менеджер не виконує свою справу професійного розвитку для інших. Може бути, "вище середнього" є більш кваліфікованим, оскільки він більше програмує? Можливо, інші "середні" програмісти стануть "вище середнього", якби мати більше роботи з програмуванням, майбутні проекти зробиться ще швидше.
програміст

39

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

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

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

Чи варто втратити деяку продуктивність від свого НАЙКРАЩОГО ПЕРАФОРМУЮчого персоналу, оскільки вони дратуються бурхливим девом? Вам доведеться визначитися.

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

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

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


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

3
@BillK: "Однак, один член команди, мабуть, має навички кодування вище середнього". Він не сказав, що він "найкращий". Я взяв удар, і сказав, що він кращий за 2/3 інших дияволів. Це залишає 1/3 з чортів, які є настільки ж хорошими або кращими, ніж цей хлопець, яким доводиться робити зайву роботу, яка не така весела, як те, що він отримує робити весь час ("всі вважають за краще кодувати"). Як би ви хотіли, якби хтось із ваших колег сказав: "Мені не подобається запускати тести для одиниць, тому вам доведеться виконувати все для мене"? Ви роздратуєтесь досить швидко. Погане ставлення цього хлопця отримує йому винагороду (менше завдань, що не кодують).
Грем

9

Перш за все, покладання вини на членів вашої команди ... позначає погані управлінські навички.

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

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

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

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

Підказка: прислухайтеся до відповіді, ніби він жива людина, а не людський ресурс.

(наприклад: спробуйте детально пояснити йому необхідність певної практики та значення певних рішень; деякі люди копають деталі, оскільки вони дають їм відчуття капітана, який не заводить корабель у скелі)


9
-1: Він нікого не звинувачує. Він визначив, що один хлопець бідніший у спілкуванні, і, отже, йому вдалося ухилитися від деяких більш нудних робіт, які повинні виконувати інші. Я не впевнений, як ви припускаєте, що це позначає погане управління, або ОП намагається спілкуватися ... Тож я повністю погоджуюся з тим, що спілкування з відповідним хлопцем має бути частиною будь-якого рішення.
cjmUK

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

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

2
+1 "Підказка: прислухайтеся до відповіді, ніби він жива людина, а не людський ресурс". Якби тільки більше менеджерів думали так ... зітхну.
demongolem

8

Люди різні. Як менеджер, вам потрібно по-різному ставитись до людей (але справедливо!), Щоб максимально використати свою команду.

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

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


6

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

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

Я також думаю, що важливо пристосувати "математику продуктивності" до більш реалістичних показників. Він ніколи не складе до 100% через неминучі втрати при "контекстних комутаторах".

  • 30 + 70, підсумовуючи до 100% продуктивність при переключенні між програмуванням та іншою роботою , ніколи не відбудеться в реальному житті; це швидше приблизно 20 + 50 або навіть 20 + 40. Контекстні комутатори особливо болючі для розробників програмного забезпечення - якщо ви зацікавлені, ознайомтеся з цією статтею, щоб мило пояснили, чому це так: НЕ БУДЕТЕ ПРОГРАММУ!
    Програмісти, які цінують свою продуктивність, природно були б незадоволені подібними втратами.

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

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

  • Як сам досвідчений тестер, я їх досить добре розумію - виробничі проблеми були для мене (як тестера) неоціненним джерелом даних, щоб дізнатися про покриття тестування ("чи правильно це питання було покрито моїми тестами?") І для пріоритетність дефектів ("добре, це було охоплено тестами та повідомлялося перед випуском, але чи я тоді встановив відповідний пріоритет / тяжкість?").

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


4

У мене є про це сказати 2 речі

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

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

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


+1 - Я погоджуюся з обома пунктами. Розробник повинен бути досить чітко визначеним. І при належній підтримці та заохоченні може не бути причин, через які хлопець не може продовжувати свою гру.
cjmUK

Так, "кодер" проти "програмний розробник" - це чудовий спосіб обрамлення. Звичайно, ми всі просто хочемо написати цікавий код. Але робити всі інші речі, які йдуть із цим, насправді саме тому більшість із нас отримують зарплату. Я можу негайно вилучити кодери. Отримати скорочення розробників програмного забезпечення, які розуміють існуючий бізнес-сферу, набагато складніше.
Грем

@Graham саме це, можливо, робить вас активом компанії
Shirish11

4

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

Але я все ж думаю, що головним пріоритетом, напевно, має бути дотримання термінів (що ви, можливо, все-таки зможете зробити при рівномірному розподілі роботи).

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


4

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

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

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

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

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


2

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

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

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

EDIT: Окрім власних почуттів, ви не визначили проблеми. У якийсь момент відсутність зв'язку перешкоджає програмісту. Інші виявлять обурення, і їхня робота може постраждати. Поки, здається, ти єдиний, хто має проблеми. Якщо є щось інше, яким ви не ділитесь?

EDIT 2 Врешті-решт, всі збираються просити особливу послугу. Ця людина робить менше спілкування та більше кодування (що йому слід за всіма записами). Хтось ще хоче прийти трохи пізніше. Ще потрібно пропустити зустріч, щоб виконати термін. Графічна людина отримує більший монітор. Коли ви робите занадто великий акцент на утримання балу, ви забуваєте, що важливо.


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

1
@cjmUK - і ніхто не сказав, що інші члени команди мали проблеми з цим. Див. Редагування 2.
JeffO

2
@Jeff O "Справедливо сказати, що розробники воліють кодувати". Вибачте, але якщо інші дияволи зараз не матимуть проблем з хлопцем, про який йде мова, вони зрештою. djcredo проявляє активність у спробах взяти це під контроль, перш ніж піти цим шляхом.
Грем

2

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

Мій колишній начальник попросив свою сім'ю / дружину та вищий керівництво нашої компанії залишити свою посаду .... одночасно. Він невтомно працював, щоб справедливо врівноважувати обов'язки і брав на себе багато навантаження. Під час будь-якої взаємодії з ким-небудь поза відділом, якщо виникло непорозуміння у спілкуванні, яке повернулося до нього, він швидко, ага, карально це виправив. Він погано «керував вгору», тому наша команда була останньою, яка отримала ресурси до надзвичайної ситуації, і тоді компанія переплатила постачальникам гладкі продажі за неперевірене обладнання без консультацій з командою, яка використовує ці інструменти. Прагнучи створити «добре збалансовану» команду, він керував нашими списками завдань і намагався збалансувати завдання, щоб члени команди могли покращити набір навичок у сферах, де вони не були великими, що призвело до ЛОТУ зламаного коду або погано сконструйованих реалізацій. Хоча людям, окрім автора, спеціально були призначені завдання підтримки для цього зламаного коду, щоб вони могли "навчитися" - погано сконструйовані реалізації, код та тести створили багато поганої доброзичливості між членами команди та насправдізбільшені випадки "гри на вину", яка є швидким шляхом до токсичного стану команди.

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

Відповідно до нового менеджера, час простою впав майже до нуля (що також знизило відсоток часу, який ми витрачаємо на завдання з підтримки, приблизно з 40% до приблизно 10%), задоволеність нашої команди пережила дах, і ми на шляху, щоб перейти від "розбиття банку на нову техніку кожні три-п'ять років", до плану безперервного придбання, який повинен заощадити компанію приблизно крутим мільйоном на рік протягом п'яти років. Цей план був початковою програмою, яка ніколи б не сталася за попереднього менеджера, але активно підштовхувалась до вищого керівництва новим менеджером і залежала від знаходження ЛОТУ синергії в наборах навичок команди. Нам неофіційно нам повідомили, що зараз ми єдина команда в компанії, яка насправді "має лайно разом" і що він " Ми будемо втручатися в наше робоче середовище якомога рідше і переміщувати якомога більше ресурсів на проблемні області, які ми визначаємо як можна. Це справдилось, і це призвело до зниження вартості нашої підтримки, хоча й порушило навантаження деяких інших команд - але це також призвело до зниження вартості підтримки цих команд.

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

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

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


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

Це лише короткі ідеї, сподіваємось, хтось вкраде ці пункти і складе їх в одну з інших відповідей. ;-)


0

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

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


0

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

Зараз, як вказували багато постів, робота не є справедливою і не повинна бути. Менеджери вимірюють, скільки цінної роботи буде виконано.

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

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

Ще один спосіб упакувати це - перелік завдань і дозволити кожному співробітнику щось вибрати. Нехай ваш хороший програміст вибере першим. Якщо ви попередите його заздалегідь і покажете йому список завдань ще краще.

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

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

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

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


0

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

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

Нарешті ... перевірити з іншими членами команди , якщо вони бачать будь нерівність в завданнях команди періодично. Це може викликати велике занепокоєння для вас, але №15 у списку всіх інших.


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

-1

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

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


2
"Однак, один член команди, ймовірно, має навички кодування вище середнього". Він не найкращий. Він вище середнього. Можливо, буде приблизно 1/3 команди, яка краще кодує.
Грем

-1

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

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

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

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

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

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


-1

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

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


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

-2

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

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

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

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

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


1
Просто, щоб було зрозуміло - тут ніхто не звільняється. Всі ми дуже добре працюємо разом, і він надзвичайно цінний член команди розробників. Я говорю про те, як призначити майбутню роботу та як покращити результативність та моральний дух команди в цілому.
djcredo
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.