Validation

Vision hara getdiyimizi deyir, value yolda olub-olmadığımızı ölçür. Amma hər ikisi bir fərziyyəyə söykənir: "bunu qursaq, bu dəyər yaranacaq". Validation bu fərziyyəni yoxlamaqdır. Peşəkar Product Owner-i yaxşı niyyətli Product Owner-dən ayıran məhz budur: o, inanmır, yoxlayır.

Bu fəsil məhsul işini eksperimentlər ardıcıllığı kimi görməyi, fərziyyələri necə ifadə etməyi, onları ucuz yoxlamağı və nəticədən öyrənməyi izah edir.

Hər feature bir fərziyyədir

Backlog-dakı hər element gizli bir iddia daşıyır: istifadəçilər bunu istəyəcək, bu problem həll olunacaq, bu göstərici dəyişəcək. Komandalar bu iddianı adətən yazmır, ona görə də onu heç vaxt yoxlamır. Feature çatdırılır, "done" olur, hamı növbəti element-ə keçir və heç kim geri dönüb soruşmur: işlədimi?

Sənaye tədqiqatları (məsələn, Standish Group-un məlumatları) çatdırılan feature-lərin böyük hissəsinin nadir hallarda və ya heç vaxt istifadə olunmadığını göstərir. Bu, komandaların pis işləməsi deyil; bu, yoxlanılmamış fərziyyələrin təbii nəticəsidir. Fərziyyələrin yarısı səhvdirsə və siz heç birini yoxlamırsınızsa, işinizin yarısı itkidir.

Fərziyyəni açıq yazmaq onu yoxlanıla bilən edir:

Biz inanırıq ki, [bu dəyişiklik] [bu insanlar] üçün [bu nəticəni] verəcək. Bunu [bu ölçünün] [bu qədər] dəyişməsi ilə biləcəyik.

Şablonun hər hissəsi bir qərardır. "Bu ölçü" boş qalırsa, fərziyyə yoxlanıla bilməz və backlog-a daxil olmamalıdır. "Bu qədər" boş qalırsa, istənilən nəticə uğur kimi şərh olunacaq.

Build-measure-learn

Eric Ries-in Lean Startup dövrü validation-ın əsas ritmidir:

Build: fərziyyəni yoxlamaq üçün lazım olan minimum şeyi qurun.
Measure: real istifadəçilərlə, real şəraitdə ölçün.
Learn: fərziyyə təsdiqləndi, təkzib olundu, yoxsa dəqiqləşdirilməlidir? Növbəti addıma qərar verin.

Dövrün dəyəri sürətindədir. Altı aylıq build fazası ilə build-measure-learn ildə iki dövr deməkdir. İki həftəlik Sprint-lərlə iyirmi beş. Dövr nə qədər qısadırsa, səhv fərziyyəyə sərf olunan iş o qədər azdır. Ona görə Time-to-Market Product Owner üçün mühəndislik göstəricisi deyil, öyrənmə sürətidir.

Minimum viable product

MVP termini çox təhrif olunub. MVP "məhsulun pis versiyası" və ya "ilk release" deyil. MVP fərziyyəni yoxlamaq üçün lazım olan minimum iş-dir. Bəzən bu, tam işləyən feature-dir. Çox vaxt isə yox:

Landing page: feature-i təsvir edin, "qeydiyyatdan keç" düyməsi qoyun, neçə nəfərin basdığını ölçün. Kod yazılmadan tələb yoxlanır.
Concierge: feature-i əl ilə, insan vasitəsilə göstərin. On müştəri üçün əl ilə hesabat hazırlayın; faydalı olduğunu görəndə avtomatlaşdırın.
Wizard of Oz: istifadəçi avtomatlaşdırılmış sistem görür, arxada insan işləyir.
Prototip: kliklənə bilən dizayn, kod yoxdur, istifadəçi reaksiyası var.
Feature toggle ilə məhdud release: istifadəçilərin bir faizinə açın, ölçün, sonra qərar verin.

Hər birinin məqsədi eynidir: öyrənmənin xərcini aşağı salmaq. Product Owner hər böyük backlog element-i üçün soruşmalıdır: bunun işləyəcəyini ən ucuz necə öyrənə bilərik?

Eksperiment dizaynı

Yaxşı eksperimentin dörd elementi var:

Aydın fərziyyə. Yuxarıdakı şablon. Əvvəlcədən yazılır, nəticədən sonra dəyişdirilmir.

Uğur meyarı əvvəlcədən. "Konversiya 3%-dən 4%-ə qalxsa, davam edirik; qalxmasa, dayanırıq." Meyar nəticədən sonra təyin olunsa, hər nəticə uğurdur.

Müqayisə bazası. A/B test ideal haldır: iki qrup, bir fərq, statistik müqayisə. Mümkün deyilsə, ən azı əvvəl-sonra müqayisəsi, mövsüm və digər faktorlar nəzərə alınmaqla.

