Комментарии 8
>> Кто работает, а кто болтом груши околачивает.
Вот с этим не согласен. Нельзя сравнивать людей по метрикам; практика показывает, что как только метрика ИЗ инструмента оценки проекта превращается в инструмент оценки людей, то начинается цирк. И клоуны.
Еще неправильнее показывать эту статистику product owner-у или hr-у — те сразу начинают лезть не в свое дело: давайте команду реорганизуем, давайте ему зарплату снизим, давайте его уволим а наймем более эффективного. Нет смысла пояснять, что всем меры неэффективные — снижение зарплаты ударит по производительности еще сильнее, а после замены человека начнут искать следующего самого слабого: не команда, а территория с естественным отбором. Это очень плохо влияет на мотивацию людей -> сроки проекта.
Сравнивать следует только человека с самим собой на разных промежутках времени; и то, это показывает не причину — (раз «болтом по грушам», значит мудак), а следствие — раз стал работать менее эффективно, значит, что-то мешает.
>> руководство проекта знает о происходящем
Тут не очень ясно, кого вы имеете в виду под руководством. Если pm и выше (ближе к заказчику) — то имхо ему достаточно выдавать 3-4 общих интегральных показателя, характеризующих прогресс по продукту + 3-4 специфических для предметной области — размер БД, или скокрострельность на тестах и т.п. На уровне проджект-лида и тех-лида следует, конечно, оперировать более полной собранной информацией; тут и KLOC не будет лишним ни в коем случае.
С остальным согласен :)
Вот с этим не согласен. Нельзя сравнивать людей по метрикам; практика показывает, что как только метрика ИЗ инструмента оценки проекта превращается в инструмент оценки людей, то начинается цирк. И клоуны.
Еще неправильнее показывать эту статистику product owner-у или hr-у — те сразу начинают лезть не в свое дело: давайте команду реорганизуем, давайте ему зарплату снизим, давайте его уволим а наймем более эффективного. Нет смысла пояснять, что всем меры неэффективные — снижение зарплаты ударит по производительности еще сильнее, а после замены человека начнут искать следующего самого слабого: не команда, а территория с естественным отбором. Это очень плохо влияет на мотивацию людей -> сроки проекта.
Сравнивать следует только человека с самим собой на разных промежутках времени; и то, это показывает не причину — (раз «болтом по грушам», значит мудак), а следствие — раз стал работать менее эффективно, значит, что-то мешает.
>> руководство проекта знает о происходящем
Тут не очень ясно, кого вы имеете в виду под руководством. Если pm и выше (ближе к заказчику) — то имхо ему достаточно выдавать 3-4 общих интегральных показателя, характеризующих прогресс по продукту + 3-4 специфических для предметной области — размер БД, или скокрострельность на тестах и т.п. На уровне проджект-лида и тех-лида следует, конечно, оперировать более полной собранной информацией; тут и KLOC не будет лишним ни в коем случае.
С остальным согласен :)
Спасибо за реакцию :) хоть кому-то интересны эти вещи :)
По порядку:
Насчет «болтом груши» — тут ключевые слова "*кто чем насколько сильно* занят". Т.е. не кто сколько сделал, а какова загруженность на текущий момент. Нет смысла назначать задачу на того, у кого этих задач вагон и маленькая тележка.
Разумеется, мерять коллектив только на том основаниии, сколько кто багов пофиксал — не совсем верно, надо учитыать ещё прорвау факторов. На предыдущем месте работы у нас собиралось довольно много метрик, но премиальные считались всё равно по субъективным факторам. Сделать это было не так сложно потому, что премии считали сначала руковдители групп — и выдавали менеджменту коэффициенты участия члена команды. Этот коэффициент трудового участия (КТУ) уже определял долю конкретного еловека в общем премиальном фонде.
Поэтому метрики по задачам важны в первую очередь для оперативного управления.
Далее, насчет руководства. Совершенно согласен — разный уровень менеджмента интересуется разными показателями — и чем выше, тем «интегральнее». А в сумме получается — одному пара метрик, другому 3-4 метрики — так и выходит, что для полноты картины на конечных «сборщиках метрик» ложится задача собрать сдесяток разнообразных метрик.
Об этом и заметка :)
По порядку:
Насчет «болтом груши» — тут ключевые слова "*кто чем насколько сильно* занят". Т.е. не кто сколько сделал, а какова загруженность на текущий момент. Нет смысла назначать задачу на того, у кого этих задач вагон и маленькая тележка.
Разумеется, мерять коллектив только на том основаниии, сколько кто багов пофиксал — не совсем верно, надо учитыать ещё прорвау факторов. На предыдущем месте работы у нас собиралось довольно много метрик, но премиальные считались всё равно по субъективным факторам. Сделать это было не так сложно потому, что премии считали сначала руковдители групп — и выдавали менеджменту коэффициенты участия члена команды. Этот коэффициент трудового участия (КТУ) уже определял долю конкретного еловека в общем премиальном фонде.
Поэтому метрики по задачам важны в первую очередь для оперативного управления.
Далее, насчет руководства. Совершенно согласен — разный уровень менеджмента интересуется разными показателями — и чем выше, тем «интегральнее». А в сумме получается — одному пара метрик, другому 3-4 метрики — так и выходит, что для полноты картины на конечных «сборщиках метрик» ложится задача собрать сдесяток разнообразных метрик.
Об этом и заметка :)
Ну а что с продолжением то?
Был материал по распределенным системам контроля… Однако пока готовил остальные материалы — появились новые мысли.
В общем, в процессе :)
В общем, в процессе :)
Спасибо, будем ждать. Собственно по DVCS и хотелось бы почитать.
Советую прочитать вот эти статьи
lib.custis.ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8_%D0%BE_Subversion
Прямо с первой — про риски распределенного контроля версий. :)
Статьи — от камрада belonesox (http://belonesox.habrahabr.ru/). В большинстве статей готов поставить свою подпись — со многим согласен.
lib.custis.ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8_%D0%BE_Subversion
Прямо с первой — про риски распределенного контроля версий. :)
Статьи — от камрада belonesox (http://belonesox.habrahabr.ru/). В большинстве статей готов поставить свою подпись — со многим согласен.
Ссылка чуть побилась… Начни с этой
lib.custis.ru/index.php/The_Risks_of_Distributed_Version_Control
и дальше иди в категорию «Статьи о Subversion».
lib.custis.ru/index.php/The_Risks_of_Distributed_Version_Control
и дальше иди в категорию «Статьи о Subversion».
Большое спасибо, буду изучать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Software Configuration Management // Метрики и документация