Você pode escrever especificações técnicas perfeitas, mas de que adianta se o desenvolvedor está chorando?

Um proprietário de produto esférico está trabalhando em uma galáxia muito, muito distante. Ele escreve notas fluentemente em um guardanapo e silenciosamente as entrega aos desenvolvedores. E logo ele recebe um produto acabado que atende 100% às suas expectativas. Mesmo que este produto seja um serviço de plataforma cruzada complexo com blackjack e adaptabilidade.



Isso é possível na prática?



“Não, irmão, você não pode nos enganar! Os termos de referência devem ser escritos longa e meticulosamente ”, dizem os idosos de cabelos grisalhos. "TK é sério!" - ecoam os Juns de boca amarela. “Minha esposa me deixou por causa de uma curta atribuição técnica”, admite um analista de negócios experiente.



Deixe-me discordar.



Escrever um TK não precisa ser demorado. Além disso, bons termos de referência são mais fáceis de escrever do que maus. Se você conhece alguns truques, é claro. Eu vou te contar sobre isso hoje. No entanto, em vez de guardanapos, ainda recomendo o uso de confluência .

O que há de errado?

Tenho escrito problemas para desenvolvedores há mais de 11 anos. Neles foram feitos aplicativos, jogos, serviços web, sistemas de CRM, plataformas de treinamento e outros produtos. Durante esse tempo, passei de escrever documentos de design de 200 páginas a termos de referência lacônicos em várias etapas. E, claro, ele preencheu todas as saliências possíveis.



Ano após ano, em diferentes empresas, observei como os produtos, os designers de jogos e os profissionais de marketing definem as tarefas. E quais são as consequências das várias "características" do design dessas tarefas. Como o início do sprint é alterado em uma semana, descobrindo o que exatamente o cliente deseja. Como em pânico, eles corrigem a funcionalidade que acabou de ser introduzida no produto. A rapidez com que a pontuação do aplicativo é eliminada devido a casos não contabilizados. Como as vendas caem e os usuários leais vão embora. Como os desenvolvedores se cansam quando precisam mexer em tarefas problemáticas.



Tenho a impressão de que muitos daqueles que definem tarefas de desenvolvimento não sabem como fazê-lo bem . E a própria questão da qualidade do TK está fora do foco de atenção: eles dizem, eles escreveram a tarefa e as normas, eles não vão descobrir, ou o quê? Além disso, sempre há coisas mais interessantes para fazer: discutir novas hipóteses, reuniões, intervalos para o café. Como resultado, todos sofrem - clientes, desenvolvedores e negócios.

Existem dois extremos ao escrever TK

Quanto maior o produto em que você está trabalhando, maior será o custo de um erro e mais importante será a qualidade da especificação técnica (obrigado, boné!). Portanto, ambas as opções não são adequadas se você estiver fazendo algo mais sério do que uma página de destino. Em produtos grandes e competitivos , a escrita TK deve ser rápida, inteligente, rock and roll . Vamos ver como chegar lá.

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. O CT deve agradar ao líder da equipe
   
   , o que significa que não requer rituais e explicações especiais para ser transferido para o desenvolvimento. Por exemplo, se um produto concluiu um trabalho técnico e foi atropelado por um ônibus ali mesmo, no escritório, isso não deve impedi-lo de fazer o trabalho técnico da melhor maneira possível.

É difícil atender a todos esses requisitos? De modo nenhum.



Pelo contrário, se você se lembrar deles, então não será capaz de escrever TK francamente ruim. Porque todos esses requisitos se resumem em apenas uma coisa - cuidar das pessoas que interagem com este TK.

Meu formato TK

Este formato é uma mistura bastante livre de história do usuário + definição de pronto .



Surgiu como resultado de muitos anos de evolução: cada vez que via um problema sistemático, mudava o formato do meu TK para que esse problema não surgisse no futuro. O resultado é um formato lacônico e visualmente limpo que até mesmo junho pode facilmente pegar. Além disso, atende aos requisitos descritos acima.



É assim que uma história típica se parece em meu TK:







E não importa o quão grande e complexo seja o produto que estamos desenvolvendo, qualquer TK consistirá em histórias tão simples (seu número só aumentará).





Importante: as histórias não devem descrever funcionalidades muito grandes (por exemplo, várias telas) ou muito pequenas (por exemplo, um botão). Normalmente, uma história é um recurso ou mecânica de produto. Por exemplo, uma história pode descrever completamente o registro de um novo usuário. Para definir uma tarefa para o layout de uma nova página de destino, como regra, também preciso de uma história.



Se a especificação técnica for grande e significativa, então, antes da lista de histórias, escrevo brevemente: por que estamos fazendo isso e que resultados queremos alcançar . Apenas para que os desenvolvedores tenham uma visão geral.

Em geral, acontece algo assim:

Exemplo

Ok, para entender como isso funciona - vamos dividir um produto nessas histórias. Por exemplo, decidimos fazer um aplicativo chamado "inicialização neural". Nele, a rede neural vai realizar conversas íntimas com produtos que não tiveram um dia (e não têm amigos).



Para simplificar, supomos que já temos uma rede neural treinada e precisamos fazer uma interface para ela na forma de um aplicativo.



Provavelmente, o TK consistirá nas seguintes linhas:

1. Autorização do usuário
2. Perfil de usuário
3. Tela de comunicação com o neuroboot
4. Tela "Catálogo Neuroboot"
5. Tela de perfil e configurações
6. Popup de pagamento
7. Conexão analítica

