Egy alkalmazás valódi fejlesztési ütemterve: az ötlettől a megjelenésig

Ha tíz ügynökséget megkérdez, mennyi ideig tart egy alkalmazás elkészítése, tíz magabiztos választ kap, és egyik sem lesz igaz. Az őszinte válasz az, hogy az első napon senki sem tudja pontosan megmondani Önnek — de bárki, aki valóban szállított már szoftvert, el tudja mondani a dolog formáját: milyen szakaszok vannak, melyek eszik fel csendben a naptárt, és hol gyorsítják fel vagy fékezik le a folyamatot az Ön saját döntései. Ez itt éppen az a forma, kerek-perec leírva.

Sok kisvállalkozó vágott már bele egy alkalmazásprojektbe úgy, hogy szép, egyenes vonalú menetelésre számított a vázlattól az App Store-ig. Ehelyett olyasmit kapnak, ami fennsíkok és hirtelen ugrások sorozatára hasonlít. Hetek, amikor úgy tűnik, semmi sem történik, aztán egy nap, amikor az egész hirtelen a helyére kattan. Ezek egyike sem annak a jele, hogy valami baj van. Egyszerűen így készül a szoftver — és amint meg tudja nevezni a szakaszokat, az egész folyamat megszűnik fekete dobozként hatni, amelybe fizet, és reméli a legjobbat.

Állítsunk hát fel reális elvárásokat. Egy üzleti alkalmazás fókuszált első verziójánál — nem egy szerteágazó platform, hanem egy első verzió, amely egy dolgot jól csinál — általában három-öt hónap körüli időről beszélünk a komoly kezdéstől a valódi megjelenésig. Hogy ezen a tartományon belül hová esik, kevésbé függ a technológiától, és inkább attól, mennyire világosan lát, milyen gyorsan dönt, és mennyi mindent próbál belezsúfolni a megjelenés előtt. Vegyük sorra.

Miért valószínűleg téves a kapott becslés

A hathetes szám nem pontosan hazugság — ennyi időbe telik megépíteni azt a részt, amelyet mindenki el tud képzelni. A képernyőket. A gombokat. Azt, amit be lehet mutatni. Amit ez a szám csendben figyelmen kívül hagy, az minden, ami a látható alkalmazás körül van: a döntések, az adatok, az Ön által már használt eszközökkel való integrációk, a tesztelés, az alkalmazásbolti felülvizsgálat, és az elkerülhetetlen „igazából, ezt is meg tudná csinálni?” kör.

Egy hasznos megközelítés: a programozás ritkán szűk keresztmetszet. A szűk keresztmetszet a tisztánlátás. Minden óra, amikor a fejlesztője egy döntésre vár — melyik fizetési szolgáltató, mi történik egy foglalás lemondásakor, ki mit lát —, egy óra, amennyivel az ütemterv csúszik. A gyorsan elkészülő projektek nem azok, ahol a legjobb mérnökök vannak. Azok, ahol a tulajdonos egy nap, nem két hét alatt válaszol a kérdésekre.

Ahogy tehát az alábbi szakaszokat olvassa, figyelje azokat a pillanatokat, amikor a labda az Ön térfelén van. Ezek azok a pontok, ahol egy projekt vagy megtartja a lendületét, vagy csendben elakad három hétre, mert egy e-mail válasz nélkül maradt. Az ütemterv közös felelősség, és a megrendelői fele az, amelyet az emberek alábecsülnek.

1. szakasz: Felmérés és terjedelem meghatározása (1–3 hét)

Mielőtt bárki egyetlen képernyőt is megtervezne, van egy szakasz, amely nem tűnik haladásnak, mégis mindent eldönt: kideríteni, mit is épít valójában, és ami fontosabb, mit nem. Itt válik egy homályos ötletből („egy alkalmazás az ügyfeleimnek”) konkrét, befejezhető funkciólista az első verzióhoz.

Jól csinálva a felmérés többnyire beszélgetés és nehéz kérdések. Ki használja, és milyen eszközön? Mi az az egy dolog, amit ragyogóan kell csinálnia? Mi várhat a második verzióra? Egy jó partner itt ellenkezni fog, és ezt akarja is — minden funkció, amelyet most kihúz, hetek, amelyeket visszanyer. A kimenet rendszerint egy rövid írott terjedelem és egy nyers drótváz, valami, amit kézbe vehet, és azt mondhatja: igen, ez az.

2. szakasz: Tervezés és prototípus (2–4 hét)

Most az alkalmazás valami olyasmivé válik, amit láthat és kattinthat, mielőtt egyetlen sornyi valódi kód bármire is elkötelezné. A tervezők a drótvázat rendes képernyőkké alakítják — a színek, a folyamat, a használat tényleges érzete — általában egy interaktív prototípusként, amelyet a saját telefonján végigböngészhet.

