11 règles de design réseau

Cet article est une traduction / adaptation en français du post de Greg Ferro sur Etherealmind.com.

Voici une approche sur la façon de concevoir une documentation de Design réseau. Le “monde” des réseaux est trop grand et varié pour n’avoir qu’un seul document pour couvrir plus d’un ou deux projets, mais voici quelques règles pour écrire un document de Design détaillé.

Les règles de Design
Règle n°1 — Une documentation de Design n’est pas un projet d’écriture créative.

• Oubliez l’école. Votre Français/Anglais ne sera pas noté par un professeur.
• C’est une déclaration de faits.
• Contentez-vous des faits, simplement les faits, oubliez le style.
• N’utilisez pas de mots fantaisistes.

Règle n°2 — Un Design n’est pas “Lu”, il est “utilisé”.

• La présentation importe moins que les faits et les données brutes.
  
• Il ne faut pas le lire comme un livre.
  
• Il ne sera pas publié.

Règle n°3 — Ne pas écrire un paragraphe quand une puce suffirait.

• Quand vous écrivez un paragraphe, vous perdez du temps. Utilisez des puces.
• Une puce vous fait vous concentrer sur la donnée, au lieu de penser à la grammaire.
• Être bref, induit moins d’erreur de compréhension.
• Vous passez moins de temps à écrire.

Règle n°4 — Une puce doit toujours être utilisée à la place des paragraphes.

• Regardez la règle d’avant.
• La seule exception est l’intro­duc­tion, vous y introduisez le contexte du projet.

Règle n°5 — Utilisez des schémas

• Un schéma est plus compréhensible qu’une puce, 90% du temps.
• Il est possible de construire un Design entier avec SEULEMENT des schémas.
• Les schémas seront utilisés plus souvent, et resterons sur les bureaux plus longtemps que les paragraphes d’un document.
• Utilisez des schémas.

Règle n°6 – Un bon tableau remplace encore plus de paragraphes.

• Vous pensez que vous avez besoin d’un paragraphe? utilisez un tableau.
• Les tableaux contiennent autant d’informations qu’un schéma.
• Plus pratique pour parler du “pourquoi”. Colonne de gauche= la raison, colonne de droite = comment, pourquoi, quoi.
• Les factures des équipements.

Règle n°7 — Ne pas utiliser d’adjectifs, c’est le boulot des avant-vente et des managers.

• Les seuls opinions à avoir sont ceux concernant la technologie.

Règle n°8 — Un design n’a pas besoin de plus de 4 niveaux de développements.

• Vraiment, pas plus de 4.
  
• Assurez-vous de comprendre pourquoi vous avez besoin de présenter un document avant de commencer.

Règle n°9 — Le processus du Design va du moins spécifique au plus spécifique.

• Ainsi, le plan d’affaires devient un Design de haut niveau et une conception détaillée devient un document opérationnel.
  
• Chacun partie contient de plus en plus d’informations spécifiques, et de moins en moins de mots.
  
• si ce que vous écrivez n’est pas plus explicite que le document précédent, ne pas l’écrire.

Règle n°10 — Utilisez les annexes pour les informations non pertinentes que vous jugez pertinent.

• Si vous avez le moindre doute quant à savoir si quelque chose est tout à fait pertinent, utilisez une annexe.
  
• mieux encore, utiliser une référence vers une ressource externe.

Règle n°11 — Un gros document est un échec

• Utiliser des références à des documents externes et des sites web
  
• On suppose que le lecteur sait quelque chose sur le sujet. Vous n’avez pas besoin de tout expliquer.
  
• Vous aurez besoin d’expliquer certaines choses, c’est le but de la conception.
  
• Vous n’êtes pas payés par page.
  
• Les gens ne sauront pas lire un long document.
  
• Vous perdez votre temps à écrire trop.
  
• Personne ne le lira.
  
• Ne pas tomber dans le piège des gros documents qui sont de meilleure qualité. Ils ne le sont pas.

C’est tout.

• Allez concevoir quelque chose.
  
• Faites les recherches et des essais.
  
• Toujours documenter avant, pendant et après. Surtout après.
  
• Faites court, simple et ce sera cool.

About Greg Ferro

Greg est un Architecte réseau et ingénieur sécurité / Designer / freelance travaillant au Royaume-Uni et à travaillé pour les revendeurs, les DotCom, Grandes entreprises et fournisseurs de services sur une grande variété de produits et de fournisseurs. Il a également co-organisateurs du Packet Pusher’s Podcast sur le réseau. C’est un blogeur très actif et très intéressant à lire. En savoir plus sur Greg: http://etherealmind.com/who-am-i/.

Benoit

Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.

More Posts - Website

Follow Me: