Joulukuun 2008 lopussa minut kutsuttiin yhteen Permin taksipalveluista tavoitteena automatisoida olemassa olevia liiketoimintaprosesseja. Yleisesti ottaen minulle annettiin kolme perustehtävää:
- Kehitä puhelinpalveluun ohjelmistopaketti mobiilisovelluksella taksinkuljettajille ja automatisoi sisäiset liiketoimintaprosessit.
- Kaikki piti tehdä mahdollisimman lyhyessä ajassa.
- Käytä omia ohjelmistoja sen sijaan, että ostaisit kolmannen osapuolen kehittäjiltä, jotka tulevaisuudessa, liiketoiminnan kehittyessä, voidaan skaalata itsenäisesti jatkuvasti muuttuviin markkinaolosuhteisiin.
Tuolloin en ymmärtänyt näiden markkinoiden toimintaa ja sen vivahteita, mutta kaksi asiaa oli kuitenkin minulle ilmeisiä. Puhelinkeskus on rakennettava avoimen lähdekoodin asterisk-ohjelmiston PBX pohjalta. Puhelinkeskuksen ja mobiilisovelluksen välinen tiedonvaihto on oleellisesti asiakas-palvelinratkaisu, jossa on kaikki vastaavat mallit tulevan projektin arkkitehtuurin suunnitteluun ja sen ohjelmointiin.
Hankkeen tehtävien, aikataulujen ja kustannusten alustavan arvioinnin jälkeen ja sovittuani kaikista tarvittavista asioista taksipalvelun omistajan kanssa aloitin työt tammikuussa 2009.
Eteenpäin katsoen sanon heti. Tuloksena oli skaalautuva alusta, joka toimii yli 60 palvelimella 12 kaupungissa Venäjällä ja kahdessa Kazakstanissa. Yrityksen kokonaistulos oli 2+ miljoonaa ruplaa/kk.
Vaihe yksi. Prototyyppi
Koska minulla ei tuolloin ollut käytännön kokemusta IP-puhelimesta ja olin vain pinnallisesti perehtynyt asteriskiin osana "koti"-kokeiluja, päätettiin aloittaa mobiilisovelluksen ja palvelinosan kehitystyö. Samalla korjataan muiden tehtävien tiedossa olevia aukkoja.
Jos mobiilisovelluksella kaikki oli enemmän tai vähemmän selvää. Tuohon aikaan sen voitiin kirjoittaa javalla vain yksinkertaisille painonapin puhelimille, mutta mobiiliasiakkaita palvelevan palvelimen kirjoittaminen oli hieman monimutkaisempaa:
- Mitä palvelimen käyttöjärjestelmää käytetään;
- Perustuen logiikkaan, että tehtävään valitaan ohjelmointikieli, eikä päinvastoin, ja ottaen huomioon kohta 1, mikä ohjelmointikieli on optimaalinen ongelmien ratkaisemiseen;
- Suunnittelussa oli otettava huomioon palvelun odotettavissa olevat korkeat kuormitukset tulevaisuudessa;
- Mikä tietokanta voi taata vikasietoisuuden suurilla kuormituksilla ja kuinka ylläpitää nopeaa tietokannan vasteaikaa siihen lähetettävien pyyntöjen määrän kasvaessa;
- Ratkaiseva tekijä oli kehitysnopeus ja kyky skaalata koodia nopeasti
- Laitteiston ja sen ylläpidon kustannukset tulevaisuudessa (yksi asiakkaan ehdoista on, että palvelimet sijaitsevat hänen hallinnassaan alueella);
- Kustannukset kehittäjistä, joita tarvitaan alustan työskentelyn seuraavissa vaiheissa;
Sekä monia muita suunnitteluun ja kehittämiseen liittyviä asioita.
Ennen projektin aloittamista ehdotin yrityksen omistajalle seuraavaa strategista päätöstä: koska projekti on melko monimutkainen, sen toteuttaminen vie huomattavan paljon aikaa, joten ensin luon MVP-version, joka ei vie paljon aikaa ja rahaa, mutta joka mahdollistaa hänen yrityksensä saavuttaa kilpailuetua markkinoilla jo "tässä ja nyt" ja laajentaa kykyään myös taksipalveluna. Tällainen väliratkaisu puolestaan antaa minulle aikaa harkitummin suunnitella lopullista ratkaisua ja aikaa teknisille kokeiluille. Samanaikaisesti toteutetun ohjelmistoratkaisun oikeaa suunnittelua ei taata, ja se voidaan suunnitella radikaalisti uudelleen tai korvata tulevaisuudessa, mutta se suorittaa ehdottomasti vähimmäistoiminnot, joita tarvitaan "irtautumaan kilpailijoista". Taksin perustaja piti ajatuksesta, joten he lopulta tekivät sen.
Ensimmäiset kaksi viikkoa opiskelin yrityksen liiketoimintaprosesseja ja opiskelin taksin työtä sisältä käsin. Tein liiketoiminta-analyysin siitä, missä, mitä ja miten voidaan automatisoida ja onko se ylipäätään tarpeellista. Mitä vaikeuksia ja ongelmia yrityksen työntekijät kohtaavat? Miten ne ratkaistaan. Miten yrityksen työntekijöiden työpäivä järjestetään. Mitä työkaluja he käyttävät?
Kolmannen viikon loppuun mennessä, aloitettuani työt ja tutkittuaan kiinnostavia asioita Internetissä, ottaen huomioon yrityksen omistajan toiveet sekä omat tuolloiset tietoni ja kykyni, päätettiin soveltaa seuraavaa pinoa :
- Tietokantapalvelin: MsSQL (ilmainen versio tietokantatiedostorajoituksella 2 Gt asti);
- Mobiiliasiakkaita palvelevan palvelimen kehittäminen Delphissä Windowsin alla, koska siellä oli jo Windows-palvelin, jolle tietokanta asennettaisiin, sekä itse kehitysympäristö mahdollistaa nopean kehityksen;
- Ottaen huomioon matkapuhelimien alhaiset Internet-nopeudet vuonna 2009, asiakkaan ja palvelimen välisen vaihtoprotokollan tulee olla binäärinen. Tämä pienentää lähetettävien datapakettien kokoa ja sen seurauksena lisää asiakkaiden työskentelyn vakautta palvelimen kanssa;
Toiset kaksi viikkoa käytettiin protokollan ja tietokannan suunnitteluun. Tuloksena oli 12 pakettia, jotka varmistavat kaiken tarvittavan tiedon vaihdon mobiiliasiakkaan ja palvelimen välillä sekä noin 20 taulukkoa tietokannassa. Tein tämän osan työstä tulevaisuutta ajatellen, vaikka joutuisikin vaihtamaan teknologiapinoa kokonaan, niin pakettien ja tietokannan rakenteen pitäisi pysyä ennallaan.
Valmistelun jälkeen oli mahdollista aloittaa idean käytännön toteutus. Nopeuttaakseni prosessia hieman ja vapauttaakseni aikaa muihin tehtäviin, tein mobiilisovelluksesta luonnosversion, hahmottelin käyttöliittymän, osittain UX:n ja otin projektiin mukaan tutun java-ohjelmoijan. Ja hän keskittyi palvelinpuolen kehittämiseen, suunnitteluun ja testaukseen.
Toisen MVP-työkuukauden lopussa palvelimen ja asiakkaan prototyypin ensimmäinen versio oli valmis.
Ja kolmannen kuukauden loppuun mennessä synteettisten testien ja kenttätestien, virheenkorjausten sekä protokollaan ja tietokantaan tehtyjen pienten parannusten jälkeen sovellus oli valmis tuotantoon. Mitä tehtiin.
Tästä hetkestä alkaa projektin mielenkiintoisin ja vaikein osa.
Kuljettajien uuteen ohjelmistoon siirtymisen aikana järjestettiin XNUMX tunnin päivystys. Koska kaikki eivät voineet tulla työaikana päiväsaikaan. Lisäksi hallinnollisesti yrityksen perustajan voimakkaalla päätöksellä se oli järjestetty siten, että sisäänkirjautumistunnuksen/salasanan syötti taksipalvelun johtaja eikä niitä välitetty kuljettajalle. Omalta osaltani tarvittiin teknistä tukea käyttäjille vikatilanteissa ja odottamattomissa tilanteissa.
Murphyn laki kertoo meille: "Kaikki mikä voi mennä pieleen, menee pieleen." Ja juuri näin asiat menivät pieleen... Se on yksi asia, kun minä ja useat taksinkuljettajat testasimme sovellusta useilla kymmenillä testitilauksilla. Ja se on täysin eri asia, kun yli 500 kuljettajaa linjalla työskentelee reaaliajassa oikeiden ihmisten tilauksista.
Mobiilisovelluksen arkkitehtuuri oli yksinkertainen ja siinä oli huomattavasti vähemmän bugeja kuin palvelimessa. Siksi työn pääpaino oli palvelinpuolella. Kriittisin häiriö sovelluksessa oli yhteyden katkeaminen palvelimesta, kun puhelimessa oleva Internet katkesi ja istunto palautui uudelleen. Ja Internet katosi melko usein. Ensinnäkin noina vuosina Internet itse puhelimessa ei ollut tarpeeksi vakaa. Toiseksi, oli monia sokeita kohtia, joissa Internet ei yksinkertaisesti toiminut. Havaitsimme tämän ongelman lähes välittömästi ja korjasimme ja päivitimme kaikki aiemmin asennetut sovellukset XNUMX tunnin kuluessa.
Palvelimella oli pääasiassa virheitä tilausten jakelualgoritmissa ja joidenkin asiakkaiden pyyntöjen virheellinen käsittely. Kun havaitsin vikoja, korjasin ja päivitin palvelimen.
Itse asiassa tässä vaiheessa ei ollut niin paljon teknisiä ongelmia. Koko vaikeus oli se, että olin töissä toimistolla melkein kuukauden ja menin vain satunnaisesti kotiin. Varmaan 4-5 kertaa. Ja nukuin kohtauksissa, koska työskentelin tuolloin projektin parissa yksin eikä kukaan muu kuin minä voinut korjata mitään.
Kuukausi, tämä ei tarkoita, että kaikki oli jatkuvasti häiriöitä kuukauden ajan ja koodasin jotain pysähtymättä. Päätimme juuri niin. Loppujen lopuksi yritys oli jo toiminnassa ja teki voittoa. On parempi pelata varman päälle ja levätä myöhemmin kuin menettää asiakkaita ja voittoja nyt. Ymmärsimme kaikki tämän erittäin hyvin, joten koko tiimi panosti yhdessä mahdollisimman paljon huomiota ja aikaa uusien ohjelmistojen tuomiseen taksijärjestelmään. Ja ottaen huomioon nykyisen tilausliikenteen, korjaamme ehdottomasti kaikki puutteet kuukauden sisällä. No, piilossa mahdollisesti jäävillä bugeilla ei varmasti ole kriittisiä seurauksia liiketoimintaprosessiin ja ne voidaan tarvittaessa korjata rutiininomaisesti.
Tässä on huomioitava korvaamaton apu taksipalvelujen johtajilta ja työnjohtajilta, jotka ymmärtäen mahdollisimman paljon kuljettajien uuteen ohjelmistoon siirtämisen tilanteen monimutkaisuutta, työskentelivät kuljettajien kanssa kellon ympäri. Itse asiassa uusien ohjelmien asennuksen jälkeen puhelimiin emme menettäneet yhtäkään ohjainta. Eivätkä he lisänneet kriittisesti asiakkaiden poistamatta jättämisen prosenttiosuutta, joka palasi pian normaalille tasolle.
Tällä saatiin päätökseen projektin ensimmäinen työvaihe. Ja on huomattava, että tulos ei odottanut kauan. Automatisoimalla tilausten jakaminen kuljettajille ilman ihmisen väliintuloa lyhensi asiakkaan keskimääräistä taksin odotusaikaa suuruusluokkaa, mikä luonnollisesti lisäsi asiakkaiden uskollisuutta palvelua kohtaan. Tämä johti tilausten määrän kasvuun. Tämän jälkeen taksinkuljettajien määrä kasvoi. Tämän seurauksena myös onnistuneesti suoritettujen tilausten määrä on kasvanut. Ja sen seurauksena yhtiön voitto kasvoi. Tietenkin tässä olen menossa hieman edellä, koska koko prosessi ei tapahtunut hetkessä. Sanoa, että johto oli tyytyväinen, ei sano mitään. Sain rajoittamattoman pääsyn hankkeen lisärahoitukseen.
Jatketaan ..
Lähde: will.com