Projet Catalyseur : L'auditabilité fait l'objet d'un audit

Le développement de logiciels pour les nuls

Dans le cadre de mon travail de consultant et de développeur en technologie, je travaille avec des clients pour élaborer des solutions qui résolvent des problèmes commerciaux réels. À différents moments, nous pouvons utiliser une approche plus “agile”, et à d’autres moments, c’est une bonne vieille “cascade”. Indépendamment des méthodologies en jeu, une vérité fondamentale sous-tend tout notre travail : Si les utilisateurs ne comprennent pas ce que nous avons construit, notre solution n’a aucune valeur. En outre, si nous ne communiquons pas étroitement tout au long du projet, il est peu probable que nous construisions la bonne chose.

La communication sur le travail - au début, au milieu et à la fin du projet - est une voie à double sens, et c’est la seule voie qui importe.

Pour faciliter la communication, nous pouvons prévoir des réunions quotidiennes, ainsi que des “revues de sprint” bihebdomadaires, au cours desquelles nous passons en revue ce qui a été construit progressivement. Lorsqu’un projet arrive à son terme, il n’y a pas de grande inauguration où le client voit ce que nous avons construit pour la première fois. Nous n’attendons pas en retenant notre souffle qu’il soit heureux (ou consterné !). Lorsqu’un projet bien géré atteint la ligne d’arrivée, les parties prenantes ont toutes participé à l’essai de la solution à chaque étape du processus. Enfin, bien sûr, la rémunération du travail de développement est liée à l’obtention de résultats. Les conditions peuvent varier, mais il suffit de dire que si un projet s’égare ou n’est jamais terminé, les conditions de paiement doivent être revues.

Blockchain est un logiciel

Cardano, comme tout réseau blockchain, est fondamentalement un projet de développement logiciel. Les projets de logiciels réussis ne sont jamais construits en une seule fois, puis libérés dans le monde, sans jamais être touchés à nouveau. Pensez à certains des logiciels les plus célèbres que vous utilisez tous les jours : Google, Facebook, iOS, Microsoft Windows, etc. Pour chacun d’entre eux, nous savons qu’une énorme entreprise s’active en coulisses, diffusant des correctifs, rédigeant de la documentation, publiant des mises à jour, de nouvelles fonctionnalités et de nouvelles versions. Sans ce travail continu, la technologie deviendrait rapidement obsolète.

La vision future de Cardano - à l’ère de Voltaire - est que la décentralisation reste la marque de fabrique de tout développement logiciel en cours. Cela signifie que le prochain chef de projet pourrait être vous, moi, ou toute personne ayant une grande idée et la volonté de se salir les mains. Le projet Catalyst est une expérience en cours qui nous permet d’apprendre à le faire à l’échelle mondiale. Dans le cadre de Catalyst, tout le monde peut proposer une solution - un “projet” de développement de logiciels, si vous voulez - et les propositions qui sont “approuvées” reçoivent un financement pour mettre en œuvre leur solution.

Regarder dans le miroir

Ainsi, pour le projet Catalyst de Cardano - dont certains diraient qu’il s’agit de la plus grande, de la plus importante et de la plus innovante expérience de développement de logiciels décentralisés de l’histoire du monde - comment ces éléments fondamentaux que sont la communication, les jalons et l’approbation de l’achèvement ont-ils été gérés ?

Eh bien, certains pourraient prétendre qu’ils n’ont pas été gérés du tout.

Le premier fonds auquel j’ai participé en tant que proposant financé était le fonds 6. Dans ce cycle, les propositions gagnantes recevaient un financement en 3 ou 4 versements mensuels. On attendait de nous des “rapports” bimensuels, mais il n’y avait aucune raison de croire qu’ils étaient examinés par qui que ce soit. En outre, le financement que nous recevions n’était pas lié à la durée du projet. Un projet d’un mois et un projet d’un an recevaient tous deux l’intégralité de leur financement par les mêmes 3 ou 4 versements mensuels, après quoi le projet était entièrement payé.

Les résultats de ce [non]système étaient prévisibles. Les proposants financés n’étaient pas incités à s’engager dans des rapports significatifs ou même à terminer leur projet une fois que tous les fonds avaient été versés. Même les acteurs honnêtes qui effectuaient réellement le travail pouvaient avoir du mal à donner la priorité à la rédaction d’un rapport de clôture de projet réfléchi. Il semblait que personne n’était vraiment intéressé à le voir, et surtout, il n’y avait aucune incitation financière finale d’aucune sorte.

Si un projet de logiciel est construit dans les bois et que personne ne le voit - est-ce vraiment arrivé ?

Une brique à la fois

Au cours des Fonds 7, 8 et 9, des étapes progressives nous ont rapprochés des normes de communication et d’exécution que l’on devrait attendre dans un contexte professionnel. Même dans un écosystème décentralisé et sans autorisation, nous payons pour du bon travail et sommes en droit d’attendre des résultats de niveau professionnel. Ces étapes progressives ont inclus :

