Atrair requisitos para pessoas de negócios?

Quais métodos parecem funcionar melhor para persuadir os requisitos de pessoas de negócios não-tecnológicas? Estou trabalhando com uma equipe que está tentando reunir uma especificação para um projeto. Toda vez que nos encontramos e se resume às expectativas para a próxima reunião, solicitamos aos empresários que recuperem seus requisitos. Eles costumam responder algo assim: "Bem, vocês acham que poderiam criar um protótipo para que possamos ver o que gostamos na próxima semana ... você sabe, não com nenhum dado ou qualquer coisa, já que é um protótipo, apenas a funcionalidade". é um projeto de mais de 6 meses, pelo que é obviamente inviável (teríamos que desenvolver a coisa toda!), e nem sabemos o que prototipar sem algum tipo de especificação. Francamente, eu acho que, como a maioria das pessoas, elas têm alguma idéia do que querem, elas simplesmente não estão pensando nisso da maneira focalizada necessária para reunir os verdadeiros requisitos. Como uma alternativa para simplesmente dizer a eles, “Dê-nos o que você quer ou não podemos / não fazemos nenhum trabalho” (queremos que eles fiquem felizes com os resultados), existem maneiras de ajudá-los a decidir o que querem? Por exemplo, poderíamos dizer a eles:

“Desenhe algumas telas (no Powerpoint, em um guardanapo, qualquer que seja) que mostrem a interface do usuário que você deseja com todos os dados que deseja ver e uma descrição da funcionalidade nas margens. A partir disso, vamos aprimorá-lo e criar o back-end com base nesse conjunto de requisitos de comportamento. ”

OU

“Não se preocupe com a aparência agora (o número 1 desliga). Basta nos fornecer uma lista de todos os dados que você deseja sobre cada item que o programa controla. Portanto, para o "Cliente", você pode listar: nome, endereço, número de telefone, pedidos etc. Não precisa ser uma estrutura de banco de dados perfeita, mas podemos resolver isso e ter uma idéia do que você está procurando "

Alguma dessas abordagens alternativas para focar as pessoas de negócios no que elas querem faz sentido? Existem alternativas que você já viu em ação?

Passei os últimos três meses em uma fase exaustiva - e exaustiva - de levantamento de requisitos de um grande projeto e aprendi, acima de tudo, que não existe uma solução única para todos . Não há processo, nem segredo, que funcione em todos os casos. A análise de requisitos é uma habilidade genuína e, quando você pensa que finalmente descobriu tudo, fica exposto a um grupo totalmente diferente de pessoas e precisa jogar tudo o que sabe pela janela.

Várias lições que aprendi:

• Diferentes partes interessadas pensam em diferentes níveis de abstração.

  É fácil dizer "falar em nível de negócios, não técnico", mas não é necessariamente tão fácil de fazer . O sistema que você está projetando é um elefante e suas partes interessadas são os cegos que o examinam . Algumas pessoas estão tão profundamente imerso no processo e rotina que eles nem sequer percebem que não é um negócio. Outros podem trabalhar no nível de abstração que você deseja, mas tendem a fazer afirmações exageradas ou até falsas, ou se envolver em pensamentos desejosos.

  Infelizmente, você simplesmente precisa conhecer todos os indivíduos como indivíduos e entender como eles pensam, aprender a interpretar as coisas que eles dizem e até decidir o que ignorar.

• Dividir e conquistar

  Se você não quer que algo seja feito, envie-o para um comitê.

  Não se encontre com comitês. Mantenha essas reuniões o menor possível. YMMV, mas, na minha experiência, o tamanho ideal é de 3-4 pessoas (incluindo você) para sessões abertas e 2-3 pessoas para sessões fechadas (ou seja, quando você precisa de uma pergunta específica respondida).

  Tento me encontrar com pessoas que têm funções semelhantes no negócio. Há realmente muito pouco a ganhar e muito a perder ao jogar o pessoal de marketing na sala com os contadores de feijão. Procure as pessoas que são especialistas em um assunto e peça que conversem sobre esse assunto.

