Documentation.

Commits de code assez fréquents.

Documentation.

Documentez vos idées, vos conceptions et votre code. Tous les pièges dont vous avez connaissance.

Documentation.

Documentez vos corrections de bogues 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ù les règles sont laxistes (les développeurs juniors ne peuvent tout simplement pas prendre la peine de soumettre des changements de documentation - les mises à jour de documentation pertinentes devraient être mandaté à côté de chaque fusion de succursales), l'examen par les pairs est manquant (les développeurs juniors / seniors sont donc pris au dépourvu lors de vagues de paresse compréhensible) et / ou la documentation est stockée séparément du code (elle peut donc être facilement perdue) , il est également important de se demander si l’environnement peut être modifié de manière à ce que ces problèmes ne le soient pas. Sinon, tous vos efforts pour rédiger de la documentation peuvent être vains.

Cela dit, je n'irais pas toujours jusqu'à appeler cela une responsabilité personnelle: en fin de compte, si les équipes sont mal gérées et / ou organisées , alors ce n'est pas votre responsabilité; dans le cas où vous passez à un nouvel emploi, je vous remettrais simplement ma documentation complète et je penserais "bien, si vous ne pouvez pas l'utiliser et le maintenir correctement, alors c'est votre faute ... maintenant bien chance ".

Cette ligne de pensée ne tient pas vraiment dans le cas du" touché par un bus ", cependant, où vous êtes peut-être en train de mettre en place de telles politiques mais ne l'avez pas encore fait encore. Pour ce scénario, je vous suggère simplement d'encourager la direction (et vos développeurs seniors) à commencer à prendre ces choses au sérieux dès que possible .

NE FAITES RIEN différemment. Travaillez comme si vous n'alliez PAS être «heurté par un bus» demain.

Le problème du «coup de 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 la direction devrait y réfléchir, mais je pense que c'est trop demander à des contributeurs individuels de travailler comme s'ils étaient littéralement partis demain. Si la direction est inconsciente des problèmes potentiels ici, 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 voudrez peut-être pour rappeler aux personnes clés et aux responsables de la nécessité d'avoir un renfort en cas d'urgence. Mais à une époque où les entreprises jettent des carrières «sous le bus» à un coup de tête dans un souci de profit à court terme, à quel point devriez-vous vraiment vous en soucier?

Des pratiques d'ingénierie diligentes résolvent de nombreux problèmes de " frappé par un dilemme de bus. Aller au-delà de cela au point d'être prêt pour une disparition immédiate et 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'un meilleur personnel, il n'est pas nécessaire pour lui de travailler comme s'il pouvait se vaporiser à tout moment.

Si vous travaillez en tant qu'entrepreneur, je dirais que c'est à 100% pour votre employeur. Dites-leur que la réalisation des objectifs qu’ils se sont fixés signifie que d’autres choses qui, selon vous, devraient être considérées comme des objectifs ne sont pas faites; demandez-leur s'ils veulent ajuster vos objectifs. Ils peuvent très bien vous dire de continuer tel quel, car votre temps coûte cher et ils veulent le meilleur rapport qualité-prix à court terme.

Si vous travaillez en tant qu'employé, vous pouvez avoir plus de marge de manœuvre pour planifier la succession (ou peut-être on s'attend à ce que vous le fassiez déjà). Néanmoins, parlez-en à votre chef d'équipe ou à votre responsable, car ils ont besoin de connaître le problème et comment vous êtes, et pensez que vous devriez le faire, passer votre temps.

