Lecture 10 minutes

Mardi, 9h, je déboule (par l'esprit) à Tel Aviv, où il est 10h. La salle de réunion est petite mais la distanciation sociale est respectée. Tout va bien. Le café a le même goût qu’à la maison... Ce qui est un vrai plus !

On démarre rapidement par une présentation de monday.com et du concept de Work OS. Viennent ensuite 2 sessions de formation orientées développeurs. Pendant que j’écoute quasi religieusement, vous pouvez lire ce qui suit pour comprendre ce qu’est un Work OS.

Quèsaco ? C’est quoi un “Work OS” ?

Eh bien, c’est un nouveau terme marketing, non ? Je charrie (un peu) mais, en fait, c’est plutôt bien trouvé. Je vais expliquer ce que j’en pense avec mes propres mots. Ce ne sera peut-être pas la version officielle... Vous pouvez compléter avec les autres articles du site.

Pour moi, après une bonne année d’utilisation, le Work OS est le nœud opérationnel de mes journées de travail. Je gagne un temps précieux car, grâce à lui, je n’ai plus à chercher l’info dans différentes sources. Mes collègues aussi sont autonomes et donc me dérangent sollicitent moins.

Le plus est que l’info est contextualisée. Quand on a besoin, elle se trouve rapidement et facilement, même si c’est longtemps après la bataille. Prenons un exemple : je bosse sur le développement d’une nouvelle fonction pour un client.

La fonction à coder a été saisie comme une nouvelle ligne dans le tableau monday.com. Elle m’est assignée avec un statut "A faire". Je lis un commentaire du Lead Dev sur la conception technique, histoire de partir immédiatement dans la bonne direction. Il y a un lien vers un mapping de correspondance des champs entre deux tables (tableau google sheet qui s’affiche directement).

Le nom de la branche git que je vais utiliser a été créé automatiquement. Je n’ai qu’à le recopier et à me lancer. J’ai une question sur un cas non prévu supposé. Je la pose au chef de projet dans la zone de discussion dédiée de la tâche en cours. C’est là que j’aurais la réponse quand elle arrivera. C’est là aussi qu’on pourra tous la trouver si on se pose des questions sur ce développement dans quelques mois ou dans 3 ans.

En résumé, on a affaire à des tableaux interactifs et dynamiques avec des fonctions avancées de gestion des droits (écriture, lecture) par tableau, ligne et colonne ; des automatismes (c’est expliqué juste après) ; des connecteurs intégrés avec d’autres outils (CRM, Zendesk, Jira, Google, etc. mais aussi Zapier ou Integromat pour aller encore plus loin) ; et j’en oublie sûrement.

11h : c’est l’apéro brainstorming

Fin de la partie formation. 2 présentations de 30 minutes durant lesquelles on nous a expliqué 2 manières différentes d’ajouter des fonctionnalités à la plateforme. Je connaissais déjà la première méthode que j’ai eu la chance de pouvoir beta tester ces dernières semaines. Big up à Alexis, un collègue qui a pu me coacher sur mon premier projet Vue.js. Il est d’ailleurs à côté de moi à Tel Aviv (imaginaire) et on va coder ensemble tout à l’heure.

La deuxième approche consiste à s’interfacer avec des API externes pour créer de nouvelles recettes d’automation. C’est là-dessus qu’on va bosser cet après-midi comme c’est nouveau. Parce qu’on est comme des gosses avec un nouveau jouet ! Mais aussi parce qu’on nous a donné une liste de courses pour des recettes dont on aurait besoin en interne.

Une recette version monday.com, ça ressemble un peu à un texte à trou pour l’utilisateur final. Par exemple : “Quand le statut ________ change pour la valeur ________, je crée un nouveau projet à partir du modèle _______“. Concrètement : l’admin du compte client choisit une recette, il l’ajoute à un board et il remplit les trous en cliquant dessus (listes à choix ou saisie libre). Chaque recette démarre par un trigger, c’est à dire un événement. Dans l’exemple, un statut vient de changer sur l’une des lignes (item) du tableau courant (board). La recette s’exécute automatiquement à chaque fois que l'événement se produit.

Notre job, en plus d’écrire la phrase sans faire de fautes*, ce sera de coder ce qui va se passer quand elle est déclenchée. Ici, dans l’exemple, ce sera envoyer les données nécessaires à un site externe qui va faire des vérifications, collecter d’autres données complémentaires, puis envoyer des ordres à la plate-forme pour qu’elle fasse ce que l’on veut.

(*private joke)

14h : l’aventura, c’est le code que j’écris avec toi

Confinement oblige, on code évidemment à distance chacun chez soi. Pour autant, le contexte du hackathon veut que l’on travaille ensemble de manière très étroite. Pour cela, nous discutons sur un canal audio dédié et utilisons la fonction de collaboration Live Share de l’éditeur Visual Code.

Nous, ce sont mes deux collègues, Alexis et Cédric, plus ma pomme. Dites bonjour les gars. Alexis travaille essentiellement sur des solutions de Business Intelligence. Cédric a trop de casquettes pour toutes les citer, sinon il rougit, mais là, c’est son expertise sur les automations/intégrations qui nous a fait le recruter. Moi, je suis la mascotte.

L’après-midi passe très vite (quand on s’amuse, hein) ! Nous obtenons un premier jet fonctionnel de ce que nous souhaitions coder en priorité.

Nous activons le dev' sur un tableau de test. Dès que l’on change le statut pour “affaire gagnée” sur une ligne de ce tableau, un nouveau tableau est créé à partir du modèle de tableau “affaire gagnée”. Bien ça !

17h : à l’heure du thé on se prépare pour demain

L’équipe technique de monday.com est très réactive et on voit passer plein d’infos intéressantes sur le Slack dédié. Ils ajoutent même de petites features à la demande. Du coup, on en a demandé une pour peaufiner notre premier développement et on l’aura demain matin. Nice !

On repasse sur le board des idées de recettes à coder. C’est un tableau créé il y a environ 2 mois quand on a été invité à participer au hackathon. Les équipes en contact fréquent avec nos clients et prospects “monday” ont listé les fonctions qui reviennent le plus souvent ou dont on a besoin en interne.

Chacun d’eux a pu voter pendant la présentation. Nous nous concentrons donc sur les idées qui ont reçu le plus de votes. Quelques unes sont écartées car l’éditeur les a déjà annoncées ou ajoutées depuis. Une poignée d’autre n’est pas adaptée au temps qui nous reste.

Nous retenons deux autres recettes d’automation à développer demain, après avoir validé leur faisabilité.. Nous retournons à l’hôtel (fictif) pour nous rafraîchir avant une folle soirée de bières avec les autres équipes de dév'. Soupir.

Mercredi matin tout s’accélère

La journée est bien remplie et pauvre en pauses. Ca ne plaisante plus !

9h : brève intervention de la team monday.com pour nous rappeler leur disponibilité et nous présenter les nouveautés ajoutées la veille.

Nous codons à nouveau en binôme avec Alexis pendant que Cédric avance de son côté sur une autre fonctionnalité. Il échange aussi avec l’équipe de monday.com sur la connection via OAuth.

La matinée passe très vite.

La pause déjeuner est prise rapidement et presque à tour de rôle.

Nous faisons un point à 14h sur ce qu’il reste à faire. On est pas mal du tout : nous pourrons présenter 3 automations en plus de la vue et du widget qui étaient déjà prêts.

Nous terminons les développements et les testons. Tranquille.

A 16h30, on arrête tout. Je modifie quelques libellés dans les tableaux exemples pour que la présentation fasse plus réaliste.

Après, j’attends mon tour en stressant un peu mais pas trop.

17h : présentation des réalisations

Deux groupes présentent avant nous : leur travail est top ! Comme nous, ils ont eu la chance de pouvoir développer avant le hackathon et cela se voit dans leur réalisation. On ne code pas ça en 2 jours.

A mon tour. Je partage l’écran et je commence par montrer ce que l’on a développé avant le hackathon. La vue et le widget reprennent les couleurs et les styles de la plateforme. Ce qui se voit et est très apprécié par nos hôtes.

J’insiste bien sur le fait que cela a été créé avant le hackathon pour ménager les groupes qui n’ont pas eu notre chance et ont été invités plus tardivement.

Je passe ensuite sur ce que l’on a créé pendant ces 2 jours.

Une première recette vérifie le format d’une valeur après sa saisie et affiche une alerte en cas d’erreur sur le format. Le client choisit lui-même son masque de saisie pour chaque colonne. Simple et efficace.

Par contre, le délai d’affichage de la notification me semble très long pendant la présentation, peut-être à cause du partage d’écran, probablement à cause d’un reste de stress.

Du coup, je présente la seconde recette en oubliant la moitié de la fonctionnalité. Oups. En plus de la validation du format sur un N°Siren, on va récupérer dans une base de données le nom de l’entreprise et son adresse.

La démo de la troisième recette est impeccable, heureusement. J’affiche le tableau fictif des affaires et je passe le statut de l’une d’elle à “gagné”. J’ai choisi une affaire de type CRM qui avait un statut “négociation” et un type “CRM”. Alexis et moi sommes sélectionnés dans la colonne “responsables”.

Le nouveau tableau a bien été créé à partir du modèle “CRM” (nom du type de l’affaire). Les propriétaires sont bien ceux qui étaient responsables de l’affaire, plus Cédric qui est ajouté systématiquement.

Je souffle en grand coup et profite des présentations restantes tout en fêtant ça avec mes collègues sur le Slack Synolia.

18h30 : l’avion atterrit dans mon canapé

Et ça fait du bien d’être chez soi.

Demain, c’est férié. Vendredi, c’est pont. Lundi, on met le repo au propre et on prépare les vraies features à partir des POCs réalisés pour le hackathon.

La marketplace devrait ouvrir dans les 2 prochains mois, on a hâte !