• Uma reunião sem preparação é uma reunião sem propósito.

  Algumas outras respostas / comentários fizeram referência à técnica do palhaço, que é excelente para aquelas pessoas problemáticas das quais você simplesmente não consegue obter respostas. Mas não contar com palha-homens demasiado muito, ou as pessoas mais vai começar a se sentir como se estivesse ferrovias eles. Você deve gentilmente cutucar as pessoas na direção certa e permitir que elas apresentem as especificidades, para que elas sintam que são donas delas (e, de certa forma, elas são donas delas).

  O que você precisa é de algum tipo de modelo mental de como você acha que os negócios funcionam e como o sistema deve funcionar. Você precisa se tornar um especialista em domínio , mesmo que não seja especialista na empresa específica em questão. Pesquise o máximo possível sobre seus negócios, seus concorrentes, sistemas existentes no mercado e qualquer outra coisa que possa estar relacionada remotamente.

  Uma vez nesse ponto, achei mais eficaz trabalhar com construções de alto nível, como casos de uso, que tendem a ser agradáveis ​​a todos, mas ainda é essencial fazer perguntas específicas. Se você começar com "Como você cobra seus clientes?" , você estará em uma reunião muito longa. Faça perguntas que impliquem um processo em vez de limitar o processo no início: Quais são os itens de linha? Como eles são calculados? Quantas vezes eles mudam? Quantos tipos diferentes de vendas ou contratos existem? Onde eles são impressos? Você entendeu a ideia.

  Se você perder um passo, alguém normalmente lhe dirá. Se ninguém reclamar, dê um tapinha nas costas, porque você acabou de confirmar implicitamente o processo.

• Adie discussões fora do tópico .

  Como analista de requisitos, você também está desempenhando o papel de facilitador e, a menos que você realmente goste de passar todo o seu tempo em reuniões, precisa encontrar uma maneira de manter as coisas no caminho certo. Ironicamente, esse problema se torna mais pernicioso quando finalmente as pessoas conversam. Se você não tomar cuidado, pode atrapalhar o trem que você gastou tanto tempo preparando os trilhos.

  No entanto - e aprendi isso da maneira mais difícil há muito tempo - você não pode simplesmente dizer às pessoas que um problema é irrelevante . É obviamente relevante para eles , caso contrário eles não estariam falando sobre isso. Seu trabalho é conseguir que as pessoas digam "sim" o máximo possível e colocar uma barreira como essa apenas o leva ao território "não".

  Esse é um equilíbrio delicado que muitas pessoas são capazes de manter com "itens de ação" - basicamente uma fila genérica de discussões que você prometeu voltar em algum momento , normalmente marcada com os nomes das partes interessadas que pensavam que era realmente importante. Isso não é apenas por causa da diplomacia - também é uma ferramenta valiosa para ajudar você a lembrar o que aconteceu durante as reuniões e com quem conversar se precisar de esclarecimentos mais tarde.

  Analistas diferentes lidam com isso de maneiras diferentes; alguns como o quadro público ou o flip-chart, outros silenciosamente o inserem em seus laptops e seguem delicadamente outros tópicos. Tudo o que você se sentir confortável.

• Você precisa de uma agenda

  Provavelmente isso é verdade para quase qualquer tipo de reunião, mas é duplamente verdadeiro para reuniões de requisitos. À medida que as discussões se arrastam, as mentes das pessoas começam a se afastar e começam a se perguntar quando você vai entender o que realmente importa. Ter uma agenda fornece alguma estrutura e também ajuda a determinar, como mencionado acima, quando você precisa adiar uma discussão que está ficando fora de tópico.

  Não entre lá sem uma idéia clara do que exatamente você quer cobrir e quando . Sem isso, você não tem como avaliar seu próprio progresso, e os usuários o odiarão por muito tempo (assumindo que eles ainda não o odeiam por outros motivos).

