2008. aasta detsembri lõpus kutsuti mind ühte Permi taksoteenusesse eesmärgiga automatiseerida olemasolevaid äriprotsesse. Üldiselt anti mulle kolm põhiülesannet:
- Arendage taksojuhtidele mõeldud mobiilirakendusega kõnekeskuse tarkvarapakett ja automatiseerige ettevõttesiseseid protsesse.
- Kõik tuli teha võimalikult lühikese ajaga.
- Omage oma tarkvara, selle asemel, et osta kolmandatest osapooltest arendajatelt, mida tulevikus, ettevõtte arenedes, saab iseseisvalt kohandada pidevalt muutuvatele turutingimustele.
Toona ei saanud ma aru, kuidas see turg toimib ja selle nüansid, kuid sellegipoolest olid kaks asja mulle ilmselged. Kõnekeskus peab olema ehitatud avatud lähtekoodiga tärnitarkvara PBX baasil. Infovahetus kõnekeskuse ja mobiilirakenduse vahel on sisuliselt klient-server lahendus koos kõigi vastavate mustritega tulevase projekti arhitektuuri kujundamiseks ja selle programmeerimiseks.
Pärast projekti ülesannete, tähtaegade ja kulude esialgset hindamist ning taksoteenuse omanikuga kõigis vajalikes küsimustes kokkuleppimist asusin tööle 2009. aasta jaanuaris.
Tulevikku vaadates ütlen kohe. Tulemuseks oli skaleeritav platvorm, mis töötab 60+ serveril 12 linnas Venemaal ja 2 linnas Kasahstanis. Ettevõtte kogukasum oli 100+ miljonit rubla/kuus.
Esimene etapp. Prototüüp
Kuna mul tol ajal IP-telefoni alal praktiline kogemus puudus ja tärniga olin “koduste” katsetuste raames tuttav vaid pealiskaudselt, siis otsustati hakata tegelema mobiilirakenduse ja serveriosa arendamisega. Samal ajal lünkade kaotamine teadmistes muude ülesannete osas.
Kui mobiilirakendusega oli kõik enam-vähem selge. Tol ajal sai seda javas kirjutada vaid lihtsate nupuvajutusega telefonide jaoks, kuid mobiilikliente teenindava serveri kirjutamine oli veidi keerulisem:
- millist serveri OS-i kasutatakse;
- Lähtudes loogikast, et ülesande jaoks valitakse programmeerimiskeel, mitte vastupidi, ning võttes arvesse punkti 1, milline programmeerimiskeel on probleemide lahendamiseks optimaalne;
- Projekteerimisel oli vaja arvestada teenuse eeldatavate tulevaste suurte koormustega;
- Milline andmebaas suudab tagada tõrketaluvuse suure koormuse korral ja kuidas säilitada andmebaasi kiiret reageerimisaega, kui päringute arv sellele suureneb;
- Määravaks teguriks sai arenduskiirus ja koodi kiire skaleerimise võimalus
- Seadmete ja nende hoolduse maksumus tulevikus (kliendi üks tingimus on, et serverid peavad asuma tema kontrolli all oleval territooriumil);
- Arendajate kulud, keda vajatakse platvormi töö järgmistes etappides;
Nagu ka paljud muud disaini ja arendusega seotud küsimused.
Enne projektiga töö alustamist pakkusin ettevõtte omanikule välja järgmise strateegilise otsuse: kuna projekt on üsna keeruline, võtab selle elluviimine märgatavalt palju aega, seega loon esmalt MVP versiooni, mis ei võta palju aega ja raha, kuid mis võimaldab tema ettevõttel saada turul konkurentsieelise juba “siin ja praegu” ning laiendab oma võimekust ka taksoteenusena. Omakorda annab selline vahelahendus mulle aega lõpplahenduse läbimõeldumaks kujundamiseks ja aega tehnilisteks katseteks. Samas ei garanteerita juurutatud tarkvaralahenduse korrektset disaini ja seda võidakse tulevikus põhjalikult ümber kujundada või välja vahetada, kuid kindlasti täidab see minimaalselt vajalikku funktsionaalsust, et “konkurentidest eemalduda”. Takso asutajale see idee meeldis, nii et lõpuks nad seda ka tegid.
Esimesed kaks nädalat uurisin ettevõttes äriprotsesse ja uurisin takso tööd seestpoolt. Viinud läbi ärianalüüsi, kus, mida ja kuidas saab automatiseerida ning kas see on üldse vajalik. Milliste raskuste ja probleemidega ettevõtte töötajad kokku puutuvad? Kuidas need lahendatakse. Kuidas on korraldatud ettevõtte töötajate tööpäev. Milliseid tööriistu nad kasutavad?
Kolmanda nädala lõpuks, pärast tööle asumist ja internetis huvipakkuvate küsimustega tutvumist, võttes arvesse nii ettevõtte omaniku soove kui ka enda tolleaegseid teadmisi ja võimeid, otsustati rakendada järgmist pinu :
- Andmebaasiserver: MsSQL (tasuta versioon andmebaasi failipiiranguga kuni 2GB);
- Mobiilkliente teenindava serveri arendamine Delphis Windowsi all, kuna juba oli olemas Windowsi server, kuhu andmebaas paigaldataks, samuti soodustab kiiret arengut arenduskeskkond ise;
- Arvestades 2009. aasta madalat internetikiirust mobiiltelefonides, peab kliendi ja serveri vaheline vahetusprotokoll olema binaarne. See vähendab edastatavate andmepakettide suurust ja selle tulemusena suurendab klientide töö stabiilsust serveriga;
Veel kaks nädalat kulus protokolli ja andmebaasi kujundamisele. Tulemuseks oli 12 paketti, mis tagavad kõigi vajalike andmete vahetamise mobiilikliendi ja serveri vahel ning ca 20 tabelit andmebaasis. Tegin selle osa tööst tulevikku silmas pidades, isegi kui peaksin täielikult tehnoloogilise pinu muutma, peaks pakettide ja andmebaasi struktuur muutumatuks jääma.
Peale ettevalmistustööd oli võimalik alustada idee praktilise elluviimisega. Et protsessi veidi kiirendada ja muudeks ülesanneteks aega vabastada, tegin mobiilirakendusest mustandversiooni, visandasin kasutajaliidese, osaliselt UX-i ning kaasasin projekti tuttava java programmeerija. Ja ta keskendus serveripoolsele arendusele, disainile ja testimisele.
MVP-ga töötamise teise kuu lõpuks oli serveri ja kliendi prototüübi esimene versioon valmis.
Ja kolmanda kuu lõpuks, pärast sünteetilisi ja väliteste, veaparandusi, protokolli ja andmebaasi väiksemaid parandusi, oli rakendus tootmiseks valmis. Mida tehtigi.
Sellest hetkest algab projekti kõige huvitavam ja raskeim osa.
Juhtide üleminekul uuele tarkvarale korraldati XNUMX-tunnine valve. Kuna päeval ei saanud kõik tulla tööajal. Lisaks korraldati administratiivselt ettevõtte asutaja tahtejõulisel otsusel nii, et sisselogimise/parooli sisestas taksoteenuse juhataja ja neid ei teavitatud juhiga. Minu poolt oli rikete ja ettenägematute olukordade korral vaja tehnilist tuge kasutajatele.
Murphy seadus ütleb meile: "Kõik, mis võib valesti minna, läheb valesti." Ja täpselt nii läkski asjad valesti... Üks asi on see, kui mina ja mitu taksojuhti testisime rakendust mitmekümne testtellimuse alusel. Ja see on hoopis teine asi, kui liinil töötab üle 500 juhi reaalajas päris inimeste tellimuste alusel.
Mobiilirakenduse arhitektuur oli lihtne ja selles oli märgatavalt vähem vigu kui serveris. Seetõttu oli töö põhirõhk serveri poolel. Kõige kriitilisem tõrge rakenduses oli serveriga ühenduse katkemise probleem, kui telefonis internet katkes ja seanss taastati. Ja internet kadus üsna sageli. Esiteks ei olnud neil aastatel telefonis olev Internet piisavalt stabiilne. Teiseks oli palju pimealasid, kus internet lihtsalt ei töötanud. Tuvastasime selle probleemi peaaegu kohe ning XNUMX tunni jooksul parandasime ja värskendasime kõik varem installitud rakendused.
Serveris esinesid peamiselt vead tellimuste jaotusalgoritmis ja mõnede klientide päringute vale töötlemine. Tõrgete tuvastamisel parandasin ja värskendasin serverit.
Tegelikult ei olnud selles etapis nii palju tehnilisi probleeme. Kogu raskus seisnes selles, et olin peaaegu kuu aega kontoris valves, ainult aeg-ajalt läksin koju. Ilmselt 4-5 korda. Ja ma magasin hoogu, sest sel ajal töötasin projektiga üksi ja keegi peale minu ei osanud midagi parandada.
Kuu, see ei tähenda, et kuu aega kõik pidevalt tõmbles ja ma midagi peatumata kodeerisin. Otsustasime just nii. Ettevõte ju töötas juba ja teenis kasumit. Parem on mängida ja hiljem puhata, kui kaotada kliente ja kasumit praegu. Saime kõik sellest väga hästi aru, seega pühendas kogu meeskond ühiselt maksimaalset tähelepanu ja aega uue tarkvara juurutamisele taksosüsteemi. Ja arvestades praegust tellimuste liiklust, siis kindlasti kõrvaldame kõik puudused kuu aja jooksul. Noh, varjatud vead, mis võivad jääda, ei avalda kindlasti äriprotsessile kriitilisi tagajärgi ja vajadusel saab neid rutiinselt parandada.
Siinkohal tuleb märkida hindamatut abi taksoteenuste direktoritelt ja meistridelt, kes, saades maksimaalselt aru juhtide uuele tarkvarale üleviimise olukorra keerukusest, töötasid juhtidega ööpäevaringselt. Tegelikult ei kaotanud me pärast uute programmide installimist telefonidesse ühtegi draiverit. Ja nad ei suurendanud kriitiliselt klientide mitteeemaldamise protsenti, mis peagi taastus normaalsele tasemele.
Sellega lõppes projekti esimene tööetapp. Ja tuleb märkida, et tulemus ei lasknud end kaua oodata. Ilma inimese sekkumiseta autojuhtidele tellimuste jagamise automatiseerimisega vähenes suurusjärgu võrra kliendi keskmine takso ooteaeg, mis loomulikult suurendas klientide lojaalsust teenusele. See tõi kaasa tellimuste arvu kasvu. Pärast seda kasvas taksojuhtide arv. Tänu sellele on kasvanud ka edukalt täidetud tellimuste arv. Selle tulemusena kasvas ettevõtte kasum. Muidugi olen siin natukene ees, sest kogu see protsess ei toimunud hetkega. Öelda, et juhtkond oli rahul, tähendab mitte midagi öelda. Mulle anti piiramatu juurdepääs projekti edasisele rahastamisele.
Jätkata ..
Allikas: www.habr.com