Когда приоритеты теряют силы...
вторник, июля 28, 2009
Почему в жизни проекта наступают моменты, когда появляется большое количество issues с максимальными приоритетами? Для этого есть несколько причин, и они на первый взгляд вполне уважительны, чтобы так поступать...
Но бывают моменты, когда стоит задуматься, а так ли это сейчас важно. Конечно, влиять на начальство не так и легко. Зачастую даже team leads не могут изменить то, что так красноречиво описал в письме ПМ или project owner.
«Предупрежден, значит защищен» — гласит народная мудрость. Мы ей поверим, и попытаемся разобраться, чем это грозит нам — team lead’ам и обычным тестировщикам.
1. Задачи, которые находят тестировщики не имеют наивысшего приоритета, за редким исключением showstopper’ов. В итоге может получится ситуация, когда важные задачи не будут реализованы из-за реализации задач с неправильно выставленным приоритетом.
2. Неверная приоретизация заразительна — пройдет время, и вот уже все ставят более высокие приоритеты исходя не из сдравой логики и важности для проекта, а исходя из важности и «удобности» для этого лица — не важно ПМ он или junior тестировщик.
3. Неверные приоритеты демотивируют сотрудников: создается впечатление, что плохо работает, раз столько ошибок найдено уже после релиза приложения.
Этот список можно продолжать, но стоит лучше обратить свой взгляд на решение проблемы.
Решение, хоть и не идеально, но оно есть — таблица критериев приоритета.
Сия таблица не есть что-то новое, это скорее хорошо забытое старое.
Суть заключается в том, что в начале проекта (или по необходимости) ключевые фигуры проекта договариваются об единых правилах для назначения того или иного приоритета.
Безусловно, бывают исключения, но только как исключения, а не как правило.
А у вас как обстоят дела с приоритетами. Все их правильно устанавливают?
