Dasturiy taʼminot muhandisi va mahsulot muhandisi: fikrlash tarzi, koʻrsatkichlardagi farqlar va katta oʻzgarishlar

Hayotingizda biror marta kodlari mukammal yozilgan, lekin hech kimga foydasi tegmagan ficha yaratganmisiz? Men shunaqa qilganman 😅. Bu narsa menga dasturiy taʼminot muhandisi va mahsulot muhandisi oʻrtasidagi asosiy farqni tushuntirib bergan. Bu ikkovi bitta majlisda yonma-yon oʻtirishi mumkin. Biroq ularning muammolarga yondashuvi va “muvaffaqiyat”ga boʻlgan qarashi, taʼrifi bir-biridan tubdan farq qiladi.

Yondashuv va eʼtibor: “Qanday qurish kerak?” va “Nima uchun (va nimani) qurish kerak?”

Dasturiy taʼminot muhandislari (software engineer) koʻpincha “Buni qanday qilib toʻgʻri qurish mumkin?” deya savol beradi. Ularning komfort zonasi – kod yozish: arxitektura, algoritmlar, toza kod va samaradorlik. Ular berilgan funksiyani qanday qilib texnik mukammal darajada amalga oshirishni oʻrganadi. Mahsulot muhandislari (product engineer) bundan farqli ravishda “Nima uchun buni ishlab chiqyapmiz va aynan nimani yaratishimiz kerak” savoli bilan ishni boshlaydi. Ular mahsulotning butun holatini va foydalanuvchi kontekstini koʻrish uchun kengroq qaraydi. Mahsulot muhandisi (product engineer) kod yozishdan oldin funksiya haqiqatdan ham foydalanuvchi muammosini hal qila olishi yoki bozor ehtiyojlariga javob berishiga ishonch hosil qilish uchun uni sinab koʻradi. Bu dasturni toʻgʻri ishlab chiqish va toʻgʻri dasturni ishlab chiqish oʻrtasidagi farqdir.

Kichik bir misol. Mijoz hisobot tayyorlab beradigan dastur yaratishni soʻradi. Dasturiy taʼminot muhandisi bu ishni qilish uchun darrov eng yaxshi maʼlumotlar bazasi yoki freymvorkni koʻrib chiqishi mumkin. Mahsulot muhandisi esa hisobotdan foydalanadiganlarga aslida nima kerakligini aniqlaydi. Oddiyroq yechim (yoki umuman yangi funksiya qo‘shmaslik) ham asosiy ehtiyojni qondira oladimi yoki yo‘qmi, degan savolni o‘rtaga tashlaydi. Faqat shundan keyingina “Buni qanday qurish kerak” degan reja tuziladi. “Muammo birinchi o‘rinda” va “yechim birinchi o‘rinda” fikrlash tarzlari kundalik ish jarayonida bir-biridan butunlay farq qiladigan yondashuvlarga olib keladi.

Muvaffaqiyat oʻlchovi: natija va samara

Mana shu yerda fikrlash tarzi haqiqatdan ham oʻzgaradi. Dasturiy taʼminot muhandisi sifatida faoliyatimning boshida men muvaffaqiyatni natija (output) bilan o‘lchardim: kod xatosiz ishladimi? Biz ishni o‘z vaqtida topshirdikmi? Tizim tez va barqaror ishlayaptimi? Kod sifati va yetkazib berish tezligi mening asosiy ko‘rsatkichlarim edi. Ammo mahsulotga yo‘naltirilgan muhandislik (product engineering) roliga o‘tganimda “g‘alaba” haqidagi tushunchamni qaytadan ko‘rib chiqishimga to‘g‘ri keldi. Mahsulot muhandisi uchun muvaffaqiyat shunchaki kodni yetkazib berish emas. Bu – foydalanuvchi muammosini hal qilish va biznes uchun sezilarli o‘zgarish qilishdir. Bu foydalanuvchilar faolligining oshishi, ro‘yxatdan o‘tishlar sonining ko‘payishi yoki daromad maqsadiga erishishni anglatishi mumkin. Hatto yechim juda tez yozilgan sodda narsa bo‘lsa ham.

