Комментарии 12
Ну вы же понимаете, что просто начать мерить метрики и раздавать заслуженных слонов и пи...лей без фактического перезаключения трудового договора не получится.
Очень часто менеджеры пытаются начать рулить задачами - эта приоритетная, эта срочная, а за эту по головке не погладят. Правда при этом забывают, что они не заключали с разрабом SLA - соответственно, говоря что какая-то задача является приоритетной, они не несут никах затрат, кроме движения языком, а разрабу нет никакой экономической выгоды от срочного выполнения такой "приоритетной" задачи.
При использовании продуктовых метрик и kpi, напрямую влияющих на зарплату, да. Но в этой статье речь больше о процессных метриках. Одна из задач менеджмента (мастер, лид, оунер и другие) — как раз расстановка приоритетов для команды в соответствии требованиями бизнеса, которые не постоянны, и это нормально в нашем нестабильном мире.
После того как в ВУЗах насадили все эти метрики качество научных публикаций и в целом преподавания только упало. Вместо того чтобы одну статью писать целый год, люди стали булшит потоком гнать.
Тоже самое с кодом. Так что удачного внедрения всех этих модных метрик!
Мы как раз отметили, что сбор метрик ради метрик — это самая неэффективная трата рабочего времени. Далеко не на всех проектах нужны измерения, например, большинство стартапов вполне справляются и без них. Но если у вас большая команда, а проект сложный и требует качественной доработки, без метрик не обойтись. Иными словами, не получится измерить глубину ямы без метра.
К сожалению, часто на проектах собирают метрики ради метрик. Ну вот взять этот торт с багами. Критических столько процентов, тривиальных - столько .. и что нам это дает.? Даже если сравнить с пирогом предыдущей версии. Стало, скажем, больше критических. То что?
- Ууу-у-у, етить-колотить, разработчики, критических, вон, стало больше!
- Да, насяльнике, босе, стало, да.
- Лучше надо делать!
- Да, лусе, надо, насяльнике.
"Данные которые не приводят к принятию решения не являются информацией."
-- Алекс Портер, "Accelerated Testing and Validation", 2004
Може стоить спросить себя что, блин, не так в приложении, если в нем дохреннилион ошибок? Наверное архитектура паршивая? И что мы делаем чтобы это улучшить? Ведь такое количество багов говорит о какой-то серьезной системной проблеме, которую в упор не хотят решать. Спринт для баголатания. Ну да. Мы же знаем, там где три починили один новый сделали.
Нет, это пахнет акционизмом менеджмента. Нужно показать работу, потому что видимо фунаментальная проблема просто не поддается решению. Например нет такого сильного менеджера который скажет, заказчику "Извини, но тут нужен капремонт. Иначе мы никогда из этого замкнутого круга не вырвемся"
А так, это как измерятъ г-но линейкой:
"О, глядите, какую мы какахху выкатилии в этот раз! Она аж на три сантиметра длиннее предыдущей. А увесистая какая! И с пятнышками. Раньше пятнышек вроде не было, да? Надо разобраться откуда пятнышки... "
Соглашусь с предыдущими ораторами. В целом плохо представляю ситуацию, когда команда сама не знает из-за чего у нее проблемы, чтобы еще зачем-то собирать метрики, которые в разных спринтах будут показывать диаметрально противоположные данные.
Отличная статья.
Вижу, что у ораторов выше все живут в мире, где очень осознанные люди, которые держат процессы команды в фокусе, а не заняты своими задачами. И команды все маленькие и все внутри команды понимают, что происходит и как сделать лучше и есть время в этом разбираться и копаться. И изменения такие, что не +/- пару процентов, а уменьшение ттм в пять раз, например.
Что ж, есть несколько человек, которые живут в другом мире и там метрики - полезное дело.
---
Я бы отметил, что метрики еще отлично подходят для ситуации, когда есть один процесс, который меняется на другой. И в процессе изменений надо не просыпать всякое, а в идеале что-нибудь даже улучшить. Тут без сбора метрик справиться довольно сложно, если конечно хочется иметь аргументированную позицию, а не "пальцем в небо"
К автору статьи есть пара вопросов:
1) по накладным расходам - откуда взять данные по которым строить метрики? Как будто бы перечисленные проблемы это больше ручной сбор, причем с постоянно меняющимся наполнением. Это как раз и основная причина, по которой метрику и не считают. Все автоматизированные вещи на этот счет - вызывают дикий баттхерт и заслужено - это всякие скриношты экранов или отметки сколько времени потрачено на задачу и т.д. Возможно есть какой-то разумный вариант, поделитесь?
2) про доказательный дизайн и его метрики есть что-то более подробное почитать, поделитесь ссылочкой, пожалуйста.
Спасибо за отклик!
1. К теме о накладных расходах — можно использовать возможности трекера. Например, создать команде задачу «созвоны»/«простои»/«прочее» и разрешить списывать туда реально потраченное на это время без дальнейших санкций (допустим, если выяснится, что четверть рабочих часов действительно утекает). В ручном режиме сбор таких данных подойдет на небольшом отрезке времени в одну неделю или один спринт и для небольшой команды до 5 человек.
2. Про доказательный дизайн можно почитать, например, тут.
Так ведь списывание часов - это и есть ручное внесение информации. Это как раз тот случай, когда "составлял отчет по дню - 30минут", которое всех и раздражает.
Ссылка кажется не очень показательной. Там весь доказательный дизайн сводится к тому, что изучили конкурентов и сделали так же. Где там метрики упоминаемые у вас в статье и работа с ними, я не увидел
Так ведь списывание часов - это и есть ручное внесение информации. Это как раз тот случай, когда "составлял отчет по дню - 30минут", которое всех и раздражает.
Есть задачи со сменой статуса в трекере, где отслеживается, когда специалист приступает к выполнению работы. Эти задачи ничем не отличаются от задач на разработку — фиксация времени тоже происходит в автоматическом режиме (сколько задача была «в работе» — 2 клика). Если фиксировать 2-х минутные промежутки времени и текстом описывать комментарии, то данный процесс займет гораздо больше 30 минут.
Ссылка кажется не очень показательной. Там весь доказательный дизайн сводится к тому, что изучили конкурентов и сделали так же. Где там метрики упоминаемые у вас в статье и работа с ними, я не увидел
В статье приведены метрики для примера, как они могут использоваться =) Звучит банально, но это действительно так: набор метрик доказательного дизайна для каждого проекта свой, какие именно будут метрики зависит от целей и задач конкретного приложения. Мы передадим нашим дизайнерам идею написать статью по этой теме =)
Типичная ситуация - взял задачу в работу, делать задачу пару дней, за эти пару дней, помимо задачи - два дейли, ретро, грумминг, митинг, проведение собеседования, 1-2-1 и плюс отвлечься проверить фикс бага.
Я вижу такие варианты как это можно обойти в данном контексте:
Разбивать задачи на супер маленькие, типа на час-два. Почти всегда нереалистично и/или требует кучи времени
Не отвлекаясь делать одну задачу. Если она на пару дней - тоже малореалистично
Каждый раз менять задаче статус, что ты ей не занимаешься. Или как-то иначе отмечать сколько времени потрачено. Как раз то о чем я выше пишу.
Какие у вас варианты в таком случае, как вы поймете, что слишком уж дофига встреч на тестере, например?
По-разному. Может поменяться статус задач — останавливается одна и включается другая (два клика), о чем и писали выше. Или в работе может быть более одной задачи одновременно: например, на разработку — большая, на пару дней, а вместе с ней одновременно задача «прочее» на съедальщиков рабочего времени. В этом случае часы второй задачи надо исключить из биллинга, здесь вопрос настроек трекера.
Когда метрики тестирования бесполезны