Fin décembre 2008, j'ai été invité dans l'un des services de taxi de Perm dans le but d'automatiser les processus commerciaux existants. En général, on m'a confié trois tâches fondamentales :
- Développer un progiciel pour un centre d'appels avec une application mobile pour les chauffeurs de taxi et automatiser les processus métiers internes.
- Tout devait être fait dans les plus brefs délais.
- Ayez votre propre logiciel, plutôt que d'acheter auprès de développeurs tiers, qui, à l'avenir, à mesure que l'entreprise se développe, pourra être adapté de manière indépendante aux conditions du marché en constante évolution.
A cette époque, je ne comprenais pas comment fonctionne ce marché et ses nuances, mais néanmoins, deux choses m’apparaissaient comme une évidence. Le centre d'appels doit être construit sur la base du logiciel open source Asterisk PBX. L'échange d'informations entre le centre d'appels et l'application mobile est essentiellement une solution client-serveur avec tous les schémas correspondants pour concevoir l'architecture du futur projet et sa programmation.
Après une évaluation préliminaire des tâches, des délais et des coûts du projet, et après avoir convenu de toutes les questions nécessaires avec le propriétaire du service de taxi, j'ai commencé à travailler en janvier 2009.
Pour l'avenir, je dirai tout de suite. Le résultat a été une plate-forme évolutive fonctionnant sur plus de 60 serveurs répartis dans 12 villes de Russie et 2 au Kazakhstan. Le bénéfice total de l'entreprise s'élevait à plus de 100 millions de roubles par mois.
Première étape. Prototype
Comme à cette époque je n'avais aucune expérience pratique en téléphonie IP et que je ne connaissais que superficiellement Asterisk dans le cadre d'expériences « à domicile », il a été décidé de commencer à travailler avec le développement d'une application mobile et d'une partie serveur. En même temps, combler les lacunes dans les connaissances sur d’autres tâches.
Si avec l'application mobile tout était plus ou moins clair. À cette époque, il ne pouvait être écrit en Java que pour de simples téléphones à bouton-poussoir, mais écrire un serveur servant des clients mobiles était un peu plus compliqué :
- Quel système d'exploitation du serveur sera utilisé ;
- Sur la base de la logique selon laquelle un langage de programmation est choisi pour une tâche, et non l'inverse, et en tenant compte du point 1, quel langage de programmation sera optimal pour résoudre des problèmes ;
- Lors de la conception, il a été nécessaire de prendre en compte les futures charges élevées attendues sur le service ;
- Quelle base de données peut garantir la tolérance aux pannes sous des charges élevées et comment maintenir un temps de réponse rapide à mesure que le nombre de requêtes qui lui sont adressées augmente ;
- Le facteur déterminant était la rapidité de développement et la capacité de faire évoluer rapidement le code.
- Le coût du matériel et sa maintenance dans le futur (une des conditions du client est que les serveurs doivent être situés sur le territoire sous son contrôle) ;
- Coût des développeurs qui seront nécessaires dans les prochaines étapes de travail sur la plateforme ;
Ainsi que bien d’autres problématiques liées à la conception et au développement.
Avant de commencer à travailler sur le projet, j'ai proposé la décision stratégique suivante au propriétaire de l'entreprise : comme le projet est assez complexe, sa mise en œuvre prendra un temps considérable, je crée donc d'abord une version MVP, qui ne prendra pas beaucoup de temps et de l'argent, mais qui permettra à son entreprise d'acquérir un avantage concurrentiel sur le marché dès « ici et maintenant », et qui élargira également ses capacités en tant que service de taxi. À son tour, une telle solution intermédiaire me donnera le temps de concevoir de manière plus réfléchie la solution finale et du temps pour les expériences techniques. Dans le même temps, la solution logicielle mise en œuvre ne sera pas garantie d'être correctement conçue et pourra être radicalement repensée ou remplacée à l'avenir, mais elle exécutera certainement le minimum de fonctionnalités nécessaires pour « se démarquer des concurrents ». Le fondateur du taxi a aimé l’idée, alors ils l’ont finalement fait.
J'ai passé les deux premières semaines à étudier les processus commerciaux de l'entreprise et à étudier le travail d'un taxi de l'intérieur. Réalisation d'une analyse commerciale pour savoir où, quoi et comment peut être automatisé et si cela est nécessaire. À quelles difficultés et problèmes les salariés de l’entreprise sont-ils confrontés ? Comment ils sont résolus. Comment est organisée la journée de travail des salariés de l'entreprise. Quels outils utilisent-ils ?
À la fin de la troisième semaine, après avoir commencé à travailler et étudié les questions d'intérêt sur Internet, en tenant compte des souhaits du propriétaire de l'entreprise, ainsi que de mes propres connaissances et capacités à l'époque, il a été décidé d'appliquer la pile suivante :
- Serveur de base de données : MsSQL (version gratuite avec limite de fichiers de base de données jusqu'à 2 Go) ;
- Le développement d'un serveur au service des clients mobiles dans Delphi sous Windows, puisqu'il existait déjà un serveur Windows sur lequel la base de données serait installée, ainsi que l'environnement de développement lui-même facilite un développement rapide ;
- Compte tenu des faibles débits Internet sur les téléphones mobiles en 2009, le protocole d'échange entre le client et le serveur doit être binaire. Cela réduira la taille des paquets de données transmis et, par conséquent, augmentera la stabilité du travail des clients avec le serveur ;
Deux semaines supplémentaires ont été consacrées à la conception du protocole et de la base de données. Le résultat a été 12 packages qui assurent l'échange de toutes les données nécessaires entre le client mobile et le serveur et environ 20 tables dans la base de données. J'ai fait cette partie du travail en tenant compte de l'avenir, même si je dois changer complètement la pile technologique, la structure des packages et de la base de données doit rester inchangée.
Après les travaux préparatoires, il a été possible de commencer la mise en œuvre pratique de l'idée. Pour accélérer un peu le processus et libérer du temps pour d'autres tâches, j'ai créé une version préliminaire de l'application mobile, esquissé l'interface utilisateur, en partie l'UX, et impliqué un programmeur Java familier dans le projet. Et il s'est concentré sur le développement, la conception et les tests côté serveur.
À la fin du deuxième mois de travail sur le MVP, la première version du prototype serveur et client était prête.
Et à la fin du troisième mois, après des tests synthétiques et des tests sur le terrain, des corrections de bugs, des améliorations mineures du protocole et de la base de données, l'application était prête pour la production. C'est ce qui a été fait.
A partir de ce moment commence la partie la plus intéressante et la plus difficile du projet.
Lors de la transition des chauffeurs vers le nouveau logiciel, un service XNUMXh/XNUMX a été organisé. Puisque tout le monde ne pouvait pas venir pendant les heures de travail pendant la journée. De plus, administrativement, par décision volontaire du fondateur de l’entreprise, celle-ci a été organisée de telle manière que les identifiants/mot de passe étaient saisis par le responsable du service de taxi et n’étaient pas communiqués au chauffeur. De mon côté, un support technique aux utilisateurs était nécessaire en cas de pannes et de situations imprévues.
La loi de Murphy nous dit : « Tout ce qui peut mal tourner tournera mal. » Et c’est exactement comme ça que les choses ont mal tourné... C’est une chose lorsque moi et plusieurs chauffeurs de taxi avons testé l’application sur plusieurs dizaines de commandes tests. Et c’est une tout autre affaire lorsque plus de 500 chauffeurs sur la ligne travaillent en temps réel sur de vraies commandes émanant de vraies personnes.
L'architecture de l'application mobile était simple et contenait nettement moins de bugs que sur le serveur. Par conséquent, l’essentiel du travail s’est concentré sur le côté serveur. Le problème le plus critique de l'application était le problème de déconnexion du serveur lorsque l'Internet sur le téléphone était perdu et que la session était à nouveau restaurée. Et Internet a souvent disparu. Premièrement, à cette époque, Internet sur le téléphone lui-même n’était pas suffisamment stable. Deuxièmement, il existe de nombreux angles morts dans lesquels Internet ne fonctionne tout simplement pas. Nous avons identifié ce problème presque immédiatement et, dans les XNUMX heures, avons corrigé et mis à jour toutes les applications précédemment installées.
Le serveur présentait principalement des erreurs dans l'algorithme de distribution des commandes et un traitement incorrect de certaines demandes des clients. Après avoir identifié des problèmes, j'ai corrigé et mis à jour le serveur.
En fait, il n’y a pas eu beaucoup de problèmes techniques à ce stade. Toute la difficulté était que j'étais de service au bureau pendant près d'un mois, ne rentrant chez moi que de temps en temps. Probablement 4 à 5 fois. Et j'ai dormi par à-coups, car à cette époque je travaillais seul sur le projet et personne d'autre que moi ne pouvait rien réparer.
Un mois, cela ne veut pas dire que tout était constamment en panne pendant un mois et que je codais quelque chose sans m'arrêter. Nous venons de décider cela. Après tout, l’entreprise fonctionnait déjà et réalisait des bénéfices. Il vaut mieux jouer la sécurité et se reposer plus tard que de perdre des clients et des bénéfices maintenant. Nous l'avons tous très bien compris, c'est pourquoi toute l'équipe a consacré collectivement un maximum d'attention et de temps à l'introduction d'un nouveau logiciel dans le système de taxi. Et compte tenu du trafic actuel des commandes, nous éliminerons définitivement toutes les lacunes d'ici un mois. Eh bien, les bugs cachés qui pourraient subsister n’auront certainement pas de conséquences critiques sur le processus métier et, si nécessaire, ils pourront être corrigés régulièrement.
Il faut ici noter l'aide inestimable des directeurs et contremaîtres des services de taxi, qui, avec une compréhension maximale de la complexité de la situation du transfert des chauffeurs vers un nouveau logiciel, ont travaillé XNUMX heures sur XNUMX avec les chauffeurs. En fait, après avoir terminé l'installation de nouveaux programmes sur les téléphones, nous n'avons perdu aucun pilote. Et ils n'ont pas augmenté de manière critique le pourcentage de non-retrait des clients, qui est rapidement revenu à des niveaux normaux.
Ceci a complété la première étape des travaux sur le projet. Et force est de constater que le résultat ne s’est pas fait attendre. En automatisant la distribution des commandes aux chauffeurs sans intervention humaine, le temps d'attente moyen d'un taxi par un client a été réduit d'un ordre de grandeur, ce qui a naturellement accru la fidélité des clients au service. Cela a entraîné une augmentation du nombre de commandes. Suite à cela, le nombre de chauffeurs de taxi a augmenté. En conséquence, le nombre de commandes exécutées avec succès a également augmenté. Et en conséquence, les bénéfices de l’entreprise ont augmenté. Bien sûr, je prends ici un peu d'avance, car tout ce processus ne s'est pas déroulé instantanément. Dire que la direction était contente, c'est ne rien dire. J'ai eu un accès illimité à un financement supplémentaire du projet.
À suivre ..
Source: habr.com