Як визначити low-performer?

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

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

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

Давайте колективним розумом сформуємо максимально об’єктивний список маркерів і можливо рекомендації як ці маркери уникати.

Ідеально, якщо хтось наведе маркери для наших контор та для ЄС, США.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

Нагуглила:
— Частые «недопонимания» своих же тасок
— Не проявляет инициативу
— Срывы сроков
— Плохая коммуникация и кооперация с коллегами
— Незавершенная и неаккуратная работа
— Отсутствие энтузиазма и энергии
— Не проявляет интерес к how things work на проекте
— Ненадежный, нельзя доверять, не сдерживает обещаний
— Не придерживается принятых в команде или компании правил, нарушает их
— Любит говорить «это не моя обязанность/ответственность»
— Оправдания и жалобы
— Абсентизм: частое отсутствие на месте (то обед то перекур то болеет)
— Скиллы не соответствуют должности
— Нежелание учиться
— Избегает лишних усилий или сложностей для себя
— На него часто жалуются

Є крутий метод, як знайти low performer’ів на великій галері — провести тунір по настільному тенісу.
П.С. На рідній АЕС на таких турнірах завжди перемагали пожежники.

Як визначити манагера-оптимізатора за заголовком статті на доу

Есть объективные KPI, статистика по которым обычно собирается автоматически: число закомпличеных пул-реквестов, закрытых тасков, открытых и пере-открытых багов и т.д. Этот показатель обычно используют как раз что бы выявлять проблемы. Например в среднем команда делает 4 пул-реквеста в неделю, а у кого-то 3 пул-реквеста за весь прошлый месяц. Это не повод стазу кричать «слабое звено», но маркер что бы обратить внимание и разобраться.
Но производительность девелоперов слишком относительная, что бы можно было мерять автоматически. Именно для этого придумывают всякие инструменты вроде стори-поинтов. Что бы можно было сравнить сколько работы в среднем делает команда за период времени и сколько отдельные девелоперы. Опять же: если кто-то «закрывает» меньше стори-поинтов это не значит что он плохо работает. Возможно у него мало опыта в нужных технологиях (бэкендера посадили фиксить фронт), возможно он тратит время помогая другим, менторя джунов или на ревью чужих ПР.
Самая очевидная оценка: субъективная. Если большинство команды считает кого-то халтурщиком, или тормозом, или жополизом — показушником, или хамовитым, или еще чем-то недовольны то это в любом случае повод задуматься.
Если это нормальные проект, а не аутстаф, то важна именно производительность команды, а не каждого в отдельности. Один топ-перфомер за всех не сделает, при этом один разгильдяй может подавать всем плохой пример. Доружная команда намного лучше, чем команда «звезд» — карьеристов.

Полностью зависит от контекста. Производительность измеряется в рамках команды. Все это лежит вообще на уровне инсктинктов, когда наши предки с каменными копьями ходили на мамонтов. У одних команд была стратегия брать только молодых и сильных мужиков, у других в охоте принимали участия почти все, одни загоняют другие кидают камни на башку и т.д. Третьи вообще начали выжигать лес и выращивать на плодородном пожарище пшеницу. Во всех случаях по разному формируется социальная иерархия, кто кому нравится и не нравится и т.д. Один и тот же человек в одной команде может прижиться и показывать нужный результат, а в другой скажем тимлиду не понравится и вообще не сделать ни одной задачи за полгода. P.S. А теперь в спомним кто сегодня кушал хлеб на завтрак, а кто шашлык из мамонтятины.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Есть такая штука в статистике — принцип Парето. В соответствии с ним любая команда делится на 20% людей, которые тащат 80% работы и остальные 80% людей, которые делают 20% работы. Это и есть искомые лоу-перформеры.
Окей, скажете вы, можно их всех уволить, сократив расходы компании на зарплату на 80%, притом уронив общий перформанс всего на 20%. Какому директору такое не понравится!
Но есть один нюанс. Правило продолжит работать и после этого нехитрого манёвра. Оставшиеся 20% разделятся уже внутри себя по тому же принципу. И вы уроните перфоманс команды не на 20, а более чем на 80%.
Поэтому всё гораздо проще.
Человек оправдывает ожидания?
Продолжаем с ним работать.
Нет? Спрашиваем причину. Ответ не устраивает — прощаемся.

Звучит как: «я узнал о принципе Парето, теперь буду его тулить везде»

Это намекает на бестолковости самой метрики.
Что до способов определения, я знаю проще способ.
Собираем All hands и задаём вопрос в толпу:"Кто Лоу перформер, отзовитесь!".
Я первый руку подниму.
Потому что раз такой вопрос прозвучал, у компании проблемы с деньгами. В этом случае я предпочитаю попрощаться с ней сразу.

Так только мотоциклистов можно найти, трулоуперформерам лень даже слушать, не то что руку поднять

Твоя правда.
Я скорее молча пойду на собеседование в другое место, после того, как у менеджмента появится в лексиконе такое слово :)

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

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

синьору на андроиде долго искать что ли? пара дней и готово, а постепенное выставление на мороз с нотис периодом, который 2-4 недели

из которых могу неспешно выбирать.

последние мои офферов 20 были с достаточно коротким сроком годности от 2 до 10 дней, часто офферы одной итерации сравнить не успеваешь, а не то что неспешно выбирать

Окей, скажете вы, можно их всех уволить, сократив расходы компании на зарплату на 80%, притом уронив общий перформанс всего на 20%. Какому директору такое не понравится!

Тому, которому клиент платит не за перфоманс, а за тушки! Любая галера стремится только УВЕЛИЧИТЬ команду. Есть 20% синьоров которые тянут 80% работы? Прекрасно — берем еще работы +50% и еще +50% вайтишникоа — бездельников. Пропорция сохраняется, синьоры все так же тянут на себе 80% уже из нового объема, платим им столько — же, а с клиента берем на 50% больше!

В аутсаффе (коего большинство) клиент это долго терпеть не будет. Живо повесит 5% самых ленивых на шею галере.

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

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

Иногда человек реально заболевает

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

чуваку навешивается тасков на спринт борд как на два спринта

«нормальный» в такой ситуации начнёт неделю с поиска нового адекватного места работы, так считаю

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

А зачем рядовому гребцу все эти геройства? Доказать менеджменту, что ему не слабО, или чтобы что?

так в той компании нету рядовых гребцов ))) выживают только те кому нравится кодить ))) все лоу перфомеры уходят очень быстро.

"нашла дура чем гордиться"©

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

А потом эти выживальщики пишут анонимные статьи про выгорание. Sad, but true

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

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

Короче я бы такой подход на вооружение не брал. Уж лучше какие-то тайные kpi: все съедет в треш хотя бы не так быстро.

когда работы в два раза больше, чем времени, то я сейчас всё не порешаю, и ты не порешаешь, и никто не порешает. на своём месте я могу только «always do my best» в рамках своих талантов и умений, прыгать выше головы не получится. если заказчику нравится устраивать цирковые представления, вроде описанного тобой, то нам не по пути. да и всех делов.

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

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

В принципе здесь все нормально, кроме

чуваку навешивается тасков на спринт борд как на два спринта

Чувак сам должен навешивать на себя таски как на 2 спринта.

