вторник, 21 июня 2016 г.

О менеджерах, тестировщиках и их отношениях

Текст моего выступления на внутренней конференции в Контуре.

О менеджерах и тестировщиках.
Ссылка на презентацию

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

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

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

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

Итак, конфликт.

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

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

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

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

Я работаю в рамках модели, которую я для себя сформулировал и сейчас попытаюсь поделиться ею с вами.

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

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

Чего хочет менеджер:
Отсутствия сюрпризов как минимум и попасть в окно качества как норма. Что может - отложить и подвигать окно качества.

В рамках этой модели первое что должен сделать тестировщик на новом проекте - отрастить себе линейку - научиться искать баги в проекте.

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

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

Кто работал в проекте с более чем 100 открытых багов?
У кого их сейчас болше 100?
200?
300?

Теперь помните я вас спрашивал про количество открытых багов и сходимость?

Открываю тайну. У нас с вами не космос, а крайне терпимые к дефектам продукты. В них полно багов и мы принципиально не хотим их исправлять. Менеджеры это отлично понимают. 
У каждого есть коридор и именно в него надо попасть. Лучше - не надо. Лучше - плохо.
У каждого тестера в истории есть отрицательная сходимость дефектов и сотни незакрытых багов. Это признак overskill тестера. Ему бы в космическую отрасль, а он у нас и не понимает, что лучше чем коридор качества менеджера - не нужно.

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

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

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

Менеджеры. Тестировать реально можно до поставки фичи на стенд. Узнать, что фича работает хорошо можно до написания кода. Есть способы. А еще тестить можно в два раза быстрей, чем через полгода после найма. Смело требуйте. Способы и техники не ваша головная боль.
Тестеры. Будьте готовы. Быстро работать руками - не поможет. Придется работать головой.
Это сложнее, на это тратится примерно один-два тестерских года.

Как это ни странно, но и здесь у менеджеров есть потолок желаний.
Чаще, чем раз в день информация уже не нужна, как правило.

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

Что дальше?
И вот тут я серьезно ошибся.
Я планировал выйти весь в белом и рассказать менеджерам ПРАВДУ о том, что нужно делать с двухгодовалыми тестерами с кризисом среднего опыта. Это когда руководитель уже не знает, куда расти этим людям и придумывает всякую фигню. То есть начинает платить за то, что человек не уходит на другую работу.

Я предположил, что в рамках этой модели следующим этапом развития является время и рост тестировщика заключается во времени. Это же самое ценное. релиз, фича, выпустить, поставить, выпнуть из процесса разработки. Уменьшить запасы. Быстрей. Уменьшить вот эти вот области. Время можно обменять на все и мало что можно обменять на время.

Мы у себя в проекте и даже биллинг запустили на несколько месяцев подсчет. Сколько времени мы тратим.
Выводы.
Эти потери можно уменьшить? Да. Можно из 20 дней сделать 8? Да. Смогут тестеры уменьшить 20 до 8? Нет. А до 16? Вполне.

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


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

Желание есть, но другое.

Я считаю, что это фатальная ошибка и в корне неверно, тем не менее это вполне себе зона роста и если научиться выполнять эту работу - менеджер это заметит и оценит. Итак, формулировки:
"Самоорганизующаяся команда", "интерфейс", "самостоятельное принятие решений", "менеджмент команды", "сами знают куда расти".
"Решить проблемы с тестерами".

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

Но это тупик - так как задача - самоподдерживающаяся система, а не изменения.

Выводы: менеджеры. Вы все делаете правильно.
Тестировщики. Работа менеджмента группы разработки - сложная штука, вы должны знать за что и зачем беретесь.

А что было потом?
Я считаю, что рост без ограничений невозможен. Само - ничего не случится.
У нас есть несколько продуктов и менеджеров с высокими требованиями к бездефектности и там можно применить весь тестерский матан. И он там еще не применен.
У нас есть пара продуктов, где нельзя тестировать, не становясь экспертом в домене и не занимаясь аналитикой. И там нужны тестеры - эксперты.
У нас есть экстерн, где очень  высокие и жесткие требования к скорости работы. По слухам, они даже повышаются. Это тоже зона роста.
У нас есть менеджеры любого продукта, которые с удовольствием отдадут тестировщикам часть работы по управлению разработкой.

И у нас есть куча народу которые считают, что уже достигли потолка в проекте. И куча руководителей, желающих странного.

Менеджеры.
Не требуйте странного. Тестировщик - линейка.
Он может: быстрее, чаще, точнее, раньше.
Остальное - детали реализации. Инструменты тестер найдет сам.

Тестеры.
Используйте мою модель.
Придумайте свою.
Но научитесь определять, чего от вас нужно. И если ничего не нужно - меняйте проект.

2 комментария: