ИТ-Беседка

ИТ-Беседка 

Внутрянка ИТ, управление, построение процессов

4subscribers

163posts

Глава "Приоритезация задач" из книги "Гибкие методологии на практик"

Приоритезация задач необходима для разработки правильного продукта. Чаще всего заказчики и пользователи делают множество запросов на разработку функционала. Если все заносить в список задач с равным приоритетом, то у команды не будет ориентира, какие задачи более важны и в каком порядке их нужно выполнять. Приоритеты помогают команде определить, на каких задачах нужно сосредоточится в текущий момент времени. Таким образом, команда не пытается сделать все и не распыляет свое внимание, а фокусируется на самых ценных задач для продукта. Фокус на конкретных задачах также дает возможность разрабатывать качественный продукт. Таким образом, мы получаем наиболее правильный продукт, готовый к конкуренции на рынке и оставляющий пользователей максимально удовлетворенными.
Приоритет формируется на основе двух направлений: ценности для бизнеса и технической сложности реализации.
Ценность для бизнеса определяется на основе того, какие функции больше всего удовлетворят пользователей, помогут продукту оставаться конкурентоспособным на рынке и будут приносить наибольшую прибыль компании. Чем ценнее для бизнеса функционал, тем выше должен быть приоритет у задачи, и наоборот.
С технической стороны, для каждой задачи должен быть определен приоритет по сложности реализации функционала. Здесь необходимо пользоваться принципом - чем проще, тем лучше. Самые простые и быстрые задачи обладают самым высоким приоритетом со стороны технической сложности.
Общий приоритет задачи формируется соединением двух приоритетов: ценности для бизнеса и технической сложности. В идеале, самыми приоритетными задачами должны быть те, которые имеют наибольшую ценность для бизнеса и наименьшую техническую сложность. То есть самые ценные и самые простые (дешевые) в реализации задачи потратят мало ресурсов компании, но принесут максимальную пользу, оправдывая себя лучше всего, поэтому их нужно делать в первую очередь.
Помимо этих двух основных направлений при установке приоритета также принимаются во внимание риски, которые несут в себе задачи. Имеет смысл задачи, несущие самый большой риск для продукта, брать в работу как можно раньше. Чтобы изучить этот риск, оценить его влияние на практике, протестировать решения и как можно скорее устранить его влияние на продукт.
При определении приоритетов задачи на практике все будет немного сложнее, чем определение самой ценной и самой простой задачи. Бывают ситуации, когда бизнес-ценность настолько критична, что даже очень большая техническая сложность не может понизить ее приоритет. Самым ярким примером может служить функционал, которым конкуренты начали переманивать к себе пользователей. Как бы много ресурсов не нужно было потратить на разработку в своем продукте такого же функционала, риск потерять бизнес полностью дает этой задаче наивысший приоритет, несмотря на высокую техническую сложность. Также бывают задачи чисто технические, которые, на первый взгляд, могут вообще не нести ценности для бизнеса, но могут стать препятствием для развития продукта. И они тоже могут иметь наивысший приоритет только лишь по этому параметру. Здесь команда вместе с бизнесом должны отталкиваться от ситуации в проекте и определять приоритеты соответственно. Важно балансировать между ценностью для бизнеса и технической сложностью, выбирая то, что наиболее важно для вашего продукта в текущий момент.
При установке приоритетов задач на выполнение, нужно обязательно помнить о приоритетах дорожной карты и постоянно сверяться с ней. Приоритеты конкретных задач должны отражать приоритеты дорожной карты. Нужно помнить, что это верхнеуровневый план проекта и он определяет основное направление развития. Поэтому нельзя, чтобы задачи в бэклоге на разработку продукта имели приоритет выше или ниже, чем они имеют в дорожной карте. Так нарушается долгосрочный план развития и можно подорвать достижение намеченных целей.
Продолжеление о том, как работать с приоритезацией на практике, ищите в книге "Гибкие методологии на практике".
Go up