Comments 30
Оставлять артифакты везде, где можно, чтобы показать свою активность, но на самом деле не делать ничего или мало.
Например: есть опытный программист A и неопытный программист B.
Тимлид смотрит бэклог и говорит: «вот тут есть баг, он непонятен, отдадим его A. А следующий баг очевиден и мы отдадим его B».
В результате A садится на задницу пытаясь найти руткос проблемы. Он не оставляет артефактов, у него нет коммитов. Он постоянно двигает due-date с мыслью «ну на этой-то неделе точно сделаю»
За время работы А программист B делает 10 мелких задач создавая много артефактов.
В конце концов у программиста А образуется 1 строка кода в правильном месте и его лишают премии за низкий рейт. Программист В получает почётную грамоту за великую производительность.
На следующей итерации всё повторяется.
Это решается разными способами. Можно анализировать метрики по опытным и неопытным разработчикам раздельно. Можно исключать из анализа такие "исследовательские" таски (для которых значительная часть используемых метрик явно не применима). Можно прибегать к анализу метрик только в тех случаях, когда традиционным (как обычно делается без метрик) способом понять что происходит не получается.
Тот кейс, который Вы описали — это банальный пример использования инструмента не по назначению. Это происходит прямо сейчас и без всяких метрик — почитайте как происходит продвижение в гугле, например. Навык сделать хорошо работу и навык донести факт важности/сложности/качества выполненной работы до того, кто должен оценивать тебя и твою работу — это два совершенно разных навыка. А учитывая, что первый навык (в случае программистов) относится к техническим, а второй к софт-скилам, то нет ничего удивительного в том, что мало у кого присутствуют оба сразу.
И адекватную и неадекватную оценку своей работы можно получить любым способом, хоть с метриками, хоть без метрик. От применения некоторых метрик (напр. подсчёт строк кода или частота нажатий на клавиши) намного больше вреда, чем пользы. Но это не значит, что полезных метрик не существует, и единственный доступный способ оценки — субъективное мнение непосредственного начальника и/или коллег.
Описанные в статье метрики — это просто инструмент. Им можно пользоваться адекватно, и он принесёт немало пользы. А можно пользоваться неадекватно, и он принесёт немало вреда.
Механически привязывать метрики к штрафам/премиям/повышениям/увольнениям, безусловно, нельзя — вреда от этого будет намного больше, чем пользы. Может лет через 20 метрики разовьются настолько, что подключенный к ним ИИ будет в состоянии автоматически принимать такие решения адекватно. А пока все эти метрики выполняют скорее роль утилиты-линтера, механически сигнализируя о типичных проблемах — такие сигналы полезны, но они не всегда корректны, и поэтому оценивать их адекватность всё равно пока что должен квалифицированный специалист.
Вот скажите мне — в этом году сколько раз лично тебя, коллега, спросили — чего тебе хочется, родной? Как дела твои, о чем мечтаешь, к чему стремишься? Напишите мне кто ни будь статью о том как кто-то заботится о программистах, если вам не трудно. Можо без картинок. Заранее спасибо пожалуйста.
Вы смешиваете в одну кучу очень разные вещи.
Сидя на работе, за которую бизнес деньги платит, надо заниматься тем, что нужно бизнесу, а не тем, чего программисту хочется/интересно. Если программист хочет заниматься тем, что ему интересно — пусть подбирает проект, на котором бизнесу нужно чтобы он занимался именно этим, либо учится доносить до бизнеса идею того, чем интересное лично ему поможет бизнесу и проекту, и почему стоит этим заниматься, либо делает то, что ему интересно, в опенсорс и в свободное время. Если плохо на текущей работе/проекте — меняйте работу, благо с нашей профессией и текущим состоянием рынка это не так уж и сложно.
Все описанные в статье метрики — вполне здравые и полезные, равно как и описанный в статье подход по их применению. И там нет абсолютно ничего про поминутный контроль перекуров или про подсчёт строк кода — такие метрики действительно причиняют больше вреда, но это не значит что любые метрики враждебны к программистам.
И да, действительно есть отчётливая тенденция попыток "перевалить" на программистов управленческие задачи, чтобы они сами про себя собирали метрики, сами реагировали на сигналы, сами контролировали исполнение этих процессов… И относится к этому можно по-разному. Можно так: "моё дело просто писать код какой попросили, а работа менеджера контролировать чтобы я это делал то, что нужно, и так, как нужно, и нечего на меня переваливать его работу". А можно так: "моё дело решить проблему бизнеса, написав нужный код в нужные сроки с нужным качеством, и любые инструменты которые автоматизируют и облегчают для меня достижение этой цели — полезны, даже если из-за них мой менеджер останется без работы". Лично мне больше нравится последний вариант, потому что он делает меня более эффективным разработчиком в глазах бизнеса, что очень положительно сказывается на том, какой у меня выбор интересных проектов и зарплаты.
Сидя на работе, за которую...Вот тут людям кто на работе работает а не сидит наверное обидно.
Если плохо на текущей работе — меняйтеЯ с этим согласный двумя руками.
моё дело решить проблему бизнеса, написав нужный код в нужные сроки с нужным качествомИ с этим я однозначно согласен.
любые инструменты которые автоматизируют и облегчают для меня достижение этой цели — полезныА вот с эти совсем не согласен. Поясняю: подвох состоит в том что, во-первых за тебя пытаются другие люди решить что для тебя есть благо а что нет. Кроме того, по условиям игры отказываться от блага запрещено. Это важно! Во-вторых, когда весь стек контроля уже запущен ты можешь решить устраивает тебя это или нет. Соответственно принимаешь ты условия работы или нет. Но когда этот стек внедряется постепенно, то трудно определить где же та размытая граница когда атмосфера перестала быть вдохновляющей. Собственно про это я и старался написать, но похоже выбрал не те слова. Если образно выражаться, то проблема в следующем — есть море проектов, курсов, программных решений, ориетнированных на то чтобы усилить контроль, повысить эффективность, увеличить продуктивность. Их можно прорекламировать, посетить или скачать и запустить. Но назовите мне такой проект который можно скачать (да-да, я тоже умею утрировать) и развернув в офисе сделать работу, ну что ли менее напряжной или стрессовой. Поимаете? В данном случае важен вектор. Сейчас можно легко найти технологию про «запрячь» и «взнуздать», но попробуйте найти хоть одну публикацию, эссе, даже простой камент в обсуждениях где будет написано о том, как в фирме Икс взяли и внедрили технологию, главная цель и профит которой в том чтобы повысить комфорт работы, поднять удовлетворенность или хотябы сбить накопившийся стресс? Причем я прошу не рекламу услуг тамады или интересных конкурсов, а описание свершившегося факта с перманентным эффектом. Сможете найти? Боюсь что такого нет. Всех эти вещей мы достигаем сами, причем зачастую не благодаря а вопреки. Вот как то так.
П.с.
мне больше нравится последний вариант, потому что он делает меня более эффективнымзамечательная эпитафия для Терминатора. Но вы же это не серьезно, правда?
Ребята, а вас не удивляет как много людей заботится о том как бы половчее впрячь нас (айтишников, в частности программистов) в бизнес-процесс. Как бы так покрепче нахлобучить на нас упряжь...
Нет, не удивляет. Программисты и тестировщики, дорвавшиеся до управления процессами, привыкли, что система работает четко. Если написан код без багов, сервер исправен, понятны все переменные окружения, и входящие данные корректны, то код работает. Но вот система, в которой участвуют люди, не работает так, как надо. Это вызывает когнитивный диссонанс и фрустрацию. Решение, которое подсказывает опыт, тоже кажется очевидным — надо усилить контроль над системой, лучше собирая метрики, как этот делает докладчик, введя формальные performance review и one-to-one, анализируя переписку в слаке, заставляя заполнять таймшиты (для привычных программистам системам это решение имеет свои аналогии — добавить логгирование на каждый запрос, прикрутить мониторинги, запускать под дебагом). Когда эти решения не работают, либо ухудшают положение, то закручивание гаек заходит на второй круг, и когнитивный диссонанс только усиливается. Поэтому, нет, не удивляет ни разу.
PS: и да, все эти люди игнорируют один нюанс, который не вывести умозаключительно из практик работы ЭВМ — сам факт контроля над программистами (точнее, знания программистов о том, что их контролируют) сильно модифицирует их поведение — почти квантовая физика выходит. Программист, который чувствовал себя партнером бизнеса, который решает проблемы, становится конвейерным рабочим. Но об этом уже можно целую статью написать…
Да, можно получать прибыль, превращая программистов в конвеерных рабочих, придерживаясь ряда омерзительных правил
1) Должен быть костяк (ядро, отцы-основатели) — команда людей, которые жестко регламентируют инфраструктуру, домен, тулинг, библиотеки, подходы, документирование. Также они создают свои API, ORM, а некоторых самых запущенных случаях и IDE. Все, кто не входит в костяк, должны быть лишены права решать что-либо из этого, и должны иметь минимальный импакт на бизнес — этих людей никто даже не пытается удерживать при попытке уйти. Костяк, понятное дело, должен иметь особые права и привилегии, ЗП выше рынка, либо долю, и понимать свою исключительность — с ними так, как со всеми, нельзя.
2) Задачи должны быть шаблонные и однотипные. На каждую задачу должен быть готовый подход, бест практис, и понимание сложности в человекоднях. Если надо что-то принцпиально новое, то пока товарищи из пункта 1 не подумают, и не научат, как, никто этого делать не будет.
3) Бизнес должен быть устоявшимся и крепким, и должен прекрасно осознавать все ограничения и побочные эффекты такого подхода.
Если хоть одно из правил не соблюдается, то скотское отношение к людям на основе метрик заканчивается очень плохо для собственника.
По факту, если все правила соблюдены, то такой подход все равно приводит к снижению гибкости и удорожанию разработки (продукты и услуги по кастомизации мелких конкурентов со стартаперским мировозрением выходят в разы дешевле), но добавляет стабильности и снижает риски в выполнении шаблонных задач (что часто бывает приоритетным для бизнеса). Не обладаю информацией, как это работает у Безоса, но могу предположить, что схема подобная.
Бизнесмены они не меценаты — поэтому мы, программеры — ресурс который надо доить.
Вот и появляется больше различных методик как поменьше кормить и побольше доить. Только программеры больно умные: на лапшу про «командный игрок» не сильно ведутся, да творческие: не понимая как создают что-то из воздуха. Поэтому обычные не подходят — придумывают необычные.
Обидно только, что сейчас набегут скулящие разработчики, которые в любом порядке видят посягательство на их нелегкую судьбу.
некоторые — ничто иное как способ давление, способ заставить девелоперов работать больше, быстрее но при этом ещё и без потери качества.
Заставить работать? Ну и много ли примеров, когда кого-то заставляли кодить больше, и действительно стали кодить больше? Не смешите меня. В этой профессии можно заставить быть на работе больше, но заставить работать больше, к сожалению, нельзя. И метрики тут никак не помогут. А вот поправить процесс, чтобы избавиться от издержек и лишней работы — вполне себе решаемая задача, и в большинстве случаев мне известных, меряют исключительно для этого.
Но. Есть две категории сотрудников — те, которые работают, и те, которые делают вид, что работают, попутно на каждом углу крича о том, их бедных несчастных прижимает кровавый бизнес. Если ты нормально работаешь и решаешь те задачи, которые тебе поручили — любая метрика скажет об этом. А вот если ты строишь ферму по полдня, ссылаясь на какие-то мифические сложности, о которых никто не знает, то это будет видно и будут приняты меры. Потому как пока ты пинаешь орган, рядом твои коллеги отдуваются в том числе и за тебя. А это не совсем честно.
Бизнес платит зарплату. Если бизнес идёт плохо, то зарплату в моменте будет нечем платить. И если ты наёмник (мы ведь в массе своей наёмники, да?), то будь любезен исполнять возложенные на тебя обязанности.
Еще раз повторюсь — метрики применяются для поиска неисправностей и улучшения процессов горздо чаще, чем для поиска способа напрячь кого-то ещё сильнее. В условиях дефицита кадров на рынке — это стрельба по ногам. Надавили — встали и ушли. Благо есть места, где платят и не давят вообще:)
Due date — инструмент планирования. В скраме инструмент планирования — велосити и капасити, что само по себе чистейшей воды метрики. А выход фич из спринта — метрика для ПМ, по ним он ориентируется на завершение проекта. ПМ в код вообще не должен смотреть. Для него важны проектные и процессные метрики, а не инструментальные. Инструментальные метрики важны для того, кто отвечает за разработку, для СТО, например. Точность и адекватность метрик — это сложный процесс, которым надо заниматься постоянно и калибровать, например, в случае, если сильно изменилась команда. Если подходить к процессу с умом, то кучу пользы можно извлечь от измерений. Причём для всех, а не только для кровавого бизнеса.
Мы на конференции про измерения говорили очень много именно для того, чтобы показать пользу, а не разрекламировать очередной инструмент для пыток.
Звучит так, что вас не повезло с руководителем и, возможно, компанией.
Я готов открыто признаться — я хочу получать максимум пользы при минимуме затрат. Чтобы кроме проектов можно было позаниматься развитием технологического стека, поработать с техдолгом и всем тем, что не приносит прибыль в явном виде, не работать сверх положенного, или в выходные, когда внезапно выяснится, что проект просрали, а никто не в курсе.
И выжимать при этом я никого не хочу, пооому что разбегутся или начнут хачить систему по закону, который коллега привёл ниже.
Работник вообще ничего не знает про бОльшую часть метрик. Они нужны для калибровки процесса. И комит в код это лишь одна из метрик для оценки!!! процесса!!.. Если у вас в этот конкретный модуль идут комиты сотнями, значит важность тестов возрастает. Если у вас Вася делает следующим комитом откат предыдущего с завидным постоянством — это повод понять, откуда растут ноги. Может ему требования меняют регулярно и надо дать по голове тому, кто требования носит, а может он тупо не может с первого раза прочитать корректно и его надо научить читать правильно. А может от затрахался и ему надо в отпуск.
Откуда такое маниакальное стремление во всем увидеть желание работодателя выжать все соки??? Инженер без соков больше ошибается и приносит меньше пользы. Если руководит адекватный менеджер, который умеет адекватно читать результаты измерений — все хорошо и все счастливы. А сдуру, как известно, можно сломать что-угодно.
— уважение к чужому труду, чужому мнению, потребностям;
— наличие компетенций и знаний в области деятельности;
— честность, смелость отстаивать интересы команды и брать на себя ответственность;
— умение слушать;
— желание и возможность учиться новому.
Поэтому адекватный менеджер будет эффективный в какой был методологии он не работал и какие процессы бы не поддерживал. Другое дело, что если процессы противоречат его ценностям, то как честному человеку ему лучше найти другую работу и оставаться в душевном спокойствии.
Понятие адекватности вполне универсальное:
Вы таки мне не поверите, поэтому у меня и ссылка есть: Адекватность это способность организма реагировать на раздражитель.
Ещё немного из того же источника: "Определенное поведение которое ясно, и не вызывает у окружающих никаких вопросов."
Суть в том, что адекватность менеджера определяется ожиданиями окружающих. И у босса этого менеджера ожидания нередко сильно отличаются от ожиданий подчинённых этого же менеджера. Вы описали свои личные ожидания, но к универсальности это отношения не имеет.
Лично для меня адекватный менеджер тот, который эффективно делает то, что должен делать на своём месте. Например, если речь о линейных менеджерах, то его работа заключается в том, чтобы организовать и обеспечить эффективную работу команды. Что конкретно для этого надо делать у адекватного менеджера определяется… раздражителем (в соответствии с вышеприведённым определением), в роли которого выступает команда с одной стороны и его собственный начальник с другой. А у неадекватного менеджера это определяется модной методологией, или тем, что ему посоветовали на последних курсах, или его ЧСВ. Либо, ещё один популярный вариант неадекватности, когда учитывается только один раздражитель (обычно его собственный начальник), а остальные раздражители (команда) никак не влияют на действия менеджера.
Существует достаточно известный Закон Гудхарта, который имеет много формулировок, но как никогда лучше применим к IT-менеджменту:
ЗАКОН ГУДХАРТА
(Goodhart’s Law) Экономический закон, в соответствии с которым любая попытка правительства контролировать экономическую переменную может исказить эту переменную настолько, что сделает правительственный контроль неэффективным. Сформулированный экономистом-монетаристом Ч.А.Э. Гудхартом (род. 1936), он был впервые использован для измерения денежной массы (money supply) М0, М1 и М3 в фунтах стерлингов, которую монетаристские правительства (cм.: монетаризм (monetarism) пытались контролировать в целях снижения инфляции.
Гудхарт считает, что, как только люди узнают о попытках правительства контролировать какую-то экономическую переменную, они начинают всячески уклоняться от этого контроля, что ведет к нарушению правительственных планов.
Впринципе это все, что нужно знать о всякого рода метриках.
Три года назад я читал доклад на тему тёмной стороны метрик. В нём в том числе я говорил о том, то крайне опасно делать выводы исключительно на цифрах и приводил синтетические, но показательные примеры. www.youtube.com/watch?v=89Xn99ZzZoY
Согласен, хорошие примеры.
Абсурдность метрик состоит в том, что статистической выборки просто недостаточно для того, чтобы вообще о чем-то можно было говорить. Ну какие выводы можно сделать по 100 коммитам или issues в трекере? Если посчитать доверительную вероятность, то можно смело заявить, что это все ни о чем. Тем не менее многие дяди с важным видом рассматривают месячные отчеты с красивыми графичками, которые они называют метриками, рассуждая почему произошел тот или иной скачок.
Метрики бывают полезны, когда у вас генерится достаточно большая статистика. Тогда внезапный скачок величины может говорить о том, что что-то произошло, и это требует дополнительного исследования. Причем сама метрика, не важно что она мерит, никогда не скажет о реальных причинах произошедшего.
Оцениваем процессы в команде разработки на основе объективных данных