Certaines choses pourraient aider à planifier pour 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 doit être résolu; se réunir, débattre de la meilleure façon de faire, arriver à une norme (consensuelle ou forcée d'en haut) et utiliser la norme, félicitations que la norme puisse figurer dans votre documentation pour le nouveau venu.
• Choses importantes qui sont communiquées par e-mail, des réunions ou des conversations occasionnelles doivent en faire une ressource partagée, allant d'un dossier de documents sur un lecteur partagé à un wiki. Il y a cette étrange croyance (du moins là où j'ai travaillé) que si quelque chose est envoyé par e-mail à tous les membres d'une équipe, cette équipe le saura pour toujours; cela ne tient pas compte du fait que la composition de l'équipe change et que toute formation (si elle se produit) ne transférera jamais toutes les connaissances, mais seulement un sous-ensemble de connaissances fréquemment utilisées.
• (éventuellement propre au logiciel) Documentez clairement les processus ou les décisions de conception contre-intuitifs, il est important d'identifier que le processus est reconnu comme contre-intuitif et pourquoi il l'est, peu importe. 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 le faire?"), Et vous avez expliqué pourquoi vous pensiez que c'était incorrect et ils confirmé que c'était ce qu'ils voulaient (encore mieux s'ils expliquaient pourquoi), alors les raisons pour lesquelles vous pensiez que c'était incorrect et l'explication de la raison pour laquelle c'était correct devraient être documentées. Que le logiciel fonctionne selon les spécifications ne suffira pas pour un remplacement, il aura la même question que vous.
• Pour tout problème que vous rencontrez qui prend beaucoup de temps / de recherche à résoudre , documentez le problème, les symptômes, le chemin raccourci vers la solution (c'est-à-dire: savoir ce que vous savez maintenant, quel a été le chemin le plus rapide entre l'identification des symptômes et une solution) et la solution. Les symptômes sont vraiment importants pour votre remplaçant, car ils les toucheront avant qu'ils ne comprennent complètement 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 plates-formes, où de nouvelles versions sont en cours publié mais non utilisé 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 ainsi l'existence même de la faille disparaîtra de la connaissance du public, jusqu'à ce qu'il soit presque impossible de trouver des informations à ce sujet.

Les vacances constituent un bon "entraînement" pour se préparer à des choses comme ça. Cela aide également à mesurer votre degré de préparation. Revenez au travail après 2-3 semaines et comptez les jours et les efforts consacrés au nettoyage de votre "backlog" - cela pourrait faire une approximation décente du "scénario de coup par bus".

Ceci est également utile outil si vous souhaitez vous améliorer. Analysez les éléments de l'arriéré que vous devez résoudre et demandez-vous ce qui pourrait être fait pour que cela puisse être fait par quelqu'un d'autre. Dans l'un des emplois précédents, cela m'a aidé à faire passer les efforts de "carnet de vacances" d'environ trois semaines à deux jours en moins d'un an.

• ^{Oh mon Dieu, je semble être le un seul ayant ces informations, j'ai besoin de les documenter pour les rendre disponibles pour toute l'équipe.
  Merde, personne ne peut résoudre ce bug à part moi, j'ai besoin de trouver et de former un gars de sauvegarde ...}

Ce qu'il faut garder à l'esprit, c'est que cela est généralement considéré comme une responsabilité de votre direction, donc tout ce que vous faites au-delà de ce qui est nécessaire est à volonté. Demandez-vous dans quelle mesure vous voulez combattre le facteur de bus et procédez en conséquence.

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

• ... pour que l'autre gars qui vérifie mes trucs depuis le dépôt n'a pas à me répondre pour essayer de comprendre code non maintenable
• ... afin que d'autres personnes qui consultent mes enregistrements dans le suivi des problèmes n'aient pas besoin de mon aide pour comprendre ce J'y pensais en travaillant dessus
• ... pour que d'autres personnes lisant mes pages wiki n'aient pas besoin de moi pour expliquer les choses qui y sont documentées
• ... pour que je puisse regarder comment les choses que j'ai faites grandissent et s'épanouissent, mènent leur propre vie

... afin que je puisse me concentrer sur de nouvelles trucs sans être distrait par les soucis de ce qui reste.

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

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 peser cela avec votre travail quotidien normal.

Hé, ils pourraient même décider que c'est un risque qui vaut la peine d'être pris. Mais, vraiment, 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 difficile que j'ai jamais apprise a été de ne pas répondre à ces questions. Mais poser la bonne question pour les amener, sans méfiance, à trouver la réponse par eux-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 de défaillance unique auquel le PO s'attaque.

Entreprise

Cela peut être une décision consciente ou le résultat d'une mauvaise planification, d'un processus ou d'une croissance de l'entreprise. Cela peut également être le résultat de l'inaction ou de l'incapacité de reconnaître et de combler le déficit de connaissances croissant.

Indépendamment de la façon dont, l'entreprise crée la situation où elle a une super dépendance envers un seul individu ou un petit groupe d'individus qui forment le noyau de leur base de connaissances. De nombreuses entreprises abordent ce problème en utilisant des programmes de mentorat, des formations croisées et le partage des connaissances formelles et informelles.

D'après mon expérience, celles qui réussissent le mieux dans ce domaine favorisent également une approche pédagogique. Je veux dire par là que l'on vous donne rarement une `` réponse '' à une question, mais plutôt une discussion et des questions pointues du ou des experts qui vous mènent sur la voie de l'apprentissage et d'élargissement de vos connaissances sur le produit, le processus, la technologie jouer.

Cela offre également une perspective et une perspective nouvelles à l'expert dans la discussion. L'enseignement peut en effet se faire dans les deux sens.

Employé

De manière générale, vous avez deux types d'employés différents qui se retrouvent à ce poste. Ce que j'appelle « The Go To » et « The Protector ».

« The Go To » est cet employé que la plupart des managers adorent. Il \ elle est celui que vous pouvez assigner à n'importe quelle tâche ou projet sans avoir à vous en soucier. Ce sont les personnes qui se taillent leur place dans l'entreprise et deviennent la personne de référence et plus que probablement celle 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 gardant leurs connaissances, ils assurent leur position, leur importance et leur avenir dans l'entreprise.

Les deux créent par inadvertance des points de défaillance uniques. ' Aller à ' en fournissant toujours la réponse rapide et le ' Le Protecteur ' en ne partageant aucune ou toutes les informations.

Donc Bref, toute la documentation dans le monde ne résoudra pas le problème sous-jacent d'un point de défaillance unique. Oui, c'est important et devrait faire partie de chaque plan de préparation aux BCP et aux catastrophes. Mais la documentation n'est pas vraiment un partage de connaissances dans le sens où quelqu'un devrait être capable d'intervenir et d'effectuer vos tâches professionnelles sans avoir à parcourir un document de 200 pages au préalable.

Ne répondez pas à la question; leur donner les moyens de répondre par eux-mêmes.

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

a) Nous utilisons un wiki pour la documentation. Pas des fichiers Microsoft Word ou des fichiers texte. Un wiki interrogeable, entièrement suivi des modifications, etc. (je recommanderais Confluence, mais Confluence v4 est un tel chien que je vous suggère de chercher ailleurs)

• Tout les processus répétitifs ou pouvant être délégués doivent être documentés.
• Les listes de contrôle «voici comment nous faisons _____» doivent être rédigées
• Les listes de contrôle sont très importantes pour constituer des équipes, car elles permettent aux processus de être fait par quiconque peut suivre la liste ...

b) Contrôle de version, évidemment

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

d) Commenter votre travail. C'est la chose la plus nuancée, et c'est tellement difficile à enseigner, mais en tant qu'entrepreneur / indépendant, vous pourrez peut-être comprendre ceci: les commentaires doivent expliquer votre processus de réflexion et le pourquoi de ce que vous faites. Les liens vers la documentation, Stack Overflow, etc. sont appropriés. Les paragraphes et pages de commentaires sont appropriés. Expliquer les choses que vous avez essayées et que vous n'avez PAS faites est approprié. L'un des plus gros problèmes du code est que la pensée et la sueur nécessaires pour faire fonctionner quelque chose dans un sens (par opposition à une autre) sont perdues. Il y a un livre, quelque chose comme "beau code" ou autre, qui contient une partie des blocs de commentaires dans une unité dans l'un des grands systèmes VCS ouverts ( Subversion ou Git, je pense). C'est beau parce qu'il raconte l'histoire. Voici ce que fait ce code. Voici comment cela fonctionne. Voici comment il est structuré. (J'avoue que ce bloc, si je me souviens bien, peut ne pas entrer dans la grande partie de la question «pourquoi».)

Un corollaire à ceci est: combien de personnes reviennent en arrière et éditent le code juste pour ajouter des commentaires? Nous devrions tous ... beaucoup. Mais en pratique, presque personne ne le fait.

Netflix a un système qu'ils appellent ChaosMonkey. Il «casse» ou émule essentiellement la rupture de certains systèmes au hasard.

