Na konci prosince 2008 jsem byl pozván do jedné z taxislužeb v Permu s cílem automatizovat stávající obchodní procesy. Obecně jsem dostal tři základní úkoly:
- Vyvinout softwarový balíček pro call centrum s mobilní aplikací pro taxikáře a automatizovat interní obchodní procesy.
- Vše se muselo stihnout v co nejkratším čase.
- Mít svůj vlastní software, nikoli kupovat od vývojářů třetích stran, který lze v budoucnu, jak se bude obchod rozvíjet, nezávisle přizpůsobovat neustále se měnícím tržním podmínkám.
Tehdy jsem nechápal, jak tento trh funguje a jeho nuance, ale přesto mi byly jasné dvě věci. Call centrum musí být postaveno na bázi open source asterisk softwaru PBX. Výměna informací mezi call centrem a mobilní aplikací je v podstatě řešení klient-server se všemi odpovídajícími vzory pro návrh architektury budoucího projektu a jeho programování.
Po předběžném posouzení úkolů, termínů a nákladů projektu a po domluvě s majitelem taxislužby na všech nezbytných záležitostech jsem v lednu 2009 nastoupil do práce.
Při pohledu dopředu řeknu hned. Výsledkem byla škálovatelná platforma běžící na 60+ serverech ve 12 městech v Rusku a 2 v Kazachstánu. Celkový zisk společnosti byl 100+ milionů rublů měsíčně.
První fáze. Prototyp
Protože jsem v té době neměl s IP telefonií žádné praktické zkušenosti a hvězdičku jsem znal jen povrchně v rámci „domácích“ experimentů, bylo rozhodnuto začít pracovat na vývoji mobilní aplikace a serverové části. Zároveň zacelit mezery ve znalostech o jiných úkolech.
Kdyby u mobilní aplikace bylo vše víceméně jasné. V té době to bylo možné napsat pouze v jazyce Java pro jednoduché tlačítkové telefony, ale napsat server obsluhující mobilní klienty bylo trochu složitější:
- Jaký operační systém serveru bude použit;
- Na základě logiky, že se pro úlohu volí programovací jazyk a ne naopak, a s přihlédnutím k bodu 1, který programovací jazyk bude pro řešení problémů optimální;
- Při návrhu bylo nutné vzít v úvahu očekávané budoucí vysoké zatížení služby;
- Která databáze může zaručit odolnost proti chybám při vysokém zatížení a jak zachovat rychlou dobu odezvy databáze s rostoucím počtem požadavků na ni;
- Určujícím faktorem byla rychlost vývoje a schopnost rychle škálovat kód
- Náklady na zařízení a jeho údržbu v budoucnu (jednou z podmínek zákazníka je, že servery musí být umístěny na území pod jeho kontrolou);
- Náklady na vývojáře, kteří budou potřeba v dalších fázích práce na platformě;
Stejně jako mnoho dalších problémů souvisejících s designem a vývojem.
Před zahájením práce na projektu jsem majiteli firmy navrhl následující strategické rozhodnutí: jelikož je projekt poměrně složitý, jeho realizace zabere značné množství času, proto nejprve vytvořím verzi MVP, která nezabere mnoho času a peněz, ale které jeho firmě umožní získat konkurenční výhodu na trhu již „tady a teď“ a rozšíří také své možnosti jako taxislužba. Takové meziřešení mi zase dá čas na promyšlenější návrh finálního řešení a čas na technické experimenty. Zároveň nebude zaručeno, že implementované softwarové řešení bude správně navrženo a může být v budoucnu radikálně přepracováno nebo nahrazeno, ale rozhodně bude plnit minimální potřebnou funkcionalitu k „odtržení od konkurence“. Zakladateli taxíku se nápad líbil, a tak to nakonec udělali.
První dva týdny jsem strávil studiem obchodních procesů ve firmě a studiem práce taxi zevnitř. Provedl obchodní analýzu, kde, co a jak lze automatizovat a zda je to vůbec nutné. S jakými potížemi a problémy se zaměstnanci společnosti potýkají? Jak se řeší. Jak je organizován pracovní den pro zaměstnance společnosti. Jaké nástroje používají?
Na konci třetího týdne, po zahájení práce a prostudování zajímavých otázek na internetu, s přihlédnutím k přání majitele firmy a mým vlastním znalostem a schopnostem v té době, bylo rozhodnuto použít následující zásobník :
- Databázový server: MsSQL (bezplatná verze s limitem databázových souborů do 2 GB);
- Vývoj serveru obsluhujícího mobilní klienty v Delphi pod Windows, protože již existoval Windows server, na který by byla databáze instalována, stejně jako samotné vývojové prostředí umožňuje rychlý vývoj;
- S ohledem na nízké rychlosti internetu na mobilních telefonech v roce 2009 musí být protokol výměny mezi klientem a serverem binární. Tím se sníží velikost přenášených datových paketů a v důsledku toho se zvýší stabilita práce klientů se serverem;
Další dva týdny byly věnovány navrhování protokolu a databáze. Výsledkem bylo 12 balíčků, které zajišťují výměnu všech potřebných dat mezi mobilním klientem a serverem a cca 20 tabulek v databázi. Tuto část práce jsem provedl s ohledem na budoucnost, i kdybych musel kompletně změnit technologický stack, struktura balíčků a databáze by měla zůstat nezměněna.
Po přípravných pracích bylo možné začít s praktickou realizací nápadu. Abych proces trochu urychlil a uvolnil čas na další úkoly, udělal jsem návrh verze mobilní aplikace, načrtl UI, částečně UX, a zapojil do projektu známého java programátora. A zaměřil se na vývoj, design a testování na straně serveru.
Na konci druhého měsíce prací na MVP byla připravena první verze prototypu serveru a klienta.
A na konci třetího měsíce, po syntetických testech a testech v terénu, opravách chyb, drobných vylepšeních protokolu a databáze, byla aplikace připravena k produkci. Což se také udělalo.
Od této chvíle začíná nejzajímavější a nejobtížnější část projektu.
Při přechodu řidičů na nový software byla organizována XNUMXhodinová služba. Protože ne každý mohl přijít v pracovní době během dne. Administrativně byla navíc z rázného rozhodnutí zakladatele společnosti organizována tak, že přihlašovací jméno/heslo zadával vedoucí taxislužby a nebyly sdělovány řidiči. Z mé strany byla potřeba technická podpora pro uživatele v případě poruch a nepředvídaných situací.
Murphyho zákon nám říká: "Co se může pokazit, pokazí se." A přesně tak se věci pokazily... Jedna věc je, když jsme já a několik taxikářů testovali aplikaci na několika desítkách testovacích zakázek. A je to úplně jiná věc, když 500+ řidičů na lince pracuje v reálném čase na skutečných zakázkách od skutečných lidí.
Architektura mobilní aplikace byla jednoduchá a bylo v ní znatelně méně chyb než na serveru. Hlavní těžiště práce bylo proto na straně serveru. Nejkritičtější závadou v aplikaci byl problém s odpojením od serveru, když se ztratil internet v telefonu a relace byla znovu obnovena. A internet mizel poměrně často. Za prvé, v těch letech nebyl internet v telefonu sám o sobě dostatečně stabilní. Za druhé, bylo mnoho slepých míst, kde internet prostě nefungoval. Tento problém jsme identifikovali téměř okamžitě a do XNUMX hodin jsme opravili a aktualizovali všechny dříve nainstalované aplikace.
Server měl především chyby v algoritmu distribuce objednávek a nesprávné zpracování některých požadavků od klientů. Po identifikaci závad jsem opravil a aktualizoval server.
Ve skutečnosti v této fázi nebylo tolik technických problémů. Celý problém byl v tom, že jsem byl skoro měsíc ve službě v kanceláři, jen občas jsem šel domů. Asi 4-5x. A spal jsem v záchvatech a začátcích, protože jsem v té době pracoval na projektu sám a nikdo kromě mě nemohl nic opravit.
Měsíc, to neznamená, že měsíc neustále všechno sekalo a já jsem bez přestání něco kódoval. Právě jsme se tak rozhodli. Obchod už totiž fungoval a vydělával. Je lepší hrát na jistotu a odpočívat později, než ztrácet zákazníky a zisky hned. Všichni jsme tomu velmi dobře rozuměli, a tak celý tým kolektivně věnoval maximální pozornost a čas zavádění nového softwaru do systému taxi. A s přihlédnutím k aktuální návštěvnosti zakázek všechny nedostatky do měsíce určitě odstraníme. Skryté chyby, které mohou zůstat, jistě nebudou mít kritické důsledky na obchodní proces a v případě potřeby je lze rutinně opravit.
Zde je třeba poznamenat neocenitelnou pomoc ze strany ředitelů a mistrů taxislužeb, kteří s maximálním pochopením složitosti situace převodu řidičů na nový software pracovali s řidiči nepřetržitě. Ve skutečnosti jsme po dokončení instalace nových programů do telefonů nepřišli o jediný ovladač. A kriticky nezvýšily procento neodebrání klientů, které se brzy vrátilo na normální úroveň.
Tím byla dokončena první etapa prací na projektu. A nutno podotknout, že výsledek na sebe nenechal dlouho čekat. Automatizací distribuce objednávek řidičům bez zásahu člověka se řádově zkrátila průměrná doba čekání na taxi klientem, což přirozeně zvýšilo loajalitu zákazníků ke službě. To vedlo ke zvýšení počtu objednávek. Následně se zvýšil počet taxikářů. V důsledku toho také vzrostl počet úspěšně dokončených zakázek. A v důsledku toho se zvýšil zisk společnosti. Tady samozřejmě trochu předbíhám, jelikož celý tento proces neproběhl okamžitě. Říci, že vedení bylo spokojeno, neznamená nic. Dostal jsem neomezený přístup k dalšímu financování projektu.
Pokračovat ..
Zdroj: www.habr.com