Ez a szakasz egyetlen okból aranyat ér: egy tervet megváltoztatni olcsó, egy megépített szoftvert megváltoztatni drága. Egy gombot áthelyezni egy prototípusban öt perc. Áthelyezni azután, hogy a funkció le van kódolva, le van tesztelve és az adataihoz van kötve, egy napba is telhet. Ez tehát az a pillanat, amikor válogatós lehet, megmutathatja néhány valódi ügyfélnek vagy munkatársnak, és elkaphatja az „ó, ezt senki sem fogja érteni” jellegű gondokat, amíg még fájdalommentesen javíthatók.

Leggyakrabban nem a tervező nyújtja el ezt a szakaszt — hanem a határozatlanság az Ön oldalán. Apró módosítások végtelen körei, vagy három, vétójoggal rendelkező ember, akik soha nem értenek egyet. Döntse el korán, ki hagyja jóvá, adjon visszajelzést kötegekben, ne csepegtetve, és a szakasz feszes marad.

3. szakasz: Építés (6–12 hét)

Ez az a rész, amelyet mindenki maga elé képzel, amikor az „alkalmazáskészítésre” gondol, és ez az egyetlen leghosszabb szakasz — de ritkán a legkiszámíthatatlanabb, ha az első két szakaszt rendesen elvégezték. A fejlesztők darabokban építik az alkalmazást, általában rövid ciklusokban, ahol egy-két hetente lát működő részeket, ahelyett hogy három hónapra eltűnnének, majd egy kész termékkel bukkannának fel újra.

Ez a ritmus számít. Valódi, futó szoftverre akar korán reagálni, nem egy állapotjelentésre. Amikor a negyedik héten ténylegesen használhatja a foglalási folyamatot, olyan dolgokat fog észrevenni, amelyeket semmilyen specifikáció nem ragadhatott volna meg — és ezeket a negyedik héten javítani sokkal olcsóbb, mint a tizediken. Egy jó építési folyamat folyamatosan láthatóvá teszi Önnek az alkalmazást, nem csak a végén.

Mi nyújtja el csendben az építést

Két dolog tágítja az építést mindennél jobban. Az első az integrációk — minden külső rendszer, amellyel az alkalmazásnak kommunikálnia kell (a fizetési szolgáltatója, a meglévő foglalási eszköze, a könyvelőszoftvere, egy futárszolgálat) munkát ad hozzá, és mindegyik a saját meglepetéseit okozhatja. A második a terjedelem-elcsúszás: az apró kiegészítések állandó csepegése, amelyek mindegyike parányinak tűnik, de együttesen egy hónappal kitolják a megjelenést. Mindkettő kezelhető, de csak ha látja közeledni őket.

• Minden külső integráció napokat, néha heteket ad hozzá — kifejezetten tervezzen velük költségben, ne feltételezze, hogy ingyen vannak.
• A „csak még egy apró funkció” messze a leggyakoribb oka egy elszalasztott megjelenési határidőnek.
• A valódi adatok kuszábbak, mint a tesztadatok; tervezzen időt azokra a peremesetekre, amelyeket a táblázata csendben eltűrt.
• A felhasználói fiókok, a fizetések és az értesítések megtévesztően mélyek — mindig többe kerülnek, mint amennyinek látszanak.
• A jóváhagyások és a csapatnak tartozott tartalom (logók, szövegek, jogi szövegek) éppolyan biztosan megakaszthatják az építést, mint egy hiba.

4. szakasz: Tesztelés és javítás (2–4 hét)

Itt egy szakasz, amelyről az emberek elfelejtik, hogy létezik, aztán neheztelnek rá, amikor felbukkan. Amint az alkalmazás elkészült, próbára kell tenni — különböző telefonokon, rossz internettel, olyan emberekkel, akik nem építették, és olyasmiket fognak csinálni, amire senki sem számított. A tesztelés nem formalitás. Ez a különbség egy alkalmazás között, amelyben az ügyfelei megbíznak, és egy között, amelyet az első összeomlás után eltávolítanak.

Számítson rá, hogy itt egy hiba- és érdességlista bukkan elő. Ez nem annak a jele, hogy az építés rosszul sikerült; ez a szakasz teljes lényege. Némelyik gyors javítás, némelyik egy újragondolandó döntést tár fel. Azok a csapatok, amelyek ezt jól kezelik, a munka normális, betervezett részeként kezelik — nem vészhelyzetként, és nem olyasvalamiként, amit át kell ugrani, mert közeleg a megjelenés. A tesztelés átugrása nem takarít meg időt. Csak átteszi a hibákat az Ön tesztelő telefonjáról az ügyfelei telefonjaira, ahol tízszer annyiba kerül kijavítani őket.

