Цитата недели




Подразделение оценивается по самому слабому сотруднику

Шпаргалки для боссов. Тимур Горяев




понедельник, 5 ноября 2012 г.

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


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 митинге.  

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

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


8 комментариев:

  1. Привет!

    1) Я так понимаю, что идут цитаты из моей статьи? Вот этой: http://software-testing.ru/library/around-testing/management/1716-2012-08-29-06-50-14
    Сразу бы ссылку, было бы понятнее :)

    2) Я, как автор статьи, из которой отобраны цитаты, всецело согласна с приведёнными тобой метриками, которые ты считаешь важными и полезными. Даже готова ещё один линк привести, на свой доклад про метрики в тестировании: http://software-testing.ru/library/around-testing/management/1494-confetqa-rukol

    3) Тогда очевидно возникает вопрос: в чём несоответствие? В том, что я считаю НЕОБХОДИМЫМ оценивать и измерять тестирование, и что я считаю БЕСПОЛЕЗНЫМ и даже ВРЕДНЫМ измерять работу отдельно взятых тестировщиков.

    Ты приводишь метрики оценки тестирования: сколько времени на него нужно, к примеру. Согласна, это необходимая и полезная метрика. А вот мерить тестировщиков циферками - нельзя, потому что ... см. список причин в статье.

    ОтветитьУдалить
  2. Не Не Наташ, мой пойнт именно в том, что мерять тестировщиков равно как и процесс тестирования можно и нужно, но выводы должны следовать не те что конкретный тестировщик в чем то виноват, а в первую очередь нужно проверять почему сама система позволила конкретному тестировщику работать именно вот так вот. Не получилось видно мысль раскрыть ))) Нужно было еще недельку поколдовать над заметкой

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

    Измерять и оценивать нужно, но вот проводить аттестацию, основываясь тупо на них - это конечно разрушение команды

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

    Еше раз упомяну книгу Деминга - Выход из кризиса. Книга потрясающая своими примерами и тем как системные проблемы "решают" за счет сотрудников.

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

    ОтветитьУдалить
  3. Только проблема с метриками в том, что они некая абстракция, что бы успешно пользоваться которой, нужно понимать, что на самом деле происходит в проекте. А то «циферки» имеют тенденцию подниматься в иерархии отчетов, по пути теряя свой контекст. В результате принимаются неожиданные обобщающие выводы, например о том, сколько еще критических багов должна открыть сферическая команда тестировщиков, что бы повысить свой KPI до среднепроектного. Так что я за метрики только вместе с контекстом.

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

    Как не измеряя ничего понять хорошо или плохо ты нынче прокатился на велосипеде?
    Я думаю это вполне реальная задача. Тем более что г-н Деминг справедливо утверждает, что от силы 3% критичных вещей можно измерить. Я не могу измерить опыт и обучение специалиста. Я не могу измерить качество (формулы Рекса Блека для измерения качества это высасывание из пальца). Это вещи, которые объективно не оцифровываются.
    Так что говорить, что совсем без численных показателей никак нельзя - несколько несправедливо. Можно. Стоит ли отказываться от численных данных? Нет, это удобный инструмент, если умеючи. Увы, правда, большинство не имеет даже базового понимания о том как работать с численными данными. Гигиену при работе с цифрами не соблюдают-с. Элементарнейших знаний в статистике тоже как правило нет.

    ОтветитьУдалить
  5. Саш, а можно тогда примеры неабстрактных метрик, которые полезны при оценке тестировщиков?

    А то ты говоришь "они полезны", а сам ни одного их примера не привёл - нелогично :)

    ОтветитьУдалить
  6. Наташа, обраточка - в твоей статье тоже не указаны плохие метрики.

    На самом деле те метрики, которые описаны в заметке я применяю для оценки производительности тестировщиков.

    1. Прогон регрессионного пака. Есть понимание сколько стоит прогон - по времени, и есть понимание - сколько каждый тестировщик тратит времени. Даже пример специально привел.

    2. Сколько времени тратиться на тестировние и не тестирование. Очень хорошо показывает сколько куда отдельные тестировщики тратят времени. Например новички - тратят много времени на коммуникации и исследование, матерые тестировщики - часто сидят на суппорте и подготовке тестовых стендов

    3.Оценка работы и реальное время потраченное на работу показывает насколько правдиво тестировщики могут прогнозировать работу

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

    Все метрики не только проектные суммарные но и для конкретных тестировщиков. Сосбна об этом и заметка.

    Не убедил?

    ОтветитьУдалить
  7. Thanks for the article, excellent stuff.
    You can get info on Web Testing as well with some guidelines with different way of thinking.

    ОтветитьУдалить