Product Backlog: Подреждане по стойност
Научете как Product Owner подрежда Product Backlog по стойност в Scrum. Балансирайте търговската полза, намаляването на риска и цената на забавянето, за да постигнете своята Product Goal.
Повечето продуктови екипи приемат, че подреждането на Product Backlog по стойност означава поставяне на най-доходоносните функционалности най-отгоре. Тази наивна гледна точка често води до провал. Стойността в разработката на софтуер рядко е просто число в електронна таблица. Тя е съвкупност от ползи за потребителя, намаляване на риска, придобити знания и стратегическо съответствие. Ако се фокусирате единствено върху непосредствената финансова възвръщаемост, ще пренебрегнете основополагащата работа и циклите за обратна връзка, необходими за изграждането на устойчив продукт.
Заблудата да се разчита само на приходите
Когато заинтересованите страни настояват за предпочитаните от тях функционалности, те почти винаги ги обосновават с прогнозни финансови стойности. Тези стойности обикновено са просто предположения. Ако Product Owner подрежда беклога единствено според тези оценки, екипът в крайна сметка изгражда големи, спекулативни функционалности, стъпващи на непотвърдени хипотези. Когато софтуерът излезе на пазара шест месеца по-късно, пазарът вече се е променил или на потребителите просто не им пука.
Истинската стойност се реализира едва когато софтуерът стигне до потребителите и предизвика измерима промяна в тяхното поведение. Докато даден Increment не е внедрен в реална среда, всяко изчисление на стойността остава само хипотеза. Разглеждането на подреждането на беклога единствено като средство за генериране на приходи често пречи на екипите да видят реалната цена на нерешените архитектурни и пазарни рискове.
Четири измерения на стойността в беклога
Ръководството за Scrum (Scrum Guide) от 2020 г. посочва, че Product Owner носи отговорност за максимизирането на стойността на продукта, получена от работата на Scrum Team. То умишлено не налага строга формула, тъй като стойността се променя според контекста. За да подредите беклога ефективно, вземете предвид четири отделни измерения:
- Търговска стойност, която включва директно генериране на приходи, привличане на клиенти и спестяване на оперативни разходи.
- Информационна стойност, която обхваща прототипи и експерименти, валидиращи бързо несигурни пазарни хипотези.
- Намаляване на риска, което елиминира навреме архитектурни уязвимости, регулаторни заплахи или проблеми с производителността.
- Стойност на ефективността, която отстранява техническите пречки и позволява на Scrum Team да доставя последващата работа по-сигурно.
Зависимости и цена на забавянето
Стойността не може да бъде оценявана изолирано. Ценен елемент, планиран твърде късно, може да загуби напълно смисъла си. Това представлява концепцията за цена на забавянето (cost of delay). Например внедряването на функционалност за данъчно отчитане след крайния регулаторен срок носи нулева стойност, без значение колко качествен е кодът. Обратно, пускането на базов прототип две седмици преди конкурент може да запази пазарния дял.
Техническите и логическите зависимости също влияят на подреждането. Да приемем, че функционалност Б обещава високи приходи, но изисква основни подобрения в автентикацията, представени от функционалност А. В такъв случай функционалност А унаследява спешността на функционалност Б. Product Owner си сътрудничи с Developers, за да разбере тези ограничения. Developers предоставят реалната техническа картина, докато Product Owner гарантира, че поредността продължава да обслужва продуктовата стратегия.
Свързване на подредбата с Product Goal
Product Goal е ангажиментът за Product Backlog в Scrum. Тя дава на екипа ясна цел, към която да се стреми, вместо хаотичен списък от несвързани заявки. Ако даден елемент не допринася за текущата Product Goal, неговото място обикновено е по-надолу в списъка, независимо колко настоятелно го изисква някой ръководител.
Когато елементите се придвижват към върха на беклога, те трябва да стават по-малки, по-конкретни и готови за избор по време на Sprint Planning. Елементи с висока стойност, които са твърде големи или неясни, не могат да бъдат завършени в рамките на един Sprint. Разделянето на ценните елементи на малки, проверими части позволява на Scrum Team да инспектира, адаптира и доставя използваема стойност непрекъснато.