На моє глибоке переконання, виявити хто є top-performer, а хто low-performer в тій чи іншій команді можливо далеко не завжди. Я б навіть сказав, що в більшості випадків це взагалі неможливо і навіть не потрібно. По-перше, визначати продуктивність розробника на періоді меньш ніж пів року навряд взагалі має сенс. Різні люди мають різну кваліфікацію в різних технологіях: хтось може бути асом в написанні скільки завгодно складних SQL-запитів, але не вміти добре читати JS код. Хтось, навпаки, може не тільки читати, але й рефакторити скільки завгодно складний та погано написаний JS код, але не розуміє що таке HAVING. Коли розробник береться за задачу, він часто має дуже приблизне уявлення про те, які саме скіли можуть знадобиться (звичайно якщо завдання не є тривіальним), тому часто доводитьс вчитися прямо в процесі розробки і на це витрачається час. Тобто множину розробників взагалі не завжди можливо лінійно впорядкувати за показником performance. До того ж, цей показник змінюється від проекту до проекту, від технології до технології та у часі. Тому оцінка продуктивності має сенс тільки на довгому періоді (десь рік і більше).
На що, на мій погляд, варто звертати увагу, це якість коду (readability, maintainability), вплив на якість рішення в цілому (дуже складно це оцінити, але це є один з ключових показників), розуміння задач проекту з бізнесовох точки зору, легкість та ясність комунікації, вміння бачити ризики та працювати з ними. Тобто на якості, за відсутності яких розробник замість допомоги проекту тянге всю команду назад. Це (на мій погляд) набагато продуктивніше за будь-які виміри чи показники (особливо автоматичні типу кількості написаних рядків кода, коммітів, закритих тікетів тощо). Якщо оцінювати розробників по кількості рядків коду, є ризик, що замість рішення задач, вони почнуть писати багато нікому непортібного коду та витрачати якомога більше енергії на доказ необхідності того чи іншого модулю в проекті. :) Тобто завжди варто пам’ятати, що будь-який показник у відриві від інших, не каже НІ ПРО ЩО. Тобто, я глибоко переконаний, що не існує в природі системи показників, за якими можливо оцінювати продуктивність розробників. І узагальнено таку систему розробити неможливо, хіба що щось досить непогане для того чи іншого конкретного проекту.

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

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

Девелопер теж може так робити...

Лоу-перформера можна визначати лише у порівнянні до інших колег. Але це складніше, якщо він виконує таку роботу, де він єдиний гравець. Наприклад, він дизайнер та малює іконки. Та він єдиний на проекті. Або він «продає» вашу систему, але також він без колег — інші програмісти. Ось тут складно буде, з ким порівняємо? А якщо у вас N програмістів, ви легко визначите хто там «на що здатен». Головні критерії — це проста перевірка його тасків, скільки та якої складності вони були, наприклад за пів-року. Є також простий критерій — коли людина не вирішує проблеми, а генерує їх. Також такі люди зазвичай десь «гуляють» у робочий час, багато інету та балачок, «ги-ги» та «ха-ха». Або що там за вікном... багато ж цікавого, аби не робота.

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

Например, у компании это может быть что-то вроде «build the most reliable messaging service in Africa». А у команды разработки мобильного клиента — «build a fully accessible UI» и «contribute back to 3rd-party open-source projects», среди прочих.

Так вот, low-performer — это член команды, который в меньшей степени, по сравнению с коллегами, движет команду и компанию в сторону достижения этих целей и ценностей. А то и вовсе в противоположном направлении.

В этом отношении, человек, который генерирует тонны жадного до сетевых ресурсов кода может быть low-performer’ом. А человек, который почти не пишет код, но помогает коллегам лучше понять, что такое accessibility — high-performer’ом.

Оце, як на мене, найбільш правильний погляд, дякую!

Рили? Хороший менеджер и без вопросов «как дела» знает, что делает каждый подчинённый, насколько он мотивирован, и как работает.
А плохому никакой инструмент не поможет.

«как дела» же, для выявления какихто скрытых недовольств.

«как дела»

Потрібно щодня або майже щодня в людини питати, але не для того аби дізнатися статус задач, для цього є більш формальні інструменти, а для того аби встановити те, що називається в психології та менеджменті «Rapport» uk.wikipedia.org/wiki/Рапорт_(психологія
Хороший лідер і керівник повинен знати мінімально необхідну інформацію про кожного свого колегу підлеглого.
Ну і само собою, що такі відносини за день і навіть за місяць не вибудовуються.

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

Вот сидит чувак делает таску, откуда ты будешь знать насколько он мотивирован без как дела? Просто посмотрев на него? Ну ну, удачи

Прошу висказатись тих, хто цього ще не зробив ;)

Завтра-післязавтра підбиваю підсумки і пишу тут коментар в якому спробую об’єднати суспільну думку.

пиши статью сразу. На доу это любят, еще и в фб запромотят!

Любит говорить «это не моя обязанность/ответственность»

то може його просто люблять напрягати всякими лівими тасками з геть іншої сфери/рівня відповідальності, тоді це ок

-

ваш вопрос не отвечает на мой вопрос, а вопрос автора не идентифицирует проблему. мой вопрос задан, чтобы найти проблему, найдя проблему можно ее обсудить и найти решение.

За кількістю коментарів на ДОУ

Не впевнений, що камера за спиною сильно підвищить performance, зате бажання працювати в цій компанії відіб’є точно

А яка ж із того користь, якщо працівника втратять?

А ничего ты не сделаешь.
Людей как не хватало, так и не будет. Уволить «зайчика», конечно можно. Но он найдёт тебе замену за неделю, а ты следующего «зайчика» собеседовать месяцами будешь. И узришь закономерность — чуваки, которые будут работать только у тебя, никому просто больше не нужны. А чуваки, которые толковые и которым хочется дать оффер, будут точно не на одну зарплату жить — их ценят все.

Ну спробуйте засунути Аквафреш знову у тюбик.
Побачите який із того буде результат.
Приблизно так само може виглядати примусове повернення в офіси.
А тому — його не буде.

Будучи галерой не продавать тушку на пару проектов?
Да нет, бред какой-то!

возвращения в стойла будет логичным решением

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

Так это падает на плечи стейкхолдера

Разумеется. Инвестиции в айти только растут от года в год. Вот и приходится их осваивать.

Когда всех в ФОП загоняли — были нотисы?)

А были причины?
Офис сразу порубит все возможности работы на нескольких заказчиков

Не будь категоричным. В старопрежни времена знал как минимум двух людей, работавших в офисах на двух заказчиков. Один из них приходил в офис никак не раньше 14 часов, уходил из офиса не ранее 22 часов. До этого работал в другом офисе другой конторы. Все про это знали. Никто этих людей не гнал, они отрабатывали свои деньги.

С женщинами у тебя такая же логика?) Те кто не изменяют — никому не нужны?

он наверное про личный опыт

Фраза «щоб ти жив на одну зарплату» отримала нове значення ))

Отлично. Скоро содержание карбона и титана у него в организме резко возрастёт.

А если ты продашь этот мот и купишь другой, ты сможешь на него переставить обвес? Или бОльшую часть деталек получится re-use, а процентов 5-10 покупать заново?

Почти ничего нельзя будет перенести.
Продавать я его не планирую. Купить ещё другой мот к нему — вполне возможно.

дия сити спасет отца советской галеры.

Ну и кому он сделает хуже? Пусть тратит бабки на найм, на онбординг и в итоге найдёт такого же, что будет работать на 2 проекта, ну а если не будет, то и на одном от такого толку мало

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

Я лично шлю на*** при малейшем намёке на треккер. Если вас устраивает соотношение цена/качество какая разница сколько я времени реально трачу на работу, если не устраивает тоже, какая разница?

А тебе трекер предлагали? Если да, то в какой именно форме?

Прикол только в том, что в реальной жизни, даже в офисе под носом у начальника никто 8 часов чистого времени в день не работает, самые стахановцы работают 5-6, остальные хорошо если 4, некоторые умудряются под носом у начальника вообще работать 1-2 часа, и изображать сверх занятость.
Так что на Кроссовере придётся работать в 2 раза больше чем средний в офисе.

это да, полностью согласен. Самое смешное когда потом сидишь где-то на собезе в офис, народ такой — ааа, ну это у вас опыт н лет на ремоуте... и с такой мордой, типа, вот мы-то тут в офисе настоящей работой занимаемся :)

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

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

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

как-то помнится индусам придумали кпи по количеству кода и они взялись

согласились под дулом трекера куярить 6-8 часов день без перерыва на оторвать еблет в окно.

и таки сделали все кпи с запасом )) они могут я проверял

Та я видел и рефачил такие поделки :-))) Теперь вот бухаю и к психологу хожу 4 год :-)

Теперь вот бухаю

В наливайке во дворе твоей бабушкиной панельки? :-)

он вроде по вискарику и бельгийскому пиву.

Ты лучше скажи, откуда ты знаешь где живет моя бабушка ? )))))

А кто ж еще будет смотрителем твоей будущей трешки под сдачу у ст.м.Алексеевская :-)

Фух, ну теперь я спокоен что у нее будет счастливая старость полная заботы :-)

Но на другом конце этого сравнения другие ... Готовые по полтора часа стоять в пробке до офиса в одну сторону и овертаймить за спасибо, да ещё и по выходным быть выдернутыми на шару. :)

