Não há nada funcional sobre specs funcionais #

Não escreva um documento de especificações funcionais #

Esses documentos de projeto geralmente acabam tendo quase nada a ver com o produto finalizado. Aqui está o porquê:

Especificações funcionais são fantasias #

Elas não refletem a realidade. Um aplicativo não é real até que os construtores estejam construindo, os designers estejam desenhando, e as pessoas estejam usando. Especificações funcionais são apenas palavras no papel.

Especificações funcionais são sobre apaziguamento #

Elas são sobre fazer todos se sentirem envolvidos e felizes o que, embora caloroso e fofinho, não é tão útil. Elas nunca são sobre fazer escolhas difíceis e expor custos, coisas que precisam acontecer para construir um ótimo aplicativo.

Especificações funcionais apenas levam a uma ilusão de acordo #

Um grupo de pessoas concordando em parágrafos de texto não é um verdadeiro acordo. Todos podem estar lendo a mesma coisa, mas estão pensando algo diferente. Isso inevitavelmente aparece mais tarde: “Espera, isso não foi o que eu tinha em mente.” “Hã? Não foi assim que descrevemos.” “Foi sim e todos concordamos com isso — você até deu sua aprovação.” Você sabe como é.

Especificações funcionais te forçam a fazer as decisões mais importantes quando você tem menos informações #

Você sabe menos sobre algo quando começa a construí-lo. Quanto mais você o constrói, mais você o usa, mais você o conhece. É quando você deve estar tomando decisões — quando você tem mais informações, não menos.

Especificações funcionais levam ao excesso de recursos #

Não há resistência durante a fase de especificação. Não há custo para escrever algo e adicionar outro bullet point. Você pode agradar alguém que é um incômodo adicionando o recurso preferido dele. E então você acaba projetando para esses bullet points, não para humanos. E é assim que você acaba com um site sobrecarregado que tem 30 abas no topo da tela.

Especificações funcionais não te deixam evoluir, mudar e reavaliar #

Uma funcionalidade é aprovada e acordada. Mesmo se você perceber durante o desenvolvimento que é uma má ideia, você está preso a ela. Especificações não lidam com a realidade de que, uma vez que você começa a construir algo, tudo muda.

Então, o que você deve fazer no lugar de uma especificação? Vá com uma alternativa mais breve que te mova em direção a algo real. Escreva uma história de uma página sobre o que o aplicativo precisa fazer. Use linguagem simples e faça rápido. Se levar mais de uma página para explicar, então é complexo demais. Esse processo não deve levar mais de um dia.

Então comece a construir a interface — a interface será a alternativa para a especificação funcional. Faça alguns esboços rápidos e simples no papel. Depois comece a codificá-lo em HTML. Ao contrário de parágrafos de texto que estão abertos a interpretações alternativas, designs de interface são um terreno comum no qual todos podem concordar.

A confusão desaparece quando todos começam a usar as mesmas telas. Construa uma interface que todos possam começar a olhar, usar, clicar e "sentir" antes de começar a se preocupar com o código de backend. Coloque-se o máximo possível na frente da experiência do cliente.

Esqueça as especificações fixas. Elas te forçam a fazer grandes decisões-chave muito cedo no processo. Contorne a fase de especificação e você manterá a mudança barata e permanecerá flexível.

Especificações Inúteis #

Uma "especificação" é quase inútil. Eu nunca vi uma especificação que fosse grande o suficiente para ser útil e precisa.

E eu vi muitos trabalhos totalmente ruins que foram baseados em especificações. É a pior maneira de escrever software, porque por definição significa que o software foi escrito para corresponder à teoria, não à realidade.

—Linus Torvalds, criador do Linux

Combata os bloqueadores #

Eu descobri que as pessoas insistindo em documentos extensivos de requisitos antes de começar qualquer design eram realmente "bloqueadores" tentando apenas desacelerar o processo (e geralmente pessoas sem nada a contribuir no design ou pensamento inovador).

Todo o nosso melhor trabalho foi feito com alguns conceitos em nossas cabeças sobre melhorar um site, fazendo um protótipo rápido (estático), mudando um pouco o design e depois construindo um protótipo ao vivo com dados reais. Depois de testar esse protótipo, geralmente tínhamos um projeto real em movimento e um bom resultado.

—Mark Gallagher, desenvolvedor de intranet corporativa