Writing/App Store
Ultimele două săptămâni înainte de review
Tot ce credeam că mai e de făcut era mărunt. Nimic din ce mai era de făcut nu era munca. Munca era suprafața de conformitate pe care n-o demonstrează nimeni și pe care fiecare verificator o deschide primul.
La începutul lui martie, TeamTipOut făcea tot ce trebuia să facă. Împărțirea era corectă, echipele funcționau, exportul arăta bine. Credeam că mai am vreo săptămână. Ce mai era de fapt erau două săptămâni de muncă ce nu apare pe nicio foaie de parcurs și în nicio demonstrație și pe care un verificator o găsește în patru minute.
Blocajele pe care verificatorul le găsește primele
Pe iPad, atingerile treceau direct printr-un strat de sticlă către ce era dedesubt. Ferestrele modale se dimensionau ca pentru telefon. Un ecran care cerea numele putea fi sărit într-un fel care lăsa contul configurat pe jumătate. Toate trei erau pe cel mai mare dispozitiv pe care îl suportă aplicația, adică exact cel pe care un verificator îl deschide primul și cel pe care o aplicație gândită pentru telefon e testată ultima dată.
Verificatorii nu folosesc aplicațiile cum le folosesc utilizatorii. Merg pe margini: rotesc, trimit în fundal, sar peste pasul pe care nu-l poți sări, deschid pe cel mai mare dispozitiv pe care îl suporți. Respingerile vin de pe perimetrul ăla, nu de la funcționalitatea la care ai muncit o lună.
Suprafața de conformitate
O pagină web pentru ștergerea contului, pentru că un magazin cere ca ea să existe în afara aplicației. Termeni actualizați pentru regulile de abonament. O declarație de confidențialitate care chiar se potrivește cu ce colectează aplicația, nu cu ce presupuneam eu că colectează. Legături directe înregistrate pe ambele platforme. Nimic din toate astea nu e o funcționalitate și tot ce e aici stă între tine și a fi publicat.
“Nimic din toate astea nu e pe o foaie de parcurs și tot ce e aici stă între tine și a fi publicat.”
Lucrurile la care ai o singură șansă
Încărcarea hărților de surse trebuia configurată înainte de primul build de producție, nu după, pentru că un raport de eroare dintr-o versiune pe care n-o poți traduce înapoi în cod e o stivă de hexazecimale. Limitarea de rată pe codul de unică folosință trebuia să existe înainte să găsească cineva endpointul. O scurgere de memorie în cache trebuia reparată înainte să înceapă să se adune sesiuni reale în ea.
Asta e categoria pentru care merită să planifici: muncă ieftină înainte de lansare și scumpă sau imposibilă după. E o listă scurtă și niciodată nu e lista care te entuziasmează.
Ce aș face altfel
Aș parcurge perimetrul de verificare la jumătatea proiectului, nu la final. Împrumută cel mai mare dispozitiv, rotește tot, trimite aplicația în fundal în mijlocul unui flux, încearcă să sari peste fiecare pas obligatoriu și citește lista magazinului ca și cum ar fi un raport de bug pe care l-a depus deja cineva. Două ore la mijlocul proiectului, în loc de două săptămâni la capătul lui.