Ну так это просто другая крайность, а так-то нам даже на том же «мегастрогом» кроссовере было можно смотреть до 3 часов видосов с ютюба, например с того же кубкона, и 2х часов чтения всяких medium и пр. в неделю.

вырезал блок времени если 6 минут нет активности ни на клавиатуре ни на мыше

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

Мне уже не надо :) Я уже там года 2 как не работаю. Оказалось, что в других местах платят не меньше, но напряга меньше.
Но вообще там трекер много за чем следит и за такими приложениями тоже, народ увольняли при обнаружении неоднократно. Он также следит за типами активности — например (VSCode, Pycharm, Iterm окна — это разработка, slack, zoom, bluejeans и пр — коммуникация, браузер конкретно там от сайта фильтры — может быть девелопмент, а может быть прокрастинация.) Ну и естественно деятельность должна держаться однотипная какое-то продолжительное время, тоесть если клацать между коммуникацией и разработкой каждые пол часа тебе назначат человека который поможет тебе овладеть этими механиками :) Вообще довольно забавно даже было, и не скажу, что это не работало в плане эффективности.

Но вообще там трекер много за чем следит и за такими приложениями тоже,

Какие «приложения»? Только хардварные решения, только харкдор
www.amazon.com/...​-Blue-Black/dp/B07P6HBD1N

А для того, чтоб не смешивать рабочую и личную жизнь на компе — KVM-свич и два компа.

Ну это слишком мануальное, а как же дневной сон?

Причём, на уровне драйвера/ядра

На кроссовере давно и тебя снимают и экраны все, на апворке тоже трекер экран снимает, как и топтал. Так что это будующее давно уже прошлое и настоящее. И не жалуется никто.

Ну логично. Зачем жаловаться потом если можно просто послать нахер заранее и просто не работать на компании, практикующие все вышеперечисленное? :)

і проконтролювати що трансляція з камери за спиною не іде на Onlyfans

В некоторых организациях уже используется посекундная тарификация и ежеминутные снимки экрана. Уровень квалификации сотрудников, готовых работать на таких унизительных условиях крайне низок!

25к зелени в месяц и я готов терпеть унижения

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

все просто — если ты не так о***нен как Уставший архитектор, то ты лоу перформер

Маю великі сумніви в його реальній «о***нєнності».

если ты

устаешь меньше чем

Уставший архитектор, то ты лоу перформер

В аутсорсе часто лоу-перформера не уволят только потому что заказчик его ещё не спалил, искать ему замену долго и дорого, подорванная репутация даст о себе знать сильно позже. Ну и главное, чем хуже перформит средний сотрудник — тем больше сотрудников можно продать заказчику. Атмосфера, культура в команде и тд. — всё по звезде конечно же. Такая ситуация особенно актуальна для проектов с стадии поддержки, когда лоу перформер единственный знаток какого-то ветхого дерьма и никому не понятно сколько времени сделать Х. Кто в этом виноват ? Я думаю что менеджмент аутсорсинговой компании, который 1) не выгонит слабое звено 2) скрывает информацию от заказчика с целью максимизации краткосрочной прибыли ценой репутации.
Про больше одной работы:
Видел парня который на двух работах педалит вроде нормас, но у него нет нервов на сложные задачи типа инвестигейтов и дизайнов. На обоих работах один стэк — выбор технологии которой нет на первой работе его сильно смущает, ведь у него нет на это нервов.
Я видел парня который педалит за двоих на каждой из двух работ. У него набита рука на определенный фреймворк + правильное отношение к работе. Такие люди существуют. Хотя возможно дело в фоне, который составляли лоу-перформеры. Один из основателей Стратоплан сказал что компании не выгодно такому парню платить две ЗП лоу-перформера, ведь в скором времени они тоже захотят такую же ЗП. Возможно это выход для такого красавчика.
Лично мне интересно решить сложную задачу надлежащим образом и это требует концентрации внимания, а главное что бы в фоновом режиме это была единственная задача.

единственный знаток какого-то ветхого дерьма и никому не понятно сколько времени сделать Х

уникальная экспертиза стОит дорого;). никто ведь не запрещает 23-летнему смузихлёбу погрузиться в какой-нибудь кобол и через каких-то пять-десять лет грести долоро лопатой. от токо нихто чочото не идёт этим путём. зато в пренебрежительном ключе отозваться об специалисте с уникальной экспертизой — єто завсегда пожалуйста. да?

Я не про Кобол, я о сам насрал — сам знаю где насрано. Есть такие люди, после того как они делают гит пуш — код сразу легаси.

я в целом понимаю что имеется в виду, однако дополнительно отмечу, что «знать где и как насрато и уметь в этом эффективно ковыряться» — это, как ни крути, но уникальная экспертиза. которая стОит дорого ;).

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

Я видел парня который педалит за двоих на каждой из двух работ. У него набита рука на определенный фреймворк + правильное отношение к работе.

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

с позиции тех лида : Мне не удалось уволить лоу перформеров, так как пм был против, аргументируя это тем что — увольнение сотрудника это проектные и продуктовые риски.

Элементарно.
Кастомер жалуется на перфоманс чувака?
Тогда он Лоу перформер. Убираем его с проекта, извиняемся.
Кастомер говорит, что норм чувак? Норм чувак.
Почему так?
Человек может за месяц ни строчки кода не написать. Но на паре созвонов с другими дать им подсказки, благодаря которым они баги, с которыми возятся уже неделю, пофиксят до обеда. Он в этом случае Лоу перформер?
Также он может придти на проект и сказать, что ваша архитектура — говно (это почти в каждом проекте будет правдой). И не просто сказать, а отрефакторить какой-то модуль, закинув PR и предложить на его основе план рефакторинга проекта, расписав дальнейшие выгоды для бизнеса в виде снижений затрат на саппорт и улучшения кавереджа. Тоже Лоу перформер? Он же ни одной текущей задачи за спринт не закрыл. 0 поинтов же.

Но на паре созвонов с другими дать им подсказки, благодаря которым они...

подсказочник ))

ну я так делал не однократно

Кастомер обычно не знает кто сколько перформит если команда из более чем 1-2 человек: он получает общий результат. Перформанс только изнутри видно, ну или если вся команда low.

Это если представителей кастомера нет в команде.
Лид обычно в курсе от кого сколько пользы

Когда-то давал советы кастомеру (не в ИТ) — он вырос в бизнесе. Даже не отблагодарим.

Когда-то нашел кастомерам крутейших бекенд-программиста на Python и гуру в JavaScript — получил самую обычное вознаграждение.

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

Консалтинговые бизнесы в Big4 (PwC, EY, KMPG, Deloitte) — дорогая и эксклюзивная вещь.
А консалтинг от BCG, Bain, McKinsey — вообще стоит огромных денег.

Думаю качественный ИТ-консалтинг (в разработке и архитектуре) или ИТ Due Diligence — это перспективное направление для бизнеса.

Продуктовые и аутсорсинговые компании — это как-то скучно.

ИТ-консалтинг

А можете декілька слів, що маєте на увазі під консалтингом і чим це відрізняється від того ж контракторства-фрілансерства?

Загалом в класичному бізнесі цим займаються Boston Consulting Group, Bain, McKinsey.

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

Робить звіт за результатами консалтингу + надає рекомендацій у вигляді to do list.

2) Наприклад, є досвідчений, топовий фронтенд розробник зі UI / UX скілами досвідченого практика. Він приходить на замовлення власника бізнесу та протягом тижня у вільному режимі досліджує продукт, софт, систему тощо.

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

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

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

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

Наприклад, огляди заробітних плат та різного роду дослідження ринку, які ДОУ публікує безкоштовно — це великі окремі бізнеси в Big 4 компаніях (Deloitte, EY, PWC, KPMG) як стандартизований, аналітичний консалтинг.

Розмір цих бізнесів (в залежності від країни) можуть коливатися від 50 тис у.е. до 1-2 мільйонів у.е. в рік.

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

Stanyslav Semukhyn описав якраз експертизу + внутрішній консалтинг.

Low performer это тот кто по прошествии, скажем, 1 месяца на проекте, плохо продвинулся в 2 направлениях — depth фич которые он делал, и breadth вокруг (не кросс функционален)

так некоторые могут хорошо продвинутся по фиче тратя до 2 часов день на всю работу вместе с митингами

Є крутий метод, як знайти low performer’ів на великій галері — провести тунір по настільному тенісу.
П.С. На рідній АЕС на таких турнірах завжди перемагали пожежники.

Перемагає той, хто більше тренується :)

тунір по настільному тенісу.

Кикер же (table soccer)

Кстатє да :)) вот еще один маркер:
«Подошел Новый год. Намечалась традиционная конторская вечеринка. Как это бывает в подобных случаях, заметно активизировались лодыри.» (Со. Довлатов)

Часто сидит на доу 🙂

У меня он часто вообще вкладкой в браузере болтается, но это не значит, что я туда часто захожу. Так, пока кофе чуть остынет. Но даже за это время меня сложно тут упрекнуть в low performance :)

...это не значит, что я туда часто захожу. Так, пока кофе чуть остынет.

Кхм... Яйцеголовые грят шо больше 5 чашек кофе в день — это ппц. У Тебя в офисе паходу халява на кофе ;) ? ведрами его употребляешь :8))

Но даже за это время меня сложно тут упрекнуть в low performance

таки да :))))

Мінімальний пакет для достатнього перформансу:

Джуніор = бути вчасно і на звязку протягом робочого часу
Мідл = Джуніор + виконувати задачі самостійно
Сінйор = Мідл + проявляти ініціативу

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

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

Есть объективные KPI, статистика по которым обычно собирается автоматически: число закомпличеных пул-реквестов, закрытых тасков, открытых и пере-открытых багов и т.д. Этот показатель обычно используют как раз что бы выявлять проблемы. Например в среднем команда делает 4 пул-реквеста в неделю, а у кого-то 3 пул-реквеста за весь прошлый месяц. Это не повод стазу кричать «слабое звено», но маркер что бы обратить внимание и разобраться.
Но производительность девелоперов слишком относительная, что бы можно было мерять автоматически. Именно для этого придумывают всякие инструменты вроде стори-поинтов. Что бы можно было сравнить сколько работы в среднем делает команда за период времени и сколько отдельные девелоперы. Опять же: если кто-то «закрывает» меньше стори-поинтов это не значит что он плохо работает. Возможно у него мало опыта в нужных технологиях (бэкендера посадили фиксить фронт), возможно он тратит время помогая другим, менторя джунов или на ревью чужих ПР.
Самая очевидная оценка: субъективная. Если большинство команды считает кого-то халтурщиком, или тормозом, или жополизом — показушником, или хамовитым, или еще чем-то недовольны то это в любом случае повод задуматься.
Если это нормальные проект, а не аутстаф, то важна именно производительность команды, а не каждого в отдельности. Один топ-перфомер за всех не сделает, при этом один разгильдяй может подавать всем плохой пример. Доружная команда намного лучше, чем команда «звезд» — карьеристов.

Есть объективные KPI, статистика по которым обычно собирается автоматически: число закомпличеных пул-реквестов, закрытых тасков, открытых и пере-открытых багов и т.д.

на эту тему столько всего писали, что вспоминать это уже смешно. КПИ обдуривается на раз

Особенно порадовало слово «абсентизм»

это типа абсент пить в рабочее время ?

ага. отвратительнейшее явление наряду с бурбонизмом и текилизмом

Ну почему, текилизм звучит неплохо и даже намекает что на проекте все замечательно

Бурбонизм с сахарком и ангостурой — вообще норм тема. Ну и охладить льдом офк

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

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

Вообще скучность пятничных компенсационных пакетов просматривается.

А лоуперформерам — теплое пиво на кортанах и семки! :-)

Наличие барной стойки и правильные сопроводительные снеки были бы реальным прорывом и даже эксклюзивом для некоторых работодателей

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

И утренний опохмел на стендапах :-)))

Подивитись у дзеркало !

Для сина маминої подруги ти завжди такий.

Як визначити манагера-оптимізатора за заголовком статті на доу

Все маркеры давно определены: rogovsky.net/...​1647-Св-во-Роговський.png

Если нужны готовые решения — обращайтесь, поможем

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

отсеять тех, кто пришел в айти за баблом

... від тих, хто готовий працювати за їду

Устаревшая информация. Любые специалисты при деньгах. Бездари есть на любых местах.

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

Тоді реальне обличчя цього індивіда буде більш чітким та зрозумілим.

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

Великі гроші передбачають великі ризики (складність діяльності) і високу відповідальність.

От більшість low performer-ів уникають персональної відповідальності та вимогливості до самого себе. В них слабко розвинені самокритика та самоаналіз. Свої косяки та фейли вони максимально приховують або перекидають їх на когось з підлеглих, шукаючи крайніх.

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

К перфомансу то это как относится?

Думаю, что нужно оценить следующие компоненты:

1) уровень сложности задач, которые самостоятельно решает профессионал в повседневной деятельности (требует опыта, знаний и умений);

2) какая персональная ответственность лежит на человеке (например, контроль качества и заранее согласованных сроков);

3) уровень рисков, которые берет на себя человек в процессе решение профессиональных задач.

Чем выше сложность, ответственность и риски — тем круче performer. У нас когда-то был junior, который делал работу senior-а. Он единственный из 100 человек получил двукратное увеличение зп за год и стал ведущим синиором своего отдела.

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

То есть вы сейчас критикуете принцип разделения ответственности?

то есть Вы считаете, что «разделение ответственности» — это и есть «перевод стрелок»? можно конечно и так разделять :)

Вы считаете, что «разделение ответственности» — это и есть «перевод стрелок»?

Но по вашему комментарию выше создаётся впечатление, что это именно вы так считаете.

Нет. Именно Вы так понимаете... наверно, я плохо обЪяснил.

This is a second thread in a row where for some reason people switch to Russian just to please their Russian-speaking opponents (just a reminder — we’re all in Ukraine).

So I wonder, how far it can go. Will you switch to English for me, Євгене? :)

А кто это у нас тут на русском комменты пишет?
dou.ua/...​pomaranskiy/activities/6

А ну быстро совершил акт самосожжения.

8 років тому я жив і працював в російських єбєнях (Західний Сибір), де на комп’ютері не було української розкладки. Навіть пости на Хабрі писав, уявляєте? ) Проте я з тих людей, котрі реагують на те, що навколо них відбувається, і відповідно коригують свою поведінку.

і відповідно коригують свою поведінку

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

якби прогортавши 8 років моїх коментарів, ви не знайшли нічого російською мовою, які би були ваші наступні кроки

Да никакими. Пожал бы плечами от недоумения (а ты именно его и вызываешь) и пошёл бы дальше — твоя персона мне не настолько интересна, чтоб с ней долго возиться. Но почему-то, открывая комменты, я был на 99% уверен, что найду это там.

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

А вот ты, дружок, весьма неосмотрителен, показывая тут своё реальное имя.

Так, я знаю, що моя позиція, порівняно з вашою, дуже невигідна.

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

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

Аноніме, я читав собі ДОУ, побачив два треди (підряд) з одинаковою тенденцією. Здивувався/усміхнувся. Задав людині запитання. І крвмть набігла купа страшно байдужих до моєї персони російськомовних вчити мене «правильній» боротьбі. На себе зі сторони подивіться. :)

Это круче, чем отсутствие вообще любой кириллицы на клавиатуре или нет?

До речі, а якби прогортавши 8 років моїх коментарів, ви не знайшли нічого російською мовою, які би були ваші наступні кроки?

Знову ж таки, I wonder, how far it can go. :)

Ты нашел 2 кейса? Реально много!
А теперь прошерсти по тредам и посмотри как часто русскоязычные переходят на украинский в ответах и ты поймешь, что они угождают украиноязычным намного больше.
Но пристебался ты именно к этому кейсу, чуть ли не единственному, который нашел, провокатор.

А можна приклад, хоча би один? Бо я направду не бачив ніколи. :)

just to please their Russian-speaking opponents

Hmmm, Iʼm really wondering how you deduce a real reason here and why are you certain that is the reason. A crystal ball?
(Just for me, this looks like a form of context inertia.)

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

