Comment j'ai gagné mon premier Hackathon – 2 jours intenses de recherche, de design et de codage

Article original : How I Won my First Ever Hackathon – 2 Wild Days of Research, Design, and Coding

Par Moshe Siegel

Je n'avais aucune expérience en codage ou en ingénierie. J'ai étudié la biologie à l'université, sans savoir quoi faire avec mon diplôme.

Mes premiers emplois consistaient à faire des appels à froid dans la vente, mais je gagnais presque rien et j'étais misérable dans mon travail.

Après avoir échoué dans quelques emplois de vente, j'ai abandonné et j'ai trouvé un travail à préparer des légumes dans un restaurant — pas exactement la vie végétale à laquelle je m'attendais après l'université.

J'avais besoin de nouvelles perspectives, et j'étais prêt à trouver quelque chose de mieux. Il ne m'a fallu qu'une forte éthique de travail, une volonté d'apprendre et quelques ressources clés pour m'orienter vers une toute nouvelle carrière.

Cela m'a également impliqué dans une compétition de codage qui m'a emmené bien au-delà de ma zone de confort.

Tout en travaillant à mon emploi de restaurant, j'ai commencé à entendre des histoires sur des personnes qui s'étaient appris à coder et avaient réussi à en faire une carrière. Prêt à essayer quelque chose de nouveau, j'ai commencé à suivre des cours en ligne avec freeCodeCamp pendant mon temps libre au travail.

Les heures ici et là se sont transformées en un engagement à temps plein. J'ai quitté mon emploi et j'ai suivi le programme de freeCodeCamp, étudiant agressivement le JavaScript full-stack comme mon nouvel emploi à temps plein.

J'ai passé un an et demi à me concentrer sur l'apprentissage du codage, et cela a porté ses fruits. J'ai été accepté dans un contrat à long terme en tant que codeur débutant dans une entreprise de mode de New York, qui générait plus de 2 milliards de dollars de ventes par an.

L'apprentissage était ma priorité absolue. Même dans cette nouvelle position, j'ai continué à pratiquer pendant mes heures libres, cette fois en me concentrant sur les meilleures pratiques pour mes responsabilités spécifiques, qui impliquaient l'écriture de tests automatisés en utilisant la version NodeJS de Selenium.

J'ai passé 10 à 15 heures par semaine à faire des tutoriels Selenium, ce qui m'a aidé à accomplir mon travail plus rapidement et m'a donné la latitude d'apprendre de mes collègues pendant les heures de travail. J'ai maximisé les temps entre les tâches, parlant à mes collègues dans l'ascenseur ou en marchant vers mon bureau. J'ai appris ce que les autres faisaient et quelles étaient leurs responsabilités pour notre entreprise.

Peu importait s'ils étaient dans le même rôle que moi. J'ai parlé à mes superviseurs en ingénierie et à des personnes dans nos unités commerciales pour mieux comprendre la structure de notre entreprise, découvrir comment les autres avaient progressé dans leurs propres positions, et voir si je pouvais trouver un gros problème que je pourrais résoudre.

Vers ma troisième semaine de travail, en parlant à mon directeur senior de l'ingénierie, j'ai remarqué plusieurs récompenses près de son bureau. Il m'a dit qu'elles provenaient de ses victoires passées au Hackathon annuel de notre entreprise.

"Wow", ai-je dit, "Vous avez gagné beaucoup de récompenses."

Il a répondu, "Merci. Vous devriez participer au prochain Hackathon. Ce sera dans quelques mois."

J'étais encore relativement nouveau en codage et je n'avais jamais participé à un Hackathon, alors après une journée de réflexion, je suis retourné à son bureau.

"Hey, j'ai vu quelques autres personnes avec des récompenses de Hackathon", ai-je dit, "mais personne n'a presque autant de récompenses que vous. De plus, la plupart de vos récompenses disent première place. Comment faites-vous pour gagner si souvent?"

Il m'a dit, "Je me concentre sur des projets qui ont un impact. Par exemple, pour l'un des Hackathons, j'ai construit un prototype qui permettrait à nos clients de commander sur notre site web et de venir chercher en magasin. Les juges ont réalisé que cela serait un grand succès auprès de nos clients et augmenterait considérablement les revenus."

Quand je lui ai demandé comment trouver un projet qui aurait un impact, il a expliqué que, pendant son temps dans notre entreprise, il était allé de l'avant et avait appris tous les différents sous-systèmes qui alimentaient notre activité eCommerce.

"Connaître tout le système rend plus facile de voir où se trouvent les opportunités", a-t-il dit. "En fait, ma compréhension large de toute notre plateforme est ce qui me différencie et m'a permis d'atteindre ma position actuelle."

Trouver un Projet

J'ai réalisé que le Hackathon serait le test ultime de mes capacités : pourrais-je prendre les stratégies de travail acharné, d'apprentissage auprès de mes collègues, et mon étude intense du codage pour passer au niveau supérieur?

Après des années à avoir l'impression de gaspiller mon potentiel, j'avais enfin trouvé un moyen de prouver ma valeur. Cela ne serait pas seulement une question de montrer, car je devrais trouver un projet qui serait réellement utile à l'entreprise.

Je n'avais pas beaucoup de temps de mon côté, et mes compétences techniques étaient relativement basiques par rapport aux ingénieurs seniors hautement qualifiés contre lesquels je serais en compétition.