Resta pintar cada história (no formato acima) e enviá-la para o desenvolvimento. Eu disse que seria fácil.

---

Hack de vida complicado

Existem várias técnicas que me ajudam a trabalhar em um produto todos os dias. Aqui estão aqueles que se relacionam a escrever termos de referência.

Hack de vida nº 1: detalhe iterativamente

Agora, eu não escrevo especificações técnicas - elas próprias, em segundo plano, aparecem no processo de trabalho. Quando uma nova tarefa aparece, eu imediatamente descubro: quais subtarefas são necessárias para fazer isso? E então eu corrijo cada subtarefa no formato da história (apenas o nome, os detalhes virão depois).



Assim, eu imediatamente tenho um termo de referência generalizado pronto. Resta apenas detalhar a história na medida em que será possível dar a atribuição técnica para o desenvolvimento.



O detalhamento também fica em segundo plano: enquanto estou pesquisando e pensando nos detalhes, imediatamente faço anotações dentro das linhas correspondentes. Em vez de design, insiro protótipos do NinjaMock .



Essa abordagem acelera significativamente o trabalho. Além disso, permite que você não perca a visão geral e não se preocupe com os detalhes com antecedência.

Hack de vida nº 2: não trabalhando com gênios

Existia um filme tão antigo em que o gênio realizava desejos da pior maneira possível.



Claro, um desenvolvedor são não procurará especificamente uma oportunidade de causar danos. Mas às vezes as pessoas não se importam com o que estão trabalhando. Em seguida, eles realizam a tarefa "como está escrita", sem realmente investigar por que ela é necessária. Periodicamente, isso resultará em arquivos grandes e pequenos. Bem, sim, a produção estabeleceu ... mas ninguém prescreveu na tarefa o que precisa ser verificado - se tal implementação quebraria todo o resto.



Não vou falar sobre terceirização, mas essa abordagem não é aceitável no produto. Um bom desenvolvedor está construindo um templo, não apenas colocando tijolos. Ou seja, ele vê o quadro geral e investiga o que está acontecendo. Esses caras costumam oferecer soluções alternativas e avisar sobre as próprias armadilhas.



Portanto, se você quer que seu TK seja feito da melhor maneira possível, então às vezes você precisa melhorar não o TK, mas a cultura de desenvolvimento na equipe. Em geral, essa é uma tarefa do PM, mas o produto também pode influenciar a situação. Principalmente se a equipe confiar nele (graças às suas especificações técnicas bem pensadas e bem elaboradas, por exemplo).

Life hack # 3: Separe a atribuição técnica da documentação

Os termos de referência respondem à pergunta "o que precisa ser feito?" E a documentação - para a pergunta "como é feito / como funciona?" O TK é escrito antes da implementação da tarefa e a documentação é escrita depois.



Se eu precisar reorganizar o gabinete, vou escrever uma tarefa no espírito de “reorganizar a partir daqui -> aqui”. Mas não vou desenhar a planta arquitetônica da casa em que há um guarda-roupa.



Às vezes há uma opinião de que o TK deve ser escrito de forma que seja , por assim dizer, ao mesmo tempo, uma documentação . Esta é uma teoria perniciosa. A documentação completa ainda não funcionará, porque não se sabe com antecedência como exatamente os termos de referência serão implementados. Além disso, os desenvolvedores precisam de espaço para manobra, o que a documentação não fornece. E o principal é escrever tal TK muitas vezes mais tempo e se tornará complicado.



Existem diferentes produtos e diferentes startups. Alguém pode passar sem documentação. Mas se você ainda precisa de documentação, contrate um junho que irá descrever a funcionalidade em detalhes após sua implementação. Você não precisa de habilidades especiais para descrever a funcionalidade existente, mas economizará tempo e nervos de funcionários habilidosos - desenvolvedores de produtos e desenvolvedores.

Hack de vida nº 4: Aprenda a programar

Uma observação puramente empírica: os produtos que sabem programar são melhores na formulação de tarefas. Além disso, não é necessário se tornar um operador backend sênior, basta dominar qualquer linguagem de programação e compreender a essência do pensamento algorítmico.



Em certa época, eu ainda estava codificando incontrolavelmente no Spectrum ctônico e, em meus anos de estudante, até tive que escrever drivers no Assembler. Ou seja, estou familiarizado com programação em primeira mão - e isso, é claro, ajuda a encontrar uma linguagem comum com os desenvolvedores.

Life hack # 5: pensando muito, escrevendo um pouco

Os maiores problemas surgem sempre com tarefas que o próprio cliente não entende totalmente. Por exemplo, ele precisa de um novo relatório na área administrativa, mas não entende direito como esse relatório será formado. Tipo, vocês programadores vão descobrir. Não, não funciona assim.



A única maneira de escrever um bom problema que é feito da maneira certa é entendendo. Idealmente, entenda o problema o suficiente para que você possa fazê-lo sozinho ... se você souber como programar.



Mas quando você descobriu - não precisa despejar todas as informações encontradas no TK. É apenas uma compreensão profunda da tarefa que permite descartar coisas desnecessárias e escrever apenas o que importa.

---

PS TK é um meio, não um fim. Portanto, às vezes o melhor TK é sua ausência. Algum dia eu contarei como lancei alguns produtos sem nenhuma especificação técnica.



PPS Se você tem seu próprio formato de termos de referência ou hacks de vida ao escrevê-los - por favor, compartilhe nos comentários.