Si vous vous faites heurter par un bus, votre entreprise aurait-elle des ennuis?

Au travail, je suis le seul gars de l'informatique (je fais tout, et je le tape maintenant) depuis 10 ans. Si jamais je me fais frapper par un bus, ils seront totalement foutus. Je l'ai mentionné plusieurs fois aux gens de type gestion / président, mais ils m'ignorent. Dommage pour eux.

Que puis-je faire pour soulager leur douleur? (Ou devrais-je même m'en soucier?)

(Oui, cela devrait être un wiki communautaire, mais je ne vois pas la case à cocher ... je n'ai peut-être pas assez de représentants.)

Documentez le diable de tout.

Il y avait récemment un fil sur Slashdot sur le démarrage de la documentation, qui m'a inspiré pour écrire mes réflexions sur la documentation.

Mes points clés étaient:

Principe n ° 1: ce n'est jamais fait

La documentation est un effort continu qui sera toujours à la traîne de ce qui est en production. Les modifications sont apportées de manière ponctuelle, les choses sont déplacées, interrompues ou mises en service au hasard. La documentation ne rattrapera jamais.

Vous devez vendre aux personnes qui paient les factures la valeur du temps (et donc de l'argent) consacré à la mise à jour de la documentation en cours. Souvent, ces conversations se déroulent comme suit: "souvenez-vous quand j'ai dû passer $ TIME à comprendre comment $ THING a été cassé? Eh bien, quand j'ai fini, il y avait cette note technique détaillant $ THING, de sorte que le prochain gars à venir ne le fera pas doivent tout comprendre. "

Vous devez le faire, même si vous ne finirez jamais.

Principe n ° 2: la seule chose pire que l'absence de documentation est une mauvaise documentation

C'est plus un truisme qu'un principe. La documentation peut vous endormir dans le faux sens que quelque chose est dans un état connu et que si quelque chose ne va pas, vous pouvez donc commencer à le réparer.

Il est important de reconnaître ce problème.

Principe n ° 3: vous rédigez de la documentation pour votre successeur

Les chances sont de 95% de tout ce que vous documentez auquel vous n'aurez plus jamais à vous référer. La documentation est une collection de sagesse pour l'avenir, pas pour vous. Vous devez donc supposer que votre public ne sait pas ou peu de choses sur la façon dont les choses sont comme elles sont.

Et il y aura un successeur. Je ne sais pas pour vous, mais je ne prévois pas être dans ces environnements spécifiques pour le reste de ma vie. Les opportunités vont et viennent, et quand elles viennent, parfois vous allez. Mais la vie continue derrière vous, et plus vous pourrez améliorer la vie de votre successeur en douceur. Sinon, vous pourriez avoir une collection d'anciens clients qui disent tranquillement des choses peu flatteuses à votre sujet. J'aime dire que ce sont les 50 mêmes gars qui travaillent partout en TI à Ottawa parce que vous les rencontrez partout. Aider votre successeur pourrait vous ouvrir des portes à l'avenir.

Maintenant, dans une certaine mesure, il y a toujours un certain "blâme envers le gars précédent" lorsque des problèmes surviennent. Cela fait partie de l'entreprise. Je l'ai fait moi-même. Mais à plusieurs reprises, quand j'avais critiqué le gars précédent comme une sorte de crétin, j'ai appris autrement qu'il avait vraiment son acte ensemble et en savait plus sur ce qui se passait que moi à l'époque.

Principe # 4: "Pourquoi" est souvent plus important que "Comment"

Lorsqu'on regarde un système, la plupart d'entre nous commencent à penser comme pourquoi diable est-ce ainsi? Il y a presque toujours des raisons très spécifiques pour les choix de configuration effectués. Dans ces circonstances, le «pourquoi» dicte le «comment», et vous devez vous assurer que le lecteur comprend les problèmes spécifiques à résoudre lors de l'examen des restes de tabac de votre solution.

Principe # 5: Ça doit être facile ou tu ne le feras pas

Cela signifie que vous devez être très conscient de vos outils ainsi que de ceux qui vont utiliser vos outils.

La mise à jour doit être facile. Si vous devez faire un effort quelconque, vous trouverez des excuses pour éviter de le faire quand il est préférable de le faire, c'est-à-dire immédiatement après un changement.

Si vos outils ne sont pas faciles à utiliser pour les autres, ils ne les utiliseront pas. Cela peut être particulièrement invalidant dans un environnement d'équipe, car plus l'équipe est grande, plus vous rencontrerez de chances un membre de l'équipe qui n'aime pas votre choix d'outils.

Personnellement, j'aime un wiki pour les documents. Cependant le problème est qu'un wiki ne vous force pas sur une structure, donc la structure doit être imposée de l'extérieur. Cela mène toujours à un conflit quelque part car quelqu'un d'autre a une idée meilleure / différente.

Dans certains endroits, j'ai utilisé des documents Word et Visio "publiés" au format PDF, le "dernier" PDF faisant autorité. C'est bien car vous avez alors une collection que vous pouvez remettre à votre employeur / successeur. Les PDF, s'ils sont correctement datés, peuvent fournir un historique de ce qui s'est passé, bien qu'il ne soit pas facile de s'y retrouver. C'est mauvais en ce que je n'aime pas Word ou Visio et j'ai été obligé d'acquérir une compréhension de base de ces outils afin de communiquer efficacement les idées.

Mon employeur actuel joue avec l'idée de documents Word dans un portail Sharepoint. Il faudra juste voir jusqu'où on va

Bien sûr, vous devriez vous en soucier. Après tout, tout travail qui en vaut la peine est un travail qui vaut la peine d'être bien fait.

1.) Cela a déjà été dit mais il faut le répéter pour le réitérer. Document, document, document. Utilisez des feuilles de calcul Excel, du papier, de la plume et du parchemin si vous le devez. Plusieurs milliers de carnets d'hydromel comme dans le film "Se7en" si besoin est. Quoi qu'il en soit, présentez-le clairement, concis et facile à lire pour quiconque devra vous remplacer lorsque vous serez touché par un météore.

2.) Une fois que vous avez commencé à tout documenter, vous devriez être d'humeur à écrire. Il est temps de démarrer un projet parallèle détaillant les modifications des dernières années apportées aux serveurs. Commencez à construire un processus de gestion du changement, mais suivez-le historiquement. Assurez-vous de noter la fréquence à laquelle vous avez changé ces disques sur certains de ces serveurs capricieux. Combien ils coûtent, etc. Ceux-ci fournissent de bonnes mesures sur lesquelles vous pouvez compter de toute façon, même si ce météore vous manque et élimine le chien du voisin à la place.

3.) Mettre en œuvre un système de surveillance qui surveille et envoie par e-mail les échecs critiques. Qu'est-ce que tu dis? Vous en avez déjà un? Doux! Maintenant, documentez-le. Comment cela fonctionne, ce que vous surveillez, pourquoi vous le surveillez.

4.) Vous avez la responsabilité de le reprendre dans vos types de gestion. Et encore et encore. Autant de fois que vous le pouvez. Sois poli. Soyez respectueux, mais venez supporter ce que coûterait l'entreprise, si ce météore tombait et que vous disparaissiez.

Ce n'est pas une responsabilité dont vous pouvez vous débarrasser, c'est une exigence éthique de votre travail et de se conformer à la position que vous occupez en tant que proverbiale «gardienne et gardienne des clés du royaume».

Pense-y de cette façon. Si vous pouvez éviter et oublier de vous inquiéter à ce sujet et que vous vous sentez bien à le faire, alors pourquoi ne peignez-vous pas les partage de fichiers comptables pour les salaires de l'entreprise pour voir quoi et combien plus ces types de gestion font que vous? Pourquoi n'exploitez-vous pas des données d'entreprise confidentielles pour votre propre usage? Pourquoi ne lisez-vous pas les courriels des gens?

Autrement dit, (et j'espère) vous ne faites pas ces choses à cause d'un bon sens solide de la morale et de l'éthique. Vous savez, le vrai bien du mauvais genre de chose. Ainsi suit, si vous avez cela, alors vous savez qu'il est clairement de votre responsabilité de documenter et de préparer des contre-mesures contre le pire scénario.

Cela étant, votre voyage de vacances ininterrompu au travail et relaxant à Hawaï. :)

