У канцы снежня 2008 гады мяне запрасілі ў адну са службаў таксі г.Перми з мэтай аўтаматызацыі існых бізнэс-працэсаў. У цэлым перада мной былі пастаўлены тры фундаментальныя задачы:
- Распрацаваць праграмны комплекс для call цэнтра з мабільным дадаткам для вадзіцеляў таксі і аўтаматызаваць унутраныя бізнес-працэсы.
- Зрабіць усё трэба было ў максімальна сціснутыя тэрміны.
- Мець уласнае, а не набытае ў іншых распрацоўшчыкаў, праграмнае забеспячэнне, якое ў далейшым па меры развіцця бізнесу можна было самастойна маштабаваць пад пастаянна змяняюцца ўмовы рынку.
На той момант я не разумеў, як уладкованы гэты рынак і яго нюансы, але тым не менш відавочнымі для мяне былі дзве рэчы. Call цэнтр неабходна будаваць на базе праграмнай АТС asterisk з адчыненым зыходным кодам. Абмен інфармацыяй паміж call цэнтрам і мабільным дадаткам па сутнасці з'яўляецца кліент-серверным рашэннем з усімі адпаведнымі патэрнамі праектавання архітэктуры будучага праекта і яго праграмавання.
Пасля папярэдняй ацэнкі пастаўленых задач, тэрмінаў выканання і затрат на рэалізацыю праекта, узгадніўшы ўсе неабходныя пытанні з уладальнікам службы таксі, у студзені 2009 года я пачаў работу.
Забягаючы наперад скажу адразу. У выніку атрымалася якая маштабуецца платформа, якая працуе на 60+ серверах, у 12 гарадах Расіі і 2 Казахстана. Агульны прыбытак кампаніі складала 100+ млн.руб/месяц.
Этап першы. Прататып
Паколькі на той момант у мяне не было практычнага досведу ў ip тэлефаніі, а з asterisk быў знакам павярхоўна ў рамках «хатніх» эксперыментаў, было прынята рашэнне пачаць працу з распрацоўкі мабільнага прыкладання і сервернай часткі. Адначасна закрываючы прабелы ў ведах па астатніх задачах.
Калі з мабільным дадаткам больш-менш усё было зразумела. На той момант яно магло быць напісана толькі на java для простых кнопкавых тэлефонаў, то з напісаннем сервера, які абслугоўвае мабільных кліентаў, пытанне стаяла некалькі складаней:
- Якая серверная АС будзе выкарыстоўвацца;
- Зыходзячы з логікі, што мова праграмавання выбіраецца пад задачу, а не наадварот і з улікам п.1, якая мова праграмавання будзе аптымальнай для рашэння задач;
- Пры праектаванні неабходна было ўлічыць меркаваныя ў будучыні высокія нагрузкі на сэрвіс;
- Якая база дадзеных зможа гарантаваць адмоваўстойлівасць пры высокіх нагрузках і як захаваць хуткі час водгуку БД пры росце колькасці зваротаў да яе;
- Вызначальным фактарам з'яўлялася хуткасць распрацоўкі і магчымасць хуткага маштабавання кода.
- Кошт абсталявання і яго абслугоўвання ў далейшым (адной з умоў заказчыка - сервера павінны знаходзіцца на падкантрольнай яму тэрыторыі);
- Кошт распрацоўшчыкаў, якія спатрэбяцца на наступных этапах працы над платформай;
А таксама шмат іншых пытанняў, звязаных з праектаваннем і распрацоўкай.
Перад пачаткам працы над праектам я прапанаваў уладальніку бізнэсу наступнае стратэгічнае рашэнне: паколькі праект досыць складаны, яго рэалізацыя зойме прыкметную колькасць часу, таму спачатку я ствараю MVP версію, на якую сыдзе не так шмат часу і сродкаў, але якая дазволіць яго кампаніі атрымаць канкурэнтная перавага на рынку ўжо "тут і цяпер", а таксама пашырыць яго магчымасці як службы таксі. Мне ж у сваю чаргу такое прамежкавае рашэнне дасць час больш абдумана спраектаваць канчатковае рашэнне і час на тэхнічныя эксперыменты. Пры гэтым, рэалізаванае праграмнае рашэнне не будзе гарантавана правільна спраектавана і магчыма ў далейшым будзе кардынальна перароблена або заменена, але яно дакладна будзе выконваць мінімальна неабходны функцыянал для "адрыву ад канкурэнтаў". Ідэя заснавальніку таксі спадабалася, таму ў выніку так і зрабілі.
Першыя два тыдні я выдаткаваў на вывучэнне бізнес-працэсаў у кампаніі, і вывучэнне працы таксі "знутры". Правёў бізнэс-аналіз, дзе, што і як можна аўтаматызаваць і ці трэба ўвогуле. З якімі цяжкасцямі і праблемамі сутыкаюцца супрацоўнікі кампаніі? Як іх рашаюць. Як арганізаваны працоўны дзень у працаўнікоў кампаніі. Якія інструменты карыстаюцца.
Да канца трэцяга тыдня пасля пачатку працы і вывучэнні пытанняў, якія цікавяць у інтэрнэце, з улікам пажаданняў уладальніка бізнэсу, а таксама маіх уласных ведаў і магчымасцяў на той момант, было прынята рашэнне ўжыць наступны стэк:
- Сервер БД: MsSQL (бясплатная версія з абмежаваннем файла БД да 2Гб);
- Распрацоўка сервера, які абслугоўвае мабільных кліентаў, у Delphi пад windows, бо ўжо меўся windows сервер на якім будзе ўсталявана БД, а таксама само асяроддзе распрацоўкі спрыяе хуткай распрацоўцы;
- З улікам нізкіх хуткасцяў інтэрнэту на мабільных тэлефонах у далёкім 2009 годзе - пратакол абмену паміж кліентам і серверам павінен быць бінарным. Гэта дазволіць паменшыць памер перадаюцца пакетаў з дадзенымі і як следства павысіць стабільнасць працы кліентаў з серверам;
Яшчэ два тыдні пайшлі на праектаванне пратакола і базы даных. Атрымалася 12 пакетаў, якія забяспечваюць абмен усімі неабходнымі дадзенымі паміж мабільным кліентам і серверам і каля 20 табліц у БД. Гэтую частку працы я рабіў з улікам на будучыню, нават калі давядзецца змяніць стэк тэхналогій цалкам, структура пакетаў і БД павінна застацца нязменнай.
Пасля падрыхтоўчых прац можна было прыступаць да практычнай рэалізацыі ідэі. Каб крыху паскорыць працэс і вызваліць сабе час для астатніх задач я зрабіў чарнавую версію мабільнага прыкладання, накіды UI, часткова UX і прыцягнуў да праекту знаёмага java праграміста. А сам засяродзіўся на распрацоўцы сервернай часткі, праектаванні і тэсціраванні.
Да канца другога месяца працы над MVP, была гатова першая версія прататыпа сервера і кліента.
А да канца трэцяга месяца пасля сінтэтычных тэстаў і палявых выпрабаванняў, фікса багаў, невялікіх дапрацовак пратакола і БД прыкладанне было гатова для вываду ў прадакшэн. Што і было зроблена.
З гэтага моманту пачынаецца самая цікавая і самая складаная частка працы над праектам.
У працэсе пераходу вадзіцеляў на новае ПЗ было арганізавана кругласутачнае дзяжурства. Бо не ўсе маглі прыехаць днём у працоўны час. Да таго ж адміністрацыйна, валявым рашэннем заснавальніка кампаніі, было арганізавана так, што лагін/пароль уводзіў менеджэр службы таксі і кіроўцу яны не паведамляліся. З майго боку была патрэбна тэхнічная падтрымка карыстальнікаў на выпадак збояў і непрадбачаных сітуацый.
Закон Мэрфі кажа нам: "Усё, што можа пайсці не так, пойдзе не так". І менавіта не так усё і пайшло… Адна справа, калі я, ды некалькі таксістаў пратэставалі дадатак на некалькіх дзясятках тэставых заказаў. І зусім іншая справа, калі 500+ кіроўцаў на лініі працуюць у рэжыме рэальнага часу на сапраўдных замовах рэальных людзей.
Архітэктура мабільнага прыкладання была простай і багаў у ім аказалася прыкметна менш, чым у серверы. Таму асноўны фокус прац быў на сервернай частцы. Самым крытычным глюкам у дадатку была праблема дысканэкту ад сервера пры знікненні інтэрнэту на тэлефоне і паўторным аднаўленні сесіі. А Інтэрнэт знікаў даволі часта. Па-першае, сам па сабе ў тыя гады інтэрнэт на тэлефоне не быў дастаткова стабільным. Па-другое, было шмат сляпых зон, дзе інтэрнэт проста не працаваў. Гэтую праблему мы выявілі амаль адразу і на працягу сутак ухіліў і абнавіў усе ўсталяваныя раней прыкладанні.
На серверы ў асноўным былі памылкі ў алгарытме размеркавання заказаў і не карэктнай апрацоўкай некаторых запытаў ад кліентаў. Па факце выяўлення глюкаў, выпраўляў і абнаўляў сервер.
Насамрэч тэхнічных праблем на гэтым этапе было не так ужо і шмат. Уся складанасць была ў тым, што амаль месяц я дзяжурыў у офісе, толькі зрэдку выбіраючыся дадому. Разы 4-5, мусіць. І спаў урыўкамі, бо над праектам на той момант працаваў адзін і акрамя мяне ніхто выправіць нічога не змог бы.
Месяц, гэта не значыць, што ўсё стала глючыла на працягу месяца і я, не перастаючы нешта тамака кадзіў. Проста мы так вырашылі. Бо бізнэс ужо працаваў і прыносіў прыбытак. І лепш перастрахавацца, і адпачыць потым, чым губляць кліентаў і прыбытак зараз. Мы ўсё гэта выдатна разумелі, таму ўсёй камандай разам надалі максімальную ўвагу і час увядзенню новага ПЗ у сістэму таксі. А з улікам бягучага трафіку заказаў, за месяц мы сапраўды ўстаранім усе недахопы. Ну а ўтоеныя багі, што могуць застацца ўжо сапраўды не будуць мець крытычных наступстваў на бізнэс працэс і іх пры неабходнасці можна выпраўляць у працоўным парадку.
Тут трэба адзначыць неацэнную дапамогу з боку дырэктараў і брыгадзіраў службаў таксі, якія з максімальным разуменнем складанасці сітуацыі пераводу вадзіцеляў на новае ПЗ кругласутачна працавалі з вадзіцелям. Па факце, пасля завяршэння работ па ўстаноўцы новых праграм на тэлефоны мы не страцілі ніводнага вадзіцеля. І не крытычна павялічылі працэнт не вывазу кліентаў, які ў хуткім часе вярнулі да нармальных паказчыкаў.
На гэтым быў завершаны першы этап працы над праектам. І трэба заўважыць вынік не прымусіў сябе чакаць. За кошт аўтаматызацыі раздачы заказаў кіроўцам без удзелу чалавека - сярэдні час чакання таксі кліентам скарацілася на парадак, што натуральным чынам павысіла лаяльнасць кліентаў да службы. Гэта прывяло да павелічэння колькасці заказаў. Следам павялічылася і колькасць таксістаў. Як следства павялічылася і колькасць паспяхова завершаных заказаў. І як вынік - павялічыўся прыбытак кампаніі. Зразумела, тут я забягаю некалькі наперад, бо ўвесь гэты працэс прайшоў не маментальна. Сказаць, што кіраўніцтва было дастаткова - нічога не сказаць. Мне быў адкрыты безліміт у далейшым фінансаванні праекту.
Працяг будзе..
Крыніца: habr.com