Kifayət qədər məlumat. Beş istifadəçi ilə A/B test nəticə vermir. Kiçik məhsullarda kəmiyyət testləri əvəzinə keyfiyyət tədqiqatı, yəni istifadəçi müsahibələri və müşahidə daha etibarlıdır.

Kəmiyyət və keyfiyyət

Kəmiyyət məlumat nə baş verdiyini deyir: istifadəçilərin 60%-i üçüncü addımda tərk edir. Keyfiyyət məlumat niyə olduğunu deyir: üçüncü addımda istədiyimiz məlumatı onlar əllərində tapmır. Yalnız kəmiyyət ilə səhv həll yolu seçmək asandır; yalnız keyfiyyət ilə beş nəfərin fikrini hamıya şamil etmək asandır. Product Owner ikisini birlikdə istifadə edir: kəmiyyət problemi tapır, keyfiyyət səbəbi izah edir, kəmiyyət həllin işlədiyini təsdiqləyir.

Feedback mənbələri

Validation yalnız A/B test deyil. Product Owner-in feedback üçün bir neçə kanalı olmalıdır və hər biri fərqli şey öyrədir:

Mənbə	Nəyi öyrədir	Tələsi
Analytics, istifadə məlumatı	Real davranış, miqyas	Niyə-ni demir
İstifadəçi müsahibələri	Səbəb, kontekst, emosiya	Kiçik nümunə, dediyi ilə etdiyi fərqlənir
Sprint Review	Stakeholder reaksiyası, istiqamət	Stakeholder istifadəçi deyil
Support və satış komandası	Təkrarlanan ağrılar	Ən çox səs çıxaran, ən vacib deyil
Rəqib analizi	Bazar gözləntiləri	Rəqibi kopyalamaq strategiya deyil
Beta və early access	Real şəraitdə erkən feedback	Beta istifadəçiləri tipik deyil

Product Owner-in ən böyük validation riski stakeholder-i istifadəçi ilə qarışdırmaqdır. Satış direktoru feature-i çox istəyə bilər; bu, istifadəçinin istəyəcəyi demək deyil. Sprint Review-da stakeholder məmnun ola bilər; bu, metrika-nın dəyişəcəyi demək deyil. Stakeholder feedback-i vacibdir, amma validation deyil.

Uğursuz eksperimentlər

Validation-ın ən çətin hissəsi mədənidir: fərziyyənin təkzib olunması uğursuzluq kimi qəbul olunur. Komanda iki Sprint işləyib, feature çıxıb, metrika dəyişməyib. Bu, "boşa işlədik" deməkdirmi?

Xeyr. Bu, iki Sprint-ə altı aylıq səhv istiqamətin qarşısını almaq deməkdir. Təkzib olunmuş fərziyyə bilikdir: artıq bilirik ki, bu yol işləmir. Təsdiq olunmamış, amma hər halda qurulmuş on feature isə bilik deyil, yükdür: onları saxlamaq, test etmək, sənədləşdirmək lazımdır və heç kim istifadə etmir.

Product Owner bu mədəniyyəti qurur: eksperimentin nəticəsini Sprint Review-da açıq paylaşır, "təkzib olundu" sözünü normal edir, istifadə olunmayan feature-i silməyi təklif edir. Feature silmək backlog-un ən az istifadə olunan, ən dəyərli əməliyyatlarından biridir: A2I artır, baxım xərci azalır.

Validation və backlog

Validation backlog-un strukturunu dəyişir. Fərziyyə yoxlanana qədər böyük element-lər tam detallaşdırılmır: əvvəlcə kiçik eksperiment, nəticəyə görə ya tam feature, ya da silinmə. Bu, Fəsil 7-də refinement-in əsas prinsiplərindən biri olacaq: backlog-un yuxarısı detallı və yoxlanmış, aşağısı qaba və fərziyyəlidir.

Product Owner üçün praktiki qayda: böyük investisiya tələb edən hər element-in yanında "bunu necə yoxlayacağıq?" sualının cavabı olmalıdır. Cavab yoxdursa, element hələ hazır deyil.

Fəslin xülasəsi

Hər feature bir fərziyyədir; yazılmayan fərziyyə yoxlanmır, yoxlanmayan fərziyyə çox vaxt səhvdir.
Build-measure-learn dövrü nə qədər qısadırsa, səhv fərziyyəyə sərf olunan iş o qədər azdır.
MVP fərziyyəni yoxlamaq üçün minimum işdir; landing page, concierge, prototip və məhdud release çox vaxt kod yazmaqdan ucuzdur.
Yaxşı eksperimentin fərziyyəsi, uğur meyarı və müqayisə bazası əvvəlcədən təyin olunur.
Stakeholder məmnunluğu validation deyil; real istifadəçi davranışı validation-dır.
Təkzib olunmuş fərziyyə uğursuzluq deyil, bilikdir; istifadə olunmayan feature-i silmək dəyərli əməliyyatdır.