Permitir que os usuários reúnam os requisitos por conta própria ou os guiem?

Tenho certeza que todo mundo já experimentou algo assim. Você entra em uma reunião com um cliente que tem um projeto. Eles não têm / poucos requisitos em mente e a vaga compreensão do que desejam / precisam. Neste ponto, parece haver duas opções:

1) Diga aos usuários: "Ok, então eu não posso criar algo para você, se você ainda não pode descrevê-lo. Por que não voltamos a se reunir em algumas semanas quando você sabe o que deseja".

2) Encontre-se com os usuários algumas vezes e ajude-os a descobrir o que desejam, orientando-os com o bom método socrático. "Você precisa rastrear X?", "Que tal Y?", "Você precisa da funcionalidade Z?"

Com a primeira opção, você não fica preso fazendo o trabalho de outra pessoa ou adquirindo poderes psíquicos; no entanto, os usuários podem nunca apresentar uma especificação coerente ou podem levar uma eternidade, à medida que o prazo continua se aproximando. Com a segunda opção, você perde muito tempo se tornando um analista de negócios e precisa colocar um monte de conhecimentos de negócios em sua cabeça que provavelmente nunca mais usará novamente, mas será muito mais provável que saia com uma especificação que faz algum sentido.

Para mim, esse é um dos aspectos mais desafiadores do desenvolvimento e sinto que não estou sozinho nesse sentimento. Na sua experiência, qual dessas opções tende a funcionar melhor?

Tenho que admitir que às vezes escolho a opção 3)

3) Ouça as idéias vagas dos clientes, empalidecer com a ideia de passar semanas ajudando-as a descobrir exatamente o que elas querem ... então, descubra o que elas precisam, construa e refatore conforme necessário.

Isso funciona, especialmente para pequenos trabalhos, porque ajuda a evitar as situações em que os clientes têm essa ideia brilhante em mente, o que é impraticável no mundo real.

Isso acontece comigo o tempo todo; "certamente poderíamos fazer ..." é uma frase muito assustadora. Especialmente porque as coisas mencionadas são quase sempre os sinos, assobios e a classe "bom de ter". Eles não entendem isso na afirmação "bem, obviamente, um rastreador de erros e depois ..." a maior parte do trabalho em potencial repousa nas primeiras quatro palavras.

Portanto, às vezes é bom ter uma visão do cliente , aplicar uma dose decente de senso comum dos programadores e criar algo que atenda às suas necessidades.

Em termos da pergunta original; Acho que depende muito do contexto. Se preso ao cliente (ou seja, é através de um contrato de trabalho ao qual estou vinculado ou não há trabalho alternativo), o item 2 é a abordagem mais sensata. Caso contrário, há uma grande probabilidade de que em uma semana você seja apresentado com uma especificação maravilhosa e detalhada ... que é completamente inútil para você como programador.

Muito o mesmo problema mencionado acima (nº 3) e um que deixa você tendo que fazer o nº 2 de qualquer maneira.

se você quiser ser apenas um programador, aguarde até que alguém descubra o que o cliente precisa e depois codifique

se você quer ser um desenvolvedor , e este é o seu cliente, então você pega a mão do cliente e os conduz gentilmente pela densa floresta assustadora de possibilidades até que juntos encontrem o feliz prado cheio de coelhos no cruzamento de Desejos e Necessidades.

ADENDO: esse processo é chamado de "análise e design de sistemas", também conhecido como Consultoria, e nunca deve ser feito de graça

A programação é preliminarmente sobre como resolver os problemas dos usuários. Então, para mim, o esforço e a dor "extras", a fim de obter uma solução satisfatória e funcional para nossos usuários, quase sempre vencem, evitando o aborrecimento "extra" e não oferecendo nada útil no final.

(É claro que existem usuários reais por aí que realmente não têm idéia do que querem, e nenhum esforço pode levá-los a um estado em que possam tomar qualquer decisão significativa. Mas acredito que na maioria dos casos eles têm um problema real, eles estão dispostos a gastar esforço e dinheiro para resolvê-lo e ficarão felizes se pudermos ajudá-los a se aproximar de uma solução que funcione.)

Portanto, o ponto principal é que nosso foco deve ser resolver os problemas dos usuários. Às vezes, isso pode exigir algumas perguntas específicas e dar-lhes mais tempo para descobrir as respostas. Às vezes, é necessário mapear o domínio juntos, em estreita cooperação. Às vezes, é preciso gastar algum tempo fazendo esboços / protótipos / modelos simples, depois mostrando o resultado e perguntando "isso se parece com o que você tinha em mente?" (depois jogam fora o protótipo quando dizem "na verdade, eu estava pensando em algo completamente diferente ..." e recomeçando ... :-)

A verdadeira habilidade está em escolher a abordagem certa para a hora certa.

Por último, mas não menos importante, na minha experiência, boas soluções quase sempre exigem pelo menos algum conhecimento de domínio da parte do desenvolvedor. Sem isso, você não tem uma linguagem comum real com o usuário, portanto, não há garantia alguma de que o que você entrega será realmente útil para ele. Os usuários normalmente não têm muita pista sobre tecnologia, portanto, não têm idéia do que é e do que não é possível e qual é o custo de diferentes abordagens / recursos. Como não podemos razoavelmente esperar que eles aprendam tecnologia com detalhes suficientes, devemos dar esse passo extra a partir do final da ponte.

Isso pode ser visto como um esforço "extra" que não compensa - no entanto, prefiro vê-lo como investimento, por dois motivos:

• isso me ajuda a fornecer boas soluções, que, a longo prazo, aumentam meu valor de mercado como desenvolvedor e
• domínios diferentes não são completamente distintos; portanto, pelo menos parte desse conhecimento de domínio provavelmente será reutilizável em shows futuros.

