Главный разработчик в Альфа-Банк
· 17.03Вопрос
Что вы думаете о метриках для оценки работы разработчиков? Что если есть только 1 сводная метрика "вклада в проект", которая просто есть, но неизвестно как и на основе чего она считается?
7 комментов
· 17.03
Метрики ни к чему хорошему не приведут. Если человек активно вовлекается в проект, делает задачи, то он будет только в лишний раз отвлекаться на метрики всякие по типу, а достаточно ли он коммитов сделал, а достаточно ли он задач закрыл (что приведёт к избыточной декомпозиции ради декомпозиции). Если человек не вовлекается, работает без особого рвения, то он будет стараться просто формально следовать метрикам, а по факту пользы будет мало.
Если же метрика непонятно как считается, это ещё хуже: активный сотрудник будет всё время стрессовать, потому как не знает, оценит ли какая-то там метрика его старания по существу. А вот человек без рвения просто рано или поздно найдёт закономерность, так как число переменных в этой истории вполне конечно, и продолжит делать минимум.
На самом деле и без метрик видно, кто работает, а кто тянет резину. Это чувствуется по интонации в голосе, по уровню инициативы, по тому, как он участвует в мозговых штурмах (насколько активно предлагает свои и/или комментирует другие идеи). И тут не наказывать надо, а разбираться, почему человек не горит желанием делать задачи. Может, он не понимает ценность проекта, может, он не умеет отдыхать, и надо научить его эффективно отдыхать, чтоб он восстановливался и приходил на работу с новыми силами, или задачи кажутся ему плохо описанными, и истинная проблема в бизнес-аналитике или другом человеке, который задачи заводит.
Помню, у меня на проекте был отличный аналитик, все задачи понятные, декомпозированные, у меня мотивация их делать была невероятная. А потом пришёл другой, описывал намного хуже, нужно было уточнять по сто раз, устраивать созвоны по каждому поводу, и вот тогда моя мотивация умножилась на ноль. Если бы при этом ещё какие-то метрики непрозрачные были, это бы вообще добило
0
ответить
коммент удалён
· 17.03
Если метрики отражают конкретные показатели или результаты, то это не плохо.
Тем, кто делает руками всегда видно, кто на самом деле работает, а кто нет. А вот руководству это не всегда бывает понятно, особенно в коллективе, где все друг другу помогают и прикрывают.
Вот тут и становятся нужны метрики. Количество багов, среднее время закрытия задач (причем не время а его интерполяция на общее значение) и тд. Эти показатели помогают руководителю просто чуть лучше видеть реальную обстановку.
Метрики никогда не должны быть показателем "кто плохо работает" или "кого выгнать". Это показатель - кому и как надо помочь стать лучше. Или на кого надо обратить внимание, что бы его сильнее развивать.
К сожалению, мало, какие руководители это понимают и используют их именно как "кто плохой"
0
ответить
ответ удалён
· 17.03
Вы точно главный разработчик в альфа банке?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 17.03
Странный вопрос. Да)
С точки зрения руководства я знаю зачем нужны метрики, как они работают и как на них смотреть. И метрики должны быть прозрачными и понятными, должны с разных сторон давать оценку работы.
А если метрика одна? И даже руководство говорит "мы сами не знаем как она работает". Как в этом случае реагировать тем, кого оценивают? Как понять на основе каких действий тебе скажут, что ты плохо или хорошо работаешь?
"Вклад в проект" самое размытое понятие из всех, что я встречал, если честно) А самое интересное, что эта же метрика направлена и на аналитиков(возможно внутри она для них как-то по-другому считается).
Непонимание того, как работает оценка "тебя", просто приводит к нервозу в коллективе.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 17.03
Так ладно. Исключительно из за теплого отношения к альфе и цеховой солидарности. Ты owner, я правильно понимаю?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 17.03
Нет, я сейчас именно разработчик
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 17.03
Ясно. -если идея ввести кпи продиктована необходимостью обосновать повышение гонорара команды, потому что иначе не поднимают-дурной знак. Скорее всего дело в том, что ищется повод отказать. Если все же хочешь пободаться-дроби задачи на мелкие таски и вводи lead и cycle time-будет низкий, это гуд, velocity-самый скам, будет тоже хорошо. Баги на продакшене-тащи в регрессионные тесты, говори что фиксили, чини многократно. Code coverage-обсуждай с qa, вы же на микросервисах, между собой решите. Техдолг-все время выписывай легаси в рефакторинг, считай за новый код. Аптайм, краш и респонс-сыпь запросами, дели время. Все сказанное выше-не по гусарски, но если с вами себя ведут подло-вот ответ.
-если тебе реально нужно осознать, кто и как, имхо, bus factor. В покере планирования со всеми разыграй не знаю, да блин простт нормально поговорите-адеуватные же люди. Поймешь кто нужен и кто тащит. Потому что пытаться мощного сеньора помидора в эти вот циферки засунуть-себе вредить. Он там не для того, понимать надо.
-если внутри команды кто то жалуется-сначала сам, не вышло-тащи его к овнеру. Решайте но совместно. Это конечно если овнер сам не автор идеи душить по деньгам. И если он там не для мебели.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён