Gerenciamento de requisitos de dicas

O que significa “melhores práticas” em Gerenciamento de Requisitos?

É tão interessante para mim que todos falam sobre querer treinar em “melhores práticas”. Este termo é freqüentemente usado para descrever o tipo de consultoria que também podemos fornecer. O que isso realmente significa? Acredito que todos nós alimentamos o mito de que as melhores práticas podem ser a base para o treinamento de indivíduos. As melhores práticas não são treinadas, são experientes.

Se compararmos a abordagem das melhores práticas à natureza, sabemos que não apenas as espécies mais fortes, mas também as mais prolíficas que sobrevivem. Esse é um dos motivos pelos quais é tão difícil mudar os processos em uma organização. Pense nisso por um momento. Os mais fortes e prolíficos provavelmente descrevem a maioria dos indivíduos que você tem em praticamente qualquer grupo de sua organização. Tenho visto isso várias vezes no campo da Engenharia de Sistemas. Os engenheiros mais fortes e prolíficos costumam fazer seu trabalho há muitos anos e têm uma maneira específica de fazê-lo. Pedir-lhes que experimentem novas técnicas e ferramentas costuma ser fútil, pois eles não sabem como isso vai melhorar o trabalho já maravilhoso que estão fazendo. A prática deles vai sobreviver se continuarmos a empurrar para eles uma abordagem de boas práticas.

Então o que fazemos? As melhores práticas começam com nossa própria experiência pessoal. Todos os livros que você pega e lê sobre as melhores práticas são sobre a experiência pessoal do autor em alguma área, seja casos de uso, elicitação de requisitos, engenharia de sistema, testes, etc. Em algum ponto, uma organização decide que precisa de um processo consistente em toda a organização. Existem muitos bons motivos para fazer isso. Portanto, um grupo é formado para propor um processo que reflita essas melhores práticas. Como há muitas práticas recomendadas no grupo, adivinhe quem geralmente vence? O mais forte e o mais prolífico. E a prática recomendada resultante geralmente resulta em um compromisso entre o grupo de práticas recomendadas e aqueles na organização que desempenham essa função. Estudos indicam que leva cerca de cinco anos para realmente definir esse processo em toda a organização. Em seguida, vêm os consultores que percebem essas práticas. Eles podem ver uma oportunidade de negócios e, portanto, apoiar as práticas que os levarão a mais negócios para eles. Eles começam a aparecer em conferências e feiras de negócios promovendo essas práticas e escrevendo livros. (Pense sobre o Abordagem ágil.) Como procuram negócios, estão focados nas práticas que lhes proporcionarão mais negócios. Estamos sempre em busca das melhores práticas, por isso não precisamos saber com que frequência funciona, apenas que CAN trabalhos. E assim, continuamos a promover essa prática em toda a organização, na esperança de obter todos os benefícios dos quais falamos ao longo dos anos.

Devemos lembrar que as melhores práticas são baseadas em retrospectiva. As melhores práticas para o seu trabalho são desenvolvidas à medida que você aprende sobre esse trabalho. Certamente podemos aprender uns com os outros. Esse não é o ponto desta discussão. A questão é que precisamos basear nossas melhores práticas principalmente em nossa própria experiência prática. Devemos ser criteriosos em como aplicamos as melhores práticas em nossos trabalhos e em nossas organizações. Só não aceite as melhores práticas porque alguém escreveu um livro sobre isso ou falou sobre isso em uma conferência. Pesquise a prática e determine o ambiente em que foram promovidas. Este ambiente é comparável ao que você está hoje? Freqüentemente, há pouca semelhança. Escolha as dicas das melhores práticas que se aplicam a você e ao seu trabalho e que lhe trarão benefícios reais. Comece com pequenas mudanças e desenvolva a prática conforme ela é aplicada em sua organização. Saiba onde teve sucesso e onde falhou e aprenda com isso. Lembre-se de que, se você tiver objetores fortes e prolíficos à prática, precisará de alguém com conhecimento prático da prática para ajudá-los a ver como essa prática pode ajudá-los. Ouça-os e trate de suas preocupações. Não os ignore e torça para que desapareçam. Eles não vão.

