Qual é a mentalidade ideal para um desenvolvedor participando de uma reunião de reunião de requisitos?

4

Como desenvolvedor de nível médio da minha equipe, participo de reuniões de planejamento de coleta de requisitos / planejamento de projetos dos quais participarei. Eu tenho achado difícil apresentar as questões que agregam valor à discussão ou ao meu conhecimento. Depois de algumas auto-análises, descobri que saber que há um engenheiro sênior encarregado do projeto que lideraria a discussão me fez recuar em algumas dessas discussões. Mas eu quero chegar a um ponto em que me seja confiada mais responsabilidade e ganhe habilidades para lidar com projetos por conta própria. Embora a mentalidade seja um termo abstrato para perguntar, gostaria de obter alguns conselhos sobre algumas coisas listadas abaixo:

  • Que tipo de preparação eu precisarei para ganhar mais dessas reuniões? A partir de observações de membros da equipe, percebi que entender o que todos os sistemas que o projeto vai impactar, quais decisões de negócios terão maior impacto no design do projeto etc. são alguns deles.

  • Preciso evitar pensar em detalhes de implementação de baixo nível para cada requisito. Por um lado, eu sinto que é importante considerá-los porque eu vou saber sobre a viabilidade, mas eu também entendo que dificulta considerar todas as escolhas.

  • Finalmente, como desenvolvedor, com o que não devo me preocupar?

por quirkystack 08.01.2015 / 23:24
fonte

3 respostas

12

Responda às suas perguntas em ordem:

  1. A mentalidade em relação a isso, em termos de preparação, é fazer as perguntas certas para que o usuário saiba exatamente o que deseja. Isso é muito mais difícil do que parece. Preciso enfatizar fazendo as perguntas certas . Seja específico, se houver alguma ambiguidade, faça outra pergunta. Normalmente, durante essas reuniões, uma resposta do cliente gera três novas perguntas. Uma vez que você saiba o que eles querem, então é seu trabalho descobrir como isso afeta os diferentes sistemas, não os deles.

Se houver algo que o cliente quer em termos de requisitos impossíveis, diga-lhes (meus professores costumavam chamá-lo de "asas em um carro"). Às vezes, os clientes simplesmente não conhecem o software o suficiente para conhecer os recursos. Contornar isso.

  1. Não, isso ocorre durante a fase de design. Se não puder funcionar, os requisitos são revisitados.

  2. Não se preocupe em acertar na primeira vez, porque você definitivamente não vai. Os requisitos são estragados o tempo todo por recursos, usuários querendo coisas novas, mas nunca dizendo, etc. Prepare-se e vá com o fluxo.

por 08.01.2015 / 23:35
fonte
4

Os usuários geralmente sabem exatamente o seu trabalho diário e quais problemas precisam resolver. O que eles normalmente não sabem é

a) como o software precisa ser exatamente para suportar esse processo.

b) como eles podem explicar seu processo para você.

Portanto, concentre-se em perguntas para entender o que o usuário realmente deseja (suas metas, seu processo de trabalho) e não se um botão deve ser azul, vermelho, à esquerda ou à direita. caixa de diálogo. Muitas vezes não é muito importante esclarecer qualquer ambigüidade, mas as ambigüidades certas .

No que diz respeito a "detalhes de baixo nível": evite que durante a reunião - muitas vezes existem soluções diferentes para atingir o mesmo objetivo, com diferentes detalhes de baixo nível, diferentes custos / esforço de desenvolvimento, diferente viabilidade. Pela minha experiência, é muito melhor pensar um pouco sobre os requisitos (após a reunião!) E sugerir uma solução viável mais tarde, quando você fizer uma análise completa dos requisitos.

E tente evitar se preocupar com o possível esforço de desenvolvimento para requisitos específicos (pelo menos, não durante a reunião). Apenas escrever todos os requisitos abaixo não significa que eles terão que ser implementados 1: 1. Após a reunião, você ou a equipe terá a oportunidade de analisá-los, fazer estimativas para a implementação (provavelmente diferentes estimativas para diferentes soluções possíveis para o mesmo requisito) e, posteriormente, os requisitos serão priorizados ou discutidos novamente. O que você deve evitar é dizer às pessoas quaisquer estimativas durante a reunião fora do seu estômago, mesmo que elas perguntem ou tentem pressioná-lo. Basta dizer "vou dar-lhe uma resposta mais tarde".

    
por 09.01.2015 / 00:15
fonte
3

O que eu tento enfatizar ao fazer a coleta de requisitos é que, se isso é para substituir um sistema existente, não pensar em como você faz as coisas no sistema existente, mas qual seria a maneira ideal de realizar o que você precisa fazer.

Com frequência, os usuários ficam presos ao modo como as coisas são feitas, e só podem descrever suas necessidades dessa maneira.

A coisa mais importante para você como implementador é entender o que eles estão realmente tentando realizar. Um livro que me ajudou enquanto eu estava aprendendo como fazer análise de negócios era Padrões de requisitos de software este livro discute como obter uma compreensão mais profunda de alguns dos requisitos implícitos que às vezes são superados.

Além disso, Design dirigido por domínio é um bom livro para estudar (especialmente com o conceito de Ubiquitous Language que basicamente diz usar os termos que os especialistas de domínio usam não os traduzem para "desenvolvedor falar" tanto se perde na tradução).

Outro item importante é tornar-se informado o mais rápido possível sobre o seu domínio de destino. Quando me desenvolvi para uma empresa de logística, acredito que aprendi sobre Transportadoras, Associados, Partes Responsáveis, Menos de Caminhões, Centrais, Docas e tudo mais que eu precisava saber para ter uma conversa inteligente com o negócio. Quando trabalhei para uma empresa de petróleo, aproveitei para aprender sobre os Bores, os poços, os campos, a produção, a saturação e todas as coisas divertidas que acompanhavam esse setor.

Esse é o conselho mais valioso que posso dar, aprender o setor para o qual você está desenvolvendo o software e conseguir reunir os melhores requisitos dos usuários.

    
por 10.01.2015 / 01:03
fonte