• Mock It

  Se você usar o PowerPoint ou o Visio como uma ferramenta de mock-up, sofrerá com o problema de parecer polido demais . É quase um vale estranho de interfaces de usuário; as pessoas se sentirão confortáveis ​​com desenhos de guardanapos (ou desenhos gerados por computador que se parecem com desenhos de guardanapos, usando uma ferramenta como Balsamiq ou Sketchflow ), porque eles sabem que não é a coisa real - mesma razão pelas quais as pessoas são capazes de assistir personagens de desenhos animados. Mas quanto mais ela se parece com uma interface do usuário real, mais as pessoas querem escolher e mexer nela, e mais tempo gastam discutindo sobre detalhes que são insignificantes.

  Definitivamente, faça simulações para testar sua compreensão dos requisitos ( após os estágios iniciais da análise) - elas são uma ótima maneira de obter um feedback muito rápido e detalhado - mas mantenha-as organizadas e não se apresse até que você ' você tem certeza de que está prestando atenção nos seus usuários.

  Lembre-se de que uma simulação não é uma entrega , é uma ferramenta para ajudar no entendimento. Assim como você não esperaria ser mantido cativo ao seu mock ao fazer o design da interface do usuário, você não pode assumir que o design está OK simplesmente porque eles deram o polegar para cima ao seu mock-up. Já vi zombarias usadas como muleta, ou pior, como desculpa para ignorar completamente os requisitos; verifique se você não está fazendo isso. Volte e transforme esse mock em um conjunto real de requisitos.

• Seja paciente.

  É difícil para muitos programadores acreditarem, mas para a maioria dos projetos não triviais, você não pode apenas sentar uma vez e elaborar uma especificação funcional completa. Não estou falando apenas de paciência durante uma única reunião; a análise de requisitos é iterativa da mesma maneira que o código. O Grupo A diz algo e, em seguida, o Grupo B diz algo que contradiz totalmente o que você ouviu do Grupo A. Então, o Grupo A explica a inconsistência e acaba sendo algo que o Grupo C esqueceu de mencionar. Repetir 500 vezes e você tem algo mais ou menos parecido com a verdade .

  A menos que você esteja desenvolvendo algum aplicativo CRUD minúsculo (nesse caso, por que se preocupar com os requisitos?), Não espere obter tudo o que precisa em uma reunião, duas ou cinco. Você vai ouvir muito, falar muito e se repetir bastante. O que não é uma coisa terrível, lembre-se; é uma chance de criar um relacionamento com as pessoas que inevitavelmente assinarão a entrega.

• Não tenha medo de mudar sua técnica ou improvisar.

  Diferentes aspectos de um projeto podem realmente exigir diferentes técnicas de análise. Em alguns casos, a UML clássica (diagrama de caso de uso / atividade) funciona muito bem. Em outros casos, você pode começar com KSIs comerciais ou fazer um brainstorming com um mapa mental ou mergulhar diretamente em modelos, apesar do aviso anterior.

  A conclusão é que você precisa entender o domínio por conta própria e fazer sua lição de casa antes de perder o tempo de outras pessoas. Se você souber que um departamento ou componente específico possui apenas um caso de uso, mas é incrivelmente complicado, pule a análise de casos de uso e comece a falar sobre fluxos de trabalho ou fluxos de dados. Se você não usaria a mesma ferramenta para todas as partes da implementação de um aplicativo, por que você usaria a mesma ferramenta para todas as partes dos requisitos?

• Mantenha seu ouvido no chão.

  De todas as dicas e sugestões que li para a análise de requisitos, essa é provavelmente a que é mais frequentemente ignorada. Sinceramente, acho que aprendi mais a espionar e ocasionalmente travar conversas com bebedouros do que em reuniões agendadas.

  Se você está acostumado a trabalhar isolado, tente descobrir onde está a ação para poder ouvir a conversa. Se não puder, faça rondas frequentes, para a cozinha ou o banheiro ou onde quer que seja. Você descobrirá todos os tipos de coisas interessantes sobre como a empresa realmente opera ouvindo o que as pessoas se gabam ou reclamam durante seus intervalos de café e fumaça.

• Por fim, leia nas entrelinhas .

  Um dos meus maiores erros no passado foi estar tão focado no resultado final que não tive tempo para realmente ouvir o que as pessoas estavam dizendo . Às vezes - na maioria das vezes - pode parecer que as pessoas estão tagarelando sobre nada ou insistindo em algum procedimento que soa totalmente inútil para você, mas se você realmente se concentrar no que elas estão dizendo, perceberá que realmente existe um requisito enterrado lá - ou vários.

  Tão brega e insípida quanto parece, os Cinco Porquês é uma técnica realmente útil aqui. Sempre que você tiver essa reação "idiota" (não que você diria isso em voz alta), pare-se e transforme-a em uma pergunta: Por quê? Por que essas informações são digitadas novamente quatro vezes, depois impressas, fotocopiadas, digitalizadas, impressas novamente, fixadas em um painel de partículas, filmadas com uma câmera digital e finalmente enviadas por e-mail ao gerente de vendas? Não é uma razão , e eles podem não saber o que é, mas é o seu trabalho para descobrir. Boa sorte com isso. ;)

Se você não conseguir obter algo deles, escreva algo e obtenha aprovação. É muito mais fácil para as pessoas não técnicas dizerem 'não, eu não gosto disso' do que 'é assim que você deve fazer'.

Muitas vezes, o que eles querem e o que eles dizem são duas coisas muito diferentes. Reserve um tempo para escrever um primeiro rascunho da especificação com as informações que você conhece atualmente. Peça às partes interessadas que leiam e aprovem. Quando o lerem, eles provavelmente verão coisas que não gostam ou com as quais concordam. Obtenha o feedback deles e depois revise.

Se houver algo em que você possa seguir um caminho ou outro, on-line nas duas opções e peça ao tomador de decisão que faça uma escolha. Não os deixe em paz até que o façam.

Quanto aos protótipos, faça modelos de tela e explique como as coisas funcionariam. Mais uma vez, ver algo ajuda a visualizar o que está acontecendo. Leve consigo novos modelos de tela para as reuniões e obtenha respostas.

No passado, eu abri o FireBug e adicionei as alterações solicitadas pelo cliente bem na frente deles, para que pudessem ver como seria. Eles deram seu feedback, tirei uma captura de tela e implementei as alterações. Eles realmente gostaram de ver como seria a mudança, e eu gostei porque era rápido e recebi minha resposta naquela reunião ... não na próxima.

Faça com que falem mais sobre seus negócios e menos sobre aplicativos. Descubra quais são os problemas reais: os relatórios no final do mês demoram muito, erros de entrada de dados, eles superaram o aplicativo atual, o crescimento da empresa está ficando fora de controle.

Suponho que essas reuniões sejam com as pessoas que fazem as compras, mas não com as pessoas que realmente farão o trabalho que envolve o aplicativo. Pergunte se você pode se encontrar com algumas dessas pessoas. Eles podem mostrar como as coisas são realmente feitas. Verifique se você está lidando com clientes que planejaram seu tempo e o custo.

Veja se eles têm algum relatório que estão usando no momento ou desejam usar. Obviamente, você não pode criar o relatório se não coletar os dados corretamente. Eles precisam fazer alguma coisa, a menos que essa seja uma linha de negócios que ainda não começaram.

Muitos têm essas noções gerais de que você é o programador, para saber como criar todos os programas. Sites de comércio eletrônico são todos iguais, certo?

Comece pequeno. Infelizmente, até você receber algo na frente deles, o processo simplesmente não é registrado. Se você não tem nada para passar, basta fingir.

Muito disso tem a ver com habilidades interpessoais genéricas e como você se comunica com o cliente em primeiro lugar. Não há muito o que dizer sobre isso, além disso - certifique-se de explicar o processo como interativo, em que você também espera feedback e esforço da parte dos clientes.