Em outras palavras, apenas dizer as palavras “prática recomendada” não significa que será uma prática recomendada para você.

Como melhorar sua definição de requisitos?

Sempre que uma mudança é feita em um processo ou nas ferramentas que são usados ​​para apoiar o processo, há uma curva de aprendizado que afetará o tempo necessário para realizar esse processo. Ao começar a pensar em como melhorar seu processo de definição de requisitos, lembre-se de que haverá um esforço associado a essa mudança. Na maioria dos casos, ocorre diminuição da produtividade à medida que o trabalho começa a progredir. Esta diminuição é freqüentemente chamada de “curva J”. Conforme os usuários tentam mudar a maneira como executam uma tarefa específica, eles chegam a um ponto em que sentem que é simplesmente muito difícil fazer a mudança. A tentação aqui é voltar à velha maneira de fazer as coisas apenas para concluir a tarefa. Sem um plano para superar esse obstáculo, muitas organizações falham em seu objetivo de fazer essa mudança. Esse desafio é verdadeiro para processos e ferramentas. Existem duas estratégias que podem acelerar a adoção de habilidades ou ferramentas.

Primeiro, há o abordagem de profundidade. Na abordagem aprofundada, um grupo central de pessoas é selecionado e treinado no novo processo ou ferramenta e continua a receber orientação à medida que atravessa o abismo do treinamento para o trabalho em um projeto real. Os mentores geralmente são consultores externos com experiência na área de habilidades específicas. É importante ter especialistas disponíveis para ajudar os profissionais a começar a usar suas novas habilidades em um projeto ao vivo. Este grupo central é bastante pequeno e a intenção é usá-los como consultores para novos projetos que usarão as novas habilidades. Eles se tornam especialistas que passam de um projeto para outro para ajudar essas pessoas a usar suas novas habilidades.

A abordagem ampla concentra-se em uma base sólida de habilidades de práticas recomendadas que serão aprimoradas com o tempo. Nessa abordagem, os mentores são trazidos para fornecer essa base de habilidades de melhores práticas, geralmente por meio de treinamento padrão na área de habilidades específicas. Normalmente, os processos e modelos padrão são definidos e documentados para uso pelas várias equipes de projeto. O treinamento inicial é fornecido a um grande grupo de indivíduos versus o grupo menor e focado mencionado na abordagem em profundidade. À medida que os projetos começam a usar as novas habilidades e aprendem mais sobre como suas tarefas específicas são afetadas, esses resultados são alimentados na base das melhores práticas para que possam ser refinados com o tempo.

Seja qual for o método que você escolher para gerenciar esse esforço, é fundamental para fazer as alterações necessárias com sucesso. Sem um plano, essas mudanças muitas vezes caem no esquecimento quando a crise de cronograma e orçamento é sentida. Fazer esse tipo de mudança requer disciplina, apoio e determinação. Cada projeto deve ser avaliado continuamente para garantir que as novas habilidades estejam sendo usadas.

Pense em uma mudança simples em seu processo de definição de requisitos. Quem são os especialistas em quem você pode confiar internamente? Você precisa de ajuda externa para treinamento e / ou orientação? Onde você irá para este treinamento e orientação? Seu processo está bem documentado hoje ou você está começando do zero? Qual é o seu plano para garantir o sucesso (profundidade, amplitude, ambos)? Qual é o prazo para a mudança?

“Insanidade é fazer a mesma coisa repetidamente e esperar um resultado diferente”. (Albert Einstein) Se você se sentir assim, comece a fazer alterações que trarão os resultados que deseja.

Dicas para uma melhor coleta de requisitos

