Konec decembra 2008 sem bil povabljen v eno od taksi služb v Permu z namenom avtomatizacije obstoječih poslovnih procesov. Na splošno sem dobil tri temeljne naloge:
- Razviti programski paket za klicni center z mobilno aplikacijo za taksiste in avtomatizirati notranje poslovne procese.
- Vse je bilo treba narediti v najkrajšem možnem času.
- Imeti lastno programsko opremo namesto kupljene od zunanjih razvijalcev, ki jo je v prihodnosti, ko se bo podjetje razvijalo, mogoče neodvisno prilagoditi nenehno spreminjajočim se tržnim razmeram.
Takrat mi ni bilo jasno, kako ta trg deluje in kakšne so njegove nianse, vendar sta mi bili očitni dve stvari. Klicni center mora biti zgrajen na osnovi odprtokodne PBX programske opreme asterisk. Izmenjava informacij med klicnim centrom in mobilno aplikacijo je v bistvu rešitev odjemalec-strežnik z vsemi pripadajočimi vzorci za oblikovanje arhitekture bodočega projekta in njegovo programiranje.
Po predhodni oceni nalog, rokov in stroškov projekta ter po dogovoru o vseh potrebnih zadevah z lastnikom taksi službe, sem januarja 2009 pričel z delom.
Če pogledam naprej, bom rekel takoj. Rezultat je bila razširljiva platforma, ki deluje na več kot 60 strežnikih v 12 mestih v Rusiji in 2 v Kazahstanu. Skupni dobiček podjetja je bil več kot 100 milijonov rubljev na mesec.
Prva stopnja. Prototip
Ker takrat še nisem imel praktičnih izkušenj z IP telefonijo, z zvezdico pa sem bil le površno seznanjen v okviru »domačih« poskusov, je bilo odločeno, da začnem delati z razvojem mobilne aplikacije in strežniškega dela. Hkrati pa odpravljanje vrzeli v znanju pri drugih nalogah.
Če bi bilo z mobilno aplikacijo vse bolj ali manj jasno. Takrat ga je bilo mogoče napisati le v Javi za preproste telefone s tipkami, pisanje strežnika, ki služi mobilnim odjemalcem, pa je bilo nekoliko bolj zapleteno:
- Kateri OS strežnika bo uporabljen;
- Izhajajoč iz logike, da se za nalogo izbere programski jezik in ne obratno, in ob upoštevanju 1. točke, kateri programski jezik bo optimalen za reševanje problemov;
- Pri projektiranju je bilo potrebno upoštevati pričakovane prihodnje visoke obremenitve storitve;
- Katera zbirka podatkov lahko zagotovi toleranco na napake pri visokih obremenitvah in kako ohraniti hiter odziv baze podatkov, ko se število zahtev do nje povečuje;
- Odločilni dejavnik je bila hitrost razvoja in sposobnost hitrega prilagajanja kode
- Stroški opreme in njeno vzdrževanje v prihodnosti (eden od pogojev stranke je, da morajo biti strežniki nameščeni na ozemlju pod njegovim nadzorom);
- Stroški razvijalcev, ki bodo potrebni v naslednjih fazah dela na platformi;
Kot tudi številna druga vprašanja, povezana z oblikovanjem in razvojem.
Pred začetkom dela na projektu sem lastniku podjetja predlagal naslednjo strateško odločitev: ker je projekt precej kompleksen, bo njegova izvedba vzela precej časa, zato najprej izdelam različico MVP, ki ne bo vzela veliko časa in denarja, ki pa bo njegovemu podjetju omogočil konkurenčno prednost na trgu že »tukaj in zdaj«, razširil pa bo tudi svoje zmogljivosti kot taksi služba. Po drugi strani mi bo taka vmesna rešitev dala čas za bolj premišljeno oblikovanje končne rešitve in čas za tehnične eksperimente. Obenem implementirana programska rešitev ne bo zajamčeno pravilno zasnovana in jo lahko v prihodnosti korenito prenovimo ali zamenjamo, vsekakor pa bo opravljala minimalno potrebno funkcionalnost za »odboj od tekmecev«. Ustanovitelju taksija je bila ideja všeč, zato so jo na koncu tudi izpeljali.
Prva dva tedna sem posvetil proučevanju poslovnih procesov v podjetju in proučevanju dela taksija od znotraj. Opravljena poslovna analiza, kje, kaj in kako se lahko avtomatizira in ali je to sploh potrebno. S kakšnimi težavami in težavami se soočajo zaposleni v podjetju? Kako se jih rešuje. Kako je organiziran delovni dan za zaposlene v podjetju. Katera orodja uporabljajo?
Do konca tretjega tedna, po začetku dela in preučevanju zanimivih vprašanj na internetu, ob upoštevanju želja lastnika podjetja ter mojega lastnega znanja in zmožnosti v tistem času, je bilo odločeno, da uporabim naslednji niz :
- Strežnik baze podatkov: MsSQL (brezplačna različica z omejitvijo datoteke baze podatkov do 2 GB);
- Razvoj strežnika za mobilne odjemalce v Delphiju pod Windows, saj že obstaja Windows strežnik, na katerega bi bila nameščena baza, pa tudi samo razvojno okolje omogoča hiter razvoj;
- Glede na nizke internetne hitrosti na mobilnih telefonih leta 2009 mora biti protokol izmenjave med odjemalcem in strežnikom binarni. To bo zmanjšalo velikost prenesenih podatkovnih paketov in posledično povečalo stabilnost dela strank s strežnikom;
Nadaljnja dva tedna sta bila porabljena za načrtovanje protokola in baze podatkov. Nastalo je 12 paketov, ki zagotavljajo izmenjavo vseh potrebnih podatkov med mobilnim odjemalcem in strežnikom ter približno 20 tabel v bazi. Ta del dela sem opravil z upoštevanjem prihodnosti, tudi če bom moral popolnoma spremeniti tehnološki sklad, mora struktura paketov in baze podatkov ostati nespremenjena.
Po pripravljalnih delih je bilo mogoče začeti s praktično izvedbo ideje. Da bi malo pospešil proces in sprostil čas za druga opravila, sem naredil osnutek mobilne aplikacije, skiciral UI, delno UX, in v projekt vključil znanega java programerja. Osredotočil se je na razvoj, oblikovanje in testiranje na strani strežnika.
Ob koncu drugega meseca dela na MVP je bila pripravljena prva različica prototipa strežnika in odjemalca.
In do konca tretjega meseca, po sintetičnih testih in testih na terenu, popravkih napak, manjših izboljšavah protokola in baze podatkov, je bila aplikacija pripravljena za proizvodnjo. Kar je bilo tudi storjeno.
Od tega trenutka se začne najzanimivejši in najtežji del projekta.
Ob prehodu voznikov na novo programsko opremo je bilo organizirano XNUMX-urno dežurstvo. Ker podnevi v delovnem času niso mogli vsi priti. Poleg tega je bilo administrativno po voljni odločitvi ustanovitelja podjetja organizirano tako, da je prijavo/geslo vnesel vodja taksi službe in nista bila posredovana vozniku. Z moje strani je bila potrebna tehnična podpora uporabnikom v primeru okvar in nepredvidenih situacij.
Murphyjev zakon nam pravi: "Vse, kar gre lahko narobe, bo šlo." In točno tako je šlo narobe ... Eno je, ko sem jaz in več taksistov testiral aplikacijo na več desetih testnih naročilih. In povsem druga stvar je, ko 500+ voznikov na progi dela v realnem času po resničnih naročilih resničnih ljudi.
Arhitektura mobilne aplikacije je bila preprosta in v njej je bilo opazno manj hroščev kot v strežniku. Zato je bil glavni poudarek dela na strani strežnika. Najbolj kritična napaka v aplikaciji je bila težava prekinitve povezave s strežnikom, ko je bil internet na telefonu izgubljen in je bila seja ponovno vzpostavljena. In internet je precej pogosto izginil. Prvič, v tistih letih sam internet na telefonu ni bil dovolj stabilen. Drugič, bilo je veliko slepih točk, kjer internet preprosto ni deloval. To težavo smo odkrili skoraj takoj in v XNUMX urah popravili in posodobili vse predhodno nameščene aplikacije.
Strežnik je imel predvsem napake v algoritmu distribucije naročil in nepravilno obdelavo nekaterih zahtev strank. Po odkritju napak sem popravil in posodobil strežnik.
Pravzaprav na tej stopnji ni bilo toliko tehničnih težav. Celotna težava je bila v tem, da sem bil skoraj mesec dni v službi v pisarni, le občasno sem šel domov. Verjetno 4-5 krat. In spal sem v krčih, saj sem takrat delal na projektu sam in nihče razen mene ni mogel ničesar popraviti.
Mesec dni, to ne pomeni, da je en mesec vse nenehno glihtalo in sem nekaj kodiral, ne da bi se ustavil. Tako smo se pač odločili. Navsezadnje je podjetje že delovalo in ustvarjalo dobiček. Bolje je igrati na varno in počivati pozneje, kot pa zdaj izgubiti stranke in dobiček. Vsi smo to zelo dobro razumeli, zato je celotna ekipa skupaj posvetila maksimalno pozornost in čas uvajanju nove programske opreme v taksi sistem. In glede na trenutni promet naročil, bomo vse pomanjkljivosti zagotovo odpravili v enem mesecu. No, skrite napake, ki morebiti ostanejo, zagotovo ne bodo imele kritičnih posledic na poslovni proces in jih je po potrebi možno rutinsko odpraviti.
Tukaj je treba opozoriti na neprecenljivo pomoč direktorjev in mojstrov taksi služb, ki so z največjim razumevanjem zapletenosti situacije prenosa voznikov na novo programsko opremo delali z vozniki XNUMX ur na dan. Pravzaprav po končani namestitvi novih programov na telefone nismo izgubili niti enega gonilnika. In niso kritično povečali odstotka neodstranitve strank, ki se je kmalu vrnil na normalno raven.
S tem je prva faza dela na projektu zaključena. In treba je opozoriti, da rezultat ni dolgo čakal. Z avtomatizacijo distribucije naročil voznikom brez človeškega posredovanja se je povprečna čakalna doba naročnika na taksi zmanjšala za red velikosti, kar je seveda povečalo zvestobo strank storitvi. To je povzročilo povečanje števila naročil. Po tem se je povečalo število taksistov. Posledično se je povečalo tudi število uspešno izvedenih naročil. In posledično se je povečal dobiček podjetja. Seveda tukaj malo prehitevam, saj se celoten proces ni zgodil takoj. Reči, da je bilo vodstvo zadovoljno, pomeni nič. Dobil sem neomejen dostop do nadaljnjega financiranja projekta.
Nadaljuj ..
Vir: www.habr.com