condensando os requisitos de negócios em especificações técnicas [fechado]

Trabalho na área de TI de um grande varejista e acabamos de iniciar um projeto com a empresa para redesenhar um sistema essencial para o nosso site.

Os usuários corporativos sabem que desejam atualizar o sistema e melhorá-lo. Eles têm alguns princípios de nível muito alto sobre como deve funcionar, mas é isso.

A gerência deseja que a equipe de desenvolvimento comece a "fazer coisas" porque há recursos disponíveis.

Estou lutando para pensar na melhor maneira de gastar nosso tempo como uma equipe de desenvolvimento. Sentar-se com os usuários de negócios não produziu muito mais do que alguns princípios de alto nível ou coisas que eles não querem que ele faça, mas certamente nada do que eu consideraria abordar os requisitos.

Como você pode vincular a implementação concreta de recursos a requisitos vagos de negócios e garantir que os negócios fiquem satisfeitos com os resultados, dada a falta de conhecimento técnico e a participação de uma empresa?

Pela minha experiência, eu não gastaria um único minuto desenvolvendo. Nem mesmo um pequeno pedaço de código. Nesta fase, onde o cliente não sabe o que deseja, é realmente importante fazer um bom trabalho de consultoria . É tão importante para eles quanto para você.

Por trás de cada projeto, há uma necessidade (às vezes não é óbvia) relacionada aos negócios do cliente. Portanto, para esclarecer a necessidade , você precisa primeiro aprender o negócio o máximo possível. Então, você poderá levar o cliente a uma solução funcional.

Durante o aprendizado, tenha cuidado na hora de diferenciar necessidades e desejos . Que necessidade do cliente pode ou não ser a mesma que o cliente deseja?

Enquanto a análise, se o cliente não tomar decisões, faça você mesmo. Como consultor, seu trabalho é dar conselhos e liderar o processo.

Como o @Ewan apontou, é mais fácil para os clientes tomar decisões, se houver alguma escolha a fazer. Oferecer várias alternativas (expondo seus prós / contras) facilita a tomada de decisões. A zombaria de protótipos é uma boa maneira de fornecer uma visão geral do que você tem em mente para eles. O cliente terá o primeiro contato (e sentimentos) sobre como as coisas serão. Ao fazer este exercício de "criatividade", você verá rapidamente as luzes e sombras do projeto antes que elas se tornem um problema.

Tente obter o máximo de feedback possível do usuário final . Tantas vezes a pessoa a quem chamamos "cliente", não é quem vai usar o sistema . Em tal situação, você obterá melhor feedback do usuário final real. Eles fornecerão dicas valiosas sobre o que eles precisam. Identificar bem quem pode fornecer as respostas certas para suas perguntas ajudará você a atender às expectativas do cliente.

Depois de coletar um bom conjunto de requisitos, coloque-os no protótipo. Metodologias ágeis como o SCRUM funcionam bem nesse estágio. Fazendo sprints sobre o protótipo.

Os protótipos serão descartados / modificados ao longo dos sprints. Você também pode "orientar" o cliente para o que melhor lhe convier. ;-). À procura de um acordo ganha-ganha.

Tento impedir que os Gerentes iniciem o desenvolvimento antes que qualquer requisito bem definido e mensurável seja assinado. Caso contrário, iniciar com requisitos indefinidos está fadado a falhar mal. Muito dinheiro e tempo serão desperdiçados (sem garantia de recuperá-lo) porque alguém decidiu implementar "o Caos". O caos e a incerteza em que nosso cliente tão querido e confuso vive agora.

É chocante ver empresas cujos funcionários fazem seu trabalho, mas eles não são capazes de explicar (razoavelmente) a você como . Também é chocante ver quantos gerentes de projeto não se importam com esse problema, eles apenas dizem "sim a todos" ou "vamos começar e vamos ver o que acontece".

Finalmente, @Ewan apontou novamente para o ponto mais importante.

Faça com que o cliente assine os que eles desejam e implementam.

Não se esqueça de definir claramente quais requisitos e condições precisam ser atendidos para dizer que o projeto está concluído . As condições de aceitação

Não há necessidade de dizer o porquê.

Escreva um documento propondo 2 ou 3 soluções nas seguintes linhas:

"Para alcançar 'alto nível de diretor x', propomos 'Solução técnica y', que será o que a solução técnica faz '"

Faça com que o cliente assine os que eles desejam e implementam.

É difícil aconselhar sem poder julgar com precisão a música ambiente.

Ou:

Os usuários e a gerência de negócios não estão fazendo seu trabalho e estão apenas chutando a lata no caminho para os desenvolvedores lidarem (e, assim, podem chutá-los quando as coisas dão errado).

Ou:

Eles realmente não têm certeza do que querem e precisam ser guiados pela equipe de desenvolvimento.

Naturalmente, o segundo cenário é mais preferível. Você pode moldar alguns desenhos e enrolar na sujeira com ele até ter um plano das sortes.

