Comment puis-je me préparer à me faire renverser par un bus ?

Documentation.

Engagements de code raisonnablement fréquents.

Documentation.

Documentez vos idées, vos conceptions et votre code. Tout getchas dont vous avez connaissance.

Documentation.

Documentez vos corrections de bugs expliquant quel était le problème et comment vous l'avez résolu, et pourquoi.

Et ai-je mentionné la documentation ? Si vous travaillez dans un environnement où la politique est laxiste (les développeurs débutants ne peuvent tout simplement pas se donner la peine de soumettre des modifications de la documentation - les mises à jour de la documentation pertinente doivent être mandées à chaque fusion de branche), où la révision par les pairs est absente (les développeurs débutants/supérieurs sont donc pris au dépourvu pendant des périodes de paresse compréhensible), et/ou où la documentation est stockée séparément du code (elle peut donc facilement être perdue), il est également important d'examiner si l'environnement peut être modifié pour que ces problèmes ne se reproduisent pas. Cela dit, je n'irais pas toujours jusqu'à dire que c'est une responsabilité personnelle : en fin de compte, si les équipes sont mal gérées et/ou mal organisées, ce n'est pas votre responsabilité ; si vous changez de poste, je vous remettrais simplement ma documentation complétée et je me dirais “eh bien, si vous ne pouvez pas l'utiliser et l'entretenir correctement, alors c'est votre faute… maintenant, bonne chance”.

Cette façon de penser ne tient pas vraiment dans le cas d'un “accident de bus”, cependant, où vous êtes peut-être en train de mettre en place de telles politiques mais n'avez pas encore tout à fait réussi. Pour ce scénario, je vous suggère simplement d'encourager la direction (et vos développeurs principaux) à commencer à prendre ces choses au sérieux _ le plus tôt possible_.

Ne faites RIEN de différent. Travaillez comme si vous n'alliez PAS vous faire “renverser par un bus” demain.

Le problème du “renversement par un bus” est un problème d'organisation et non quelque chose qui doit être explicitement abordé dans vos propres objectifs de travail.

Vos collègues et votre direction devraient y réfléchir, mais je pense que c'est trop attendre des contributeurs individuels qu'ils travaillent comme s'ils étaient littéralement partis demain. Si la direction n'est pas consciente des problèmes potentiels, cela signifie qu'elle est totalement déconnectée ou que vous n'êtes peut-être pas aussi indispensable que vous le pensiez.

Au mieux, si vous êtes généreux, vous pourriez rappeler aux personnes clés et aux responsables qu'il faut avoir des renforts en cas d'urgence. Mais à une époque où les entreprises jettent les carrières “sous le bus” sur un coup de tête au nom du profit à court terme, à quel point devriez-vous vous en soucier ?

Des pratiques d'ingénierie diligentes résolvent de nombreux problèmes du dilemme du “coup de bus”. Aller au-delà de cela au point d'être prêt à disparaître immédiatement et de façon permanente créera beaucoup de frais généraux pour le contributeur individuel. Il semble que l'environnement décrit par le PO pourrait bénéficier simplement de meilleures pratiques et d'une meilleure dotation en personnel, il n'est pas nécessaire qu'il travaille comme s'il pouvait s'évaporer à tout moment.

Si vous travaillez comme entrepreneur, je dirais que c'est votre employeur qui paie à 100 %. Dites-lui que la réalisation des objectifs qu'il vous a fixés signifie que d'autres choses que vous pensez devoir être considérées comme des objectifs ne sont pas faites ; demandez-lui s'il veut ajuster vos objectifs. Il se peut qu'il vous dise de continuer comme si de rien n'était, car votre temps est précieux et il veut en avoir le plus pour son argent à court terme. Si vous travaillez en tant qu'employé, vous avez peut-être une plus grande marge de manœuvre pour planifier votre succession (ou peut-être pensez-vous que vous le faites déjà). Néanmoins, parlez-en à votre chef d'équipe ou à votre manager, car ils doivent connaître le problème et savoir comment vous êtes, et pensez que vous devriez passer votre temps.

