Комментарии 338
Вот сколько каждая компания могла бы сэкономить ежегодно, уволив их.
А если уволить половину или всех. Представляете сколько можно сэкономить? :)
Какие подсчёты, такие и ответы.
"Половина денег, которые я трачу на рекламу, не приносит пользы. Проблема в том, что я не знаю, какая именно половина".
А самое весёлое, что каждый раз эта часть разная.
Сегодня люди пришли с щитовой рекламы
Завтра с аудио
Послезавтра с буклетов
И так далее.
Из той же серии "пользователь редко использует более 5% возможностей программы, но разным пользователям нужны разные 5%".
*выкидываем половину резюме*
А неудачники нам не нужны
Если люди реально не работают, то что компания потеряет если их уволит?
ну предположим, что всë работает, то что ещë делать?)) А если уволить, то не факт что наработки не перетекут конкурентам или некому будет поддерживать этот код в случае изменений... Вы похоже не понимаете как всë работает в мире. И это не только ИТ, например автомастерская, если сегодня нет машин на ремонт, то всех уволить, а завтра снова нанять?))
ну предположим, что всë работает, то что ещë делать?
Покажите мне крупную фирму у которой всё работает и работает как надо. Без багов, без раздутых страница-приложений, без проблем с оптимизацией.
Вы похоже не понимаете как всë работает в мире.
Ну так расскажите мне. Я не вижу смысла платить деньги, причём местами приличные деньги, людям которые только изображают деятельность.
Насколько я вижу люди месяцами, а то и годами практически ничего не делают.
И это не только ИТ, например автомастерская, если сегодня нет машин на ремонт, то всех уволить, а завтра снова нанять?))
Я готов спорить на что угодно что если бы так себя начали вести работники средней автомастерской, то их бы очень быстро уволили.
Я не вижу смысла платить деньги, причём местами приличные деньги, людям которые только изображают деятельность.
Как раз те, кто изображает деятельность, в этот отчет не попали.
Есть сотрудники, которые освоили искусство написания отчетов, имитации важности на совещаниях и создания иллюзии занятости, а есть сотрудники просто хорошо делающие свою работу. Об их существовании за пределами отдела многие не догадываются.
Всё начинает тихонько разваливаться, когда кризис-менеджеры решают увольнять вторых, т.к. они не вписываются в придуманный ими KPI.
Всё начинает тихонько разваливаться, когда кризис-менеджеры решают увольнять вторых, т.к. они не вписываются в придуманный ими KPI.
Именно! Одна крупная питерская фирма развалилась из-за того, что "дефективные эффективные менеджеры" ввели KPI, общий моральный дух ушёл в минус, зато... KPI стал соблюдаться! Многим этот KPI надоел. А потом реально работающий народ стал разбегаться. Да так разбегаться, что продукты и клиентов поддерживать стало некому. Зато у оставшихся стал заоблачный KPI!
пс: ещё до разбегания народа и развала конторы, совместная работа людей из разных отделов, без которой невозможна работа нескольких проектов, попросту исчезла. Люди перестали тратить время на взаимопомощь, выполняли ТОЛЬКО СВОИ задачи и посылали нафиг всех обращающихся, ведь за помощь другим KPI не повышался, а только снижался, так как СВОИ задачи не получали достаточно времени на исполнение. Собственно, люди стали делать только свои задачи, всё по инструкции, дабы KPI не падал и не падали заработки. И местные начальники среднего звена ничего поделать не могли, ведь непосредственные исполнители (кодеры, тестеры, автоматизаторы, базовики и имплементаторы с эксплуататорами) выполняют приказ высшего руководства, а дело... не шло! Всё только ухудшалось, но менеджеры вплоть до развала конторы "не видели проблем". Бизнес на миллионы долларов развалился.
ппс: Вот, какой-то дефективный менеджер ввёл то, что «поможет избавиться от "работников-призраков"», в итоге убил контору. В итоге, им пришлось создавать новую контору с другим названием, переоформлять клиентов на неё, потерять огромную кучу денег, т.к. клиенты ставили их в позицию, что либо они уходят (конкуренты этой конторы были бы только рады), либо ценник на услуги будет снижен.
Без багов, без раздутых страница-приложений, без проблем с оптимизацией
А они находятся в зоне ответственности разработчиков из статьи? В крупной корпе вы не можете взять и начать править код, потому что вам там померещилось, что приложение раздуто...
Так речь не о том что разработчики сами должны туда лезть. Речь о том что у фирм обычно работы хватает и они не будут держать людей просто "про запас" и чтобы они при этом сидели вообще без дела.
То есть вариант дать новое задание своему работнику и получить результат в фирме обычно не должны рассматривать? Или просто - проблема менеджмента менеджера не касается?
Где я писал что-то подобное? Я вполне себе допускаю что в менеджменте у этих фирм тоже проблемы.
Но это не значит что такие разработчики правильно себя ведут. И что таких людей не надо увольнять.
И что таких людей не надо увольнять.
таких людей можно уволить и допустить ошибку, случайно.
Например чел реально ничего не делает, используя отмазку из статьи "на встрече в Slack"
А если его реально дергают с этими вонючими созвонами по 3 часа, что ему - сверхурочно ночью работать?) а ведь судя по статье - его можно уволить и словить профит)
И что таких людей не надо увольнять.
Тех, кто ничего не делает, не увольняют, потому что уполномоченные не знают, что те ничего не делают. Не всегда/не каждый может отличить деятельность от имитации деятельности.
Ну так расскажите мне. Я не вижу смысла платить деньги, причём местами приличные деньги, людям которые только изображают деятельность.
Никогда не слышали про микроменеджмент?
Представьте, что вы глава компании в которой работает 100.000 сотрудников. Каким образом вы найдете тех, кто мало работает? Будете с каждым лично общаться? Будете вводить метрики по количеству закомиченных строк в день? Будете вводить скриншоты с экранов?
Или расскажите мне ваш смысл, потому что вы похоже не понимаете что организовать работу на 5 человек и на десятки тысяч - это немного разные вещи.
Никогда не слышали про иерархическую структуру? Находить мало работающих сотрудников должны их менеджеры, находить мало работающих менеджеров должны менеджеры менеджеров, и т. д. Неужто бывают компании со 100.000 сотрудников, где всё успешно пущено в плоский горизонтальный самотёк?
Прикол в том, что владельцу бизнеса интересно развитие бизнеса. Ну максимам еще нескольким, кто владеет частью компании.
А вот почти все менеджеры, особенно среднего и низшего звена - простые сотрудники на зарплате, им интересен не бизнес а продвижение наверх и премии.
А тут выясняется, что если ты просто хорошо делаешь свою работу, за это тебя не повышают и премии не дают. надо показывать наверх что-то необычное или лояльно поддерживать других менеджеров, создавая политические интриги внутри компании, очковтирательство и красивые графики и диаграммы.
Поэтому то, что в вашем представлении "должны", практически невозможно организовать в крупных компаниях. И эти самые 5-10-15% призраков-сотрудников - для успешной компании не составляют проблем. А вот кризисные менеджеры, которые ну никак не смогут лично разобраться во всех нюансах, и полюбому зарубят топором полезные вещи, могут принести компании огромный вред, который в краткосрочной перспективе может показать прибыль, а негатив проявится только среднесрочной и долгосрочной перспективе, но этот негатив может привести к необратимому краху компании. Вот и решай.
Спорить не буду, расскажу анекдот из своей молодости.
Форд нанял советских ученых из НИИ Труда, проверить и организовать работу по НОТ. Месяц они ходили по заводу и выдали вердикт:
"Все организовано идеально, улучшать нечего. Кроме сотрудника в соседнем кабинете весь месяц сидит чувак с ногами на столе и курит. Он - лишний"
Ответ Форда: "этот чувак, два года назад, выдал рацуху, удвоившую прибыль завода. Насколько помню, он был в том же кабинете и том же состоянии. Это - самый ценный сотрудник".
Еще анекдот в тему:
В оркестр пришёл новый менеджер с MBA и заявил:
— Мы будем работать эффективнее! Сейчас проведём оптимизацию.
Он начал с дирижёра:
— Зачем вы здесь? Вы вообще ничего не играете, только руками машете! Уволен.
Дальше дошёл до скрипачей:
— У вас у всех одинаковые ноты. Зачем десять человек играют одно и то же? Оставим одного, остальных — на аутсорс.
Дошло до барабанщика:
— Почему вы отдыхаете половину времени? Перепрограммируем вас, чтобы вы работали на максимум.
Через месяц оркестр дал концерт. Получился идеальный… хаос!
Публика в шоке, но менеджер доволен:
— Зато расходы сократили на 30%, а звук — это вопрос восприятия!
Если все работает, то нужно просто бороться с энтропией. Она всегда растет.
Самое простое, эти люди не работают потому что у них в настоящий момент нет загрузки.
Появился проект - появилась загрузка.
А если нет сотрудника, то при любом изменении загрузки всё сыплется.
10% это смешные цифры, меньше чем офисный работник тратит на перекуры в рабочее время.
Во-первых. И никто не обязан сам искать себе загрузку, это должностные обязанности других людей. Которых в статье никто не обвиняет.
А во-вторых, "причина неясна, ищем" и "спецификация неясна, выясняем" - это по мнению авторов отмазки? Т.е. они думают, что люди делают такую же предсказуемую работу, как укладка кирпичей?
И в-третьих, просьба создать тикет - это отмазка?
В-четвертых, blocked by another team - это что, не причина? Ну т.е. если я, скажем, дизайнер карты мира для какой-то игрушки, но историю мира и что должно быть на этой карте, мне еще не дали, мне что рисовать, огурцы с помидорами?
В-пятых, про 2 недели и 1 день - см "во-вторых" и еще обязательно понимаем, что люди, в обязанности которых входит находить нагрузку, не всегда квалифицированы определить, на что нужен 1 день, а на что 2 недели.
Речь о том, что все пять этих объяснений могут быть оправданными причинами временного простоя, а могут быть выдуманными отмазками для постоянного безделья, и одно от другого слишком сложно отличить.
Программистов можно грузить разработкой тестовых приложений. Если важен сам факт постоянной нагрузки и на самом деле не имея цели в дальнейшем раскрутить проект. Для примера, берем игровую индустрию. Есть входные данные планируемой игры, открытый мир(космос, на земле), далее выбираем стратегия, симулятор, потом сценарий. Куча вариантов и идей. Загруженность обеспечена на постоянной основе.
Крупные игроделы уж очень вряд ли делают всего одну игру 3-5 лет. А рокстарс одну гта пилятс таким промежутком лишь для того чтобы был эффект новизны, а он невозможен если делать игры даже раз в 5 лет, по причине слабого роста производительности чипов.
Программистов можно грузить разработкой тестовых приложений
А солдат грузить покраской травы, например.
Только солдат, красящий траву, способность красить заборы не потеряет от этого.
А среди программистов статистически сильно больше доля людей с состояниями, при которых бывает выгорание как медицинский термин. От которого восстанавливаются года 3-4.
Скорее "копайте пока здесь, а я пойду узнаю где надо"
никто не обязан сам искать себе загрузку, это должностные обязанности других людей
Это правда. Но обычно в колонке TODO таск-трекера есть длинный список "следующих" задач, и правило используемое в конкретной команде как их брать (следующую уже назначенную на тебя, следующую не назначенную на никого, любую какая нравится, и т.п. плюс обычно есть правило что делать если следующих задач конкретно для тебя там нет - обычно уведомить об этом своего тимлида). И чтобы при всём этом остаться по-честному без задач - это надо чтобы либо тимлид облажался, либо чтобы в компании реально не было задач для твоей команды.
"причина неясна, ищем" и "спецификация неясна, выясняем"
Тут всё сложно. У хорошего тимлида на такие ситуации должно выделяться ограниченное время, по истечению которого он должен поинтересоваться есть ли результаты, а если их ещё нет, то что конкретно уже было проделано за прошедшее время и оценкой сколько ещё времени требуется на эту задачу (или кому её лучше передать, чтобы повысить вероятность её успешно завершить в разумные сроки).
В любом случае как только прекращаются активные действия по задаче (т.е. вместо отладки проблемы разработчик переходит в режим ожидания ответа от кого-то другого) нужно брать следующую задачу из трекера.
просьба создать тикет - это отмазка?
Нет. Но нередко используется как способ отложить выполнение задачи и/или переложить её выполнение на другого, поэтому и попало в этот список отмазок.
blocked by another team - это что, не причина
Бездельничать? Нет, конечно, не причина. Заблокирован по одной задаче - займись другой задачей.
люди, в обязанности которых входит находить нагрузку, не всегда квалифицированы определить, на что нужен 1 день, а на что 2 недели
Не всегда. Поэтому за этим и должен приглядывать тимлид, его квалификации для этого вполне достаточно (а если и нет, то обычно всё-равно никого более квалифицированного рядом нет). В целом, если бизнес выдал задачу на 2 недели а её удалось сделать за 1 день - я тут проблемы не вижу. Бизнес получил что просил в требуемые сроки - значит всё ок. Уставать на работе совершенно не обязательно, если работодатель и так тоже доволен.
Подстраховку. Никто не работает 100% времени.
Будет задач больше - как быстро HR найдет новых? Или компания будет платить сверхурочные? Нагружать на 100%, а потом оплачивать психолога выгоревшим или искать новых после уволившихся?
Упомянутые 9.5% отличный результат, более того, имхо, неадекватно заниженный.
И это если еще не вспоминать о том, что зачастую работа как раз и состоит в том, что бы работы не было. Сделал прогер без багов с первого раза программу - сидит отдыхает, ай ай ай, 9.5% времени он отдохнул, атата, так? А другой 146% времени впахивает, задерживаясь за свой счет, 40% из которого уходит на исправление багов, при чем из-за него еще и отдел тестирования напрягается. Свободное время - зачастую признак качественной работы.
Причём здесь какое-то "будет задач больше"? Вы о чём? Покажите мне ИТ фирму в которой нет технического долга, возможностей для оптимизации, необходимости в создании внутренних тулов и так далее и тому подобное.
Если фирма не хочет увольнять людей, то она всегда может найти что-то полезное чтобы их занять.
оптимизация ради оптимизации зло. как впрочем исправление тех.долга без выхлопа.
А откуда взялась именно оптимизация ради оптимизации? Что, необходимой оптимизации не бывает?
Вы реально хотите сказать что у крупных фирм с их продуктами всё просто идеально и там нигде ничего оптимизировать не надо? И у них нет раздутого и тормозного софта?
Софт тормознут по причине моды на фреймворки, а не из-за "бездельников", которые вместо тонн говнокода вносят оптимальные исправления, которые и выглядят как упомянутые в статье "три коммита", в то время как "небездельники", которых хвалят в статье, пишут тонны тормозного говнокода лепя заплатку на заплатку, которые и создают те самые тормоза, на которые вы жалуетесь.
Софт тормознут по причине моды на фреймворки, а не из-за "бездельников",
Во первых одно другому не мешает.
которые вместо тонн говнокода вносят оптимальные исправления, которые и выглядят как упомянутые в статье "три коммита", в то время как "небездельники", которых хвалят в статье, пишут тонны тормозного говнокода лепя заплатку на заплатку, которые и создают те самые тормоза, на которые вы жалуетесь.
Вам сову не жалко?
И вы реально никогда не встречали людей, которые просто не хотят работать и по возможности стараются этой самой работы избегать?
Ну вот сидит бэкэндырь с лайвовым сервисом, смотрит чтобы у него SLA не опускался. Какой ему техдолг чинить? На раст переписать чисто по приколу? Или может базу данных взять другую чтобы внезапно добавить какую-нибудь хитрую распределенность, хотя в требованиях этого нет? При всем при том фронтенд, использующий этот API вполне может зашиваться по задачам, пока бэкэндырь ждет ситуации для воспроизведения какого-нибудь гейзенбага. В итоге бэкэнд выглядит бездельником. Ну и все эти истории про то как в энтерпрайзе фикс в пару строчек добирается по полгода до основной ветки тоже частое явление, поэтому в том же фейсбуке работа с версией кода звучит как форк от форка форка.
То есть работника, который создал технический долг и не оптимизированный код - вы пошлете его чинить?) Звучит разумно)
Внутренние тулы? Это называется велосипед, вообще-то. Потом приходишь, а там тебе говорят у нас тут внутренний тул и тебя в дрожь кидает.
То есть работника, который создал технический долг и не оптимизированный код - вы пошлете его чинить?) Звучит разумно)
То есть вы хотите сказать что эти люди мало того что сейчас ничего не делают, так ещё и создают технический долг и плохие приложения? И таких не надо увольнять? :)
Внутренние тулы? Это называется велосипед, вообще-то
Вообще-то совсем не обязательно.
Внутренние тулы? Это называется велосипед, вообще-то.
вы вероятно будите удивлены, но абсолютно все инструменты которые сейчас де-факто стандарт когда-то были на уровне внутренних тулов
Если фирма не хочет увольнять людей, то она всегда может найти что-то полезное чтобы их занять
Ну вот мы и пришли к пониманию подлинной причины - херовый менеджмент. Как говорится - главное в ходе расследования не выйти на самих себя
Вы видимо статью неверно поняли. Тут не про то, что у одного человека простой и отсутствие работы 10%, а то что 10% работников практически НЕ РАБОТАЮТ, внося малое количество изменений и коммитов. Тут есть вопросы, потому что нет данных о задачах этих инженеров (может это Лиды, которые не уходят сами или задачи требуют большого количества времени) но суть статьи не в простое в работе, а об отсутствии работы
НЕ РАБОТАЮТ, внося малое количество изменений и коммитов
суть статьи не в простое в работе, а об отсутствии работы
Оксиморон же. Если не работают, то кто вносит правки? А если вносят, то почему это называется "не работает"?
В статье, если посмотреть исходные данные в ней, а не общие выводы: один из критериев "неработы" это "меньше 10% вклада от среднего по некой выбранной методике оценки коммитов", второй еще более грубый.
Это значит что все же у них есть задачи и они их все же выполняют.
10% максимально эффективных разумных людей, которые четко знают, что хотят, которую вертели на приборе корпоративные ценности и знают, что весь их отдел творит дичь, а они честно признают, что пришли чисто за зарплатой?)
Кстати, возможно единственные кто знает, как сделать работу департамента эффективной, уволив 90% других людей)
Нет. 10% людей, которые не работают и получают за это деньги. По крайней мере в статье речь идёт о таких.
Так что вы пишите про кого-то другого.
Проблема в том, что работа не ограничивается только комитами.
Конечно. Но и три коммита в месяц это не нормально для среднего разработчика.
А если он в отпуске? ;)
У разработчика есть непосредственный начальник, который знает, чем занимается подчинённый. Если не знает - вот с кого нужно начинать оптимизации.
А если он в отпуске? ;)
Весь год?
Если не знает - вот с кого нужно начинать оптимизации.
А кто-то где-то писал что это не надо делать? Разве от этого проблема с тем, что люди не работают и получают зарплату, перестаёт быть проблемой?
Вы сейчас, кстати, нашли главную причину, почему таких не увольняют. Потому что начальнику надо прийти и сказать: у меня есть подчиненный, который нифига не делает. А первый вопрос будет - так заставь его, а тебе проще самому сделать, чем его заставить.
И проще просто молчать.
Это вполне может быть нормальным, при исправлении трудноуловимого глюка на поиски которого ушло больше двух недель.
В таких компаниях средний разработчик (L4 software engineer) будет заниматься не только кодингом. Писать спеки, готовить данные, экспериментировать, делать презентации и репорты, общаться с коллегами из других отделов, менторить, интервьювить, вести различные инициативы, обучаться и так далее. Импакт не только написанием кода достигается.
Ковид четко показал, что будет, если оптимизировать излишние койкоместа в больницах =) В дискретный момент времени точно будет выигрыш, главное горизонт планирования поменьше задавать,чтобы случайно не задуматься о последствиях... :/
Эффективный менеджмент бесконечно далёк от теории массового обслуживания.
Во первых причём тут больницы? Во вторых вы серьёзно хотите сказать что фирмы знают что эти люди не работают и всё равно оставляют их у себя?
фирмы знают
Не знают, в том и дело. Фирма начальство выстроило какую-то систему KPI, эта система показывает какие то цифры. Это в мастерской где 3 слесаря сложно спрятаться, а в коллективе из 100 человек - никто не знает, чем занимается чувак из соседнего отдела. селяви. А в коллективе из 500 человек бюрократический аппарат (а без него никак) будет заниматься исключительно выполнением KPI и прикрытием своей задницы.
Ну так никто же не говорит что фирмы всё делают правильно. Речь исключительно о том, что в этих фирмах есть люди которые ничего не делают, но получают зарплату.
Почему так происходит это отдельный вопрос. Вполне себе допускаю что проблема в том числе и в некомпетентном менеджменте.
То что они почти ничего не делают, совершенно не значит, что всё без них будет дальше работать. Там где "бездельник" обойдётся парой строк кода, "небездельник" срочно взятый на его место, наговнокодит так, что создаст ненужную работу вообще всем, включая ТП и клиентов, в том числе и "бездельнику", которого будут срочно выискивать, чтобы он вернулся и опять "бездельничал".
То что они почти ничего не делают, совершенно не значит, что всё без них будет дальше работать
Я вполне себе допускаю что есть и такие люди. Но их однозначно не 6% или тем более 9%. Ну вот никак.
С другой стороны я знаю кучу людей, которые не будут работать если у них не стоит кто-то с палкой за спиной. И в ИТ я тоже таких людей немало знаю. Или вон можете посмотреть сколько на хабре пишут про прокрастинацию.
Поэтому я вполне себе верю в то, что особенно в крупных фирмах действительно есть люди, которые реально бездельничают за зарплату.
Поэтому я вполне себе верю в то, что особенно в крупных фирмах действительно есть люди, которые реально бездельничают за зарплату.
Конечно есть. Но в выборку они не попадают, потому что умело занимаются ИБД, иначе им бы уже давно прописали пинка.
А вот это утверждение как минимум надо было бы доказать. Потому что я думаю что в выборуку такие люди тоже попали.
То есть однозначно не все, кто попал в выборку, это исключительно "бездельники". Но на мой взгляд и они там тоже есть. Причём не то чтобы в явном меньшистве.
>>Но на мой взгляд и они там тоже есть. Причём не то чтобы в явном меньшистве.
Cуждения основанные на личном опыте и восприятии мира. Свечку не держали - овец не считали. По личному опыту и восприятию мира вашего оппонента все наоборот. Кому верить? Вам или ему? Подтверждаемых фактов ни один не привел. Все на личных ощущениях.
PS: Сцена из Office space о мотивации
https://youtu.be/OwfNjGxa_D4?t=129
Это в мастерской где 3 слесаря сложно спрятаться
в эту игру могут играть трое)
Во вторых вы серьёзно хотите сказать что фирмы знают что эти люди не работают и всё равно оставляют их у себя?
Да, я такое встречал вполне сознательно как в компаниях которые занимаются разработкой, так и в совсем других сферах. И если в компании из сферы разработки честно говорили, что проще держать незагруженных людей чем чуть что искать новых (на тот момент на рынке найм был совсем трешовым), то в иных сферах говорили очень специфичными словами про сознательную избыточность и т.д.
Что-то вроде следующего, сокращаю очень сильно ибо обычно это целый длиный диалог рассуждений взаимных:
Да, эту работу могут делать 5 хорошо мотированных толковых людей, но у нас всесто этого 25 типовых балбесов, потому что:
во-первых, где ты быстро найдёшь 5 толковых людей быстро чтобы сформировать отдел? нет, типовые балбесы с обычными в одном деле плохо уживаются, начинаются неприятные вопросы про почему Вася за «ту же самую работу» получает в 2-3 раза больше и т.д.;
во-вторых, если не дай бог что-то случиться с персоналом, например заболели, попали в ДТП, решили уйти по ультиматуму жены (реальные примеры), или банально забухали, то потеря 1-2 людей из команды 5 людей это будет трагедия, и нагрузку возросшую проблема вытянуть и замену найти, в то время как даже если половина из 25 раздолбаев забухает, то вторая половина со скрипом и неголование как-то да справится;
Есть некоторая ирония в том, что железо не должно быть загружено на 100% во избежание проблем при росте нагрузки, но с людскими ресурсами в компаниях так не считаются. Все должны впахивать 100% времени, а при росте нагрузки...
А разве задача обеспечить работой сотрудников, это не задача работодателя? Вот пришел ты в компанию, там был завал, работал каждый день с переработками со всей командой, закрыли хвосты, задач стало сильно меньше, и кому-то не достается вовсе. Что значит нужно увольнять? Если услуги сотрудника работодателю больше не нужны, то пожалуйста сокращайте.
Если сотрудник специально пришел на работу как самозванец и сидит только эмитирует работу, это другое, такого уволить не составит труда, но и он врятли в такие метрики попадет.
Это естественное распределение "ресурсов" в сообществах. У муравьев примерно также. В любом сообществе будет фиксированный процент "бездельников" которые мобилизируются в случае необходимости для данного сообщества. Увольнение этих людей приведет к тому что произойдет очередное перераспределение и появятся очередные "бездельники". И так пока компания не закроется. Данное количество "резерва" всегда необходимо как для подмены уставших так и для ускоренного буста при определенных действиях.
Об этом уже было сломано олимпиард копий.
Скорее всего из оставшихся , появятся другие люди которые ничего не делают. Процент в среднем стабилен в больших компаниях, и это не только IT
Компания потеряет выходное пособие
Тогда из тех, кто работал, выделится группа которая перестанет работать. И всё повторится. Проверено.
Согласно ЭТОМУ исследованию (оно же проводилось в разных компаниях и это усредненные цифры) у тебя получится такой сценарий:
- из 100 человек 10 показывают метрики на уровне призраков.
- ты их выявляешь и увольняешь.
- из 90 человек 9 показывают метрики на уровне призраков.
- ты их выявляешь и увольняешь.
...
Более умное поведение, видимо, оценить в своей копании показатели, и, если они отличаются, - вдаваться в детали...
Я автор этого исследования. Соглашусь с вами, что эти расчёты выглядят немного кликбейтно. Но я упоминаю, что это чисто гипотетический сценарий – у меня нет эмпирических данных о производительности инженеров в этих компаниях (а если бы были, я бы не мог об этом сказать).
Надеюсь, вы понимаете, что для привлечения большего числа участников в исследование иногда приходится использовать кликбейт. Основные результаты исследования абсолютно надёжны, но некоторые расчёты "на салфетке" выглядят довольно громкими. Виноват :-)
Типа такое себе. Иногда можно на неделю уйти в раздумья, а потом сделать ключевые правки. Так сто считать количество и интенсивность коммитов, это такое себе. Лучше посчитать эфыект.
А по поводу увольнений - надо. Но вместе с ними всех «соучастников» - техлидов, техдиров и менеджеров, которые это прошляпили и которым норм. Очевидно, что они суетологи, которые не понимпют, что происходит
Как-то раз почти три недели ушло на коммит из одного символа. (некто понафигачил запрос длиной в десятки килобайт обращаясь к таблицам по коротким именам из 2-3 букв и в одном месте одну букву перепутал, что вызывало неэфемерные, но трудно воспроизводимые проблемы).
Если править баги, то часто изменения очень небольшие, а времени уходит туча. Скорее всего по метрикам таких исследований такое может уйти в корзину бесполезной работы.
А если задача предполагает еще и рисерч, то вообще хз что коммитить. А на то, чтобы, скажем, проанализировать существующие программные решения для выбора оптимальных к нашему проекту можно и день, и два потратить
По результатам рисерча можно написать рипорт: вот такие решения я вообще обнаружил, проверял так-то, выводы по каждому решению такие-то, выбрал такое-то по совокупности критериев таких-то. Полезная вещь, если не доводить до фанатизма. Даже не в смысле "больше бумаги - чище задница", а потому, что через год ведь иной раз и сам не вспомнишь, почему выбрал эту херню, хотя вон та, другая, вроде, перспективнее выглядит.
Я обычно прошу (и сам коммичу) фиксировать блокноты (jupyter, с выводами, да большие, но удобнее) и пайплайны, даже если не вполне успешно работает. Не единожды доставал из репозиториев код годовой и более давности, когда внезапно понадобилась подобная идея в вообще другом контексте. Плюс, помогает избегать повторений экспериментов, ну и подобие отчётов без лишнего бумагомарания
Я автор этого исследования. Мы считаем, что наша модель учитывает это, потому что если баги влияют на множество зависимостей, то модель это распознает. Признаю, существует риск, что модель может этого не учесть. В худшем случае? Около 5 из ваших ~48 продуктивных недель в году могут быть неточными. Зато остальные 43 недели будут довольно точными.
Как-то раз почти месяц ушёл на замену одного символа.
Приложение с нативной либой рандомно сегфолтилось на 32-бит мобилах, но работало на 64-бит. В итоге оказалось, что там написали проверку на наличие фонового треда как `if (pthread_id <= 0)`, а ID — не число, а рандомные 32 бита. На 64-бит телефонах они все помещались в младшие разряды, а на 32 иногда залетали в знаковый бит, и происходил бабах. Замена на `if (pthread_id != 0)` всё починила, но предшествовали этому несколько недель с дебаггером и приколами типа рассчётов смещений в структуре которая когда-то могла быть по тому адресу, где фактически бахнуло, и всем таким :-)
Я автор этого исследования. Отвечу, скопировав комментарий, который я уже оставлял на похожее замечание:
По моему опыту, такие примеры звучат убедительно в риторике, но часто не подкреплены доказательствами. Мы годами анализировали эти вещи. Случаи, когда инженер тратит "недели на исправление критической ошибки", действительно бывают, но основная часть работы инженера обычно не про это. А если в команде есть инженер, который занимается "поиском сложных багов, которые никто больше не может найти", об этом, как правило, все знают.
Модель не идеальна, и я это признаю. Более того, я всегда открыт к критике – это помогает мне шире взглянуть на вещи.
Ну я и не говорю, что каждую неделю так было. На один такой баг за всю карьеру на том месте пришлось где-то с десяток таких, где фактический баг чинится за час, я говорил лиду, что сделаю за день (ибо потестить надо и почиллить, как без этого), а от него получал ответ, что один хрен со стороны заказчика блокеров на неделю вперёд в этой части проекта, так что особо не торопись лишнего :-)
ЧСХ, такая лафа была не на удалёнке, а вполне себе в офисе. Прям с ностальгией порой вспоминаю это время, офис в центре города, в который приходишь и 70% времени занимаешься своими проектами на рабочей машине — никто ничего не говорил, если не наглеть. Потом уходишь домой и вполне себе от них отдыхаешь. А вот сейчас на удалёнке наоборот жопа и завал порой бывают такие, что ни пёрнуть ни выдохнуть за день — заказчиков никаких нету, блокеры создавать некому, как сам сделал, столько команда и заработала %) После работы можно сесть за свой проект, конечно, но ощущение двух-трёх-пяти работ (в зависимости от состояния пет-проектов) перестало покидать уже давно.
Вообще, как по мне, ушат говна вам принесли в комменты не за точность модели и не за такие вот выбросы, когда в машинный код в андроид-аппе лезть надо первый и последний раз за 15 лет разработки, а за то, что это очередной шаг от ремесла к конвейеру. Люди очень не любят когда их сводят до функции рода «писатб кот», выкидывая за рамки всё остальное.
Для меня, например, одной из критических мотиваций к уходу с вышеописанных «райских садов» была невозможность на рабочем месте воткнуть в уши хотя бы плеер с музыкой, не говоря уже про хорошую акустику. Ну вот привычка такая, если погружаешься в проект, навалить басов аки в заниженной приоре, да на 180-250 BPM, иначе без тактового сигнала мозг лагает и еле шевелится.
Кому-то, может быть, точно так же нужно с утра загрузить в голову проект и пойти поспать часок-другой, чтобы потом за полчаса всё написать, а не пытаться в сознании еле еле из себя что-то выдавливать.
И тут уже, конечно, всё сводится к тому, чтобы найти фирму, с которой вы идеально совместимы по этим тараканам — но таких, увы, меньшинство, в отличие от любителей завернуть трекер в трекер и сверху трекером отслеживать эти трекеры, а содержание статьи отчасти апеллирует именно к таким технологиям и компаниям. Вот и понеслась кочка по пизде...
Индивидуальные инженеры не понимают, что моя модель значительно лучше того мусора, который используется в большинстве случаев. Не знаю, как в России, но в США все пользуются глупыми метриками вроде подсчёта коммитов, DORA (исследование Microsoft/Google, которое вырвали из контекста и исказили) и так далее.
Моя цель – сделать разработку ПО более меритократичной, прозрачной и ориентированной на ответственность. Меньше тумана, интриг и политики)
Моя цель – ...
Ваша цель - впарить ЭТО лохам. А то, что ваши клиенты разорятся - это "лох - не мамонт, не вымрет".
Моя цель – сделать разработку ПО более меритократичной, прозрачной и ориентированной на ответственность. Меньше тумана, интриг и политики)
Извините, но это буллшит-бинго. У меня были и фиксы из одной строки, которым предшествовала неделя поиска, и фиксы строк в 10, которым предшествовали три недели бюрократии. Сам код был написан и отлажен за день. А потом он гулял по ревью.
И вариант "ой, мы откатили ваш уже смёрженный PR, у нас тут апдейт кода большой и новый релиз, а он нам много сломал. ну вы потом почините ещё, да?" (PR на 30+ файлов, куча мелких фиксов).
Особенно весело, когда ты - контрактор удалёнщик, и пойти и подёргать за кресло ответственных за ревью нельзя.
Меритократия работает в коллективах локальных и "маленьких" (ну где-то до числа Данбара). В больших менеджеры разводят полный "П".
за то, что это очередной шаг от ремесла к конвейеру.
Да лаааднааа, вы его сначала сделайте, этот шаг, а потом уже обсудим параметры гипотетического ушата с говном. Тут, скорее, вполне понятное раздражение в адрес очередного эксперта по эффективной эффективности, в очередной раз заявившего, что "а теперь я и тебя посчитал!" и в очередной же раз вывалившего в качестве иллюстрации очередную оторванную от жизни хрень.
три недели ушло на коммит из одного символа
вы уволены)
/s
Вы очень непродуктивны, и надо вас, как минимум, вы*бать, а, возможно, даже и уволить. А тот человек, который нах*ячил этот запрос, - у него, ведь, наверняка, очень развитый soft-skills и правильное Виденье Миссии и Ценностей Компании, т.ч он, в отличие от вас, намного более ценный сотрудник.
На практике будет еще хуже: ушел в отпуск или заболел, коммитов нет - увольняем.
Другой способ взглянуть на это — подсчёт коммитов кода. Хотя это несовершенный способ измерения производительности, он выявляет бездействие: ~58% делают <3 коммитов в месяц, что соответствует текущей метрике из исследования. Остальные 42% вносят тривиальные изменения, например, редактируют одну строку или символ, делая вид, что это работает.
Авторы - дебилы! По их мнению, те кто искал трудноуловимую ошибку и нашёл её - "бездельники заслуживающие увольнения", а те кто нахреначил кучу глюкавого глючного торомозного говнокода - "молодцы!".
PS добавьте в голосование вариант "авторы - дебилы".
Свежий пример результата борьбы "бездельниками":
https://pikabu.ru/story/otvet_na_post_kpi_12064135
В моей первой компании начальники ввели "гениальную" систему оценки работы инженеров-конструкторов - в форматках А(1-4) в штуках. Сколько начертил за день чертежей - такая и премия. А4 - это считалась одна форматка, А1 - тоже, несмотря на то, что этот чертеж больше в несколько раз.
Через пару дней мы стали разбивать наши большие чертежи А1 на маленькие А4 с множеством связей между ними. Получалось, что начерчено за день очень много, но разобраться в документации - что, откуда и куда - было сильно сложнее, чем когда у тебя большой чертеж А1 и сразу все перед глазами.
Наш портал — Software Engineering Productivity», — уточнили исследователи.
Их ещё не DDOSнули?
Я автор исследования, спасибо за добрые слова. Но такие комплименты лучше делать после того, как вы прочитали нашу работу.
Глючный код не должен попадать в продакшн. Если это происходит, значит, у вас проблемы с QA или другими частями CI/CD пайплайна. А если всё-таки попал, то, скорее всего, его придётся дорабатывать, что замедлит процесс, потому что придётся возвращаться и исправлять. Кроме того, мы также отслеживаем случаи, когда код "перерабатывается", и можем видеть, какое количество ваших коммитов – это новый код, а какое – переработка старого.
С уважением: проще всего бросаться словами, но гораздо лучше делать это, когда вы тщательно изучили работу автора.
Кстати, классные картинки.
Кстати, я вот читаю комментарии, и не совсем понимаю, что и вправду обсуждается. Сверху -- презентация с картинками, по ссылке у Вас написано "We've published a paper on this and have more on the way", но где можно почитать подробнее? Я нашёл только статью "Predicting expert evaluations in software code reviews", но она не сказать что "published", она на arXiv, а вот обсуждаемая методика и числа пока нигде не опубликованы -- есть пока только презентация?
Глючный код не должен попадать в продакшн
Ахаха, то есть мяу
а те кто нахреначил кучу глюкавого глючного торомозного говнокода - "молодцы!".
Именно так считают в множестве образцово-показательных тех-компаний лол. Как там у Google? Сделать новую фичу или продукт это хорошо, а чинить баги это для лохов. This is why we can't have nice things.
Но если уволить плохо работающих, то оставшиеся распределятся в точно такой же пропорции :-)
Даже анекдот был на эту тему, только с ходу найти не могу.
столько сотрудников уволили, а половина компании всё равно работает хуже медианного сотрудника!
Из аниме "Врата" : ""Вы знали? Если колония муравьев избавится от самого ленивого, вместо него начнет лениться другой?» — Ёдзи Итами"
На карандашной фабрике провели исследование и обнаружили, что огрызками меньше 3 сантиметров никто не пользуется. Убрали из последних 3 сантиметров карандаша графит – экономия графита! Получили премии за рацпредложение.
Через месяц решили, что раз графита нет, можно и дерево убрать. Укоротили карандашные дощечки на 3 сантиметра – экономия дерева! Премии, опять же, получили.
Еще через месяц вернулись к изначальному предложению убрать графит. Ну а чуть позже и деревянную часть укоротили. Каждый раз экономия и каждый раз премии.
Ну а когда длина карандаша стала равной трём сантиметрам, производство карандашей свернули – огрызками меньше 3 сантиметров никто не пользуется.
Программист легко может заменить менеджера. Менеджер программиста - никогда. Отсюда в любой непонятной ситуации проще менеджеров увольнять.
Помню у нас один такой был. Типа курировал команду. Когда тот ушел никто не заметил разницы в работе. Только проблем меньше стало. Зато когда разработчик ушел проект встал колом.
Программист легко может заменить менеджера. Менеджер программиста - никогда.
Смотря кто у них отвечает за стаффинг. ;)
Да ну фиг знает насчёт замены менеджера программистом. Вот взять этих из недавней темы про стрессы, которые камеру боятся на созвоне включить, какой менеджер из них? Вообщем далеко не любой заменит и далеко не любого, я вот например не захочу скорее менять.
Наоборот скорее нет, это так, если менеджер не бывший программист.
Программист легко может заменить менеджера.
Ахаха. Ну, разве что на таком уровне:
Попугай научился говорить "ну что там? " и был повышен до проджект-менеджера
Кроме шуток, во многих конторах, особенно средней руки, программист -- и менеджер, и аналитик, и тестировщик, и оформитель документации, и специалист 2-3 линии техподдержки, и даже немного HR. Разве что полы мыть не заставляют.
Интересное, зарплату он за троих получает? или фонарик на лоб выдали и крутись как хочешь? ;)
и чего в этом хорошего. Я тоже в таких местах работал. Но больше не хочу, и теперь уже в проекте без выделленного менеджера+аналитика+qa не работаю
Ничего хорошего в этом нет. Но, тем не менее, именно так зачастую происходит в реальной жизни. Поэтому тезис о том, что программист может заменить менеджера - не прикол, а суровая реальность жизни. Большинство программистов отлично представляют себе работу менеджера, а вот наоборот -- это так не работает.
По такой логике, программист и уборщицу легко заменить может, а она программиста - вряд ли. Да еще и работает уборщица пару часов в день всего, а то и не каждый день.
Ужасно не эффективно.
Программист легко может заменить менеджера
И получить плохого менеджера вместо хорошего программиста
А что, единственная возможная работа для программиста - коммитить в гит?
Тем более, что в оригинальной статье речь даже не о программистах, а о software engineer - ах, под которых можно много кого подвести
Большие, жирные коммиты нужно, судя по статье. LOC навалил, значит хорошо поработал!
Благо управленцы выдающие такие забавные факты не настолько компетентны чтобы оценивать работу специалистов и никогда не будут.
"отмазки" так называемых призраков в статье это типичные огрехи руководителя/технического лидера и менеджеров разного уровня, которые должны решаться.
Но эти проблемы делегируются на плечи разработчиков. Полагается, что разработчик и жнец и жрец и на дудке игрец, и сам договорится с кем нужно, и чатик создаст и всё уточнит, и за другую команду напишет код и сборку починит и рефакторинг в внерабочее время будет делать и будет писать код ночью потому что у него рабочий календарь забит встречами на 80% рабочего времени.
Такой человек конечно большой молодец, но быстро перегорит на короткой дистанции делая работу за трёх сотрудников и 12 из 24 рабочего графика.
Во-первых, в этих 9% корпоративные паразиты. Это люди с высокими софтскиллами, которые умеют красиво болтать, отлично натасканы на проход собесов, и так далее. Они могут многое знать и уметь, но работать они не хотят. Понеработал там, здесь, отдохнул от отдыха и повторил - жизнь удалась.
Во-вторых, на западе там квоты, кого взяли за черный цвет кожи, секс в задницу или прочие сомнительные достижения. У не-запада квоты заменяются на камнеголовых отпрысков высокого начальства и прочий блат.
В-третьих, среди 9% сотрудники, которые сидят в поддержке, консультациях и на устранении пожаров. От них может быть десяток коммитов в год, но без них в любом факапе все будут с криком АААА бегать по кругу, не зная, что делать. Без них вторая-третья линия поддержки потеряет 30% KPI в среднем. Без них сложные проблемы будут решаться дольше и дороже. Отчасти сам среди таких, и прекрасно вижу, что вроде бы показатели в циферках так себе, но отзывы со стороны живых людей только позитивные.
Софтскилы зло. Всегда это знал.
Надо брать самых токсичных работников, чтобы они им пришлось своё хамство оправдывать работой.
Правда, со временем, под них научиться ныкаться софтскильщики)
Ох блин, меня не так поняли. Суть не в софтскиллах, а суть в их применении для одурачивания публики. Это не манагерство, когда на фоне болтовни у продукта таки создается ценность, это именно умение заговаривать зубы, чтобы ничего не делать в самом прямом смысле.
Вот из последнего - пришел чел, сеньор, на удаленку, регион. Ему отправили ноутбук, передали с коммандированым сотрудником. Ноут мы лично проверили, всё ок было. Чел ждет три дня и возвращает его заявкой, "не работает", говорит, винда не загружается. Так дважды, причем, когда мы его назад получили %%ему дали другой, чтобы не ждать доставку туда-сюда%% - все ок было. Потом - "у меня нет доступа", проверяем - группы есть. Просим удаленное подключение для проверки, чел начинает парить мозги, что не может, типа кнопочка согласия не прожимается. И так красиво говорит, что сложно ему не поверить... Так он сношал всем мозги два месяца, наконец получил все доступы и всё заработало. Ему насыпали задач "на старт", чтобы с системой ознакомился. Еще месяц он "изучал", не написав ни одной строчки. Дальше, после тыкания веточкой, пошли коммиты... Угарали всем отделом: там хаотично по коду комментарии вставлены, от чатгпт, местами в литералах английские с заменены на русские - зачем? - местами отформатирован весьма странным образом код... Спрашиваем - ты чего творишь? "Аааа, вы такие гады, вы доминируете меня, у меня тонкая душевная организация..." - и понеслось. Жалобы всему начальству, причем красиво и грамотно. Находит личные телефоны руководителей, звонит туда... Суммарно 5 месяцев имел мозги до того, как его изгнали... Из интереса пробили его на прошлом его рабочем месте, где он пронеработал 9 месяцев - идентичная история, ничего не делал и только кляузничал.
Это не единичная история, за несколько лет чуть ли не десяток таких выгнали. И все как один соловьем поют, собесы проскакивают влёт, на встречах активны и проявляют инициативу (пустую, конечно же - я предложил, но делайте вы)... Только не работают.
Да что за дичь вы только что рассказали, разве такое бывает вообще? Похоже на придумку.
Бывает, не так явно, но бывает.
К сожалению, бывает. Аналитик-хлебушек так год просидел в команде.
Поверьте, это встречается гораздо чаще чем можно подумать. И я бы не связывал такое явление с каким-то конкретным поколением, встречал и возрастных с такими симптомами.
Нет, не дичь. Бюрократическая машина крупного бизнеса очень неповоротлива, только прием сотрудника порой занимает месяц-полтора, ибо дай оборудование (и курьер на мопеде не пойдет, либо передавать с кем-то своим, либо спецпочтой), дай доступы - а их надо согласовать, обучи работе в куче ИС (а тут зоопарк - сап, 1С, самопис, какие-то рудименты от ibm, ...), запусти тренинги ему по ИБ и охране труда, ... - короче жесть.
Это в крохотный стартап одним днем берут, крупняк так не умеет. Уволить одним днем можно тоже только за инциденты ИБ, уголовку или крупный косяк по охране труда типа пьянки. Так процесс увольнения занимает месяц-два, поскольку халявщик от заявления по собственному отбрыкивается, а на статью надо фактуру набрать... В результате можно где-то 3-4 месяца вообще халявить, а потом, когда запахнет жареным, свинтить по собственному. Если трахать мозги всем и быть спецом по ИБД, можно и год просидеть, а если начальник раздолбай, то паразит будет получать зарплату ооочень долго.
Состава мошенничества тут нет, никто же не признает, что он специально пришел жульничать. Все скажут "лень", "я это не знаю", "меня обижают", "я ошибся местом" - ну и всё, ничего не предъявишь.
У него на западе "за секс в задницу" программистов нанимают. Когда люди начинают такое рассказывать, сразу можно пролистывать, а рассказы делить на 16.
Я видел похожие истории как лично, так и у знакомых. В пике до полутора лет получалось у человека получать зарплату ни за что, при том что он умел красиво говорить, но не умел работать вообще.
Суммарно 5 месяцев имел мозги до того, как его изгнали...
Т.е. получил за 5 месяцев зарплаты плюс увольнительные. Плюс ещё с предыдущего места за 9 месяцев. Плюс сколько у него ещё там мест было. И будет.
Я поэтому продолжу форсить тезис: в айти неправильно завышены оклады. Завышенные оклады привлекают всю эту плесень. А должно быть так чтобы оклад не превышал например 50 тыр., а всё остальное - сдельщина и премии за конкретные оговоренные и реализованные части проекта (и неустойка за нереализованные). Либо что-то в этом духе. Проблема с проходимцами по 1000 на вакансию решится сама собой!
Я тоже за премии. Кнопку во фронте поправил - пусть миллион перечисляют.
Сдельно всегда в разы дороже...
Ну не миллион, а как договоритесь.
Сдельно всегда дороже потому что сдельщина гарантирует результат и сроки. Сдельщина не пугает настоящего специалиста. Кто взялся за сдельщину подписавшись за неустойку, того можно вообще без собесов неглядя брать.
Вот кто против сдельщины и за оклады - это как раз рукожопы-балбесы. Им выгодно чтобы им за 3 месяца перекрашивание кнопки миллион заплатили.
Я готов, яж написал.
Только вот бизнес предпочитает платить не сдельно. Потому как при нормальной организации это гораздо-гораздо дешевле.
Собственно, если компания занимающаяся разработкой платит сдельно, то даже непонятно зачем она нужна и в чем ее бизнес...
Сдельщина может быть только там где только кнопки и можно добавлять. А где нужно что то серьезное реализовать, что еще никто не делал ранее, какая тут сдельщина? Может нужно вообще сначала научно исследовательскую работу сделать и концепт написать, а по итогу это и не нужно окажется. Программист потратит на это пол года, а ему потом 50*6 и оплатят.
Бывают раздобалны, "знающие свои права" и в других профессиях, даже продавцы в пятерочке такие бывают. Которому проще зарплату за пару месяцев заплатить, чтобы он только, c#@$, на работу не приходил, до даты увольнения. Просто когда такая история в ИТ история звучит лучше.
Зло для кого? Для конкретного сотрудника который благодаря им вероятно больше отдыхает и меньше стрессует и скорее всего имеет более здоровую психику как результат, мне кажется, не зло.
Для его работодателя и коллег - зло.
Не выполнять задачи это одно и можно подвести под прямой ущерб (или зло) для работодателя, за это уволят. Но не стремиться брать на себя больше задач если все и так довольны тем как ты работаешь (даже если ты делаешь те самые 3 коммита в месяц из статьи) это уже сложно для меня подвести под зло в типичном бизнесе, где сотрудник просто получает зарплату, а не является совладельцем. Точно так же его коллеги не должны бы объективно (но могут субъективно например от зависти) от этого страдать при условии, что они так же получают зарплаты, а не совладельцы бизнеса.
Часто именно эти проценты "паразитов" с высоким уровнем софтскилла решают вопросы связанные с продажей того, что было сделано остальными членами команды. Иногда в каких то неформальных подходах. Задача любой коммерческой компании это прибыль. Код без его монетизации так себе затея...
Помню, в книжке "Peopleware" было:
I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project: she's not a great developer or tester or much of anything." With a little investigation, I turned up this intriguing fact: During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn't obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn't recognize the role of catalyst as essential to a project.
-TDM
Главное, чтобы они не "продавали" (продвигали, продавливали) сделанное, как собственную единоличную разработку.
А так, таки да, донести красиво прототип/проект/этап до начальства - это искусство, которое по идее должно быть у руководителя. Но бывает руководитель прекрасный администратор и психолог. Он круто организует работу, но "продать" не может, тогда часто подключает "продавца" из команды. Чистых продавцов я лично , не видел, но вот людей, которые меньше других в команде, но умели зацепить начальство проектом (и кстати тратили время на подготовку к этому, а не просто кайфовали в сторонке) повидал довольно много.
Речь не про душевных продажников говорунов, у них понятное дело, что работа сама по себе такая, речь про тех кто красиво рассказывает слова сначала рекрутёрам, потом HR, потом будущим коллегам, его нанимают, он должен вроде как код пилить и всё такое, а он физически не умеет это делать и не собирался. Такие вот мошенники с подвешеным языком.
Допустим вы увоолите 9%. Медиана сдвинется - и опять будет какой-то процент людей, делающих 0.1x от медианного количества коммитов.
Свой вариант ответа "хочу/стремлюсь стать таким!" )))
Вы о них?
Исследование (или его пересказ) вызывает разные вопросы, некоторые уже перечислили. От меня такой: а как это сравнить с другими сферами деятельности? Это только в ИТ каждый десятый мало чем полезен? Если нет, то в ИТ больше или меньше таких чем в среднем по планете? Или примерно как и везде?
Помнится адмиралтейство установило, что в среднем количество народу растет на 10% в год, если количество работы не меняется...
В год Карл !
Ахаха. Смотрел видео, как индийские железнодорожники сваривают рельс термитом. Их там реально 10 человек ;) 1 с умным видом выравнивает стыки - остальные стоят, как эти на картинке. Закончил - за работу принимается следующий.. Досмотрел до момента, когда они наконец подожгли свою поджигу, но до конца ниасилил :)
Это высококвалифицированные узкие специалисты. С их менталитетом по другому нельзя. Индийцы любят в приписки и если ему дать две функции, он одну в лучшем случае кое-как исполнит, а про вторую скажет, что сделал, аж всю ночь работал, но принципиально забьёт. А при четкой узкой ответственности, его "сдадут" другие участники процесса.
В августе разработчик рассказал, что он заработал $500 тыс. в Amazon, не выполнив за полтора года ни одной задачи.
@denis-19, ок, в той статье вы ошиблись заголовке и хотя-бы в тексте написали, что он не разработчик, а менеджер, цитата из той статьи:
у него позиция старшего Technical Product Manager
Но здесь-то зачем опять писать разработчик? Выглядит уже как целенаправленное вранье, извините.
Исправил.
Но здесь-то зачем опять писать разработчик? Выглядит уже как целенаправленное вранье, извините
А за что вы извиняетесь? Человек действительно целенаправленно лжет. Всей статьей, кстати, тоже. Когда переваливает с менеджеров на разработчиков.
Ага, весь смысл меняется. Для менеджера это считай нормально отработал. Не отлично, но нормально
Как-то я работал на онсайте в Сингапуре на одну большую страховую фирму.
Так из 20ти инженеров работало всего 4. Остальные просто сидели в офисе 8 часов. Благо индусы способны месяцами дисциплинировано сидеть в офисе и ничего не делать.
Что эти исследователи вообще знают про особенности кровавоэнтерпрайзного найма?!
Исследование о том, что всех нужно загнать в офисы.
А сколько в руководстве таких! ))) И как их вычислить? А кто руководители этих 9%?
Странная метрика, я бы тоже вышел по ней инженером-призраком. Так как в последнее время мои задачи почти не включают написание кода.
Видимо по мнению этих горе-исследователей, программисты занимаются только написание кода.
Я тоже иногда могу месяц ничего не коммитить в git, перебирая локально какой из способов решения задачи более оптимален к ситуации. И выкатить в конце концов всего строчек 100 кода или конфигов. Понимаю что это не очень правильно -- лучше всё же идти инкрементально и документировать все действия, но не всегда так получается. Но это не значит что я рабочие часы пинал балду, наоборот иногда загоняюсь и истощаюсь, предвосхищая вопросы менеджеров о пустом гите.
Ну Маск не просто так уволил половину сотрудников твиттера.)
Ошибка есть в логической цепочке размышлений. Эти 9.5% это постоянная величина. Хоть обувольняйтесь. Это неизбежное зло больших компаний, где можно затеряться за спинами коллег.
Секунду, то есть руководитель этих призраков не в состоянии был понять этого? Может, тогда лучше уволить руководителя?
может и в состоянии, но непосредственному менеджеру лично с этого ни горячо ни холодно. Если весь проект в плюсе, зачем ему суетится.
Я конечно никогда не был менеджером, но разве у них нет каких-то бонусов/комиссий за срезание костов?
Там много нюансов. Например, если у тебя в отделе обнаружился такой призрак, и ты его за это уволил, то у кого-то обязательно возникнет вопрос: а как он вообще туда попал. Начнутся разбирательства кто его нанял, почему его не выявили раньше… подключится офисная политика… и крайним в результате вполне может оказаться тот "оптимизатор", который его выявил и уволил. И вместо бонусов есть ненулевой шанс получить прямо противоположное. Дальше возникнет вопрос "если ваш отдел прекрасно справлялся с нагрузкой при наличии призрака, значит вы были недогружены"… Все эти проблемы решаемые, конечно, но одно из решений это просто не начинать вот это вот всё.
Может, тогда лучше уволить руководителя?
Ты_такие_вещи_не_говори_брат.jpg
На протяжении последних 8 лет мне регулярно выпадали позиции, на которых я писал строчек по 10 кода в месяц. И речь не про менеджерство. Это были самые сложные и истощающие технические и аналитические задачи. Приятно видеть, что за них с лёгкой руки ТС можно получить увольнение
Мне вспомнилась "Повесть о том как один мужик двух генералов прокормил" Михаила Евграфовича Салтыкова-Щедрина.
ограничивает прогресс человечества.
Это должно прекратиться. Помогите нам остановить это безумие
конечно замечательно, что исследователи смогли посчитать строки кода, но что-то мне подсказывает, что проводя своё исследование они не сделали ни одного коммита, вероятно их стоит уволить...
Легко найти какой то очевидный критерий (строки кода) и говорить -ну программисты не работают, а на самом деле в любой другой сфере куда больше ничего не делающих людей. Или даже работающих в минус. Менеджмент, продажники, громадное количество вообще ничего не делающих должностей, найм ради поддержания занятости, лишь бы не протестовали в ущерб производительности труда и тд
"Человек делает мало коммитов, значит, он ничего не делает". Это - сильно.
Сразу вспоминается история из "Совершенного кода":
Несколько лет назад я работал над проектом Минобороны, и как-то на этапе выработки требований нас посетил куратор проекта — генерал. Мы сказали ему, что работаем над требованиями: большей частью общаемся с клиентами, определяем их потребности и разрабатываем проект приложения. Он, однако, настаивал на том, чтобы увидеть код. Мы сказали, что у нас нет кода, и тогда он отправился в рабочий отдел, намереваясь хоть кого-нибудь из 100 человек поймать за программированием. Огорченный тем, что почти все из них находились не за своими компьютерами, этот крупный человек наконец указал на инженера рядом со мной и проревел: «А он что делает? Он ведь пишет код!» Вообще-то этот инженер работал над утилитой форматирования документов, но генерал хотел увидеть код, нашел что-то похожее на него и хотел, чтобы хоть кто-то писал код, так что мы сказали ему, что он прав: это код.
А мне сразу вспомнилась одна из первых глав Чистой архитектуры, где сравниваются графики изменения количества строк кода при развитии продукта (с увеличением версии рост количества строк замедляется) и количества программистов (постоянно растет). И Мартин делает вывод "Любой менеджер, взглянув на эти два графика, придет ко выводу, что необходимо что-то предпринять, чтобы предотвратить крах"
Я недавно стал таким «призраком».
Точнее, 7 лет я усердно пилил свой инструмент (см. мои статьи, я его там подробно описываю), и в результате допилил до такого состояния, что он покрывает все потребности бизнеса. У меня больше нету задач, сижу теперь смотрю аниме в рабочее время... Работодатели в курсе, и их это почему-то устраивает. Обещали поискать мне работу по линии аутстаффа, конечно, но чё-то ничего не находится.
Скучно, жуть как скучно. Но фиг щас что приличного найдёшь, если уволиться :/
Вот сколько каждая компания могла бы сэкономить ежегодно, уволив их.
Нельзя. Некоторый запас нужен на случай ухода сотрудников. Или например сотрудники иногда уходят в отпуск. Поэтому да, крупные компании могут себе позволить иметь некотрый запас рабочих.
а они что, все сразу в отпуск уходят, все 100%, как в Китае?
я думал, что это статистический процесс, 9 человек в отпуск ушло - 10 из отпуска вышло и вошло в работу. И чем крупнее фирма, тем меньше "всплесков".
Вообще сразу. Ну т.е. за 2-3 летних месяца почти все. И в рф и в европе часто так, французы в некоторых компаниях обязывают ежегодно, скажем в августе брать 2-3 недели отпуска всех, ибо иначе работать затруднительно, с мая по октябрь можно совершенно не продвинутся, то одних нет на месте, то других
Но балласт этой проблемы не решает
то одних нет на месте, то других
охрененный же тогда bus factor у "крупной фирмы"
не, я понимаю для малого бизнеса, там в самом деле, каждый тащит там, где у него лучше получается, и полноценное дублирование компетенций конторе не по средствам, там в самом деле - пока Вася из отпуска не вышел, его задачи полноценно двигать не получится. Но речь-то шла в исследовании вроде о гигантах.
уборщица Маша уехала на дачу, а без неё никто толком не умеет мыть лифт на третьем этаже? как-то несерьёзно
А если покопать вне IT, там и не такое найдётся. Я, например, после универа работал на одном предприятии и два раза ловил себя на том, что уже целый месяц абсолютно ничего не делал по работе. И это не потому что я был плохой работник, а потому что ничего и не надо было делать. Потом мне конечно придумали загрузку, но такие как я появлялись каждый год по несколько человек в каждом отделе.
Ну Егорка дает... теперь у Стэнфорда такой уровень исследований?
9.51%
Cмущает меня пара моментов
А если добавить к коммитам активность по переписке в слаке? В команде кто-то может общаться и выяснять детали того, как должна выглядеть картина в целом, а не тупо нарезать задачи, которые потом придется переделать. Хотя с точки зрения коммитов тот кто сделал и переделал - лучше чем тот кто выяснил и сделал один раз
Если уволить эти 10%, медиана сдвинется и опять будет какой-то процент, делающих 0.1x от медианы. Да и вообще - как кадры не оптимизируй, а половина будет работать хуже медианного сотрудника.
Показательно, что те кто призваны определить полезность программиста, недостаточно компетентны для этого и выбирают странные показатели эффективности, вполне соответствующие их компетентности. :)
Как известно, лучший код — это ненаписанный код
Мне кажется люди стали забывать правило 20/80. Всего 10% ничего не делают это слишком идеальная картина мира. Другие просто эффективнее маскируются или ещё хуже, только портят продукт своими коммитам
Подходил к концу 2024 год...
Исследователи оценивают производительность по коммитам и строкам кода.
В 2025-м видимо поувольняют девопсов, у которых коммиты были в закрытые репозитории, непопавшие в статистику. Или старожилов, которые единственные могли поправить баги говнокоде, нагенеренном 5х сотрудниками.
не веришь что можно реально сидеть и ничего не делать?
я бы честно говоря больше присматривался к 5х сотрудникам.
Бывают такие, которые нагенерируют 10 тысяч строк, из них допустим 60% правильные, остальные 4 тысячи строк либо с багами, либо нужно будет переделывать в будущем. Т.е. они нагенерировали работы в будущем больше, чем решили этими строками
В этом-то и проблема. Пишут, работает, даже ревью проходят по принципу "у меня нет возражений". Начинаешь читать - понимаешь, что на поддержке этого поделия с высокой сложностью (accidential complexity) потеряется x10 в будущем. А кабанычам нормально до поры до времени. Они литкод на собесах спрашивают вместо методов борьбы со сложностью кода.
Исследователи оценивают производительность по коммитам и строкам кода.
Потому что их цель навешать лапши менеджерам-гумманитариям, которые в этом не разбираются, и продать свои "ценные" услуги этим лохам.
Кстати да, "Смотрите какой я молодец, 10 коммитов в день! Повысьте меня, а то я уже задрачиваю учебники под собеседование в соседнюю контору.
А этот сеньор всего один коммит в день несколько строк, в каком то говне старом ковыряется баги вылавливает. Может вообще уволим его?".
Один коммит в день и меньше трёх коммитов в месяц это совсем не одно и тоже.
И я даже допускаю что и для трёх коммитов в месяц вполне себе может быть легитимное обоснование. Но это как минимум не стандартная ситуация для среднего разработчика.
Всего 10%? По ощущениям, это совсем мало. Было бы круто провести такое исследование в других областях. Вангую, что в строительном секторе оно приблизится к 90%.
Разработчики ладно. Что насчёт менеджеров?
10% это я так понимаю, которые даже комп не включают.
Ещё процентов 80 бурно имитируют деятельность абсолютно бесполезную.
"...По оценке IT-эксперта под ником Deedy..."
А вы нам не P. Deedy? 😁
Всем привет! Я автор этого исследования -- Егор Денисов-Бланч (Yegor Denisov-Blanch). Наполовину русский. Буду рад пообщаться подробнее, если кто-то хочет взять интервью для своих подписчиков. Пишите в личку!
на вторую половину котик ? и зачем вообще эта информация нужна.
Спасибо, вы меня рассмешили. Мне нравится, насколько дружелюбным всегда оказывается русскоязычное сообщество!
Я отвечаю на комментарии, потому что никогда раньше не имел возможности обсудить это с русскоязычным сообществом, и для меня это что-то новое. Мне интересно, есть ли кто-то с совершенно иным образом мышления, чем тот, к которому я привык в Кремниевой долине. Такие комментарии, хоть и забавные, не производят сильного впечатления.
Дело в том, что тут по большей части всем наплевать на то, что за солянка намешана в генах и какие культурные штампы в голове. По этому и неписали, что не понятно зачем это было указывать.
Ну право же, если бы предыдущий комментатор не был бы токсичным, он бы догадался, что эта ремарка - для того, чтобы догадаться, что автору можно писать на русском, у него другой культурный контекст и может быть сложно понимать наш контекст / выражать мысли на русском, который не практикует. Ну и остальным нормальным людям, может быть и не "наплевать", хотя "гены и культурные штампы" - да, не имеют значения.
вторая половина - гены-призраки
Я думаю автор имел ввиду что он знает русский и поэтому может отвечать на русском. Ну чего ж вы так?
Привет, Егор! Классно, что вы пришли сюда в коменты. Интересная работа и исследование. Вопросы у меня следующие.
1) За какой период времени анализировались данные? Какие-то данные я увидел только на картинке Company B - USA - Web Team, период 2019.1 – 2022.4 не выглядит достаточным и репрезентативным. Для того, чтобы сравнивать производительность в офисе/гибриде/удаленке период ковида и адаптации к удаленной работе не подходит, т.к. очевидно, что из-за стресса, локдауна и необходимости менять свои привычки, производительность пострадала. Более того, моя гипотеза, чтобы корректно сравнивать офис и удаленку, нужно брать один исторически период, т.к. внешние условия очень сильно могут влиять. Например, можно было бы трактовать снижение производительности после начала ковида как негативное влияние общемирового стресса и неопределенности. Метрики за 2023 и 2024 - последствия экономического кризиса и увольнений.
2) Пробовали ли вы отслеживать, как меняются метрики Ghost Engineers в течении длительного времени? Моя гипотеза, что часть людей по каким-то внутренним или внешним причинам имела плохую производительность, типа депрессия, выгорания, неинтересный проект, конфликт в команде или с менеджментом и т.п., и со временем эти люди восстанавливаются.
3) Аналогично, какая динамика на длительном промежутке времени (разброс вашей метрики) для среднего/хорошего/крутого инженера?
4) Какой разброс метрик внутри каждой качественной группы (Ghost/плохой/средний/хороший/крутой)?
5) Есть ли какая-то корреляция между параметрами метрик (например, резкими изменениями) и самостоятельным увольнением человека?
6) Есть ли какая-то корреляция между параметрами метрик (например, резкими изменениями) при изменении должности человека?
7) Пробовали ли вы делать опросы Ghost Engineers и их коллег, чтобы как-то еще валидировать свою гипотезу о них?
8) Вообще, в принципе, вы как-то еще валидировали вашу модель и ваши гипотезы, кроме анализа комитов и их экспертной оценки?
9) Как чистили и матчили данные? Типа у одного человека может быть несколько идентификаторов в репозитории.
10) Пробовали ли вы оценить, есть ли bias у вашей модели?
11) Есть ли у вас более техническое описание, что за модель? Как обучали, как валидировали, какая архитектура, loss function, метрики и т.п.
Вообще, классная задачи, сделать некий сервис, который будет оценивать параметры инженера, используя разные его активности. Но уж очень много всего нужно отдавать в такой сервис.
PS К слову говоря, после начала войны, большая часть аудитории иммигрировала на другие ресурсы, и ее качество изменилось.
PPS Я Computer Vision Engineer / ML Engineer, на Хабре я могу только раз в сутки отвечать, если интересно, пишите в Линкедин (https://www.linkedin.com/in/ilirium/).
с вашим ником я долго не мог сообразить, что с ним не так) извините
это значит что люди уже достаточно поработали на контору и теперь могут и полениться 🤷♂️
Ну в статье совсем дикие показатели. 3 коммита в месяц... Коммиты с исправлением нескольких символов... Это действительно паразиты, тут сложно спорить.
Однако замечу, что оценка продуктивности она вообще очень специфичная штука. Заметил, что вклад организации процессов в продуктивность огромный.
Если у вас в команде заметный процент прокрастинаторов - с большой вероятностью часть из них не паразиты, и ленивые сотрудники, а просто попали под каток ваших процессов.
совершенно не так. На практике знаю задачи, где был и один коммит в месяц, просто перед ним было несколько недель тестов, прогонов на тестовых серверах, включении небольшого изменения на боевых серверах с коммитами от других людей но под наблюдением разработчика и с долгим анализом логов и различных метрик. Так что измерять проиводительность количеством коммитов - бред для больших компаний, где малейшее изменение затрагивает петабайты пользовательских данных. Для мелочи всякой или каких нить корпоративных систем, где че хочешь делай, можно всегда поправить - это, возможно, работает, но точно не в гугле
По моему опыту 75% руководителей в крупных компаниях не только ничего не делают, а еще и вредят. Решаю сложную алгоритмическую задачу, а они мне:-срочно посчитай сколько коммитов в среднем в месяц делает каждый разработчик!!!
А автор исследования похож на тех кто делает вид что работает. Я прочитал текст и не пойму в каком месте это исследование? Нет никаких деталей про то как реально устроено время разработчика в зависимости от модели работы в компании.. Ну там кто то по водопаду, кто то то эджайлу. Он посмотрел на все только по колву изменений кода. Кроме прочего он сразу преподносит информацию в негативном свете, как будто доказал свою правоту. Но это исследование не исследование, а фигня.
Раньше считали по количеству строк кода , теперь по коммитам)) Ну ок.
Я автор этого исследования. Мы пропускаем код из каждого коммита через модель, которая оценивает его с точки зрения влияния на кодовую базу. Результаты этой модели имеют высокую корреляцию с оценками независимой группы экспертов, анализирующих код, что является наиболее точным приближением к измерению продуктивности в области программной инженерии.
А это вообще как "с точки зрения влияния на кодовую базу" ? Коммит с одной измененной строчкой менее важен чем с 10 ? Хотя оба фиксят баг и решают проблему клиента ?
//Я написал всё это на английском и перевёл через ChatGPT, так что надеюсь, получилось понятно. Я не привык говорить о таких вещах на русском!//
Под "влиянием" я не имею в виду влияние на бизнес. Мне нравится разделять два понятия: выход и результаты.
Представьте, что результаты зависят от списка приоритетных функций, составленного продуктовой командой, или от решений инженера, принимающего продуктовые решения. Выход, с другой стороны, – это осязаемая работа, которую выполняет инженер, независимо от её ценности для бизнеса.
Если инженер выдаёт много качественного результата, но его влияние на бизнес невелико – это не проблема инженера.
Как видно из этой матрицы, у вас может быть высокоэффективная инженерная команда, работающая над продуктом, который не приносит дохода. Такое часто бывает. Также можно встретить малоэффективную инженерную команду, работающую над продуктом, который, несмотря на их низкую производительность, приносит огромные деньги.
В своём исследовании мы концентрируемся именно на выходе. Это не про подсчёт строк кода. Мы рассматриваем более 40 измерений, включая когезию, сложность, связность, классы, методы, уровни хранения данных, API-интерфейсы, архитектурные паттерны и многое другое. Объяснить, как всё это работает, непросто. (Не говоря уже о том, что как человечество мы до сих пор не до конца понимаем, что происходит "под капотом" моделей машинного обучения).
Объяснить, как всё это работает, непросто
Уж будьте любезны, если пытаетесь это на технической площадке продавать)
А вы пробовали убрать эти найденные вами 9% и посомтреть, что же будет с бизнесом, будет ли для него выход в +?
Пока выглядит так, что мы тут прикинули если убрать людей по нашим метрикам то вы зарботаете 100500 бабла, но никто не проверял, что же на самом деле будет?
Я автор этого исследования
У вас @ydebl :
те, кто искал не один день трудноуловимую ошибку и нашёл её исправив пару символов - "бездельники заслуживающие увольнения"
а те кто нахреначил тонны глюкавого глючного тормозного говнокода заплатка поверх заплаток на заплатки - "молодцы!".
Помню как то сделал коммит для фикса бага, небольшой в пару строк.
Через пару недель возвращаются тестеры, фикс не работает, захожу в код а фикса нет!
Смотрю историю, а этот код вытерт с комментом WTF как раз очень крутым экспертом которого наняла компания за здоровенные деньги повысить качество нашего кода )))
Когда появляются KPI — вся разработка уходит в эти KPI.
Продуктом занимаются по остаточному принципу
Очередная попытка эффективного менеджера доказать свою необходимость фирме.
А как с этим бороться? как понять, что вот такие призраки есть в команде?
С чем бороться? У авторов:
те, кто искал трудноуловимую ошибку и нашёл её исправив пару символов - "бездельники заслуживающие увольнения"
а те кто нахреначил кучу глюкавого глючного торомозного говнокода - "молодцы!"..
По моему опыту, такие примеры звучат убедительно в риторике, но часто не подкреплены доказательствами. Мы годами анализировали эти вещи. Случаи, когда инженер тратит "недели на исправление критической ошибки", действительно бывают, но основная часть работы инженера обычно не про это. А если в команде есть инженер, который занимается "поиском сложных багов, которые никто больше не может найти", об этом, как правило, все знают.
это называется "запас прочности". У любой компании можно уволить 10% сотрудников и ничего не изменится в худшую сторону, но запас прочности по любому необходим на разные жизненные случаи
Возможно. Более элегантное экономическое объяснение этого можно найти в исследовательской статье "Рынок лимонов".
"Рынок лимонов" -- это экономическая концепция, описанная Джорджем Акерлофом. Она иллюстрирует ситуацию, когда продавцы и покупатели имеют неравный доступ к информации о качестве товара. Продавцы знают больше о товаре (например, об автомобиле), чем покупатели. Это приводит к снижению доверия на рынке и тому, что на рынке остаются преимущественно товары низкого качества ("лимоны"), так как высококачественные товары теряют спрос.
О причинах сего постыдного явления. А она в разбалансированности иерархии работников.
Пример: есть директор и есть разраб. Директор каждый "час" ходит и "пинает" разраба. Разраб выдает 100% продуктивность. Под "пинанием" понимается постановка задачи, контроль сроков и выполнения, приемка решения. Под "часом" понимается оговоренное время контроля.
Дальше, бизнес расширяется, теперь у нас не 1 разраб, а 10. И вот, внимания и времени директора уже не хватает на всех. Половина работает на 50%, другая на 25%, а парочка вообще обделена вниманием (то есть все задачи в различных блоках). Один не долюбленный увольняется (ему скучно сидеть), а второй сидит ровно потому как "сотрудник спит, а зп капает".
Решение: организовавать иерархию, что бы каждый был на виду. Но это нужно знать и уметь и еще людей подходящих подбирать.
Сейчас тут набигут адепты бирюзовых плоских компаний, которых я всех сразу посылаю в "нетфликс" (или кто там главный идол).
А вот решение уволить всех непродуктивных очень близорукое. Как раз возможно нужно наоборот нанять всяких менеджеров, чтобы сбалансировать иерархию. Опять же, сбалансировать на 100% производительность тоже плохо. Любой факап и все порушится.
Но, по всей видимости, это выходит за рамки исследования.
Это история про "стукнуть молоточком 1 раз в нужном месте". И стучат 1 раз часто не только "инженеры-призраки". Уволить кого-то за непродуктивность - это тоже стукнуть молоточком один раз.
В краткосрочной перспективе это экономия - в долгосрочной - не известно. Сколько коммитов должен сделать, например, архитектор или аналитик? А системный инженер?
А если этот системный инженер не понимает, как пользоваться гитом? Давайте срочно его уволим вместе с мат. моделью, которую он сохранял в папочках model-2024.10.16, model-2024.10.18 и т.д. а потом будем удивляться, что ничего у нас не работает и мы не знаем почему и вообще компании нет без этой модели.
Конечно, всех можно всему научить. И перевоспитать. И платить поменьше. И вообще сказать, пусть они свои личные проблемы решают как-нибудь сами.
Проблема в том, что сейчас время сверхглубокой специализации. И, да, в пределе специалист становится настолько узким, что он становится подобным не флюсу, а носу Буратино, который и не укоротить и не расширить. Когда это становится эпидемией, надо менять способы работы. Менеджер должен начинать понимать, кто что делает. А корреляция в 85% не будет хорошим оправданием, когда увольнение ключевого специалиста по указанию алгоритма приведёт к краху компании в конечном итоге.
Чрезвычайно интересное исследование. Очень информативно. /s Мне очень нравится, как обтекают проблемы «эффективного менеджмента» ресурсов, когда нагрузка может откровенно из рук вон плохо распределяться в отделе. Как игнорируется работа с багфиксами, сложными для отлавливания, где проблема не особо решается большим объемом кода, но ни разу легче не становится. То, что работа разработчика клином не сходится на написании кода (и его объем может слабо коррелировать с качеством решения поставленной задачи). Но да, очень удобно для эффективных менеджеров, сказать что человек не работает и его стоит уволить. Браво.
Вообще не согласен. Когда у тебя инфраструктура из дестяков проектов, внесение изменений в одну строчку требует запуска кучи тестов, прочтения логов, согласования с админами, обсуждения как лучше сделать. Даже простое обновление систем, которое делается девопсами, а наблюдается разработчиками может быть огромным процессом без единого коммита от разработчика. Поэтому предложенная методика оценки эффективности наверное работает в какой то компании по заказной разработке, где надо тупо выдавать кучу кода разным заказчикам, но никак не в условном Google или Yandex.
Статья - хороший ответ на стоны разработчиков «Ну почему работодатель стремится загнать нас в офис?!».
Хотя причинно-следственная связь не установлена, возможно не удаленка - причина превращения в «призрака», а сотрудники-«призраки» больше остальных стремятся к удаленной работе.
Еще не освещена область research, когда разрабочик пытается что-то запрогать, но в продуктовые репозитарии не идет ни одного коммита, а он просто экспериментирует. Это может длиться месяцами, например применение какого нибудь нового фильтра, результатом работы которого является пара строчек в коде, но выкатка затрагивает тысячи серверов и может сэкономить компании сотни тысяч долларов на сервера, т.к. облегчит нагрузку на 5-6%. Только чтобы такое применить, надо провести десятки тестов и проанализировать результаты. Это в больших компаниях совершенно нормальная практика.
>Это безумие, что ~9,5% инженеров-программистов почти ничего не делают, получая зарплату. Это несправедливо обременяет команды, тратит ресурсы компании, блокирует рабочие места для других и ограничивает прогресс человечества.
Забыли про энтропию вселенной упомянуть.
Как много драмы.
Оценивать работу по количеству коммитов это то же самое, что платить за количество строк кода.
Иногда исправления сложных багов выглядят очень тривиально, когда ты смотришь коммит. А на деле месяц ушел, чтобы найти эту злополучную строку кода. Особенно если это какая-нибудь кодовая база телеграмма например.
Не забываем что еще есть процент блатных. Их никто не уволит
Могут ли авторы исследования пояснить как учитывался вклад Team Lead программистов? или они были исключены из выборки? если да, по каким критериям?
С тех пор как моя команда стала больше, я пишу мало кода, а больше занимаюсь проработкой архитектурных задач.
Я - призрак и бездельник?
А как оценить затраты на Code Review? обучение молодых? митосы по 20ч в неделю? single-исправление, но занявшее несколько часов?
В двух словах:
"Зачем делать в офисе три туалета, когда в данный момент ни в одном из них никого нет? Неэффективно!"
А сотрудники Стэнфордского университета уже проводили исследование, как много их сотрудников проводят бесполезные и однобокие исследования?
Для достоверных выводов для оптимизации бизнеса исследование слишком поверхностное. Нужно глубже разбираться с причинами такой неактивности. Потому что метрик "количество коммитов" и подобных абсолютно не достаточно для таких кликбейтных выводов как "10% сотрудников ничего не делает".
Вспоминаются коллеги, которые занимая должность разработчика занимались смежными активностями. Кто то лидировал разработку, почти не писал код, но активно консультировал коллег из многих команд, ревьювил код и так далее. Или выполнял функции проектного менеджера, занимался планированием, постановками задач, встречался с заказчиками и так далее. Встречал разработчиков выполняющих функции девопсов. Самому приходилось выполнять обязанности аналитика, проектировать систему писать документацию и инструкции - несколько месяцев от меня не было ни одного коммита в код.
Возьмите меня ничего не делать , за недорого удаленно .Кто-нибудь.
Интересно мнение @ydeblо достоверности следующей гипотезы: что подобное поведение вполне себе ок для огромного количества профессиональных корпоративных менеджеров, и, по сути, вполне себе взаимовыгодная ситуация и для программиста, и для менеджмента. Из того, что я понял из общения с сотрудниками транснациональных корпораций, там есть несколько неочевидных принципов работы:
1) Предельно важно попадать в бюджет. Наказывают за промах более 5% в обе стороны. Условно, если заложили на аутсорс миллион в год, а сейчас 15е декабря, и потрачено $800К, то, скажем, просто договориться с аутсорсером, и, даже без откатов, слить $200К на несуществующую работу, как дополнительное тестирование, или исследование безопасности решения, очень выгодно.
2) Layoff на, например, 10% ФОТ может прилететь сверху в любой момент, и людям наверху будет вообще не интересно слушать о том, что все люди, реально, заняты, и без них планы не выполнить. Поэтому, иметь жирок в виде лишних людей выгодно. Сокращения не становятся подножкой и не сбивают темп
3) Серьезный менеджер руководит большим хедкаунтом. Человек, у которого 30 подчиненных, не будет зарабатывать так, как тот, у которого в подчинении 3000. Даже, если, за счет грамотной автоматизации и продакт менеджмента, делает х3 результата.
4) Серьезный проект не может стоить дешево. Если предложить какой-то микропроектик, закрывающий проблему, ресурсами на 2.5 разраба вместо серьезного и масштабного проекта, просто не поймут, и будут относится к проекту, как к чему-то несущественному
Соответственно, как будто бы, симбиоз такого теневого инженера с профессиональным карьеристом начальником может быть очень взаимовыгодным. Из плюсов еще и то, что, чем меньше напишет кода, тем меньшим будет потом якорь мейнтененса и багфикса, соотсветсвенно, работа отдела будет более прогнозируемой в будущем...
О, да, 10% тунеядцев! Неужели никто не догадался просто их уволить?
Проблема в том, что когда начинается охота на ведьм, то увольняют другие 10% - социофобов, которые не умеют правильно отписаться о проделанной работе. При этом как правило они-то как раз работают нормально, но получают такой плевок в душу.
Более того, когда менеджеры озадачиваются выявлением тунеядцев, вместо того чтобы разобраться в их работе, вводят разнообразные формальные KPI, которые легко подделываются людьми с хорошо подвешенным языком. Или performance review, которые также легко обходятся.
В общем, неоднократно убеждался - главное не умение работать, а умение красиво отчитаться о проделанной работе. Правило действует везде, где более 1 начальника в цепочке управления. Чем больше начальников - тем больше надо отчитываться (и меньше можно работать). В крупной госконторе доходило до маразма - на заполнение отчетности тратилась большая часть рабочего дня!
Так что описанный процесс - естественное явление.
А автор статьи, как я понял, пытается продать продукт для борьбы с этим явлением. Заранее обреченный на провал - низкая частота коммитов ничего не значит. Коммиты с одним добаленным/убранным пробелом тоже. В моей практике были долгие исследовательские задачи по выявлению каких-то плавающих багов, которые часто заканчивались единственным коммитом в месяц, как правило - на несколько строчек. Самый эпичный коммит - удаление одного символа! (Из-за опечатки в имени объекта не работало оповещение в D-Bus, и чтобы найти причину убил неделю не понимая почему не едут лыжи, и всё из-за поганого лишнего символа, ListIngibitions вместо ListIngibition)
Формально это подходит под тунеядство, поэтому, в полном соответствии с правилом "главное не работать, а красиво отчитаться", компенсировал это многословным описанием процесса поисков, прокатило. Но блинский блин, с тем же успехом я мог и решить задачу моментально, а потом неделю пинать вола и расписывать детективные истории о своих напряженных поисках!
Ни один автоматизированный софт и ни один формализованный KPI не сможет такое правильно выявлять. Dixi.
Учёные из Стэнфорда создали модель, которая количественно оценивает работоспособность разработчиков, анализируя исходный код из закрытых репозиториев Git, имитируя группу из 10 экспертов, оценивающих каждый коммит по нескольким параметрам.
Дальше можно не читать, видимо. Они в курсе, что не все разработчики (особенно старшие) в принципе пишут код? Есть и другие обязанности, и бывает, что они поглощают 100% времени. Это не означает, что сотрудник не приносит пользы компании. Возможно, их следы можно найти в Miro/Confluence/JIRA или ещё где. Или они обучают других сотрудников, например (вовсе не становясь при этом менеджерами, остаются разработчиками).
Увольняйте таких, удачи вам потом разгребать.
Очень спорная метрика.
Статистика, конечно, штука хорошая, но есть нюансы. По статистике большинство людей правши, а значит можно смело отрезать всем левую руку. Это я утрирую, разумеется.
Говоря ближе к теме, какое-то время назад я тоже был разрабом и уволился, кстати, по той причине, что был неэффективным. Я довольно сильно не любил "тапать кнопку" тайм трекера и всегда считал это чем-то пошлым, но с трепетом относился к клиентам. Мне нравилось создавать элегантные системы, но рыночек заставляет играть по другим правилам. Понимаете по каким.
Вот вам пища для размышлений - а может те, кто делает "мало комитетов" не всегда бездарь? А может на тех, кто пытается делать качественно, эта сфера всё ещё не скатилась в говно?
К слову, я целиком сменил сферу и очень это рад
Спасибо за кликбэйтный заголовок, эту статью обсуждают на форуме анимешников в разрезе "ага, люди получают чемоданы деняк и ничего не делают", статью "Программистов можно увольнять. Каждый десятый разработчик в ИТ-гигантах почти не работает и только получает зарплату" обсуждают HRы.
Если дойдут до статистики по коммитам - видимо, первым порежут премии CEO-оптимизаторам, DevOps и аналитикам, заодно тимлмдам сделают мозг, если не дойдут - просто устроят охоту на 10% ведьм.
PS причём, обсуждается не вся статья, а заголовок, в формате новостного агентства ОБС (одна бабка сказала):
слышали, что 10% программистов ничего не делает?
Это только нашли 10%, а сколько пропустили?
Коробка Пандоры открыта.
Я хз чего люди так спорить начали. Сколько "волков" тех же ходит, что учатся чисто собесы проходить в крупные компании, (желательно сразу в несколько), а потом сидеть пол года/год/полтора, на каждую работать пару часов в неделю. Они даже не скрываются, в телеге и твиттере хвастаются с гордостью насколько хорошо у них обманывать выходит. И даже на хабре бывает пишут.
Или мнение распространенное довольно что в фаанги идут либо на старте карьеры, либо на пенсию, ничего не делать (ибо отследить сложно) а деньги хорошие. Тоже не думаю что на пустом месте взялось. В небольших компаниях то где разработчиков сотня-две вклад каждого еще можно разглядеть, а когда разработчиков сотня тысяч - я скорее удивлен что процент "волков" низкий такой.
В общем то даже по опросу приложенному к статье заметно. Прошли времена когда в айти шли из интереса к отрасли.
А чёт Стэнфорд не заикнулся чтоб "инженерам 5х" зепку в 5 раз поднять 😁 Хотя да, это же другое
Опять же, а вы уверены, что "инженер 0.1х" это не тот человек, который проводит по 4 ревью в день "инженерам 5х", потому как плодить говнокод ума много не надо, удаль молодецкая нужна. Можете в рамках эксперимента конечно уволить таких, но через год придется вызывать "эффективного менеджера", который потрясая дипломами European Businesses School родит банальное "закрыть направление и зафиксировать убыток". Ну и уволить заодно предыдущего оптимизатора, который решил уволить инженеров 15+ лет опыта за недостаточное количество зелёных плиточек в корпоративном гитлабе.
"Реджи, если живёшь в стеклянном доме, не бросайся камнями" Ауф штоле))
Мне кажется, если делалось такое исследование, то паралельно нужно было бы предоставить цифры о проценте компаний, заставляющих своих работников перерабатывать самым различным образом без оплаты. И гит дает такую возможность. И там будет далеко не 10%. Мой опыт говорит, что практически все. Конечно можно сказать, что это субъективные данные одного человека. Но так было бы честнее. Интересно, что заставило автора выбрать именно эту тему?
Знаете, я видимо, по факту один из таких инженеров-призраков: меня взяли "под задачу", и я её, блин делал целый год, реально изучал-говорил-решал-планировал-воплощал-дописывал...
Когда наступил день Х с моей стороны всё практически стартануло (может просто повезло), были ожидаемые проблемы и неожиданные, часть неожиданных была мной нерешаема...
Что-то подсказали "смежники" что-то подсмотрел в интернете, что-то пришлось по факту необходимости добавлять (несколько фич)... А через год я стал тем самым призраком: работает-не трожь, не работает почини хоть посреди ночи (посреди ночи не особая проблема, поскольку данная специфика была ясна ещё при изучении задачи). И чинить приходилось нечасто... Меня вроде даже хвалили за отсутствие проблем (лол).
В общем когда я собрался оттуда уходить (по причинам не связанным прямо с работой) мне, блин, предлагали повышение з/п и просили хотя бы резко не уходить!!! В итоге на моё место взяли другого человека (и з/п у него походу побольше моего было), потом, кажется, пригласили к сотрудничеству фирму, и потом кажется взяли ещё одного человека!!!!! (Хотя конечно задача у них стояла не только поддержки, но ещё и модернизации и не только того что я делал). Хотя по факту я там нового кода не добавлял иногда месяцами ((.
Так что, думаю, не все инженеры-призраки одинаково бесполезны. )))
Непосредственному рукводителю и так очевидно, у кого какая производительность, не обязательно считать коммиты. Принимать решения об увольнении должен тоже непосредственный руководитель. И перед тем как это сделать, он обязан разобраться в ситуации. Потому что иначе уволив сотрудника и проигнорировав проблему вы потеряете деньги дважды.
А вот такое принятие решений "через плечо" руководителя по метрикам не разбираясь в ситуации, в целом ухудшает качество решений и может в итоге стоить дороже, чем 10%.
"Это несправедливо обременяет команды, тратит ресурсы компании, блокирует рабочие места для других и ограничивает прогресс человечества. " - а представляете какая экономия будет, если перестать содержать менеджеров призраков и акционеров, тем более что среди последних ничего не делают 100% :) Гроши от экономии на программистах будут незаметны на фоне таких сокращений :)
В очередном треде на реддите юзер хвалился, как он делает за полдня работу, на которую отведены две недели, а остальное время пинает балду. На вопрос "как же так" последовал гениальный ответ -- "Это проблема менеджеров".
Так и здесь -- если кто-то бездельничает, значит это кому-нибудь нужно кому-то безразлично.
Следствие ли это свободной корпоративной культуры, diversity hire или, может быть, менеджеры тоже принадлежат к аналогичным 9.5% -- тема для следующего исследования.
Ну что могу сказать эти грубо говоря 10% это для больших компаний это лишние траты потому что если находят таких то это идёт бюрократическая мешанина с расследованием, а это простой или замедление работы отдела/отделов и выплаты за увольнение, так что проще их держать в штате. Так же эти сотрудники очень хорошо прячутся среди тысяч сотрудников, а не сдают их лишь потому, что за это может прилететь и тому же менеджеру отдела и вместо плюсика перед начальством быть уволенным вместе с ним, поэтому всем попросту наплевать. Плюсом это так же потенциальные убытки ведь такие люди это потенциальные клиенты, так как они могут покупать и использовать продукцию компании (И тут выходит вопрос, в долгосрочной перспективе они потеряют больше или меньше, если последуют вашему "исследованию" ибо вы не показали метод исследования, а учитывая что в графике указаны только софтскилл инженеры, а это зачастую тимлиды, что по факту руководят и не пишут код, даже если могут и умеют, а это зачастую важные люди в компаниях). Так же эти 10% процентов даже если о них знают, то вспоминают о них только тогда, когда начинаются убытки и идёт массовое сокращение. И будем честны избавление от этих 10% процентов ничего не даст, на их месте появятся новые и так по кругу. Так же любой грамотный работник может попасть в эту выборку, потому что сроки выполнения задач N , а он выполнил быстрее и занимается ИБД, вместо того, чтобы делать сверхнормы, ибо зачем, если ему не платят за это.
Тут ничего удивительного нет. С одной стороны бесконечное раздувание штата в сторону тех, кто к коду вообще отношения не имеет, с другой стороны изобретение методологий, согласно которым прогрОмировать может любая обезьяна, главное, соблюсти некий священный ритуал. Это то, что на поверхности.
Горящие глаза в этой индустрии уже как-то не очень нужны. Нужны красивые отчёты, хорошо подвешенный язык, новояз со всех сторон. Не дай бог какую снежинку заденешь...
Вот тоже интересный вопрос. Один делает таск пару дней, другой - пару месяцев (да с красивыми отчётами). И кто из них на самом деле ничего не делает?
Исследование само по себе интересно (что исследовалось и как), но, как и часто в других исследованиях, с выводами я не согласен.
Некто за месяц делают меньше 3 коммитов и это плохо (согласно статье). Ну, видимо, я тот самый (как и большинство в моей команде), потому что я всегда сливаю в один крупный коммит по своей задаче в своей ветке всё, что было сделано, чтобы потом, когда сливаю с master/test/prod, меньше проблем с конфликтами было.
Некто делает тривиальные изменения в 1 строку. Тут непонятен срок. Тоже в месяц? Тогда, скорее всего, либо их не проверяют менеджеры, либо они искали и нашли сложную ошибку. В первом случае, вина и программиста, и менеджера, во втором программист молодец. И даже в этом случае, у задач есть сроки, зачастую. Это всё должны проверять регулярно менеджеры, а до них (зависит от иерархии) тимлиды, техлиды. Если и есть проблема, то потому что выше по иерархии кто-то, как минимум один, свою работу не делал. Даже если такое происходит у это сотрудника регулярно - есть те, кто про иерархии выше и должны были это проверять. BigTech же, а не команда на 5 человек, где сам следит за собой.
Ну и дальше скорее всего ложные выводы на базе других ложных выводов - экономия, плохие программисты, 0 информации о менеджерах и т.д.
Печально что если поискать эту статью в сети, то выйдет десяток, где уже все программисты не работают, программистов можно увольнять, программисты не нужны и т.д., и т.п. Ящик ИТ-Пандоры открыт.
Ждём аналогичное исследование о деятельности менеджеров от Стэндфорда же, вместе с сокращениями (а их ЗП в 10-300 раз больше) и всё такое.
Как говорил Василий Иванович Петьке - "Но есть один нюанс" - и этот нюанс заключается в частности в том, что люди вообще-то общаются между собой и кто бы мог подумать - на работе часто общаются по работе! И как оценить вклад опытного человека который помогает другим? Да даже просто разряжает атмосферу! И никогда не возможно оценить умственную работу количественным показателем в виде написанных строк или количества коммитов.
Не все люди одинаковые.
Мой личный опыт говорит, что люди в офисе в основном обсуждают "а я вчера так на бэмэвэ зажёг... а я вчера с такой тёлкой эээээ...."
Да, понимаю, мне не повезло с отделом. Но за 10 лет в офисе, имхо, не было ни одного полезного обсуждения "в курилках". И смысл тогда так рваться в офис?
А по мне так наоборот повезло, обычно на кухне и в курилке все же хочется отвлечься немного от работы :) А по рабочим вопросам можно и комнате пообщаться. Понятно если эти беседы затягиваются на политические споры надолго и т.д. это ни к чему а если на пару минут историю из жизни кто-то расскажет - по мне так неплохо.
Я понимаю, что копипастить только то, что подходит под наши убеждения - это то, что все мы так любим.
Но в конце оригинальной статьи есть гораздо более важные выводы, чем вынесены в заголовок. А именно:
Среди удалёнщиков встречаются сотрудники, которые показывают производительность в разы лучшую, чем офисные сотрудники. (Видимо потому, что их никто не отвлекает).
Зы: Омг, нашёл. В статье есть фраза "разработчики 5х". Хехе. Сорри за панику ;)))
Так это вопрос не к инженерам, а к менеджменту. Не грузит задачами, взял про запас, не умеет контролировать выполнение, ждёт подписания договора, не хватает инфраструктуры на всех, etc.
Какими метриками измерить коммуникацию (которая съедает минимум половину времени), ревью кода, консультации, парное программирование, прототипирование, эксперименты?
"Эффективные менеджеры" видят вот эти цифры и отменяют удалёнку, а добросовестные работники страдают.
Исследование: 9,5% программистов в крупных IT-компаниях практически ничего не делают и являются сотрудниками-призраками