Здравствуйте, Glоbus, Вы писали:
Pzz>>Они не только результат хочут, они еще хочут, чтобы програмизды строем ходили. Некоторым это нравится, впрочем, ходить строем и чтобы порядок был. Не понимаю, почему эти некоторые в армию на контракт не идут, им так должно быть комфортно по идее.
G>Ходить строем — само собой маразм. Но к метрикам это никак не относится. И к порядку в конторе тоже.
Результат работы программистов измеряется даже не в строках кода, а в написанных, отлаженых и работающих продуктах. А отнюдь не в тех дебильных метриках, которые можно замерить.
Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.
23.09.2010 21:18, mag745 пишет: > > V>А если то, что чинить приходится напоминает небоскреб построенный на > V>основе собачьей будки? > V>Т.е. код настолько ужасен, что починка в одном месте ломает в другом? > > Есть такие программисты, у которых это в порядке вещей. Не хватает > усидчивости всё обдумать сначала, а потом не хватает этой же усидчивости > посмотреть что-же у него получилось.
Ты невнимательно прочитал то, что я написал выше. По очень многим
причинам (и программисты часто самая последняя причина) в конкретный
момент времени код некоего продукта может напоминать коромысло с двумя
ведрами. Долив воды в одно, поднимется другое.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Glоbus, Вы писали:
Pzz>>>Они не только результат хочут, они еще хочут, чтобы програмизды строем ходили. Некоторым это нравится, впрочем, ходить строем и чтобы порядок был. Не понимаю, почему эти некоторые в армию на контракт не идут, им так должно быть комфортно по идее.
G>>Ходить строем — само собой маразм. Но к метрикам это никак не относится. И к порядку в конторе тоже.
Pzz>Результат работы программистов измеряется даже не в строках кода, а в написанных, отлаженых и работающих продуктах. А отнюдь не в тех дебильных метриках, которые можно замерить.
Оки, ну давай обсудим. Как ты определяешь что продукт готов, отлажен и работает? Более того — просто работать продукту недостаточно — нужно чтобы он работал как требуется, а не как решила левая пятка девелопера в прошлый четверг. А это уже — формальные кретерии.
Pzz>Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.
А кто-то пытается определить результат по затраченным усилиям? Имя, сестра, имя! Я как раз и предлагаю судить о работе по результату: сколько времени заняло, насколько пролетели мимо кассы, сколько косяков напороли, процентный вклад каждого вида косяков по приоритетам (баги Urgent/High/Medium/Low...), по типам (UI, функционал, производительность,...). Всего-то 5-7 показателей, считаются руками в экселе за 5 минут, но вкупе с другими наблюдениями сказать нам могут об оооочень много
Здравствуйте, Marduk, Вы писали:
M>Здравствуйте, mag745, Вы писали:
M>>Здравствуйте!
M>>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом. M>>... M>>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией. M>>Какие же параметры загнать в KPI? M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
M>Как-то доводилось работать с компанией, где подобные метрики внедрялись. Результат не из самых веселых. M>Работа на "красивые циферки" оказалась приоритетнее работы на хороший качественный результат.
Метрики разные бывают — как правильные, так и нет
M>Да и есть классические примеры, как то же измерение производительности программистов в строчках кода. Вот то, о чем вы говорите может скатиться в подобную бредятину.
Один дурацкий пример неправильной метрики не говорит о том, что метрики как таковые не работают вообще
Здравствуйте, Glоbus, Вы писали:
G>Оки, ну давай обсудим. Как ты определяешь что продукт готов, отлажен и работает? Более того — просто работать продукту недостаточно — нужно чтобы он работал как требуется, а не как решила левая пятка девелопера в прошлый четверг. А это уже — формальные кретерии.
По наличию факта согласия заинтересованных сторон. Hint: в создании продукта не только девелопер участвует.
Pzz>>Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.
G>А кто-то пытается определить результат по затраченным усилиям? Имя, сестра, имя! Я как раз и предлагаю судить о работе по результату: сколько времени заняло, насколько пролетели мимо кассы, сколько косяков напороли, процентный вклад каждого вида косяков по приоритетам (баги Urgent/High/Medium/Low...), по типам (UI, функционал, производительность,...). Всего-то 5-7 показателей, считаются руками в экселе за 5 минут, но вкупе с другими наблюдениями сказать нам могут об оооочень много
То, что человек вставляет много зловредных косяков, может говорить о том, что у него руки-крюки, а может о том, что он писал самую сложную часть проекта. Другие критерии примерно столь же сомнительны.
С другой стороны, любой вменяемый тим-лидер знает, на кого в своей команде он может положиться, а кого терпит по принципу, "ну хорошо, что хоть эту работу он делает". В терминах галочек в ёкселе это не выражается. Надо доверять немного людям и прислушиваться к их мнению
Именно поэтому я считаю, что если компания начинает внедрять формальные системы учета и контроля, это означает, что человеческие отношения скоро эту компанию покинут, и поэтому надо неторопясь искать новую работу
Здравствуйте, Pzz, Вы писали:
Pzz>С другой стороны, любой вменяемый тим-лидер знает, на кого в своей команде он может положиться, а кого терпит по принципу, "ну хорошо, что хоть эту работу он делает". В терминах галочек в ёкселе это не выражается. Надо доверять немного людям и прислушиваться к их мнению
Так почему бы этому вменяемому тим-лидеру не дать дополнительную возможность стимулировать девелоперов деньгами, а не только красивыми речами о важности проекта и тп?
Может тот, кого приходиться терпеть, так работает от того, что не видит смысла стараться, и больше сил уделяет шабашкам.
А тот, на кого он привык полагаться, все еще не теряет надежды на то, что его усилия наконец-то будут оценены по достоинству, и вот-вот разочаруется.
Pzz>Именно поэтому я считаю, что если компания начинает внедрять формальные системы учета и контроля, это означает, что человеческие отношения скоро эту компанию покинут, и поэтому надо неторопясь искать новую работу
Насчет формальных, совершенно согласен, большое зло там, где работу невозможно оценивать формальными методами.
Так почему бы не оценивать неформальными? Просто оценить на глазок, Вася сделал 80% работы, а Петя только 20%, соответственно и премии получат столько же.
Если ПМ вменяемый, и сам заинтересован в успешности проектов, то будет стараться распределять по справедливости.
Хотя конечно, если Вася шибко увлеченный чел, и безо всяких премий готов вкалывать, то премию и так и так не получит
Здравствуйте, Demotivated, Вы писали:
D>Так почему бы этому вменяемому тим-лидеру не дать дополнительную возможность стимулировать девелоперов деньгами, а не только красивыми речами о важности проекта и тп?
В некоторых конторах дают. Но это далеко не всегда хорошо работает, и далеко не всем нравится.
Я, например, не люблю такой стиль работы не с какой стороны — ни как начальник, ни как подчиненный. Мне больше нравятся не месячные премии, а когда хорошим людям не забывают вполне регулярно поднимать зарплату.
D>Может тот, кого приходиться терпеть, так работает от того, что не видит смысла стараться, и больше сил уделяет шабашкам. D>А тот, на кого он привык полагаться, все еще не теряет надежды на то, что его усилия наконец-то будут оценены по достоинству, и вот-вот разочаруется.
Большинство людей мотивированны не деньгами — при условии, что они получают зарплату, близкую к среднерыночной.
D>Так почему бы не оценивать неформальными? Просто оценить на глазок, Вася сделал 80% работы, а Петя только 20%, соответственно и премии получат столько же. D>Если ПМ вменяемый, и сам заинтересован в успешности проектов, то будет стараться распределять по справедливости. D>Хотя конечно, если Вася шибко увлеченный чел, и безо всяких премий готов вкалывать, то премию и так и так не получит
Если Вася — человек, на которого я всегда могу полагаться, моя забота следить о том, чтобы Васе не забывали зарплату поднимать. А Петя, если он лодырь и разгильдяй, я не буду за его зарплату хлопотать перед начальством. А премии эти, ну их нафиг, от них суета и нервотрепка одна.
Здравствуйте, Glоbus, Вы писали:
G>На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!" G>На вскидку, можно предложить следующие KPI: G>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом). G>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п. G>Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.
Огромное спасибо. Вы указали направление, в котором уже можно рыть. Особенно количество предложений, внесенное за год.
Здравствуйте, Glоbus, Вы писали:
G>На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!" G>На вскидку, можно предложить следующие KPI:
Именно, что навскидку. Давайте копнем чуть глубже.
G>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).
Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March
G>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.
Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором.
Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.
И это еще не самое страшное. Глобальная проблема заключается в том, что люди станут избегать сложных и неделимых задач, т.к. они непредсказуемы. А это уже ведет к остановке профессионального роста программеров в компании. Естественно, руководство это, хоть и поздно, но заметит и начнет делать одних людей более равными, чем другие. У них испортятся отношения с остальными... ну и так далее.
Ни разу не слышал про KPI для программистов в достаточно зрелой компании, где есть хорошие ПМы. В таких компаниях обычно есть формальные оценки, но они делаются ПМами на основе личных наблюдений, и уж совсем не за количеством строк или багов. 360 фидбэк и т.п.
G>Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.
О! А вот это уже гораздо лучше. Стимулируется рост и селекция работников. Правда, к KPI в его классическом понимании это уже имеет весьма отдаленное отношение
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Glоbus, Вы писали:
G>>Оки, ну давай обсудим. Как ты определяешь что продукт готов, отлажен и работает? Более того — просто работать продукту недостаточно — нужно чтобы он работал как требуется, а не как решила левая пятка девелопера в прошлый четверг. А это уже — формальные кретерии.
Pzz>По наличию факта согласия заинтересованных сторон. Hint: в создании продукта не только девелопер участвует.
Откуда заинтересованная сторона узнает что продукт "готов, отлажен и работает"? Как она, сторона эта, это проверит? На глазок?
Pzz>>>Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.
G>>А кто-то пытается определить результат по затраченным усилиям? Имя, сестра, имя! Я как раз и предлагаю судить о работе по результату: сколько времени заняло, насколько пролетели мимо кассы, сколько косяков напороли, процентный вклад каждого вида косяков по приоритетам (баги Urgent/High/Medium/Low...), по типам (UI, функционал, производительность,...). Всего-то 5-7 показателей, считаются руками в экселе за 5 минут, но вкупе с другими наблюдениями сказать нам могут об оооочень много
Pzz>То, что человек вставляет много зловредных косяков, может говорить о том, что у него руки-крюки, а может о том, что он писал самую сложную часть проекта. Другие критерии примерно столь же сомнительны.
Не понял выделенное — косяки они и в африке косяки — хоть в "мегасложной части кода", хоть в диалоговом окне с одной кнопочкой ОК.
Pzz>С другой стороны, любой вменяемый тим-лидер знает, на кого в своей команде он может положиться, а кого терпит по принципу, "ну хорошо, что хоть эту работу он делает". В терминах галочек в ёкселе это не выражается. Надо доверять немного людям и прислушиваться к их мнению
Галочки в экселе дополняют картину, а точнее сказать — делают ее реалистичной. Потому как очень часто бывает так, что ты вроде думаешь, что на человека можно положиться, а вот галочки в экселе показывают, что последние 2-3 месяца он твоим доверием злоупотребляем.
Pzz>Именно поэтому я считаю, что если компания начинает внедрять формальные системы учета и контроля, это означает, что человеческие отношения скоро эту компанию покинут, и поэтому надо неторопясь искать новую работу
Дружище, компания — это прежде всего способ зарабатывания денег, и человеческие отношения там могут культивироваться только как один из способов мотивации коллектива. Если человеческие отношения перерастают в панибратство (а так зачастую и бывает, когда люди видят, что контроля за ними нету, и что попив пивка в тимлидом или проджект манагером можно авторитетно ему доказать, что он на самом деле не забивает на работу, а это типа клиент плохой, проект галимый ну и т.п.), то это первый гвоздь в гроб конторы.
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, Glоbus, Вы писали:
G>>На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!" G>>На вскидку, можно предложить следующие KPI:
nvb>Именно, что навскидку. Давайте копнем чуть глубже.
G>>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).
nvb>Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March
Поэтому нужно быть technical enought, чтобы понимать, насколько реалистичны предлагаемые сроки. Для нормального проджект-менеджере, или тим лида, которые с этими же самыми людьми каждый день бок о бок педалит оценить реалистичность вообще не проблема, и не только оценить, а и аргументированно доказать это своим подчиненым, чтобы не было конфронтации.
G>>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.
nvb>Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором. nvb>Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.
Но в сумме все равно получается неделя+день — т.е. 6 дней Плюс к тому: для понижения бажности кода никто не мешает вместе с KPI использовать такие вещи как стандарты кодирования, код-ревью и т.п. Должна быть вообще комплексная деятельность — на одних голых KPI никуда не уедешь. но они реально необходимы.
nvb>И это еще не самое страшное. Глобальная проблема заключается в том, что люди станут избегать сложных и неделимых задач, т.к. они непредсказуемы. А это уже ведет к остановке профессионального роста программеров в компании. Естественно, руководство это, хоть и поздно, но заметит и начнет делать одних людей более равными, чем другие. У них испортятся отношения с остальными... ну и так далее.
Таких вот "сложных и неделимых задача" всего дай бог чтоб 10% от общего объема было — если ты конечно не чистой наукой занимаешься. Для этих 10%можно проявить гибкость и устанавливать менее строгие KPI — скажем, просто: сделал/не сделал — и оценивать по ним.
nvb>Ни разу не слышал про KPI для программистов в достаточно зрелой компании, где есть хорошие ПМы. В таких компаниях обычно есть формальные оценки, но они делаются ПМами на основе личных наблюдений, и уж совсем не за количеством строк или багов. 360 фидбэк и т.п.
А KPI личные наблюдения ни разу не отменяют — эти техники друг друга дополняют.
G>>Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.
nvb>О! А вот это уже гораздо лучше. Стимулируется рост и селекция работников. Правда, к KPI в его классическом понимании это уже имеет весьма отдаленное отношение
Ты очень ошибаешся В том же lean production это как раз один из наиболее "любимых" KPI — количественная оценка инициативности сотрудника.
Здравствуйте, Glоbus, Вы писали:
GG>>>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).
nvb>>Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March
G>Поэтому нужно быть technical enought, чтобы понимать, насколько реалистичны предлагаемые сроки. Для нормального проджект-менеджере, или тим лида, которые с этими же самыми людьми каждый день бок о бок педалит оценить реалистичность вообще не проблема, и не только оценить, а и аргументированно доказать это своим подчиненым, чтобы не было конфронтации.
Немного разовьем высказывание. Тимлид хорошо разбирается в технической части и хорошо знает, на что способны его люди. Вопрос — а зачем ЗДЕСЬ вводить KPI? Что конкретно не устраивает руководство? Тимлид, зная все и вся, выдает реалистичный план-график, который выполняется. Такие тимлиды редко, но бывают (например, у меня были), и единственный вопрос, который им нужно задавать — не требуется ли чем-нибудь еще помочь? Лезть к ним с KPI — верх глупости. Если у такого тимлида в команду затесалась паршивая овца — гораздо проще эту овцу убрать и взять нового человека, чем играть в справедливость и ломать работающую устоявшуюся систему вводом KPI.
Вы не принимаете во внимание человеческий фактор. Программист не любит ходить строем, и чем он выше уровнем, тем меньше он любит муштру и тем больше имеет возможностей послать компанию на фиг, если в ней что-то не понравилось. Когда он пьет пиво в кругу близких друзей, он обычно хвастается свободным графиком, а не интересными задачами или зарплатой. Для него любое новое ограничение — повод задуматься о смене работы. Установите точное время прихода и штрафуйте за опоздания — очень скоро вы потеряете часть команды.
А архитектора вы как собираетесь оценивать? А еще священные коровы будут?
G>>>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.
nvb>>Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором. nvb>>Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.
G>Но в сумме все равно получается неделя+день — т.е. 6 дней
В озере в среднем по колено воды, но корова все-таки утонула. Куда именно сместится баланс? А если в желательную сторону у 10 формоклепателей и в нежелательную сторону у одного человека, который пишет ядро системы? Или подстраивать KPI под каждого человека? Так жизни не хватит.
G>Плюс к тому: для понижения бажности кода никто не мешает вместе с KPI использовать такие вещи как стандарты кодирования, код-ревью и т.п. Должна быть вообще комплексная деятельность — на одних голых KPI никуда не уедешь. но они реально необходимы.
Ну хоть признали, что на голых KPI никуда не уедешь. Зачем они необходимы — я не понимаю. На мой взгляд, обезличка оценки программистов через KPI никакой пользы не приносит, и применяется только тогда, когда уровень менеджеров ниже плинтуса, когда менеджеры не способны самостоятельно управлять коллективом (или их начальство так считает, что случается даже чаще).
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, Glоbus, Вы писали:
GG>>>>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).
nvb>>>Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March
G>>Поэтому нужно быть technical enought, чтобы понимать, насколько реалистичны предлагаемые сроки. Для нормального проджект-менеджере, или тим лида, которые с этими же самыми людьми каждый день бок о бок педалит оценить реалистичность вообще не проблема, и не только оценить, а и аргументированно доказать это своим подчиненым, чтобы не было конфронтации.
nvb>Немного разовьем высказывание.
Ага, давай
nvb>Тимлид хорошо разбирается в технической части и хорошо знает, на что способны его люди. Вопрос — а зачем ЗДЕСЬ вводить KPI?
Ответ прост: подчиненные этого тимлида — люди, а людям свойственно менятся, это динамичные системы, а это значит что под влиянием тех или иных факторов они могут начать педалить лучше, а могут хуже, могут вообще бунт устроить по каким-то политическим мотивам ну и т.п. Так вот КПИ позволяют выявить тенденции. К примеру: дев Вася очень хорошо кодит, но 2 недели наз он разбежался со своей девченкой и у него депресняк. Вполне вероятно, что Вася не настолько сильный человек, чтобы оставлять личное за дверью и педалить также эффективно всегда — вот и получается, что проблемы в личной жизни будут аффектить его работу. А КПИ позволят нам выявить следствия этого: отставание от графика, или увеличившееся число багов, или большее количество переоткрытых багов ну и т.п. И вот эти показатели позволяют нам задуматься — а мож с ним поговорить, узнать чем вызван спад в работе? Расскажет — классно, не расскажет — будем искать обходные пути узнать (черех ХР, других сотрудников ну и т.п.) — это уже другой комплекс мероприятий. Самое главное что мы в РЕАЛЬНОМ времени получили быструю обратную связь. Самая простая аналогия — тахометр в машине. Мы можем очень хорошо знать свю машину, заботиться о ней и все такое, но с помощью тахометра мы можем на ранней стадии определить неполадки в двигле или сопутствующих системах — скажем начали обороты плавать.
nvb>Что конкретно не устраивает руководство? Тимлид, зная все и вся, выдает реалистичный план-график, который выполняется. Такие тимлиды редко, но бывают (например, у меня были), и единственный вопрос, который им нужно задавать — не требуется ли чем-нибудь еще помочь? Лезть к ним с KPI — верх глупости. Если у такого тимлида в команду затесалась паршивая овца — гораздо проще эту овцу убрать и взять нового человека, чем играть в справедливость и ломать работающую устоявшуюся систему вводом KPI.
Ключевое здесь выделено — тебе как менеджеру или работодателю этих тимлидов нужно построить работу так, чтобы от них независеть, или по крайней мере зависить минимально. С точки зрения работодателя идеал — это когда у тебя куча легкозаменяемых и контролируемых винтиков. Насчет "лезть к ним с КПИ верх глупости" — не согласен. КПИ — это РЕАЛЬНЫЕ приборы, которые помогают тимлиду оценивать подчиненных не наоснове своих чувств, а на основе реально значащих показателей.
nvb>Вы не принимаете во внимание человеческий фактор. Программист не любит ходить строем, и чем он выше уровнем, тем меньше он любит муштру и тем больше имеет возможностей послать компанию на фиг, если в ней что-то не понравилось. Когда он пьет пиво в кругу близких друзей, он обычно хвастается свободным графиком, а не интересными задачами или зарплатой. Для него любое новое ограничение — повод задуматься о смене работы. Установите точное время прихода и штрафуйте за опоздания — очень скоро вы потеряете часть команды.
Выделенное — вообще высосано из пальца Насчет кто любит, а кто не любит муштру: муштру никто не любит, а вот порядок любят многие. Про потерю части команды — да, вполне вероятно, но я могу поступить и таким образом: я могу просто заткнуть им рты деньгами — банально дать з/п выше рыночной, при этом отжимая тоже больше чем в среднем по отрасли. И вот тут уже проблема у девелопера: с повышением з/п сразу поднимается уровень потребления, и отказаться от этого уровня наааамного тяжелее, чем приходить на работу к определенному времени и тратить 10 мин в день на заполнение тайм репорта. Скажу даже больше: когда недовольный товарищ потом пойдет по собеседованиям он может просто банально обломаться — окажется, что он не то что инкриса не может получить, а даже того уровня что у него есть щас, никто не предлагает. Сразу отвечу на вопрос "откуда взять доп.деньги, чтобы заткнуть девов": если расчеты верны и комплекс мер выбран правильно, то работа компании банально будет эффективнее — отсюда доппоступления. И самый прикол в том, что я лично знаю такие конторы — то есть это не мои фантазии. В общем и целом: КПИ — это составляющая целого комплекса из других мер и подходов, которые в сумме позволят оперативно реагировать на происходящее, если надо — быстро эволюционировать, измениться.
nvb>А архитектора вы как собираетесь оценивать? А еще священные коровы будут?
По результатам того, что он нааръитектурил. В простонародье это называется lessons learned: по завершении проекта подбивается итог — какие проблемы были, чем вызваны и т.п. Если окажется, что этот мегаархитектор напорол боков, при этом у меня в команде оказася человек, который эти бога смог выявить на ранних стадиях (для этого в компании есть такая вещь, как докладная записка), но всилу своей крутизны архитектор на эти замечания забил, то тут очень велик шанс того, что архитектор будет разжалован, а его место займет вот тот проницатильный бойкий пионер.
G>>>>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.
nvb>>>Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором. nvb>>>Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.
G>>Но в сумме все равно получается неделя+день — т.е. 6 дней
nvb>В озере в среднем по колено воды, но корова все-таки утонула. Куда именно сместится баланс? А если в желательную сторону у 10 формоклепателей и в нежелательную сторону у одного человека, который пишет ядро системы? Или подстраивать KPI под каждого человека? Так жизни не хватит.
Под каждого человека может и не хватит, а вот под определенный набор/тип тасков — вполне.
G>>Плюс к тому: для понижения бажности кода никто не мешает вместе с KPI использовать такие вещи как стандарты кодирования, код-ревью и т.п. Должна быть вообще комплексная деятельность — на одних голых KPI никуда не уедешь. но они реально необходимы.
nvb>Ну хоть признали, что на голых KPI никуда не уедешь.
Покажи мне, где я говорил иное?
nvb>Зачем они необходимы — я не понимаю.
Суммируя все выше сказанное: за тем же, зачем в автомобиле есть тахометр, спидометр, указатель уровня топлива, давления масла, заряда батареи ну и т.п. Зачтем же, зачем комании нужна бухгалтерия — цифры не обманишь: можно сколько угодно кричать, что твой продукт или твоя услуга меганравятся пользователям и клиентам, но если у тебя убытки, то тут шапкозакидательством ничего не решишь — только детальный анализ.
nvb>На мой взгляд, обезличка оценки программистов через KPI никакой пользы не приносит, и применяется только тогда, когда уровень менеджеров ниже плинтуса, когда менеджеры не способны самостоятельно управлять коллективом (или их начальство так считает, что случается даже чаще).
Управлять коллективом на одном чутье может получится только у реальных гениев управления — я таких за 8+ лет практики и в 5 разных конторах с персоналом от 5 до 300 человек ни разу не встречал. Более того, даже в бизнесе В ЦЕЛОМ все эти гении известны поименно: Сталин, Карлос Гон, Рэй Крок и еще наверное не более 10 других. Ты хочешь, чтобы твой бизнес зависил от гениев, от настроения примадонн? А если твоему гению завтра конкурент предложит не просто прибавку к з/п, а целый share в его бизнесе и он свалит — что будем делать с разбитым корытом (читай — неуправляемым бизнесом), у которого ты останешся? Или ты думаешь, что гении бизнеса и управления на каждом шагу? Реальность такова, что 99% людей (и мы с тобой в том числе) — слабые люди, подверженные переменам настрония, климатическим изменениям ну и т.д. и т.п., и задача процесса (частью которого должны быть КПИ) — снижение вот таких вот несистемных рисков.
Здравствуйте, Glоbus, Вы писали:
G>Ходить строем — само собой маразм.
Справедливости ради стоит заметить, что если надо чтоб относительно большая группа людей быстро и эффективно куда то переместилась пешим порядком то построиться в колонну и идти строем будет самое оно.
Но только для таких применений, да.
Здравствуйте, Glоbus, Вы писали:
G>Ответ прост: подчиненные этого тимлида — люди, а людям свойственно менятся, это динамичные системы, а это значит что под влиянием тех или иных факторов они могут начать педалить лучше, а могут хуже, могут вообще бунт устроить по каким-то политическим мотивам ну и т.п. Так вот КПИ позволяют выявить тенденции. К примеру: дев Вася очень хорошо кодит, но 2 недели наз он разбежался со своей девченкой и у него депресняк. Вполне вероятно, что Вася не настолько сильный человек, чтобы оставлять личное за дверью и педалить также эффективно всегда — вот и получается, что проблемы в личной жизни будут аффектить его работу. А КПИ позволят нам выявить следствия этого: отставание от графика, или увеличившееся число багов, или большее количество переоткрытых багов ну и т.п. И вот эти показатели позволяют нам задуматься — а мож с ним поговорить, узнать чем вызван спад в работе? Расскажет — классно, не расскажет — будем искать обходные пути узнать (черех ХР, других сотрудников ну и т.п.) — это уже другой комплекс мероприятий. Самое главное что мы в РЕАЛЬНОМ времени получили быструю обратную связь. Самая простая аналогия — тахометр в машине. Мы можем очень хорошо знать свю машину, заботиться о ней и все такое, но с помощью тахометра мы можем на ранней стадии определить неполадки в двигле или сопутствующих системах — скажем начали обороты плавать.
Извини, сейчас жутко занят, поэтому не могу ответить подробно. Если кратко — ты говоришь про систему сбора метрик, называя ее KPI. Но это разные вещи. Метрики нужны и очень важны, и они используются и в KPI, но KPI подразумевает (полу)автоматическое принятие решения по метрикам. Это принятие решения возведено в ранг закона, т.е. если Вася из-за девушки снизил производительность, ему надо однозначно резать зарплату. Даже если из-за этого он уйдет из компании, потому что иначе другие завопят: а почему мне режут зарплату, а Васе нет? Разрушится вся система, основанная на KPI. Либо менеджеру придется вилять и обманывать людей, что тоже приведет к краху.
Система же метрик предполагает, что у тебя документированы изменения параметров производительности сотрудников, но ты сам волен принимать решение, и не обязан за него отчитываться.
Поэтому, если везде в тексте заменить слово KPI на слово "метрики" — соглашусь с тобой почти во всем, кроме того, что нужно стремиться к переводу программиста в разряд легкозаменяемого винтика. Даже не буду объяснять, почему
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, Glоbus, Вы писали:
G>>Ответ прост: подчиненные этого тимлида — люди, а людям свойственно менятся, это динамичные системы, а это значит что под влиянием тех или иных факторов они могут начать педалить лучше, а могут хуже, могут вообще бунт устроить по каким-то политическим мотивам ну и т.п. Так вот КПИ позволяют выявить тенденции. К примеру: дев Вася очень хорошо кодит, но 2 недели наз он разбежался со своей девченкой и у него депресняк. Вполне вероятно, что Вася не настолько сильный человек, чтобы оставлять личное за дверью и педалить также эффективно всегда — вот и получается, что проблемы в личной жизни будут аффектить его работу. А КПИ позволят нам выявить следствия этого: отставание от графика, или увеличившееся число багов, или большее количество переоткрытых багов ну и т.п. И вот эти показатели позволяют нам задуматься — а мож с ним поговорить, узнать чем вызван спад в работе? Расскажет — классно, не расскажет — будем искать обходные пути узнать (черех ХР, других сотрудников ну и т.п.) — это уже другой комплекс мероприятий. Самое главное что мы в РЕАЛЬНОМ времени получили быструю обратную связь. Самая простая аналогия — тахометр в машине. Мы можем очень хорошо знать свю машину, заботиться о ней и все такое, но с помощью тахометра мы можем на ранней стадии определить неполадки в двигле или сопутствующих системах — скажем начали обороты плавать.
nvb>Извини, сейчас жутко занят, поэтому не могу ответить подробно. Если кратко — ты говоришь про систему сбора метрик, называя ее KPI. Но это разные вещи.
KPI — это инструмент измерения поставленных целей.
— это синоним метрик.
nvb>Метрики нужны и очень важны, и они используются и в KPI, но KPI подразумевает (полу)автоматическое принятие решения по метрикам. Это принятие решения возведено в ранг закона, т.е. если Вася из-за девушки снизил производительность, ему надо однозначно резать зарплату.
Все написанное выше (и в том числе выделенное) — не более чем твои домыслы.
nvb>Система же метрик предполагает, что у тебя документированы изменения параметров производительности сотрудников, но ты сам волен принимать решение, и не обязан за него отчитываться.
nvb>Поэтому, если везде в тексте заменить слово KPI на слово "метрики" — соглашусь с тобой почти во всем, кроме того, что нужно стремиться к переводу программиста в разряд легкозаменяемого винтика. Даже не буду объяснять, почему
M>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании.
Это неправильное определение, в расшифровке аббревиатуры нет ни единого упоминания о доходах компании.
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
На предыдущей работе у нас была следующая система
1. Программист (каждый) в начале месяца накидывал себе на месяц в Excel план задач (задача — не менее 2 часов и не более 3 дней) так, чтобы покрыть весь рабочий месяц. Задачи берутся из пула задач. Пул задач формируется менеджером совместно с тимлидом/архитектором. План выглядит как "задача" — "запланированное на задачу время". Отгулы/отпуска точно также записываются в план. Время на планирование/отчётность — тоже.
2. Программист программирует месяц. Задачи делаются, информация о потраченном времени записывается в куда угодно. Да, естественно есть много внезапных задач, они тоже делаются и инфа о них записывается в туда же.
3. В конце месяца программист делает Excel-отчёт, в виде "задача" — "запланированное на задачу время" — "потраченное время" — "скорректированное время". "Скорректированное время" присутствует только там, где потраченное время больше, чем запланированное. По идее, менеджер должен проверить каждый случай превышения времени, и если оно объективно, то скорректированное время устанавливается равным фактически потраченному. На практике это делали сами программисты, а менеджеры, если возникали сомнения, могли повлиять на это время. Неприходы на работу по уважительным причинам также считались как задачи и должны были войти в отчёт.
4. Отчёт, в конце концов, выдавал некую цифру в процентах, для негулявшего и не перерабатывающего сотрудника как правило равнявшуюся 100%. По сути, это получался процент общего рабочего времени, потраченного именно на работу. Это и был KPI.
Плюсы такой системы:
* У программистов всегда есть работа
* Программисты учатся оценивать сроки
* Народ перестаёт мыслить дедлайнами и начинает мыслить "чистым" временем
* Топ-менеджмент мог в любой момент узнать, за что данный конкретный программист получил свои деньги в предыдущем месяце (и обсудить этот вопрос с ПМ, если возникали какие-то вопросы)
Минусы:
* Слишком частые внезапные вызывают частые переключения контекста разработчиков, на что уходит довольно много времени (была идея перейти с месячного цикла на недельный, с мораторием на внезапные задачи до наступления следующей недели — не считая шоустопперов, конечно)
* Очередной менеджер попытался довести процесс до маразма, заставляя разработчиков логировать задачи продолжительностью от 5 минут и заносить всё это в Jira. В результате 60% команды единомоменто ушли из конторы.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
G>KPI — это инструмент измерения поставленных целей.
G> — это синоним метрик.
G>Не надо сливать. КПИ и метрики это одно и то же.
По вашей же ссылки.
KPI — это инструмент измерения поставленных целей. Если показатель, который вы придумали не связан с целью, то есть не образуется исходя из ее содержания, тогда нельзя использовать данный термин.
метрики — это показатель, который не связан ни какой целью.
К примеру, Вася пишет 300 LOC в день. — это просто метрика
A KPI,
Если Вася пишет меньше 300 LOC он бездельник и его надо депримировать
Если Вася пишет больше 500 LOC он крутой програмист, и ему надо премировать.
Здравствуйте, Tourist, Вы писали:
G>>Не надо сливать. КПИ и метрики это одно и то же.
T>По вашей же ссылки.
T>KPI — это инструмент измерения поставленных целей. Если показатель, который вы придумали не связан с целью, то есть не образуется исходя из ее содержания, тогда нельзя использовать данный термин. T>
T>метрики — это показатель, который не связан ни какой целью.
T>К примеру, Вася пишет 300 LOC в день. — это просто метрика
T>A KPI,
T>Если Вася пишет меньше 300 LOC он бездельник и его надо депримировать T>Если Вася пишет больше 500 LOC он крутой програмист, и ему надо премировать.
Нет, Globus прав, по крайней мере, формально, я признаю. Целью не обязательно являются деньги, по определению KPI. Могут быть не менее важные показатели, например, способность программиста к коммуникации. Другое дело, что ее померить сложно — она носит качественный характер, а не количественный.
Кстати, в моем сознании коммуникабельность привязана к деньгам — если программер взял ТЗ и без единого вопроса ушел к себе, а через неделю принес никому не нужный результат — потому что не спрашивал про спорные пункты, а делал на свое усмотрение — наверно, я десять раз подумаю, прежде чем поднимать ему зарплату. И не надо мне про плохое ТЗ говорить.
А если цели нет — зачем тогда нужна метрика? Она же не с неба сваливается, ее надо собирать, интерпретировать, отвлекая ценные ресурсы.
Другое дело, что руководство, которое KPI продавливает, в 9 случаях из 10 интересуют только измеряемые, финансовые параметры. Поэтому обычно KPI в сознании большинства людей (и прошлого меня в том числе связаны с премированием-депремированием.
