Неабстрактный менеджер в защиту метрик

Lesson 198. There’s nothing more dangerous than a vice-president with statistics
Lesson Learn in Software Testing

Постоянно сталкиваюсь с крайностями мнений об оценке работы тестировщиков. В одних случаях руководители отслеживают все - вплоть до времени проведенного за компьютером и возле кофейной машины, другие - не отслеживают ничего, объясняя, что люди и так хорошо работают.

Одна из последних прочитанных заметок в очередной раз напомнила о проблеме (прям цитирую):

Истина проста: метрики для оценки сотрудников внедряются в ситуациях, когда у руководства есть проблемы с управлением

Это не так. Или - не всегда так. Я учитывал и вводил метрики для оценки производительности своих подчиненных не когда  были проблемы, а для того чтобы проблем не было. 

Отношу себя  категории людей, которые считают, что считать лучше чем не считать. И как вы поняли, сегодня хочу поворчать на тему - почему оценивать производительность сотрудников при помощи метрик нужно и полезно. 

Почему у меня встает вопрос о метриках

Я не параноик, но следить за командой и тем более собой нужно. И мне не понятно - как менеджеры не измеряющие производительность команды, могут утверждать, что команда работает хорошо\плохо\хоть как-нибудь? То же самое - об отдельных  тестировщиках.

У меня всегда встает (гусары молчать!) вопрос о метриках производительности когда я хочу:

понимать скорость своей команды и каждого отдельного тестировщика

это нужно чтобы

знать когда предположительно может закончиться цикл тестирования

чтобы

иметь цифры на руках, которые подтвердят мой ответ успеваем мы или нет и какие у нас риски

Ранее я уже ссылался на свой опыт использования метрик и по прежнему считаю, что зная производительность каждого своего сотрудника, оценив объем работ, заложив исторически подтвержденные риски легче понять сможем ли мы вот этот данный конкретный кусок работы закончить к данному ограниченному указанному сроку с текущим составом команды. 

Это нормальная постоянная забота менеджера - считать, прогнозировать, учитывать, расспрашивать, выпытывать информацию, наконец. Тест менеджер не может контролировать многие ситуации - но он может попытаться к ним подготовиться, и он, на самом деле, обязан к ним готовиться. Ухудшения равно как и улучшения качества работы невозможно заметить если не опираться на те же самые метрики.

Сторонники числового измерения результатов в этом месте спрашивают:

Если ты не можешь отвести пять минут своего времени в день на анализ - что ты или команда делали, как делали и насколько хорошо делали - можно ли говорить что вы весь день делали все правильно? А если неделя? А если месяц?.. А если жизнь? 

Про жизнь я конечно замахнулся, но вдруг?

Проблема в системе

На самом деле я придерживаюсь мнения, что плохие показатели - это, в большинстве своем, сигналы о проблемах в системе, а не о работе отдельного специалиста. Но бывают и случаи, когда приходится отстреливать хромых разработчиков, тестировщиков или менеджеров. Но чаще проблемы именно в системе (хотя по моему скромному ИМХО найм неподходящего сотрудника - это тоже проблема системы подбора персонала).

Есть замечательная книга "Выход из Кризиса" Эдварда Деминга. Всем начинающим (равно как и опытным) менеджерам советовал бы ее прочесть. Очень много примеров, когда именно система, именно процессы являлись  узким местом. Там же показывается, что подход если-рабочие-будут-стараться-то-проблем-не-будет - разрушительный или даже самоубийственный подход.И кстати там  есть очень замечательная фраза про улучшение показателей и метрик.

Если вы в состоянии повысить производительность или объем продаж, или качество, или что-нибудь еще, например, на 5% в будущем году, не имея разумного плана улучшений, то почему вы не занимались этим в прошлом году?

Очень емкая фраза. В одной из компаний, в которой я имел счастье работать от очень высшего руководства спускались цели типа "Уменьшить количество багов  severity 1/2 на 50 %".

Это я к тому, что лозунги про улучшение показателей - самый худший способ улучшать показатели системы.

 ТОП метрик от неабстрактного тест менеджера Селяева

Я не могу ссылаться на абстрактные метрики производительности команды тестирования и обязан привести свой топ метрик, которые считаю в настоящий момент для моей текущей команды важными.

Сколько времени требуется на прогон регрессионного пака: одного теста, набора, критического набора, смок теста.

Эта метрика позволяет оценить сколько идеально мы можем потратить на один цикл тестирования.. Сравнивая с цифрой сколько мы реально прогнали получается дельта, которую мы обязаны с каждым циклом уменьшать до нуля. А идеально еще и в минус уйти (автоматизация, пересмотр приоритетов сценариев, кросстестирование).

