Как стать автором
Обновить

Комментарии 68

Раза три перечитал статью, но никак не могу понять: как именно, по-вашему представлению, связаны эффективность бизнеса и объём кодовой базы?

Невнимательно читали. Это ведь даже не между строк:
Цель измерения продуктивности — повышение эффективности бизнеса
Существенную часть расходов составляет фонд оплаты труда
наличие какой-то системы оценки продуктивности позволяет тим-лиду ответить на вопросы

-> Оцениваем хоть как-то продуктивность (правильно или нет — неважно)
-> тим-лид отвечает, кого уволить и кому не повышать ЗП
-> снижаются расходы
-> повышается эффективность бизнеса (но это не точно)

Жаль, что Вы не ТС, которому этот вопрос был адресован изначально. Ну да ладно, всё равно спасибо за ответ.


Разработчики, собаки этакие, действительно денег хотят. Некоторые даже много. Может, проще их вообще всех уволить (или хотя бы зарплату не платить), и тогда наша бизнес-эффективность взлетит к небесам?


Прошу, не отвечайте! Это был риторический вопрос. Лучше тоже, пожалуйста, внимательно перечитайте мой предыдущий комментарий. Я разве спрашивал "зачем надо оценивать продуктивность программистов?"? Нет, вопрос был другой: "как связана эффективность бизнеса и объём кодовой базы?". Могу переформулировать: влияет ли объём кодовой базы на эффективность бизнеса? Если да, то каким образом? Если нет, то почему?

А как разбогатеет тот, кто научится измерять продуктивность CEO, CFO, CTO и прочего менеджмента! Только почему-то никто не хочет думать о них. Всё внимание на разработчиках.

«Кто девочку ужинает, тот её и танцует» (с) :-)
(сам не руководитель, если что)
Как только разработчики прознают про метрики, они будут под них оптимизироваться: откладывать коммиты до нужного дня/часа и т.п.
Что Вы предлагаете взамен метрик?
Достаточно личного мнения руководителя о работнике. Видимо, такие руководители, которые не могут понять, хорошо выполняется работа, или нет, вынуждены делать формальные замеры.
А можете конкретизировать? На основании чего руководитель должен составить личное мнение о каждом работнике?
На всякий случай, я не руководитель. Но однажды захотел изменить принятую в компании систему KPI. И не смог, потому что не нашел достойных альтернатив.
На основании выполняемой работы. Всё хорошо видно на дейли-митингах: насколько быстро двигаются задачи, если ли возврат тасков обратно и по какой причине: баги или изменения требований.
Смахивает на субъективщину. Для объективной оценки нужны конкретные цифры, причем по каждому сотруднику в отдельности.
Впрочем, если в каждом конкретном случае разбираться и фиксировать на бумаге причину возврата тасков («баги или изменения требований»), то вполне неплохая метрика получается. Заодно и качество софта повысится )
НЛО прилетело и опубликовало эту надпись здесь

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


Вот же здорово будет: измерил художников и знаешь что это у нас новый Дали, а этот наоборот вообще бесперспективный :)

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

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

Ммм, измеряем эффективность труда программистов по количеству строк кода. Какая новая, и не побоюсь этого слова, революционная идея!

количества кода, создаваемого этой командой разработки
Если количество кода растет, значит, развитие идет правильно

Самый продуктивные по этой метрике — говнокодеры!
А рефакторинг (=чистка авгиевых конюшен от говна) — по этой метрике считается вредом.
Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.

Самого обосранного говнокодера — назначили сеньором! *фейспалм*
image

PS у этой статьи поддерживающей говнокод — рейтинг +19, и 24 «эффективных» манагера на Хабре (Карл!) не знают, что такое рефакторинг и считают правильным накопление говнокода!
Как такие люди становятся начальниками и руководят разработкой?

Да уж, лучший код - тот, который не написан.

Угу. Кажется, именно так родилось понятие «индусский код»?

Метрика показывает долю работы (и времени), потраченную впустую. 

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

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

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

А если 10 одинаковых формочек?
Разбил на компоненты, сделал динамическое создание - кода получилось мало
Тупо накопипастил - кода много, да ещё и быстро

случайные пятизначные числа

Скромные, однако, у вас кандидаты. Это за месяц и в рублях, или за год и в долларах?

Это же ДомКлик — то есть, Сбер. Должно быть понятно и так!

