Приоритизация требований: почему приоритеты почти всегда меняются

Приоритизация требований в теории выглядит просто: есть список задач, есть методика, есть порядок выполнения. В реальности это почти никогда так не работает.

И я уверена, что вы сталкивались с тем, что у заказчика «всё срочно, горит!», у разработчиков «всё сложно», тестировщикам всё нужно протестировать, а аналитик оказывается между этими точками напряжения и должен собрать из этого что-то, что вообще можно реализовать.

И первая ошибка, которую делают многие начинающие аналитики – они пытаются зафиксировать это как статичную картину. Мол, вот приоритеты, вот список, дальше просто делаем по порядку. Но в живых продуктах приоритеты не существуют в стабильном виде. Они постоянно двигаются. И дело вовсе не в «плохом» управлении, а в том, что меняется контекст: рынок, сроки, ограничения, зависимость от других систем. По сути это нормальная ситуация.

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

Как с этим работать на практике? 

У меня есть проверенный алгоритм. Расскажу в следующем посте. 

Спойлер: это вообще не про таблицы и методики.