5. szakasz: Megjelenés és az alkalmazásbolti várakozás (1–2 hét, plusz a felülvizsgálat)

A megjelenés nem annyira egyetlen pillanat, mint inkább egy gondos kiterjesztés. Ha webalkalmazásról van szó, az időzítést teljesen Ön irányítja — akkor billenti át a kapcsolót, amikor készen áll. Ha az Apple App Store-jába vagy a Google Playre kerül, az ütemterv egy részét átadja nekik: a felülvizsgálati folyamatuk egy naptól több mint egy hétig is tarthat, és olykor visszaküldik valami javítanivalóval. Ezt érdemes előre tudni, hogy ne érje váratlanul egy olyan megjelenési határidőnél, amelyet az ügyfeleknek ígért.

A megjelenés okos módja nem egy nagy durranású leleplezés a teljes ügyfélkörének. Egy csendes kiadás előbb egy kis csoportnak — egy maroknyi jóindulatú ügyfélnek vagy a saját munkatársainak —, hogy elkapja a valós világbeli problémákat, mielőtt mindenki látná. Aztán szélesebbre tárja az ajtót. Egy unalmasan eseménytelennek tűnő megjelenés egy jól sikerült megjelenés.

1. 1
   Csendes megjelenés egy kis csoportnak

   Adja ki előbb egy maroknyi jóindulatú felhasználónak vagy munkatársnak. A valódi használat megtalálja, amit a tesztelés elszalasztott, miközben a tét a minimumra van csavarva.
2. 2
   Adja be korán, ha az alkalmazásboltokba megy

   A felülvizsgálat óráit az Apple és a Google irányítja, nem Ön. Adja be tartalékkal, hogy egy lassú felülvizsgálat vagy egy elutasítás ne robbantsa szét az ígért dátumot.
3. 3
   Figyelje szorosan az első hetet

   Tartson valakit kéznél a gyors reagáláshoz. Az első hét felszínre hozza azokat a valós világbeli peremeseteket, amelyeket egyetlen tesztkörnyezet sem hoz soha.
4. 4
   Tervezze meg a megjelenés utáni munkát, mielőtt megjelenik

   Egy alkalmazás a megjelenéskor soha nem „kész”. Egyezzenek meg előre, ki kezeli az elkerülhetetlen apró javításokat és a visszajelzés első körét.

Összerakva a teljes ütemtervet

Egymás után rakva ezek a szakaszok reális képet adnak Önnek. Egyik sem egzotikus; ami megfekteti az embereket, az annak elfeledése, hogy a hálátlanok — a felmérés, a tesztelés, az alkalmazásbolti várakozás — valódi időt jelentenek a naptárban, nem kerekítési hibákat. Íme nagyjából, hogyan oszlik el egy fókuszált első verzió a hónapok között.

Adja össze, és látja, miért a három-öt hónap az őszinte tartomány egy valódi első verzióhoz, és miért fogalmazzák át csendben azok, akik hat hetet ígérnek, hogy mit jelent „egy alkalmazás”. Ez nem pesszimizmus — ez a különbség egy dátum között, amelyet ténylegesen tartani fog, és egy között, amely miatt az egész projekt során mentegetőznie kell.

Hogyan gyorsítható fel valóban (és hogyan nem)

Mehet gyorsabban is, de a valódi emelők nem azok, amelyekhez az emberek nyúlnak. Több fejlesztőt rádobni egy félig meghatározott projektre általában lassabbá teszi, nem gyorsabbá. Az őszinte gyorsítók hálátlanok: döntse el, mit hagy ki, válaszoljon gyorsan a kérdésekre, és álljon ellen a kísértésnek, hogy az építés közepén dolgokat adjon hozzá.

A messze legnagyobb a könyörtelen terjedelem. Minél kisebb és tisztább az első verziója, annál hamarabb jelenik meg — és egy megjelent alkalmazás, amely megtermeli a maga árát, két hét alatt többet tanít Önnek, mint újabb két hónap tervezgetés valaha is. Hozzáadni mindig tud. A senki által nem kívánt funkciók építésével eltöltött hónapokat nem nyeri vissza.

Van egy kapcsolódó igazság, amelyet érdemes hangosan kimondani: nem mindennek kell egyedi alkalmazásnak lennie. Néha a valódi probléma egy adag kézi munka, amelyet egy darab automatizálás csendben elintézhetne, mindenféle alkalmazás nélkül. Egy jó partner megmondja, mikor van ez így, ahelyett hogy a nagyobb építést adná el Önnek — mert a legolcsóbb alkalmazás az, amelyet nem kellett elkészítenie.

Gyakori kérdések