Review prosesi: test hesabları, iradlar, iterasiyalar

1. Review prosesinə yüksək səviyyəli baxış

Store-da ChatGPT App dərc etmək — bu “linki yüklədim və unutdum” deyil, tamamilə canlı bir dövrdür. Sadələşdirilmiş şəkildə belə görünür: App-i hazırlayırsınız, review-ya göndərirsiniz, reviewer-lər onu öz yoxlama siyahıları üzrə keçirirlər, siz iradlar alırsınız, düzəliş edirsiniz və yenidən göndərirsiniz. Və bu, hamı razı qalana qədər bir neçə dəfə təkrarlana bilər.

Buna kiçik bir iş prosesi (workflow) kimi baxmaq ən rahatıdır:

flowchart TD
  A[Dev Mode / Internal beta] --> B[Submit to Store]
  B --> C[Under review]
  C -->|Approved| D[Published]
  C -->|Changes requested| E[Fixes & Iteration]
  E --> B
  D --> F[Updates]
  F --> C
  D --> G[Paused / Unpublished]

İlkin addımlarda (Dev Mode, daxili beta test) siz texniki və UX problemlərini tutursunuz. “Submit to Store” düyməsini basanda daha rəsmi review başlayır: kontent siyasətinə uyğunluq, icazələr, sabitlik və listing-lə hüquqi sənədlərdə yazılanlara baxılır.

Faydalı fəlsəfə belədir: review — bu nə “imtahanı ya keçdin və bir daha qayıtmayacaqsan”, nə də “kəsildin”. Bu, sizinlə platforma arasında daimi əks-əlaqə kanalıdır. Store istəyir ki, App-iniz təhlükəsiz, anlaşılan və sabit olsun, siz isə istifadəçilərə çıxış almaq və bir həftə sonra çıxarılmamaq istəyirsiniz. Sürpriz: maraqlarınız, əslində, üst-üstə düşür.

2. Review-a nə göndərirsiniz

Platforma tərəfində kimsə App-inizi açmazdan əvvəl, kifayət qədər banal bir dəst məlumatı doldurursunuz:

1. App metaməlumatları: ad, alt başlıq, kateqoriya, ikon.
2. Listing təsviri: qısa və tam təsvir, ssenari nümunələri.
3. Keçidlər: Privacy Policy, Terms, Support/Contact.
4. İcazə ayarları: App hansı girişləri tələb edir (məsələn, OAuth, xarici API-lər, ödəniş rejimləri və s.).
5. Bəzən — reviewer üçün test ssenarilərinin və hesablarının təsviri.
6. Elə App-in özü: MCP‑server, UI‑bundle, system‑prompt və platformanın artıq Dev Mode/production‑URL vasitəsilə bildiyi tools təsvirləri.

Texniki olaraq siz bu ana qədər artıq production versiyanı (adətən Vercel və ya analoqu) deploy edirsiniz ki, Store da məhz ora müraciət etsin. Yəni “Submit” düyməsi kodun deployu haqqında deyil, onun statusunun dəyişməsi haqqındadır: “bu kod artıq sizin production-da yaşayır, indi, zəhmət olmasa, onu yoxlayın və istifadəçilərə buraxın”.

Bütün hissələri birləşdirmək üçün, adətən, repozitoridə kiçik bir konfiqurasiya faylı saxlamaq rahat olur; burada “review namizədi” versiyaya nələrin daxil olduğunu açıq şəkildə fiks edirsiniz. Məsələn, sadə bir TypeScript strukturu:

// config/release-candidate.ts
export const releaseCandidate = {
  version: "1.0.0",
  apiBaseUrl: process.env.API_BASE_URL,
  enableCommerce: true,
  privacyPolicyUrl: "https://example.com/legal/privacy",
  termsUrl: "https://example.com/legal/terms",
  supportUrl: "https://example.com/support",
};

Belə bir fayl Store formalarının özünü əvəz etmir, amma komandanıza hazırda reviewer-lərə və istifadəçilərə nəyi “satdığınızı” başa düşməyə kömək edir.

3. Reviewer-lər App-ə necə baxırlar

