IT kompaniyalarning vakansiyalarida "Product Owner" lavozimi tez-tez uchraydi. Nomi "mahsulot egasi" deb tarjima qilinadi, lekin bu odam mahsulotga egalik qilmaydi va jamoaning boshlig'i ham emas. Unda u aslida nima qiladi?
Bu maqolada Product Owner rolini amaliy tomondan ko'rib chiqamiz: uning asosiy vositasi bo'lgan backlog, user story qanday yoziladi, vazifalar qanday ustuvorlashtiriladi va bu rolga qanday kirish mumkin.
Scrum'da Product Owner qayerda turadi
Scrum bu jamoa qisqa davrlarda (sprintlarda, odatda 1–4 hafta) ishlaydigan va har bir sprint oxirida ishlaydigan natija ko'rsatadigan ish usuli. Scrum jamoasida uchta mas'uliyat bor:
- Developers: mahsulotni yaratadigan jamoa (dasturchilar, dizaynerlar, testerlar).
- Scrum Master: jarayon to'g'ri ishlashi va jamoaga hech narsa xalaqit bermasligi uchun javob beradi.
- Product Owner: jamoa yaratayotgan narsaning qiymati uchun javob beradi.
Oddiy qilib aytganda, jamoa "qanday qilamiz?" degan savolga javob beradi, Product Owner esa "nimani va qaysi tartibda qilamiz?" degan savolga.
Asosiy vosita: product backlog
Product Owner ishining markazida product backlog turadi. Bu mahsulotda qilinishi kerak bo'lgan hamma narsaning yagona, tartiblangan ro'yxati: yangi funksiyalar, xatolarni tuzatish, texnik yaxshilanishlar, tadqiqotlar.
Backlog bilan ishlash uch qismdan iborat:
- Yaratish. Foydalanuvchilar, mijozlar, rahbariyat va jamoadan kelgan g'oyalar va ehtiyojlarni yig'ib, backlog elementlariga aylantirish.
- Tartiblash. Eng qimmatli ishni ro'yxat tepasiga qo'yish. Jamoa har doim yuqoridan boshlab oladi, shuning uchun tartib Product Owner'ning eng muhim qarori.
- Aniqlashtirish (refinement). Tepadagi elementlarni jamoa bilan birga muhokama qilish, savollarga javob berish, katta vazifalarni kichiklarga bo'lish. Sprint boshlanganda jamoa nima qilish kerakligini tushunib turishi kerak.
Backlog hech qachon "tayyor" bo'lmaydi. Mahsulot, bozor va foydalanuvchilar o'zgargan sari u ham doim yangilanib boradi.
User story qanday yoziladi
Backlog elementlari ko'pincha user story ko'rinishida yoziladi. User story funksiyani texnik tilda emas, foydalanuvchi nuqtai nazaridan tasvirlaydi. Klassik shablon:
Foydalanuvchi sifatida men nimanidir qilishni istayman, chunki bu menga qandaydir foyda beradi.
Masalan, onlayn kurslar platformasi uchun:
O'quvchi sifatida men darsni keyinroq ko'rish uchun saqlab qo'yishni istayman, chunki ish kunida darsni oxirigacha ko'rishga har doim ham vaqtim bo'lmaydi.
Shablonning uchinchi qismi, "chunki", eng muhimi. U jamoaga funksiya nima uchun kerakligini tushuntiradi. Sababni bilgan jamoa ko'pincha Product Owner o'ylagandan ham yaxshiroq yechim taklif qiladi.
Yomon va yaxshi yozilgan story farqi:
| Yomon | Yaxshi |
|---|---|
| "Saqlash tugmasini qo'shish" | O'quvchi sifatida darsni saqlab qo'yishni istayman, chunki uni keyinroq ko'rmoqchiman |
| "Bazaga yangi jadval" | Bu texnik vazifa: u qaysi foydalanuvchi ehtiyojiga xizmat qilishi yozilmagan |
| "Profil sahifasini yaxshilash" | O'qituvchi sifatida o'quvchining progressini bir sahifada ko'rishni istayman, chunki kim ortda qolayotganini tez aniqlashim kerak |
| "Hammasi tez ishlasin" | O'quvchi sifatida dars sekin internetda ham ochilishini istayman, chunki men mobil internetdan foydalanaman |
Acceptance criteria: "tayyor" nimani anglatadi
User story qachon bajarilgan hisoblanadi? Buni acceptance criteria, ya'ni qabul qilish shartlari belgilaydi. Ular bo'lmasa, dasturchi, tester va Product Owner "tayyor"ni har xil tushunishi mumkin.
Shartlarni yozishning qulay usullaridan biri Given / When / Then shabloni. O'zbekchada uni shunday o'qish mumkin: berilgan holat, qachonki foydalanuvchi biror narsa qiladi, unda natija shunday bo'ladi.
Yuqoridagi "darsni saqlash" story'si uchun:
- Berilgan: o'quvchi tizimga kirgan va dars sahifasida turibdi. Qachonki: "Saqlash" tugmasini bossa. Unda: dars "Saqlanganlar" ro'yxatida paydo bo'ladi.
- Berilgan: dars allaqachon saqlangan. Qachonki: o'quvchi tugmani yana bossa. Unda: dars ro'yxatdan olib tashlanadi.
- Berilgan: o'quvchi tizimga kirmagan. Qachonki: "Saqlash" tugmasini bossa. Unda: unga tizimga kirish taklif qilinadi.
Ko'rib turganingizdek, shartlar nafaqat asosiy holatni, balki chekka holatlarni ham qamrab oladi. Aynan chekka holatlarni oldindan o'ylash Product Owner'ning jamoaga eng katta yordamlaridan biri.
Ustuvorlashtirish: nimani birinchi qilish kerak
G'oyalar doim resursdan ko'p bo'ladi. Shuning uchun Product Owner har kuni "hozir nima muhimroq?" degan savolga javob beradi. Bunga yordam beradigan ikkita oddiy usul bor.
MoSCoW usuli. Har bir element to'rt guruhdan biriga ajratiladi:
- Must have: bo'lishi shart, usiz reliz ma'nosiz.
- Should have: muhim, lekin bir muddat kutsa bo'ladi.
- Could have: bo'lsa yaxshi, vaqt qolsa qilinadi.
- Won't have (this time): bu safar qilinmaydi, va buni ochiq aytamiz.
Qiymat va mehnat. Har bir elementni ikki savol bo'yicha baholaysiz: foydalanuvchi va biznes uchun qanchalik qimmatli, jamoa uchun qanchalik ko'p mehnat talab qiladi. Birinchi navbatda "qiymati yuqori, mehnati kam" ishlar olinadi. "Qiymati past, mehnati ko'p" ishlar esa ko'pincha umuman qilinmaydi.
Bu usullarning hech biri qarorni Product Owner o'rniga qabul qilmaydi. Ular faqat muhokamani tartibga soladi va qarorni boshqalarga tushuntirishni osonlashtiradi.
Sprint davomida Product Owner
Product Owner Scrum tadbirlarida faol qatnashadi:
- Sprint planning. Sprint maqsadini taklif qiladi va backlog'ning tepasidagi elementlarni jamoaga tushuntiradi. Jamoa esa shu sprintda qancha ish ola olishini o'zi baholaydi.
- Sprint davomida. Jamoaning savollariga tez javob beradi. Product Owner topilmay qolsa, jamoa taxmin bilan ishlashga majbur bo'ladi.
- Sprint review. Tayyor natijani stakeholder'lar bilan birga ko'rib chiqadi, fikr-mulohazalarni yig'adi va shunga qarab backlog'ni yangilaydi.
Biznes va jamoa o'rtasidagi ko'prik
Product Owner bir tomondan rahbariyat, sotuv, marketing va mijozlarni, ikkinchi tomondan ishlab chiqish jamoasini tinglaydi. Uning vazifasi hamma istagini bajarish emas, balki shu istaklar ichidan eng qimmatlisini tanlash.
Shuning uchun bu rolda eng qiyin ko'nikmalardan biri "yo'q" deyish. Har bir "ha" boshqa biror narsaga "yo'q" degani, chunki jamoaning vaqti cheklangan. Yaxshi Product Owner rad etganda sababini tushuntiradi va g'oyani butunlay o'chirib tashlamay, backlog'da o'z o'rniga qo'yadi.
Qiymatni o'lchash ham shu yerda muhim. Funksiya chiqarildi, lekin foydalanuvchilar undan foydalanyaptimi? Qaytib kelyaptimi? Muammo hal bo'ldimi? Product Owner "chiqarildi"ni emas, "foyda berdi"ni muvaffaqiyat deb hisoblaydi.
Product Owner va Product Manager
Bu ikki rol ko'p kompaniyalarda yonma-yon ishlaydi va ba'zan bitta odam ikkalasini bajaradi. Qisqa qilib aytganda, Product Manager ko'proq uzoq muddatli strategiya va bozor bilan, Product Owner esa shu strategiyani jamoa uchun aniq backlog'ga aylantirish bilan shug'ullanadi. Batafsil farqni Product Manager va Project Manager farqi maqolasida yozganmiz, unda Product Owner'ga ham alohida bo'lim bor.
Ko'p uchraydigan xatolar
- "Vazifa tarqatuvchi" bo'lib qolish. Product Owner jamoaga kim nima qilishini aytmaydi. U nima muhimligini aytadi, qanday qilishni jamoa o'zi hal qiladi.
- Qiymatsiz story'lar. "Chunki" qismi bo'lmagan yoki "chunki buni rahbar so'radi" deb yozilgan story jamoaga hech narsa tushuntirmaydi.
- Backlog'ni axlatxonaga aylantirish. Har bir g'oya yozib qo'yiladi, lekin hech qachon o'chirilmaydi. Natijada yuzlab eskirgan elementlar muhim ishni ko'mib tashlaydi. Bir necha oydan beri tegilmagan elementlarni vaqti-vaqti bilan tozalash kerak.
- Jamoadan uzoqlashish. Faqat sprint boshida va oxirida paydo bo'ladigan Product Owner jamoani noaniqlik ichida qoldiradi.
- Hamma narsaga "ha" deyish. Ustuvorlik yo'q joyda hamma narsa "shoshilinch" bo'lib qoladi.
Bu rol kimga mos
Product Owner bo'lishingiz uchun dasturchi bo'lish shart emas. Quyidagi xususiyatlar ko'proq muhim:
- odamlarni tinglash va ularning asl ehtiyojini topa bilish;
- murakkab narsani sodda va aniq yozish;
- qaror qabul qilish va uni dalillar bilan himoya qilish;
- bosim ostida ham xotirjam muloqot qilish;
- tafsilotlarga e'tibor: chekka holatlarni oldindan o'ylash.
Bu rolga ko'pincha biznes-analitiklar, loyiha koordinatorlari, mijozlar bilan ishlagan mutaxassislar va Scrum jamoalarida ishlagan odamlar o'tishadi.
Qanday boshlash mumkin
- Scrum Guide'ni o'qing. Bu Scrum'ning rasmiy qisqa qo'llanmasi, u bepul va bir necha soatda o'qiladi.
- O'zingiz ishlatadigan ilova uchun story yozing. Masalan, taksi yoki yetkazib berish ilovasini oling va unga yetishmayotgan 10 ta funksiyani user story va acceptance criteria bilan yozing.
- Backlog tuzing. Shu story'larni Jira yoki Trello'da backlog qilib joylang va MoSCoW bo'yicha tartiblang. Har bir qaroringizni bir gap bilan asoslang.
- Fikr so'rang. Tanishlaringizdan kimdir dasturchi bo'lsa, story'laringizni o'qib chiqishini so'rang: ular nimani tushunmadi, qanday savollar tug'ildi?
Tizimli o'rganmoqchi bo'lsangiz, Yangi Avlod Akademiyasida Product Owner kursi bor. Kurs 2 oy davom etadi, boshlang'ich darajaga mo'ljallangan va onlayn, haftasiga 2 marta o'tadi. Dasturda Scrum va Product Owner roli, backlog boshqaruvi va ustuvorlashtirish, user story va acceptance criteria, sprint rejalashtirish va review hamda biznes qiymatini o'lchash bor.
Xulosa
Product Owner jamoaning vaqti eng qimmatli ishga sarflanishi uchun javob beradi. Uning asosiy vositalari oddiy: tartiblangan backlog, aniq user story'lar va tushunarli qabul qilish shartlari. Qiyinligi esa boshqa joyda: doimiy tanlov qilish, "yo'q" deyish va biznes bilan jamoa o'rtasida ishonch saqlash.
Odamlarning ehtiyojini tushunish va uni aniq vazifalarga aylantirish sizga yoqsa, Product Owner roli sinab ko'rishga arziydi.
