Ingénieux vs. Faire le Travail

Il y a un équilibre délicat entre bien faire les choses et livrer.

Je dirige une équipe de 8 développeurs. Chaque heure où l’équipe est bloquée représente huit heures de développement perdues.

Un collègue avait pour tâche de me fournir une base de données. Après deux jours d’attente, j’ai demandé le statut. Il a dit que nous avions des problèmes avec l’importation des données. Quand il a scripté les données, cela faisait presque un giga. Un giga était un peu trop pour être intégré dans subversion. Il cherchait une méthode alternative.

Un autre jour passe. Je lui ai demandé comment ça avançait. Il dit que c’est presque fini. Ok cool, j’ai trois jours de retard, 192 heures de temps de développement perdues. J’ai hâte de commencer. Mon équipe saigne des heures.

Le quatrième jour, il est prêt. Enfin ! Il m’envoie le projet de base de données et les scripts d’importation de base de données. Il utilise PowerShell et BCP pour importer les données. Je les envoie à l’équipe avec des instructions détaillées.

L’équipe a 12 heures d’avance sur moi, en Inde. La boucle de rétroaction est de 12 heures. Il faut 24 heures pour démarrer quoi que ce soit.

Comme le dit la loi de Murphy : “Tout ce qui peut mal tourner, tournera mal”. L’équipe a exécuté les scripts d’importation de données et a rencontré un échec. Les scripts Powershell ont échoué, un problème de sécurité a empêché l’importation des données.

J’ai cinq jours de retard. 320 heures ont été perdues. La date limite approche, nous devons commencer.

À ce stade, je dois faire fonctionner la base de données pour l’équipe. Sur ma machine, je détache la base de données, la compresse et l’envoie à l’équipe. Chaque développeur sait comment rattacher une base de données. Dans l’heure qui suit la réception de la base de données, les huit développeurs ont une base de données fonctionnelle. Succès !

Créer un processus ingénieux est bien, mais parfois simplement faire le travail est plus important qu’être ingénieux.