Product Discovery в рамките на Scrum
Научете как да интегрирате Product Discovery в Scrum, без да създавате изолирани екипи. Провеждайте експерименти, валидирайте нуждите на потребителите и изграждайте правилния продукт в рамките на стандартните Sprint периоди.
Екипите често възприемат Scrum като поточна линия за писане на код. Те предполагат, че изискванията идват напълно готови, а разработчиците просто ги сглобяват в софтуер. Когато компаниите осъзнаят, че това води до продукти, които никой не иска, обичайната им реакция е да създадат отделен поток за discovery. Дизайнери и продуктови мениджъри правят проучвания в една изолирана среда, след което прехвърлят задачи през оградата към инженерите в друга. Това възпроизвежда точно онзи проблем с предаването на щафетата, за чието решаване бе създаден Scrum. За Product Discovery не е необходим отделен поток. Мястото му е директно вътре в самия Sprint.
Заблудата за предварителната фаза на Discovery
Ръководството за Scrum от 2020 г. е категорично: съществува само един Scrum Team, фокусиран върху една цел на продукта в даден момент. В този екип няма подекипи или йерархии. Когато разделите хората, които проучват, от хората, които създават, губите техническия контекст и съпричастността към потребителя. Инженерите познават техническите ограничения и възможности по-добре от всеки друг. Ако инженер присъства на интервюта с клиенти, той често забелязва решения, които дизайнер или продуктов мениджър никога не биха обмислили.
Предварителното проучване също така предполага, че знанията остаряват бавно. При софтуера изискванията се променят в момента, в който реални потребители се докоснат до интерфейса. Прекарването на три месеца във валидиране на прототипи, преди да бъде написан дори един ред код, е просто Waterfall, маскиран като модерно продуктово управление. Истинската валидация се случва тогава, когато работещият софтуер се срещне с реалното потребителско поведение.
Включване на работата по Discovery в Sprint Backlog
Sprint Backlog принадлежи изцяло на Developers. Той съдържа Sprint Goal, елементите от Product Backlog, избрани за дадения Sprint, както и приложим план за тяхното изпълнение. Нищо в Scrum рамката не пречи този план да включва дейности по discovery. Ако екипът трябва да намери отговор на критичен въпрос за потребителите, за да постигне своя Sprint Goal, това проучване представлява реална работа.
Един зрял Scrum екип съчетава задачи по доставка със задачи по discovery. Работата по discovery може да приема различни форми според това какво трябва да научи екипът:
- Провеждане на пет интервюта с потребители чрез интерактивен прототип за тестване на навигацията.
- Създаване на временен архитектурен spike за тестване на латентността на външен платежен портал при натоварване.
- Пускане на fake door тест, за да се измери реалният интерес на клиентите към планирана функция за експорт на аналитични данни.
- Вграждане на проследяване на събития в съществуващ екран, за да се определят изходните нива на отпадане на потребителите преди неговия редизайн.
Sprint Review като двигател за Discovery
Много екипи свеждат Sprint Review до еднопосочна демонстрация. Те показват завършените задачи и очакват учтиви аплодисменти. Ръководството за Scrum определя това събитие по съвсем различен начин, а именно инспекция на Increment и адаптация на Product Backlog. То трябва да бъде съвместна работна сесия със заинтересованите страни.
Ако подходите към Sprint Review като към процес на discovery, вие представяте реални данни за използването. Показвате какво е изградено, споделяте потребителски метрики, събрани по време на съответния Sprint, и обсъждате какво е изненадало екипа. Заинтересованите страни и Developers разглеждат актуалния пазарен контекст заедно. Резултатът от едно качествено Sprint Review е обновен Product Backlog, който отразява новооткритата реалност, а не просто първоначалната пътна карта.
Отказването от свършена работа е напълно валиден резултат
Най-трудната част от прилагането на Product Discovery в Scrum е приемането на загуби от различен характер. В екип, фокусиран единствено върху доставката, писането на код, който впоследствие бива изтрит, се възприема като провал. В екип, основан на емпиричен подход, спирането на функционалност, защото проучването я е доказало като ненужна, е огромна победа. Спестили сте месеци на бъдеща поддръжка и технически дълг.
Scrum осигурява кратки, ясно дефинирани цикли за обратна връзка. Всеки Sprint е възможност за събиране на доказателства. Когато Product Owner и Developers разглеждат всеки елемент от Backlog като подлежаща на проверка хипотеза, а не като поръчка за изпълнение, discovery и разработката се сливат в една единна, цялостна дисциплина.