I slutet av december 2008 blev jag inbjuden till en av taxitjänsterna i Perm med målet att automatisera befintliga affärsprocesser. Generellt fick jag tre grundläggande uppgifter:
- Utveckla ett mjukvarupaket för ett callcenter med en mobilapplikation för taxichaufförer och automatisera interna affärsprocesser.
- Allt måste göras på kortast möjliga tid.
- Ha din egen programvara, snarare än köpt från tredjepartsutvecklare, som i framtiden, allt eftersom verksamheten utvecklas, kan skalas oberoende till ständigt föränderliga marknadsförhållanden.
På den tiden förstod jag inte hur denna marknad fungerar och dess nyanser, men ändå var två saker uppenbara för mig. Callcentret måste byggas på basis av asteriskprogramvaran PBX med öppen källkod. Informationsutbytet mellan callcentret och mobilapplikationen är i huvudsak en klient-serverlösning med alla motsvarande mönster för att utforma arkitekturen för det framtida projektet och dess programmering.
Efter en preliminär bedömning av uppgifterna, deadlines och kostnaderna för projektet, och efter att ha kommit överens om alla nödvändiga frågor med ägaren av taxitjänsten, började jag arbeta i januari 2009.
Om man ser framåt, säger jag direkt. Resultatet blev en skalbar plattform som körs på 60+ servrar i 12 städer i Ryssland och 2 i Kazakstan. Företagets totala vinst var 100+ miljoner rubel/månad.
Etapp ett. Prototyp
Eftersom jag vid den tiden inte hade någon praktisk erfarenhet av IP-telefoni, och jag bara var ytligt bekant med asterisk som en del av "hem"-experiment, beslutades det att börja arbeta med utvecklingen av en mobilapplikation och serverdel. Samtidigt täppa till luckor i kunskap om andra uppgifter.
Om allt var mer eller mindre klart med mobilapplikationen. På den tiden kunde det bara skrivas i java för enkla tryckknappstelefoner, men att skriva en server som betjänar mobila klienter var lite mer komplicerat:
- Vilket server-OS kommer att användas;
- Utifrån logiken att ett programmeringsspråk väljs för en uppgift, och inte vice versa, och med hänsyn till punkt 1, vilket programmeringsspråk som kommer att vara optimalt för att lösa problem;
- Under konstruktionen var det nödvändigt att ta hänsyn till de förväntade framtida höga belastningarna på tjänsten;
- Vilken databas kan garantera feltolerans under hög belastning och hur man bibehåller en snabb databassvarstid när antalet förfrågningar till den ökar;
- Den avgörande faktorn var utvecklingshastigheten och möjligheten att snabbt skala koden
- Kostnaden för utrustning och dess underhåll i framtiden (ett av kundens villkor är att servrarna måste vara placerade i territoriet under hans kontroll);
- Kostnad för utvecklare som kommer att behövas i nästa steg av arbetet med plattformen;
Samt många andra frågor relaterade till design och utveckling.
Innan jag påbörjade arbetet med projektet föreslog jag följande strategiska beslut för företagsägaren: eftersom projektet är ganska komplext kommer implementeringen att ta en märkbar tid, så först skapar jag en MVP-version, som inte tar mycket tid och pengar, men som gör det möjligt för hans företag att få en konkurrensfördel på marknaden redan "här och nu", och kommer också att utöka sina möjligheter som taxitjänst. En sådan mellanlösning kommer i sin tur att ge mig tid att mer genomtänkt designa den slutliga lösningen och tid för tekniska experiment. Samtidigt kommer den implementerade mjukvarulösningen inte garanteras att vara korrekt designad och kan komma att radikalt omdesignas eller bytas ut i framtiden, men den kommer definitivt att utföra den minsta nödvändiga funktionaliteten för att "bryta sig loss från konkurrenterna." Grundaren av taxin gillade idén, så till slut gjorde de det.
Jag ägnade de två första veckorna åt att studera affärsprocesserna i företaget, och studera arbetet med en taxi inifrån. Gjorde en affärsanalys av var, vad och hur kan automatiseras och om det överhuvudtaget är nödvändigt. Vilka svårigheter och problem möter företagets anställda? Hur de löses. Hur arbetsdagen är upplagd för företagets anställda. Vilka verktyg använder de?
I slutet av den tredje veckan, efter att ha börjat arbeta och studerat frågor av intresse på Internet, med hänsyn till företagsägarens önskemål, såväl som min egen kunskap och kapacitet vid den tiden, beslutades det att tillämpa följande stack :
- Databasserver: MsSQL (gratis version med databasfilgräns upp till 2GB);
- Utveckling av en server som betjänar mobila klienter i Delphi under Windows, eftersom det redan fanns en Windows-server på vilken databasen skulle installeras, liksom själva utvecklingsmiljön underlättar snabb utveckling;
- Med hänsyn till de låga internethastigheterna på mobiltelefoner redan 2009 måste utbytesprotokollet mellan klienten och servern vara binärt. Detta kommer att minska storleken på överförda datapaket och, som ett resultat, öka stabiliteten i klienternas arbete med servern;
Ytterligare två veckor ägnades åt att designa protokollet och databasen. Resultatet blev 12 paket som säkerställer utbytet av all nödvändig data mellan den mobila klienten och servern och ett 20-tal tabeller i databasen. Jag gjorde den här delen av arbetet med hänsyn till framtiden, även om jag måste ändra teknikstacken helt, bör strukturen på paketen och databasen förbli oförändrad.
Efter det förberedande arbetet var det möjligt att påbörja det praktiska genomförandet av idén. För att snabba på processen lite och frigöra tid för andra uppgifter gjorde jag ett utkast till mobilapplikationen, skissade på UI, delvis UX, och involverade en bekant java-programmerare i projektet. Och han fokuserade på utveckling, design och testning på serversidan.
I slutet av den andra månadens arbete med MVP var den första versionen av servern och klientprototypen klar.
Och i slutet av den tredje månaden, efter syntetiska tester och fälttester, buggfixar, mindre förbättringar av protokollet och databasen, var applikationen klar för produktion. Vilket är vad som gjordes.
Från detta ögonblick börjar den mest intressanta och svåraste delen av projektet.
Under övergången av förare till den nya mjukvaran organiserades XNUMX-timmarstjänst. Eftersom alla inte kunde komma på arbetstid dagtid. Dessutom, administrativt, genom ett starkt beslut av företagets grundare, organiserades det på ett sådant sätt att inloggningen/lösenordet angavs av chefen för taxitjänsten och de kommunicerades inte till föraren. För min del behövdes teknisk support för användare vid fel och oförutsedda situationer.
Murphys lag säger till oss: "Allt som kan gå fel kommer att gå fel." Och det var precis så det gick fel... Det är en sak när jag och flera taxichaufförer testade applikationen på flera dussin testordrar. Och det är en helt annan sak när 500+ förare på linjen arbetar i realtid på riktiga beställningar från riktiga människor.
Arkitekturen för mobilapplikationen var enkel och det fanns märkbart färre buggar i den än i servern. Därför låg huvudfokus i arbetet på serversidan. Det mest kritiska felet i applikationen var problemet med frånkoppling från servern när Internet på telefonen försvann och sessionen återställdes igen. Och Internet försvann ganska ofta. För det första, under dessa år var Internet på telefonen i sig inte tillräckligt stabilt. För det andra fanns det många blinda fläckar där Internet helt enkelt inte fungerade. Vi identifierade detta problem nästan omedelbart och inom XNUMX timmar fixade och uppdaterade alla tidigare installerade applikationer.
Servern hade huvudsakligen fel i orderdistributionsalgoritmen och felaktig bearbetning av vissa förfrågningar från klienter. När jag identifierade fel, korrigerade och uppdaterade jag servern.
Det var faktiskt inte så många tekniska problem i det här skedet. Hela svårigheten var att jag var i tjänst på kontoret i nästan en månad och gick bara hem då och då. Förmodligen 4-5 gånger. Och jag sov i kramper, eftersom jag vid den tiden arbetade ensam med projektet och ingen utom jag kunde fixa något.
En månad, detta betyder inte att allt ständigt krånglade i en månad och jag kodade något utan att sluta. Det bestämde vi precis. När allt kommer omkring var verksamheten redan igång och gick med vinst. Det är bättre att spela säkert och vila senare än att förlora kunder och vinster nu. Vi förstod alla detta mycket väl, så hela teamet ägnade tillsammans maximal uppmärksamhet och tid åt att introducera ny mjukvara i taxisystemet. Och med hänsyn till den nuvarande trafiken av beställningar kommer vi definitivt att eliminera alla brister inom en månad. Tja, dolda buggar som kan finnas kvar kommer säkerligen inte att få kritiska konsekvenser på affärsprocessen och vid behov kan de korrigeras rutinmässigt.
Här är det nödvändigt att notera den ovärderliga hjälpen från taxitjänsters direktörer och förmän, som, med maximal förståelse för komplexiteten i situationen för att överföra förare till ny programvara, arbetade med förare dygnet runt. Faktum är att efter att ha slutfört installationen av nya program på telefoner, förlorade vi inte en enda drivrutin. Och de ökade inte kritiskt andelen icke-borttagande av klienter, som snart återgick till normala nivåer.
Detta avslutade den första etappen av arbetet med projektet. Och det bör noteras att resultatet inte lät vänta på sig. Genom att automatisera distributionen av beställningar till förare utan mänsklig inblandning, minskade den genomsnittliga väntetiden för en taxi av en kund med en storleksordning, vilket naturligtvis ökade kundlojaliteten till tjänsten. Detta ledde till att antalet beställningar ökade. Efter detta ökade antalet taxichaufförer. Som ett resultat har även antalet framgångsrikt genomförda beställningar ökat. Och som ett resultat ökade företagets vinster. Naturligtvis, här går jag lite före mig själv, eftersom hela denna process inte ägde rum direkt. Att säga att ledningen var nöjd är att inte säga något. Jag fick obegränsad tillgång till ytterligare finansiering av projektet.
Fortsättning följer..
Källa: will.com