Banklarda məhsul problemləri çox vaxt texniki çatışmazlıqdan yox, səhv məhsul qərarlarından yaranır. Bu qərarların mərkəzində isə adətən Məhsul Sahibi (Product Owner) dayanır. Aşağıdakı nümunələr real bank təcrübələrinə əsaslanır, lakin heç bir qurumun adı çəkilmir.
1. “Bu funksiya lazımdır” deyildi, amma niyə sualı verilmədi
Vaxtilə işlədiyim banklardan birində mobil tətbiqə yeni funksiya əlavə olundu. Funksiya texniki baxımdan problemsiz idi, testlərdən keçmişdi və istifadəyə verilmişdi. Lakin analitika göstərdi ki, istifadəçilər bu funksiyadan demək olar ki, yararlanmır. Sonradan məlum oldu ki, PO funksiyanı sifariş əsasında icra edib, lakin istifadəçi davranışını və real problemi analiz etməyib. Funksiya ehtiyacdan yox, fərziyyədən doğmuşdu. “Niyə edirik?” sualına cavabın olmaması məhsulun dəyər yaratmamasına səbəb oldu.
2. Prioritet siyahısı var idi, amma hamısı “ən vacib” idi
Başqa bir bankda backlog kifayət qədər dolu idi və hər stakeholder öz tələbinin kritik olduğunu iddia edirdi. PO isə konflikt yaratmamaq üçün bütün işləri eyni prioritetdə saxlayırdı. Nəticədə komanda hansı işin həqiqətən vacib olduğunu ayırd edə bilmirdi. Prioritetləşdirmə edilmədikdə fokus itir, resurslar xırda hissələrə bölünür və məhsul irəliləmir. Əslində prioritet verməmək də bir qərardır və bu qərar məhsulun tempini aşağı salır. Burada əsas səhv “hamını razı salmaq” yanaşmasını məhsul strategiyasından üstün tutmaq idi.
3. Regulyasiya arqument kimi istifadə olundu, həll kimi yox
Bir çox bankda “tənzimləyici icazə vermir” cümləsi müzakirəni bağlayan arqumentə çevrilir. Bir halda PO bu arqumenti araşdırmadan qəbul etmişdi və alternativ yolları nəzərdən keçirməmişdi. Halbuki regulyasiyanın çərçivəsi daxilində fərqli dizayn həlləri mövcud idi. Regulyasiya məhsulun qarşısını alan baryer yox, nəzərə alınmalı məhdudiyyətdir. Yaxşı PO bu məhdudiyyətləri dizayn inputu kimi istifadə edir. Regulyasiyanı müzakirəsiz qəbul etmək məhsulun innovasiya imkanlarını məhdudlaşdırır.
4. İT nə desə, qərar o oldu
Bir məhsulda texniki komanda “bu çox çətindir” dedikdən sonra PO mövzunu bağladı. Funksiya yenidən analiz edilmədi, sadələşdirilmədi və mərhələli icra variantları müzakirə olunmadı. Texniki risk biznes dəyəri ilə balanslaşdırılmadı. Bir müddət sonra eyni funksiya başqa bankda daha sadə formada istifadəyə verildi. Bu da göstərdi ki, problem mümkünsüzlükdə yox, yanaşmada idi. Texniki çətinliyi son söz kimi qəbul etmək məhsul liderliyinin zəifləməsidir.
5. KPI yox idi, amma nəticə gözlənirdi
Məhsul istifadəyə verildi, lakin onun uğurunun necə ölçüləcəyi əvvəlcədən müəyyən edilməmişdi. Hansı metriklərin dəyişməsi lazım olduğu və hansı davranışın dəyər yaratdığı bilinmirdi. Məhsul “işləyirdi”, amma effektivliyi naməlum idi. Ölçülməyən məhsul idarə edilə bilməz. KPI-lar olmadan optimizasiya təsadüfi xarakter daşıyır. Buradakı əsas səhv nəticəni ölçmədən nəticə gözləmək idi.
6. Pilot yox, birbaşa böyük həll
Bir bankda məhsul birbaşa bütün müştərilərə açıldı və pilot mərhələ nəzərdə tutulmadı. Nəticədə zəng mərkəzinə yük artdı və istifadəçi narazılığı yüksəldi. Geri addım atmaq isə həm reputasiya, həm də texniki baxımdan çətinləşdi. Halbuki kiçik pilot mərhələ ilə risklər erkən aşkar edilə bilərdi. Pilot məhsulun öyrənmə mərhələsidir, satış mərhələsi deyil. Burada əsas səhv sürəti öyrənmədən üstün tutmaq idi.
7. Məhsulu bağlamaq məğlubiyyət sayıldı
Bir məhsul gözlənilən nəticəni vermirdi və bütün göstəricilər bunu açıq şəkildə göstərirdi. Buna baxmayaraq PO emosional olaraq məhsula bağlanmışdı. “Bəlkə növbəti releasdə düzələr” yanaşması ilə proses uzadıldı. Nəticədə zaman və resurs itirildi. Halbuki məhsulu vaxtında bağlamaq bəzən ən doğru strateji qərardır. Dayandırma qərarını məğlubiyyət kimi görmək məhsul düşüncəsinə ziddir.
Təcrübə göstərir ki, Yaxşı Məhsul Sahibi hər deyiləni icra etmir, hər riski bloklamır və hər funksiyonallığı qorumağa çalışmır.
Toğrul Xəlilov, Məhsul sahibi.