Même si je me sentais hors de ma ligue, j'avais la sauce secrète pour une solution dans ma poche : les leçons que j'avais apprises du livre de stratégies de vente de Neil Rackham, SPIN Selling, qui m'a donné le modèle en quatre étapes pour trouver des problèmes dans les grandes entreprises.

Étape 1 : Apprendre comment quelque chose fonctionne.

Puisqu'on m'avait conseillé d'apprendre le fonctionnement interne de notre activité eCommerce, j'ai commencé à parler aux employés de notre département de planification, situé commodément entre mon bureau et la salle à manger (et entre mon bureau et les toilettes). Ils étaient responsables de décider combien de marchandises acheter et à quels prix elles seraient vendues.

Je quittais mon bureau et prenais un moment pour poser des questions comme comment ils choisissaient combien de stock acheter à l'avance, comment ils fixaient leurs prix, et si le commerce de détail et l'eCommerce avaient des règles différentes pour la tarification. Grâce à mes questions, j'ai appris comment les planificateurs introduisaient de nouvelles lignes de vêtements et calculaient à quel prix les vendre.

Étape 2 : Poser des questions pour trouver un problème.

Une fois que j'avais compris comment fonctionnait la planification, j'ai commencé à chercher des problèmes qui pourraient survenir. Une fois qu'ils avaient fixé un montant pour le stock, l'entreprise achetait-elle parfois la mauvaise quantité ? Les prix étaient-ils parfois fixés incorrectement ?

J'essayais de trouver le genre d'erreurs ou de frustrations que je pourrais résoudre.

Étape 3 : Poser des questions pour explorer les implications du problème.

Après plusieurs jours de questions, j'ai appris qu'il y avait des problèmes de prix, où les prix étaient fixés et apparaissaient incorrectement sur notre site web. Comment ce problème était-il survenu et quelles étaient les implications ?

J'ai demandé à quelle fréquence les erreurs de prix se produisaient et quel genre de problèmes supplémentaires elles pourraient causer.

Étape 4 : Poser des questions pour explorer la valeur de la résolution du problème.

Si un script informatique automatisé trouvait tous les articles eCommerce mal tarifiés, à quel point cela serait-il utile ?

J'ai posé aux planificateurs des questions qui m'aideraient à déterminer quel type de valeur je pourrais leur offrir. Si j'allais corriger quelque chose lors du Hackathon de notre entreprise, je voulais m'assurer que cela avait un impact notable.

Après mes conversations, j'ai découvert que les erreurs de prix seraient un projet valable sur lequel travailler. Chacun de nos trois ou quatre planificateurs assistants passait 30 minutes par semaine à vérifier manuellement les erreurs de prix. Un système automatisé économiserait ce temps — une estimation de 100 heures par an qui ne seraient plus gaspillées.

Même si on m'avait déjà parlé du Hackathon, il n'y avait pas encore de date officielle. J'avais un problème résoluble dans ma poche, et, bien que je ne sois pas sûr d'avoir les compétences en codage, j'étais assez confiant en mes chances. En attendant l'annonce, je me concentrerais sur mon travail. Mais dès qu'elle arriverait, je serais prêt à commencer.

Confirmation avec les Planificateurs

Deux semaines plus tard, j'avais un email dans ma boîte de réception. L'événement Hackathon aurait lieu dans un mois, durant deux jours consécutifs, incluant une présentation le jour 2, un vendredi.

Les idées de projets seraient jugées selon quatre critères : l'originalité de l'idée, l'impact sur l'entreprise, la complétude du prototype et la force du pitch. Il y avait tant d'inconnues et il était impossible de prédire si un mois serait suffisant pour se préparer.

Je suis allé voir les planificateurs et j'ai confirmé que le problème était toujours présent — la vérification manuelle des prix de vente en ligne était toujours effectuée.

J'ai été heureux d'apprendre que notre entreprise avait un marchand eCommerce dédié, responsable de la déclaration de tous les prix incorrects sur le site web et de leur résolution. Elle serait en mesure de me donner beaucoup plus d'informations et pourrait confirmer si c'était un problème qui valait la peine d'être résolu.

J'ai été mécontent d'apprendre qu'elle était en vacances, et que je devrais attendre une semaine pour lui parler. Le temps pressait, et j'étais bloqué jusqu'à alors.

Avec trois semaines avant le Hackathon et notre marchand eCommerce de retour au bureau, j'ai pu commencer à explorer le problème plus en détail. Elle a confirmé les problèmes dont j'avais entendu parler et a dit que construire quelque chose qui pourrait scanner automatiquement le site web et trouver les prix incorrects serait d'une grande aide.

Lors de conversations supplémentaires avec les planificateurs, j'ai appris comment les prix étaient téléchargés sur le site web : les planificateurs copiaient et collaient une liste de prix d'une feuille de calcul Excel vers SAP, un logiciel qui fait beaucoup de choses comme la gestion des stocks pour les détaillants. SAP poussait ensuite les prix vers notre site web eCommerce.

J'ai réalisé que les prix Excel pourraient être comparés aux prix du site web pour trouver tout problème. Je construirais un site web simple qui permettrait aux planificateurs de télécharger des listes de prix Excel.

Un script lirait ensuite les listes de prix Excel et les comparerait en temps réel à nos prix sur le site web. Toutes les divergences seraient ensuite regroupées dans une liste et envoyées à nos planificateurs pour examen.