Se você estiver entrevistando usuários e basicamente disser “Trick or Treat - me dê alguns bons requisitos”, adivinhe o que você encontrará? Você obterá uma mistura de coisas que os usuários gostariam de ver. Alguns serão importantes para você e outros não. Você terá que classificar todas essas necessidades e classificá-las em categorias. Normalmente chamamos essas categorias de recursos. Alguns desses recursos serão pertinentes ao projeto e outros não. Portanto, se você está começando a reunir requisitos, por que não se concentra mais nas perguntas que faz? Pesquise e analise todas as informações disponíveis que sejam pertinentes ao sistema. Identifique os usuários finais (você não precisa enganar ou tratar em toda a subdivisão, concentre-se em algumas ruas onde as guloseimas realmente boas são fornecidas) e marque reuniões com eles. 

Identifique os processos que são afetados pelo projeto - quais estão mudando, quais são novos, não são mais necessários? Pergunte aos usuários quais processos estão funcionando bem para eles? Trabalhe para entender como eles estão fazendo seu trabalho hoje.

Em segundo lugar, depois de classificar os requisitos em recursos, você precisará priorizar esses recursos. Quais são os "favoritos" do cliente para fazer primeiro?Às vezes, deixamos de priorizar de fato e acabamos trabalhando primeiro nas partes fáceis do sistema, em vez de nos concentrarmos nas partes do sistema que são de alto risco ou não são bem compreendidas.

No final do projeto, revisite o que aconteceu. Podemos perguntar se seguíssemos pelas ruas certas, se seguíssemos o processo ou desviávamos por algum motivo, recebíamos tantos doces quanto esperávamos? O que funcionou bem? Que mudanças podem ser feitas para melhorar o processo? Obtivemos os resultados finais esperados? Os usuários ficaram satisfeitos com o produto?

3 dicas para treinar sua equipe em gerenciamento de requisitos

Pedir a alguém que nunca escreveu ou administrou requisitos para seguir um processo de requisitos robusto e complexo é como pedir a uma criança de cinco anos para tocar a Sonata ao Luar de Beethoven. E como geralmente não fornecemos nenhum treinamento ou orientação, vamos pedir que eles aprendam a tocar essa peça por conta própria. Isso é o que estamos fazendo quando colocamos nossos analistas em um processo de requisitos complexo.

Eu sugiro que consideremos treinar nossa equipe. Vamos parar de pensar que todos nós apenas “sabemos fazer o nosso trabalho”. Não é verdade. Podemos aprender a tocar essa peça sozinhos. Eu sugeriria que, em vez de levar cinco anos, levaria dez anos sozinho. E assim é com nossos engenheiros e analistas de requisitos. Podemos deixá-los aprender por conta própria. Ou podemos dar-lhes algum treinamento, orientação e tempo para praticar.

Claro, a chave para fazer esse trabalho (sem trocadilhos) é ter algum tipo de processo definido que usamos para treinar nossos analistas. Eu odiava essa palavra “processo”, mas é importante. Aqui estão algumas sugestões para transformar seus novos analistas de requisitos em analistas de requisitos especialistas rapidamente.

  1. Forneça treinamento para seus analistas em torno de seu processo específico, usando seus requisitos e resultados, para que o treinamento seja mais real. Classes genéricas sobre definição e gerenciamento de requisitos são ótimas, mas devem estar alinhadas com os processos que você está seguindo em sua organização. Se você estiver trabalhando com um consultor externo, espere que haja algum esforço para personalizar o treinamento para você, mas o investimento valerá a pena.
  2. Atribua um mentor para seus novos analistas. Que alguém que “esteve lá fizesse isso” e tem as feridas e cicatrizes para provar isso ajude o novo analista e mostre-lhe o caminho. Isso ajudará a eliminar esse pensamento de “conhecimento tribal”. Deixe-os auxiliar nas sessões de elicitação, revisar os documentos de requisitos com o analista e ser um recurso para eles. 
  3. Deixe o analista praticar. Isso pode não parecer muito prático, mas não inicie um novo analista em um projeto que seja crítico para a empresa ou que tenha tanta história e polêmica que será difícil seguir em frente. Deixe-os “praticar” em um projeto simples e bem compreendido para molhar os pés.
3 dicas para treinar sua equipe em gerenciamento de requisitos

7 dicas para escrever requisitos melhores

Escrever requisitos tem sido um desafio para nós há muitas décadas. Por que é tão difícil? Bem, um dos motivos é o desafio da linguagem de requisitos. Sabemos que precisamos escrever requisitos de uma maneira que possam ser lidos e compreendidos pelo leitor. Se estivermos escrevendo requisitos do usuário, o leitor é o proprietário da empresa, usuário final ou parte interessada e o foco é escrever em uma linguagem “natural”. O problema com uma linguagem “natural”, entretanto, é que é muito imprecisa e provavelmente será mal interpretada ou mal compreendida. Como podemos preencher essa lacuna?

Estou surpreso com o número de analistas com quem falo que resistem a qualquer tipo de estrutura na redação de seus requisitos. Eles parecem estar bastante satisfeitos com sua abordagem não estruturada, que geralmente consiste em parágrafos descritivos e sentenças que implicam em muitos requisitos adicionais. Seus leitores gostam desse método, eles argumentam. O problema é que, uma vez que esses “requisitos” são entregues aos desenvolvedores ou analistas de sistemas, geralmente há muita discussão para esclarecer o que esses requisitos realmente significam.

Eu acredito que há um compromisso a ser feito aqui. 

Aqui estão algumas dicas para ajudar a preencher essa lacuna.

  1. Escreva em voz ativa, certificando-se de que um dos atores é o sujeito de todas as frases.
  2. Certifique-se de que cada frase é uma frase completa e gramaticalmente correta com um assunto, verbo e predicado.
  3. Especifique claramente quais informações são passadas entre os atores.
  4. Mantenha um nível consistente de detalhes. Por exemplo, para requisitos do usuário, um usuário final deve ser o sujeito de cada frase. Para requisitos de sistema, um sistema deve ser o assunto de cada frase.
  5. Cada requisito deve descrever critérios de sucesso claros. Por exemplo, “O usuário deve ser capaz de visualizar o Relatório de Registro de Auditoria”.
  6. Cada requisito deve indicar uma única ação e objetivo. Cuidado com o uso excessivo de "e" e "ou". Por exemplo, “Se a última sexta-feira do mês e o pagamento vencerem no dia 31, e se o dia 31 for a última sexta-feira do mês, enviar o pagamento naquele dia após as 6h, horário do leste, resultará em atraso no pagamento” . Eu desafio você a entender isso!
  7. Um requisito não deve ter uma cláusula de escape. Por exemplo, “O sistema deve determinar o número de tentativas de login, exceto quando o usuário inseriu claramente um nome de usuário incorreto”.

4 dicas para ajudá-lo a gerenciar requisitos complexos do cliente

Como você lidaria com este cenário? Um cliente afirmou que deseja que o sistema seja amigável. Eu chamo isso de um requisito complexo porque é efetivamente uma coleção de muitos requisitos exclusivos. Os requisitos gerados devem estar em um nível atômico. Em outras palavras, cada requisito deve ser um pensamento único e completo. Mas qual é a melhor maneira de chegar a esse nível com o cliente? A realidade (e a experiência) nos dizem que muitos requisitos são, na verdade, muito mais complexos do que o declarado.  

Lembre-se de que não devemos esperar que o cliente nos forneça bons requisitos. Eles deveriam nos fornecer o problema que desejam resolver. Se isso não estiver claro, precisamos perguntar a eles! Eles são os especialistas no problema. Se prosseguirmos com essa afirmação um pouco mais, podemos descobrir que a exigência é que o Cliente treine 500 pessoas em três meses para usar o novo sistema. Claro que deve ser amigável. Mas o que o cliente realmente precisa é uma maneira de garantir que novos usuários possam ser treinados rapidamente. Isso pode mudar o foco da solução - manuais do usuário, treinamento online, tutoriais, etc.  