У меня в практике был случай когда один и тот же кусок работы делался всей командой кроме одного сотрудника за день, он же тратил - два. Не один раз. Постоянно. При ближайшем рассмотрении выяснилось что он много "курит" и много разговаривает по телефону. Причем человек работал 9 часов. Ровно 9 часов на работе - потом домой. Были беседы. Были договоренности, но человек предпочел уйти, а не перестать работать в своем "телефонно-перекурном" режиме. Кстати как технический специалист - очень и очень неплох. Это один из тех случаев, когда работа и сотрудник не подошли друг к другу.

Сколько времени мы потратили на тестирование и сколько времени мы потратили не на тестирование (документирование, поддержка тестового стенда, митинги пр) в последнем релизе.

Тестирование (прогон тестов и исследование продукта) в идеале должна быть единственная основная активность. Настройка тестового стенда, митинги, исследование нештатных ситуаций - это активности время потраченное на которые должно стремиться опять же к нулю.

В одном из моих проектов время простоя  из-за нестабильного тестового стенда (причем не нашего проекта, а следующего за нами), доходило до катастрофических  60%. Мы на своей стороне боролись с потерями как могли. Тестировали с заглушками, потом прогоняли смок тесты на интеграцию. Тестировали области, которые можно было тестировать без интеграции. Несколько релизов подряд мы жили в постоянном цейтноте. Человека из другой команды, который не решал нашу проблему попросили уйти. Пришел другой человек. Потери времени упали до 2% в релиз. Это второй случай, когда специалисты действительно не хотели решать проблемы.

Казалось бы стабильность тестового стенда -так себе метрика, но показывает отношение к работе.

Количество дней для решения задачи 

В моей текущей команде задачи на автоматизацию и на тестирование производительности могут поступать не только для конкретного релиза, но и сами по себе "когда будут автоматизированы/протестированы тогда и поступят в релиз". Странная система для некритичных задач, но она есть и мне нужно научиться их решать. Зная сколько требуется времени на тестирование отдельной задачи можно набирать кусок работы на мезсезонье - время между релизами.

Количество багов закрытых разработчиками как не баги

Это еще одна головная боль. Очень болезненная. Половина регрессионных багов закрывается как не баги.

Проблемы и в сложной системе и в неподготовленности = молодости тестировщиков, и сам процесс хромает, поскольку  релиз готовиться несколько месяцев, а регрессионное тестирование начинается за несколько недель до релиза...

Короче - есть где развернутся любителю улучшать процессы и ликвидировать узкие места.

Нужно ли использовать метрики всегда?

Мой ответ на этот вопрос - нет. Не всегда. Одни и те же метрики в разных проектах могут иметь разный приоритет, и даже необходимость их иметь (гусары - в сад!).

Метрика это один из способов упростить окружающий мир. В нашем случае упростить понимание того как эффективно работает команда тестирования.

Для проектов стадии стартапа, метрики оценки трудоемкости - не совсем критичны. Критичны сроки. Для случаев стартапов важно выполнить задел, поставить разработку продукта на промышленные рельсы. Но опять же в условиях стартапов планировать сложно, но возможно.

Если вспоминать аджайл вещи: меряя в попугаях, команды ищут свою производительность и "одинаковость" историй. 

В заключение - об искренности, профессиях и опять же метриках

Еще одна цитата из упоминаемой ранее заметки:

Ваши циферки не нужны ни тестировщикам, ни сотрудникам из смежных отделов. Ваши сотрудники хотят искреннего общения, а ваши коллеги (разработчики, Рмы) – заинтересованности в общих проектных результатах. И если кто-то просит циферки – значит, просто не хватает правильного общения!

Ох если бы это было всегда правдой, уважаемый ты мой коллега-автор. Если бы всегда было все так просто.

Один из самых частых вопросов которые я слышал к команде тестировщиков: Сколько вам потребуется времени на тестирование? или Когда вы закончите?

А следующий вопрос был, как правило: Почему вам требуется столько времени на тестирование?

Вот они самые циферки, вот они ненаглядные.

Искренность это интересный способ руководства, но кроме искренности нужно еще и уметь ставить задачи - кому разжевано и последовательно, кому в виде проблемы. Потому что качество продукта не меряется оживленными беседами за кружкой чая и тем более не измеряется тем как мы хорошо поболтали на нашем one-to-one митинге.  

Хорошие отношения с сотрудниками не означает хорошего качества продукта. 

Цели измеримые, достижимые и конкретные нужно ставить и привязаны они должны быть к работе, улучшению процессов и достижению конечных результатов  например - уменьшению багов в проде. Другое дело устанавливая цель уменьшить количество багов в проде нужно закладывать еще и понимание как это делать.