I slutningen af december 2008 blev jeg inviteret til en af taxiservicerne i Perm med det formål at automatisere eksisterende forretningsprocesser. Generelt fik jeg tre grundlæggende opgaver:
- Udvikl en softwarepakke til et callcenter med en mobilapplikation til taxachauffører og automatiser interne forretningsprocesser.
- Alt skulle klares på kortest mulig tid.
- Få din egen software frem for at købe fra tredjepartsudviklere, som i fremtiden, efterhånden som virksomheden udvikler sig, selvstændigt kan skaleres til konstant skiftende markedsforhold.
På det tidspunkt forstod jeg ikke, hvordan dette marked fungerer og dets nuancer, men ikke desto mindre var to ting indlysende for mig. Callcenteret skal bygges på basis af open source asterisk-softwaren PBX. Udvekslingen af information mellem callcenteret og mobilapplikationen er i det væsentlige en klient-server-løsning med alle de tilsvarende mønstre til at designe arkitekturen for det fremtidige projekt og dets programmering.
Efter en foreløbig vurdering af opgaverne, deadlines og omkostninger for projektet, og efter at have aftalt alle nødvendige forhold med ejeren af taxakørsel, startede jeg arbejdet i januar 2009.
Ser jeg fremad, vil jeg sige med det samme. Resultatet var en skalerbar platform, der kører på 60+ servere i 12 byer i Rusland og 2 i Kasakhstan. Virksomhedens samlede overskud var 100+ millioner rubler/måned.
Etape et. Prototype
Da jeg på det tidspunkt ikke havde nogen praktisk erfaring med IP-telefoni, og jeg kun overfladisk kendte stjerne som en del af "hjemme"-eksperimenter, blev det besluttet at begynde at arbejde med udviklingen af en mobilapplikation og serverdel. Samtidig med at lukke huller i viden om andre opgaver.
Hvis alt var mere eller mindre klart med mobilapplikationen. På det tidspunkt kunne det kun skrives i java til simple trykknap-telefoner, men at skrive en server, der betjener mobile klienter, var lidt mere kompliceret:
- Hvilket server-OS vil blive brugt;
- Ud fra logikken om, at et programmeringssprog vælges til en opgave, og ikke omvendt, og under hensyntagen til punkt 1, hvilket programmeringssprog der vil være optimalt til at løse problemer;
- Under designet var det nødvendigt at tage højde for de forventede fremtidige høje belastninger på tjenesten;
- Hvilken database kan garantere fejltolerance under høje belastninger, og hvordan man opretholder en hurtig databasesvartid, efterhånden som antallet af anmodninger til den stiger;
- Den afgørende faktor var udviklingshastigheden og evnen til hurtigt at skalere koden
- Udgifterne til udstyr og dets vedligeholdelse i fremtiden (en af kundens betingelser er, at serverne skal være placeret i det område, der er under hans kontrol);
- Udgifter til udviklere, der vil være nødvendige i de næste stadier af arbejdet på platformen;
Samt mange andre spørgsmål relateret til design og udvikling.
Inden jeg påbegyndte arbejdet med projektet, foreslog jeg følgende strategiske beslutning til virksomhedsejeren: da projektet er ret komplekst, vil dets implementering tage en mærkbar tid, så først opretter jeg en MVP-version, som ikke vil tage meget tid og penge, men som vil gøre det muligt for hans virksomhed at opnå en konkurrencefordel på markedet allerede "her og nu", og vil også udvide sine muligheder som taxiservice. Til gengæld vil en sådan mellemløsning give mig tid til mere gennemtænkt at designe den endelige løsning og tid til tekniske eksperimenter. Samtidig vil den implementerede softwareløsning ikke garanteres at være korrekt designet og kan blive radikalt redesignet eller erstattet i fremtiden, men den vil helt sikkert udføre den minimale nødvendige funktionalitet for at "bryde væk fra konkurrenterne." Grundlæggeren af taxaen kunne lide ideen, så til sidst gjorde de det.
Jeg brugte de første to uger på at studere forretningsprocesserne i virksomheden, og studere arbejdet i en taxa indefra. Foretaget en forretningsanalyse af hvor, hvad og hvordan kan automatiseres og om det overhovedet er nødvendigt. Hvilke vanskeligheder og problemer står virksomhedens ansatte over for? Hvordan de løses. Hvordan arbejdsdagen tilrettelægges for virksomhedens medarbejdere. Hvilke værktøjer bruger de?
Ved udgangen af den tredje uge, efter at have startet arbejde og studeret spørgsmål af interesse på internettet, under hensyntagen til virksomhedsejerens ønsker såvel som min egen viden og evner på det tidspunkt, blev det besluttet at anvende følgende stak :
- Databaseserver: MsSQL (gratis version med databasefilgrænse op til 2GB);
- Udvikling af en server, der betjener mobile klienter i Delphi under Windows, da der allerede var en Windows-server, som databasen ville blive installeret på, samt selve udviklingsmiljøet letter hurtig udvikling;
- Tager man højde for de lave internethastigheder på mobiltelefoner tilbage i 2009, skal udvekslingsprotokollen mellem klient og server være binær. Dette vil reducere størrelsen af transmitterede datapakker og som et resultat øge stabiliteten af klienternes arbejde med serveren;
Yderligere to uger blev brugt på at designe protokollen og databasen. Resultatet blev 12 pakker, der sikrer udveksling af alle nødvendige data mellem den mobile klient og server og omkring 20 tabeller i databasen. Jeg lavede denne del af arbejdet under hensyntagen til fremtiden, selvom jeg skal ændre teknologistakken fuldstændig, skal strukturen af pakkerne og databasen forblive uændret.
Efter det forberedende arbejde var det muligt at påbegynde den praktiske implementering af ideen. For at fremskynde processen lidt og frigøre tid til andre opgaver, lavede jeg en kladdeversion af mobilapplikationen, skitserede UI'en, dels UX'en, og involverede en velkendt java-programmør i projektet. Og han fokuserede på udvikling, design og test på serversiden.
Ved udgangen af den anden måneds arbejde på MVP'en var den første version af server- og klientprototypen klar.
Og ved udgangen af den tredje måned, efter syntetiske test og felttest, fejlrettelser, mindre forbedringer af protokollen og databasen, var applikationen klar til produktion. Hvilket er, hvad der blev gjort.
Fra dette øjeblik begynder den mest interessante og sværeste del af projektet.
Under overgangen af chauffører til den nye software blev der organiseret XNUMX-timers vagt. Da ikke alle kunne komme i arbejdstiden i dagtimerne. Derudover var det administrativt, ved en stærk beslutning fra virksomhedens grundlægger, organiseret på en sådan måde, at login/adgangskode blev indtastet af lederen af taxatjenesten, og de blev ikke kommunikeret til chaufføren. Fra min side var der brug for teknisk support til brugerne i tilfælde af fejl og uforudsete situationer.
Murphys lov fortæller os: "Alt, der kan gå galt, vil gå galt." Og det var præcis sådan, det gik galt... Én ting er, da jeg og flere taxachauffører testede applikationen på flere dusin testordrer. Og det er en helt anden sag, når 500+ chauffører på linjen arbejder i realtid på rigtige ordrer fra rigtige mennesker.
Arkitekturen af mobilapplikationen var enkel, og der var mærkbart færre fejl i den end på serveren. Derfor var hovedfokus for arbejdet på serversiden. Den mest kritiske fejl i applikationen var problemet med afbrydelse af forbindelsen fra serveren, når internettet på telefonen gik tabt, og sessionen blev gendannet igen. Og internettet forsvandt ret ofte. For det første var internettet på selve telefonen i disse år ikke stabilt nok. For det andet var der mange blinde vinkler, hvor internettet simpelthen ikke virkede. Vi identificerede dette problem næsten øjeblikkeligt og inden for XNUMX timer rettet og opdaterede alle tidligere installerede applikationer.
Serveren havde hovedsageligt fejl i ordrefordelingsalgoritmen og forkert behandling af nogle anmodninger fra klienter. Efter at have identificeret fejl, korrigerede og opdaterede jeg serveren.
Faktisk var der ikke så mange tekniske problemer på dette tidspunkt. Hele vanskeligheden var, at jeg var på vagt på kontoret i næsten en måned, kun lejlighedsvis at gå hjem. Sikkert 4-5 gange. Og jeg sov i kramper, da jeg på det tidspunkt arbejdede på projektet alene, og ingen undtagen mig kunne ordne noget.
En måned betyder det ikke, at alt konstant fejlede i en måned, og jeg kodede noget uden at stoppe. Det har vi lige besluttet. Forretningen var jo allerede i gang og gav overskud. Det er bedre at spille det sikkert og hvile senere end at miste kunder og overskud nu. Vi forstod det alle godt, så hele teamet brugte samlet maksimal opmærksomhed og tid på at introducere ny software i taxasystemet. Og under hensyntagen til den aktuelle trafik af ordrer, vil vi helt sikkert fjerne alle manglerne inden for en måned. Nå, skjulte fejl, der kan forblive, vil bestemt ikke have kritiske konsekvenser for forretningsprocessen, og om nødvendigt kan de rettes på en rutinemæssig basis.
Her er det nødvendigt at bemærke den uvurderlige bistand fra taxatjenesternes direktører og formænd, som med maksimal forståelse for kompleksiteten af situationen med at overføre chauffører til ny software arbejdede med chauffører døgnet rundt. Faktisk, efter at have afsluttet installationen af nye programmer på telefoner, mistede vi ikke en eneste driver. Og de øgede ikke kritisk procentdelen af ikke-fjernelse af klienter, som hurtigt blev vendt tilbage til normale niveauer.
Dette afsluttede den første fase af arbejdet med projektet. Og det skal bemærkes, at resultatet ikke lod vente på sig. Ved at automatisere distributionen af ordrer til chauffører uden menneskelig indgriben blev den gennemsnitlige ventetid på en taxa hos en klient reduceret med en størrelsesorden, hvilket naturligvis øgede kundeloyaliteten til tjenesten. Dette førte til en stigning i antallet af ordrer. Herefter steg antallet af taxachauffører. Som følge heraf er antallet af vellykket gennemførte ordrer også steget. Og som et resultat steg virksomhedens overskud. Her kommer jeg selvfølgelig lidt foran mig selv, da hele denne proces ikke fandt sted med det samme. At sige, at ledelsen var tilfreds, er at sige ingenting. Jeg fik ubegrænset adgang til yderligere finansiering af projektet.
Fortsættes ..
Kilde: www.habr.com