#3 Journal d’un développeur chez Esker : R&D cases & questions PS
Cher journal,
Cela fait plus de deux ans que j’ai décroché mon premier emploi chez Esker. Je suis développeur dans une des dix équipes de la R&D en charge du développement des solutions à destination de nos clients. Nous sommes entre quatre et six développeuses/développeurs par équipe, et travaillons tous en méthode Agile sur une base de code commune afin de développer de nouvelles fonctionnalités pour nos produits. Mais notre travail ne se limite pas à ça ! Je tenterai donc de t’en présenter toutes les facettes en plusieurs articles. Tu peux retrouver les sujets précédents sur la page d’Esker Labs.
Aujourd’hui, les équipes de notre support technique avaient besoin d’aide de notre part au sujet d’un problème client qu’ils n’arrivaient pas à résoudre. En effet, certains tickets nécessitent parfois une investigation plus poussée de la part des équipes R&D pour être résolus, et cela fait aussi partie de notre mission d’aider à débloquer nos clients. Pour réaliser ce travail, nous pouvons regarder directement le code du client, mais nous avons surtout la possibilité d’utiliser toute une batterie d’outils de diagnostic et de monitoring : Kibana, QueryTool, MMCWeb… Des outils parfois développés en interne qui nous permettent en général de trouver rapidement une solution.
Ces tickets, appelés R&D Cases, sont l’occasion pour moi d’en apprendre un peu plus sur des parties de notre produit que nous n’aurions pas l’occasion de regarder habituellement. Notre produit a un historique. Il est impossible que je le connaisse dans ses moindres recoins. Ainsi, même après 2 ans de travail, j’apprends toujours énormément de chaque nouveau R&D Case qui se présente.
Ceux-ci ne proviennent d’ailleurs pas uniquement des équipes support, mais peuvent être créés directement par nos services de consulting, aussi appelés PS (Professional Services). Les équipes PS sont en charge d’adapter notre solution aux besoins spécifiques de nos clients et de personnaliser le produit en fonction de leurs attentes. Dans le cadre de ces modifications, elles sont amenées à nous contacter pour nous poser des questions concernant leurs implémentations, questions qui donnent parfois lieu à des améliorations de notre part. Cette collaboration est donc bénéfique pour tout le monde !
Pour gérer ces R&D Cases, chaque équipe est libre de s’organiser comme elle le souhaite. Dans la mienne, nous utilisons un Round-Robin : tous les membres de l’équipe sont listés les uns à la suite des autres, et chaque fois qu’un nouveau R&D Case arrive, il est assigné à une personne qui devient owner du case et devra donc s’assurer de sa résolution. Être owner ne signifie pas forcément résoudre le case par soi-même, mais mobiliser les ressources nécessaires pour le résoudre (par exemple en faisant appel à une personne qui connaît mieux le sujet, en communiquant avec le créateur du R&D case pour lui expliquer les investigations en cours…). Le case suivant sera assigné à la personne suivante dans la liste, et ainsi de suite. Ce mode de fonctionnement assure une répartition égale entre chaque membre de l’équipe.
D’autres équipes ont cependant des façons de s’organiser totalement différentes et qui leur conviennent mieux ! Chaque équipe a sa manière de gérer les choses, ses expérimentations, qui se définissent souvent d’elles-mêmes, de manière naturelle, au fil du temps passé à travailler ensemble. Pour moi, c’est un peu à ça que se résume l’Agilité : travailler tous ensemble, s’organiser et s’améliorer au fur et à mesure pour finalement arriver à un but commun, le tout dans une ambiance de travail au sein de laquelle chacun se sent impliqué et valorisé. Ce n’est pas plus compliqué que ça !
Tu as hâte de savoir la suite ? C’est par ici :
Retrouve les autres parties du journal d’un développeur chez Esker :