Deməli, formaları doldurdunuz, keçidləri hazırladınız və Submit basdınız. Store-un o tərəfində nə baş verir? Təsəvvür edin ki, elə siz özünüz reviewer-siniz. Kodu görməmisiniz, layihənin tarixçəsini bilmirsiniz, amma əlinizdə bir yoxlama siyahısı və məhdud vaxt var. Adətən App-ə bir neçə rakursdan baxırlar.

Birinci növbədə, kontent siyasətinə və brendə uyğunluğa baxırlar. Qadağan olunmuş kateqoriyaları vermək olmaz, tibb, hüquq və ya maliyyə sahələrində lazımi disclaimer-lər və “human in the loop” olmadan qaydaları pozmaq olmaz. OpenAI kimi görünmək və ya onların brendini sanki rəsmi məhsullarıdırmış kimi istifadə etmək olmaz.

İkincisi, icazələr təhlil olunur. Əgər həssas nəyəsə (istifadəçi profilləri, ödənişlər, OAuth vasitəsilə üçüncü tərəf hesabı) giriş istəyirsinizsə, sizdən soruşacaqlar: bu, doğrudanmı lazımdır? Və istifadəçi bunu təsvirlərdən və App-in davranışından aydın başa düşürmü? İdeal hal — icazələrin minimum olması və təsvir edilən ssenarilərə tam uyğun gəlməsidir.

Üçüncüsü, UX və sabitlik qiymətləndirilir. App ChatGPT ekranını tam “ələ keçirməməlidir”: aydın izah olmadan hər fürsətdə fullscreen-ə keçməsi minusdur. Əgər backend mütəmadi olaraq xətalar atırsa, alətlər hərdən işləyib hərdən pozulursa, etibar da olmayacaq.

Nəhayət, listing-in dürüstlüyünə baxırlar: App təsviri reviewer-in söhbətdə real gördüyü ilə üst-üstə düşürmü. “İldırım sürətli ideal hədiyyə seçimi və ani checkout” vəd edirsinizsə, amma əslində App axtarış addımında üç dəfə yıxılır və sifariş rəsmiləşdirməyi bacarmırsa, review tez və kefsiz bitəcək.

Reviewer-lər üçün işi asanlaşdırmaq üçün əvvəlcədən onlara “marşrut” hazırlamaq məntiqlidir: yoxlanmalı addımların siyahısı və gözlənilən nəticələr. Bu, həm də sizin öz reqressiyanız üçün faydalıdır.

Belə təsvirin ən sadə nümunəsi — daxili sənədlərdə istinad edə biləcəyiniz test ssenariləri strukturu:

// test/review-scenarios.ts
export const reviewScenarios = [
  {
    id: "gift-basic",
    title: "Alış olmadan hədiyyə seçimi",
    steps: [
      "İstək: Dost üçün hədiyyə seç, stolüstü oyunları sevir, büdcə 50$",
      "Tətbiqin variantlar təklif etdiyini və giriş tələb etmədiyini yoxlayın",
    ],
  },
  {
    id: "gift-checkout",
    title: "Test checkout ilə hədiyyə seçimi",
    steps: [
      "Siyahıdan istənilən hədiyyəni seçin",
      "Test kartından istifadə edərək rəsmiləşdirməyə keçin",
    ],
  },
];

Bu struktur birbaşa Store-a getmir, amma komandanızı nizamlayır və sonra reviewer-lər və texniki dəstək üçün təsviri yeniləməyə kömək edir.

4. Test hesabları və məlumatlar: onsuz review uçmayacaq

Məsələyə pul, şəxsi məlumat və ya xarici hesablar daxil olan kimi, reviewer-lər sizdən bütün ssenarini onların real kartını, şəxsi e-poçtunu və ya real Slack/Google/başqa nəyisə istifadə etmədən keçməyin təhlükəsiz yolunu təqdim etməyinizi gözləyirlər.

Şərti olaraq iki böyük test subyekti növünü ayırmaq olar.

Birinci növ — sisteminizdə test istifadəçiləri/təşkilatları. Məsələn, GiftGenius üçün xüsusi “review təşkilatı” yarada bilərsiniz: əvvəlcədən hazırlanmış demo kataloqu və ödəniş provayderinin sandbox rejimində bağlanmış test ödəniş metodları ilə. Vacibdir ki, reviewer çətin onboarding keçməsin: idealda o, login/parol və ya magic link almalı və dərhal hazır sandbox mühitinə düşməlidir.

