Comments 68
Раза три перечитал статью, но никак не могу понять: как именно, по-вашему представлению, связаны эффективность бизнеса и объём кодовой базы?
Цель измерения продуктивности — повышение эффективности бизнеса
Существенную часть расходов составляет фонд оплаты труда
наличие какой-то системы оценки продуктивности позволяет тим-лиду ответить на вопросы
-> Оцениваем хоть как-то продуктивность (правильно или нет — неважно)
-> тим-лид отвечает, кого уволить и кому не повышать ЗП
-> снижаются расходы
-> повышается эффективность бизнеса (но это не точно)
Жаль, что Вы не ТС, которому этот вопрос был адресован изначально. Ну да ладно, всё равно спасибо за ответ.
Разработчики, собаки этакие, действительно денег хотят. Некоторые даже много. Может, проще их вообще всех уволить (или хотя бы зарплату не платить), и тогда наша бизнес-эффективность взлетит к небесам?
Прошу, не отвечайте! Это был риторический вопрос. Лучше тоже, пожалуйста, внимательно перечитайте мой предыдущий комментарий. Я разве спрашивал "зачем надо оценивать продуктивность программистов?"? Нет, вопрос был другой: "как связана эффективность бизнеса и объём кодовой базы?". Могу переформулировать: влияет ли объём кодовой базы на эффективность бизнеса? Если да, то каким образом? Если нет, то почему?
А как разбогатеет тот, кто научится измерять продуктивность CEO, CFO, CTO и прочего менеджмента! Только почему-то никто не хочет думать о них. Всё внимание на разработчиках.
На всякий случай, я не руководитель. Но однажды захотел изменить принятую в компании систему KPI. И не смог, потому что не нашел достойных альтернатив.
Впрочем, если в каждом конкретном случае разбираться и фиксировать на бумаге причину возврата тасков («баги или изменения требований»), то вполне неплохая метрика получается. Заодно и качество софта повысится )
Программисты это грубо говоря частный случай. Лучше сразу придумать как измерять "продуктивность" людей в творческих профессиях. На примере тех же художников или скульпторов или поэтов.
Вот же здорово будет: измерил художников и знаешь что это у нас новый Дали, а этот наоборот вообще бесперспективный :)
Ммм, измеряем эффективность труда программистов по количеству строк кода. Какая новая, и не побоюсь этого слова, революционная идея!
количества кода, создаваемого этой командой разработки
Если количество кода растет, значит, развитие идет правильно
Самый продуктивные по этой метрике — говнокодеры!
А рефакторинг (=чистка авгиевых конюшен от говна) — по этой метрике считается вредом.
Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.
Самого обосранного говнокодера — назначили сеньором! *фейспалм*
PS у этой статьи поддерживающей говнокод — рейтинг +19, и 24 «эффективных» манагера на Хабре (Карл!) не знают, что такое рефакторинг и считают правильным накопление говнокода!
Как такие люди становятся начальниками и руководят разработкой?
Да уж, лучший код - тот, который не написан.
Метрика показывает долю работы (и времени), потраченную впустую.
Отричательный результат это тоже результат - скорее всего, задача была сложная и поэтому приходилось много экспериментировать. Но на деле эта доля работы не потрачено впустую. Она потрачена на исследования.
В целом, что то такое можно и про другие метрики найти. На самом деле, все они это средняя температура по больнице и они не дают делать вот такие выводы. Но зато ими можно манипулировать.
Кажется очевидным, что пока задачи выглядят как «сделай красиво», то измерить ничего нельзя. А если задачи больше похожи на «сделай ещё одну формочку», то тут запросто. То есть возможность и точность измерения зависят от процесса, решаемой задачи и архитектуры системы. Если звёзды сошлись, то измеряется все прекрасно количеством тикетов в час или попугаев или самих часов. Но это если все стандартизовано и нормализовано.
случайные пятизначные числа
Скромные, однако, у вас кандидаты. Это за месяц и в рублях, или за год и в долларах?
Это же ДомКлик — то есть, Сбер. Должно быть понятно и так!
Не, строки кода это хорошо конечно. Тут уже многие про это высказались.
Плуреквесты тоже наверное не плохо, жаль не пропорциональны размеру команды.
А как насчет бэклога, фич и прочих пользовательских сценариев? Или насколько больше пользователь может сделать это никому не интересно?
Не совсем так. Считать, что программист, который пишет меньше кода, работает хуже — это уже очень вредно и в корне неправильно (выше в комментариях подробно про это написано). А то, что в команде не нашлось людей, кто смог бы это объяснить — это и вовсе очень плохой знак. Можно надеяться только на то, что автор статьи просто поигрался с графиками, ни на какие решения не влияет, а метрику "количество кода" никто из управленцев на самом деле не использует.
Смертным грехом менеджера является подойти к разработчику и начать спрашивать: «А почему ты написал в два раза меньше кода чем Вася ?!». Потому что разработчик поймет, что его оценивают по количеству кода — и эта метрика станет бесполезной (он будет стараться подогнать ее под среднее чтобы к нему не лезли с вопросами). Ну а если менеджер говорит :«Я буду платить пропорционально строкам кода» — эта метрика мгновенно становится исключительно вредной (потому что все начнут соревноваться, как ее загнать на максимум).
А когда менеджер работает с метриками правильно — про его «шестое чувство» (на самом деле — нет) начинают ходить легенды: никто еще не заметил проблему — а он уже на пороге с уместными корректирующими мероприятиями…
Но, автор назначил «сеньором» самого «производительного» по потоку говна говнокодера, и невероятно горд этим решением, а 37 «эффективных» менеджеров на Хабре (Карл!) считают это решение самым правильным. *фейспалм*
Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.
У него вообще нет никаких сомнений в голове, что тот у кого понос говнокода = «сеньор».
«Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. Причем причины могут быть вполне естественные: они просто junior-разработчики.» Я один вижу слова «могут быть»?
У автора других вариантов, кроме «пишет мало кода = junior, пишет много кода = senior» — вообще не представлено, и он считает это «естественным». И если, senior написал меньше кода, чем junior — он считает это «противоестественным».
сеньор работает быстро, на него валят все больше и больше задач
Сеньор — это не тот на кого стоит навалить побольше мелких однотипных простеньких задач.
Сеньор — это тот кто сможет выполнить качественно сложную задачку, с которой качественно ни мидлы, ни джуниоры не справятся.
Вы, ruomserg, очевидно очень любите забивать гвозди микроскопом.
Откуда вы сделали вывод про меня и микроскоп — мне непонятно. Естественно, что забивать гвозди лучше молотком. Но если гвоздь совершенно нуждается быть забитым и под рукой из инструментов микроскоп — ну блин, значит придется микроскопом… Хотя потом, как руководитель, я буду вынужден объяснять себе (а может быть, и не только себе...) — отчего мы так неэффективно использовали дорогой ресурс оптического увеличителя. :-)
— я затратил несколько дней чтобы поймать трудноуловимую ошибку
— когда я её поймал, я… ничего не написал нового, а УДАЛИЛ пять символов!
По этой метрике про которую автор хвастливо пишет:
Метрика показывает долю работы (и времени), потраченную впустую.
— я не должен был искать ошибку
— а должен был бы в первый же день написать несколько сот строк говно-заплатки
— естественно говно-заплатка всё сломала бы
— но я должен был бы опять же не искать ошибку в говно-закладке
— а должен был налепить поверх одной говно-заплатки другую говно-закладку
— которая опять что-нибудь сломала бы
— но так как метрика поиск ошибок считает за «долю работы (и времени), потраченную впустую»
— нужно было бы поверх говно-заплатки налепленной на говно-закладку налепить ещё несколько говно-закладок
В результате:
— по этой метрике нужно налепить 50 тысяч строк говно-закладок одну на другую с получением жутко глюкавого кода
— вместо того чтобы просто удалить 5 ошибочных символов.
При этом, на право разработчика исправить баг удалив пять символов — никто не посягает. Если менеджер с бэкграундом программиста — он может и поблагодарить за такое красивое решение.
Может быть изначально требования хреново описаны? Может быть где-то документации не хватало? Может быть произошло дублирование работ?
Любой нормальный менеджер уровня PM знает об этом не из графиков, а потому что ему словами через рот об этом сказали. Практически все программисты, помимо написания кода, навыками устной (или письменной) речи вполне себе владеют.
Так возражения же не против самих графиков делаются, а против авторских выводов из них, однобоких и во-многом наивных. Если бы автор представил хотя бы пару возможных интерпретаций для одних и тех же графиков, было бы значительно лучше. Но он уныло слился, и альтернативные интерпретации вынуждены высказывать комментаторы.
данная статья дает вполне разумный набор метрик для мониторинга и направление, как ими правильно пользоваться
*фейспалм*
Нет! Статья берёт за метрику = количество поноса говнокодом, и дальше уже идут неверные выводы.
По этой метрике:
— молодец не тот, кто добился цели не обосравшись
— а тот, кто ЭПИЧНО ОБОСРАЛСЯ, наплодив сотни тысяч строк говнокода, но так и не достиг целей.
Я боюсь, что ваши представления о людях и менеджменте сформированы где-то в мире летающих пони…
Мой комментарий выше — почти полностью про программистов, а не про менеджмент. Если программисты, столкнувшись с проблемами, не в состоянии сообщить об этом — вот это как раз и должно решаться разговором с PM.
Задача менеджера — ходить и разговаривать с людьми.
Ага. Ходить и разговаривать с людьми, и при этом не знать об их проблемах, потому что "кто-то слишком скромный". Вы излагаете взаимоисключающие параграфы.
Речь как раз идёт о том, что PM, адекватно выполняющий свои рабочие обязанности — должен быть в курсе проблем. Именно потому, что "ходит и разговаривает с людьми". А вот неадекватно выполняющий свои рабочие обязанности — весьма вероятно, что будет не в курсе, но зато придёт с графиками и будет радовать всех своими выводами "вот Вася много пишет, значит он сеньор". Итого (и у меня есть жизненный опыт на этот счёт) графики и метрики — удел профнепригодных менеджеров, частенько бывших программистов, которые пытаются решать социальные вопросы техническими способами. Конечно, менеджер-бывший-программист не станет делать выводы по числу строк кода, но это не значит, что его трактовки метрик будут хоть сколько-нибудь лучше.
Если PM будет постоянно ходить и с программистами разговаривать — они первые завоют, что он их от работы отвлекает.
Учитывая, что сейчас каждая первая контора "работает по agile" (что бы под этим не понимали) и почти всегда имеет ежедневные или около того пятиминутные встречи на "сказать, что делал и что будешь делать" — ваш тезис как раз откуда-то из страны единорогов.
Это даже не считая того, что из каждого утюга вещают (и всё больше контор реализуют) о необходимости регулярной обратной связи между исполнителями и средним звеном менеджмента.
Последний раз взять задачу и свалить в закат на недельку+ я мог в 2014 году, к слову говоря.
Удивляет, конечно, язвительность некоторых комментариев. Проношу свои извинения, если этой статьей нанес кому-то психологическую травму или наступил на старую мозоль. Но зато в некоторых комментариях есть вполне себе интересные мысли! (хоть и изложены они особым образом;)).
— должна ставиться за правильность решения задач?
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.
Продуктивность разработки