Especificamente para o cenário que você descreveu, eis mais alguns conselhos: Comece descrevendo o que você consideraria útil e forneça veículos para descrever as informações em termos que não exijam especialização técnica ou conhecimento:

• Histórias de usuário / casos de uso Peça descrições detalhadas do que os usuários esperam fazer, quais informações eles precisam para fazê-lo e o que você deve e pode esperar que os usuários insiram. Depois de obter essas informações, acompanhe-as com elas e verifique se tudo está coberto de histórias - não deve haver nada que apareça no aplicativo, onde você não tem histórias cobrindo o que o usuário fará lá.

• Demonstrações convincentes O que é mais importante para conquistar clientes? Quais partes do programa ou funcionalidade precisam se destacar e precisam ser completamente polidas? Você pode me fornecer uma demonstração de maquete, usando notas postadas, caixas de papelão ou outros substitutos que você gostaria de ter trabalhado?

• Informações competitivas / de mercado Para cada história de usuário, o que estamos fazendo, semelhante aos nossos concorrentes? Diferente? Que história nossos concorrentes contam e estamos tentando copiar / emular / melhorar / inovar / ser propositalmente diferentes?

• Perguntas abertas Quais dos requisitos e design são as informações que você tem certeza e o que é um experimento? Onde vamos tentar alternativas para ver qual deles funciona? Se você está procurando várias alternativas e só nos disse uma, quais são as outras que está considerando?

Em seguida, desenhe alguns limites:

• Por favor, não coloque restrições técnicas em mim . Uma pessoa de negócios não deveria estar dizendo para você "usar o Windows porque é melhor que o Linux". Eles podem, no entanto, fornecer instruções na mesma linha de "todo o nosso mercado-alvo usa o Windows, nosso aplicativo precisará ser executado no Windows para ter sucesso"

• Não se preocupe com o design Especialmente se você estiver lidando com pessoas orientadas para vendas ou marketing, elas tenderão a ficar atoladas com problemas de design. Novamente, reduza o escopo das informações ao que elas se especializam - "o azul é mais bonito aqui" provavelmente não é apropriado. "Nosso concorrente está usando um tema de cor azul, e existe desde os anos 80, para partes do nosso programa em que não estamos inovando, devemos usar um esquema azul para comunicar que não somos novos", provavelmente é apropriado. "O nome deve estar na parte superior da tela" provavelmente não é apropriado, mas "as informações mais importantes nesta página são o nome do usuário e o saldo da conta bancária", provavelmente é. Verifique se um designer está envolvido na conversão desses requisitos em uma interface do usuário.

• Anote as decisões Preferencialmente, construa-as em contratos ou outros compromissos que você faz. Lembre-se, porém, que uma decisão que o cliente não entende, não vale o papel em que foi escrita. Um cliente que assina "o aplicativo será executado na porta 1521" não vale tanto quanto o cliente que assina "o aplicativo será executado em uma porta configurável e personalizada, que pode exigir configuração especial para firewall e segurança quando implantada "

Do seu ponto de vista, para incentivar o processo a continuar:

• Forneça feedback no mesmo nível de abstração Isso ocorre em geral, por exemplo, para unidades - se o cliente estiver falando mensalmente de usuários, não responda em gigabits de largura de banda. Ou, para casos de uso - descreva a funcionalidade em termos de casos de uso em funcionamento, em vez de módulos ou correções ou recursos.

• Forneça comunicação significativa Expresse as perguntas que você possui e as informações adicionais que você descobriu ou está procurando, em termos das informações que foram fornecidas a você. "Nós estamos indo com o linux" provavelmente é um feedback mal escrito, enquanto "nossos testes mostram que o aplicativo é mais suave quando hospedado em máquinas linux e acessado com o IE no Windows" pode ser mais apropriado.

• Iterar rapidamente Para manter o cliente envolvido, forneça atualizações e iterações rápidas e significativas. Especificações e informações que não estavam disponíveis ou eram fáceis de obter quando o processo foi iniciado podem exigir muito esforço de seu cliente, que provavelmente está pagando, enquanto você não está pagando pelo trabalho deles. Conseguir que o cliente se envolva e invista no processo pode ajudar quando o trabalho acaba sendo algo em que eles precisam gastar tempo e esforço.

Seus clientes, as pessoas de negócios, podem ter algum tipo de problema, desejam algum tipo de solução técnica, mas têm pouca idéia de como a solução pode funcionar e, portanto, têm pouca idéia de como especificar qualquer solução em potencial. Nesse caso, o papel que falta é o de um analista de soluções de negócios, que pode estudar o cliente, seus problemas, fluxos de trabalho etc., e como todas as soluções possíveis podem se encaixar em seus procedimentos corporativos, cultura etc., bem como se há alguma pode ser possível implementar uma solução específica em tempo, dentro do orçamento etc. Isso pode ser uma função altamente interdisciplinar, exigindo algum conhecimento das práticas de negócios (direito, contabilidade, logística, etc.), psicologia do usuário e tecnologia de software.

Parece que você deseja forçar o cliente a ser seu próprio analista de soluções de negócios. Pode não ser uma função em que eles tenham experiência suficiente para garantir uma especificação razoável. E parece que você também não quer assumir esse papel. Se nem você nem seu cliente têm o conhecimento necessário para desempenhar essa função, talvez você não tenha todas as pessoas necessárias para um projeto bem-sucedido.

Às vezes, vários protótipos rápidos com os quais o cliente pode brincar podem ser a única maneira de descobrir e convergir experimentalmente em algum tipo de solução utilizável para as necessidades (expressas e não expressas) do cliente. Isso pode ou não ser adequado para qualquer tipo de contrato não aberto.

ADICIONADO: Se você tentar forçar a saída de um documento de requisitos de clientes que não possuam a experiência necessária, isso pode ser uma enorme bandeira vermelha indicando um desastre que se aproxima.

Não solicite requisitos de interface do usuário ou dados, solicite requisitos de funcionalidade.

Pergunte a eles o que eles querem que o aplicativo faça. Peça que eles mostrem como gostariam de usar o aplicativo. Deixe detalhes como interface do usuário, dados, etc. para começar.

Descobri que muitas vezes os usuários não sabem o que querem em termos de interface do usuário ou dados, mas sabem o que querem em termos de funcionalidade. Por exemplo, eles me dizem "Quero fazer login e ver todas as informações do cliente". Não entre na aparência das telas ou em quais dados eles desejam, apenas obtenha a funcionalidade delas.

Depois disso, faça uma maquete rápida (eu gosto do Balsamiq ). Apenas assuma qual será a interface do usuário / dados e não gaste muito tempo com isso. Em seguida, leve essa maquete de volta ao cliente. A partir daí, eles podem dizer "não precisamos desses campos" ou "Na verdade, queremos uma lista de números de telefone, não apenas um" ou "isso deve ser uma lista suspensa, não uma caixa de listagem".

Depois de ter o ponto de partida, é muito mais fácil detalhar dados e interface do usuário, e acho que determinar a funcionalidade é o melhor ponto de partida.

Eu sugiro que você tente focá-los nos processos de negócios em primeiro lugar. Faça com que eles definam, em um documento ou em uma discussão, como atualmente realizam quaisquer tarefas que seriam tratadas pelo seu software. Em seguida, concentre-se nas partes do processo que eles gostariam que fossem alteradas (o motivo pelo qual desejam o seu software). Use isso como ponto de partida para discutir quais outras partes do processo podem ser aprimoradas, ou mesmo removidas por completo, usando seu software.

Se seu cliente não está acostumado a fornecer requisitos de software, sua equipe deve redigir os requisitos para eles. Espere passar por várias revisões, mas você deve pelo menos fornecer um documento inicial para ajudar a comunicar o que está procurando.

