Toyota est reconnue comme l’organisation la plus efficace de la planète en dehors du corps humain, et l’une de ses philosophies est d’éviter toute documentation. Au lieu de faire un "processus" quand quelqu'un sur la chaîne de montage a besoin de plus de boulons, ils ont simplement 5 bacs de boulons sur leur étagère et quand l'un est vide, ils le sortent et quelqu'un passe toutes les heures. de derrière. Il n'y a pas besoin de documenter quoi que ce soit, le processus le fait pour vous.

Il y avait un article récent sur Quartz qui a parlé de l'attention d'Apple aux listes de contrôle.

Il s'avère que la clé de la créativité, de la rapidité et de l'adaptabilité d'Apple est, à ses yeux, l'exact opposé du type de créativité libre qu'on pourrait attendre. C'est une liste de contrôle ... une très longue.

Ce qui m'a fait réfléchir à ma philosophie concernant les listes de contrôle. Il y a beaucoup de problèmes avec les listes de contrôle. Ils deviennent obsolètes. Ils peuvent être longs et ennuyeux et répétitifs. Comme toutes les métriques, ils peuvent se concentrer sur les mauvaises choses. Mais toutes ces choses sont vraies pour sauter des listes de vérification aussi, non? Je veux dire la troisième fois que vous avez fait la même erreur, il est probablement temps d'admettre que suivre une liste de contrôle pourrait vous avoir permis de gagner du temps.

Mais les listes de contrôle ne sont bonnes que si elles s'appliquent et elles sont souvent mises à jour, et vous êtes toujours à la merci d'un être humain qui, admettons-le, n'est pas conçu pour être parfait tout le temps.

Problème du monde réel

Nous avons un standard Drupal installer nous commençons avec pour la plupart des clients qui sont sur Drupal. Cela inclut les modules, les paramètres, les utilisateurs par défaut et nos données de test par défaut. C'était une liste de contrôle, mais elle était toujours obsolète. Alors quelqu'un est entré et l'a rendu si précis que n'importe qui, même avec une connaissance limitée de Drupal, pouvait le faire, alors tous les gens de Drupal dans le magasin détestaient ça, alors nous avons éliminé tout. sur elle et seuls les développeurs seniors de Drupal pouvaient le suivre, alors nous avons commencé à le coder en dur dans Drush.

Drush signifie que toute personne ayant une expérience Drupal pourrait exécuter quelques lignes de code et que tout se passerait comme par magie. Pas plus "erreur humaine", c'est une liste de contrôle, mais au lieu d'un humain en désordre essayant de suivre une liste de contrôle, un ordinateur l'a suivi.

Le problème était que même les changements les plus simples nécessitaient un développeur et que chaque modification devait être testée et que, par conséquent, elle était tombée en panne assez rapidement.

Finalement, nous sommes tombés sur la solution évidente, qui est quelque chose de dur codé dans Drush, ce qui rend quelque peu difficile à changer.

Maintenant, nous avons simplement un site appelé "clone me" ou quelque chose comme ça et chaque fois que nous avons un nouveau client, nous le dupliquons. Changer le système impliquait un programmeur et beaucoup d’autres travaux, maintenant tout le monde avec le mot de passe de notre équipe peut aller changer quelque chose. Si un concepteur souhaite des données de test différentes, il les modifie et cela sera automatiquement dans notre prochain projet. Si un PM décide que nous avons besoin d'un autre utilisateur par défaut à des fins de formation, il en crée un et ce sera dans notre prochain projet.

"La première fois que vous faites quelque chose, faites-le simplement. La deuxième fois, faites-le et prenez des notes. La troisième fois, arrêtez-vous et voyez si c'est vraiment pareil. Si c'est le cas, il y aura probablement un 4ème et 5ème, et ainsi de suite. "- Gavin Andresen, CTO Bitcoin

Nous avons eu la chance d'avoir Gavin ici chez Gravity Switch pendant quelques années. Il a beaucoup contribué à notre culture et à notre code, mais sa sagesse quant au moment de "pirater" les choses et de les traiter est quelque chose qui a vraiment changé ma façon d'aborder la documentation.

Gavin nous a appris que le bon code est auto-documenté.

Les 10 commandements de la documentation

  1. Vous ne devez pas trop documenter - Si cela prend plus de temps pour documenter que pour faire, vous êtes trop documenté.
  2. Vous devez automatiser avant document - Retirez le facteur humain chaque fois que possible.
  3. Tu ne devras pas brouiller la même chose trois fois - Si tu as foiré ou que tu as dû trouver la même chose deux fois, il est temps de procéder à la procédure.
  4. Si cela échoue, faites-le échouer - Les choses les plus délicates sont les choses qui vous manquent le premier (et même le dixième) temps que vous les passez en revue. Si vous avez le choix entre créer un processus qui arrête la chaîne d’assemblage ou faire planter votre site en cas d’échec ou qui crée une légère erreur, choisissez toujours «démonter le site», car au moins vous rencontrerez le problème pour la première fois. .
  5. Tu mettras le processus sur lequel on doit trébucher - parce qu'il faut le trouver.
  6. Possédez-le - Lorsque vous suivez un processus, gardez à l'esprit que votre travail consiste à produire le meilleur résultat. Il ne faut pas suivre le processus. Toujours aborder avec scepticisme et regarder de manière critique les résultats.
  7. Admettre quand il ne fonctionne pas - Parfois, les choses peuvent se ressembler, mais elles ne le sont pas. Dans notre monde, nous avons toujours besoin de données de test standard, mais le processus de création dans WordPress est complètement différent de celui de création dans Drupal. Nous avons donc besoin de processus complètement différents.
  8. Résolvez le problème rapidement - Si votre processus n'est pas à jour, ne vous contentez pas d'ignorer le problème et de choisir celui que vous souhaitez suivre. Fixez-le comme vous allez. Cela ne vous prendra que quelques minutes de plus à faire dans la plupart des cas et ces minutes deviendront des heures la prochaine fois que vous ou quelqu'un d'autre utiliserez le processus.
  9. Choisissez vos batailles - Steve Krug (le maître de la facilité d'utilisation) dit que vous devriez tester souvent. Trouvez votre plus gros problème. Faites le minimum de travail que vous pouvez faire pour qu’il ne soit plus votre plus gros problème, puis recommencez. Vous n'essayez pas de faire peu de bruit avec le système, vous essayez de faire en sorte que le système complet fonctionne mieux.
  10. Revisiter - Si vous avez utilisé un processus une douzaine de fois et que vous ne l'avez pas modifié, vous devriez réfléchir à la manière de le rendre plus efficace ou de l'automatiser.