Когда приоритеты теряют силы...



Почему в жизни проекта наступают моменты, когда появляется большое количество issues с максимальными приоритетами? Для этого есть несколько причин, и они на первый взгляд вполне уважительны, чтобы так поступать...
Но бывают моменты, когда стоит задуматься, а так ли это сейчас важно. Конечно, влиять на начальство не так и легко. Зачастую даже team leads не могут изменить то, что так красноречиво описал в письме ПМ или project owner.
«Предупрежден, значит защищен» — гласит народная мудрость. Мы ей поверим, и попытаемся разобраться, чем это грозит нам — team lead’ам и обычным тестировщикам.
1. Задачи, которые находят тестировщики не имеют наивысшего приоритета, за редким исключением showstopper’ов. В итоге может получится ситуация, когда важные задачи не будут реализованы из-за реализации задач с неправильно выставленным приоритетом.

2. Неверная приоретизация заразительна — пройдет время, и вот уже все ставят более высокие приоритеты исходя не из сдравой логики и важности для проекта, а исходя из важности и «удобности» для этого лица — не важно ПМ он или junior тестировщик.

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

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

Решение, хоть и не идеально, но оно есть — таблица критериев приоритета.
Сия таблица не есть что-то новое, это скорее хорошо забытое старое.
Суть заключается в том, что в начале проекта (или по необходимости) ключевые фигуры проекта договариваются об единых правилах для назначения того или иного приоритета.

Безусловно, бывают исключения, но только как исключения, а не как правило.

А у вас как обстоят дела с приоритетами. Все их правильно устанавливают?

Из-под пера Maksim Grinevich

Тэги: , ,
Нашли ошибку в тексте? Выделите её мышкой и нажмите Ctrl + Enter.

Ещё по данной теме:


0 ответов, оставьте свой...: