Como mover um cliente de modelos de interface do usuário para um conjunto de requisitos reais?

Digamos que você tenha uma maquete de 25 telas dos estados visuais do seu aplicativo. A expectativa é que isso seja suficiente para termos certeza de que podemos desenvolver e entregá-lo à parte interessada ou ao cliente original como um aplicativo finalizado, e eles ficarão satisfeitos. Naturalmente, você acabará repetindo muitas perguntas às partes interessadas que foram usadas para criar a interface do usuário, o que é um desperdício.

No entanto, muitas vezes descobri que isso não é o bastante. No decorrer do desenvolvimento do aplicativo, os requisitos ficam obscurecidos pelo fato de estarmos replicando uma interface e, no final, o cliente não ficar tão feliz quanto parecia à primeira vista. quando pedimos a eles todas as informações para criar a interface do usuário.

Só não tenho certeza do que mais pedir, tentei ser específico e pedir requisitos e uma compreensão do objetivo geral, mas não sei o que devo pedir. Se eu começar agora, muito tempo será desperdiçado re-hash de todas as informações que levaram à interface do usuário e, durante esta fase, muitos motivos importantes que o cliente tinha originalmente serão perdidos.

Como faço para que as pessoas entendam que não podemos bloquear requisitos com base em modelos de interface do usuário solicitando algo acionável que eles possam criar para mim?

Com o que você idealmente começaria para executar adequadamente a tarefa de desenvolver um aplicativo para usuários finais?

Algumas outras coisas que você pode precisar são:

• Descrições de casos de uso ou de fluxo de trabalho: Só porque você sabe como é a tela, você sabe o quanto as entradas são ruins? Você sabe como fazer a transição entre telas em TODOS os casos? Você também pode incluir o tratamento de erros aqui.

• Descrição do sistema de alto nível: Algo explica o que é o sistema inteiro para essas 25 telas e o que elas fazem.

• Modelo de dados: É possível inferir um modelo de dados nessas telas? Existe um modelo de dados que deve ser usado ou você está livre para criar seu próprio projeto para realizar o trabalho?

• Requisitos técnicos: as tecnologias específicas que devem ser usadas devido ao licenciamento ou por razões de integração?

• Requisitos de desempenho: se houver uma tela de pesquisa, existe uma expectativa do que pode ser pesquisado e com que rapidez a resposta deve ser? E as respostas para outros tipos de ações? Alguns podem ou devem ser assíncronos (o usuário envia o trabalho e volta mais tarde)?

• Requisitos de segurança: o aplicativo armazena dados pessoais / potencialmente sensíveis e, em caso afirmativo, que tipos de dados e o que deve ser feito para mantê-lo seguro? Você precisa atingir algum nível de conformidade (como conformidade com PCI para efetuar pagamentos com cartão de crédito)?

Além disso, existe algum conhecimento especial no domínio comercial em que você possa precisar deles para ajudá-lo? Alguns setores, como seguros, bancos, registros médicos, etc ... têm todo tipo de lógica de negócios complexa. Esses projetos não devem ser tentados sem a ajuda de um analista de negócios que conhece esse domínio. Mas se for apenas um site de carrinho de compras / informações para widgets genéricos, talvez você não precise desse membro da equipe.

Como fazer as pessoas entenderem que as simulações de interface do usuário não são suficientes para criar um programa de trabalho:

Eu lidaria com isso com uma analogia. Desde que eu sou um pouco louco por carros, estou indo por esse caminho.

"Finja que não sei nada sobre carros. Você me passa algumas fotos de uma Ferrari. Algumas de fora e uma de dentro do carro (tiradas do banco do motorista para que eu possa ver os controles do carro). Agora você me pergunta para construir uma Ferrari. Volto com uma coisa que se parece com as fotos e tem todos os controles. Infelizmente, esses controles não estão ligados a nada, porque (desde que eu não sei nada sobre carros) eu não sei o que esses os controles devem fazer.Eu não posso nem adivinhar, porque eu nem sei o que os carros devem fazer.Então, temos uma conversa como esta:

"Então, o que uma Ferrari faz?" "Isso me permite passar de um ponto para outro rapidamente." "OK. Então, o que essa coisa de círculo faz?" "Ah, esse é o volante. Ao girá-lo, você pode mudar para que lado as rodas do lado de fora do carro apontam. Isso vai mudar para que lado o carro se move." "OK, e quanto a essa coisa de pedal?" "Esse é o pedal do acelerador. Faz o motor acelerar, o que faz o carro andar mais rápido." ... alguns minutos depois ... "Ok, então que tipo de motor ele precisa? Eu fiz algumas pesquisas e encontrei motores para carrinhos de golfe e outros para carros esportivos. Qual devo usar?" ... etc ... "

Então você pode explicar a analogia. Entregar zombarias de telas aos desenvolvedores apenas diz a eles como é, não o que faz. Os desenvolvedores precisam saber qual problema o programa resolve ou como será usado (como saber o que um carro faz facilita o design do carro e adivinhar dicas sobre o que as coisas devem fazer). Eles precisam saber que tipos de coisas devem usar (por exemplo, o mecanismo do carrinho de golfe versus o mecanismo do carro esportivo) e quais outros requisitos que não são da interface do usuário (o carro deve ir rápido).

Coisas que eu pediria:

Descrição geral / de alto nível do problema

Casos de uso / histórias de usuários

Requisitos de desempenho

Tecnologias / plataforma necessárias (Windows, Linux, Web)

Tudo que FrustratedWithForms tem em sua resposta

Algo para o efeito de 80% do esforço de desenvolvimento vai para 20% dos casos de uso adicionais. As capturas de tela não informam sobre casos de uso, portanto você ficará no escuro por 80% do seu desenvolvimento ativo.

É bom que você esteja tentando descobrir mais e tentando comunicar a importância de o cliente se envolver mais nos requisitos do projeto; no entanto, se ele não fizer isso, estará configurando o projeto para falhas e isso não é culpa sua.

A maioria dos projetos de software falha porque o cliente não está envolvido o suficiente no processo de desenvolvimento de software. Esse não é um problema novo e certamente não é um mistério o motivo pelo qual os projetos de software fracassam, mas acontece continuamente na indústria por causa de situações como essa.

Você não pode simplesmente lançar um monte de informações sobre uma parede e esperar recuperar todas as suas esperanças e sonhos na forma de um pacote de software. O desenvolvimento de software simplesmente não funciona dessa maneira. Seja você uma loja Agile ou Waterfall, é necessária uma direção sólida do cliente para o sucesso ou fracasso de um projeto.

Uma coisa que as pessoas parecem esquecer de perguntar é para que os dados serão usados ​​depois que forem inseridos? Você precisa de relatórios? Você precisa gerar uma guia de remessa e enviá-lo ao armazém para remessa, etc. Se os dados forem usados ​​para tomar decisões de gerenciamento e os relatórios forem necessários, isso poderá alterar o design do banco de dados. Também pode adicionar uma quantidade séria de tempo ao desenvolvimento, dependendo da complexidade dos relatórios.

Você também precisa garantir que haja um caminho para cada decisão possível. Portanto, se algo exigir aprovação de gerenciamento - o que você fará se for reprovado e o que você fará se for aprovado. Se não for aprovado ou reprovado em X por um período de tempo, o que acontece? Se eles selecionarem um produto e ele não estiver em estoque, o que acontece com o pedido? Esses tipos de perguntas.

Você também precisa saber se existem limites específicos sobre quais dados devem ser colocados em cada campo. Existem valores obrigatórios. De onde você vai tirá-los? Como eles serão atualizados? Você precisa saber como lidar com erros. Você precisa saber se o banco de dados precisa ter auditoria ou se é necessário recriar dados de uma perspectiva histórica (de volta aos relatórios incômodos).

Outra coisa que vejo acontecendo é que os aplicativos podem ser projetados apenas para chegar ao lançamento sem considerar como os dados serão mantidos posteriormente. Você precisa de uma página de administrador para garantir que eles possam atualizar suas listas de valores necessários? Você precisa enviar e receber dados para outros sistemas. Como você irá obter os dados iniciais no banco de dados?

Pessoalmente, eu pediria uma reunião de meio dia a dia com o cliente para percorrer seu design de interface do usuário e seus objetivos e garantir que tudo estivesse alinhado.

Comece simples. Faça com que eles entendam que, com as informações fornecidas, nenhuma dessas telas faria nada . Não há detalhes sobre casos de uso, mau comportamento de entrada e assim por diante. Simplesmente não vai funcionar. Explicar uma generalização contundente é mais fácil do que explicar detalhes, porque o ponto não pode se perder. Tentar dar uma justificativa mais complicada para o motivo pelo qual os modelos de tela não são suficientes dá a eles a oportunidade de questionar suas definições em vez de reconhecer o problema. Peça-lhes que imaginem que o desenvolvedor de back-end não falava inglês (ou o idioma em que as telas são apresentadas). Em seguida, pergunte o quão diferente é essa situação para um desenvolvedor que não tem conhecimento algumde seus processos de negócios. Em seguida, desenvolva o exemplo mais realista de vocês, que têm algum conhecimento, mas são justificados em acreditar que não é apropriado decidir a lógica de negócios deles.

Pessoas que não desenvolveram software não sabem o que os desenvolvedores de software precisam saber. Não se pode esperar que eles produzam especificações de requisitos e casos de uso por conta própria. Você precisa aplicar técnicas de obtenção de requisitos para obter as informações que precisa saber. Trabalhe com o cliente (e, com sorte, uma amostra de usuários de várias funções) para determinar o que eles precisam ou desejam. Técnicas comuns para isso são entrevistas e / ou observação de usuários, identificando casos de uso e histórias de usuários e prototipagem.

Eu recomendo a aplicação de técnicas de desenvolvimento iterativo e incremental nesse caso, pois você possui requisitos vagos, incompletos ou pouco compreendidos. Observe as várias metodologias ágeis, juntamente com o Modelo Espiral, para abordar o planejamento do ciclo de vida.

