I slutten av desember 2008 ble jeg invitert til en av taxitjenestene i Perm med mål om å automatisere eksisterende forretningsprosesser. Generelt fikk jeg tre grunnleggende oppgaver:
- Utvikle en programvarepakke for et kundesenter med en mobilapplikasjon for drosjesjåfører og automatiser interne forretningsprosesser.
- Alt skulle gjøres på kortest mulig tid.
- Ha din egen programvare, i stedet for å kjøpe fra tredjepartsutviklere, som i fremtiden, ettersom virksomheten utvikler seg, kan skaleres uavhengig til stadig skiftende markedsforhold.
På den tiden forsto jeg ikke hvordan dette markedet fungerer og dets nyanser, men likevel var to ting åpenbare for meg. Kundesenteret må bygges på grunnlag av åpen kildekode stjerne-programvare PBX. Utvekslingen av informasjon mellom kundesenteret og mobilapplikasjonen er i hovedsak en klient-server-løsning med alle de tilsvarende mønstrene for utforming av arkitekturen til det fremtidige prosjektet og dets programmering.
Etter en foreløpig vurdering av oppgaver, tidsfrister og kostnader for prosjektet, og etter å ha avtalt alle nødvendige forhold med eieren av drosjetjenesten, startet jeg arbeidet i januar 2009.
Ser jeg fremover, vil jeg si med en gang. Resultatet var en skalerbar plattform som kjører på 60+ servere i 12 byer i Russland og 2 i Kasakhstan. Selskapets totale overskudd var 100+ millioner rubler/måned.
Etappe én. Prototype
Siden jeg på den tiden ikke hadde noen praktisk erfaring med IP-telefoni, og jeg bare var overfladisk kjent med stjerne som en del av "hjemme"-eksperimenter, ble det besluttet å begynne å jobbe med utviklingen av en mobilapplikasjon og serverdel. Samtidig tette hull i kunnskap om andre oppgaver.
Hvis med mobilapplikasjonen var alt mer eller mindre klart. På den tiden kunne det bare skrives i java for enkle trykkknapptelefoner, men å skrive en server som betjener mobile klienter var litt mer komplisert:
- Hvilket server-OS vil bli brukt;
- Ut fra logikken om at et programmeringsspråk velges for en oppgave, og ikke omvendt, og under hensyntagen til punkt 1, hvilket programmeringsspråk som vil være optimalt for å løse problemer;
- Under utformingen var det nødvendig å ta hensyn til forventede fremtidige høye belastninger på tjenesten;
- Hvilken database kan garantere feiltoleranse under høy belastning og hvordan opprettholde en rask responstid for databasen etter hvert som antallet forespørsler til den øker;
- Den avgjørende faktoren var utviklingshastigheten og muligheten til raskt å skalere koden
- Kostnaden for utstyr og dets vedlikehold i fremtiden (en av kundens betingelser er at serverne må være plassert i territoriet under hans kontroll);
- Kostnader for utviklere som vil være nødvendige i de neste stadiene av arbeidet med plattformen;
Samt mange andre problemstillinger knyttet til design og utvikling.
Før jeg startet arbeidet med prosjektet, foreslo jeg følgende strategiske beslutning til bedriftseieren: siden prosjektet er ganske komplekst, vil implementeringen ta merkbar tid, så først lager jeg en MVP-versjon, som ikke vil ta mye tid og penger, men som vil tillate selskapet hans å få et konkurransefortrinn på markedet allerede "her og nå", og vil også utvide sine muligheter som taxitjeneste. På sin side vil en slik mellomløsning gi meg tid til mer gjennomtenkt utforme den endelige løsningen og tid til tekniske eksperimenter. Samtidig vil den implementerte programvareløsningen ikke garanteres å være riktig utformet og kan bli radikalt redesignet eller erstattet i fremtiden, men den vil definitivt utføre minimumsfunksjonaliteten for å "bryte seg vekk fra konkurrentene." Grunnleggeren av taxien likte ideen, så til slutt gjorde de det.
Jeg brukte de to første ukene på å studere forretningsprosessene i selskapet, og studere arbeidet til en taxi fra innsiden. Gjennomførte en forretningsanalyse av hvor, hva og hvordan kan automatiseres og om det i det hele tatt er nødvendig. Hvilke vanskeligheter og problemer møter selskapets ansatte? Hvordan de løses. Hvordan arbeidsdagen er organisert for bedriftens ansatte. Hvilke verktøy bruker de?
Ved slutten av den tredje uken, etter å ha startet arbeidet og studert spørsmål av interesse på Internett, tatt i betraktning bedriftseierens ønsker, så vel som min egen kunnskap og evner på den tiden, ble det besluttet å bruke følgende stabel :
- Databaseserver: MsSQL (gratis versjon med databasefilgrense på opptil 2 GB);
- Utvikling av en server som betjener mobile klienter i Delphi under Windows, siden det allerede fantes en Windows-server som databasen skulle installeres på, samt utviklingsmiljøet i seg selv letter rask utvikling;
- Tatt i betraktning de lave internetthastighetene på mobiltelefoner tilbake i 2009, må utvekslingsprotokollen mellom klient og server være binær. Dette vil redusere størrelsen på overførte datapakker og som et resultat øke stabiliteten til klienters arbeid med serveren;
Ytterligere to uker ble brukt til å designe protokollen og databasen. Resultatet ble 12 pakker som sikrer utveksling av all nødvendig data mellom mobilklienten og serveren og ca 20 tabeller i databasen. Jeg gjorde denne delen av arbeidet med tanke på fremtiden, selv om jeg må endre teknologistabelen fullstendig, bør strukturen til pakkene og databasen forbli uendret.
Etter forarbeidet var det mulig å begynne den praktiske gjennomføringen av ideen. For å få litt fart på prosessen og frigjøre tid til andre oppgaver, laget jeg en utkastversjon av mobilapplikasjonen, skisserte UI, delvis UX, og involverte en kjent java-programmerer i prosjektet. Og han fokuserte på utvikling, design og testing på serversiden.
Ved slutten av den andre måneden med arbeidet med MVP var den første versjonen av server- og klientprototypen klar.
Og innen utgangen av den tredje måneden, etter syntetiske tester og felttester, feilrettinger, mindre forbedringer av protokollen og databasen, var applikasjonen klar for produksjon. Som er det som ble gjort.
Fra dette øyeblikket begynner den mest interessante og vanskeligste delen av prosjektet.
Under overgangen av sjåfører til den nye programvaren ble det organisert XNUMX-timers vakt. Siden ikke alle kunne komme i arbeidstiden på dagtid. I tillegg, administrativt, etter en sterk avgjørelse fra selskapets grunnlegger, ble det organisert på en slik måte at påloggingsinformasjonen/passordet ble skrevet inn av sjefen for drosjetjenesten, og de ble ikke kommunisert til sjåføren. Fra min side var det nødvendig med teknisk støtte til brukere i tilfelle feil og uforutsette situasjoner.
Murphys lov forteller oss: "Alt som kan gå galt, vil gå galt." Og det var akkurat slik ting gikk galt... Det er én ting da jeg og flere drosjesjåfører testet applikasjonen på flere titalls testordrer. Og det er en helt annen sak når 500+ sjåfører på linjen jobber i sanntid på ekte bestillinger fra ekte mennesker.
Arkitekturen til mobilapplikasjonen var enkel og det var merkbart færre feil i den enn på serveren. Derfor var hovedfokus for arbeidet på serversiden. Den mest kritiske feilen i applikasjonen var problemet med frakobling fra serveren når Internett på telefonen gikk tapt og økten ble gjenopprettet igjen. Og Internett forsvant ganske ofte. For det første, i disse årene var ikke Internett på selve telefonen stabil nok. For det andre var det mange blindsoner der Internett rett og slett ikke fungerte. Vi identifiserte dette problemet nesten umiddelbart og innen XNUMX timer fikset og oppdatert alle tidligere installerte applikasjoner.
Serveren hadde hovedsakelig feil i ordrefordelingsalgoritmen og feilbehandling av enkelte forespørsler fra klienter. Etter å ha identifisert feil, rettet og oppdaterte jeg serveren.
Faktisk var det ikke så mange tekniske problemer på dette stadiet. Hele vanskeligheten var at jeg var på vakt på kontoret i nesten en måned, og dro bare av og til hjem. Sikkert 4-5 ganger. Og jeg sov i kramper, siden jeg på den tiden jobbet med prosjektet alene og ingen bortsett fra meg kunne fikse noe.
En måned, dette betyr ikke at alt feilet konstant i en måned, og jeg kodet noe uten å stoppe. Vi bestemte oss nettopp for det. Tross alt var virksomheten allerede i drift og gikk med overskudd. Det er bedre å spille det trygt og hvile senere enn å miste kunder og fortjeneste nå. Vi forsto dette veldig godt, så hele teamet viet samlet maksimal oppmerksomhet og tid til å introdusere ny programvare i taxisystemet. Og med tanke på den nåværende trafikken av bestillinger, vil vi definitivt eliminere alle manglene innen en måned. Vel, skjulte feil som kan forbli vil absolutt ikke ha kritiske konsekvenser for forretningsprosessen, og om nødvendig kan de rettes på rutinemessig basis.
Her er det nødvendig å merke seg den uvurderlige hjelpen fra direktørene og formennene for taxitjenester, som, med maksimal forståelse av kompleksiteten i situasjonen med å overføre sjåfører til ny programvare, jobbet med sjåfører døgnet rundt. Faktisk, etter å ha fullført installasjonen av nye programmer på telefoner, mistet vi ikke en eneste driver. Og de økte ikke kritisk prosentandelen av ikke-fjerning av klienter, som snart ble returnert til normale nivåer.
Dette fullførte den første fasen av arbeidet med prosjektet. Og det skal bemerkes at resultatet ikke lot vente på seg. Ved å automatisere distribusjonen av bestillinger til sjåfører uten menneskelig innblanding, ble gjennomsnittlig ventetid for en taxi av en klient redusert med en størrelsesorden, noe som naturlig nok økte kundelojaliteten til tjenesten. Dette førte til en økning i antall bestillinger. Etter dette økte antallet taxisjåfører. Som et resultat har også antallet vellykket gjennomførte bestillinger økt. Og som et resultat økte selskapets fortjeneste. Selvfølgelig, her går jeg litt foran meg selv, siden hele denne prosessen ikke fant sted umiddelbart. Å si at ledelsen var fornøyd er å si ingenting. Jeg fikk ubegrenset tilgang til videre finansiering av prosjektet.
For å fortsette ..
Kilde: www.habr.com