Depois de ter uma boa idéia dos requisitos funcionais do processo de resultado final esperado que incorporará seu software, você poderá começar a desenhar modelos das interfaces. Se você gostaria de deixá-los dar uma facada primeiro, você pode, mas geralmente é melhor você fornecer as idéias iniciais e deixá-los ajustá-las. Você não precisa de código funcional para isso. Capturas de tela de UIs em desenvolvimento, representações HTML dos layouts usando texto de preenchimento estático ou mesmo desenhos (se você tiver um artista decente na equipe) podem ser usadas nas discussões iniciais da UI.

Depois de passar por algumas revisões e todos concordarem com o que é apresentado, obtenha a aprovação do cliente por escrito! Não importa o quanto eles resistam, essa etapa é crucial. Pode ser necessário assegurar a eles que a assinatura dos requisitos não significa que eles não possam ter mais informações sobre o projeto (dependendo da natureza do seu relacionamento com o cliente); nesse caso, você deve descrever como as revisões dos requisitos serão tratados (por exemplo, sujeitos a revisão e aprovação, enviados para uma versão subsequente, com preços separadamente como aprimoramento etc.).

Eu diria a eles que você desenvolverá o recurso do programa por recurso. Até uma próxima reunião, digamos que em 1 a 2 semanas você trabalhará com um número X de recursos. Pode ser 1, 2, 3 ou mais.

Digamos que você comece desenvolvendo a funcionalidade mais importante primeiro. Você precisa começar com os principais recursos. Digamos que você esteja fabricando um caixa eletrônico (por uma questão de argumento). Diga a eles: ok, o primeiro (ou o próximo) da lista dos recursos mais importantes está pedindo a data de nascimento do usuário como uma confirmação ao fazer uma retirada grande (substitua uma funcionalidade no seu projeto que você sabe que não é um dos principais recursos principais que seria implementado a seguir).

Essa afirmação ingênua deve provocar uma reação do cliente. Quando perguntar a eles o que eles fariam em seguida? Qual é o recurso mais importante que ainda não foi feito no projeto e melhor que o que você mencionou.

Reutilizando o exemplo anterior, o cliente pode dizer que está validando o cartão do usuário ou fazendo depósitos, etc. Em seguida, peça para que o definam para você. Não tenha medo de fazer muitas perguntas, até mesmo perguntas ingênuas, se necessário.

Depois de discutir isso com o cliente, você deve ter alguns requisitos para essa peça de funcionalidade. Você poderia definir mais de uma peça de funcionalidade, mas eu manteria o número muito baixo.

Em uma ou duas semanas, reúna-se com o cliente para apresentar o que você fez e obter a opinião dele. Apresente-o ao cliente e obtenha sua opinião se algo precisar ser alterado ou adicionado.

Em seguida, repita o exercício anterior para o próximo monte de recursos. Continue com esse processo de maneira iterativa para o restante do projeto, mantendo-se em contato com o cliente e tendo reuniões regulares para mostrar seu trabalho e planejar o que será feito a seguir (sempre com pequenos pedaços).

Você está falando de engenharia e eles não se importam com isso, na minha experiência; eles também não querem se comprometer a fazer nada (especialmente por escrito) e realmente não querem fazer nenhum trabalho, embora isso não seja específico dos tipos de negócios - ninguém quer fazer um monte de trabalho em um domínio que eles Não sei e não quero saber. Esse é o seu trabalho (na mente deles).

O que faço é o seguinte: converse com eles sobre o que eles querem, no idioma do domínio. Eles não serão capazes ou dispostos a ser precisos da maneira que você esperaria (casos de uso, design por contrato, etc.), mas você pode ser preciso ao traduzir o tipo de lista vaga e arejada de desiderata em design real, e , consequentemente, um documento de design. Se eles lhe oferecerem o tempo para fazer isso formalmente, tanto melhor. Caso contrário, crie um informal e improvisado no qual você possa interagir.

