Pod koniec grudnia 2008 roku zostałem zaproszony do jednego z serwisów taksówkowych w Permie w celu automatyzacji istniejących procesów biznesowych. Generalnie postawiono mi trzy podstawowe zadania:
- Opracuj pakiet oprogramowania dla call center z aplikacją mobilną dla taksówkarzy i zautomatyzuj wewnętrzne procesy biznesowe.
- Wszystko należało zrobić w jak najkrótszym czasie.
- Posiadaj własne oprogramowanie, a nie kupowane od zewnętrznych programistów, które w przyszłości, w miarę rozwoju biznesu, będzie można samodzielnie skalować do stale zmieniających się warunków rynkowych.
Nie rozumiałem wtedy jeszcze jak ten rynek działa i jakie są jego niuanse, ale mimo to dwie rzeczy były dla mnie oczywiste. Call center musi być zbudowane w oparciu o oprogramowanie Asterisk typu open source PBX. Wymiana informacji pomiędzy call center a aplikacją mobilną to w zasadzie rozwiązanie klient-serwer ze wszystkimi odpowiednimi wzorcami do projektowania architektury przyszłego projektu i jego programowania.
Po wstępnej ocenie zadań, terminów i kosztów projektu oraz po uzgodnieniu wszystkich niezbędnych kwestii z właścicielem firmy taksówkarskiej, w styczniu 2009 roku rozpocząłem pracę.
Patrząc w przyszłość, powiem od razu. W rezultacie powstała skalowalna platforma działająca na ponad 60 serwerach w 12 miastach w Rosji i 2 w Kazachstanie. Całkowity zysk firmy wynosił ponad 100 milionów rubli miesięcznie.
Scena pierwsza. Prototyp
Ponieważ nie miałem wówczas praktycznego doświadczenia w telefonii IP, a gwiazdkę znałem jedynie powierzchownie w ramach „domowych” eksperymentów, zdecydowano się rozpocząć pracę nad rozwojem aplikacji mobilnej i części serwerowej. Jednocześnie uzupełnianie luk w wiedzy na temat innych zadań.
Jeśli z aplikacją mobilną wszystko było mniej więcej jasne. W tamtym czasie można było go napisać tylko w Javie dla prostych telefonów z przyciskami, ale napisanie serwera obsługującego klientów mobilnych było nieco bardziej skomplikowane:
- Jaki system operacyjny serwera będzie używany;
- Wychodząc z logiki, że język programowania wybiera się do zadania, a nie odwrotnie i biorąc pod uwagę punkt 1, który język programowania będzie optymalny do rozwiązywania problemów;
- Podczas projektowania należało uwzględnić przewidywane w przyszłości duże obciążenia serwisu;
- Która baza danych może zagwarantować odporność na awarie przy dużych obciążeniach i jak utrzymać szybki czas odpowiedzi bazy danych w miarę wzrostu liczby żądań do niej;
- Decydującym czynnikiem była szybkość rozwoju i możliwość szybkiego skalowania kodu
- Koszt sprzętu i jego przyszłej konserwacji (jednym z warunków klienta jest to, że serwery muszą znajdować się na kontrolowanym przez niego terytorium);
- Koszt programistów, którzy będą potrzebni w kolejnych etapach pracy nad platformą;
Jak również wiele innych zagadnień związanych z projektowaniem i rozwojem.
Przed rozpoczęciem pracy nad projektem zaproponowałem właścicielowi firmy następującą decyzję strategiczną: ponieważ projekt jest dość złożony, jego realizacja zajmie zauważalnie dużo czasu, dlatego najpierw tworzę wersję MVP, która nie zajmie dużo czasu i pieniędzy, ale co pozwoli jego firmie zdobyć przewagę konkurencyjną na rynku już „tu i teraz”, a także rozszerzy jej możliwości jako usługi taksówkarskiej. Z kolei takie rozwiązanie pośrednie da mi czas na dokładniejsze zaprojektowanie rozwiązania końcowego i czas na eksperymenty techniczne. Jednocześnie nie ma gwarancji, że wdrożone rozwiązanie programowe będzie poprawnie zaprojektowane i może zostać w przyszłości radykalnie przeprojektowane lub wymienione, ale z pewnością będzie zapewniało minimalną niezbędną funkcjonalność, aby „odbić się od konkurencji”. Założycielowi taksówki spodobał się pomysł, więc w końcu go zrealizowali.
Pierwsze dwa tygodnie spędziłem studiując procesy biznesowe w firmie i studiując pracę taksówki od środka. Przeprowadziłem analizę biznesową gdzie, co i jak można zautomatyzować i czy jest to w ogóle konieczne. Z jakimi trudnościami i problemami spotykają się pracownicy firmy? Jak je rozwiązano. Jak zorganizowany jest dzień pracy pracowników firmy. Jakich narzędzi używają?
Pod koniec trzeciego tygodnia, po rozpoczęciu pracy i przestudiowaniu interesujących mnie zagadnień w Internecie, biorąc pod uwagę życzenia właściciela firmy, a także moją ówczesną wiedzę i możliwości, zdecydowano się zastosować następujący stos :
- Serwer bazy danych: MsSQL (wersja bezpłatna z limitem pliku bazy danych do 2 GB);
- Rozwój serwera obsługującego klientów mobilnych w Delphi pod Windows, gdyż istniał już serwer Windows, na którym będzie zainstalowana baza danych, a także samo środowisko deweloperskie ułatwia szybki rozwój;
- Biorąc pod uwagę niską prędkość Internetu w telefonach komórkowych w 2009 roku, protokół wymiany pomiędzy klientem a serwerem musi być binarny. Zmniejszy to rozmiar przesyłanych pakietów danych, a w rezultacie zwiększy stabilność pracy klientów z serwerem;
Kolejne dwa tygodnie poświęcono na projektowanie protokołu i bazy danych. W efekcie powstało 12 pakietów zapewniających wymianę wszystkich niezbędnych danych pomiędzy klientem mobilnym a serwerem oraz około 20 tabel w bazie danych. Tę część pracy wykonałem z myślą o przyszłości, nawet jeśli będę musiał całkowicie zmienić stos technologiczny, struktura pakietów i bazy danych powinna pozostać niezmieniona.
Po pracach przygotowawczych można było przystąpić do praktycznej realizacji pomysłu. Aby nieco przyspieszyć proces i mieć czas na inne zadania, stworzyłem wersję roboczą aplikacji mobilnej, naszkicowałem UI, częściowo UX, a także zaangażowałem do projektu znajomego programistę Java. Skoncentrował się na rozwoju, projektowaniu i testowaniu po stronie serwera.
Pod koniec drugiego miesiąca pracy nad MVP gotowa była pierwsza wersja prototypu serwera i klienta.
I pod koniec trzeciego miesiąca, po testach syntetycznych i testach terenowych, poprawkach błędów, drobnych usprawnieniach protokołu i bazy danych, aplikacja była gotowa do produkcji. Co właśnie zostało zrobione.
Od tego momentu zaczyna się najciekawsza i najtrudniejsza część projektu.
W trakcie przejścia kierowców na nowe oprogramowanie zorganizowano dyżur całodobowy. Ponieważ nie każdy mógł przyjść w godzinach pracy w ciągu dnia. Dodatkowo od strony administracyjnej zdecydowaną decyzją założyciela firmy zostało to zorganizowane w ten sposób, że login/hasło wprowadzał kierownik taksówki i nie były one przekazywane kierowcy. Z mojej strony potrzebne było wsparcie techniczne dla użytkowników na wypadek awarii i nieprzewidzianych sytuacji.
Prawo Murphy'ego mówi nam: „Wszystko, co może pójść źle, pójdzie źle”. I tak właśnie poszło... Co innego, gdy wraz z kilkoma taksówkarzami testowaliśmy aplikację na kilkudziesięciu zamówieniach testowych. A to zupełnie inna sprawa, gdy ponad 500 kierowców na linii pracuje w czasie rzeczywistym na rzeczywistych zamówieniach od prawdziwych ludzi.
Architektura aplikacji mobilnej była prosta i było w niej zauważalnie mniej błędów niż na serwerze. Dlatego też główny nacisk położony został na stronę serwerową. Najbardziej krytycznym błędem w aplikacji był problem rozłączenia się z serwerem w przypadku utraty Internetu w telefonie i ponownego przywrócenia sesji. A Internet znikał dość często. Po pierwsze, w tamtych latach sam Internet w telefonie nie był wystarczająco stabilny. Po drugie, było wiele martwych punktów, w których Internet po prostu nie działał. Zidentyfikowaliśmy ten problem niemal natychmiast i w ciągu XNUMX godzin naprawiliśmy i zaktualizowaliśmy wszystkie wcześniej zainstalowane aplikacje.
Serwer miał głównie błędy w algorytmie dystrybucji zamówień i nieprawidłowe przetwarzanie niektórych żądań od klientów. Po zidentyfikowaniu usterek poprawiłem i zaktualizowałem serwer.
Tak naprawdę na tym etapie nie było zbyt wielu problemów technicznych. Cała trudność polegała na tym, że przez prawie miesiąc pełniłem dyżur w biurze, tylko okazjonalnie wracając do domu. Prawdopodobnie 4-5 razy. I spałem z przerwami, ponieważ w tym czasie pracowałem sam nad projektem i nikt oprócz mnie nie mógł niczego naprawić.
Miesiąc, to nie znaczy, że przez miesiąc wszystko ciągle szwankowało i bez przerwy coś kodowałem. Właśnie tak zdecydowaliśmy. Przecież firma już działała i przynosiła zyski. Lepiej zagrać bezpiecznie i odpocząć później, niż teraz stracić klientów i zyski. Wszyscy doskonale to rozumieliśmy, dlatego cały zespół wspólnie poświęcił maksimum uwagi i czasu na wprowadzenie nowego oprogramowania do systemu taksówkowego. A biorąc pod uwagę aktualny ruch zamówień, na pewno w ciągu miesiąca wyeliminujemy wszystkie niedociągnięcia. Cóż, ukryte błędy, które mogą pozostać, z pewnością nie będą miały krytycznych konsekwencji dla procesu biznesowego i, jeśli to konieczne, można je rutynowo poprawiać.
W tym miejscu należy zwrócić uwagę na nieocenioną pomoc dyrektorów i brygadzistów służb taksówkowych, którzy przy maksymalnym zrozumieniu złożoności sytuacji przeniesienia kierowców na nowe oprogramowanie pracowali z kierowcami przez całą dobę. Tak naprawdę po zakończeniu instalacji nowych programów na telefonach nie straciliśmy ani jednego sterownika. Nie zwiększyły też znacząco odsetka nieusunięć klientów, który wkrótce powrócił do normalnego poziomu.
Tym samym zakończył się pierwszy etap prac nad projektem. I należy zauważyć, że na wynik nie trzeba było długo czekać. Automatyzując dystrybucję zamówień do kierowców bez interwencji człowieka, średni czas oczekiwania klienta na taksówkę został skrócony o rząd wielkości, co w naturalny sposób zwiększyło lojalność klientów wobec usługi. Przełożyło się to na wzrost liczby zamówień. W związku z tym wzrosła liczba taksówkarzy. W rezultacie wzrosła również liczba pomyślnie zrealizowanych zamówień. W rezultacie zyski firmy wzrosły. Oczywiście tutaj trochę wyprzedzam siebie, ponieważ cały ten proces nie nastąpił od razu. Powiedzieć, że kierownictwo było zadowolone, to nic nie powiedzieć. Otrzymałem nieograniczony dostęp do dalszego finansowania projektu.
Aby kontynuować ...
Źródło: www.habr.com