Comece obtendo o objetivo de negócios que impulsiona o desenvolvimento deste software. Entreviste o cliente e os usuários e, se puder, assista-os no trabalho. Tente determinar qual problema eles estão tentando resolver. Veja quais ferramentas eles estão usando atualmente e como eles as utilizam, para que você possa melhorar sua maneira atual de fazer as coisas. Use esta oportunidade para aprender o domínio e seu idioma - será infinitamente mais fácil se comunicar se os desenvolvedores de software e os clientes / usuários falarem o mesmo idioma (e não esperarem que os clientes / usuários falem em termos de software).

Depois de entender quais são os objetivos, você poderá começar a trabalhar com os modelos de design de interface do usuário que possui e "fazer engenharia reversa" dos casos de uso e histórias de usuários a partir deles, com base em como várias telas se encaixam. O formato da história do usuário provavelmente funcionaria bem para lidar com um público não técnico. O formato As a <user type>, I want to <action> so that <reason>funciona em termos de obter desenvolvedores e clientes / usuários falando o mesmo idioma. Assim que você começar as histórias dos usuários, eu adotaria uma abordagem de prototipagem para o desenvolvimento.

Eu acho que abordaria isso com o uso de prototipagem. Você poderia abordar isso a partir de uma perspectiva de prototipagem evolutiva ou prototipagem descartável , mas eu consideraria uma abordagem de prototipagem evolutiva primeiro. Comece com as histórias de usuário com as quais você se sente mais confortável e validou e comece a implementá-las. Ao implementá-los, obtenha feedback do cliente e desenvolva novas histórias de usuários, casos de uso e resolva mal-entendidos.

Além disso, não pense nisso como "implementar uma interface de usuário com recursos". Em vez disso, pense nisso como fatias verticais finas. Não implemente toda a interface do usuário de uma só vez e depois se preocupe com os recursos. Em vez disso, use as maquetes da interface do usuário para identificar recursos e outros requisitos e, em seguida, implemente uma fatia vertical da interface do usuário até a lógica comercial e o armazenamento de dados. Repita isso para cada fatia vertical. Você também deve fazer sugestões para melhorar a interface do usuário com base nos requisitos e nos princípios de usabilidade.

Eu recomendaria a leitura de dois livros de Karl Wiegers - Requisitos de Software e Mais sobre Requisitos de Software . Penso que estes irão ajudá-lo com a engenharia de requisitos e as melhores práticas nesta área.

Bem, esta é uma referência inicial embaraçosamente óbvia, mas a Wikipedia pode ser um lugar para você e os usuários começarem. O fato de haver uma entrada sobre esse material pode ajudar a convencê-los de que esse é um problema real, e não de você estar sofrendo.

Mais especificamente, você está confuso com o que o aplicativo faz, mesmo depois de revisar as maquetes? Nesse caso, admita-o e tente explicar que você não tem idéia de quais dados cada formulário deve exibir ou de onde viriam, são de outras telas ou dados externos?

Se você tem alguma idéia, tente criar exemplos de coisas que você não sabe fazer ("a lista de modelos a ser selecionada será uma lista global ou será por Usuário ou qualquer outra? Não pelo usuário devo permitir que duas pessoas editem ao mesmo tempo? O que a interface do usuário deve mostrar se alguém estiver editando? Existe uma tela para isso? Depois que alguém usa um modelo para qualquer modelo usado e o modelo é editado essa mudança deve ser propagada para o que eles fizeram com o modelo? ").

Deixe claro que, com o seu nível atual de conhecimento, você precisará responder a perguntas a cada 90 segundos pelo restante do ciclo de desenvolvimento e, na maior parte do tempo, não conseguirá continuar trabalhando até obter uma resposta. O objetivo deve ser esclarecer por que ter algum tipo de processo facilitará tudo. Mencione também que o controle de qualidade precisará das mesmas informações que você, por isso será mais fácil anotá-las para que estejam disponíveis para todos e ninguém se esqueça de nada.

Pode ser útil mencionar que parte do código que você escreve afeta mais de uma tela por vez; portanto, se você tiver o máximo de respostas possíveis, será mais fácil escrever esse código adequadamente e não precisar alterá-lo mais tarde.

Se você ainda não consegue obter os requisitos e realmente não sabe como proceder, envie e-mails sempre que precisar de mais informações (ou seja, requisitos) e se não puder continuar trabalhando sem essas informações, indique claramente que infelizmente, não é possível continuar trabalhando, porque o código que você precisa escrever será muito diferente, dependendo das respostas às suas perguntas. Não reclame, apenas muito profissionalmente, deixe que eles saibam que você não pode escrever o programa até saber o que ele deve fazer.

Você precisa conhecer os limites e os intervalos de cada campo no aplicativo. Por exemplo, se o campo for o número de telefone, eles esperam que você lide com +1? Quais campos são obrigatórios? O que eles querem que o aplicativo faça se o usuário digitar "abc" no campo # do telefone? Todas as 25 telas estão na ordem em que todos os usuários devem prosseguir?

Caso contrário, basta criar tudo como campos de texto e pronto! Quer apostar que vai passar como um balão de chumbo?