Fine de decembro 2008, mi estis invitita al unu el la taksiaj servoj en Perm kun la celo aŭtomatigi ekzistantajn komercajn procezojn. Ĝenerale, mi ricevis tri fundamentajn taskojn:
- Disvolvu programaron por vokcentro kun movebla aplikaĵo por taksiistoj kaj aŭtomatigu internajn komercajn procezojn.
- Ĉio devis esti farita en la plej mallonga tempo.
- Havu vian propran programaron, prefere ol aĉetita de triaj programistoj, kiuj estontece, dum la komerco disvolviĝas, povas esti sendepende skalita al konstante ŝanĝiĝantaj merkatkondiĉoj.
Tiutempe mi ne komprenis kiel funkcias ĉi tiu merkato kaj ĝiaj nuancoj, sed tamen du aferoj estis evidentaj al mi. La telefoncentro devas esti konstruita surbaze de la malfermfonta asteriska programaro PBX. La interŝanĝo de informoj inter la telefoncentro kaj la movebla aplikaĵo estas esence kliento-servila solvo kun ĉiuj respondaj ŝablonoj por desegni la arkitekturon de la estonta projekto kaj ĝia programado.
Post antaŭtakso de la taskoj, templimoj kaj kostoj de la projekto, kaj interkonsentinte ĉiujn necesajn aferojn kun la posedanto de la taksioservo, mi eklaboris en januaro 2009.
Rigardante antaŭen, mi tuj diros. La rezulto estis skalebla platformo funkcianta per 60+ serviloj en 12 urboj en Rusio kaj 2 en Kazaĥio. La totala profito de la firmao estis 100+ milionoj da rubloj/monato.
Etapo unu. Prototipo
Ĉar tiam mi ne havis praktikan sperton pri IP-telefono, kaj mi nur supraĵe konis asteriskon kiel parto de "hejmaj" eksperimentoj, oni decidis eklabori kun la disvolviĝo de movebla aplikaĵo kaj servila parto. Samtempe, fermante mankojn en scio pri aliaj taskoj.
Se kun la poŝtelefona aplikaĵo ĉio estis pli-malpli klara. Tiutempe, ĝi povus esti skribita nur en java por simplaj butonaj telefonoj, sed skribi servilon servantan poŝtelefonajn klientojn estis iom pli komplika:
- Kia servilo OS estos uzata;
- Surbaze de la logiko ke programlingvo estas elektita por tasko, kaj ne inverse, kaj konsiderante punkton 1, kiu programlingvo estos optimuma por solvi problemojn;
- Dum la dezajno, estis necese konsideri la atendatajn estontajn altajn ŝarĝojn sur la servo;
- Kiu datumbazo povas garantii misfunkciadon sub altaj ŝarĝoj kaj kiel konservi rapidan datumbazan respondtempon kiam la nombro da petoj al ĝi pliiĝas;
- La determinanta faktoro estis la rapideco de evoluo kaj la kapablo rapide skali la kodon
- La kosto de ekipaĵo kaj ĝia bontenado en la estonteco (unu el la kondiĉoj de la kliento estas, ke la serviloj devas troviĝi en la teritorio sub lia kontrolo);
- Kosto de programistoj, kiuj estos bezonataj en la sekvaj etapoj de laboro sur la platformo;
Same kiel multaj aliaj aferoj rilataj al dezajno kaj evoluo.
Antaŭ ol komenci labori pri la projekto, mi proponis la sekvan strategian decidon al la komercisto: ĉar la projekto estas sufiĉe kompleksa, ĝia efektivigo prenos rimarkindan tempon, do unue mi kreas MVP-version, kiu ne prenos multe da tempo kaj mono, sed kiu permesos al lia firmao akiri konkurencivan avantaĝon sur la merkato jam "ĉi tie kaj nun", kaj ankaŭ vastigos siajn kapablojn kiel taksioservo. Siavice tia meza solvo donos al mi tempon por pli pripense desegni la finan solvon kaj tempon por teknikaj eksperimentoj. Samtempe, la efektivigita programara solvo ne garantiiĝos ĝuste desegnita kaj eble estos radikale restrukturita aŭ anstataŭigita en la estonteco, sed ĝi certe plenumos la minimuman necesan funkciecon por "foriĝi de konkurantoj." La fondinto de la taksio ŝatis la ideon, do finfine ili faris ĝin.
Mi pasigis la unuajn du semajnojn studante la komercajn procezojn en la firmao, kaj studante la laboron de taksio de interne. Faris komercan analizon de kie, kio kaj kiel povas esti aŭtomatigita kaj ĉu ĝi estas necesa. Kiajn malfacilaĵojn kaj problemojn alfrontas dungitoj de la kompanio? Kiel ili estas solvitaj. Kiel la labortago estas organizita por la dungitoj de la firmao. Kiajn ilojn ili uzas?
Antaŭ la fino de la tria semajno, post komenci laboron kaj studi interesajn aferojn en Interreto, konsiderante la dezirojn de la komercisto, kaj ankaŭ miajn proprajn scion kaj kapablojn en tiu tempo, oni decidis apliki la sekvan stakon. :
- Datumbaza servilo: MsSQL (senpaga versio kun datumbaza dosierlimo ĝis 2GB);
- Disvolviĝo de servilo servanta moveblajn klientojn en Delfo sub Vindozo, ĉar jam ekzistis Vindoza servilo sur kiu la datumbazo estus instalita, same kiel la evolumedio mem faciligas rapidan evoluon;
- Konsiderante la malaltajn interretajn rapidojn ĉe poŝtelefonoj en 2009, la interŝanĝa protokolo inter la kliento kaj servilo devas esti binara. Ĉi tio reduktos la grandecon de transdonitaj datumpakaĵoj kaj, kiel rezulto, pliigos la stabilecon de la laboro de klientoj kun la servilo;
Pliaj du semajnoj estis pasigitaj projektante la protokolon kaj datumbazon. La rezulto estis 12 pakoj, kiuj certigas la interŝanĝon de ĉiuj necesaj datumoj inter la movebla kliento kaj servilo kaj ĉirkaŭ 20 tabloj en la datumbazo. Mi faris ĉi tiun parton de la laboro konsiderante la estontecon, eĉ se mi devas tute ŝanĝi la teknologian stakon, la strukturo de la pakaĵoj kaj datumbazo restu senŝanĝa.
Post la prepara laboro, eblis komenci la praktikan efektivigon de la ideo. Por iom akceli la procezon kaj liberigi tempon por aliaj taskoj, mi faris malneton de la poŝtelefona aplikaĵo, skizis la UI, parte la UX, kaj implikis konatan java-programiston en la projekton. Kaj li koncentriĝis pri servo-flanka evoluo, dezajno kaj testado.
Antaŭ la fino de la dua monato da laboro pri la MVP, la unua versio de la servilo kaj kliento-prototipo estis preta.
Kaj antaŭ la fino de la tria monato, post sintezaj testoj kaj kampaj provoj, korektoj de cimoj, etaj plibonigoj al la protokolo kaj datumbazo, la aplikaĵo estis preta por produktado. Kiu estas kio estis farita.
De ĉi tiu momento komenciĝas la plej interesa kaj plej malfacila parto de la projekto.
Dum la transiro de ŝoforoj al la nova programaro, XNUMX-hora devo estis organizita. Ĉar ne ĉiuj povis veni dum laborhoroj dumtage. Krome, administre, per fortvola decido de la fondinto de la firmao, ĝi estis organizita tiel, ke la ensaluton/pasvorton estis enigita de la administranto de la taksioservo kaj ili ne estis komunikitaj al la ŝoforo. Miaflanke necesas teknika subteno por uzantoj en kazo de malsukcesoj kaj neantaŭviditaj situacioj.
La Leĝo de Murphy diras al ni: "Ĉio, kio povas misfunkcii, misfunkcios." Kaj ĝuste tiel la aferoj misfunkciis... Estas unu afero, kiam mi kaj pluraj taksiistoj testis la aplikaĵon sur kelkdeko da testaj mendoj. Kaj estas tute alia afero kiam pli ol 500 ŝoforoj en la linio laboras en reala tempo laŭ realaj mendoj de realaj homoj.
La arkitekturo de la poŝtelefona aplikaĵo estis simpla kaj estis rimarkeble malpli da cimoj en ĝi ol en la servilo. Tial, la ĉefa fokuso de laboro estis sur la servila flanko. La plej kritika eraro en la aplikaĵo estis la problemo de malkonekto de la servilo kiam la Interreto en la telefono estis perdita kaj la sesio estis restarigita denove. Kaj la interreto malaperis sufiĉe ofte. Unue, en tiuj jaroj la Interreto sur la telefono mem ne estis sufiĉe stabila. Due, estis multaj blindaj punktoj kie la Interreto simple ne funkciis. Ni identigis ĉi tiun problemon preskaŭ tuj kaj ene de XNUMX horoj riparis kaj ĝisdatigis ĉiujn antaŭe instalitajn aplikaĵojn.
La servilo ĉefe havis erarojn en la ordon-distribua algoritmo kaj malĝusta prilaborado de iuj petoj de klientoj. Post identigo de eraroj, mi korektis kaj ĝisdatigis la servilon.
Fakte, ne estis tiom da teknikaj problemoj en ĉi tiu etapo. La tuta malfacilaĵo estis, ke mi deĵoris ĉe la oficejo preskaŭ unu monaton, nur foje hejmenirante. Verŝajne 4-5 fojojn. Kaj mi ekdormis, ĉar tiam mi sole laboris pri la projekto kaj neniu krom mi povis ion ripari.
Monaton, ĉi tio ne signifas, ke ĉio konstante fuŝis dum monato kaj mi kodis ion sen ĉesi. Ni ĵus decidis tion. Post ĉio, la komerco jam funkciis kaj faris profiton. Pli bone estas ludi sekure kaj ripozi poste ol perdi klientojn kaj profitojn nun. Ni ĉiuj tre bone komprenis tion, do la tuta teamo kolektive dediĉis maksimuman atenton kaj tempon al enkonduko de nova programaro en la taksiosistemon. Kaj konsiderante la nunan trafikon de mendoj, ni certe forigos ĉiujn mankojn ene de monato. Nu, kaŝitaj cimoj, kiuj povas resti, certe ne havos kritikajn sekvojn sur la komerca procezo kaj, se necese, ili povas esti korektitaj rutine.
Ĉi tie necesas noti la valoregan helpon de la direktoroj kaj skipestroj de taksiaj servoj, kiuj, kun maksimuma kompreno pri la komplekseco de la situacio de translokado de ŝoforoj al nova programaro, laboris kun ŝoforoj ĉirkaŭ la horloĝo. Fakte, post kompletigi la instaladon de novaj programoj en telefonoj, ni ne perdis eĉ unu pelilon. Kaj ili ne kritike pliigis la procenton de neforigo de klientoj, kiu baldaŭ revenis al normalaj niveloj.
Tio kompletigis la unuan fazon de laboro en la projekto. Kaj oni devas rimarki, ke la rezulto ne longe atendis. Aŭtomatigante la distribuadon de mendoj al ŝoforoj sen homa interveno, la meza atendotempo por taksio de kliento estis reduktita per grandordo, kiu nature pliigis klientlojalecon al la servo. Ĉi tio kaŭzis pliiĝon de la nombro da mendoj. Post tio, la nombro da taksiistoj pliiĝis. Kiel rezulto, la nombro de sukcese plenumitaj mendoj ankaŭ pliiĝis. Kaj kiel rezulto, la profitoj de la kompanio pliiĝis. Kompreneble, ĉi tie mi iom antaŭiĝas, ĉar ĉi tiu tuta procezo ne okazis tuj. Diri, ke la administrado estis kontenta, estas diri nenion. Mi ricevis senliman aliron al plia financado de la projekto.
Daŭrigota..
fonto: www.habr.com