• des paiements plus structurés qui établissent un lien entre le calendrier des paiements et la durée du projet.
• des attentes plus élevées en matière de rapports mensuels
• des paiements finaux subordonnés à l’approbation de l’achèvement du projet.

Rapports basés sur des jalons

La dernière étape de cette progression est l’expérience qui se déroule actuellement dans le Fonds 9 avec tous les projets financés dans le cadre de la campagne DApps, Products, and Integrations, ainsi qu’avec tout projet financé avec un budget supérieur à 75 000 dollars. Ces projets participeront à un nouveau système de financement et de supervision des projets “Milestone Based Reporting”. Au lieu de remplir des rapports mensuels génériques, ces proposants financés sont invités à structurer leur travail en étapes concrètes avec des livrables vérifiables. Le paiement du travail est ensuite effectué en plusieurs versements liés à l’achèvement vérifié de chaque étape.

Pour les proposants expérimentés et ceux qui ont une expérience du développement de logiciels ou de la gestion de projet, le travail d’identification des produits livrables et des étapes vérifiables peut avoir déjà été fait lors de la rédaction de la proposition de projet. Un plan de projet et une feuille de route bien rédigés comporteront de bons jalons déjà définis. Cependant, pour les proposants financés ayant moins d’expérience formelle de ce type de projets, cette mise à jour pourrait introduire de nouveaux concepts sur la façon de planifier et de communiquer les plans et les progrès du projet avec les parties prenantes.

Avoir un état d’esprit de croissance !

Le changement est difficile, et il est inévitable que la machine grince un peu lorsque nous changeons de vitesse. Mais plutôt que de s’attarder sur ce qui ne fonctionne pas encore et sur l’ampleur des lacunes, je préfère attirer notre attention sur ce qui est inspirant et intéressant dans tout cela :

Nous ne sommes pas coincés avec des systèmes qui ne fonctionnent pas. Les changements progressifs apportés par chaque Fonds prouvent que le “système fonctionne”. Les gens participent, apportent des idées et de l’énergie, et aident à mettre en œuvre la prochaine itération de l’expérience.

Personne n’est laissé pour compte. Les développeurs et les chefs de projet professionnels peuvent ressentir une frustration justifiée face au travail désordonné qui a été réalisé jusqu’à présent. Ce qui me donne de l’espoir et de la satisfaction, c’est qu’en tant que communauté, nous trouvons un moyen d’inclure ceux qui n’ont pas ce bagage professionnel et de les former aux compétences de gestion de projet qu’ils ne possèdent pas encore. Je trouve passionnant que des personnes d’horizons différents aient la possibilité de participer, sachant que nous pouvons leur enseigner les compétences dont elles ont besoin en matière de rapports et de gestion de projet pour combler leurs lacunes. Nous sommes plus forts ensemble, et nous avons tous quelque chose à apprendre les uns des autres.

**Nous sommes à la hauteur de la situation. L’un des problèmes passés avec les rapports de Project Catalyst était que, bien qu’ils soient hypothétiquement publics, ils n’étaient pas faciles à utiliser ou à digérer. Ils vivaient dans une feuille de calcul, où des colonnes et des colonnes de texte provenant de milliers de projets rampaient comme des fourmis. Lido Nation a récemment comblé cette lacune en présentant des données de rapport agrégées sur des listes de “projets” individuels dans notre outil Catalyst Explorer. Le portail du projet Catalyst devrait bientôt offrir une transparence similaire.

Les rapports font l’objet d’une attention plus soutenue, de sorte que les progrès insuffisants sont enfin repérés et traités. Lorsque ces conversations ont lieu, on s’efforce de faire en sorte qu’elles ne soient pas punitives. Une demande d’informations supplémentaires est simplement une occasion d’améliorer vos compétences en matière de communication et d’expliquer votre travail en des termes que davantage de personnes peuvent comprendre et apprécier. Nous devrions attendre ces normes élevées pour le travail financé par “notre” trésor central !

Qui va utiliser ces solutions ?

En guise de conclusion, j’aimerais revenir une dernière fois sur le projet de développement logiciel “traditionnel” et sa mesure ultime du succès :

• La solution finale est-elle utilisée ?
• Les utilisateurs l’apprécient-ils ?
• Savent-ils où la trouver ?
• Existe-t-il une bonne documentation ?
• Existe-t-il un moyen pour eux de contacter le support pour poser des questions, faire des commentaires et proposer des améliorations ?

Soyons enthousiastes à l’idée d’un écosystème Project Catalyst qui ne se contente pas de lâcher des projets isolés dans la nature, pour ne plus jamais les revoir. Au lieu de cela, en tant qu’utilisateurs, préparons-nous à nous engager dans les projets que nous finançons : pendant leur construction et après leur achèvement. En tant que constructeurs, n’oublions pas que notre véritable public n’est pas la personne qui tient les cordons de la bourse pour notre prochaine “tranche” de paiement - ce sont les utilisateurs finaux ! Que devez-vous leur montrer pour les faire participer au projet, obtenir leur avis à intervalles réguliers et, finalement, leur fournir une solution gagnante ?