Por favor, defina uma política.
Uma das coisas que ouço frequentemente de designers e desenvolvedores enquanto trabalho como gerente e planejador de projetos é Selecione a políticaQuero dizer. Mas sempre pensei que essa política já existisse. Também definimos requisitos baseados em políticas. Por exemplo, como segue:
000 Implementamos a função de bloqueio do aplicativo para proteger os direitos de propriedade dos usuários e garantir a segurança do aplicativo de acordo com as leis e diretrizes. Enquanto isso, para esse propósito, você deve tomar medidas para bloquear o aplicativo à força quando as funções de bloqueio do dispositivo e de bloqueio do aplicativo não estiverem aplicadas.
Quando eu forneço requisitos como esse e realizo uma reunião com os membros da minha equipe, eles geralmente entendem tudo. Eu também disse: “Ah, os requisitos foram bem transmitidos. Eu penso: 'Agora só preciso prestar atenção aos detalhes com as considerações adicionais que surgem durante o processo de implementação'”, e seguir em frente com outras tarefas. Mas quando pensei que as coisas estavam a ser bem implementadas, pediram-me para fazer uma política: “Que tipo de política? “Entendo que todas as políticas e requisitos foram entregues?”
Este artigo apresenta como escrever um plano por meio de cenários de usuário. A ordem de escrita é a seguinte.
1. Qual é a política?
2. Escreva o cenário do usuário.
3. Benefícios e prática de escrever cenários de usuário
Qual é a política?
Primeiro, o que os membros da equipe estão dizendo “Política”Eu estive pensando o que é isso.
Primeiro, política Conteúdo relacionado a negócios, indústria ou direitodiz! Por exemplo, há um caso como este. “O ambiente de negócios mudou recentemente. Consequentemente, a necessidade da função B aumentou.”, “O artigo 00 foi recentemente criado com a revisão da Lei das Redes de Informação e Comunicações. Assim, tornou-se necessário implementar a função A. Neste forma, incluindo mudanças no ambiente interno e externo da organização, Explica por que precisamos realizar uma tarefa específica no grande esquema das coisasPor favor, diga-me o que posso fazer por você.
Em segundo lugar, a política Problemas que os usuários podem encontrarEle diz. Esta é a parte frequentemente chamada de “definição do problema”. Por exemplo, “Os usuários estão preocupados com a exposição de seus ativos imediatamente após o lançamento do aplicativo”. Ou “Pessoas más podem iniciar o aplicativo imediatamente e fazer coisas ruins. Coisas como” Isso em breve causará grandes danos aos usuários “são definições de problemas. A definição do problema também é semelhante à primeira definição. Explicando por que precisamos fazer um trabalho no grande esquema das coisasIsto é o que você faz.
Terceiro, política requisitosdiz! Os requisitos são Medidas específicas para resolver o problemadiz! Também definimos metas e cronogramas alcançáveis com base nos requisitos. O exemplo no início deste artigo, “Quando as funções de bloqueio do dispositivo e do aplicativo não são aplicadas, a função forçar bloqueio do aplicativo deve funcionar”, pode ser um requisito. Além disso, você deve fornecer metas a serem alcançadas, como “cumprir 000 leis e diretrizes por meio da função de bloqueio de aplicativos e proteger os direitos de propriedade dos usuários” e prazos específicos, como “deve distribuir até o dia 4 do mês AD .” É melhor ser específico.
Finalmente, a política caso de exceçãoEle diz. Pessoalmente, esta foi a parte em que tive uma compreensão completamente diferente dos meus companheiros e, ao mesmo tempo, foi a parte que mais senti falta. Exceções ocorrem durante o processo de implementação de requisitos. Detalhes que podem não ter sido considerados em um nível superiordiz! Isso ocorre porque há casos excepcionais em que o designer tropeça ao projetar o produto, ou quando ocorre um conflito entre funções ou surge uma lacuna quando o desenvolvedor implementa o produto. Neste momento, os membros da equipe nos informarão.
“Primeiro Ministro, por favor, faça uma política.”
“Não creio que esta política tenha recebido consideração suficiente.”
“Não sei o que fazer. “Por favor, seja específico.”
Cometi muitos erros ao longo do caminho. Quando ouvia algo assim, procurava detalhes mais específicos na lei ou no manual para complementar as evidências, ou escrevia os requisitos com mais detalhes. Sem realmente ser capaz de resolver o bloqueio que os membros da equipe estão enfrentando, Quero dizer.
Os membros da nossa equipe costumam usar o termo “política” para se referir a todas essas coisas. Portanto, o nosso plano deve incluir políticas que incluam todas estas questões.
Vamos escrever um cenário de usuário.
Agora só temos que escrever algo mais em nosso plano. Com a maior brevidade Cenário do usuárioSim. As políticas mencionadas anteriormente, que podem incluir todas essas coisas Nossa principal arma são os cenários do usuário.Não olhe. Um cenário de usuário é uma descrição ou história de uma situação em que um usuário usa um produto ou serviço. do utilizador Alcance algum objetivoSe o usuário deseja atingir o objetivo Qual é o contexto/antecedentes?, Para atingir o objetivo, o usuário O que você faz?Isso significa desenhar.
Vamos criar um exemplo de cenário de usuário simples. Para dar um exemplo de como escrever um cenário adequado, vamos considerar o processo de implementação da função de bloqueio do aplicativo, que é a função descrita acima. Primeiro, vamos definir o usuário e o objetivo. Nossos usuários são “usuários que estão preocupados em se machucar porque seu celular foi perdido ou roubado ao usar aplicativos financeiros”. Seu objetivo pode ser “trabalhar de tal forma que ninguém além do usuário possa executar o aplicativo”.
Agora que configuramos ambos, vamos visualizar o que o usuário está fazendo. Você pode escrever ações do usuário conforme mostrado abaixo. O cenário a seguir é um exemplo e, no processo de implementação da função real, pode ser necessário escrever situações mais diversas e especificações detalhadas.
1. As funções de bloqueio do dispositivo do usuário e de bloqueio do aplicativo não estão definidas.
2. O usuário inicia o aplicativo para verificar ativos, transferir fundos, etc.
3. Na fase de execução do aplicativo, se o dispositivo do usuário está bloqueado, se o aplicativo está bloqueado ou não, e as informações do usuário são recuperadas do servidor.
4. Se o dispositivo estiver bloqueado e o bloqueio do aplicativo estiver desativado, a função de bloqueio do aplicativo será implementada com força.
5. Se alguma das condições estiver ativada, acesse o aplicativo sem forçar o bloqueio do aplicativo.
No entanto, se implementado desta forma, Sempre há exceções e deficiências.Eu vou fazer isso. Por exemplo, no exemplo aqui, este pode ser o caso. “Se a lógica que recupera e compara se o dispositivo está bloqueado e se o aplicativo está bloqueado no servidor toda vez for implementada no Splash, acho que o desempenho do aplicativo irá piorar, certo?” Ou “Como deveria funcionar se eu definir uma senha do dispositivo enquanto o aplicativo estiver em segundo plano por um tempo? Preciso verificar se o aplicativo está bloqueado à força mesmo quando ele passa do segundo plano para o primeiro plano?” Agora, escreva o seguinte cenário adicional.
6. Para evitar a verificação do servidor sempre que a lógica de bloqueio forçado do aplicativo é aplicada, ou quando o aplicativo vai para segundo plano ou fecha o aplicativo, se o usuário bloqueou o aplicativo é armazenado no cache do cliente. Isso reduz o tráfego ao reduzir as chamadas do servidor e evita a degradação do desempenho durante a fase de execução do aplicativo.
7. Como é difícil determinar se o dispositivo de um usuário está bloqueado quando o aplicativo não está em execução, as informações são recuperadas do dispositivo sempre que o aplicativo é iniciado ou sempre que o aplicativo entra em primeiro plano. Isso é comparado ao bloqueio do aplicativo em cache para determinar se o bloqueio do aplicativo deve ou não ser aplicado.
Agora resolvemos o problema da equipe escrevendo um cenário com casos excepcionais. Escrito aqui Cada cenário é um requisito e uma especificação do produtoPode ser isso. Agora, os membros da equipe podem acompanhar o design com base no cenário criado desta forma, a comunicação entre os desenvolvedores cliente e servidor e os designers podem acompanhar o fluxo do design.
Benefícios e prática de escrever cenários de usuário
Existem três vantagens principais em escrever um roteiro como este.
1. Os custos de comunicação entre os membros da equipe podem ser reduzidos.
2. Como vários casos podem ser considerados, erros nos requisitos podem ser reduzidos e funcionalidades desnecessárias podem ser reduzidas.
3. Pode reduzir os custos gerais de desenvolvimento e melhorar a velocidade de desenvolvimento.
Para escrever bem os cenários do usuário, é útil praticar duas coisas principais.
Primeiramente, Imagine constantemente os casos que queremos implementar do ponto de vista do usuárioTente. Pense em todos os tipos de ações do ponto de vista do usuário. É claro que, apesar disso, os usuários sempre podem encontrar situações inesperadas. No entanto, se você incorporar tantas perspectivas do usuário quanto possível durante o processo de planejamento, poderá implementar um produto mais completo complementando outras instâncias durante o processo de design subsequente.
Em segundo lugar, é claro Escreva com frequência e forneça feedback ativo aos membros da equipeVamos encontrar. A razão pela qual escrevemos planos é permitir que os membros da equipe criem produtos e, acima de tudo, nosso trabalho é fazer as coisas acontecerem. Portanto, quanto mais experiência você tiver na criação de um plano que seja aceitável para os membros da sua equipe e em conduzi-lo à implementação real, melhor você será capaz de fazê-lo. À medida que essas experiências se acumulam continuamente, você será naturalmente capaz de pensar em diferentes casos excepcionais sem ter que pensar muito ou profundamente. Além disso, à medida que essa experiência se acumula, pode ser criado um plano no qual os membros da equipe confiem.
Conclusão
Nós sempre nos preocupamos. Como posso criar um plano que faça com que os membros da equipe entendam melhor? Se os membros da equipe não entenderem o plano que temos em vigor, Se você continuar solicitando uma política ou se os requisitos não forem claros, recomendo escrever um plano por meio de cenários de usuário.
Junho disse BrunchApós a edição do artigo publicado em , apresentamos-o novamente no Mobi Inside.
“Leitor implacável. Especialista em mídia social. Amante de cerveja. Fanático por comida. Defensor de zumbis. Aficionado por bacon. Praticante da web.”