Полностью зависит от контекста. Производительность измеряется в рамках команды. Все это лежит вообще на уровне инсктинктов, когда наши предки с каменными копьями ходили на мамонтов. У одних команд была стратегия брать только молодых и сильных мужиков, у других в охоте принимали участия почти все, одни загоняют другие кидают камни на башку и т.д. Третьи вообще начали выжигать лес и выращивать на плодородном пожарище пшеницу. Во всех случаях по разному формируется социальная иерархия, кто кому нравится и не нравится и т.д. Один и тот же человек в одной команде может прижиться и показывать нужный результат, а в другой скажем тимлиду не понравится и вообще не сделать ни одной задачи за полгода. P.S. А теперь в спомним кто сегодня кушал хлеб на завтрак, а кто шашлык из мамонтятины.

А може хтось може визначити лоу перформера в контексті роботи менеджера? Чи є якісь «червоні прапорці» в роботі менеджера, коли можна сказати, що він не тягне?

0. Iнертний і без ініціативний, або взагалі нічого не робить, або лише формально приймає участь (таскає джира тикети по борді), а далі моя хата з краю лише б від керівництва не дали по голові, якщо дають «дрюче команду» у роботі взагалі не розбирається і не має бажання
1. Мікро менеджмент — за усіма і все перевіряє, делегує лише формально, робив би сам але керівництво не дозволяє
2. Не розраховує проект, регулярно бере на команду більше ніж можливо зробити, не оцінює ризики і не закладає під них часу і ресурсів на усунення можливих проблем
3. Ігнорує інтереси однієї із сторін, або команди або клієнта — не тримає баланс
4. Ігнорує інтереси іньших команд, займається політичною боротьбою за методами підстав і «мені добре коли сусіду погано».
5. Робить кумовство на проекті чи в акаунті, розділяє людей на своїх і чужих
6. Не володіє собою, занадто сильно психологічно давить на людей.

У мене є стаття, там більшь детально прописано.

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

Національність тут майже нічого.

Чому національність? Звичайно ні, радше історичні традиції, ментальність і релігія (те що називається cultural difference), які орієнтовані переважно на колектив і суспільство, на відміну від європейського і американського індивідуалістичного підходу. Там в культурі корпорацій є і мікроменеджмент, і психологічний тиск та ігнорування інтересів рядових працівників (e.g. обов’язкові перепрацювання та мінімальні відпустки), боротьба з іншими тімами в межах одної корпорації, і т.д.

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

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

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

В аутсорсе коммуникация очень часто через пару тройку человек, которые тот самые тех менджмент.
Овертаймят часто молодые и не опытные, опытные в этом случае часто становятся причиной «текучки» :-)

Почему она не требует уделить времени техническому долгу, например. Почему не отказывается оверкомитится. + К овертаймам

Команда мож требовать, но оно все будет реджектиться, так как сроки горят, дедлайн на носу, клиенты недовольны, времени и ресурсов нет, но вы держитесь, итд.

Да. В конце-концов все сдаются и говнячат до конца

ой ... как на меня, совсем немного обЪективных маркеров, которые можно померить, и все не очень справедливые:
— турновер на проекте больше чем в среднем по больнице (а может быть проект хреновый :( )
— прибыль меньше чем планировалась (а если хреново планировали? )
— обнаруживается проблема, которую сам манагер решить не может и вверх не эскалирует, бо ж шо люди подумають ... это более однозначный признак, но так не всегда бывает.

обязанностью менеджера является «управление изменениями», соответственно красные флажки:
— изменения не происходят
— изменения плохо- или неуправляемы
— изменения происходят в неправильном направлении («правильное» направление оговорено и согласовано)

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

П.С. не знаю как с этим в Украине, но в Голландии часто густо замечал что по дефолту если шо то не получается, то первым страдает лид, менеджер, а то даже и директор. Как то работал год в конторе, в которой за год моей там работы поменялся топ менеджер аж 4 раза. Хозяева все искали как же поменять вектор у фирмы. И тот не такой, и этот не такой. На моей текущей работе постоянно получаем письма по корпоративной почте то одного начальника отдела уволил ген. директор, то другого. За последние 7лет только начальник нашего отдела остался не тронутым. А все остальные посменялись по нескольку раз. Мы честно говоря даже распереживались за нашего :).

Какой менеджер? , Product manager, people manager, account manager, technical manager, sales manager? Может быть вы дом строите, тогда это наверное construction manager. У всех разные роли и kpi. Да и kpi не более чем виденье руководства о том какие метрики считать корректными для роли.

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

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

Это слишком общее и удобное обобщение с целью нифига не делать и получать з-п. Для начала «решатель» задачи и должен определиться, хотя бы для себя, какой результат он ждет от работы программера: человекочасы, отчет в джире, количество строк кода, количество закрытых иссь, «гут» или «не гут» от заказчика абощо. Как на меня, наиболее близкий к истине последний критерий, но именно он и дает основания отмазываться «я думал», «я Пайтон учил», «я в 3-rd-party либу залез и застрял» и пр. в таком же духе. Правда это или нет — компетенция лида/ПМа и в принципе льохко определяется тем, знал ли кто-либо еще о том, что дев «думал» а не код писал.

Правда это или нет — компетенция лида/ПМа и в принципе льохко определяется

Лучший ПМ — это отсутствие ПМ

хороший индеец — мертвый индеец (ковбойське прислів"я)

Да, это правда, но только до момента когда Вам, вместо несуществующего ПМа, надо принять какое-либо решение по проекту, а потом обосновать его заказчику и отчитаться перед вышележащим начальством. Обязанности ПМа — разрешать многочисленные конфликты интересов, работать с людьми, и они никуда не испаряются сами по себе. Если девелопер ОК такими делами заниматься, то имеем тех-лидов и тим-лидов вместо ПМ-ов на проектах, но заказчик далеко не всегда хочет соглашаться с тем что суффикс «лид» означает что у человека будет на пару часов меньше времени заниматься кодом :(

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

Если людей больше трёх — нет.

Лучший ПМ/Лид/Архитект/девопс(особенно лид если много девопсов) которого не видно, но он как суслик :-) Обычно таких задача помогать/налаживать рабочие процессы и решать проблемы чтобы эти процессы работали гладко. Поэтому если тех менджмент оч хорош то деливери стабильный, факапы оч редкие, текучки мало, команда не срется и не депрессирует, заказчик доволен фичами и сроками...ну это конечно идеальный кейс :-) Но в целом направление такое.

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

А якщо баг чи критична враливість були пофікшені шляхом видалення шматків коду)?

Як оцінити продуктивність працівника який привносить Value шляхом видалення шматків коду чи реверту непотрібних змін?

повторюсь, надо смотреть пул реквесты. И количество строк кода в единицу времени — только один из критериев, причем в ряде случаев вторичный.

Это тоже самое что измерять продуктивность программиста путем подсчёта строк кода. Уже с 60 з годов прошлого столетия все подобные методики в ИТ потерпели крах.

Это не тоже самое.
Капитан очевидность подсказывает, что в нормальном процессе задачи распределяются исходя из велосити конкретно взятого девелопера.
А то у вас получаается, что (условно) июнь и сеньор в одной команде берут одинаковые задачи и тратят на них одинаковое время(в случае сеньора бОльшая часть времени тратится на кофепитие с девушками). Зачем в такой ситуации нужен сеньор — вопрос открытый.
И кстате улучшенная методика подсчета строк кода — количество фичеров в единицу времени — прекрасно работает для типичных фичеров

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

Отож, за вишою рекомендацією треба дуже суттєво розширити наявний штат розробників( +5% −10% )новими сіньйорними фахівцями які повний час будуть виключно робити оціночні судження роботи решти команди.

В поточній реальності — недосяжна мета.

Вы все верно говорите. Забываете только одну мелочь: пул реквесты(в нормальном процессе) уже ревьюваются более опытными коллегами(лидом, архитектором, сеньором и тд). Тоесть не нужен отдельный человек, достаточно тех что есть. Надо просто их спросить правильно. С учетом того, что(в нормальном процессе), ревьюверов больше одного, субьективность оценок сильно снижается.
Не благодарите :)

Тут мы возвращаемся в начало — перформанс определяет лид/манагер чье мнение очень не редко субьективно.

А я ж прямо написал: в нормальных процессах есть пул людей, которые апрувают пул реквесты, в том числе и друг друга. Поэтому собрав 2-4 фидбека, можно как минимум определить группу риска, и, например, попросить экспертов из соседней команды, посмотреть случайные реквесты чуваков из этой самой группы риска.
Не благодарите :)