Como desenvolvedor de software, parte de sua tarefa é obter uma compreensão suficiente do domínio em que o software será usado. Assim, fazer parte da fase inicial de um projeto é extremamente valioso (em termos de tempo e experiência do cliente) . Sim, isso significa fazer uma análise completa de domínio e requisitos. É o momento perfeito para incorporar os usuários-alvo, entrevistá-los ou caminhar pelo local onde seu software será usado.

Porém, adquirir essa habilidade é quase uma forma de arte, especialmente quando o domínio não está conectado a uma disciplina de engenharia. Suas perguntas óbvias podem parecer assustadoras para o cliente, sua presença in situ pode não ser desejada, sua falta de compreensão da estrutura social do seu público-alvo pode desmoronar as conexões ainda frágeis.

Falhar em entender os meandros dessa fase geralmente leva à decepção, tanto com os desenvolvedores de software quanto com o cliente. Gostaríamos de passar por essa fase cada vez mais rápido ou acabar com ela completamente. Os resultados são muitas vezes desastrosos: após o início apressado, durante o desenvolvimento, as apostas em obter sucesso são cada vez maiores e fica cada vez mais difícil voltar à prancheta. Quando o sistema finalmente termina e milhões são gastos, nem o cliente nem a empresa de engenharia estão dispostos a admitir sua falha, levando à introdução forçada de um sistema com falha.

Uma alternativa é deixar um analista de negócios fazer o trabalho por você. Isso pode ser sensato para alguns produtos, e o analista geralmente pode ser um intermediário, mas criará apenas mais canais de comunicação (e, portanto, uma maior chance de erro).

De qualquer forma: reescrever um pedaço de código nunca supera reescrever um pedaço de requisitos.

ps talvez você ache que estou defendendo o método cascata. Não acredito no "grande design inicial", mas acredito que o esforço de análise de domínio deve ser proporcional ao esforço de implementação. Pode-se fazer vários ciclos (protótipo, candidatos a liberação etc.).

Definitivamente, a opção 2, a menos que seus usuários sejam desenvolvedores (mesmo assim, a opção 2 pode ser necessária).

Muitos dos ciclos de vida de desenvolvimento de software concentram-se na coleta de requisitos. A maioria dos usuários não apenas não sabe o que deseja, como também não sabe o que é possível; portanto, trabalhar com o usuário para entender o que ele precisa é uma tarefa crítica de desenvolvimento de software.

Eu acho que você precisa ir com as duas opções. Deixe-os sair e decidir o que querem. Então, quando houver uma idéia concreta a ser usada como ponto de partida, guie-os para ajudar a refinar os requisitos para algo útil.

Você não quer pular para a Opção 2 quando eles mal conseguem articular o que querem, pois isso tornará todo o processo mais lento e frustrante (a menos que eles já tenham uma ideia muito clara do que querem quando o procuram, mas na minha experiência, isso é muito raro). Faça com que eles juntem suas idéias. Peça que escrevam algo no papel, descreva o que eles querem em termos de sistemas existentes, se possível (por exemplo, "queremos um site como blahblah.com, mas com essas diferenças ... queremos uma ferramenta que execute a Tarefa A como o Produto X , mas a interface do usuário também deve executar a Tarefa B ... "). Então é um bom momento para começar a refinar o que eles desejam em requisitos muito específicos que você pode usar para criar o sistema.

Em geral, os clientes entram em contato com você sabendo exatamente o que eles acham que precisam. Infelizmente, é isso que eles dirão, em vez de descrever os problemas que levam à solução que eles acham que você fornecerá.

Para projetar algo que atenda às suas necessidades, você deve identificar essas necessidades e, para fazer isso, alguém terá que segurar o cliente e extrair essas necessidades. Se ninguém mais pode fazer isso, então você deve. (Se alguém achar que pode, talvez seja necessário sentar com ela e extrair as necessidades reais mais tarde ...)

Com a opção 2, em várias reuniões, esperamos que você possa treinar o cliente para compartilhar problemas com você, em vez de soluções. (Mesmo que o cliente tenha capacidade técnica - por exemplo, ele não tem disponibilidade para fazer esse trabalho e precise que você faça isso - ele ainda pode estar se concentrando em uma implementação que não é ideal para o cliente final.) importa muito qual processo de desenvolvimento você usa, você ainda precisará ir e voltar algumas vezes até que eles possam responder a perguntas de maneira a definir especificações para você.

Lembre-se, você deseja detectar defeitos o mais cedo possível no ciclo de desenvolvimento. Se você conseguir capturá-los durante os requisitos, e não durante a codificação ou teste, economizará muito tempo.

A opção 1 é uma excelente maneira de evitar o trabalho. Eu o usei quando achei que o trabalho era desnecessário ou tinha coisas mais importantes a fazer.

Primeiro, os usuários não sabem o que os computadores podem fazer. A maioria de nós passou anos aprendendo a entender computadores e computação, e o que é óbvio para nós pode não ser facilmente compreensível para alguém que passou esses anos aprendendo outras coisas.

Segundo, os usuários não sabem necessariamente o que precisam, e geralmente não sabem o que querem, em nenhum sentido acionável.

Para fazer uma analogia, quando comprei minha casa atual, um designer de interiores selecionou as cores das paredes dos quartos no piso principal (primeiro EUA, no Reino Unido). Eu nunca teria escolhido essas cores pessoalmente. Eu queria uma casa que parecesse boa e consegui. Se o designer tivesse me ouvido e me dado algo que eu pudesse articular, não teria saído tão bem.

A única maneira de oferecer aos usuários algo que faz o que eles precisam da maneira que eles gostam é trabalhar com eles.