Excité d'avoir trouvé un moyen de résoudre le problème, j'ai commencé à expliquer l'idée du projet à d'autres développeurs de notre organisation, demandant si quelqu'un voulait rejoindre mon équipe. Cependant, j'ai fait une exigence stricte que tout coéquipier potentiel devrait d'abord parler à nos planificateurs en personne et entendre le problème de leur perspective.

Dans le cadre du système SPIN, j'avais besoin de coéquipiers prêts à comprendre le processus et le problème avant que nous puissions concevoir pleinement la solution. Malheureusement, je n'ai pas réussi à recruter d'autres ingénieurs logiciels pour mon projet, mais d'autres ingénieurs m'ont donné des conseils précieux sur la façon de coder mon projet et quelles technologies apprendre.

J'étais seul, mais j'étais excité, me sentant confiant dans ma solution.

Besoin de Pivoter

Deux semaines avant le Hackathon, j'ai revu l'une des planificatrices adjointes et lui ai expliqué mon idée pour un script automatisé qui comparerait les prix Excel et les prix du site web et signalerait les divergences. Elle m'a rapidement informé que mon idée serait inutile, puisque les prix Excel et les prix du site web seraient toujours identiques.

La planificatrice adjointe a continué à expliquer que les listes de prix Excel originales étaient générées par un outil qui prenait en compte les coûts de fabrication des produits, les coûts de livraison et d'autres facteurs pertinents, puis générait des listes de prix Excel, que nos planificateurs téléchargeaient ensuite dans le logiciel SAP alimentant notre site web.

Si les planificateurs entraient par erreur des coûts de fabrication ou de livraison incorrects dans l'outil de tarification, alors le prix serait également erroné sur les listes Excel.

"Donc, vous dites qu'il n'y a pas de liste principale qui est garantie de toujours contenir tous les prix corrects?" ai-je demandé.

"Exactement", a dit la planificatrice adjointe.

C'était l'inverse de ce que je voulais entendre. Des semaines de planification, de réflexion, de discussion et d'attente — perdues.

J'étais à deux semaines d'un Hackathon où mon manque d'expérience me retenait déjà, et je n'avais rien. Il n'y avait pas assez de jours pour tout recommencer.

Je devais repenser mon processus.

Comme le temps était serré, je ne pouvais pas faire toutes les recherches et le travail que j'avais essayés la première fois. Au lieu de cela, je laisserais les planificateurs établir les exigences du projet pour moi.

Je suis retourné au département de planification, cette fois avec une question différente : "Imaginez que vous avez un script robotique qui pourrait automatiquement récupérer des nombres de n'importe où, comme une feuille de calcul Excel, une base de données ou un site web, et automatiquement soustraire, ajouter ou comparer les données. Quel problème pourrait être résolu avec l'aide d'un tel script?"

Après que la planificatrice adjointe à qui je parlais y ait réfléchi pendant quelques minutes, elle m'a dit que ce serait utile pour vérifier les prix de vente. Elle a expliqué que notre site web organisait des ventes massives hebdomadaires chaque mercredi. Les ventes seraient listées sur notre page d'accueil et utiliseraient des textes tels que "25% de réduction sur toutes les vestes pour hommes" ou "15% de réduction sur toutes les robes pour femmes".

Chaque mercredi matin, nos 3-4 planificateurs adjoints passaient 30 minutes à cliquer manuellement sur notre site web et à confirmer que les réductions correctes étaient appliquées. Si les planificateurs trouvaient des prix de vente incorrects, ils les envoyaient à notre marchand eCommerce.

Seul le service informatique était en mesure de modifier les prix de vente en direct. Pour simplifier les choses pour le service informatique, notre marchand eCommerce pouvait attendre et envoyer une liste au service informatique par lots.

Cela signifiait que même une fois qu'un article mal tarifié était trouvé — sauf en cas d'urgence — le prix ne serait pas corrigé immédiatement.

J'avais un problème, et la solution n'était pas loin de ce que j'avais initialement prévu : un script automatisé qui pourrait signaler tous les articles mal réduits économiserait du temps en réduisant la quantité de travail pour nos planificateurs, pour notre marchand eCommerce et pour le service informatique, et cela améliorerait l'expérience client en réduisant la quantité de prix de vente incorrects et en le faisant rapidement.

J'aurais seulement besoin d'une liste principale de toutes les ventes en cours qui pourrait être comparée aux prix du site web, mais les planificateurs m'ont dit qu'une telle liste "100% exacte" n'existait pas, du moins pas sur papier.

"Mais une liste de prix entièrement correcte existe dans nos têtes", ont-ils dit, "parce que nous connaissons nos produits de fond en comble. C'est pourquoi nous pouvons parcourir notre site web et repérer les prix incorrects."

Après y avoir réfléchi quelques instants, j'ai demandé : "Et si vous n'aviez pas à parcourir notre site web ? Et si vous pouviez obtenir tous nos prix de site web en direct dans une liste bien organisée juste en cliquant sur un bouton ?"

"Cela accélérerait considérablement notre vérification des prix", ont-ils dit.

Nous avons élaboré un plan : je construirais un site web simple qui permettrait aux planificateurs de télécharger des dizaines de noms d'articles et de recevoir immédiatement une liste facile à lire des prix en direct de ces articles sur le site web et des réductions de vente.

L'idée était concrète et réalisable. Elle avait un impact — conservation de la main-d'œuvre, QA plus rapide et amélioration de l'expérience client — et j'étais confiant dans ma propre capacité à la construire (même si je ne savais pas encore exactement comment).

