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