İkinci növ — xarici provayderlərin test məlumatları. Ödənişlər, bir qayda olaraq, sandbox rejiminə malikdir (test kartları, test hesabları). Əgər App ödənişi ACP/Instant Checkout vasitəsilə delegasiya edirsə, review zamanı test mühitindən istifadə etdiyinizə və heç kimin real pulla ödəmədiyinə əmin olmalısınız. Bu artıq commerce hissəsinin arxitekturasına toxunur, amma fikir sadədir: backend-ə “review/test mode” bayrağı əlavə edin.

Kod terminləri ilə bu, sadə mühit bayrağı və konfiqurasiya kimi görünə bilər:

// config/env.ts
export const env = {
  nodeEnv: process.env.NODE_ENV,
  reviewMode: process.env.REVIEW_MODE === "true",
  paymentProviderEnv: process.env.REVIEW_MODE === "true" ? "sandbox" : "production",
};

Və ödəniş sistemi müştərisini init etdiyiniz yerdə:

// lib/payments/client.ts
import { env } from "@/config/env";

export const paymentClient = createPaymentClient({
  environment: env.paymentProviderEnv, // "sandbox" və ya "production"
  apiKey: process.env.PAYMENT_API_KEY!,
});

Belə xırdalıqlar həyatı xeyli asanlaşdırır: App-i production-a maksimum bənzər rejimdə işə sala bilərsiniz, amma reviewer-lər real pul toxunmur.

Ayrıca, Gmail, Slack, Notion və s. kimi inteqrasiyalar üçün test ssenarilərini düşünmək lazımdır. OAuth istifadə olunan yerdə, review çox vaxt ya ümumi demo hesabı, ya da test workspace yaratmağın çox sadə təlimatını gözləyir. “Support-a yazın, biz sizə əl ilə nəsə aktiv edərik” ssenarilərindən qaçın: review çox vaxt avtomatlaşdırılıb və vaxtla məhdudlaşdırılıb, sizin məktubu gözləməyəcəklər.

5. Tipik review iradları və onlara necə reaksiya vermək

İndi, ola bilsin, xoş olmayan xəbər: ilk review keçidinizi ideal etmək ehtimalı, proqramçının ilk cəhddə bugsuz kod yazması ehtimalı kimidir. Yəni sıfra yaxındır. Və bu, normaldır.

İradlar çox vaxt bir neçə proqnozlaşdırılan kateqoriyaya düşür.

Birinci kateqoriya — icazələr və məxfilik. Məsələn, istifadəçinin e-poçtuna giriş istəyirsiniz, amma listing-də nə üçün olduğu izah edilmir. Və ya Privacy Policy-də “chat məlumatlarını saxlamırıq” yazılıb, amma MCP serverin logları sorğunu PII ilə birlikdə rahatca yazır. Reviewer sizdən ya sənədləri dəqiqləşdirməyi, ya App-in davranışını dəyişməyi, ya da hər ikisini istəyə bilər.

İkinci kateqoriya — UX və söhbətdə davranış. App dialoqu “ələ keçirə” bilər: inline yerinə əsassız şəkildə fullscreen açmaq, hərəkətlərdən sonra mətn xülasəsi qoymamaq, istifadəçiyə “söhbətə qayıt”mağın aydın yolunu verməmək. Belə hallarda sizdən çox güman ki, UX-i sadələşdirmək və ChatGPT-nin əsas dialoq interfeysinə hörmət etmək tələb olunacaq.

Üçüncü kateqoriya — sabitlik və xətalar. Tipik ssenarilərdə App mütəmadi olaraq “Error talking to app” və ya daxili 500-lər çıxarırsa, review siz bunu istisna hal, yoxsa norma olmadığını göstərənə qədər dayandırıla bilər. Burada sizdən yalnız bug fix deyil, həm də minimal müşahidəolunurluq gözlənilir: loglar, health check-lər, məntiqli timeout-lar.

