O Gerente de Produto é muitas vezes descrita como a “ponte entre negócios, design e tecnologia”. A ponte “entre design e Tecnologia” parte é especialmente crítica quando se trata de enviar um produto de qualidade: livre de bugs, pixel-perfeito e que leva em conta todos os casos scenarii e edge possíveis. Para ter certeza de que a ponte está funcionando bem, aqui estão várias maneiras que ela é tratada pela equipe de design:

• o designer envia um protótipo abrangente, que mostra todos os fluxos do produto. Infelizmente, isso muitas vezes vai demorar muito tempo e ainda vai perder alguns casos de ponta.
• o designer irá apenas enviar um protótipo que mostra os principais fluxos da característica, e permanece disponível para perguntas da equipe de desenvolvimento. Infelizmente, estes para a frente e para trás são altamente ineficientes (especialmente em uma configuração remota) e desperdiçam muito tempo de design e equipe de desenvolvimento.
• o designer, além do protótipo abrangente, escreve um documento de especificações adequadas que lista todos os casos scenarii e edge possíveis. O problema é que muitas vezes é uma perda de tempo, porque (1) o tempo precioso dos designers será melhor gasto projetando realmente outros recursos, não escrever um doc spec, e (2) eles nem sempre têm a mesma visão 360° do produto como os gerentes de produtos fazem, o que fará com que eles ignorem alguns cenários e casos extremos.

é por isso que as equipas de produtos maduros geralmente confiam a escrita das suas especificações de produtos aos gestores de produtos.mas como escrever as especificações do produto? Eu escrevi especificações de produto para os últimos 5 anos e eu encontrei um formato que é bem apreciado pelas equipes de software com quem eu trabalho. Neste post, estou compartilhando mais sobre minha metodologia e as ferramentas que estou usando para escrever especificações de produtos. Também estou descrevendo algumas limitações que estou enfrentando com as ferramentas que estou usando e algumas idéias de melhoria que tenho em mente.

Aqui estão os 5 tópicos principais que eu abordar em uma especificação de produto:

1. o Contexto e os objetivos
2. Arquitetura map
3. Épicos e histórias de Usuário
4. critérios de Aceitação
5. Design, conteúdo e traduções

o Contexto e os objetivos

Mesmo se as especificações de produto é voltado principalmente para as equipes de software, eles ainda gostaria de saber por que eles estão trabalhando no que eles estão trabalhando. Eu vim a entender que um dos principais motores de motivação para engenheiros de software é o impacto. A maioria deles sonha em trabalhar em recursos que são usados por milhões de usuários. Ficam entusiasmados quando ouvem que o novo UX que implementaram aumentou a retenção em 15%, por exemplo. Então é importante dar contexto sobre o recurso que eles estarão implementando:

• do que estamos falando? Que parte do produto? Sinta-se livre para adicionar qualquer história do recurso que é útil para entender a situação atual.qual é o problema actual? Nota: pode haver vários problemas para resolver.
• existe algum feedback qualitativo / verbatismos dos usuários a serem citados?
• existe algum dado (por exemplo, gráficos) a ser mostrado? Nesta seção, sinta-se livre para incluir quaisquer gráficos ou gráficos que tornem os dados mais compreensíveis.qual é a solução escolhida? (descreva-o simplesmente, em algumas frases)
• alguma outra solução foi considerada? Em caso afirmativo, por que razão foi posto de lado?já foi implementada alguma outra solução? Como tem corrido?quais são os objectivos ? Há algum KPI que estejamos a tentar impactar? Isso irá ajudar especialmente a equipe de software a entender se eles precisam implementar quaisquer novos rastreadores / tags / eventos para coletar adequadamente os dados. Vi equipas a sentirem-se tão motivadas pelo projecto que tomaram a iniciativa de montar painéis para seguir métricas em tempo real, sem que eu ou mais ninguém o pedisse.

mapa de arquitectura

Antes de entrar demasiado nos detalhes do recurso, é importante dar uma visão geral de alto nível sobre as alterações e o que permanece o mesmo no seu produto. E mesmo que você esteja trabalhando em um produto inteiramente novo, um mapa de arquitetura ainda será extremamente relevante para entender como o produto é estruturado.

“mapa de arquitetura” é a forma que eu chamo de representação de um diagrama de alto nível das características do produto (fluxos, telas e conteúdo) e como eles estão relacionados entre si. Algumas pessoas chamam-lhe “arquitetura de Informação”, “Mapa de fluxo”, “mapeamento UX”, etc.

Há nenhum oficial metodologia de como desenhar uma arquitetura de mapa. Em uma aplicação móvel, eu normalmente tento diferenciar fluxos, telas e” partes de uma tela “(ou” conteúdo em página”), usando uma forma diferente para cada um deles, como detalhado na legenda acima.