попросить экспертов из соседней команды

Ты сам прекрасно помнишь как эти фидбэки писались в епаме, иногда норм, но в большинстве случаев по бырому за пару часов до лока абы отвязались, ну или подружился с челом и хочешь ему плюсануть в «карму» :-)))
Ну и РМ также к ним относились на 1 to 1 :-)

а вот это уже от ПМ-а зависит :)
найти людей, которые и компетентны и не «на отьебись» напишут, да и самому серьезно отнестись. В том же епаме я видел очень разные кейсы.

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

значит метрика количества пул реквестов выбрана неправильно :)
Ну и я ж прямым текстом написал, что обращение к спецам со стороны — exceptional case, для группы риска. Т.е. условно, пару раз в год.

а якщо дев 20 років на проекті ?) і просто фіксить раз в місяць проблему за 10 хв він ефективний ?)

...а все остальное время пьет кофе с девушками? :)

20 років на проекті

корвалол с бабушками скорее)

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

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

Угу, один написал код который великолепно быстро работает, потребляет мало памяти и без дефектов. Другой скинул говнокодище которое ещё и выкинуть придется и переписать. Первый работал три дня над задачей, второй два часа — а потом травил весь день анектоды с девушками.

Значит второй девелопер недозагружен. Ошибка менеджмента :)

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

1) Определить косвенные показатели качества. Не путать с бюрократическими цифрами на кшталт процента покрытия кода тестами.
2) Определить KPI.
3) Измерять KPI.
4) Бить себя стеной об голову при соблазне менять формулы и способы измерения KPI, подгоняя под результат; углом об мизинец — при попытке забить на косвенные показатели, которые говорят, подделываются ли KPI; яйцами менеджера о ногу — при попытке ставить планы на рост KPI и наказывать за их недостижение.

1. Хто має визначати ці КРІ
2. Хто має вимірювати ці КРІ? Менеджер, лід, СТО чи сам дев?
3. Чи мають КРІ та формули їх обчислення бути публічними? З одного боку, людям буде зрозуміло як саме оцінюється їх робота і чого чекають, з іншого боку, працівники почнуть гнатись саме за КРІ замість зосередження на корисній роботі.

1. Хто має визначати ці КРІ

Кто-то из (топ?)менеджмента.

2. Хто має вимірювати ці КРІ? Менеджер, лід, СТО чи сам дев?

Идеально это должно быть автоматически.

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

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

это должно быть автоматически.

Мем про команду бігдати
pikabu.ru/...​_bigdata_v_xsolla_8386389

Категорически против KPI :( Они эффективны лишь тогда, когда подопытный о них ничего не знает, в противном случае рано или поздно начинается работа на KPI : больше строк, больший процент, слаще поцеловать клиента, что само по себе и не плохо, но на качество продукта влияет практически никак. Но ничего не знать — это плохо, это гребцы начинаю возмущаться что «нас опять намахали», они-то думали что лучший — тот кто 12 часов на работе, а не тот кто больше иссь закрыл...

Именно поэтому KPI идут вторым пунктом. И ваш коммент — прекрасный пример, как вы пропустили пункт № 1, погнавшись за ключевым словом. Косвенные индикаторы — они такие, именно про их регулярный анализ наблюдаемый не должен догадываться, хотя про сам факт того что их могут привести как аргумент — знать будет. Но должен верить в случайность этого «человеческого фактора» вместо знания что это свойство системы.

Именно поэтому KPI идут вторым пунктом.

А-а-а... Гуманно тогда смотрится тот факт что «Бить себя стеной об голову» только четвертый пункт :8)

всё просто: чем больше у гребца удалёнок, тем он больше перформит. очевидно же.

Peer feedback обычно это показывает. Демотивирует команду поведением или кодом, требует дополнительных усилий со стороны всех в команде при общении или при код ревью. На фидбек реагирует слабо или не реагирует вовсе.

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

Спорно, если некто портит перфоманс всей команды/компании, которую я представляю своим бездействием (слишком рачительным зайчизмом) или генерированием говно-PR-ов — это очерняет нас всех — так зачем покрывать такого человека? Не просто так манагеры следят, чтобы производительность была стабильной.

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

Нету таких оценочных критериев. У человека могут быть низкие «софт-скилы», но он в то же время может писать много отличного кода, выполнять большой объём работы самостоятельно, и быть полезным для бизнеса. А может быть наоборот — весь такой активный-проактивный и коммуникабельный, любитель митингов и чатиков, создающий много шума, но код плохой и некачественный. И кто из этих двоих лоу-перформер?

От его начальника зависит. Если у оного мысль что главное это митинги, втом числе и пустые без результатные — то любителей по общатся потом еще и повысят.

быть полезным для бизнеса

Вы сами озвучили критерий. Потому что бывает и «много отличного», но абсолютно бесполезного с точки зрения ценности кода.

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

Можна визначення

low-performer

?
Це той хто перформить на якусь конкретну кількість процентів менше за інших? Так у нього і зп може бути меншою відповідно.
Чи можна вважати джуна який тільки прийшов на проект лоу-перформером?
Купа питань до цього терміну.

Я слышала что во многих компаниях не используют термины low/high и когда оценивают чью-то работу то дают оценки «meets expextations», «exceeds expectations» или «below expectations» (как я понимаю ожидания должны быть заранее известны и работнику и его менеджеру)

Это игра словами. Разницы между low и below expectations нет

Так у нього і зп може бути меншою відповідно.

Як ви на практиці бачите таку кореляцію? :)

Можна визначення

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

Нагуглила:
— Частые «недопонимания» своих же тасок
— Не проявляет инициативу
— Срывы сроков
— Плохая коммуникация и кооперация с коллегами
— Незавершенная и неаккуратная работа
— Отсутствие энтузиазма и энергии
— Не проявляет интерес к how things work на проекте
— Ненадежный, нельзя доверять, не сдерживает обещаний
— Не придерживается принятых в команде или компании правил, нарушает их
— Любит говорить «это не моя обязанность/ответственность»
— Оправдания и жалобы
— Абсентизм: частое отсутствие на месте (то обед то перекур то болеет)
— Скиллы не соответствуют должности
— Нежелание учиться
— Избегает лишних усилий или сложностей для себя
— На него часто жалуются

— Абсентизм: частое отсутствие на месте (то обед то перекур то болеет)

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

І як на цивілізованому заході відносятся до таких?

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

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

Если вышестоящий менеджер не из местной среды и есть мозк, то таким людям дают больше индивидуальных задач заставляя их фейлить, чтобы не удавалось прятаться за командой. Некоторых это исправляет, других — нет. Дальше выбор менеджера, обычно пару вызовов на ковёр для тёплых бесед и затем farewell lunch. Но менеджеров не из местной среды мало + необходимо наличие мозга и их на всех не хватает.

Но в среднем по палате такие люди есть и не особо они куда-то исчезают.

Если лично моё мнение, то я часто не понимаю как компании умудряются с такими троянскими лосями внутри ещё получать прибыль — я сейчас говорю про многие компании, такое тут есть везде. Иногда складывается впечатление, что люди готовятся к собеседованиям просто чтобы прорвать барьер, попасть внутрь и затем ничего не делать.

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

Но вдь в этом вся прелесть работы в корпорации! Ходишь еплуешь леццом, подружился с коллективом и вуаля! Ты словно в школе которую сам выбрал — делай минималочку, а остальное время трать на приятные шутки типа : разговоры на кухне, коты и соц сети, личные дела типа найти в интете барахло, собрать тур в поездку! Что еще тебе надо!? :-)

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

І сам перетворишся на правильного пацана.

Ну первый год с ковидом показал, что такие люди всё-таки на карандаше и под сокращение попадают одними из первых. Вот только ковид once in a while.

В сериале HIMYM была целая серия про это :-) «Как мы можем уволить этого чувака если он всегда приносит халявные пончики!?»

Это где, в Европе или в Штатах так?

Й&буть. Бо зазвичай на такі ролі здогадуються взяти «тьолочку».

в Канаді такого важко звільнити