Então, vamos pegar aquele pedido simples de um sistema amigável. Aqui estão alguns dos problemas.

  • Um cliente não quer um workshop para determinar o que significa amigável para o usuário. O Cliente quer que pensemos por ele. Afinal somos seus “consultores”.
  • O cliente não sabe completamente o que quer. Eles não pensaram exatamente no que amigável significa para eles. Eles podem ter adicionado isso porque é uma boa ideia e todo mundo está fazendo isso. 
  • O cliente está muito ocupado para nos fornecer informações de qualidade. Peça-lhes para passar meia hora falando sobre o que significa amigável para o usuário e eles podem simplesmente recusar-se a gastar esse tempo.
  • O Cliente pode não ter determinado todos os usuários que procuram um sistema amigável. Em outras palavras, ele pode não ter identificado todos que podem querer determinar se o sistema é amigável (por exemplo, clientes corporativos, não corporativos, usuários experientes vs. usuários inexperientes, clientes estrangeiros, etc.).

Existem algumas coisas que podem ser feitas para mitigar o risco associado a um requisito desse tipo.  

  1.  Faça alguma prototipagem de telas e mostrá-las ao usuário. Pergunte especificamente se eles acham que são fáceis de usar. Em seguida, capture os aspectos das telas em um conjunto de requisitos de interface do usuário.
  2. Crie sua própria definição de amigável. Defina os critérios e use-os para definir os testes de aceitação do usuário. Forneça-os ao cliente para revisão.
  3. Continue buscando sua compreensão do problema.  Não tenha medo de continuar fazendo perguntas e investigue a verdadeira razão por trás da necessidade do cliente.
  4. Certifique-se de ter critérios claros para medir o requisito. Sem ele, você nunca passará o requisito aos olhos do Cliente. E sem ele, o requisito é inútil.
Gerenciar requisitos complexos graças aos modelos de dados do Visure

Casos de uso no gerenciamento de requisitos

Os casos de uso são uma ferramenta eficaz para documentar como o usuário faz seu trabalho. Freqüentemente chamadas de “como está” e “ser”, essas narrativas ajudam a garantir que entendamos como o usuário faz seu trabalho hoje (como está), bem como como ele pode imaginar fazer seu trabalho amanhã (ser). Os casos de uso estão se tornando cada vez mais populares à medida que os analistas continuam a lutar com os problemas em torno do relacionamento dos requisitos.

No entanto, às vezes os casos de uso são usados ​​de forma eficaz durante elicitação e definição de requisitos, mas se perca quando a transição for feita para o gerenciamento de requisitos. Se você pensar sobre as etapas em um caso de uso, cada etapa descreve uma ação do usuário ou do sistema. Dependendo da granularidade que você deseja em seus requisitos e rastreabilidade, considere tornar cada etapa no caso de uso uma declaração de requisitos. Pegue o seguinte caso de uso simples como exemplo.

O sistema exibe as informações da conta para o cliente.

O cliente analisa as informações da conta.

O cliente seleciona a opção de pagamento.

O sistema exibe as opções de pagamento para o cliente.

É bastante claro neste caso de uso que há duas etapas do sistema e duas etapas do cliente (ou seja, usuário). Se extrairmos as duas declarações do sistema e, se necessário, adicionarmos "deve" a elas, obteremos os dois requisitos de sistema a seguir:

O sistema deve exibir as informações da conta para o cliente.

O Sistema deve exibir as opções de pagamento para o Cliente.

Esses dois requisitos começam a formar a base para os requisitos do sistema. Esses requisitos de sistema provavelmente serão decompostos em muitos requisitos de sistema, mas podemos rastreá-los diretamente até as etapas do sistema no caso de uso.

Lembre-se de que os casos de uso contêm informações muito valiosas para análise e desenvolvimento de sistemas. Os casos de uso nunca são realmente concluídos, pois devem ser continuamente revisados ​​durante o desenvolvimento para garantir que reflitam com precisão como o produto se comporta quando é entregue. Certifique-se de que os casos de uso não sejam colocados em uma prateleira, mas sejam rastreados para testes e requisitos de sistema.


Agende uma demonstração gratuita
Saída