Je suis retourné à mon bureau et j'ai tapé un document expliquant les exigences commerciales de ce que je prévoyais de construire, comment cela serait utile, et la date du Hackathon où je le construirais.

Je suis retourné voir les planificateurs et j'ai fait lire mon document à l'un des responsables de la planification et au marchand eCommerce. Il n'y avait plus de temps pour reculer.

Ils m'ont donné leur confirmation. L'idée était fixée, et avec une semaine restante, il était temps de déterminer comment j'allais faire de cela une réalité fonctionnelle et utilisable.

Je suis allé voir les ingénieurs de mon entreprise plus avancés que moi (et il y en avait beaucoup) et j'ai demandé : "Comment coderiez-vous un script qui retournerait automatiquement les prix du site web pour les articles que nous vendons ?"

Après avoir parlé à plusieurs ingénieurs, j'ai appris que les pages produits de notre site web obtenaient leurs prix en interrogeant notre base de données eCommerce interne, qui à son tour obtenait ses informations de prix de SAP. Il s'agissait d'une base de données Redis qui avait sa propre documentation bien écrite montrant exactement comment demander toute information de prix.

J'ai trouvé l'ingénieur qui avait construit la base de données et j'ai appris que je pouvais récupérer les prix du site web et les prix de vente d'une liste complète d'articles en utilisant un seul appel de base de données.

Même si mon plan se concrétisait, j'étais toujours très conscient de la quantité de travail que j'avais devant moi. J'ai essayé de recruter d'autres ingénieurs, mais je n'ai pas trouvé beaucoup d'intérêt, surtout quand je leur ai parlé de mon attente qu'ils parlent aux planificateurs.

Sans coéquipiers ingénieurs, j'ai passé chaque moment possible après le travail à étudier le matériel par moi-même, expérimentant avec des appels de base de données et étudiant comment écrire du code JavaScript pour lire des feuilles de calcul Excel.

Étendre à notre Marque Principale

La veille du Hackathon, par curiosité, j'ai demandé à nos planificateurs comment ils savaient quelles options de stock vendre. Ils ont répondu que le département merchandising de notre entreprise était responsable de ces décisions, alors je suis allé parler à nos merchandisers.

Lors de notre conversation, ils ont mentionné en passant quelque chose à propos de leurs homologues dans notre marque principale.

"Notre marque principale ?" ai-je demandé. "N'êtes-vous pas notre marque principale ?"

"Non", ont-ils dit. "Le merchandising et la planification pour cet étage sont dédiés à notre marque plus petite, qui représente 15% de notre chiffre d'affaires total. À l'étage se trouve notre marque phare de vêtements."

Cela ne pouvait pas arriver. Je savais que nous avions plusieurs marques dans notre entreprise, mais la veille du Hackathon, je découvrais que mon projet était construit pour la plus petite marque de notre organisation.

Avec un arrière-plan plus faible en codage, aucun autre ingénieur dans mon équipe, et le besoin de faire quelque chose de grand pour impressionner les juges, je n'avais pas l'air très bien.

Je suis monté à l'étage et j'ai commencé à demander où je pouvais trouver le département de planification pour notre marque principale. Je devais leur parler si mon projet devait avoir un impact suffisamment grand.

Il semblait y avoir au moins 20 à 40 planificateurs dans notre marque principale. À qui devrais-je parler ?

J'avais besoin de trouver un planificateur qui comprendrait ce que j'avais en tête, mais aussi qui aurait la base de connaissances et la pensée créative pour trouver les domaines que je manquais.

Et si la marque plus grande utilisait un système différent ? J'avais besoin de quelqu'un de fiable, et je n'avais pas le temps de m'étendre sur quelques semaines.

Avec le Hackathon à un jour, j'ai pris un raccourci.

La planification avait un environnement de bureau ouvert, ce qui signifiait que les gens étaient à des cubicles sans murs. J'ai commencé à parler de mon idée de Hackathon à l'un des planificateurs de notre marque principale.

En parlant, j'ai élevé la voix et j'ai commencé à marcher de haut en bas de l'allée, regardant autour de moi les autres planificateurs. Cela m'a permis d'attirer l'attention potentielle de jusqu'à huit planificateurs à la fois.

L'un des planificateurs a montré un grand intérêt et a posé beaucoup de questions. Il était spécifiquement intéressé par notre base de données Redis et si d'autres informations que les prix pouvaient être trouvées.

Je lui ai montré notre documentation de base de données et nous l'avons rapidement parcourue.

Il a mentionné qu'il y avait d'autres informations que les prix qui pourraient être utiles, comme si les articles étaient listés sur notre site web, et à quelles catégories ils appartenaient. Il m'a ensuite présenté les merchandisers eCommerce de notre marque principale, qui ont convenu que ce que je construisais avait un potentiel au-delà des simples prix.

Il n'y avait pas assez de temps pour que je fasse des extensions drastiques à mes exigences de codage, mais nous avons convenu que je pourrais construire mon projet de manière suffisamment flexible pour qu'il soit utilisé par les planificateurs de notre marque plus petite ou de notre marque principale.

Entendre parler de la valeur et de la viabilité de mon projet de la part de collègues qui étaient vraiment enthousiastes à ce sujet était exactement la poussée dont j'avais besoin.

J'avais la confiance, les ressources, la recherche, et, espérons-le, la capacité. Même si je ne l'avais pas, il n'y aurait pas moyen de l'éviter — le Hackathon commençait le lendemain matin, et il n'allait pas attendre quoi que ce soit.

Trouver un Coéquipier

Le Hackathon était une affaire de deux jours, sur un jeudi et un vendredi.

Quand j'ai regardé le calendrier pour la date, j'ai réalisé que j'avais un engagement familial le vendredi après-midi que je ne pourrais pas éviter. La présentation et le jugement auraient tous deux lieu le vendredi, ce qui signifiait que je devais absolument trouver un coéquipier qui pourrait présenter, ou le projet serait mort avant même que j'aie écrit une ligne de code.

Je me suis approché des planificateurs de la plus petite marque de notre entreprise avec lesquels j'étais en conversation depuis plusieurs semaines déjà. Je leur ai demandé si l'un d'eux serait en mesure de présenter notre projet aux juges. Aucun ne semblait enthousiaste. Certains m'ont dit qu'ils avaient des réunions le vendredi tandis que d'autres ont dit qu'ils étaient nerveux à l'idée de parler en public.

Ayant besoin d'un coéquipier, je suis allé directement voir Oliver, le planificateur de notre marque principale qui avait un intérêt si actif pour mon projet. C'était un gars populaire avec un visage gentil. Ses cheveux grisonnaient, bien qu'il soit dans la vingtaine, et il avait réussi à atteindre le rôle de planificateur senior en seulement quatre ans après l'université, alors que la plupart mettaient cinq à huit ans pour atteindre ce point. Il avait beaucoup de récompenses sur son bureau, et beaucoup de snacks aussi.

Oliver a immédiatement accepté de présenter le projet et a dit qu'il était excité de le faire.

Nous sommes descendus dans l'espace de réunion dédié au Hackathon et nous nous sommes inscrits en tant qu'équipe. Nous avions besoin d'un nom pour notre projet, alors nous l'avons appelé PriceSeeker.

Il y avait neuf autres équipes en compétition, dont la plupart étaient composées d'ingénieurs seniors. Certains chefs de projet et designers UX faisaient également partie de quelques équipes. À l'exception de mon coéquipier planificateur, tous les autres concurrents appartenaient à notre département eCommerce.

Simplifier le Design

J'avais mon plan en tête en entrant dans le Hackathon : je construirais un site web simple qui permettrait aux utilisateurs de télécharger des listes Excel d'articles.

Mon site web analyserait la feuille de calcul Excel, récupérerait la liste des articles et demanderait leurs prix à notre base de données Redis. Il retournerait ensuite aux planificateurs une nouvelle feuille de calcul Excel contenant les articles et leurs prix.

Avec cela, au lieu de cliquer manuellement sur notre site web pour vérifier les prix des articles, ils pourraient immédiatement voir tous les prix pertinents du site web en un clic de bouton. Cela rendrait la vérification des prix beaucoup plus facile et plus pratique.

Nous avions deux jours pour travailler sur notre projet et ensuite le présenter aux juges, qui étaient des leaders de haut rang au sein de notre département eCommerce. Mon directeur senior de l'ingénierie — qui m'avait présenté le Hackathon en premier lieu et m'avait appris à faire un impact — était l'un des juges. Il était également disponible tout au long du Hackathon pour répondre à toute question de codage.

Excité de commencer, je me suis assis à mon ordinateur.

Je me suis rapidement levé de mon ordinateur, car j'avais très vite rencontré un obstacle : je n'avais pas assez de connaissances en codage pour comprendre comment configurer un site web HTML de base qui pourrait facilement lire à partir d'une feuille Excel téléchargée.

Je me suis approché de mon directeur senior de l'ingénierie pour obtenir des conseils, et il m'a suggéré de simplifier mon design et de simplement créer un formulaire avec une zone de texte. Les utilisateurs copieraient les articles d'Excel dans le formulaire et le soumettraient.

Lors de la soumission, les prix seraient demandés à notre base de données. Les prix seraient ensuite retournés dans un simple tableau HTML, que les utilisateurs pourraient copier dans Excel s'ils le souhaitaient.

N'ayant plus besoin d'écrire du code pour lire les documents Excel, cela simplifiait beaucoup les choses.

Construire PriceSeeker

Même avec l'aide, ce fut une journée intense de codage presque constant.

J'ai pris quelques pauses pour vérifier auprès de nos planificateurs et obtenir leur approbation sur le design. J'ai pris beaucoup de snacks sur le bureau d'Oliver. J'ai également parlé avec d'autres ingénieurs chaque fois que j'avais besoin d'aide ou que je bloquais sur le code.

Je n'étais pas seul, et j'étais reconnaissant pour l'aide, mais c'était ma responsabilité de continuer à surmonter les difficultés et de fournir l'effort physique et mental d'écrire tout le code.

J'étais extrêmement conscient de mon désavantage dans la compétition, mais j'étais heureux de constater qu'à la fin du premier jour, j'avais réussi à faire fonctionner un prototype décent. Il retournait des informations pour de petites listes de quatre articles ou moins, mais pour des listes plus grandes, il ne retournait rien du tout.

La journée touchait à sa fin et je n'avais pas le temps d'enquêter ou de dépanner, alors j'ai téléchargé PriceSeeker sur GitHub Pages, j'ai envoyé l'adresse du site web à plusieurs planificateurs, et je suis rentré chez moi. Espérons qu'une bonne nuit de sommeil et un peu de temps pour les réponses m'aideraient sur mon chemin.

