La Toyota è nota come l'organizzazione più efficiente sul pianeta al di fuori del corpo umano, e una delle loro filosofie è di evitare la documentazione. Invece di fare un "processo" per quando qualcuno sulla catena di montaggio ha bisogno di più bulloni, ha semplicemente 5 cassetti di bulloni sullo scaffale e quando uno è vuoto lo spostano dallo scaffale e qualcuno arriva ogni ora e riempie tutti gli scaffali da dietro. Non è necessario documentare nulla, il processo lo fa per te.
C'era un recente articolo su Quartz che ha parlato dell'attenzione di Apple alle liste di controllo.
Si scopre che la chiave della creatività, della velocità e dell'adattabilità di Apple è, sulla sua superficie, l'esatto opposto del tipo di creatività a ruota libera che ci si potrebbe aspettare. È una lista di controllo ... molto lunga.
Il che mi ha fatto pensare a quale sia la mia filosofia sulle liste di controllo. C'è molto sbagliato con le liste di controllo. Non sono aggiornati. Possono essere lunghi, noiosi e ripetitivi. Come tutte le metriche, possono concentrarsi sulle cose sbagliate. Ma tutte queste cose valgono anche saltare le checklist, giusto? Intendo la terza volta che hai commesso lo stesso errore è probabilmente il momento di ammettere che seguire una lista di controllo potrebbe averti fatto risparmiare tempo.
Ma le liste di controllo sono valide solo se si applicano e sono aggiornate spesso, e tu sei ancora al capriccio di un umano che, ammettiamolo, non è costruito per essere perfetto tutto il tempo.
Abbiamo uno standard Drupal installazione che iniziamo con la maggior parte dei client su Drupal. Ciò include moduli, impostazioni, utenti predefiniti e i nostri dati di test predefiniti. Era una lista di controllo, ma era sempre obsoleto. Poi qualcuno è entrato e lo ha reso così specifico che chiunque, anche se con una conoscenza limitata di Drupal, poteva farlo, quindi tutti i duri Drupal del negozio lo odiavano, quindi l'abbiamo tolto, e quindi non potevamo allenare nessuno nuovo su di esso e solo gli sviluppatori di Drupal senior potevano seguirlo, quindi abbiamo iniziato a programmarlo Drush.
Drush significa che chiunque abbia esperienza con Drupal potrebbe eseguire un paio di righe di codice e tutto "accadrebbe" magicamente. Niente più "errore umano", è una lista di controllo, ma invece di un umano disordinato che cerca di seguire una lista di controllo, un computer l'ha seguito.
Il problema era che anche il cambiamento più semplice aveva bisogno di uno sviluppatore e ogni cambiamento doveva essere testato e così è crollato abbastanza rapidamente.
Alla fine ci siamo imbattuti nella soluzione ovvia, che è qualcosa di hard-coded in Drush, che ha reso un po 'difficile cambiare.
Ora abbiamo semplicemente un sito chiamato "clone me" o qualcosa del genere e ogni volta che abbiamo un nuovo client lo duplichiamo. Modificandolo era usato per coinvolgere un programmatore e molti altri lavori, ora chiunque abbia la password del nostro team può andare a cambiare qualcosa. Se un progettista vuole dati di test diversi, lo cambiano e sarà automaticamente nel nostro prossimo progetto. Se un PM decide che abbiamo bisogno di un altro utente predefinito per scopi di formazione, ne crea uno e sarà nel nostro prossimo progetto.
"La prima volta che fai qualcosa, fallo e basta. La seconda volta, fallo e prendi nota. La terza volta, fermati e vedi se è davvero la stessa cosa. Se è un processo fuori di esso perché ci sarà probabilmente un 4 °, 5 ° e così via. "- Gavin Andresen, CTO Bitcoin
Siamo stati abbastanza fortunati da avere Gavin qui a Gravity Switch per alcuni anni. Ha contribuito un po 'alla nostra cultura e al nostro codice, ma la sua saggezza su quando "hackerare" le cose e quando proceduralizzarle è qualcosa che è davvero cambiato nel modo in cui approccio la documentazione.
Gavin ci ha insegnato che un buon codice è auto-documentante.