Quelques éléments de cette démarche pourraient vous aider à planifier la succession :

• Les processus quotidiens devraient être documentés dans une certaine mesure, mais il est probable que d'autres personnes de votre équipe suivent les mêmes processus et pourraient les enseigner à un nouveau venu. Si vous n'utilisez pas tous des processus similaires, c'est un problème actuel qui devrait être résolu ; réunissez-vous, débattez de la meilleure façon de procéder, établissez une norme (consensuelle ou imposée d'en haut) et utilisez cette norme, félicitations, cette norme peut figurer dans votre documentation pour le nouveau venu.
• Les choses importantes qui sont communiquées par courrier électronique, réunions ou conversations informelles doivent devenir une ressource partagée, qu'il s'agisse d'un dossier de documents sur un disque partagé ou d'un wiki. Il y a cette croyance étrange (du moins là où j'ai travaillé) que si quelque chose est envoyé par e-mail à tous les membres d'une équipe, alors pour toujours cette équipe connaîtra la chose ; cela ne prend pas en considération le fait que la composition de l'équipe change et que toute formation (si elle a lieu) ne transmettra jamais toutes les connaissances, seulement un sous-ensemble de connaissances fréquemment utilisées.
• (Peut-être spécifique à un logiciel) Documentez les processus ou les décisions de conception clairement contre-intuitifs, il est important d'identifier que le processus est reconnu comme étant contre-intuitif et pourquoi il l'est, quoi qu'il en soit. Par exemple, si votre client vous a demandé de faire quelque chose qui semble “incorrect” (“Je ne suis pas un expert du domaine, mais êtes-vous sûr de vouloir faire cela ?”), et que vous avez expliqué pourquoi vous pensiez que c'était incorrect et qu'il a confirmé que c'était ce qu'il voulait (encore mieux s'il a expliqué pourquoi), alors les raisons pour lesquelles vous pensiez que c'était incorrect et l'explication de pourquoi c'était correct devraient être documentées. Que le logiciel fonctionne selon les spécifications ne sera pas suffisant pour un remplacement, ils auront la même question que vous.
• Pour tout problème que vous rencontrez et dont la résolution demande beaucoup de temps et de recherche, documentez le problème, les symptômes, le chemin raccourci vers la solution (c'est-à-dire : savoir ce que vous savez maintenant, quel était le chemin le plus rapide de l'identification des symptômes à une solution), et la solution. Les symptômes sont vraiment importants pour votre remplacement, car ils les toucheront avant qu'ils ne saisissent pleinement le problème.
• Le point précédent est encore plus important en ce qui concerne les systèmes hérités, comme les bibliothèques ou les plateformes, où de nouvelles versions sont publiées mais non utilisées dans votre produit. Les problèmes que vous rencontrez dans votre version (ou pire encore, dans les interactions entre plusieurs systèmes hérités) peuvent être résolus dans les versions futures et donc l'existence même de la faille s'effacera de la connaissance du public, jusqu'à ce qu'il soit presque impossible de trouver des informations à son sujet.

Les vacances constituent une bonne “formation” pour se préparer à ce genre de choses. Elles permettent également de mesurer votre degré de préparation. Reprenez le travail après 2 ou 3 semaines et comptez les jours et les efforts consacrés au nettoyage de votre “arriéré” - cela pourrait faire une bonne approximation du “scénario du bus de nuit”.

Cela constitue également un outil utile si vous voulez vous améliorer. Analysez les points de l'arriéré que vous devez résoudre et demandez-vous ce qui pourrait être fait pour que cela soit fait par quelqu'un d'autre. Dans l'un de mes précédents emplois, cela m'a aidé à faire passer le “retard des vacances” d'environ trois semaines à deux jours en moins d'un an.

• Oh là là, il semble que je sois le seul à disposer de cette information, je dois la documenter pour la mettre à la disposition de toute l'équipe. La chose qu'il faut garder à l'esprit, c'est qu'en général, cela est considéré comme une responsabilité de votre direction , donc tout ce que vous faites au-delà de ce qui est nécessaire est à votre gré. Demandez-vous à quel point vous voulez combattre le facteur bus et procédez en conséquence.