também pode ser útil jogar no código de cores. No exemplo acima, eu usei 3 cores e também Linha Sólida vs. pontilhada para explicar como a arquitetura de informação atual seria atualizada com o UX revamp da aplicação em que estávamos trabalhando. (verde: ficará como está, laranja: será atualizado, vermelho: será excluído; sólido: ficará no mesmo lugar, pontilhado: será movido para outro lugar). Dessa forma, os engenheiros tinham uma visão geral clara sobre qual parte da aplicação estaria sujeita a alterações.

outra dica para construir um mapa de arquitetura compreensível é distinguir claramente as várias partes da navegação, como feito abaixo com áreas separadas para cada uma delas.

Tendo uma arquitetura mapa será extremamente útil para o seu produto especificações; ele permitirá que você destaque qual parte do produto que você está falando em cada uma das suas histórias de usuário.

Qual a ferramenta que deverá usar para desenhar um mapa de arquitectura? Há toneladas deles disponíveis lá fora, meu favorito é caprichoso (porque é visualmente agradável e muito direto, não confuso com tantas características), mas eu também usei Draw.io no passado-o que é interessante porque está integrado com o Google Drive, por isso, se você trabalha com o Google Slides e o Google Docs, torna-o agradável de usar. Também está integrado com JIRA e confluência.

Se quiser aprender mais sobre mapas de arquitectura (do e don’TS, quais as ferramentas a usar, alguns exemplos, etc.), Toptal teve uma grande leitura: O guia abrangente de arquitetura de informação.

épicos e histórias de utilizador

quebrar e explicar todas as partes do seu produto pode rapidamente tornar-se bastante caótico. Escrevendo especificações de produtos ao longo dos últimos 5 anos, a melhor maneira que eu encontrei para manter as especificações organizadas e compreensíveis é quebrá-las de acordo com “histórias de usuário”.o que é uma história de utilizador? De acordo com modelagem Ágil, uma história de usuário é “uma definição de alto nível de um requisito, contendo apenas informações suficientes para que os desenvolvedores possam produzir uma estimativa razoável do esforço para implementá-lo.”

A idéia de histórias de usuários é colocar os usuários em primeiro lugar e evitar o uso exclusivo obscuro & vocabulário técnico ao discutir recursos. Como diz Atlassian: “depois de ler uma história de usuário, a equipe sabe por que eles estão construindo o que eles estão construindo e que valor ele cria.”

eles são destinados a construir um produto melhor, onde o usuário está no centro dos debates, ao contrário do bom e velho desenvolvimento de produtos Cachoeira.

Aqui como uma história de usuário deve ser formulado:

Como < tipo de usuário > Eu quero < algum objetivo > para que < alguma razão >.

Por exemplo, aqui está como nós poderíamos formular as histórias de usuário para as seguintes subparte da arquitetura mapa eu desenhei para um dos meus clientes:

• Usuário História #1: Como um funcionário com perfil de seção, eu quero editar o meu perfil para que eu possa atualizar minha foto, nome e sobrenome.
• história de Utilizador #2: Como um empregado na seção de perfil, eu quero acessar as configurações para que eu possa atualizar minha senha e atualizar as preferências de notificação.
• User Story #3: como um empregado na seção de perfil, eu quero acessar o chat para que eu possa dar feedback aos desenvolvedores do aplicativo

cabe ao gerente de produto decidir qual o nível de detalhes que eles querem cobrir na história do Usuário. Se quiséssemos, também poderíamos ir um nível mais profundo na história de usuário #2, por exemplo:

• história de usuário #2.a: Como um empregado na configuração, eu quero acessar a seção “Editar senha” para que eu possa atualizar minha senha
• história de usuário #2.b: Como um funcionário em “configurações”, eu quero acessar as preferências de notificações para que eu possa atualizar a frequência que eu receber cada tipo de notificações

Mas como você vê, isso é um pouco óbvio e redundante. Eu pessoalmente escolhi cobrir estes scenarii nos “critérios de aceitação” (ver seção seguinte) das histórias em questão.

para organizar histórias de usuários, muitas vezes usamos “épicos”. Em termos ágeis,” épicos ” são grandes quantidades de trabalho que podem ser divididos em pequenas histórias de usuários. Eu pessoalmente uso epics para agrupar histórias que fazem parte do mesmo tema ou área no produto. Por exemplo, eu escolhi agrupar as histórias acima como parte do épico “perfil”. Algumas pessoas escolhem formular épicos da mesma forma que histórias de usuários, com uma estrutura mais simples (e.g. “Como um usuário, eu quero acessar meu perfil”)

critérios de Aceitação

certifique-se de que o suficiente detalhe é adicionado a uma história de usuário, usamos “critérios de aceitação” (às vezes também chamado de “condições de satisfação”).