Dördüncü kateqoriya — listing-in dürüstlüyü və marketinq vədləri. Təsvirində bacardığınızdan artıq vəd verirsinizsə, reviewer-lər bunu adətən tez görürlər, xüsusən də həssas domenlərdə “zəmanətli nəticələr” vəd edirsinizsə. Düzəliş iki addımdan ibarətdir: ya vədləri azaldırsınız, ya da reallaşdırmanı artırırsınız (adətən birincisi).

İradlara düzgün necə reaksiya vermək? Əsas qayda — review-ya “şərik” kimi yanaşmaq, “pis moderatorlar” kimi yox. Cavabda faydalıdır:

1. Problemi aydın etiraf etmək: “Bəli, cari versiyada App X edir, təsvirində isə Y yazılıb”.
2. Nələri dəyişdiyinizi təsvir edin: “Listing-i düzəltdik və Privacy Policy-ni yenilədik, belə ki…”
3. İmkan daxilində, reviewer-in düzəlişi görəcəyi qısa test ssenarisi əlavə edin.

Aydın başa düşmürsünüzsə ki, niyə belə irad gəlib, təxmin etməkdənsə aydınlaşdırıcı sual vermək daha yaxşıdır. Məsələn: “Düz başa düşürükmü ki, əsas problem App-in istifadəçi sorğusu olmadan avtomatik fullscreen açmasıdır?”.

6. Review-a göndərməzdən əvvəl daxili yoxlama siyahısı

İterasiyaların sayını azaltmaq üçün modullar 7, 15–17 əsasında öz “pre‑flight yoxlama siyahınızı” yaratmaq faydalıdır. Bu, “formallıq” üçün siyahı deyil, hər submitdən əvvəl həqiqətən keçdiyiniz praktik bir alətdir.

Texniki olaraq bu yoxlama siyahısını repozitoriyə kiçik JSON/TS modul kimi salıb README-də və ya pipeline-da işə sala bilərsiniz.

TypeScript-də ən sadə variant belə görünə bilər:

// tools/review-checklist.ts
export interface ChecklistItem {
  id: string;
  description: string;
  done: boolean;
}

export const reviewChecklist: ChecklistItem[] = [
  {
    id: "ux-inline-first",
    description: "App-in əsas ssenariləri inline rejimdə işləyir, fullscreen yalnız həqiqətən əsaslandırıldığı yerlərdədir.",
    done: false,
  },
  {
    id: "privacy-links",
    description: "Privacy Policy, Terms, Support keçidləri etibarlıdır və avtorizasiyasız açılır.",
    done: false,
  },
  {
    id: "permissions-minimal",
    description: "Yalnız minimal zəruri icazələr tələb olunur; hər biri listing-də təsvir olunub.",
    done: false,
  },
];

Daxili alətlərinizdə və ya sadəcə konsolda bu siyahını çıxarıb prosesinizi qeyd edə bilərsiniz. Bu, əlbəttə, məcburi avtomatika deyil, amma proqramçılar ənənəvi olaraq koda Google Docs-dan daha çox həvəslə yanaşırlar, niyə də tanış alətdən istifadə etməyəsiniz.

7. İterasiyalar və versiyalaşdırma: ilk dərcdən sonra həyat

İkinci sürpriz: App-iniz review-dan keçib istifadəçilərə açıldıqdan sonra da proses bitmir. Hər hansı əhəmiyyətli yeniləmə yenidən yoxlamanı tetik edə bilər, xüsusən icazələri dəyişirsinizsə, yeni həssas ssenarilər əlavə edirsinizsə və ya UX-i radikal dəyişirsinizsə.

Ona görə də ChatGPT App-ə “son atəş” kimi deyil, normal release prosesi olan canlı məhsul kimi yanaşmağa dəyər.

Adətən minimal ağlabatan yanaşma belədir: kodda versiya (semver), dəyişiklik jurnalı (changelog) və hansı relizlərin təkrar review tələb etdiyini, hansının isə etmədiyini anlamaq. Məsələn, App-in davranışını və icazələri dəyişməyən UI-dəki yazı səhvlərinin düzəldilməsi səssiz keçə bilər, amma “yalnız tövsiyələr”dən “tam checkout və ödəniş”ə keçid mütləq yeni diqqət tələb edəcək.

