Як поводитися з егоцентричними програмістами?

15

Дозвольте мені це трохи пояснити.

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

Проблема полягала в тому, що інші програмісти знали його секрет. Він оптимізував правило 80/20, тому витратив 20-відсотковий час, щоб закінчити 80 відсотків коду. Інші (важкі) 20% залишилися програмістам з технічного обслуговування. Хто (не дивно) був покараний через відсутність прогресу. Але оскільки цей програміст мав добру репутацію з керівництвом, перекласти провину на нього було майже неможливо. (На щастя, він покинув компанію).

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

behavior

— Toon Krijthe
джерело

6

Я не впевнений, що "егоцентричний" - це правильний термін. Я б спробував щось на кшталт "оманливого".

— Майстер

можливий дублікат

2

Справжня історія: Так розвивався UNIX, і він породив ціле покоління однодумців-програмістів. Бачити гірше - краще .

— imgx64

Якщо ви можете проголосувати і вважаєте, що це корисне питання або у вас є корисні відповіді нижче, будь ласка, проголосуйте. На сайти StackExchange потрібні голоси, щоб створити хорошу спільноту. Ви можете дати 30 голосів на день, не витрачайте їх. Спеціально користувачі з високою репутацією та низьким підрахунком голосів, будь ласка, прочитайте це: meta.programmers.stackexchange.com/questions/393/…

— Maniero

Одиниці суперечать 20% часу та 80% коду. Просто залиште це: "Він працював на 80%, що було легко, і залишив 20%, що було важко для решти команди".

— Хупернікетес

13

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

— Даєніт
джерело

1

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

— інкогніто

8

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

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

— Білл
джерело

6

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

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

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

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

— Вінфілд
джерело

5

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

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

— Тамара Війсман
джерело

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

— Toon Krijthe

3

Вся команда мусить бити попку! Повірте, його поведінка назавжди зміниться.

2

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

— JeffO
джерело