Boshqacha aytganda, dasturiy ta’minot muhandisi haftalab ustida ishlagan murakkab algoritmini muvaffaqiyatli ishga tushirganini bayram qiladi. Mahsulot muhandisi esa mana shu funksiya haqiqatan ham asosiy ko‘rsatkichni oshirganda yoki mijozning hayotini osonlashtirganda quvonadi. Ular uchun kod bu – maqsad emas, balki ana shu maqsadga erishish vositasidir. Bu, shuningdek, mahsulot muhandislari zarur bo‘lganda biznesga ta’sir ko‘rsatish uchun texnik mukammallikdan voz kechishga tayyorligini anglatadi. (Bozor o‘zgarib borayotgan bir paytda bir chekkada kodga jilo berib oʻtirgandan ko‘ra foydalanuvchi fikrini olish uchun bugunning o‘zida soddaroq versiyani ishga tushirish va uni keyinroq takomillashtirish afzalroqdir.)

Fikrlash tarzining oʻzgarishi: kod MVPʼdan mahsulot MVPʼga

Sof dasturiy ta’minot muhandisligidan mahsulot muhandisligi roliga o‘tish fikrlash tarzini tubdan o‘zgartirishni talab qiladi. Ko‘p yillik tajribaga ega dasturchilarning mahsulot uchun mas’uliyatni o‘z zimmasiga olishda qiynalayotganiga guvoh bo‘lganman. Bu qiyinchilik oʻzimning boshimdan ham oʻtgan. Bunaqa payt birdan jamoadagi eng yaxshi kod yozadigan dasturchi boʻlishning oʻzi yetarli boʻlmay qoladi. Endi siz mijozning muammolari, bozorga mosligi va har bir oʻzgarish ortidagi “Nega?” degan savol haqida ham oʻylashingiz kerak boʻladi.

Boʻlgan voqea: bir necha hafta davomida optimal ishlash uchun kompaniya ichidagi dasturni qayta ishlab chiqdim. Bu texnik sanʼat asari edi (har holda men shunday deb o‘ylagandim!), ammo foydalanuvchilar undan deyarli foydalanmas ekan 🤦‍♂️. Dasturiy ta’minot muhandisi sifatida mukammal yechimdan faxrlangandim. Mahsulot muhandisi sifatida esa bu ishning qiymatini foydalanuvchilarning boshqa muhim ehtiyojlari bilan solishtirib koʻrgan va, ehtimol, uning o‘rniga muhimroq funksiyani yaxshilashni tanlagan bo‘lardim. “Foyda keltirish > mukammallik” formulasini tushunish fikrlash tarzining o‘zgarishidir. Kod yozishni yaxshi koʻrsangiz, bu tushuncha biroz qiyin boʻladi. Lekin ishingiz foydalanuvchilar hayotida o‘zgarish yasayotganini ko‘rish hammasiga arziydi.

Mahsulot muhandisligi yo‘nalishida harakat qilayotgan boʻlsangiz, fikrlash tarzingizda bir nechta o‘zgarishlar boʻlishi kutiladi:

• Faol izlanish. Siz tayyor, batafsil texnik topshiriqni kutib o‘tirmasdan, uning shakllanishida bevosita hamkorlik qilasiz. Foydalanuvchilar bilan gaplashasiz yoki hech bo‘lmaganda voqelikka ularning nigohi bilan qarashga harakat qilasiz. (Ha, siz mijozga qo‘ng‘iroq qilishingiz yoki foydalanuvchilar tahlili ma’lumotlariga ko‘z yugurtirishingizga to‘g‘ri kelishi mumkin!)

• Yaxlit fikrlash. Texnik qarorlarni foydalanuvchi tajribasi va biznes qiymati bilan taqqoslay boshlaysiz. Hattoki o‘zingizga o‘zingiz: “Menda ajoyib texnik g‘oya bor, lekin u haqiqiy muammoni hal qiladimi?” deb savol berayotganingizni sezib qolasiz.

• Noaniqlik bilan ishlay olish. Hamma savolning ham oldindan javobi aniq boʻlavermaydi. Mahsulot muhandislari ko‘pincha tajriba o‘tkazadi va jarayonni takrorlaydi — tezkor prototip yaratadi, fikr-mulohazalarni to‘playdi, o‘rganadi. An’anaviy dasturiy ta’minot muhandisligi esa ba’zan belgilangan talablar va “tayyor” mezonlar bilan yanada aniqroq tuyulishi mumkin.