Kodda bu, sadə bir sabit və dəyişikliklər obyekt kimi görünə bilər:

// config/app-version.ts
export const appVersion = "1.1.0";

export const appChangelog = {
  "1.1.0": [
    "Test istifadəçiləri üçün sandbox-checkout əlavə edildi",
    "Listing-də icazələrin təsviri dəqiqləşdirildi",
  ],
  "1.0.0": ["Ödənişsiz GiftGenius-un ilk publik versiyası"],
};

Və bəli, bu qeydləri Store-un release qeydləri ilə sinxronlaşdırmağınız əladır. O zaman həm reviewer-lərə, həm də istifadəçilərə nə baş verdiyini anlamaq daha asan olacaq.

8. Platforma ilə ünsiyyət: reviewer-lərlə necə münasibəti korlamamaq

Bəlkə də ən az qiymətləndirilən bacarıq — reviewer-lərlə normal danışmaqdır. Adətən feedback tezislər şəklində gəlir: nə düz deyil, hansı siyasət bəndlərinə ilişmisiniz, UX-in hansı yerləri sual doğurur. Yaxşı cavab “Siz heç nə başa düşmürsünüz” deyil, sakit və konkret mesajdır.

Bir neçə sadə prinsipı yadınızda saxlayın.

Birincisi, aydınlıq. MCP serverinizin daxili arxitekturasının niyə bu qədər gözəl olduğu barədə uzun esselər yazmayın. Reviewer-i hər şeydən əvvəl istifadəçi təcrübəsi və siyasətə uyğunluq maraqlandırır. Nələri dəyişdiyinizi və indi bunu necə yoxlamağın mümkün olduğunu qısaca təsvir etmək kifayətdir.

İkincisi, şəffaflıq. Problem “mətn düzəltdik”dən daha mürəkkəbdirsə və ciddi dəyişikliklər tələb edirsə, daha dürüstdür yazmaq: “Bu irad checkout flow-un əsas hissəsinə toxunur, düzgün düzəliş üçün 1–2 həftə lazım olacaq. Hazır olan kimi yenilənmiş versiyanı göndərəcəyik.”

Üçüncüsü, yadda saxlayın. Review iradlarını təkcə poçtda və ya daxili trekerdə deyil, həm də sənədləşmədə kiçik “qərar” kimi saxlamağa dəyər: dəqiq nəyin olmaz olduğu və niyə. Bu, yeni tərtibatçılara və product-a eyni tələyə düşməməyə kömək edir. Burada daxili sənəddə sadə qeyd və ya hətta README-də “Store Review Decisions” bölməsi kömək edə bilər.

9. Arxitektura və əvvəlki modullarla əlaqə

Review prosesinə əvvəlki modullarda etdiyiniz hər şeyin “integral yoxlaması” kimi baxmaq faydalıdır.

Təhlükəsizlik və icazələr (7, 15) modulları olmadan çox güman girişlər, PII ilə iş, OAuth və destructive actions barədə suallar olacaq.

Sabitlik və müşahidəolunurluq (16, 17) modulları olmadan App-in niyə bəzən yıxıldığını, bəzən yox, və buna necə nəzarət etdiyinizi inandırıcı izah edə bilməyəcəksiniz. Metriklər və SLO nəzəriyyədən arqumentə çevrilir: “əsas alət üçün p95 < 2 saniyə və error rate < 1% son N gün ərzində”.

UX modulları (8, 11) olmadan App sadəcə “söhbəti sındıra” bilər: lazım olmayan yerdə fullscreen, rejimlər arasında anlaşılmaz keçidlər, mətn xülasəsinin olmaması. Reviewer-lər bu şeyləri sizdən daha tez görürlər, çünki çox fərqli App-ları test edirlər və kimsə “həddi aşanda” yaxşı hiss edirlər.

Və nəhayət, bugünkü review prosesini anlama olmadan “göndərdik, geri qaytardılar, inciyib qaldıq” mərhələsində ilişib qala bilərsiniz. Düzgün münasibət isə buna daha bir iterasiya dövrü kimi baxmaqdır — sizin daxili reqressiyanıza çox oxşayır, sadəcə daha bir maraqlı iştirakçı ilə — platforma ilə.