Спасибо, теперь понятнее :)
Если честно я плохо разбираюсь в зарплатах, но по моей информации, в мск ниже 120 тр в месяц ни один уважающий себя разработчик работать не будет, а приемлемые зарплаты начинаются от 200 тр - поправьте, если ошибаюсь.

Я не в Мск, к счастью. Было бы здорово услышать ответ от ТС, но его что-то не видать...

Не, строки кода это хорошо конечно. Тут уже многие про это высказались.
Плуреквесты тоже наверное не плохо, жаль не пропорциональны размеру команды.
А как насчет бэклога, фич и прочих пользовательских сценариев? Или насколько больше пользователь может сделать это никому не интересно?

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

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

Возьмите меня сеньором. Я знаю if и else!

if не возьмем else что?

goto line1
Заставляете козыри из рукава доставать!
НЛО прилетело и опубликовало эту надпись здесь
Я бы сказал, что описанное использование метрик совершенно валидно. Менеджер смотрит на метрики, чтобы понять — куда ему следует обратить свое внимание! Я тоже смотрю на метрики… Ошибкой является оценка(!) программистов на основе метрик. Или еще хуже — оплата за метрики… Но текст этого никоим образом не пропагандирует!

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

Ну… в тексте написано "… Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. ". Я бы сказал, что так оно и есть. Если менеджер или тимлид видят, что по метрикам человек выбивается из нормы — они должны посмотреть и найти объяснение этому явлению. В данном случае гипотеза очевидна — это джуны. Но в другом случае — может быть разработчик занят сложной проблемой где математики много, а кода — мало. Это тоже будет валидным объяснением. Или на него навешали административных функций из за того, что кто-то пошел в отпуск или заболел — такое бывает. Если в результате анализа было понято, что это объяснимое отклонение — ну и ОК с ним… В противном случае, можно начинать думать о корректирующих действиях (обучить, разгрузить/нагрузить, и т.д.).

Смертным грехом менеджера является подойти к разработчику и начать спрашивать: «А почему ты написал в два раза меньше кода чем Вася ?!». Потому что разработчик поймет, что его оценивают по количеству кода — и эта метрика станет бесполезной (он будет стараться подогнать ее под среднее чтобы к нему не лезли с вопросами). Ну а если менеджер говорит :«Я буду платить пропорционально строкам кода» — эта метрика мгновенно становится исключительно вредной (потому что все начнут соревноваться, как ее загнать на максимум).

А когда менеджер работает с метриками правильно — про его «шестое чувство» (на самом деле — нет) начинают ходить легенды: никто еще не заметил проблему — а он уже на пороге с уместными корректирующими мероприятиями…
НЛО прилетело и опубликовало эту надпись здесь
В нормальной ситуации, да — сеньор может написать меньше всех кода, потому что у него высокая эффективность = меньшее количество кода производит больший эффект, чем сотни строк говнокодера.
Но, автор назначил «сеньором» самого «производительного» по потоку говна говнокодера, и невероятно горд этим решением, а 37 «эффективных» менеджеров на Хабре (Карл!) считают это решение самым правильным. *фейспалм*
Мне кажется что вы сами в своей голове выдумали тезис «автор назначил...» и теперь с этой ветряной мельницей воюете… Вы можете как-то обозначить свою позицию: вам не нравятся примеры? Или вам не нравится управление на основе метрик? Если первое — ну придумайте свой пример… Если второе — попробуйте закрыть щиток приборов в машине картонкой и поездить неделю (в случае если не убедительно — сделайте то же самое на самолете — но предварительно не забудьте обновить завещание...).
Вы статью читали? Автор прямо пишет:
Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.

У него вообще нет никаких сомнений в голове, что тот у кого понос говнокода = «сеньор».

«Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. Причем причины могут быть вполне естественные: они просто junior-разработчики.» Я один вижу слова «могут быть»?

У автора других вариантов, кроме «пишет мало кода = junior, пишет много кода = senior» — вообще не представлено, и он считает это «естественным». И если, senior написал меньше кода, чем junior — он считает это «противоестественным».
Хорошо, я примерно понял — что вам не нравится. Да, бывает так — что сеньор пишет мало кода, а джуны — много. Но очень часто бывает и наоборот — поскольку сеньор работает быстро, на него валят все больше и больше задач. А джуны без руководства тыкаются туда-сюда с околонулевым КПД. Из метрик в такой ситуации сразу будет видна аномалия. В общем, вам не нравятся примеры. Дальше это сводится к дискуссии о вкусах (о которых, как известно, не спорят).
сеньор работает быстро, на него валят все больше и больше задач