Quand je suis retourné au travail le deuxième jour, j'ai trouvé un email qui m'attendait de la part d'Oliver — il n'avait pas réussi à faire fonctionner PriceSeeker, mais il m'a utilement envoyé plusieurs captures d'écran montrant ce qu'il avait essayé.

En voyant les captures d'écran, j'ai immédiatement réalisé que je n'avais pas correctement expliqué comment copier et coller les articles dans le formulaire. J'ai renvoyé un email à Oliver avec une capture d'écran lui montrant comment faire, et il m'a renvoyé un email deux minutes plus tard, me montrant que cela fonctionnait.

Après avoir pris le temps de me mettre dans le bon état d'esprit, je suis allé au bureau d'Oliver. Il y avait plusieurs autres planificateurs autour de son bureau et sur son écran se trouvait PriceSeeker, qu'ils discutaient.

Oliver avait envoyé l'adresse du site web à tous les autres planificateurs de son équipe. Les planificateurs discutaient de la façon dont ce serait incroyable d'explorer davantage la collaboration entre la planification et l'ingénierie. J'étais excité par l'enthousiasme, et surtout par la possibilité d'ouvrir de nouvelles portes avec cette collaboration.

Cela excitait particulièrement Oliver, car il adorait l'idée de briser les barrières qui cloisonnaient les départements et les fermaient les uns des autres. Peut-être pourrions-nous créer d'autres opportunités pour trouver des problèmes et des solutions impactantes en encourageant la communication entre les départements.

Sachant que je ne serais pas présent pour la présentation, j'ai parlé à Oliver, et nous avons passé en revue son pitch de cinq minutes. Il a commencé par afficher notre site web PriceSeeker fonctionnel et le montrer en action. Il a copié et collé des articles dans le formulaire, l'a soumis, et a expliqué pourquoi c'était si utile de pouvoir obtenir les prix instantanément.

Sa démonstration a continué en expliquant comment "le ciel est la limite", avec des exemples d'autres données qui seraient utiles à recevoir. Il a expliqué l'impact commercial de la façon dont notre site web d'automatisation réduirait l'effort manuel et mènerait à une expérience client améliorée.

Il a conclu que bien que PriceSeeker ne retourne actuellement que les prix, il y avait beaucoup plus qui était possible. C'était incroyable de l'entendre parler des possibilités du site web. Il s'est concentré entièrement sur des termes commerciaux comme "effort manuel réduit" et "ventes annuelles augmentées", et étant lui-même planificateur, Oliver a pu parler de notre projet avec beaucoup plus de précision que je n'aurais jamais pu le faire.

Quand il a terminé sa présentation, j'ai posé des questions pour à la fois en apprendre davantage sur la valeur de notre projet et pour lui donner une pratique supplémentaire à expliquer son impact potentiel : "Combien d'effort manuel pourrait être réduit ?"

"Comment l'automatisation de la vérification de nos données de site web améliorerait-elle vos capacités à commander la bonne quantité de stock ?"

"En plus de la planification, quelles autres équipes ou départements bénéficieraient de la vérification automatisée des données de site web ?"

"Pourquoi ?"

Je savais poser ces questions parce que j'avais appris cette technique de questionnement dans le livre Spin Selling. Spin Selling reconnaît que les vendeurs ne peuvent parfois pas présenter directement aux acheteurs et doivent compter sur des intermédiaires pour transmettre les messages. Le livre conseille de coacher vos intermédiaires en leur posant des questions qui les amènent à expliquer les avantages du produit dans leurs propres mots.

C'est exactement ce que j'ai fait, posant beaucoup de questions qui ont amené Oliver à expliquer davantage toutes les nombreuses façons dont notre projet pouvait ajouter de la valeur.

Environ une heure avant le début du jugement, j'ai dû partir. J'étais désolé de ne pas pouvoir être là pour notre présentation, mais j'étais rassuré de savoir que nous étions entre de bonnes mains.

J'ai souhaité bonne chance à mon coéquipier et j'ai demandé à un collègue de m'envoyer un message si mon projet se classait dans le top trois.

Les Résultats Sont Là

Après être parti, je suis resté assis dans un train pendant deux heures. En chemin, je me suis mentalement préparé à ce qui se passerait une fois le concours terminé.

J'avais eu l'impression que nous étions la seule équipe à avoir commencé à planifier de manière extensive même avant que le Hackathon ne soit officiellement annoncé. J'avais également eu l'impression que nous étions la seule équipe à avoir préparé notre présentation pour nous concentrer exclusivement sur un impact commercial.

J'avais une certaine confiance grâce à cela, mais j'étais toujours nerveux car il y avait tant de choses incontrôlables qui pourraient nous empêcher d'atteindre les trois premières places ou même de gagner le Hackathon.

Je n'arrêtais pas d'imaginer toutes les choses qui pourraient mal tourner sans que je puisse faire quoi que ce soit. Peut-être que nous avions fait quelque chose de mal et que nous serions disqualifiés d'une manière ou d'une autre. Peut-être qu'Oliver ne pourrait pas présenter. Peut-être qu'une autre équipe livrerait une présentation superbe qui éblouirait tout le monde.