Иногда встречаются целые команды, проповедующие митингизм. Приходилось работать в таких. Иногда больше половины рабочего времени — митинги. Причем некоторые по 6 часов длиной и люди занимаются на них откровенной фигней. Например, у меня было так, что первый час из 6 — командные игрульки,последний — квиз. Остальное время в основном ни о чем. Производительность команды была ниже плинтуса. Мне приходилось одну крошечную апишку писать месяц. Раз попытался сделать быстрее, так мне прямо заявили, что не надо гнать коней, потому что у них Agile:) Плюнул и забил, тем более, что меня как контрактера такие расклады вполне устраивали:)

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

отсутствие энтузиазма... єто как вообще?? запускать отладчик нада с сияющими глазами и улыбкой до ушей?

Какой отладчик? В продакшен — пущай вот они отлаживают! Главное не забыть написать документацию

отсутствие энтузиазма это когда ему не особо важно зачем он делает свою работу и для кого. закончит задачи тогда когда закончатся. в основном — к концу недели. К концу недели — с понедельника ещё раз посмотрю. Там где понедельник там — к среде закомичу. А к среде это автоматом уже — к концу недели. И если нет каких то видимых метрик то такие задачи могут висеть недели и месяцы. Даже дейли митинги часто размывают представление о том сколько же прошло времени. Кажется что задачу начали только на прошлой наделе, а затем смотришь на количество шариков на тикете в джире, наводишь на них мышку а там написано 71d (в ин прогресс).

Могу от себя добавить что «отсутствие энтузиазма» часто сопровождается фразами «а зачем ты ищешь проблемы в моём проекте ?» и «Концентрируясь на проблемах — мы чувствуем себя беспомощными. Концентрируясь на Решениях, Мы — Всесильны!» (может потому что перечитали Папика, и слишком самоуверенны, не ?) уже было так.

Вообще problem thinking vs solution thinking — то что отличает «местных безинициативных» умельцев, от успешных западных коллег.

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

Найн, имеются в виду 90-ые (или когда его там уволили)

Избегает лишних усилий или сложностей для себя

от же ж отщепенец — не хочет от забора и до обеда, когда все другие с песней и строем, имитируют присутствие экскаватора

Дед Мороз — прямо 100% попадание. Даже стишок рассказать — и то перекладывает на несовершеннолетних.

— Не проявляет инициативу

А що тут поганого?

Я думаю этот список работает как и закон о присутствии трудовых отношений: нужно набрать ответ «да» по нескольким пунктам чтобы попасть под подозрение в low performance

— На него часто жалуются

А якщо скаржаться, що занадто багато працює, за ним інші не встигають?)

— Частые «недопонимания» своих же тасок

Проблеми комунікації, а не перформанса

— Не проявляет инициативу

Проблеми менеджменту

— Срывы сроков

Проблеми менеджменту

— Плохая коммуникация и кооперация с коллегами

Особливості характеру. Проблема менеджменту

— Незавершенная и неаккуратная работа

Нестача досвіду в працівника та контролю за виконанням задач з боку лідів та менеджменту

— Отсутствие энтузиазма и энергии

Проблеми в компанії

— Не проявляет интерес к how things work на проекте

Проблеми менеджменту

— Ненадежный, нельзя доверять, не сдерживает обещаний

Можна сказати про будь-кого

— Не придерживается принятых в команде или компании правил, нарушает их

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

— Любит говорить «это не моя обязанность/ответственность»

Він наймит. Не зобов’язаний брати на себе зайву відповідальність на безоплатній основі. Наявні завищені очікування від працівника.

— Оправдания и жалобы

Проблеми менеджменту.

— Абсентизм: частое отсутствие на месте (то обед то перекур то болеет)

Якщо виконує поставлені задачі, то глибоко фіолетово.

— Скиллы не соответствуют должности

Проблема керівництва.

— Нежелание учиться

Не зобов’язаний нікому. Навчання співробітника — суто витратна частина компанії. Не є бізнес-задачею.

— Избегает лишних усилий или сложностей для себя

Абсолютно кожного стосується. Хто багато працює тому ніколи заробляти гроші.

— На него часто жалуются

Проблема менеджменту.

Поверить не могу, от кого я это всё читаю...

— Частые «недопонимания» своих же тасок
Проблеми комунікації, а не перформанса

Отсутствие обратной связи, Невнимательное отношение к комуникации, Занижение ценности работы или коммуникации. Сначала это нужно разбирать а не проблему коммуникации. Мало раздолбаев которые ходят на 12 часов митингов а затем ничего не понимают и не помнят? Те самые которые просят скриншоты/дизайны чтобы не читать 4 параграфа текста. И те самые за которыми десяток багов по пропущенных НФРах.

— Не проявляет инициативу
Проблеми менеджменту

Лихо ты сразу в менеджмент записал. У людей не бывает депрессий?! У людей не бывает ошибочных решений по принятию офера с закрытыми глазами и затем выгорания без обратной связи?! Люди не прокрастинируют?!

— Срывы сроков
Проблеми менеджменту

Срыв сроков это проблема исполнителя. Если исполнитель не может вовремя прийти и уведомить и блокерах или срыве сроков, то это плохой исполнитель. Джуну/Мидлу такое можно простить но синьорам нет. Если синьор не может подорвать жопу и вовремя сказать что есть проблема, а тянет её до последнего то он раздолбай.

— Плохая коммуникация и кооперация с коллегами
Особливості характеру. Проблема менеджменту

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

— Незавершенная и неаккуратная работа
Нестача досвіду в працівника та контролю за виконанням задач з боку лідів та менеджменту

Читай про срыв сроков.

— Отсутствие энтузиазма и энергии
Проблеми в компанії

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

— Не проявляет интерес к how things work на проекте
Проблеми менеджменту

Читай про отсутствие энтузиазма и энергии.

— Ненадежный, нельзя доверять, не сдерживает обещаний
Можна сказати про будь-кого

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

— Не придерживается принятых в команде или компании правил, нарушает их
Платять за виконану роботу, а не за виконання правил, які можуть бути дебільними по суті

Опять про принятие офера на закрытых глазах и ушах. Чаще это тот самый который обливает дерьмом рекрутёров и не придаёт значения первоначальному общению с ними для составления понимания о компании и её культуре. Отсутствие профессионализма в выборе своих заказчиков. Хватается за что угодно лишь бы бабки платили. Результат на лице.

— Любит говорить «это не моя обязанность/ответственность»
Він наймит. Не зобов’язаний брати на себе зайву відповідальність на безоплатній основі. Наявні завищені очікування від працівника.

Он на трудовой книжке?! Он подписывал должностную инструкцию?! Скорее всего это или работа через конверт или апворк или ФОП. Игнорирование того что написано в контракте. Отсутствие понимания что такое профессиональная работа и адаптация к заказчику и обратная связь.

— Оправдания и жалобы
Проблеми менеджменту.

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

— Абсентизм: частое отсутствие на месте (то обед то перекур то болеет)
Якщо виконує поставлені задачі, то глибоко фіолетово.

Такие вещи не идут в одиночке. Абсентизм это первый маркер ко всему вышеперечисленному. Нужно только копнуть. Запросить анонимный фидбек от коллег.

— Скиллы не соответствуют должности
Проблема керівництва.

В IT обе стороны разделяют риски мискоммуникации при подписании офера. Это 50/50 и обе стороны могли недостаточно прозрачно договорится об ожиданиях.

— Нежелание учиться
Не зобов’язаний нікому. Навчання співробітника — суто витратна частина компанії. Не є бізнес-задачею.

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

— Избегает лишних усилий или сложностей для себя
Абсолютно кожного стосується. Хто багато працює тому ніколи заробляти гроші.

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

— На него часто жалуются
Проблема менеджменту.

непрофессионализм. Отсутствие работы над фидбеком. Не запрашивает фидбек и коллег, заказчиков. Не работает над поведением, навыками, качеством работы чтобы поднять свой «рейтинг» в глазах окружающих. Если переложить на более понятный пример — открыл кофейню и продаёт дерьмовый кофе. Не интеерсуется какие там рейтинги на гугле и что пишут покупатели. Это чья проблема? Покупателя (нанимателя)?! Или профессионала.

_____
В целом твои комментарии как раз указывают что скорее всего ты сам лоу перформер раз такие базовые вещи не понимаешь.

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

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

Коммуникация это не про характер это про поведение.

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

Проблема сотрудника.

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

Он на трудовой книжке?! Он подписывал должностную инструкцию?!