Nəticədə, əgər sizdə ağlabatan yoxlama siyahısı, test hesabları və sandbox rejimi, baza müşahidəolunurluq və reviewer-lərlə normal ünsiyyət varsa, review prosesi lotereya olmaqdan çıxır. Bu, sadəcə sizin ChatGPT App ətrafında daha bir iterativ dövrdür — relizdən əvvəl reqressiya və ya komanda daxilində kod review kimi təbii.

10. Review-dan keçərkən tipik səhvlər

Səhv №1: App-i daxili yoxlama siyahısı olmadan “olduğu kimi” göndərmək.
Çox komanda App “Dev Mode-da işə düşən kimi” Submit basır. Nəticədə review-da baza şeylər üzə çıxır: Privacy/Terms-ə qırıq linklər, işləməyən ssenarilər, test hesablarının olmaması. Bu, hər submitdən əvvəl həqiqətən keçdiyiniz sadə daxili yoxlama siyahısı ilə müalicə olunur (etibarlı linklər, minimal icazələr, işlək əsas ssenarilər) — belə bir siyahının nümunəsini yuxarıda “Review-a göndərməzdən əvvəl daxili yoxlama siyahısı” bölməsində nəzərdən keçirdik.

Səhv №2: Test hesablarını və sandbox rejimlərini görməzdən gəlmək.
Reviewer-dən real bank kartı tələb edən App-i review-a göndərmək — pis fikirdir. Eyni dərəcədə pisdir ki, checkout nəzəri olaraq var, amma reviewer onu ümumiyyətlə test edə bilmir. Sisteminizdə əvvəlcədən test organization/user-ları və ödəniş provayderinin sandbox rejimini REVIEW_MODE və ya oxşar bayraqla bağlamağı qabaqcadan düşünmək lazımdır.

Səhv №3: Problemi həll etmək əvəzinə “istisna qoparmağa” çalışmaq.
Bəzən tərtibatçılar reviewer-lə mübahisəyə başlayırlar: “axı rəqiblərdə də eynidir” və ya “bu platforma məhdudiyyətidir, bizlik deyil”. Bu üslub nadir hallarda kömək edir. Daha effektivdir ssenarini yenidən formalaşdırmaq, UX-i sadələşdirmək, icazələri azaltmaq və listing-i App-in real davranışını dürüst əks etdirəcək şəkildə düzəltmək.

Səhv №4: İradları və qərarları sənədləşdirməmək.
Review-dan şərh alıb sadəcə “koddakı bug-u düzəldib” nəyin olmaz olduğunu yazmasanız, altı aydan sonra komandanızdan kimsə yenə eyni şeyi edəcək. Review qərarlarının kiçik reyestrini aparmaq daha yaxşıdır: “İstifadəçinin açıq hərəkəti olmadan avtomatik fullscreen açmaq olmaz”, “Policy-də açıq göstərilmədən chat mətnlərini N gündən artıq saxlamaq olmaz” və s.

Səhv №5: “Böyük relizlər” üçün mərhələli strategiya olmaması.
Bir relizdə həm ödəniş, həm yeni icazələr, həm yeni UX, həm də yenilənmiş backend əlavə etməyə çalışmaq — review-da uzun iterasiyalar üçün yaxşı reseptdir. Daha rahatdır kiçik addımlarla çıxmaq: əvvəlcə ödənişsiz tövsiyələr, sonra — sandbox checkout, sonra — tam ödəniş flow-u. Beləliklə həm riskləri azaldırsınız, həm də review-da arqumentlər azalır.

Səhv №6: Öz QA və müşahidəolunurluq əvəzinə Store-un qəbuluna arxalanmaq.
Bəzən komanda şüuraltı olaraq reviewer-lərin “onlar üçün test edəcəyini” gözləyir. Nəticədə review pulsuz QA-ya çevrilir, amma işə salmanı həftələrlə gecikdirir. Review-a artıq kifayət qədər yetkin məhsulun final “sanity yoxlaması” kimi yanaşmaq daha sağlamdır — testləri, logları, metrikləri və aydın ssenariləri olan məhsul.