2008. december végén meghívást kaptam az egyik permi taxiszolgálathoz azzal a céllal, hogy automatizáljam a meglévő üzleti folyamatokat. Általában három alapvető feladatot kaptam:
- Szoftvercsomag fejlesztése a taxisofőrök számára mobilalkalmazással rendelkező call center számára, és automatizálja a belső üzleti folyamatokat.
- Mindent a lehető legrövidebb idő alatt kellett elvégezni.
- Legyen saját szoftvere, ne pedig külső fejlesztőktől vásárolja meg, amely a jövőben az üzlet fejlődésével függetlenül a folyamatosan változó piaci feltételekhez igazítható.
Akkor még nem értettem ennek a piacnak a működését és árnyalatait, de ennek ellenére két dolog nyilvánvaló volt számomra. A call centernek a nyílt forráskódú, asterisk alközponti szoftverre kell épülnie. A call center és a mobilalkalmazás közötti információcsere lényegében egy kliens-szerver megoldás, minden megfelelő mintával a jövőbeli projekt architektúrájának és programozásának megtervezéséhez.
A projekt feladatainak, határidőinek és költségeinek előzetes felmérése után, valamint a taxiszolgáltatás tulajdonosával minden szükséges kérdésben egyeztetve 2009 januárjában kezdtem el dolgozni.
Előre tekintve, azonnal mondom. Az eredmény egy skálázható platform, amely több mint 60 szerveren fut Oroszország 12 és 2 kazahsztáni városában. A cég teljes nyeresége 100+ millió rubel/hó volt.
Első szakasz. Prototípus
Mivel akkor még nem volt gyakorlati tapasztalatom az IP-telefóniában, a csillagozást pedig csak felületesen ismertem az „otthoni” kísérletek részeként, ezért elhatározták, hogy egy mobilalkalmazás és szerver rész fejlesztésével kezdek dolgozni. Egyúttal az egyéb feladatokra vonatkozó tudásbeli hiányosságok felszámolása.
Ha a mobilalkalmazással minden többé-kevésbé egyértelmű volt. Akkor még csak egyszerű nyomógombos telefonokhoz lehetett java-ban írni, de a mobilklienseket kiszolgáló szerver megírása kicsit bonyolultabb volt:
- Milyen szerver operációs rendszert fognak használni;
- Azon logikán alapulva, hogy egy feladathoz programozási nyelvet választanak, és nem fordítva, és figyelembe véve az 1. pontot, melyik programozási nyelv lesz optimális a problémák megoldására;
- A tervezés során figyelembe kellett venni a szolgáltatás várható jövőbeni nagy terheléseit;
- Melyik adatbázis tudja garantálni a hibatűrést nagy terhelés mellett, és hogyan tartható fenn az adatbázis gyors válaszideje a hozzá intézett kérések számának növekedésével;
- A meghatározó tényező a fejlesztés sebessége és a kód gyors méretezhetősége volt
- A berendezések és karbantartásának költsége a jövőben (az ügyfél egyik feltétele, hogy a szervereknek az irányítása alá tartozó területen kell elhelyezkedniük);
- A platformon végzett munka következő szakaszaiban szükséges fejlesztők költsége;
Valamint sok más, a tervezéssel és fejlesztéssel kapcsolatos kérdés.
A projekten való munka megkezdése előtt a következő stratégiai döntést javasoltam a cégtulajdonosnak: mivel a projekt meglehetősen összetett, a megvalósítása észrevehetően sok időt vesz igénybe, ezért először készítek egy MVP verziót, ami nem fog sok időt igénybe venni és pénzt, de amely lehetővé teszi, hogy cége már „itt és most” versenyelőnyre tegyen szert a piacon, és taxiszolgáltatásként is bővíti képességeit. Egy ilyen köztes megoldás viszont időt ad a végső megoldás átgondoltabb megtervezésére és időt a műszaki kísérletekre. Ugyanakkor a megvalósított szoftvermegoldás nem garantáltan megfelelően lesz megtervezve, és a jövőben radikálisan újratervezhető vagy lecserélhető, de mindenképpen teljesíti a minimálisan szükséges funkcionalitást, hogy „elszakadjon a versenytársaktól”. A taxi alapítójának tetszett az ötlet, így végül megcsinálták.
Az első két hetet azzal töltöttem, hogy tanulmányoztam a cég üzleti folyamatait, és belülről tanulmányoztam a taxi munkáját. Üzleti elemzést készített arról, hogy hol, mit és hogyan lehet automatizálni, és egyáltalán szükséges-e. Milyen nehézségekkel, problémákkal szembesülnek a cég alkalmazottai? Hogyan oldják meg. Hogyan szervezik meg a munkanapot a vállalat alkalmazottai számára. Milyen eszközöket használnak?
A harmadik hét végére a munka megkezdése és az érdeklődésre számot tartó kérdések internetes tanulmányozása után, figyelembe véve a cégtulajdonos kívánságait, valamint saját akkori tudásomat és képességeimet, a következő verem alkalmazása mellett döntöttek :
- Adatbázis-szerver: MsSQL (ingyenes verzió 2 GB-ig terjedő adatbázis-fájl korláttal);
- Mobilklienseket kiszolgáló szerver fejlesztése Delphiben Windows alatt, hiszen már volt Windows szerver, amelyre az adatbázist telepítenék, valamint maga a fejlesztői környezet is gyors fejlődést tesz lehetővé;
- Figyelembe véve a mobiltelefonok 2009-es alacsony internetsebességét, a kliens és a szerver közötti csereprotokollnak binárisnak kell lennie. Ez csökkenti a továbbított adatcsomagok méretét, és ennek eredményeként növeli az ügyfelek szerverrel végzett munkájának stabilitását;
További két hét a protokoll és az adatbázis tervezésével telt. Az eredmény 12 olyan csomag, amely biztosítja az összes szükséges adat cseréjét a mobil kliens és a szerver között, valamint mintegy 20 tábla az adatbázisban. A munka ezen részét a jövőre tekintettel végeztem, még ha a technológiai stacket is teljesen módosítanom kell, a csomagok és az adatbázis szerkezete változatlan maradjon.
Az előkészítő munka után meg lehetett kezdeni az ötlet gyakorlati megvalósítását. Hogy egy kicsit felgyorsítsam a folyamatot és időt szabadítsak fel más feladatokra, elkészítettem a mobilalkalmazás vázlatos verzióját, felvázoltam a felhasználói felületet, részben az UX-t, és egy ismerős java programozót is bevontam a projektbe. És a szerveroldali fejlesztésre, tervezésre és tesztelésre összpontosított.
Az MVP-n végzett munka második hónapjának végére elkészült a szerver és kliens prototípus első verziója.
A harmadik hónap végére pedig szintetikus tesztek és helyszíni tesztek, hibajavítások, kisebb protokoll- és adatbázisfejlesztések után az alkalmazás készen áll a gyártásra. Ami meg is történt.
Ettől a pillanattól kezdve kezdődik a projekt legérdekesebb és legnehezebb része.
A sofőrök új szoftverre való átállása során XNUMX órás ügyeletet szerveztek. Mivel nappal nem tudott mindenki jönni munkaidőben. Ráadásul adminisztratívan, a cégalapító határozott döntése alapján úgy szervezték meg, hogy a bejelentkezést/jelszót a taxiszolgálat vezetője adta meg, és nem közölték a sofőrrel. Részemről a felhasználók technikai támogatására volt szükség meghibásodások és előre nem látható helyzetek esetén.
Murphy törvénye azt mondja nekünk: "Bármi, ami elromolhat, el is romlik." És a dolgok pontosan így mentek rosszul... Az egy dolog, amikor több taxisofőrrel több tucat próbarendelésen teszteltük az alkalmazást. Teljesen más a helyzet, amikor több mint 500 sofőr dolgozik valós időben valós emberektől származó megbízások alapján.
A mobilalkalmazás architektúrája egyszerű volt, és érezhetően kevesebb bug volt benne, mint a szerverben. Ezért a munka fő hangsúlya a szerver oldalon volt. Az alkalmazás legkritikusabb hibája az volt, hogy megszakadt a kapcsolat a szerverrel, amikor megszakadt az internet a telefonon, és a munkamenet újra helyreállt. És az internet elég gyakran eltűnt. Először is, azokban az években maga a telefonos internet nem volt elég stabil. Másodszor, sok olyan vakfolt volt, ahol az internet egyszerűen nem működött. Szinte azonnal azonosítottuk ezt a problémát, és XNUMX órán belül kijavítottuk és frissítettük az összes korábban telepített alkalmazást.
A szerver főként a rendeléselosztási algoritmusban hibázott, és az ügyfelektől érkező kéréseket nem megfelelően dolgozta fel. A hibákat észlelve javítottam és frissítettem a szervert.
Valójában ebben a szakaszban nem volt sok technikai probléma. Az egész nehézséget az jelentette, hogy majdnem egy hónapig voltam szolgálatban az irodában, csak néha mentem haza. Valószínűleg 4-5 alkalommal. És rohamokban aludtam, hiszen akkoriban egyedül dolgoztam a projekten, és rajtam kívül senki nem tudott semmit megjavítani.
Egy hónap, ez nem azt jelenti, hogy egy hónapig folyamatosan minden hibázott, és megállás nélkül kódoltam valamit. Csak úgy döntöttünk. Hiszen az üzlet már működött és nyereséget termelt. Jobb biztonságban játszani és később pihenni, mint most elveszíteni az ügyfeleket és a nyereséget. Ezt mindannyian nagyon jól megértettük, így az egész csapat közösen maximális figyelmet és időt fordított arra, hogy új szoftvereket vezessenek be a taxirendszerbe. A jelenlegi rendelésforgalmat figyelembe véve pedig egy hónapon belül minden hiányosságot mindenképpen kiküszöbölünk. Nos, az esetlegesen megmaradt rejtett hibáknak biztosan nincs kritikus következménye az üzleti folyamatra nézve, és ha szükséges, rutinszerűen kijavíthatók.
Itt meg kell jegyezni a taxiszolgáltatások igazgatóinak és elöljáróinak felbecsülhetetlen értékű segítségét, akik maximálisan megértették a sofőrök új szoftverre való áthelyezésének összetettségét, éjjel-nappal a járművezetőkkel dolgoztak. Valójában az új programok telefonokra történő telepítése után egyetlen illesztőprogramot sem veszítettünk el. És nem növelték kritikusan az ügyfelek el nem távolításának arányát, amely hamarosan visszatért a normál szintre.
Ezzel befejeződött a projekt munka első szakasza. És meg kell jegyezni, hogy az eredmény nem sokáig váratott magára. Azáltal, hogy emberi beavatkozás nélkül automatizálták a rendelések kiosztását a sofőrök között, nagyságrenddel lecsökkentette az ügyfelek átlagos taxivárakozási idejét, ami természetesen növelte az ügyfelek szolgáltatás iránti lojalitását. Ez a megrendelések számának növekedéséhez vezetett. Ezt követően nőtt a taxisok száma. Ennek köszönhetően nőtt a sikeresen teljesített megrendelések száma is. Ennek eredményeként nőtt a cég nyeresége. Természetesen itt egy kicsit megelőzöm magam, hiszen ez az egész folyamat nem ment végbe azonnal. Ha azt mondjuk, hogy a vezetőség elégedett volt, nem mond semmit. Korlátlan hozzáférést kaptam a projekt további finanszírozásához.
Továbbra is ..
Forrás: will.com