Pour ma part, je veux être remplaçable…

• …pour que l'autre personne qui vérifie mes affaires dans le dépôt n'ait pas à me rappeler pour essayer de comprendre un code non maintenable
• … … de sorte que l'autre personne qui regarde mes enregistrements dans issue tracker n'ait pas besoin de mon aide pour comprendre ce à quoi je pensais en travaillant dessus
• … de sorte que l'autre personne qui lit mes pages wiki n'ait pas besoin de moi pour expliquer les choses documentées là
• . …pour que je puisse prendre plaisir à regarder comment [ les choses que j'ai faites ]&3 grandit et s'épanouit, en vivant sa propre vie

…pour que je puisse me concentrer sur la réalisation de nouvelles choses sans être distrait par les soucis de ce qui reste.

Demandez à votre équipe. Demandez à votre manager. Présentez-leur le problème exactement comme vous l'avez fait avec nous.

Donnez-leur des options. Documentation pour un futur développeur. Documentation pour eux. Remboursement de la dette technique. Tout ce à quoi vous pouvez penser. Donnez-leur des estimations de temps. Donnez-leur le choix. Laissez-les comparer avec votre travail quotidien habituel.

Hé, ils pourraient même décider que c'est un risque à prendre. Mais, en réalité, c'est à eux de décider.

Et, s'ils ont décidé de prendre le risque, alors votre esprit immortel devrait cesser de se sentir coupable.

Je voulais tendre la main et répondre à ces questions…

La leçon la plus dure que j'ai apprise est de ne pas répondre à ces questions. Mais de poser la bonne question pour les amener, sans méfiance, à trouver la réponse par elles-mêmes.

Une réponse donnée est différente d'une leçon apprise !

Explication

Il existe essentiellement deux scénarios différents qui créent le point d'échec unique auquel le PO s'attaque.

Entreprise

Cela peut être une décision consciente ou le résultat d'une mauvaise planification, d'un mauvais processus ou de la croissance de l'entreprise. Elle peut également être le résultat de l'inaction ou de l'incapacité à reconnaître et à combler le fossé croissant en matière de connaissances.

Quelle que soit la manière dont elle le fait, l'entreprise crée une situation de super-dépendance vis-à-vis d'un seul individu ou d'un petit groupe d'individus qui forment le noyau de sa base de connaissances. De nombreuses entreprises répondent à cette situation en utilisant des programmes de mentorat, de formation croisée et de partage des connaissances formel et informel.

D'après mon expérience, les entreprises qui réussissent le mieux dans ce domaine adoptent également une approche pédagogique. Je veux dire par là que vous recevez rarement une “réponse” à une question, mais plutôt une discussion et des questions pointues de la part de l'expert ou des experts qui vous mènent sur un chemin d'apprentissage et d'élargissement de vos connaissances sur le produit, le processus, la technologie en jeu.

Cela offre également un nouvel aperçu et une nouvelle perspective à l'expert dans cette discussion. L'enseignement peut en effet aller dans les deux sens.

Salarié

En général, vous avez deux types de salariés différents qui se retrouvent à ce poste. Ce que j'appelle “The Go To” et “The Protector”.

“The Go To” est l'employé que la plupart des managers aiment. C'est celui à qui vous pouvez confier n'importe quelle tâche ou projet sans avoir à vous en soucier. Ce sont ces personnes qui se taillent une place dans l'entreprise et deviennent le “go to person” et, plus que probablement, celui qui a les réponses

“The Protector” est cet employé qui a pris la décision de protéger son territoire. Ils ont le sentiment qu'en protégeant leurs connaissances, ils assurent leur position, leur importance et leur avenir dans l'entreprise.

Tous deux créent par inadvertance des points d'échec uniques. Le “Go To” en fournissant toujours une réponse rapide et le “Protector” en ne partageant aucune ou toutes les informations.

Donc, en un mot, toute la documentation du monde ne résoudra pas le problème sous-jacent d'un seul point de défaillance. Oui, elle est importante et devrait faire partie de chaque PCA et plan de préparation aux catastrophes. Mais la documentation n'est pas vraiment un partage de connaissances dans le sens où quelqu'un devrait pouvoir intervenir et effectuer vos tâches sans avoir à parcourir un document de 200 pages au préalable.

Ne répondez pas à la question ; donnez-lui les moyens de répondre par lui-même.

Voici ce que nous faisons là où je travaille :

a) Nous utilisons un wiki pour la documentation. Pas de fichiers Microsoft Word, ni de fichiers texte. (je recommanderais Confluence , mais Confluence v4 est un tel chien que je vous suggère de chercher ailleurs)

