Если вы не используете базу ошибок в разработке ПО, то обязательно начните. База не особо нужна маленьким командам, но это, вероятно, поможет понять, делаете ли вы всё правильно в плане продукта. Учёт ошибок, наличие документа с требованиями к продукту, макеты интерфейса или визуальные компоненты — с помощью этого вы сможете управлять организацией разработчиков.
Двигаясь от приоритета к приоритету, нужно помнить: дьявол кроется в деталях. Всегда что-то идёт неправильно. Никогда не видел спринта или релиза без неожиданностей, которые могут всё испортить. Приоритизация даёт уверенность в том, что вы ставите реальные цели.
Если нет приоритетов, вы не знаете, от чего можно отказаться. И так двухнедельный спринт превращается в трёхнедельный, а затем в четырёхнедельный, а потом в спринт длиной несколько месяцев. В итоге вы никогда не закончите работу. Это одна из главных причин важности приоритетов.
Одна из главных сложностей при создании продукта: довольно трудно определить, что делать сейчас, а что потом. И здесь снова может понадобиться приоритизация. Благодаря ей от релиза к релизу вы будете уверены, что продукт развивается в правильном направлении.
Это азы продукт-менеджмента. Но многие этого не делают: ничего не фиксируют, не понимают, зачем нужны те или функции, кому они нужны, какие проблемы в целом решает продукт.
Ещё один момент, с которым все сталкиваются при разработке, — объём работы, качество продукта и время.
- Объём. Количество взятой работы.
- Качество. Нельзя охватить его с помощью требований, о нём судят пользователи продукта. Также сюда входят ошибки и элементы, которые не работают.
- Время. Вы можете сделать функциональность качественной, без ошибок, но тогда придётся сдвинуть сроки на пару недель. Если вы возьмёте большой объём работы, то не успеете всё сделать качественно, в таком случае пользователи получат продукт с массой ошибок.
Ещё одна причина, почему важна приоритизация, — без неё вы можете сделать множество странных и неуместных решений. Бывало ли у вас такое, что, настраивая iPhone или другое устройство, вы думали: «Кто и зачем это сделал?» Скорее всего, разработчики просто не стали доделывать продукт до конца. Они просто махнули рукой: «А давайте выкатывать так».
Это большая ошибка. Без приоритизации падает качество, и продукт может провалиться.
Дизайн взаимодействия Итак, вы знаете, кто ваш пользователь и какие у него проблемы. Как это перевести в задачи, над которыми вы будете работать? Как люди будут всем этим пользоваться? Какие у них цели, как они их достигнут?