Tout en étant assis dans le train, j'ai réalisé que prévoir de gagner le Hackathon n'était pas quelque chose d'utile, car ce n'était pas quelque chose que je pouvais contrôler. J'ai décidé que — indépendamment des résultats — je continuerais à travailler sur mon projet et à le mettre en œuvre de manière à ce qu'il conduise à une augmentation de 20 000 à 80 000 dollars de profits.

J'ai choisi ces chiffres de manière plutôt arbitraire, mais cela semblait être quelque chose de réalisable. Pour atteindre mon objectif, je savais qu'il y avait encore beaucoup de travail à faire une fois le Hackathon terminé.

Je suis descendu du train et j'ai réussi à me rendre à mon événement familial. Une partie de moi était encore ailleurs, mais je savais qu'il n'y avait rien que je puisse faire maintenant. Je n'ai pas regardé mon téléphone pendant un moment, c'est pourquoi il a fallu un certain temps avant que je ne voie le message. Les résultats étaient là. Mon équipe avait gagné.

Pendant un bref moment, j'ai été choqué, soulagé, heureux. J'avais atteint ce point après tant de travail, tant d'attente et de lutte, et il semblait que cela portait enfin ses fruits.

La victoire n'a pas duré longtemps, car maintenant je suranalysais à nouveau toutes les possibilités négatives. Pour remporter cette victoire, j'avais fait beaucoup de choses au travail que je n'avais jamais expressément eu la permission de faire.

J'avais donné le lien vers la documentation de notre base de données à des planificateurs qui n'étaient clairement pas membres de notre département eCommerce. J'avais hébergé notre projet de Hackathon dans mon propre GitHub personnel plutôt que dans le dépôt de code de notre entreprise. J'avais constamment disparu pendant les pauses déjeuner et à la fin de la journée pour parler aux planificateurs, ce qui signifiait que mes collègues pouvaient argumenter que je négligeais ma charge de travail régulière.

Plus que tout cela, je m'inquiétais des répercussions sociales. J'étais extrêmement loin de tout niveau de séniorité dans mon département d'ingénierie, alors quel genre d'accueil recevrais-je pour avoir surpassé les ingénieurs plus seniors ?

Après le Hackathon

Je suis retourné au travail après le week-end, inquiet du pire, pour constater que personne ne semblait s'en soucier beaucoup.

Quand je suis revenu, un groupe de personnes m'a fait des high-fives et m'a souhaité leurs félicitations. Mais ma charge de travail quotidienne est restée la même qu'avant le Hackathon. On m'a dit par la direction supérieure de l'ingénierie qu'il n'y avait pas assez de marge de manœuvre en ingénierie pour me permettre, ou à tout autre ingénieur, d'obtenir l'autorisation officielle de travailler sur PriceSeeker.

Nos responsables de la planification ont dit qu'ils étaient en pleine restructuration majeure et ont dit qu'ils ne pourraient pas consacrer de temps à mon projet pendant au moins plusieurs mois. J'ai été frustré de constater que, bien que je recevais des retours positifs de la part de mes collègues, tous mes efforts se résumaient à un projet annexe soigné dont je pouvais être fier, mais que je ne pourrais pas vraiment faire quoi que ce soit.

J'avais beaucoup de travail à rattraper maintenant que le Hackathon était terminé, alors je suis retourné me concentrer uniquement sur ma charge de travail, avec 5 à 15 heures par semaine après le travail consacrées à l'étude des meilleures pratiques de Selenium. Il m'a fallu environ un mois ou deux de travail sur mes compétences pour atteindre le point où je terminais ma charge de travail assez rapidement pour avoir quelques heures de libre pendant la journée.

PriceSeeker était presque terminé et il ne restait qu'un peu plus de codage à faire pour corriger tous les bugs. J'ai estimé avoir besoin d'un jour ou deux de plus, mais sans autorisation officielle, cela devrait être mon propre projet à compléter secrètement par moi-même.

Aucun de mes collègues ne savait que je passais du temps sur PriceSeeker, ni ne s'en souciait, puisque je faisais mon travail régulier et le soumettais à temps.

Après un effort considérable et des ajustements, j'ai réussi à résoudre tous les bugs de PriceSeeker.

Excité, je me suis rendu chez les planificateurs de notre marque mineure pour leur montrer le modèle fonctionnel. Ils m'ont dit qu'ils n'en avaient plus besoin. Je n'arrivais pas à le croire. J'étais si choqué que je pouvais à peine demander ce qui n'allait pas.

Comme je l'ai découvert, le problème des prix incorrects avait été temporaire, causé par un changement récent dans la manière dont les prix seraient affichés. À un moment donné après le Hackathon, les affichages des prix avaient été mis à jour de manière à permettre aux planificateurs de trouver toute tarification incorrecte beaucoup plus rapidement.

Avec le recul, j'aurais dû m'en rendre compte pendant la préparation du Hackathon, mais j'ai dû être si enthousiaste à propos de mon plan que je n'avais pas correctement enquêté sur tous les domaines où cela pourrait mal tourner. Peu importe pourquoi je l'avais manqué, cela signifiait que PriceSeeker avait été effectivement inutile pendant un certain temps.

Oliver m'a dit que PriceSeeker tel qu'il était serait également inutile pour notre marque principale. Cependant, il m'a dit qu'il y avait un problème où les articles sur notre site web "tomberaient" occasionnellement. Cela signifiait que certains articles et couleurs qui étaient dans notre inventaire seraient accidentellement retirés de notre boutique eCommerce.

