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

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

>> Кто работает, а кто болтом груши околачивает.

Вот с этим не согласен. Нельзя сравнивать людей по метрикам; практика показывает, что как только метрика ИЗ инструмента оценки проекта превращается в инструмент оценки людей, то начинается цирк. И клоуны.
Еще неправильнее показывать эту статистику product owner-у или hr-у — те сразу начинают лезть не в свое дело: давайте команду реорганизуем, давайте ему зарплату снизим, давайте его уволим а наймем более эффективного. Нет смысла пояснять, что всем меры неэффективные — снижение зарплаты ударит по производительности еще сильнее, а после замены человека начнут искать следующего самого слабого: не команда, а территория с естественным отбором. Это очень плохо влияет на мотивацию людей -> сроки проекта.

Сравнивать следует только человека с самим собой на разных промежутках времени; и то, это показывает не причину — (раз «болтом по грушам», значит мудак), а следствие — раз стал работать менее эффективно, значит, что-то мешает.

>> руководство проекта знает о происходящем
Тут не очень ясно, кого вы имеете в виду под руководством. Если pm и выше (ближе к заказчику) — то имхо ему достаточно выдавать 3-4 общих интегральных показателя, характеризующих прогресс по продукту + 3-4 специфических для предметной области — размер БД, или скокрострельность на тестах и т.п. На уровне проджект-лида и тех-лида следует, конечно, оперировать более полной собранной информацией; тут и KLOC не будет лишним ни в коем случае.

С остальным согласен :)
Спасибо за реакцию :) хоть кому-то интересны эти вещи :)
По порядку:

Насчет «болтом груши» — тут ключевые слова "*кто чем насколько сильно* занят". Т.е. не кто сколько сделал, а какова загруженность на текущий момент. Нет смысла назначать задачу на того, у кого этих задач вагон и маленькая тележка.
Разумеется, мерять коллектив только на том основаниии, сколько кто багов пофиксал — не совсем верно, надо учитыать ещё прорвау факторов. На предыдущем месте работы у нас собиралось довольно много метрик, но премиальные считались всё равно по субъективным факторам. Сделать это было не так сложно потому, что премии считали сначала руковдители групп — и выдавали менеджменту коэффициенты участия члена команды. Этот коэффициент трудового участия (КТУ) уже определял долю конкретного еловека в общем премиальном фонде.

Поэтому метрики по задачам важны в первую очередь для оперативного управления.

Далее, насчет руководства. Совершенно согласен — разный уровень менеджмента интересуется разными показателями — и чем выше, тем «интегральнее». А в сумме получается — одному пара метрик, другому 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/). В большинстве статей готов поставить свою подпись — со многим согласен.
Большое спасибо, буду изучать
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.