• Tout processus répétitif ou pouvant être délégué doit être documenté.
• Les listes de contrôle de “voici comment nous faisons ____” devraient être rédigées
• Les listes de contrôle sont très importantes pour la constitution d'équipes, car elles permettent à quiconque peut suivre la liste d'effectuer des processus…

b) Contrôle de version, évidemment

c) Système de suivi des cas/questions, évidemment

d) Commentaires sur votre travail. C'est la chose la plus nuancée, et c'est tellement difficile à enseigner, mais en tant que contractant/indépendant, vous pouvez peut-être le comprendre : Les commentaires doivent expliquer votre processus de réflexion et le pourquoi de ce que vous faites. Les liens vers la documentation, les débordements de piles, etc. sont appropriés. Les paragraphes et les pages de commentaires sont appropriés. Expliquer ce que vous avez essayé et ce que vous n'avez PAS fait est approprié. L'un des plus grands problèmes du code est que la réflexion et la sueur qui sont nécessaires pour faire fonctionner quelque chose d'une certaine manière (par opposition à une autre) sont perdues. Il y a un livre, quelque chose comme un “beau code” ou autre, qui a un morceau sur les blocs de commentaires d'une unité dans l'un des grands systèmes ouverts VCS Subversion ou Git , je pense). C'est beau parce que ça raconte l'histoire. Voici ce que fait ce code. Voici comment il fonctionne. Voici comment il est structuré. (J'avoue que ce bloc, si je me souviens bien, ne va peut-être pas jusqu'à la question du “pourquoi”)

Un corollaire à cela est : Combien de personnes reviennent en arrière et modifient le code juste pour ajouter des commentaires ? Nous devrions tous le faire… beaucoup. Mais en pratique, presque personne ne le fait.

Netflix a un système qu'ils appellent ChaosMonkey . Les employés peuvent être considérés comme des systèmes et une façon d'imiter la rupture d'un employé est de lui donner un congé sans préavis et non programmé. Le ChaosMonkey vous a dit d'aller voir un film sans le dire à vos collègues. À court terme, l'effet sur eux est le même que si vous aviez été heurté par un bus.

Cela permet de tester la robustesse de leurs systèmes et de repérer de nouvelles failles dans leurs systèmes qui auraient pu passer inaperçues autrement. Cela pourrait faciliter le transfert de connaissances d'une manière générale, car un système plus robuste est susceptible de moins tomber en panne et de présenter moins de bogues importants nécessitant une attention particulière, ce qui permet aux personnes concernées de se concentrer davantage sur le fonctionnement du système et sur les raisons pour lesquelles il fait ce qu'il fait, plutôt que de se contenter de rechercher des problèmes ennuyeux qui absorbent un temps précieux pour l'échange de connaissances. En gros, la FDIC recommande aux banques d'imposer des congés payés obligatoires d'au moins deux semaines consécutives aux employés clés des banques. Le bien-être des employés est une considération secondaire. La considération principale est que cela obligera les banques à nommer quelqu'un d'autre pour s'occuper des responsabilités de l'employé qui quitte la banque. Si l'employé qui quitte la banque détourne les fonds, le système s'effondrera sous la surveillance de son remplaçant. Cela signifie également que la banque ne sera pas vulnérable à une attaque de bus.