Cela arrivait rarement, mais les planificateurs ne le sauraient pas avant de revoir les rapports de ventes eCommerce hebdomadaires, de remarquer que certains articles n'avaient aucune vente, puis de vérifier s'ils étaient sur notre site web. À ce moment-là, ils marqueraient les produits à retourner sur notre site web.

Une fois de plus, c'était plus de travail manuel et moins de productivité que ce qui était optimal, et Oliver a conseillé qu'il serait très utile si PriceSeeker pouvait être modifié pour leur faire savoir si un article était sur notre site web ou non.

Après avoir parcouru notre documentation de base de données, j'ai réalisé qu'il serait très simple de demander à notre base de données de voir si un article était listé sur notre site web ou non, alors j'ai rapidement mis à jour PriceSeeker pour inclure également cette vérification.

Oliver m'a dit que nos merchandisers eCommerce étaient ceux qui étaient responsables des vérifications de qualité de l'inventaire du site web et qu'ils bénéficieraient le plus de cette nouvelle fonctionnalité dans PriceSeeker. Je me suis approché des merchandisers eCommerce pour chacune de nos marques et j'ai constaté qu'ils étaient très satisfaits de ce que je leur ai montré.

Ils ont copié et collé des centaines d'articles à la fois et ont rapidement vérifié que PriceSeeker signalait correctement tous les articles qui n'étaient pas listés sur notre boutique eCommerce. Et juste comme ça, ils ont commencé à l'utiliser plusieurs fois par semaine.

Au cours des semaines suivantes, j'ai continué à parler aux planificateurs et aux merchandisers, essayant de trouver d'autres domaines où PriceSeeker pourrait être utile.

J'ai appris que notre département de planification avait récemment mis en place une équipe de science des données. L'équipe était responsable de la construction de scripts automatisés et de tableaux de bord pour aider nos planificateurs à prendre de meilleures décisions. Signaler l'inventaire eCommerce non listé avait en fait été sur leur liste de choses à faire.

J'ai apprécié parler avec l'équipe de science des données et échanger des idées, mais sans sanction officielle pour travailler sur PriceSeeker ou autre chose, nos conversations étaient principalement théoriques. Néanmoins, j'étais heureux de savoir que mon projet avait accompli quelque chose et voyait enfin le jour.

Ce n'est pas longtemps après que j'ai reçu un email du département des ressources humaines de ma société de conseil. Ils voulaient planifier une réunion.

Je suis allé leur parler et on m'a dit qu'il y aurait des licenciements. Plusieurs consultants ne verraient pas leurs contrats renouvelés. J'en faisais partie. J'avais un préavis de trois semaines avant la fin de mon contrat.

Je savais que la marque de mode était confrontée à un déclin des ventes et que licencier un consultant était plus facile que de se débarrasser d'un employé à temps plein. Néanmoins, j'ai été assez surpris d'être parmi ceux qui seraient licenciés.

Lors de mes dernières semaines, j'ai rangé mon travail régulier et j'ai accordé une attention particulière à PriceSeeker. Je voulais voir si je pouvais quantifier l'impact financier qu'il avait eu, mais la valeur de la détection des stocks non listés par accident ne serait pas facile à quantifier.

Quand je suis allé voir nos merchandisers eCommerce, ils m'ont dit que son impact serait impossible à mesurer. Il y avait tant de facteurs compliqués impliqués, comme le nombre d'articles non listés qui seraient détectés, la marque à laquelle ils appartenaient, la popularité de ces articles, et la quantité de stock restant.

Oliver a résumé la situation : "Bien que nous ne puissions pas donner une valeur monétaire à PriceSeeker, nous sommes certains qu'il a un impact positif sur notre résultat net."

Avec mon contrat terminé, je me suis retrouvé à regarder en arrière sur environ sept mois dans une entreprise où j'avais vécu des aventures incroyables, dont la plus excitante était notre Hackathon.

Après que notre Hackathon soit terminé, beaucoup de mes collègues m'ont dit que j'avais gagné parce que je "m'étais concentré sur un impact commercial". Bien qu'ils le disent comme un compliment, je me sentais toujours vide quand j'entendais cela comme la seule raison.

Personnellement, j'attribue ma victoire à la préparation active même avant que le Hackathon ne soit officiellement annoncé. En faisant cela, j'ai pu obtenir continuellement les retours dont j'avais besoin pour améliorer ma proposition afin qu'elle ait finalement un impact commercial légitime.

Je n'aurais pas pu le faire sans l'aide des autres. Tant de travail semblait être de ma responsabilité, comme si je devais être celui qui pousse, découvre, s'auto-forme et travaille.

La vérité est que je n'étais pas seul. Ceux qui ont offert de la passion et de l'enthousiasme — mon directeur senior de l'ingénierie et mon coéquipier, Oliver — étaient ceux qui m'ont poussé à faire partie d'une compétition à laquelle je ne me serais jamais approché deux ans plus tôt.

Je continue d'apprendre. J'essaie toujours de nouvelles choses. J'espère toujours que je trouverai plus de cette collaboration qui m'a permis de créer quelque chose d'utile pour mon entreprise et de significatif pour mon propre parcours.

En repensant, il est encore difficile pour moi de croire que quelqu'un comme moi, qui avait tant lutté pour obtenir une carrière, pourrait entrer dans le monde de l'entreprise et transformer sa vie.

Pour moi, le Hackathon était une seconde chance. Et j'en ai fait le meilleur usage.