A Toyota é bem conhecida como a organização mais eficiente do planeta, fora do corpo humano, e uma de suas filosofias é evitar a documentação. Em vez de fazer um “processo” para quando alguém na linha de montagem precisa de mais parafusos, eles simplesmente têm 5 caixas de parafusos na prateleira e quando um está vazio eles o movem da prateleira e alguém vem a cada hora e enche todas as prateleiras de trás. Não há necessidade de documentar nada, o processo faz isso por você.
Havia um artigo recente sobre Quartz que falou sobre a atenção da Apple para as listas de verificação.
Acontece que a chave para a criatividade, velocidade e adaptabilidade da Apple é, em sua superfície, exatamente o oposto do tipo de criatividade que se pode esperar. É uma lista de verificação ... muito longa.
O que me fez pensar sobre o que é minha filosofia sobre listas de verificação. Há muita coisa errada com as listas de verificação. Eles ficam desatualizados. Eles podem ser longos e chatos e repetitivos. Como todas as métricas, elas podem se concentrar nas coisas erradas. Mas todas essas coisas são verdadeiras de pular listas de verificação também, certo? Quero dizer, na terceira vez que você cometeu o mesmo erro, provavelmente é hora de admitir que seguir uma lista de verificação pode ter lhe poupado tempo.
Mas as listas de verificação só são boas se forem aplicadas e são atualizadas com frequência, e você ainda está à mercê de um humano que, vamos encarar isso, não é feito para ser perfeito o tempo todo.
Nós temos um padrão Drupal instalar começamos com a maioria dos clientes que estão no Drupal. Isso inclui módulos, configurações, usuários padrão e nossos dados de teste padrão. Costumava ser uma lista de verificação, mas estava sempre desatualizada. Então alguém entrou e tornou isso tão específico que qualquer um, mesmo com conhecimento limitado de Drupal, poderia fazê-lo, então todas as pessoas drupal na loja odiaram, então tiramos isso, e então não pudemos treinar ninguém novo e apenas os desenvolvedores do Drupal poderiam acompanhá-lo, então começamos a codificá-lo em Drush
Drush significa que qualquer um com experiência em Drupal poderia rodar algumas linhas de código e tudo iria “acontecer” magicamente. Não há mais "erro humano", é uma lista de verificação, mas em vez de um humano confuso tentando seguir uma lista de verificação, um computador a seguiu.
O problema era que mesmo a mudança mais simples precisava de um desenvolvedor e todas as mudanças tinham que ser testadas e, assim, elas desmoronavam rapidamente.
Eventualmente nos deparamos com a solução óbvia, que é algo embutido no Drush, o que dificultou muito a mudança.
Agora nós simplesmente temos um site chamado “clone me” ou algo parecido e sempre que temos um novo cliente nós apenas o duplicamos. Mudá-lo costumava envolver um programador e muitos outros trabalhos, agora qualquer um com a senha da nossa equipe pode mudar alguma coisa. Se um designer quiser dados de teste diferentes, ele será alterado e será automaticamente em nosso próximo projeto. Se um PM decidir que precisamos de outro usuário padrão para fins de treinamento, ele criará um e estará em nosso próximo projeto.
“A primeira vez que você faz algo, apenas faça. Na segunda vez, faça e faça anotações. Na terceira vez, pare e veja se é realmente o mesmo. Se for fazer um processo, provavelmente haverá um quarto, um quinto e assim por diante. ”- Gavin Andresen, CTO Bitcoin
Nós tivemos a sorte de ter Gavin aqui no Gravity Switch por alguns anos. Ele contribuiu bastante com nossa cultura e nosso código, mas a sua sabedoria sobre quando “hackear” as coisas e quando processuralizá-las é algo que realmente mudou a forma como abordo a documentação.
Gavin nos ensinou que um bom código é auto-documentado.