Je commencerais par

1. Normalisation

2. Examen régulier et obligatoire des codes/projets

3. Esprit d'équipe

4. Évidemment Document. C'est une vieille chanson. Je ne la chanterai plus.

La planification de cette activité fait partie d'un Plan de continuité des activités , alors qu'il s'agit de planifier des catastrophes plus importantes que le simple fait de se faire renverser par un bus, mais le processus met en place les éléments nécessaires pour se remettre de petits incidents comme le braconnage d'un acteur clé, à des problèmes plus importants comme une catastrophe qui détruit des bâtiments et les personnes qui les occupent.

Wiki-How has a so-so write up on comment créer un PCA et bien que je ne recommande pas vraiment d'utiliser cette méthode pour votre entreprise, elle donne un bon aperçu des processus et de la réflexion nécessaires pour en créer un. En général, les PCA sont élaborés selon des approches par étapes, en traitant les risques les plus importants, en préparant d'abord les scénarios les plus probables et en abordant ensuite les problèmes à moindre risque. Mais chaque entreprise élabore généralement son PCA en fonction de ses propres besoins, de sorte que le processus exact varie. Le processus comprend généralement :

• Identifier les zones de risque
• Documenter les processus impliqués
• Déterminer les réponses appropriées aux différents scénarios
• Adopter des plans pour traiter les scénarios

Nos règles quotidiennes contre les gens qui emportent la connaissance dans la tombe :

• Si quelqu'un écrit un script/routine, alors quelqu'un d'autre doit être le premier à l'utiliser en production.
• Si quelqu'un déploie de nouveaux systèmes, alors personne ne les utilisera ou ne les soutiendra que s'il peut vérifier tous les droits d'accès nécessaires par lui-même, seul, la nuit, sans demander à quelqu'un d'autre.
• Il y a aussi la “configuration en tant que code” et les tests automatisés pour les logiciels. Cela permet à votre successeur de faire de la rétro-ingénierie dans votre travail.

En effet, “les choses qui ne sont pas encore répertoriées/testées n'existent pas pour nous”. Seules les choses qui sont répertoriées sont fiables.

Nous l'appelons “ connaissance de l'arcane ”. (seulement stocké dans la tête de quelqu'un), et tout le monde refuse d'agir en conséquence.

De toute évidence, cela ne fonctionne pas entre les sujets techniques et non techniques. Mais nous n'attendons pas non plus des techniciens qu'ils puissent reprendre les calculs financiers du service comptable. Ainsi, même notre service comptable pourrait emporter “la connaissance dans la tombe”, si un seul comptable faisait ces calculs.

Parce qu'il y a une limite. Si l'équipe est trop petite, il y aura toujours quelqu'un qui sera heurté par un bus.

Les points ci-dessous doivent figurer dans votre description de travail qui vous a été remise et qui a été établie par les propriétaires de l'entreprise. C'est à eux qu'il incombe de les mettre en place. Il se peut toutefois que vous soyez le seul à avoir les connaissances nécessaires pour les informer de cette nécessité.

• Travailler dans le cadre de normes bien établies, établies pour votre domaine ou votre organisation.
• Documenter ce que vous faites.
• Documenter de manière très détaillée si vous vous écartez des normes bien établies et pourquoi vous l'avez fait.
• Documenter comment documenter pour votre organisation.
• Si vous êtes au sommet d'une chaîne d'administration du système et que vous détenez les comptes d'utilisateur root/super ; créer un compte qui a la plus haute habilitation de sécurité possible. Générez un mot de passe long et aléatoire pour ce compte. Imprimez-le sur papier. Signez le. Scellez-le dans une enveloppe et remettez-le au conseil d'administration et non au PDG. Parce qu'un PDG peut se séparer de l'entreprise en mauvais termes tout en conservant ce mot de passe. Dites-lui de le conserver en lieu sûr, hors site et de l'utiliser (il peut vous donner le statut de super-utilisateur sur le réseau en cas d'absence ou pour d'autres raisons).