İnkişaf

Sıfırdan SaaS: ilk relizə nələr daxildir

SaaS-ın ilk relizi kəsilmiş məhsul deyil, bir işləyən ssenarisi olan məhsuldur. Nəyin məcburi olduğunu, nəyi təxirə salmaq mümkün olduğunu və bunun nə ilə ödənildiyini təhlil edirik.

30 avqust 2026

SaaS-ın ilk versiyası demək olar ki, həmişə funksiyalar siyahısı ilə müzakirə olunur, amma onu ssenaridən qurmaq lazımdır. Fərq prinsipialdır: funksiyalar siyahısını istənilən şeyə qədər kəsib istifadə edilə bilməyən məhsul almaq olar, ssenari isə ya tamamilə işləyir, ya da ümumiyyətlə işləmir. Aşağıda ilk relizdə nəyin məcburi olduğu, nəyin zərərsiz təxirə salındığı və hər "sonra"nın dəqiq nə ilə ödənildiyi var.

Minimal faydalı məhsul — bir başdan-başa ssenaridir

Müştərinin sizə gələcəyi əsas işi götürün və onu yan yollar olmadan sona çatdırın. Məhsul müraciətlərin uçotuna kömək edirsə — deməli, müraciəti yaratmaq, dəyişmək, tapmaq və bağlamaq olar. Hesabatlarla bağlıdırsa — məlumatları yükləmək, baxmaq və ixrac etmək olar.

Ssenarinin natamam olduğunun əlaməti: nümayişdə "bunu hələlik əl ilə edirik" demək lazım gəlir. Belə bir yer məhsulu xidmətə çevirir və müştəri proqram təminatına deyil, sizin əl ilə müşayiətinizə ödəyir. Bəzən başlanğıcda bu, şüurlu strategiyadır, amma bunu faktla deyil, açıq həll etmək lazımdır.

Praktik üsul: ilk relizi funksiyalarla deyil, "müştəri daxil olur və bir seansda belə nəticə alır" cümləsi ilə təsvir edin. Bu cümlədə iştirak etməyən hər şey növbəti versiyaya namizəddir.

Qeydiyyat, hesablar və rollar

Ən çox uğursuz qənaət burada edilir. SaaS-da istifadəçi demək olar ki, heç vaxt tək deyil: müştərinin şirkəti var, orada bir neçə nəfər var, onların fərqli hüquqları var.

Artıq görünsə belə, dərhal daxil etməyə dəyənlər:

"Şirkət hesabı" və "istifadəçi" bölgüsü. Bunu sonra dəyişmək məlumat modelini və bütün sorğuları yenidən yazmaq deməkdir. Başlanğıcda hər şirkətdə bir nəfər olsa belə, təşkilat mahiyyəti mövcud olmalıdır.
Həmkarları e-poçtla dəvət etmək. Bu olmadan məhsul müştərinin daxilində böyümür, SaaS isə adətən məhz belə böyüyür.
Ən azı iki rol: sahib və iştirakçı. Ətraflı hüquq sistemini təxirə salmaq olar, amma məlumatları silmək və tarifi dəyişmək hüququ hamıda olmamalıdır.
Parolun bərpası və e-poçtun dəyişdirilməsi. Darıxdırıcıdır, amma bu olmadan dəstək bunu bazada əl ilə etməyə başlayır.

Nəyi təxirə salmaq olar: xarici xidmətlər vasitəsilə giriş, korporativ müştərilər üçün vahid giriş, iki faktorlu autentifikasiya, hərəkətlər jurnalı. Bunların hamısı hazır istifadəçi modelinin üzərinə yenidən qurmadan əlavə olunur.

Tariflər, sınaq müddəti, billinq

Tarif modeli koda marketinqdən çox təsir edir, buna görə onu başlanğıca qədər deyil, hazırlanmadan əvvəl müəyyən etmək lazımdır.

Əsas sual: nəyə görə pul alırıq. Variantlar azdır və onlar məhsula fərqli oturur.

İstifadəçiyə görə. Hesablamaq ən sadədir, müştəriyə anlaşılandır, amma həmkarları dəvət etməyə görə cəzalandırır — sizə isə məhz bu lazımdır.
Həcmə görə. Qeydlərin, layihələrin, müraciətlərin sayı. Məhsulda ilk gündən sayğaclar tələb edir: geriyə dönük hesablamaq olmaz.
İmkanlar dəstinə görə. Bu halda kodda funksiyanın tarif üzrə əlçatanlığının yoxlamaları yaranır və onları ekranlara səpələmək deyil, bir yerdə etmək lazımdır.

Modeldən asılı olmayaraq, ilk relizdə olmalıdır: tarif üzrə məhdudiyyətin özü, onun tükənməsində anlaşılan davranış və daha yüksək plana keçid. Heç yerdə işə düşməyən məhdudiyyət tarif deyil, saytdakı yazıdır.

Sınaq müddəti. Son gün nə baş verdiyini əvvəlcədən həll edin. Məlumatlar dondurulur və ödəniş gözləyir? Müəyyən müddətdən sonra silinir? Hesab məhdud imkanlarla pulsuz plana keçir? Bu, xırdalıq deyil: giriş məntiqi və müştəriyə gedən məktublar cavabdan asılıdır. Cavabın olmaması müddəti bitmiş hesabların əbədi yaşamasına və əl ilə söndürülməsinə gətirib çıxarır.

Ödəniş. İlk versiyada bir ödəniş qəbulu üsulu və bir valyuta kifayətdir. Həqiqətən dərhal lazım olan — uğursuz silinmənin və təkrar cəhdlərin düzgün emalı, həmçinin hüquqi şəxslərlə işləyirsinizsə, onlar üçün bağlayıcı sənədlərdir. Mürəkkəb sxemlər — ayın ortasında tarif dəyişdikdə mütənasib yenidən hesablama, promokodlar, tərəfdaş ayırmaları — rahat təxirə salınır.

Müştəri məlumatlarının təcridi

Bu, səhvin yeniləmə ilə müalicə olunmadığı hissədir. SaaS-da müxtəlif şirkətlərin məlumatları bir sistemdə yerləşir və onları ayıran yeganə şey sizin kodunuzdur.

SaaS-da bir müştərinin məlumatlarının digərinə sızması baq deyil, məhsulun sonudur. Təcridi biznes məntiqinin ilk sətrindən əvvəl layihələndirmək lazımdır.

Praktik minimum:

Müştəri məlumatları olan hər cədvəldə təşkilat identifikatoru var və o, qeyri-məcburi deyil.
Təşkilat üzrə filtr hər sorğuya əl ilə deyil, sorğunun aşağısına gedə bilməyəcəyi səviyyədə qoyulur. Əl intizamı burada işləmir: gec-tez bir sorğunu filtrsiz yazacaqlar.
Hüquqlar serverdə yoxlanılır. İnterfeysdə gizlədilmiş düymə heç nəyi qorumur.
Obyektlərin identifikatorları ardıcıl rəqəmlər olmamalıdır: ünvanda qonşu rəqəmi qoymaq istənilən maraqlı istifadəçinin etdiyi ilk şeydir.
Müştərilərin yüklədiyi fayllar bazadakı qeydlərlə eyni bölgü ilə saxlanılır və birbaşa proqnozlaşdırıla bilən keçidlə verilmir.

Silinmə məsələsini də dərhal həll etməyə dəyər: müştəri gedəndə nə baş verir. Məlumatlar tamamilə silinir, məhdud müddət saxlanılır və ya sorğu üzrə ona ixrac edilir. Öz məlumatlarını götürmək imkanı həm də satışda arqumentdir. Müşayiət edən kontur — ehtiyat nüsxələr, monitorinq, yeniləmələr — təhlükəsizlik bölməsində təhlil olunur.

