Комментарии 11
Эх, очередной рекламный пост AI-скама на сомнительных алгоритмах... Никакой конкретики, одни превознесения их загадочной, но НЕСОМНЕННО всезнающей модели. Кушайте, не обляпайтесь.
Я поделился разговором с автором исследования, чтобы была лучше понятная мотивация. Зачем вообще оценивать продуктивность, этично ли это делать и как грамотно всё устроить. Автор исследования как раз и рассказал зачем ему всё это:
Мне нравится работать в условиях, где мой труд оценивают справедливо и поощряют за результат. Я предпочитаю команды в которых нет тех, кто ничего не делает, но получает ту же зарплату, что и я. Кроме того, если я лучше других, то я хочу чтобы мне платили больше. Это логично и мотивирует расти.
Так и не понял зачем реклама исследованию. Во-первых, это даже не продукт. Если кто-то вдохновится и захочет такое провернуть в своей компании, то ему нечего будет купить. Нет сервиса или услуги. Есть текст исследовательской работы и графики, которые как-то подтверждают теорию. Во-вторых, исследователи из США и реклама на Хабре в нынешнее время им не особо поможет. Рядом со Стэнфордом есть куча компаний, которым можно продать услугу быстрее и сразу же получить от них деньги, а не пытаться вывести средства из России окольными путями.
Нет, не этично делать это с помощью ML моделей. Этим занимается только один тип людей - те, которым нужно что-то продать. Да, это настолько простой вопрос.
Исследованиям тоже нужна реклама в наше время, т.к. они должны показывать свою актуальность, а не что это очередной развод на гранты. (Пока плохо выходит) Графики, которые что тут, что в твиттере это не более чем публицистический наброски, которые не отображают ну ровным счётом ничего.
Сообщество Хабра не сошлось клином на России - здесь есть люди из множества стран, не вижу никаких противоречий.
Да, у Стэнфорда есть прилегающие компании, вот только они не лохи и это далеко не первый (и боюсь не последний) раз, когда им пытаются продать кое-как обученную модельку, которую прошу заметить обучали на какой-то непонятной выборке из добровольцев (с - твиттер этого мужика) и они так просто уже не купятся.
Как ML, чёрт его побери, модель должна определять, что человек, который день-два продумывал архитектуру, хорошо подумал это вообще выше моего понимания. Ну нееееет оптимальных критериев, чтобы такое мерить. Но из раза в раз мы видим таки горе бизнесменов-исследователей, который продают откровенно вредные утилиты ничего не подозревающему бизнесу.
Закончу чудесной цитатой из твиттера этого творца. Выводы делайте сами. (А к чему относится данный пост вообще лучше не читайте, а то совсем скиснете.)
"Europe didn't give me a chance to use my potential. The rigid system wouldn't let me skip 5 grades to enroll in university. The US did." (c)
К принципам в конце статьи можно добавить закон Гудхарта:
Принцип Когда мера становится целью, она перестает быть хорошей мерой
И на этом закончить разговор, оставив тему инженеров-призраков консалтерам-инфоконокрадам
Поддерживаю, пол статьи как крут автор и его регалии в стенфорде, потом как то фигня про построение моделей и оценки, а на десерт ссылка на 80-20 правило и цитата и Брукса. Я все это могу выдать без стенфорда и больших языковых моделей.
В корпорациях мера ВСЕГДА становится целью. Как результат - вы получаете то, что вы измеряете.
Исследование интересное. И похоже что авторы понимают, что кто креативность плохо работает под давленмем. Однако их инструмент, который они пытаются создать и продать компаниям, ведет в сторону цифрового конслагеря. Когда эффективные менеджеры быстро приспособят этот инструмент, чтобы увольнять кого он им их покажет и держать в страхе остальных. Т.е. если сейчас существуют компании с трекингом экрана, то с таким инструментом это уже не нужно. Можно любого проанализировать постфактум за любой период. "А че это вы тут так плохо работали с 15 по 22 августа 2019 года? Депримирован! Уволен!"
Но ИИ работает в обе стороны. Если одни начнут мерять код и наказывать или премировать сотрудников с помощью ИИ, то и сотрудники начнуит генерировать бесконечное количество бессмысленного кода лишь бы создать видимость деятельности, так что это игра в двое ворот так сказать. Пользы от этой практики в конечном итоге не будет, а вред будет.
Ограничения своего подхода авторы понимают. Но вот пользователи их результатов не всегда.
В больших компаниях, особенно если кодовые метрики учитываются в ежегодном ревью, попадается тип инженера - "энтузиаст". Он влезает в любой проект в самом начале. Пишет тонны кода. Но для того чтоб проект дошел хотя-бы до стадии MVP, нужно весь его код выкинуть и переписать. Этот код написан без размышлений о том как он будет взаимодействовать с другими компонентами, как он будет работать во всех сценариях, и прочее. Такой код даже заглушкой назвать нельзя. Он написан в стиле "суета ради суеты".
Кодовые метрики таких типов всегда на высоте, на уровне лучших senior инженеров компании.
С другой стороны есть люди которые пишут очень мало кода. Но этот код критически важен, и часто сложен. Он определяет архитектуру системы на годы вперед. Часто такие люди проводят большую часть рабочего дня за разговорами в кабинетах и на кухнях. У этих людей кодовые метрики обычно не сильно хорошие. Единственно что их отличает, их код живет долго. Десятилетия спустя его все еще можно найти внутри основных библиотек. И он обычно обвешан комментариями вида: "ни в коем случае не менять", "обязательно code review с super-system-core командой", "director of engineering approval is a must".
И если первый тип инжинеров можно легко уволить, то вторые критически важны для развития компании. Но понять это, глядя на кодовые метрики, практически нереально.
Принцип Парето (80/20) Принцип: 80% результата достигается за счёт 20% усилий, а оставшиеся 20% результата требуют 80% усилий. В разработке ПО: Обычно 20% разработчиков создают 80% ценного кода, а 20% функционала продукта удовлетворяют 80% потребностей пользователей. Этот принцип помогает менеджерам сосредоточиться на ключевых приоритетах, не растрачивая ресурсы на малозначительные задачи.
Но вы всегда ставите приоритет не на тех 20 процентах. И увольняете не те 20% инженеров.
Продуктивность зависит не от разработчика, а от процессов, которые выстраивают менеджеры. Согласны ли вы с этим суждением?
Правильно, от выстроенных процессов очень зависит и от команды. Не бывает, чтобы кто-то ничего не делал, в хорошо выстроенном процессе и продуктивной команде.
Ну а описанное выявление "призраков" нейросетью ищет симптомы, а не болезнь, как мне кажется.
Интервью с Егором Денисовым-Бланчем: кто такие «инженеры-призраки» и как с ними бороться