Сеньор — это не тот на кого стоит навалить побольше мелких однотипных простеньких задач.
Сеньор — это тот кто сможет выполнить качественно сложную задачку, с которой качественно ни мидлы, ни джуниоры не справятся.
Вы, ruomserg, очевидно очень любите забивать гвозди микроскопом.
Жизнь сложнее простой схемы. В мире розовых пони, сеньоры решают сложные задачи, а джуны усердно учатся под присмотром тимлидов. В жизни оно бывает… по-разному. И задача руководителя — либо согласиться с этим «по-разному», либо намечать и проводить корректирующие мероприятия, чтобы оно стало по-другому.

Откуда вы сделали вывод про меня и микроскоп — мне непонятно. Естественно, что забивать гвозди лучше молотком. Но если гвоздь совершенно нуждается быть забитым и под рукой из инструментов микроскоп — ну блин, значит придется микроскопом… Хотя потом, как руководитель, я буду вынужден объяснять себе (а может быть, и не только себе...) — отчего мы так неэффективно использовали дорогой ресурс оптического увеличителя. :-)
Жизнь сложнее простой схемы
Именно поэтому сеньор может день провозиться с проблемой, и решится она не написанием какого-либо кода, а перенастройкой справочников CRM, или конфига сервера.
Ну так обязанность менеджера — выдвигать гипотезы и проверять их. Гипотеза что у людей низкая производительность из-за того что они джуны требует проверки не больше, но и не меньше чем гипотеза что они сеньоры. В первом случае нужно контролировать обучение и становление джунов. Во-втором случае можно сидеть и радоваться, как экономно люди научились решать задачи. Но в любом случае, нужно сначала это найти, потом пойти туда посмотреть, и только после этого можно принимать решения.
Реальный пример из жизни:
— я затратил несколько дней чтобы поймать трудноуловимую ошибку
— когда я её поймал, я… ничего не написал нового, а УДАЛИЛ пять символов!

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

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

В результате:
— по этой метрике нужно налепить 50 тысяч строк говно-закладок одну на другую с получением жутко глюкавого кода
— вместо того чтобы просто удалить 5 ошибочных символов.
Поставьте себя на место менеджера (вот мне везет, наверное — я то по одну сторону баррикад, то по другую)… Если он видит, что в ветке сначала люди пишут код — а потом к merge в мастер от него остается, скажем 30% — это разве не повод посмотреть, что там происходит? Может быть изначально требования хреново описаны? Может быть где-то документации не хватало? Может быть произошло дублирование работ? А может быть — это нормальное явление (и, например, этот код вытащен в соседнюю библиотеку)? В любом случае — менеджер должен для себя ответить на этот вопрос. Потому что ну это же в конце-концов — время, деньги и усилия людей! Если есть возможность не выкидывать на воздух ресурсы — ну так надо их и не выкидывать…

При этом, на право разработчика исправить баг удалив пять символов — никто не посягает. Если менеджер с бэкграундом программиста — он может и поблагодарить за такое красивое решение.
Может быть изначально требования хреново описаны? Может быть где-то документации не хватало? Может быть произошло дублирование работ?

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

Автор назначил сеньором говнокодера с максимальным поносом. Это значит, что он он объяснения предыдущего сеньора "почему он написал за день меньше строчек, чем джуниор" — даже слушать не стал.
Я боюсь, что ваши представления о людях и менеджменте сформированы где-то в мире летающих пони… Иногда люди не видят проблему, потому что это является для них исторической нормой. Иногда они не видят проблему потому что не могут сравнивать ситуацию у себя и у других команд. Иногда они видят проблему, но им кажется что не стоит заменять прыгающего убийцу — летучим… Иногда источник проблем находится вне зоны их контроля. Кто-то слишком скромный, кто-то не любит лишний раз мозолить глаза начальству, и т.д… Задача менеджера — ходить и разговаривать с людьми. И я согласен с автором статьи в том, что используя метрики в качестве стартовой точки — он может больше уделять внимания местам потенциального возникновения проблем. Еще раз повторю свою мысль — график и показатель не являются проблемой сами по себе. Это индикаторы, куда следует обратить внимание в первую очередь. В чем неразумность этого подхода?

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

«Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. Причем причины могут быть вполне естественные: они просто junior-разработчики.» Я один вижу слова «могут быть»? В общем, я не понимаю причин вашего недовольства. Если посмотреть статьи про внедрение KPI — то на фоне бодрого хора: «давайте назначим правильные KPI и будем платить за их достижение» — данная статья дает вполне разумный набор метрик для мониторинга и направление, как ими правильно пользоваться IMHO.
данная статья дает вполне разумный набор метрик для мониторинга и направление, как ими правильно пользоваться

*фейспалм*
Нет! Статья берёт за метрику = количество поноса говнокодом, и дальше уже идут неверные выводы.

По этой метрике:
— молодец не тот, кто добился цели не обосравшись
— а тот, кто ЭПИЧНО ОБОСРАЛСЯ, наплодив сотни тысяч строк говнокода, но так и не достиг целей.
Я боюсь, что ваши представления о людях и менеджменте сформированы где-то в мире летающих пони…

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


Задача менеджера — ходить и разговаривать с людьми.

Ага. Ходить и разговаривать с людьми, и при этом не знать об их проблемах, потому что "кто-то слишком скромный". Вы излагаете взаимоисключающие параграфы.


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

Не, не пойдет! Если PM будет постоянно ходить и с программистами разговаривать — они первые завоют, что он их от работы отвлекает. Плюс, PM один — а программистов много. Я остаюсь при убеждении, что нормальный менеджер должен в первую очередь уметь интерпретировать побочную информацию, которую создают разработчики в процессе написания кода (те самые метрики). Если метрики показывают аномалию — идти туда и разбираться (разговаривать с вовлеченными в аномалию людьми). Это не отменяет необходимости время от времени общаться со всеми остальными — но в первую очередь ограниченный ресурс руководителя должен использоваться там, где либо уже есть проблема — либо проблемы еще нет, но косвенные признаки заставляют подозревать что таковая появится.
Если PM будет постоянно ходить и с программистами разговаривать — они первые завоют, что он их от работы отвлекает.

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


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

Какой инструмент используется для получения такого анализа?

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

PZ1 к вам, только один вопрос: оценка за контрольную по математике
— должна ставиться за правильность решения задач?
2 + 2 = 4

— или за количество текста? (которое вы назвали «производительность»)
2 + 2 = ( 1 + 1 ) + ( 1 + 1 )
1 + 1 = 2
1 + 1 = 2
( 1 + 1 ) + ( 1 + 1 ) = 1 + 1 + 1 + 1 + 1
1 + 1 + 1 + 1 + 1 =  2 + 1 + 1 + 1
2 + 1 = 3
1 + 1 + 1 + 1 + 1 = 3 + 1 + 1
( 1 + 1 ) + ( 1 + 1 ) = 3 + 1 = 4
4 + 1 = 5
( 1 + 1 ) + ( 1 + 1 ) = 5
итого 2 + 2 = 5
НЛО прилетело и опубликовало эту надпись здесь
только 1 разработчик обладает знаниями по этому сервису. И если он уйдет, то вам придется потратить много времени на погружение новичков в проект. Находим все такие сервисы и делим кодовую базу с другими разработчиками компании.
Поскольку Брукс давно доказал, что «увеличение штата разработчиков снижает общую эффективность команды», надо не кодовую базу с другими делить, а создать такие условия, при которых у разработчиков не возникало бы желания уйти.
Много причин не зависит от компании: например, жена получила в наследство недвижимость в Москве, и семья переезжает.

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

Причём, там такие закавыки бывают. Например, врач москвы выдал постановление по торговле и транспорту, а вакцинируют программиста в Усть-Зажопинске.

Всё потому, что по бумаге контора занимается торговлей (а кто ей сейчас не занимается) или транспортом (как РЖД), а в постановлении не указано, что оно качается только тех, кто контактирует с клиентами — оно касается всех сотрудников. У компании офис в Москве, а в бумаге написаны — все сотрудники, т.е. формально филиалы во всех городах тоже включены.
Вы снова приводите частные случаи, навроде в-первый-раз-случившейся-вакцинации, в то время как я говорю о более распространенных ситуациях, которые имеют место быть в подавляющем большинстве случаев.
Ладно, не будем флудить.

Вы невнимательно читали. У меня нет под рукой самой книги, но вот цитата из вики, которая хорошо соответствует тому, что я запомнил после прочтения:

..., то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.

В вики точного числа не приведено, но емнип Брукс говорил о пределе около 7 разработчиков в команде. Так что даже если сделать двойное резервирование и назначит на сервис трёх человек, то это всё ещё будет полезно и для скорости его разработки. К тому же это позволит применять такие полезные практики, как code review.

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