Se você lida com o primeiro cenário, fique absolutamente claro que as coisas que matam os projetos repetidamente são requisitos confusos e não possuem o conceito de "pronto". Certamente o projeto será concluído eventualmente, mas quanto dinheiro será incendiado antes disso?

Em algum momento, os desenvolvedores precisam de um conjunto de requisitos onde possam desenvolver um aplicativo e, posteriormente, verificar se ele atende aos requisitos ou não. E então eles constroem um aplicativo que atende aos requisitos.

E é uma idéia muito, muito boa ter requisitos em que um aplicativo que atenda aos requisitos beneficie os negócios :-)

Alguém precisa criar esses requisitos. Os donos da empresa não podem. Os desenvolvedores não querem. Os desenvolvedores tentaram fazer com que os proprietários da empresa criassem requisitos, mas não obtiveram sucesso. Ainda assim, alguém precisa criar esses requisitos.

Você pode tentar encontrar alguém na empresa e torná-lo seu trabalho. Não como os desenvolvedores fizeram no começo, tentando solicitar requisitos, mas falhando, mas escolha uma pessoa e faça dela o seu trabalho em período integral. Se a equipe de desenvolvimento achar que pode criar os requisitos, sugira-o à empresa e receba o trabalho e a autoridade para fazê-lo.

De qualquer maneira, será o trabalho de alguém criar os requisitos. E é preciso deixar claro que, se a equipe de desenvolvimento criar os requisitos, os requisitos serão os que a empresa obterá e, se não gostar, precisará garantir que os requisitos sejam alterados. É melhor fazer isso antes do início do trabalho de desenvolvimento.

E você não precisa dar escolhas às pessoas. Você pode dizer a eles que o que está nos requisitos é o que acontecerá, e eles podem assinar ou reclamar e os requisitos podem ser alterados.

Se você acha que um protótipo é muito polido e confunde o cliente, basta esboçá-lo. Você pode ter várias versões se achar que isso ajudará o prompt do cliente.

Isso atenderá à necessidade da gerência de fazer coisas sem criar um monte de código que você jogará fora (se você souber o que é bom para você).

O cliente também precisa saber que precisa pagar por esse tipo de coisa. Caso contrário, há pouco incentivo para fazê-los avançar no projeto. Pode ser benéfico para as reuniões se você puder restringir aqueles que realmente estão envolvidos no projeto e na tomada de decisões sem que muitas pessoas enviem sugestões inúteis que apenas atrasarão as coisas.

Vamos fazer um experimento mental: imagine que você quer construir uma casa do zero e não sabe nada sobre construção. Como você descreve os requisitos para o construtor? Mesmo se você pudesse, elas provavelmente seriam declarações vagas, como "Quero ter bastante espaço no armário" e "Quero uma cozinha moderna". Obviamente, não se pode esperar que você conheça todos os detalhes: o arquiteto que desenha os planos fará uma tonelada de perguntas e tomará algumas decisões por conta própria, de acordo com as melhores práticas do setor.

Aqui é onde você está: alguém decidiu que quer algo, mas está tendo dificuldades para explicar exatamente o que deseja para você. É seu trabalho trabalhar junto com eles para descobrir isso.

Se houver um recurso disponível e você tiver princípios de alto nível, comece a decompor esses princípios em histórias de usuários. A partir daí, você pode criar uma lista de tarefas a serem executadas. Faça sugestões ao longo do caminho, mas certifique-se de entender completamente as necessidades comerciais da atualização primeiro. O desempenho é ruim? Isso é inseguro? O design está desatualizado? Cabe a você lidar com muitos detalhes que seus usuários finais não conhecem. Documente as escolhas que você fez e por quê, e faça com que os usuários comerciais (ou a pessoa aplicável) os assinem. Agora você tem requisitos!

Lembre-se de que um desenvolvedor não precisa codificar o tempo todo: ele também deve planejar uma parte significativa do tempo. Algumas das habilidades sociais mais importantes que um desenvolvedor pode ter derivado desse processo de pegar vagas "idéias de negócios" e transformá-las em um projeto de trabalho, que gera um produto adequado às necessidades da empresa.

Construir um protótipo é uma ótima idéia para obter feedback específico, o que levará a melhores requisitos. Mantenha-o leve e simples: existem ferramentas disponíveis (aqui está uma ) que permitem criar modelos de trabalho sem escrever uma única linha de código.

Além disso, um protótipo básico pode ser mal interpretado pelos usuários de negócios ...

Claro que pode: é por isso que a comunicação é tão essencial. Explique que é um protótipo repetidamente. Coloque uma marca d'água com a mensagem 'DRAFT', qualquer que seja. Os usuários corporativos, especialmente aqueles que não são conhecedores de tecnologia, terão um tempo incrivelmente difícil simplesmente fornecendo requisitos, especialmente se não houver nada para ver. Se você conseguir criar rapidamente um protótipo com o qual eles possam brincar, será mais fácil dizer "eu prefiro isso do que isso" quando você o vir.