Марио ТрендафиловЕдин добър анализ рядко завършва с един проблем.
По-често резултатът изглежда така:
категориите имат нужда от преструктуриране;
част от продуктовите данни са непълни;
checkout-ът създава ненужно затруднение;
някои страници са бавни;
tracking-ът има пропуски;
вътрешните връзки са слаби;
администрацията изисква твърде много ръчна работа.
Всички тези неща може да са верни.
Но от това не следва, че трябва да започнем от най-видимото.
Нито от най-лесното.
Нито непременно от проблема с най-голям очакван ефект.
След анализа започва втори вид работа:
да определим кое решение има смисъл да бъде първо — и дали моментът за него е правилният.
Това е различен проблем.
И понякога е по-трудният.
Списъкът с проблеми не е план
Одитът може да бъде напълно правилен и въпреки това да доведе до лош проект.
Причината е проста.
Да знаем какво не работи не е същото като да знаем в какъв ред трябва да го променим.
Ако открием 20 проблема и ги подредим само по това колко сериозно изглеждат, лесно можем да пропуснем зависимостите между тях.
Представете си, че в онлайн магазин филтрите са лоши.
Това е важен UX проблем.
Потребителите трудно намират продукти.
Следователно изглежда разумно да започнем с нова филтрираща система.
Но анализът показва още нещо:
продуктовите характеристики са непоследователни и непълни.
Тогава новият филтър зависи от работа, която още не е направена.
Можем да разработим интерфейса първо.
Само че ще го изградим върху данни, които не могат да го поддържат.
Така една правилна задача се превръща в грешен първи приоритет.
Приоритетът не е качество на самата задача
Често казваме:
„Това е висок приоритет.“
сякаш приоритетът е постоянна характеристика на проблема.
Но той зависи от контекста.
Една задача може да бъде много важна и все пак да не трябва да бъде първа.
Може да зависи от друга.
Може причината още да не е достатъчно проверена.
Може рискът от промяната да е прекалено висок.
Може да има друг проблем, който блокира няколко подобрения наведнъж.
Може ресурсът да е необходим другаде.
И може самата задача да е правилна, но моментът за нея да е лош.
Следователно приоритетът е отношение между:
целта, проблема, останалите задачи, наличния ресурс и конкретния момент.
Не просто число до задача в backlog.
Нека направим един хипотетичен одит
Представете си онлайн магазин, при който анализът открива пет реални проблема.
Първо: checkout-ът понякога не позволява на клиент да избере определен метод за доставка при конкретна комбинация от продукти.
Второ: продуктовите характеристики са непоследователни и това ограничава филтрите.
Трето: категориите имат нужда от нова структура.
Четвърто: част от изображенията са прекалено тежки и забавят страниците.
Пето: измерването на част от ключовите действия е непълно.
Всички проблеми са реални.
Кое решаваме първо?
Ако използваме само „ефект срещу усилие“, вероятно ще получим някаква подредба.
Тя може да бъде полезна.
Но още не е достатъчна.
Първо проверявам дали нещо причинява директна загуба или блокира основен процес
Проблемът в checkout-а засяга човек, който вече се опитва да завърши поръчката.
Той не е просто неудобство.
При определени условия системата не позволява желаното действие.
Това променя характера на задачата.
Ако дефектът е потвърден и може да блокира реални поръчки, има силна причина той да изпревари по-голям стратегически проект.
Дори новата категорийна архитектура потенциално да носи много по-голям дългосрочен ефект.
Причината не е, че checkout-ът е по-важен от архитектурата по принцип.
Причината е, че в момента имаме повреда в основен работещ процес.
След това търся задачите, от които зависят други задачи
Да приемем, че сме решили критичния проблем.
Остават:
продуктовите данни;
категорийната структура;
производителността;
измерването.
Изкушението е да започнем с новата структура, защото тя е най-видима за клиента.
Само че новите категории и филтри зависят от добри продуктови характеристики.
Ако първо направим UX концепцията и едва след това установим, че половината необходими атрибути липсват, ще се върнем назад.
Следователно продуктовите данни могат да получат по-висок приоритет не защото клиентът ги вижда директно, а защото отключват следващата работа.
Някои задачи носят резултат сами.
Други позволяват няколко следващи задачи да бъдат направени правилно.
Вторите често изглеждат по-малко впечатляващи, но могат да бъдат по-важни в началото.
Видимият резултат не трябва да определя реда
Екипът естествено предпочита промени, които могат да бъдат показани.
Нова начална страница.
Нова категория.
Нова функционалност.
Нов дизайн.
Те създават усещане за напредък.
Почистването на продуктови данни не изглежда толкова впечатляващо.
Коригирането на tracking-а също.
Изчистването на зависимост между две системи може въобще да не бъде забелязано от клиента.
Но проектът не трябва да бъде подреден според това кое изглежда като повече работа.
Трябва да бъде подреден според това кое създава условия следващата промяна да има смисъл.
Ефектът е важен, но очакваният ефект не е сигурен ефект
Да приемем, че две задачи са независими.
Едната изглежда способна да донесе значително подобрение, но причината зад проблема още не е сигурна.
Другата има по-малък потенциален ефект, но връзката е много по-добре установена.
Коя трябва да бъде първа?
Няма универсален отговор.
Но този пример показва защо не е достатъчно да записваме:
„висок ефект“;
„среден ефект“;
„нисък ефект“.
Трябва да попитаме:
Колко сме сигурни, че тази промяна действително ще произведе очаквания ефект?
Ако не сме, понякога първата задача не е самата промяна.
Първата задача е проверката, която ще намали несигурността.
Това може да спести много повече ресурс от бързото започване на голям проект.
Рискът също участва в приоритета
Някои промени се връщат лесно назад.
Други не.
Да сменим текст на страница е едно.
Да преструктурираме хиляди продуктови URL-и е друго.
Да тестваме нов елемент в checkout-а е едно.
Да мигрираме цялата платформа е друго.
Колкото по-трудно обратима е промяната, толкова по-висока трябва да бъде увереността, че решаваме правилния проблем.
Това не означава големите промени винаги да чакат.
Означава рискът да участва в решението за реда.
Моментът също променя приоритета
Има задачи, които са правилни като посока, но грешни точно сега.
Да приемем, че онлайн магазин има нужда от голяма URL миграция.
Архитектурата е натрупала проблеми и промяната има смисъл.
Но магазинът навлиза в най-силния си сезон след две седмици.
Тогава въпросът вече не е само:
„Трябва ли да направим миграцията?“
А:
„Трябва ли да я направим точно сега?“
Същото важи за голям redesign непосредствено преди важна кампания.
Не защото redesign-ът е грешен, а защото създава допълнителен риск точно когато стабилността е по-ценна.
Или за интеграция с външен доставчик, който все още променя API-то си.
Можем да започнем разработката веднага, но има риск да изграждаме върху интерфейс, който още не е стабилен.
Или за SEO архитектура, когато продуктовата структура още се променя.
Можем да определим URL-и и категории сега, но след месец бизнесът може да промени самата логика, върху която сме ги изградили.
Или за автоматизация на вътрешен процес, който в момента се преструктурира.
Технически можем да го автоматизираме.
Но така рискуваме да вложим ресурс в прецизното автоматизиране на процес, който след няколко седмици вече няма да съществува в същия вид.
Във всички тези случаи задачата може да бъде правилна.
Проблемът е моментът.
Приоритетът не отговаря само на въпроса „кое преди кое“, а и „защо сега“.
„Бързата победа“ невинаги трябва да бъде първа
Лесна, видима и полезна промяна естествено изглежда привлекателна.
Понякога това е правилният старт.
Но не и ако лесните подобрения постоянно изместват проблема, от който зависи основната цел.
Ако магазинът има лоши продуктови данни, можем бързо да подобрим бутони, изображения и текстове.
Това може да е полезно.
Но ако основният проблем е, че потребителят не може надеждно да сравнява продуктите, лесните задачи не решават ядрото.
Лесно + видимо + полезно не означава автоматично първо.
Как подреждам задачите
Не използвам един показател, който механично да произведе окончателен списък.
По-полезно ми е да проверя задачата през няколко различни въпроса.
Какъв ефект очакваме върху реалната цел?
Не върху абстрактно „подобряване на сайта“, а върху промяната, която бизнесът търси.
Има ли друга работа, която зависи от нея?
Ако да, задачата може да има по-голяма системна стойност, отколкото изглежда сама.
Тя зависи ли от нещо, което още не е готово?
Ако да, може да е важна, но преждевременна.
Колко сме сигурни в причинно-следствената връзка?
Ако причината е само хипотеза, може първо да ни трябва проверка.
Какво рискуваме, ако я направим погрешно?
Тук влизат цена, технически риск, загуба на трафик, прекъсване на процес или трудно връщане назад.
Колко ресурс изисква?
Време, хора, пари, внимание и зависимост от външни страни.
Блокира ли проблемът други подобрения или основен процес?
Понякога именно това решава реда.
Има ли причина тази задача да бъде направена точно сега — или причина да не бъде?
Тук влизат сезонност, кампании, техническа стабилност, външни зависимости, текущи промени в процеса и други условия, които могат временно да променят правилния ред.
Тези въпроси не дават математическа истина.
Но правят избора аргументиран.
Нека се върнем към петте проблема
След тази логика редът може да изглежда различно от първоначалното очакване.
Проблемът в checkout-а може да бъде първи, защото блокира основно действие.
След това може да се наложи да подобрим измерването там, където липсва информация, необходима за оценка на следващите промени.
Продуктовите данни могат да предшестват новата категорийна структура, защото тя зависи от тях.
Оптимизацията на изображенията може да бъде направена по-рано или паралелно, ако е достатъчно независима и не отклонява ресурс от критичната работа.
Новата структура може да дойде чак когато основата, върху която ще работи, е достатъчно стабилна.
Приоритетът трябва да се променя, когато се променя информацията
Планът не е договор с миналото.
Ако по време на работата открием нов проблем, който променя зависимостите, приоритетите трябва да могат да се променят.
Ако хипотеза отпадне, не трябва да продължаваме задача само защото вече е била записана в roadmap-а.
Ако външно условие промени риска или момента, редът също може да се промени.
Добрата последователност не е тази, която никога не се променя.
Тя е тази, за която във всеки момент можем да обясним:
Защо точно това е следващото най-смислено действие?
Не всички проблеми заслужават решение
Има и още една възможност.
Да не правим нищо.
При анализ почти винаги могат да бъдат намерени подобрения.
Но ресурсът е ограничен.
Ако даден проблем има малък ефект, висока цена и не блокира нищо важно, може да е напълно разумно да остане нерешен.
Това понякога е трудно за приемане.
Особено когато вече сме инвестирали време да го открием.
Но целта на анализа не е да произведе достатъчно работа за екипа.
Целта е да помогне на бизнеса да използва ресурса си по-добре.
Добрият анализ не завършва с „какво е грешно“
Той трябва да стигне и до:
Какво правим първо?
Какво може да чака?
Какво зависи от друго?
Кое трябва първо да бъде проверено?
Кое е правилно, но не точно сега?
Кое въобще не си струва да правим?
Защото бизнесът не разполага с безкраен бюджет, време или внимание.
Да откриеш правилния проблем е само половината работа.
Другата половина е да поставиш промяната на правилното място в последователността — и в правилния момент.
Затова правилната задача, изпълнена в грешния момент, все още може да бъде грешен приоритет.