Intégrer la RS&DE dans votre processus de développement logiciel Dans un billet précédent, j’ai discuté de l’importance pour une société de documenter ses connaissances et son savoir-faire. Or, j’aimerais poursuivre en abordant la possibilité d’intégrer la documentation de la RS&DE à des méthodologies existantes de documentation dans une société. Préalablement à l’intégration de la RS&DE à une méthodologie de documentation Avant d’intégrer la RS&DE, il faut s’assurer que la méthodologie en place pour documenter les projets est structurée et centralisée, ce qui permettra d’être efficace et crédible lorsque viendra le temps de discuter de R&D dans le processus. Pour ce faire, l’entreprise doit avoir une vision technologique commune. Le génie logiciel est composé de différents services : le développement, la maintenance et l’intégration d’une solution, d’un produit ou service logiciel. Ces services sont réalisés par une équipe composée de plusieurs professionnels. Souvent, le nombre de professionnels impliqués dans les différents chantiers est tellement grand qu’ils n’ont pas connaissances des travaux qui sont effectués par les autres. Dans ce genre de situation, les responsables techniques ne semblent pas au courant des travaux de leurs développeurs. Il est alors important que chaque initiative puisse être analysée par un individu ou un groupe d’individus. Ce ou ces individus porteront le rôle d’expert dans l’architecture et la conception de bases et orientations technologiques de la solution. La méthodologie de travail est-elle assez efficace pour répondre au programme de la RD&DE? Pour bien documenter la RS&DE, il faut d’abord savoir la reconnaître. En fait, la documentation est parfois trop élaborée ou pas assez. Dans tous les cas, que faut-il documenter? L’élaboration de connaissance ou d’un savoir-faire consiste à décrire chronologiquement les étapes qui ont mené à la construction d’un projet. Autrement dit, il faut distinguer la documentation d’une solution ou d’un produit de la documentation de sa conception. Par exemple, il y a une tendance à documenter sous forme d’hypothèses les idées qui ont été essayées pour arriver à bon port. Cette série d’idées ne fait que cheminer vers ce qui est possible, ce qui indique que leurs auteurs ne sont pas en mesure de différencier des travaux standards d’une incertitude technologique, puisqu’ils utilisent les technologies telles quelles et ne les adapte pas. Or, une bonne documentation devrait être en mesure de répondre à ces questions : Peut-on identifier quand l’incertitude s’est présentée? Peut-on expliquer pour quelle raison l’incertitude est survenue? Peut-on référer l’explication à des preuves externes de la base des connaissances? Peut-on retracer, extraire et fournir efficacement votre documentation? Est-ce que votre documentation est datée et peut-on suivre la chronologie des événements? Dans le cas contraire, la documentation est incomplète. Elle ne fait probablement qu’explorer les connaissances du domaine public, sans aborder de réelles incertitudes. D’où l’importance de l’analyse par un expert pour différencier les travaux standards vs incertitude. Comment inciter les professionnels à documenter la RS&DE sans que cette action constitue une charge de travail supplémentaire? La documentation est importante, mais si on veut intégrer une stratégie de documentation de la RS&DE, il faut qu’elle soit le moins invasive possible aux méthodologies de travail déjà en place. En outre, la documentation peut se limiter uniquement à ce qui est nécessaire pour la RS&DE, le produit ou la société. Par exemple, si une société possède un expert capable de discerner les travaux standards des incertitudes, ce dernier peut décider d’entreprendre un projet de R&D pour surmonter ces incertitudes. Dans ce cas, il s’assure que ses développeurs documentent leurs hypothèses et les expérimentations pour les valider. Dans le cas de travaux standards, aucune R&D ou documentation n’est entreprise, car les développeurs travaillent sur des tâches qu’ils connaissent ou qu’ils rencontrent chaque jour. Outre la présence d’un expert, la présence d’un outil comme Jira peut aussi faciliter l’intégration de la RS&DE en permettant de créer des gabarits de tâches qui documentent des activités clés dans la RS&DE. Lorsqu’une tâche de votre méthodologie présente de la RS&DE, il est alors possible d’ajouter une sous-tâche basée sur le gabarit de tâche relié à l’activité RS&DE présente. Il est alors efficace de retracer les tâches reliées à la RS&DE pour discussions et preuves. En somme, l’intégration de la documentation de la RS&DE nécessitent l’articulation de changements. Cependant, pour que ces changements aient un impact minimal sur le travail des employés, il faut que : La société possède une méthodologie de documentation structurée. La société possède une vision technologique commune, sous la forme d’un expert ou d’un groupe d’experts. Le ou les experts soient en mesure de différencier des travaux standards des incertitudes technologiques.