Esta não é uma resposta super feliz, eu sei, mas achei a vida mais fácil quando parei de tentar fazer com que clientes (ou alguém) realmente entrassem no meu universo e falassem meu idioma. Mesmo que eu acabe fazendo as mesmas perguntas várias vezes quando chego a um acordo com o domínio e os requisitos (que muitas vezes são vagamente entendidos pelo cliente), a coisa contra-intuitiva é que as discussões não são frustrantes. De fato, o relacionamento com os clientes tende a ficar mais forte, suponho, porque as pessoas gostam de falar sobre o que sabem, e você acaba entendendo o ponto de vista deles de maneira mais abrangente do que se deixasse para uma abordagem de design mais rigorosa.

Sem um gerente que saiba alguma coisa sobre programação, nunca tive um pouco de sucesso nisso. Em vez disso, a única abordagem que achei que funciona é observar o que realmente está acontecendo.

Eu acho que os programadores têm uma melhor capacidade de visualizar como um programa será antes de ser construído. A prototipagem de papel pode ser uma técnica eficaz para superar isso. Os protótipos de papel são relativamente "baratos" de construir. Ao guiar seus clientes por um simples protótipo de papel, você demonstra a necessidade de pensar "da maneira concentrada necessária para reunir os verdadeiros requisitos". E fornece uma maneira específica de focar: realmente tentando usar o aplicativo que está na sua cabeça!

Além disso, você pode iterar muito rapidamente a partir do seu melhor palpite sobre o que o cliente deseja para o aplicativo que ele realmente deseja, mas tem dificuldades em transmitir. É mais fácil olhar para um protótipo e decidir por que ele não corresponde à aplicação ideal em sua cabeça do que listar todos os requisitos dessa aplicação.

Eu trabalhei em um site onde os outros parceiros eram mais orientados para os negócios. Continuei solicitando requisitos específicos de várias maneiras diferentes. A resposta deles foi basicamente: "Você é o cara do computador, esperamos que você descubra isso. Preferimos fazer o negócio". Eles não estavam preocupados com os detalhes específicos ... até a primeira versão ser lançada! Eles ficaram muito mais entusiasmados com os requisitos após o lançamento, fornecendo todo tipo de feedback que me pouparia muito tempo na frente quando eu havia perguntado inicialmente.

Então, decidi que a iteração é a chave: crie a versão mínima viável e melhore-a com base no feedback. Se os requisitos forem muito vagos e gerais, tome decisões com base em "Qual é a implementação mais simples e rápida?" (exceto design / arquitetura fundamental do sistema). Não pense demais em suposições baseadas no que você acha "certo". Isso acabará perdendo tempo, porque é muito provável que seu processo de pensamento seja diferente dos seus clientes.

Por exemplo: o cliente solicita o recurso de upload de imagens; não elaborará requisitos mais específicos. Construa o mais ingênua possível. Mesmo que você pense que é isso que o cliente deseja, não adicione recursos automáticos de corte, redimensionamento e miniatura. Deixe o cliente ver a versão mínima viável (que você pode desenvolver muito mais rápido que a versão não ingênua), e os requisitos começarão a aparecer como "Isso é o que há de errado na versão atual". Registre cada um desses novos requisitos como "bugs". Você pode priorizar quais são as mais fáceis / mais benéficas.

Na verdade, aconteceu comigo: formulário de solicitação de inscrição com código de convite especial. A idéia era criar um processo de registro viral em que cada novo usuário recebesse alguns convites. Passei muito tempo garantindo que os códigos fossem únicos e pudessem ser usados ​​apenas uma vez. Também fiz um grande esforço para tornar o processo o mais fácil possível, tornando os campos de nome e sobrenome opcionais. No final, os parceiros solicitaram essas alterações: nome e sobrenome obrigatórios, "código" de inscrição válido se alguma coisa foi inserida no campo ... suspiro ~