Məhsulun hissəsi kimi dəstək və yeniləmələr

SaaS sifarişli hazırlanmadan onunla fərqlənir ki, hamıda versiya birdir və o, sizindir. Bu, həyatı sadələşdirir və öhdəliklər əlavə edir.

Müraciət kanalı. E-poçt və ya interfeysdə çat. Əsas odur ki, müraciət onu görəcəkləri yerə düşsün və müştəri cavabı nə vaxt gözləyəcəyini başa düşsün.
Müşahidə imkanı. Loqlar, çökmələr barədə xəbərdarlıqlar, səhvlərin izlənməsi. Bu olmadan nasazlıq barədə müştəridən öyrənirsiniz, üstəlik ilk qarşılaşandan deyil, ən səbirlisindən.
Fasiləsiz yayımlama. Yeniləmələr tez-tez gedir və hər biri müştərilərin işini dayandırmamalıdır. Bu, relizlər cədvəlinə deyil, arxitekturaya tələbdir.
Bərpa ilə yoxlanılmış ehtiyat nüsxələr. Ondan bir dəfə də sistem qaldırılmamış nüsxə nüsxə deyil, fərziyyədir.
Dəyişikliklər barədə qeydlər. Nəyin dəyişdiyinin qısa siyahısı. Məhsulun yaşadığını göstərməyin ucuz üsuludur.

Öz komandanız üçün inzibati panel də ilk relizə aiddir: hesabı tapmaq, tarifə baxmaq, sınaq müddətini uzatmaq, girişi söndürmək. Onsuz hər müraciət verilənlər bazasına yürüşə çevrilir.

Nəyi təhlükəsiz təxirə salmaq olar

İşləyən əsasın üzərinə əlavə olunan və məlumat modelinin yenidən qurulmasını tələb etməyən hər şeyi təxirə salmaq olar:

mobil tətbiq — adaptiv interfeys başlanğıcı bağlayır;
açıq API və xarici xidmətlərlə inteqrasiyalar;
məhsul daxilində qabaqcıl analitika — baza rəqəmlər kifayətdir;
müştəriyə görə ayarlar: öz domeni, loqo, xüsusi sahələr;
ilk müştərilər bir dildə danışırsa, çoxdillilik;
marketinqin avtomatlaşdırılması və mürəkkəb məktub hunları.

Bu siyahıda nəyin olmadığına diqqət yetirin: məlumatların təcridi, rollar, istehlakın uçotu, ehtiyat nüsxələr. Bu, təməldir və onu canlı müştərilərin altında tamamlamaq dərhal etməkdən bahadır.

Hazırlanmaya başlamazdan əvvəl yoxlama siyahısı

Müştərinin sizin iştirakınız olmadan tamamilə keçdiyi bir başdan-başa ssenari ifadə olunub.
Nəyə görə pul alındığı həll olunub və məhsulda bu kəmiyyətin sayğacı var.
Sınaq müddətinin son günündə və uğursuz ödənişdə davranış təsvir olunub.
Məlumat modeli əvvəldən yalnız istifadəçi deyil, təşkilat barədə də bilir.
Müştəri məlumatlarının təcridi proqramçı intizamı ilə deyil, bazaya giriş səviyyəsində edilib.
Dəstək üçün daxili panel və müştərilərin yazdığı kanal var.
Ehtiyat nüsxələr var və onlardan bərpa heç olmasa bir dəfə yoxlanılıb.

1 və 2-ci bəndlər üzrə cavablar dumanlıdırsa, hazırlanmaya başlamaq tezdir: məhsulun əsasına hansı sayğacların və məhdudiyyətlərin tikiləcəyini məhz onlar müəyyən edir. Belə layihələri mərhələlərə necə böldüyümüz — SaaS hazırlanması bölməsində.