Яка різниця на чому він? Хоч на Джаваскрипті. Давай візьмемо стандартну фразу, яка присутня в трудових договорах: «Мусить сумлінно виконувати завдання». Фраза ні про що. Хто буде визначати сумлінність виконання? Менеджер? За якими критеріями? Суб’єктивними? Повна маячня, а не вимога. Цей пункт працює проти працівника завжди. Він про звинувачення його в недостатній сумлінності, і довести іншого не має ніякої можливості. Це про покарання, а не про мотивування.

Оправдания это не про профессионализм. Профессионал не должен оправдывать свои ошибки или жаловаться.

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

Абсентизм это первый маркер ко всему вышеперечисленному

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

В первую очередь он профессионал участвующий в рынке. А рынок не стоит на месте.

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

Всё вышеперечисленное является элементами формулы почему человек избегает лишних усилий и сложностей.

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

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

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

This is me, last 20 years lol

а нафига его искать, не очень понимаю? Ну в смысле, что если команда не справляется из-за того, что кто-то забивает (а не по каким-то другим объективным причинам), то проблем с идентификацией едва ли вознкнет — достаточно поговорить с тимой. А если сравляется и норм велосити, то чего ради искать слабое звено?)

то чего ради искать слабое звено?

Ну как зачем ? закрывать план о 20% увольнении сотрудников кончено.

думал, такое практикуют фанги/околофанги. Но не наши компании, которые месяцами позицию не могут закрыть.

закрыть позицию раз в месяц то реферал бонус +хрюшке. А уволить кого — то отчетность заказчигам об оптимизации росходов. Все довольны вообщем.

то можна його то звільняти, то наймати назад :)

Скажи мне где этот план — и я скажу, где пастись HRюшках конкурирующих галер. Разумеется, когда заберут лучших, это всё равно в показателе отразится как выполнение плана. А если будут вопросы — скажут что у них внутренний конфликт и из жопы пахло.

1. Одна з цілей топіку — саморефлексія, тобто спроба оцінити себе.
2. Тримати в голові, що таке лоу перформер і не стати таким.

не стати таким

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

Для вас, як фаундера, мають підійти ті самі критерії, що і вигоряння: цинізм, апатія, низький рівень енергії, пасивність, агресія щодо колег і т.д.

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

А во сколько обойдётся найм нового и работа без лоуперформера? Где гарант что новый не будет лоу перформером? Сколько нужно времени чтобы вьехать в проект?

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

Что если оценка перформанса субьективная, дев не нравится лиду/команде по личным причинам(веган, мясоед, любитель поболтать, все время молчит, не смотрит игру престолов...етц)

И я не подкалываю, мне интересно, потому как многие галеры готовы платить бенч, порой месяцами абы был дев в запасе. ХЗ правда будут ли платить 5-7К за бенч долго.

Щас у меня проект такой что уже который месяц без созвонов с архитектором нихиба не могу сделать

Так, спостерігав такі проекти декілька разів.

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

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

Частота и объёмы коммитов + закрытие тасков. Всё это, в сравнении с другими кодерками.

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

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

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

Если сделать поправку на галеру, то сотрудник может быть включён во внутренние активности (интервью, ассесменты). Пока клиент доволен — нет смысла делать волны

Пока клиент доволен

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

Плюс кастомер далеко не всегда вникает в то как контрибьютит конкретный сотрудник, скорее может быть довольным общей работой команды.

В аутсорсе/аутстаффе такие решения принимает клиент, не галера, по результатам сотрудничества с конкретным членом команды.

аутсорсе

Клиент может максимум дропнуть человека со своего проекта. И обычно стараются до такого не доводить. Для этого и есть менеджмент на стороне галеры.

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

Насколько меньше и кто и как определяет нижнее пороговое значение?

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

Легко обходится — берешь тот же объем работ и разбиваешь его на большее кол-во коммитов

Это уже смотрится по обстоятельствам.

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

Кол-во коммитов в сравнении с другими можно использовать только как «сито» для оценки того стоит ли вообще начинать дальнейшие разбирательства

Плох тот лид и тот менеджер, который не знает суть работы своей команды и реальную пользу, которую каждый её член (не) приносит.

Ну вот и выходит, что хорошему лиду/менеджеру не нужны никакие performance KPIs, а еще он вряд ли сравнивает сотрудников между собой по количеству коммитов

По вашей логике в команде ВСЕГДА будет минимум один человек, который закрывает меньше всех остальных (если вот так взять всех отсортировать по вашим критериям производительности труда). Как по мне, это не есть правильный критерий определения лоу перформера, по крайней мере он не должен быть единственным.

Разумеется, это далеко не единственный критерий.

Другие кодерки могут двигать картинку на 5 пикселей вправо-влево, плодя кучу тикетов и ПР и гордо рапортуя об этом. В то время как ваш «кодерок» может две недели выдебаживать критический баг из-за которого продакшен постоянно падает и кастомер лаве теряет.

А что есть критический баг?
Один ты описал, но насколько критична кривая картинка?
Если я тебе скажу, что кривой UI при работающем приложении раздражает пользователей и в целом плохой UX, они приходят смотрят и уходят, не платят денег, не пользуются сервисом. Денежные потери могут быть еще больше, ведь все мы знаем, что пользователи ведутся на картинку. Теперь баг с картинкой стал критичней?

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

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

Если я тебе скажу, что кривой UI при работающем приложении раздражает пользователей и в целом плохой UX, они приходят смотрят и уходят, не платят денег, не пользуются сервисом

Ты видел капитализацию фейсбука и амазона? А их UX?

Уверен, что они решали и решают UX задачи, которые критичны.

На что лид и менеджер, которые таски и выдают, и их оценивают?

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

Лід в якого немає часу на команду — поганий лід, сам таким був перші пару років, коли набрався досвіду то в мене завжди вистачало часу на все.

это часто проблема не лида, а менеджера, который так бъет респонсибилити \ процесс у команды.

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

то в мене завжди вистачало часу на все.

Вот и первый лоу-перформер

А якщо у нього зп менша на 50% ніж у інших?

А кількість багів у цих комітах, а якість коду, а тести, а доки і т.д.

Это всё под «закрытие тасков».

Если менторство/митинги отвлекают от коденья — его проблемы. Пускай не менторит/не митингует.
Впрочем, из моего опыта, хорошим перформерам всё это не мешает быть в топ-перформерах проектов.

объемы коммитов — это даже интереснее ))

Можно ещё количеством строк кода

И ввести штрафы за отрицательное сальдо добавленных/удаленных

Наоборот!

Меньше кода — меньше багов/меньше тестов. Профит!

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

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

устранил плавающий баг без сценария воспроизведения

Если баг без сценария воспроизведения:
— почему ты решил, что там был баг?
— почему ты решил, что ты его пофиксил?

А вообще, похоже на low-performer.

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

а вообще, похоже на долб**б

Если ты нашёл баг, как тебе удалось не суметь научиться его воспроизводить? А если ты так и не смог его воспроизвести, то может это вообще не тот баг?

В общем, больше похоже на шаманщину, чем на разработку. А увлечение шаманщиной — ведёт к low-performing.

Недавно было — иногда веб-сервер внезапно начинает отдавать странички не за неск миллисекунду а за секнуд 30-50...Странички некоторые, сложные некоторые простые как двери и данные из кэша.
Никакая не шаманщина просто в одном случае были дедлоки на незаметной страничке которые потом оправляли сервер в жепс и он начинал тормозить, в другой пересекалось с просадкой перформанса на сиквеле и джобами на нем.

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

Не все приложения это формошлепство где перформанс идмеряется количством форм и крудов для них.

когда баг найден-его любой суслик воспроизведёт;)

Если ты нашёл баг, как тебе удалось не суметь научиться его воспроизводить? А если ты так и не смог его воспроизвести, то может это вообще не тот баг?

Класический пример для мелких процов. Есть некая переменная, разрадностью больше разрядности проца. Записывается в прерывании, читается в теле основной программы. Предположим что для считывания процу нужно вполнить две инструкции.
Баг проявляется, когда между первой и второй инструкцией возникает прерывание и перезаписывает переменную. В итоге получаем половину бит старого значения, а вторую половину — нового. Понять в чем баг — легко. Специально сгенерить прерывание между этих двух инструкций — сложно.

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

Підписатись на коментарі