Информация

Дата основания
Местоположение
Россия
Сайт
dodo.dev
Численность
101–200 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 5
Я бы добавил чуть ли не нулевой пункт — избегайте «законов льва» (если лев устанавливает законы, то он будет есть всех абсолютно легально). Необходимо очень четко понимать, кем и в чьих интересах создаются метрики и любые способы оценивания.

Условно, если на абстрактный проект наняли тупых или слабых разработчиков, то все метрики, придуманные ими, будут показывать приемлемую динамику или просто будут нормально (или хорошо, зависит от наглости) выглядеть. Если команда, которой заплатили за разработку качественного продукта, постоянно допускает большой технический долг, то будет ли она создавать метрики и методы оценки проблем, которые скажут, что она не справляется? А если от метрик зависит повышение/зарплата/премии? То у всех все хорошо, вот только пришлось тратить миллионы на доработку готового продукта, за который программистам уже заплатили.
Да, вы правы, это важное замечание. Необходимо понимать кто и зачем создает метрики.
Мы создавали метрики не для того, чтобы кого-то наказывать или кому-то показывать что у нас все хорошо. Мы действительно хотим создавать качественный продукт и поэтому решили это качество измерять.
Это довольно неплохо. Единственное, что я бы добавил, что стоит понимать, кто именно «мы». Это можете быть конкретно вы, часть команды, команда, несколько команд или произвольный набор людей. Приходилось сталкиваться с ситуациями, когда кто-то действительно хочет сделать достойный продукт, вокруг ему поддакивают, но в реальности хотят легкую премию и индексацию зарплаты.
Инициаторами введения метрик во всех продуктах и публичное их отображение были руководители it-направления в компании. Я был полностью за, так как мы некоторые показатели в монолите уже замеряли и следующим шагом логично было бы собирать их не только в монолите, но и в других сервисах тоже.
А начали собирать метрики в монолите тестировщики и разработчики, без чьих-либо указаний, больше года назад.
Метрики нужны, чтобы не понимающий ничего в разработке менеджер мог, по его мнению, контролировать тех, кто делает работу. Инвесторов и их приказчиков-менеджеров бесит одна только мысль о том, что они не могут лично контролировать процесс переноса стоимости рабочей силы сотрудников в личную прибыль владельца производственных мощностей или личного знакомста с купленным заказчиком (чиновником). Отсюда и потребности в неких формальных метриках.
Хотя вполне достаточно иметь конкретные сроки выполнения, постановку задачи и хорошо поставленное тестирование. И всё! Но… сам процесс тогда останется невидимым, непонятным и раздражающим владельца капиталов (непонятно откуда взятых — это тоже есть великая тайна, непонятная работникам. И, кстати, без всякой надежды покрыть её метриками).
Собственно, сам agile и прибыл, чтобы получше выбрать «пустые» потери на отдых и размышления, выжать побольше прибыли. Ни для чего другого он не предназначен, по сути.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.