Kundalik ta’sir: har bir commitʼda biznes konteksti

Amaliy jihatdan, mahsulotga yoʻnaltirilgan fikrlashni qabul qilish kundalik ish jarayoningizni oʻzgartiradi. Dasturiy ta’minot muhandisi kunlik yutuqlarini Jira vazifalari yoki oʻtkazilgan test holatlari bilan oʻlchashi mumkin. Mahsulot muhandisi esa, aksincha, ish kunini kechagi foydalanuvchilarning roʻyxatdan oʻtish koʻrsatkichlarini yoki oxirgi chiqarilgan funksiya boʻyicha bildirilgan fikr-mulohazalarni koʻrib chiqishdan boshlashi va shunga qarab vazifalarining ustuvorligini oʻzgartirishi mumkin.

Biznes konteksti doimiy hamrohga aylanadi. Masalan, xatolik haqida hisobot kelib tushganda dasturiy ta’minotga yo‘naltirilgan fikrlash “Bu xatolikni tezroq tuzataylik” boʻlishi mumkin. Mahsulotga yo‘naltirilgan yondashuvda esa “Bu xatolik qancha foydalanuvchiga ta’sir qilyapti? U bizning asosiy mijozlar segmentimizga yoki eng muhim jarayonga zarar yetkazyaptimi?” savoli beriladi. Agar xatolik kichikroq, o‘sha vaqtda yanada muhimroq vazifa bor bo‘lsa, mahsulot muhandisi avvalroq samarasi yuqori bo‘lgan ishni bajarib, xatoni keyinroq tuzatishga qaror qilishi mumkin. Bu sifatga e’tibor bermaslik emas, bu – strategik ustuvorlikni belgilash demakdir.

Mahsulot haqida fikrlash, shuningdek, muhandis bo‘lmagan mutaxassislar bilan yaqindan ishlashni ham anglatadi. Mahsulotning to‘liq manzarasini tushunish uchun mahsulot menejerlari, dizaynerlar, hattoki savdo va marketing bo‘limlari bilan ko‘proq muloqot qilishga tayyor bo‘ling. Bunda sizga shunchaki tayyor yo‘l xaritasi berilmaydi, siz uni shakllantirishda bevosita yordam berasiz. Mening tajribamda bu muhandislik ishini yanada jamoaviy va, ochig‘ini aytsam, ancha qiziqarli qiladi. Siz biznes qarorlari qanday qabul qilinishi va foydalanuvchilar qanday o‘rganilishini ichkaridan ko‘rish imkoniga ega bo‘lasiz hamda o‘z texnik bilimlaringizni jarayonning eng boshidanoq kirita olasiz. (Bu dabdurustdan sizni chaqirib “Tez mana buning kodini yozib ber” deyishlaridan ancha koʻproq mamnuniyat hissini tuydiradi.)

Barchasini birlashtirish

Har ikkala rol ham juda muhim va ular bir-birini inkor qilmaydi. Aksincha, eng kuchli jamoalar chuqur texnik bilimga ega mutaxassislar va mahsulotga yo‘naltirilgan muhandislarning qorishmasidan iborat bo‘ladi, ular bir-biridan ko‘p narsani o‘rganadi. Dasturiy ta’minot muhandisi sifatida vaqti-vaqti bilan klaviaturadan uzoqlashib “Hozir vaqtimni sarflashim uchun eng qimmatli narsa shu ishmi?” deb so‘rash foydadan holi emas. Mahsulot muhandisi sifatida esa sizda baribir mustahkam dasturlash ko‘nikmalari va sifatga nisbatan hurmat bo‘lishi lozim. Chunki agar kod doimiy ravishda xato beraversa, eng ajoyib mahsulot g‘oyasi ham uzoqqa bormaydi.

Xulosa o‘rnida: dasturiy ta’minot muhandisi sifatli dasturiy ta’minot yaratadi; mahsulot muhandisi esa dasturiy ta’minot yordamida ajoyib mahsulot yaratadi. Agar siz har ikkala fikrlash tarzini birlashtira olsangiz, yaratgan funksiyalaringiz ham texnik jihatdan mukammal, ham foydalanuvchi uchun haqiqatda foydali bo‘ladi.

Manba: “The Product-Minded Engineer”