Les employés peuvent être considérés comme des systèmes et un moyen d'imiter la rupture d'un employé est de lui donner des congés imprévus et imprévus. Le ChaosMonkey vous a dit d'aller regarder un film sans le dire à vos collègues. Pour le court terme, l'effet sur eux est le même que si vous aviez été heurté par un bus.

Ceci teste la robustesse de leurs systèmes et leur permet de repérer de nouvelles failles dans leurs systèmes qui auraient pu autrement passé inaperçu.

Cela pourrait faciliter le transfert des connaissances d'une manière circulaire et à peu près car un système plus robuste est susceptible de moins casser et aura moins de gros bogues qui nécessitent une attention permettant aux personnes en question d'être en mesure de se concentrer davantage sur comment le système fonctionne et pourquoi il fait ce qu'il fait plutôt que de simplement traquer des problèmes ennuyeux qui prennent un temps précieux d'échange de connaissances.

Depuis la rédaction de cette réponse, j'ai pris conscience de https: // www.fdic.gov/news/news/financial/1995/fil9552.html. Fondamentalement, la FDIC recommande aux banques d'imposer des vactions obligatoires et payées d'au moins 2 semaines consécutives aux employés clés de la banque. Le bien-être des employés est une considération secondaire. La principale considération est que cela obligera les banques à nommer quelqu'un d'autre pour prendre en charge les responsabilités de l'employé qui quitte. Si l'employé qui quitte son emploi détourne, le système s'effondrera sous la surveillance du remplaçant. Cela signifie également que la banque ne sera pas vulnérable à une attaque de bus.

Je commencerais par

1. Standardisation

   Ma dernière position avant mon courant utilisé pour exécuter une méthodologie de type ouest sauvage . Tout le monde a utilisé les outils qu'ils voulaient, ce qu'ils connaissaient. Ce qui importait, c'était que les projets soient livrés en bon état de fonctionnement et dans les délais. Cela a permis une maintenance de code horrible où un projet serait développé avec GWT comme couche de présentation et JUnit uniquement pour toutes sortes de tests unitaires et un autre développeur coincé avec des JSP brutes tandis qu'un autre apportait JSF dans le mélange. Tout le monde était enchaîné à leurs projets et partir en vacances était impensable pour beaucoup et sonnait le glas de la révision et de l'optimisation du code.

   J'ai proposé de normaliser un certain nombre de technologies et d'outils standard de l'industrie qui garantissaient que nous tous dormi dans la même direction du lit (SoapUI pour ws-testing, JSF pour le niveau Web et avec un succès modéré, Spring pour le traitement back-end et quelques autres). Et nous avons tous vécu heureux pour toujours. Découragez toute individualité en ce qui concerne les outils du métier qui créeront un fichier avec une extension propriétaire (ou au moins essayer de l'atténuer);

   Si quelqu'un a un outil préféré avec lequel il fait confiance, laissez-le le présenter au tribunal pour évaluation et éventuellement adoption à l'échelle de l'équipe. Vous auriez dû prendre sur vous de définir les normes avec vos outils. Les avantages sont évidents ici, tout le monde a utilisé les mêmes choses avec un niveau de confort acceptable, donc avec un document de conception décent, n'importe qui peut prendre la part de quelqu'un d'autre et passer à autre chose.

2. Revues régulières et obligatoires des codes / projets

   Ceci est une autre fonctionnalité de mon dernier concert. Nous nous sommes tous réunis une fois par semaine avec notre responsable lors d'une séance de groupe et avons discuté de l'état d'avancement des projets de chacun et soulevé des préoccupations et des défis. Nous avions tous, à un très haut niveau, une idée de ce sur quoi le prochain gars travaillait et parfois nous puissions donner des conseils et quelques lignes de code pour nous aider. Il n'y a pas eu d'isolement total

3. Esprit d'équipe

   Je sais que cela semble un peu banal et peut-être une évidence, mais un esprit d'équipe sain (et peut-être un peu de compétition) favorise le partage d'informations. L'inconvénient de l'environnement des cabines (en particulier les membres de l'équipe dans les cabines éloignées) est que les membres de l'équipe sont souvent trop éloignés de la vie professionnelle de l'autre qu'il est trop facile d'avoir une panne de communication. Il y a une meilleure communication et un meilleur partage d'informations lorsque les coéquipiers sont situés à proximité les uns des autres, de préférence dans un environnement de bureau ouvert avec peu de murs ou de cloisons. Les discussions et les frottements d'esprit auront lieu et se dérouleront plus librement, avec pour objectif de favoriser le partage d'informations.

4. De toute évidence, Document . C'est une vieille chanson. Je ne la chanterai plus

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

Wiki-How a un peu écrit sur comment créer un BCP et bien que je ne recommande pas réellement d'utiliser cette méthode pour votre entreprise, il fournit un bon aperçu de les processus et la réflexion nécessaires pour en créer un. En général, les BCP sont effectués selon des approches échelonnées en traitant les risques les plus importants, en se préparant d'abord à des scénarios plus probables et en abordant les préoccupations à moindre risque par la suite. Mais chaque entreprise y construit généralement BCP en fonction de ses propres besoins, donc le processus exact varie.

Le processus implique généralement:

• Identifier les zones de risque
• documenter les processus impliqués
• déterminer les réponses appropriées à divers scénarios
• Mettre en place des plans pour gérer les scénarios

Que ferais-je si je donnais un préavis de deux semaines?

J'ai fait un bref aperçu et j'ai commencé à enregistrer en vidéo mon écran et ma voix. Il comprenait:

1. Où dois-je tout conserver?
2. Des exemples de demandes en cours et où j'en suis dans le processus.
3. Des démonstrations de la façon dont pour effectuer certaines des tâches les plus uniques ou complexes au cas où une personne moins technique devrait gérer les choses à court terme.
4. Comment trouver des éléments dans la base de données que j'ai créée le premier jour pour gérer tous les petites choses (Lorsque vous commencez un emploi, vous découvrez vraiment ce que vous ne savez pas.).

Mon objectif, comme toujours, de quitter un emploi mieux que je ne l'ai trouvé. J'essaie de ne pas laisser la direction fixer mes normes. Leur travail est de se préoccuper des résultats finaux, mon travail est de savoir comment faire mon travail mieux qu'eux. Je ne suis pas simplement un jeu de mains supplémentaire.

Nos règles de tous les jours contre les personnes qui emportent leurs connaissances dans la tombe:

• Si quelqu'un écrit un script / une routine, quelqu'un d'autre doit être le premier à utiliser en production.
• Si quelqu'un déploie de nouveaux systèmes, personne ne les utilisera ou ne les prendra en charge tant qu'il ne pourra pas rechercher tous les identifiants d'accès nécessaires par lui-même, seul, la nuit, sans demander à quelqu'un d'autre.
• Il existe également une "configuration en tant que code" et des tests automatisés pour les logiciels. Cela permet à votre successeur de rétroconcevoir votre travail.

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

Nous l'appelons " connaissance des arcanes " (uniquement stockée dans la tête de quelqu'un), et tout le monde refuse d'agir en conséquence.

Évidemment, cela ne fonctionne pas entre les sujets techniques et non techniques. Mais nous ne nous attendons pas non plus à ce que les techniciens soient en mesure de prendre en charge les calculs financiers du service comptable. Ainsi, même notre service de comptabilité pourrait prendre "les connaissances 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 établie par les propriétaires de l'entreprise. C'est leur responsabilité de mettre cela en place. Vous pouvez cependant être le seul à avoir les connaissances nécessaires pour les informer que cela est nécessaire.

• Travaillez selon les normes bien établies établies pour votre domaine ou organisation.
• Documentez ce qui
• Documentez en détail si vous vous écartez des normes bien établies et pourquoi vous l'avez fait
• Documentez comment documenter pour votre organisation.
• Si vous sont au sommet d'une chaîne d'administration système et détiennent les comptes root / super utilisateur; créer un compte avec la cote de sécurité la plus élevée possible. Générez un long mot de passe aléatoire pour cela. 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 à de mauvaises conditions et conserver ce mot de passe. Dites-leur de le stocker en toute sécurité, hors site et son utilisation (cela peut vous donner le statut de super utilisateur sur le réseau en cas d'absence ou pour d'autres raisons qui pourraient s'appliquer).