Testando 1, 2, 3 (e mais vezes)
Precisamos validar nossas ideias e produtos. Coloque à prova, sem medo de falhar nessa etapa.
O papel aceita tudo.
O Excel, Google Sheets e o Word também.
Em outras palavras, os documentos não provam nada. Você pode escrever o que quiser neles. Planejamentos precisam ser revistos diversas vezes. Previsões nunca acertam. Um checklist será sempre incompleto.
A única coisa que nunca erra é a realidade, pois ela é 100% verdadeira.
O problema são os outros
Pensou em uma piada engraçada? Ela só vai ter graça se alguém rir.
A combinação de ingredientes faz sentido na receita? Então vamos preparar esse prato e dar para alguém provar.
O anúncio está super criativo e adequado ao briefing? Pena que o público não entendeu.
Na maioria das atividades, estamos fazendo algo para outras pessoas.
Então você precisa testar suas ideias, produtos e serviços com os outros.
A avaliação final não é sua, apesar de você ser o primeiro responsável com sua autocrítica.
Controlar a qualidade é achar erros
Por que o professor corrige as provas? Não seria mais fácil ele dar der para os alunos e elogiar seu esforço?
Seria mais fácil, mas não seria melhor.
A evolução dos alunos é feita em etapas complementares de educação e revisão. Questões erradas indicam necessidade de mais atenção ou de mais estudo.
Sem achar os pontos fracos, fica muito mais difícil evoluir. As falhas ficam ocultas e vamos colocando novas camadas de informação por cima, construindo sob uma base fraca.
O mesmo vale para a vida profissional.
No universo de desenvolvimento de produtos existe a figura do QA, Quality Analyst, ou analista de qualidade. Essa é a pessoa que testa todos os sistemas de forma metódica e profissional.
A parte que mais gosto é que esse cargo não é um "achador de defeitos". Essa pessoa existe para garantir a qualidade e por isso o cargo de QA também se refere a Quality Assurance.
Mas por que a gente pede para outra pessoa conferir? Por que não é o próprio aluno que corrige a prova, ou o próprio desenvolvedor que verifica seu código?
Porque é muito difícil ver os próprios problemas. Ou porque a gente quer tanto que dê certo que não vê com olhos críticos.
Teste antes do uso em massa
Fail Fast, Fail Often.
Move fast and break things.
O mundo da inovação está cheio de frases que acabam se tornando clichês. Ou, pior ainda, produzem soluções que quebram e falham quando você mais precisa.
Se você não quer que um produto se transforme em um erro monumental, precisa testar seus limites de forma controlada, com um público mínimo ou com seu próprio time.
No software temos diversos releases em um ciclo de desenvolvimento: alpha, beta, release candidate etc.
O mesmo acontece com hardware. Aviões passam por túneis de vento. Carros são avaliados por empresas que as certificam em questões de segurança contra colisões. A Apple tem um laboratório especializado em testar os limites de seus equipamentos.
Outra indústria que faz isso é a dos filmes. Versões preliminares são apresentadas durante a produção ou assim que os diretores acreditam que esteja pronto.
No livro "Creativity Inc" e neste artigo do Ed Catmull, que mostram os bastidores da Pixar, podemos ver como a crítica sincera e construtiva (ou até destrutiva) pode levar a resultados melhores. Na Pixar, todas as etapas da produção são avaliados por pares regularmente. Para questões mais complexas existe o "Brain trust", unidade especial com a liderança sênior.
Seu público final não deve ser o "testador" do seu produto. Deixe ele com a melhor função, que é tirar o máximo proveito.