Nous avons sélectionné pour alimenter votre veille deux billets écrits respectivement par un développeur et par un responsable innovation au sein d’une DSI. Ces deux experts incarnent les deux univers, deux revers d’une même médaille, que le DSI doit savoir orchestrer : le build et le run. Ces deux billets sont aussi deux beaux exercices de pédagogie, par un développeur dans un style « fleuri », sans pitié pour le « quick dev qui induit de la dette technique », et le responsable innovation dans un style « concis », sans pitié pour les acronymes. L’occasion de rappeler que la pédagogie est une merveilleuse arme dans l’arsenal du DSI, et que c’est bien sûr le contexte et l’interlocuteur qui vous aideront à placer votre curseur pour faire passer les bons messages, à la bonne personne, pour le bénéfice de toute l’entreprise ! Pour faire comprendre aux fonctionnels la dette technique (tout en restant courtois) Olivier Servières, développeur chez TEA, The eBook Alternative, ne dit jamais non (dans le cadre professionnel). Il l’explique dans un billet de blog qui sent le vécu, et qui fait passer avec humour des messages importants pour une meilleure compréhension entre les devs et les fonctionnels. « En tant que développeur, je suis souvent mené à rechigner à faire ce qu’on me demande. (…) Au fil du temps, ma réaction par rapport à ce genre de cas a évolué. Quand j’étais en tout début de carrière, n’ayant aucune personnalité, je disais oui à tout sans jamais rien questionner. (…) J’ai depuis quelques années trouvé la solution qui me convient personnellement : je ne dis jamais « non » à une demande. Je dis que c’est possible, je donne le coût, je donne les implications, et je donne une alternative. Et je laisse décider. Systématiquement. Même pour la demande la plus débile qui me fout la rage de feu intérieure. (…) Quand le quick-dev demandé en urgence induit de la dette technique, je négocie une story de remboursement à caser en priorité critique sur le prochain sprint. Ou pas : je suis aussi capable de dire que je peux vivre un certain temps avec cette dette technique, qu’il ne sera obligatoire de la rembourser que quand telle future grosse fonctionnalité devra être développée. » L’intégralité du billet à lire sur le blog d’Olivier Servières : Je suis développeur et je ne dis jamais non. Pour clarifier les acronymes (tout en évitant les amalgames) Nombre d’approximations sont faites lorsque sont évoqués les plans de continuité d’activité, de reprise d’activité, de continuité informatique… ces charmants acronymes méritaient un beau décryptage. C’est chose faite avec M. Hichem MRABET, Directeur du Pôle innovation numérique à la DSI de l’AFPA, Association pour la formation professionnelle des adultes. · PCA (Plan de continuité d’activité) : Haute disponibilité de la production · PRA (Plan de reprise d’activité) : Reprise en cas de sinistre · PCI et PRI : Pour les informaticiens · PCC (Plan de Communication en cas de crise) : L’oublié ! « L’amalgame de terminologie est souvent fait entre métiers et DSI. PRA et PCA sont utilisés par tous. Il y a bien une distinction entre les périmètres de responsabilité des métiers et de la DSI. Trop souvent dans les entreprises la mise en œuvre d’un PCA et PRA avaient été transmis uniquement à la DSI, DSI qui naturellement et de bonne foi réduisait à son strict périmètre de responsabilité son étude et mise en œuvre de plans ! » L’intégralité du billet à lire sur LinkedIn Pulse : PCA PRA PCI PRI et PCC… de quoi s’agit-il ?!! Et pour tout le reste… Vous aussi, vous avez su faire preuve de pédagogie, rester calme, et clarifier des concepts importants auprès de votre direction générale et des métiers ? N’hésitez pas à le partager avec la communauté ATOUT DSI ! Ajouter à mes favoris
