Сегодня у нас в программе говяжьи методы приоритизации - то, что поможет вам быстро распределить задачи в полевых условиях.
Суть этой группы методов проста - садимся с умными людьми и давай задачи по полкам раскладывать. Тут я выделяю 3 основных метода работы:
1. Хуман-центеред. Мы резко вспоминаем, что не просто так таскаем приписку «хуикс» к своей профессии, первым делом проводим исследования и составляем CJM нашего продукта (про CJM сына маминой подруги можно почитать у меня вот тут).
Этот CJM мы делаем не просто так, но чтобы прикинуть, какие фичи нам потребуются для прохождения пользователем сценария - и насколько они вообще критичны.
Дальше все просто: берем критичные задачи, без которых сценарий вообще никак не прокатится, а все остальное, без чего можно прожить, распределяем по вторым-третьим-четвертым релизам.
Если возникают сложности в распределении задач внутри первой очереди разработки (типа, что делать первым в сценарии покупки - каталог или карточку товаров), то можно или оттолкнуться от самой хронологии пользовательского сценария (за что пользователь примется первым делом - то и делаем в первую очередь), или же воспользоваться вторым методом.
2. Аркитекча-центеред. Мы резко вспоминаем, что дофига инженеры и делаем сложные информационные системы, первым делом прикидываем системную архитектуру и распределяем задачи по целесообразности разработки. Например, если мы делаем мобильное приложение банка, то с точки зрения разработки нет смысла делать историю операций прежде процедуры регистрации клиента и внедрения списка карт и счетов - историю будет некуда привязать.
В этом процессе не обойтись без системного архитектора - того самого хмурого деда, который в обычное время глушит водку в углу, не мигая смотрит на календарь с голыми женщинами и всякие клиентские проблемы-CJM-UJM-методы персон видит в лучшем случае в гробу, а то и где похуже.
Этот дед вынимает сигару изо рта, шевелит густыми усами, смотрит на ваши планы, говорит хмуро «ВОТ ЭТО БЛЪ ДЕЛАЕМ В САМОМ НАЧАЛЕ ЭТО БЛЪ ДЕЛАЕМ В САМОМ КОНЦЕ А ПРО ЭТО БЛЪ ЗАБЫЛ СРОЧНО ЭТО НЕ РЕАЛИЗУЕМО ОПЯТЬ НАПРИДУМЫВАЛИ БЛЪ ХИМОТУ А НАМ ДЕЛАЙ».
Вот вам и приоритизация с точки зрения деда-архитектора: бронебойная с точки зрения разработки, но не всегда осмысленная с точки зрения пользователей - вполне может статься, что вы будете долгое время делать классные и логичные технические фичи, которые будут обладать нулевой ценностью для пользователей.
Это не очень хорошо - таким макаром вы быстро пользовательское решение не получите. Тогда вас выручит следующий метод.
3. Суперстракчед-хуман-аркитекча-центеред-2000 эдишон-ПЛЮС. Как можно догадаться из названия, этот метод приоритизации объединяет предыдущие два - и предполагает, что вы усаживаете за стол переговоров и UX-специалистов, и архитектурных дедов. Спустя несколько часов споров, выпитых бутылок водки и порванных - нет, вы не так поняли, подождите - листов бумаги вы получите план по разработке, который будет сбалансирован и с системной, и с пользовательской точки зрения. Его можно брать в работу и не беспокоиться, что вы где-то сядете в лужу.
Ну, почти не беспокоиться. Вышеописанные методы проканают только в том случае, если вы делаете новый продукт, который нужно довести до MVP, или какую-то особо крупную фичу, которую надо разбить на подфичи и заниматься ими отдельно (в таком случае ситуация неотличима от запуска нового продукта).
Если же перед вами лежит ворох задач, которые несут разную ценность для пользователя, отличаются по трудозатратам и при этом должны разрабатываться одной командой - у меня для вас есть плохая и хорошая новость.
Плохая новость заключается в том, что в таком случае говяжьи методы не сработают. Хорошая новость заключается в том, что у вас есть я - и в следующий раз я расскажу вам про более хитрые методы приоритизации, которые вас спасут в случае лютой неопределенности.
(или не спасут, но я не буду пугать вас раньше времени)
#батинамудрость
Суть этой группы методов проста - садимся с умными людьми и давай задачи по полкам раскладывать. Тут я выделяю 3 основных метода работы:
1. Хуман-центеред. Мы резко вспоминаем, что не просто так таскаем приписку «хуикс» к своей профессии, первым делом проводим исследования и составляем CJM нашего продукта (про CJM сына маминой подруги можно почитать у меня вот тут).
Этот CJM мы делаем не просто так, но чтобы прикинуть, какие фичи нам потребуются для прохождения пользователем сценария - и насколько они вообще критичны.
Дальше все просто: берем критичные задачи, без которых сценарий вообще никак не прокатится, а все остальное, без чего можно прожить, распределяем по вторым-третьим-четвертым релизам.
Если возникают сложности в распределении задач внутри первой очереди разработки (типа, что делать первым в сценарии покупки - каталог или карточку товаров), то можно или оттолкнуться от самой хронологии пользовательского сценария (за что пользователь примется первым делом - то и делаем в первую очередь), или же воспользоваться вторым методом.
2. Аркитекча-центеред. Мы резко вспоминаем, что дофига инженеры и делаем сложные информационные системы, первым делом прикидываем системную архитектуру и распределяем задачи по целесообразности разработки. Например, если мы делаем мобильное приложение банка, то с точки зрения разработки нет смысла делать историю операций прежде процедуры регистрации клиента и внедрения списка карт и счетов - историю будет некуда привязать.
В этом процессе не обойтись без системного архитектора - того самого хмурого деда, который в обычное время глушит водку в углу, не мигая смотрит на календарь с голыми женщинами и всякие клиентские проблемы-CJM-UJM-методы персон видит в лучшем случае в гробу, а то и где похуже.
Этот дед вынимает сигару изо рта, шевелит густыми усами, смотрит на ваши планы, говорит хмуро «ВОТ ЭТО БЛЪ ДЕЛАЕМ В САМОМ НАЧАЛЕ ЭТО БЛЪ ДЕЛАЕМ В САМОМ КОНЦЕ А ПРО ЭТО БЛЪ ЗАБЫЛ СРОЧНО ЭТО НЕ РЕАЛИЗУЕМО ОПЯТЬ НАПРИДУМЫВАЛИ БЛЪ ХИМОТУ А НАМ ДЕЛАЙ».
Вот вам и приоритизация с точки зрения деда-архитектора: бронебойная с точки зрения разработки, но не всегда осмысленная с точки зрения пользователей - вполне может статься, что вы будете долгое время делать классные и логичные технические фичи, которые будут обладать нулевой ценностью для пользователей.
Это не очень хорошо - таким макаром вы быстро пользовательское решение не получите. Тогда вас выручит следующий метод.
3. Суперстракчед-хуман-аркитекча-центеред-2000 эдишон-ПЛЮС. Как можно догадаться из названия, этот метод приоритизации объединяет предыдущие два - и предполагает, что вы усаживаете за стол переговоров и UX-специалистов, и архитектурных дедов. Спустя несколько часов споров, выпитых бутылок водки и порванных - нет, вы не так поняли, подождите - листов бумаги вы получите план по разработке, который будет сбалансирован и с системной, и с пользовательской точки зрения. Его можно брать в работу и не беспокоиться, что вы где-то сядете в лужу.
Ну, почти не беспокоиться. Вышеописанные методы проканают только в том случае, если вы делаете новый продукт, который нужно довести до MVP, или какую-то особо крупную фичу, которую надо разбить на подфичи и заниматься ими отдельно (в таком случае ситуация неотличима от запуска нового продукта).
Если же перед вами лежит ворох задач, которые несут разную ценность для пользователя, отличаются по трудозатратам и при этом должны разрабатываться одной командой - у меня для вас есть плохая и хорошая новость.
Плохая новость заключается в том, что в таком случае говяжьи методы не сработают. Хорошая новость заключается в том, что у вас есть я - и в следующий раз я расскажу вам про более хитрые методы приоритизации, которые вас спасут в случае лютой неопределенности.
(или не спасут, но я не буду пугать вас раньше времени)
#батинамудрость