De 10 bud af dokumentation

Toyota er kendt som den mest effektive organisation på planeten uden for menneskekroppen, og en af ​​deres filosofier er at undgå dokumentation. I stedet for at lave en "proces", når en person på samlebåndet har brug for flere bolte, har de simpelthen 5 bolte bolte på deres hylde, og når man er tom, flytter den den fra hylden og nogen kommer hver time og genopfylder alle hylderne fra bagsiden. Der er ingen grund til at dokumentere noget, processen gør det for dig.

Der var en Nylig artikel om kvarts som talte om Apples opmærksomhed på checklister.

Det viser sig, at nøglen til Apples kreativitet, hurtighed og tilpasningsevne er på overfladen, det nøjagtige modsatte af den slags frihjulende kreativitet man kunne forvente. Det er en tjekliste ... en rigtig lang en.

Som fik mig til at tænke på, hvad min filosofi om tjeklister er. Der er meget galt med tjeklister. De bliver forældede. De kan være lange og kedelige og gentagne. Ligesom alle målinger kan de fokusere på de forkerte ting. Men alle disse ting er sandt for at springe tjeklister også rigtigt? Jeg mener tredje gang du har lavet den samme fejl, det er nok tid til at indrømme, at efter en tjekliste måske har sparet dig tid.

Men tjeklister er kun gode, hvis de finder anvendelse, og de opdateres ofte, og du er stadig på indfaldet af et menneske, som lad os se det, er ikke bygget til at være perfekt hele tiden.

Virkelig verdens problem

Vi har en standard Drupal installere vi starter med for de fleste klienter, der er på Drupal. Dette omfatter moduler, indstillinger, standard brugere og vores standard testdata. Det plejede at være en tjekliste, men det var altid forældet. Så gik der ind og gjorde det så specifikt, at alle med begrænset viden om Drupal kunne gøre det, så alle de sværte Drupal-folk i butikken hadede det, så vi tog det ud, og da kunne vi ikke træne nogen ny på det og kun senior Drupal devs kunne følge det, så så begyndte vi at kodede det hårdt Drush.

Drush betyder, at alle med Drupal erfaring kunne køre et par linjer kode og alt ville "ske" magisk. Ikke mere "menneskelig fejl", det er en tjekliste, men i stedet for et rodet menneske, der forsøger at følge en tjekliste, fulgte en computer det.

Problemet med det var, at selv den enkleste forandring havde brug for en udvikler, og hver ændring skulle testes, og så faldt det fra hinanden ganske hurtigt.

Til sidst kom vi på den indlysende løsning, som er noget hardkodet i Drush, hvilket gjorde det lidt svært at ændre.

Nu har vi blot et websted kaldet "klone mig" eller sådan noget, og når vi har en ny klient, duplikerer vi bare det. Ændring det plejede at involvere en programmør og masser af andet arbejde, nu kan enhver med adgangskoden på vores team gå og ændre noget. Hvis en designer ønsker forskellige testdata, ændrer de det, og det vil automatisk være i vores næste projekt. Hvis en PM beslutter, at vi har brug for en anden standardbruger til træningsformål, opretter de en og det vil være i vores næste projekt.

Vi var heldige nok til at have Gavin her på Gravity Switch i et par år. Han bidrog ganske lidt til vores kultur og vores kode, men hans visdom om hvornår at "hack" ting og hvornår man skal procedurere dem er noget, der virkelig har ændret, hvordan jeg nærmer mig dokumentation.

Gavin lærte os, at god kode er selvdokumenterende.

De 10 bud af dokumentation

1. Du må ikke overdokumentere - Hvis det tager længere tid at dokumentere end at gøre, er du overdokumenteret.
2. Du skal automatisere før dokumentet - Tag den menneskelige faktor ud, når det er muligt.
3. Du skal ikke forstyrre det samme tre gange . Hvis du har rodet op eller skulle finde ud af det samme to gange, er det tid til at procedurere.
4. Hvis det kommer til at mislykkes, gør det svigtigt . Det sværeste er de ting, du savner den første (og endda den 10.) tid, du gennemgår dem. Hvis du har et valg mellem at skabe en proces, der vil stoppe samlebåndet eller nedbryde dit websted, hvis det fejler eller en, der vil skabe en lille fejl, skal du altid vælge "tag ned webstedet", fordi du i hvert fald vil se problemet første gang .
5. Du skal sætte processen, hvor man skal rejse over det - fordi den skal findes.
6. Eje det - Når du følger en proces, skal du huske på dit job er at producere det bedste resultat. Det er ikke at følge processen. Altid nærme det med skepsis og se kritisk på resultaterne.
7. Indrøm når det ikke virker - Sommetider kan tingene se ud, men de er ikke. I vores verden behøver vi altid standard testdata, men processen til at skabe det i WordPress er helt anderledes end at skabe det i Drupal, så vi har brug for helt forskellige processer.
8. Løs det hurtigt - Hvis din proces er forældet, skal du bare ignorere problemet og vinge det, eller vælg og vælg de dele, du vil følge. Løs det som du går. Det vil kun tage dig længere tid at gøre i de fleste tilfælde, og disse minutter bliver til timer næste gang du eller en anden bruger processen.
9. Vælg dine kampe - Steve Krug (mesteren om brugervenlighed) siger, at du skal teste ofte. Find dit største problem. Lav det mindste arbejde du kan gøre, så det ikke længere er dit største problem, og gentag derefter. Du forsøger ikke at få lidt kink ud af systemet, du forsøger at få hele systemet til at løbe bedre.
10. Revision - Hvis du har brugt en proces et dusin gange og ikke har ændret det, bør du tænke på, hvordan du kan gøre det mere effektivt, eller hvis du bare skal automatisere det.

• ← Hvordan man designer til mobile enheder, når du ikke har en
• Sådan optimeres din websteds destinationsside til mobil →