(Sans météore, c'est.)

Soyez prudent en traversant la rue, regardez dans les deux sens, assurez-vous qu'il n'y a pas de bus avec Keanu Reeves et Sandra Bullock à l'intérieur pour charger sur la route.

Si vous souhaitez réduire la courbe d'apprentissage de votre remplacement, la meilleure chose à faire est d'écrire une documentation sur la configuration et vos processus. La façon la plus simple de le faire est peut-être de mettre en place un système wiki quelque part et de continuer à y ajouter. Certains deviendront obsolètes, mais ce qui ne sera pas précieux.

Les nombreux articles ci-dessus concernant l'importance de la documentation sont parfaits, mais il y a un autre aspect à être "le gars" au travail que vous voulez surveiller.

Si vous êtes la seule personne qui sait tout gérer, les vacances / naissances / urgences sont difficiles à gérer, et vous ne pouvez jamais être promu ou apprendre d'autres postes dans l'entreprise (si cela vous intéresse). Si vous n'êtes pas en mesure de grandir et d'apprendre et d'étendre vos compétences, vous pouvez vous retrouver dans une position en bas de la ligne où vous recherchez un emploi, et votre CV montre que vous avez passé 10 ans en tant que programmeur COBOL / FORTRAN ou Administrateur OS \ 2 / Novell / NT.

La croissance et l'entraînement croisé sont importants pour le développement en tant qu'administrateur système. Au lieu d'être "le gars" dont dépend tout le réseau, soyez "le gars" qui est toujours prêt à montrer au nouveau gars quoi faire et qui est toujours intéressé à en savoir plus sur l'entreprise.

La clé ici est une documentation détaillée et complète. C'est quelque chose qui est essentiel non seulement si vous êtes frappé d'incapacité, mais si une personne junior entre et que vous souhaitez partir en vacances (ou passer à des pâturages plus verts). Avoir des documents et des références appropriés peut être extrêmement utile pour que quelqu'un d'autre se familiarise avec le réseau.

J'essaie TRÈS DIFFICILEMENT de m'assurer que nous n'avons pas de connaissances SPoF, y compris la mienne. Cette attitude est plus précieuse que toute connaissance locale que j'aurais pu garder pour moi.

J'ai repris ce poste (Sys Admin / Lead Dev) d'un gars qui avait sa propre façon de tout faire. Les 17 serveurs que nous avons sont tous configurés légèrement différents. Il y a tellement de procédures et de traitement manuel des problèmes ici et presque aucun n'a été documenté (la documentation comprenait à peu près une explication sur chaque ligne de chaque serveur et de son rôle). Cela m'a fait réévaluer beaucoup de processus au bureau. Chaque fois que j'apprends quelque chose, c'est ajouté au wiki. Je délègue également du travail sur le serveur à d'autres développeurs afin qu'ils puissent au moins apprendre des informations minimales sur les petits travaux.

La rédaction de la documentation est nulle, mais pensez à ce que ce serait de venir à votre poste sans aucune.

La documentation est une affaire énorme. Là où je suis, j'ai le problème opposé comme vous, nous avons récemment mis en place un nouveau système de suivi des commandes et des commandes (nous sommes une entreprise de gravure et de promotion) et j'ai le problème d'amener les gens à écrire dans le système les informations sur la personnalisation. Principalement des personnes de bas niveau, car le gestionnaire le fera pour ses commandes, car elle le faisait pour toutes les commandes, le plaçant dans une base de données d'accès TRÈS ANCIEN. Je veux donc me passer du papier, et c'est tout à fait possible dans notre entreprise, mais je ne peux tout simplement pas amener les gens à taper les informations de l'ordre de travail, bon sang.

Alors, continuez de vous brancher pour obtenir une autorisation. Ou si vous vous sentez bien, faites-le à votre rythme. Ce pourrait être une bonne chose pour votre avenir dans l'entreprise, sans parler de votre successeur.

re: dois-je m'en soucier?

À moins que votre bureau ne soit 100% dysfonctionnel, les gens vont remarquer que vous faites fonctionner les choses plus en douceur. Que vous vous souciez du bien-être de l'entreprise, et pas seulement de l'enfermement de votre «indispensable». L'entreprise qui compte sur vous pour ne jamais quitter / ne jamais obtenir une meilleure offre ne fonctionne pas très bien. C'est le travail de quelqu'un de remarquer que vous retenez ce genre de chose à l'entreprise.

Personnellement, j'aime travailler avec des gens qui documentent et veulent que le travail qu'ils ont terminé soit autonome et ne nécessite pas constamment leur implication. Lorsque vous documentez et mettez derrière vous ce que vous avez déjà fait , vous disposez de plus de temps pour travailler sur de futurs projets.

Nous avons essentiellement la même situation. C'est pourquoi le directeur m'a engagé pour ajouter un nœud de connaissances supplémentaire.

Mais honnêtement, ce n'est pas à vous de vous en soucier. Il appartient à la direction d'évaluer les risques et de les traiter.

J'ai trouvé que l' approche Getting Things Done aide à surmonter la barrière mentale initiale qui vous empêche de documenter correctement votre travail. Plutôt que de considérer la documentation comme une tâche monolithique qui vous empêchera de faire un "vrai" travail, subdivisez-la en morceaux de la taille d'une bouchée. Chaque fois que vous rencontrez une petite quantité d'informations que votre successeur devrait connaître, notez-les. Réservez ensuite une heure ou deux par semaine pour revoir, clarifier et classer vos connaissances.

• Documentation: Important
• Votre précieux travail: pas aussi important que vous le pensez

Ne documentez pas. Ne partagez pas vos connaissances avec les autres. En documentant les choses, vous vous rendez moins précieux. Vous serez moins payé. Votre bonus sera moindre. Votre sécurité d'emploi sera diminuée. Pourquoi voudriez-vous faire cela?

Le bon équilibre est celui où vous n'êtes pas dérangé inutilement pendant le sommeil ou les vacances. Sinon, vous vous dévalorisez.