de acordo com LeadingAgile.com, ” critérios de aceitação “são” as condições que um produto de software deve satisfazer para ser aceito por um usuário, cliente, ou no caso de funcionalidade de nível de sistema, o sistema consumidor.”

nos critérios de aceitação, você deve listar todas as especificidades funcionais que não são claramente explicadas pela história do Usuário. Exemplo:

história de utilizador

como empregado na secção de perfil, quero editar o meu perfil para poder actualizar a minha fotografia, primeiro nome e último nome.

critérios de Aceitação

• uma vez que eu estou em editar perfil tela Quando eu clicar em editar nome do primeiro ícone, em Seguida, ele deve alternar para o modo de edição, foco na entrada e abrir o teclado (mesmo para o último nome)
• uma vez que eu estou em editar perfil tela Quando eu clique em o editar ícone de fotografia em Seguida, ele deve pedir-me para escolher entre a câmera e a biblioteca
• uma vez que eu estou editando meu primeiro nome, Quando eu clicar em “save”, em Seguida, ele deve redirecionar me para o modo de leitura e que eu deveria visitar um sucesso de notificação

, etc…

Acho que os critérios de aceitação como um lista de verificação que terá de ser preenchida para que o produto seja enviado. O formato dado/quando/então usado acima é uma boa maneira de ajudá-lo a formular seus critérios de aceitação, mas em alguns casos pode ser desafiador de usar.

Design, Conteúdo e traduções

tendo desenhos actualizados nas especificações do seu produto

até agora, não mencionei que Ferramenta estou a usar para escrever especificações. No passado, troquei entre o Google Docs, o Google Slides e a noção. Eu realmente gostei de usar a noção para todas as integrações legais que oferece (especialmente aquelas com incisão e Figma). Mas agora eu mudei completamente para o Google Docs: eu prefiro ter mais liberdade na forma como formato minhas especificações de produto. Também é mais conveniente usar os produtos Google quando você trabalha com parceiros externos ou clientes.

para se certificar de que a identidade visual do seu produto é justamente trazida à vida pela equipe de desenvolvimento, é importante dar-lhes acesso às telas mais atualizadas enviadas pelo(s) Seu (s) designer (ES). Mas como não há uma integração real entre o Google Docs e ferramentas de design como Figma, InVision ou Zeplin, eu costumava exportar telas e copiá-las para as especificações do meu produto.

isso rapidamente se tornaria um problema: designers iterate em suas telas em uma base diária, e mesmo quando tudo foi acordado em uma tela, ele pode mudar algumas semanas depois por causa de um componente específico que está sendo atualizado na biblioteca de design. Isto faria com que as minhas especificações estivessem desactualizadas a maior parte do tempo.

é por isso que hoje só estou usando o nome dos ecrãs. Por exemplo, se uma história de usuário sobre edição de perfil é sobre 2 telas que foram projetadas na Figma, eu só vou escrever “Figma screen name: edit-profile-1 e edit-profile-2”.

claro que isto não é ideal e obriga os programadores ou qualquer outra pessoa a ler as minhas especificações a alternarem entre várias ferramentas.

mas isso mostra que há hoje algo ineficiente na forma como escrevemos especificações de produto. O uso de vários produtos levanta questões de integração e sincronização. Como garantir que toda a informação necessária para construir um produto é visível em um único lugar, sem estar desatualizado? (Na verdade, isso não só se aplica a projetos, mas também a mapas de arquitetura e conteúdo).

→ se você também está experimentando este problema e encontrou uma solução, eu estaria interessado em obter o seu feedback!

dando fácil acesso ao conteúdo e traduções para evitar erros de Digitação

Quando você projetar telas com uma grande quantidade de conteúdo, é bom dar aos desenvolvedores a oportunidade de copiá-lo facilmente em vez de ter que reescrevê-lo eles mesmos. Caso contrário, você pode acabar com (1) muitos erros de digitação e (2) desenvolvedores irritados. Existem várias maneiras que você pode dar-lhes acesso ao conteúdo:

• dando-lhes acesso aos ficheiros de origem do trabalho de desenho em Sketch, Figma ou Zeplin, por exemplo.
• copiando / colando o conteúdo diretamente na especificação (pode torná-lo um pouco confuso).

Se o seu produto existir em várias línguas, dê também acesso a cada tradução. Por exemplo, você pode usar um array para mostrar a tradução de seu conteúdo original em cada idioma. O próximo nível de gerenciamento de tradução é usar uma ferramenta de localização (como frase) e apenas adicionar as “chaves de tradução” em seu produto spec. Mas mais uma vez, isso implica mais um para trás e para a frente entre as especificações do seu produto e outra ferramenta.