Profissionais TI - Pra quem respira informação

Nos artigos anteriores falei sobre como identificar as partes interessadas e gerar um plano de comunicação eficaz.

Agora que você tem em mãos quem são os envolvidos no projeto e já sabe como entrar em contato com eles. Uma das primeiras atividades que precisará realizar é o Levantamento de Requisitos. 

Nesta fase buscamos identificar quais são os requisitos do projeto na visão do cliente e também na visão de quem realiza o projeto. Este tema pode ser considerado complexo, existem cursos para isso e semestres inteiros em faculdades de Engenharia para tratar somente deste tópico.

Como estamos falando de projetos em micro e pequenas empresas, precisamos de soluções simples, porém eficientes, que nos ajudem a identificar estes requisitos de maneira adequada. Desta forma, abaixo listo algumas dicas e técnicas que podem ajudá-lo nesta etapa do seu projeto!

Premissas, Riscos, Restrições e Processos

Durante as entrevistas para identificação dos requisitos é comum receber outras informações que não necessariamente poderemos classificar como Requisitos. Mesmo assim a informação não deixa de ser útil e pode ser aproveitada em outros tópicos do projeto. Alguns deles:

• Premissas
  • São informações que você considerará como verdadeiras, mesmo que não tenha como comprová-las. Tenha cuidado, pois é muito comum uma premissa se tornar um Risco no projeto.
    • Exemplo: “O cliente disponibilizará total acesso ao ambiente de hardware/software conforme o serviço contratado”.
• Restrições
  • São informações que restringem alguma atuação no projeto. Assim como as Premissas, uma Restrição pode se tornar um risco.
    • Exemplo: Nosso orçamento é limitado à R$100.000,00.
    • Exemplo: Não podemos contratar mais que 10 pessoas para o projeto devido à restrição de espaço físico na empresa.
• Riscos
  • São situações que podem prejudicar nosso projeto. Para cada risco, você deve traçar um plano de ação para mitigá-lo, evitá-lo ou caso seja um risco aceitável, monitorá-lo e controlá-lo
    • Exemplo: Estamos em uma região em que temos apenas uma operadora de internet e nosso projeto depende de acesso 24/7. Plano: Buscar alternativas de conexão
• Processos
  • No contexto de requisitos, podemos entender que são solicitações dos envolvidos no projeto que envolvem mudanças nos processos da empresa ou de negócio
    • Exemplo: Para este projeto precisamos que toda solicitação de compra passe por aprovação pelo Gerente A e Gerente B, ao contrário do que é feito hoje onde a aprovação é automática.

Os três primeiros você pode incluir no seu TAP ou em um documento detalhado de escopo do projeto, já o último dependerá do contexto em que você está. Mudanças em processos, mesmo que em empresas pequenas, precisam ser registradas e em geral aprovadas por um conselho e diretoria.

Classificando Requisitos

Usualmente costumamos classificar os requisitos de duas formas:

• Requisitos Funcionais
  • São requisitos de funcionamento do produto do projeto em si. Em software podem ser cálculos, seu comportamento, saídas, etc.
  • Alguns autores dividem os requisitos funcionais de 3 maneiras:
    • Evidente: É quando o usuário final tem ciência do que está acontecendo com o sistema. Exemplos: Login em um sistema, cadastrar um fornecedor.
    • Escondida: É uma função importante que está sendo feita, porém é escondida para o usuário final. Exemplos: Manter um log de vendas, integrar informações com outros sistemas.
    • Friso: É uma funcionalidade que quando executada não afeta outras funções do software.

• Requisitos Não Funcionais
  • São requisitos relacionados ao uso do produto do projeto, sua confiabilidade, disponibilidade, segurança e tecnologias envolvidas. É comum que um requisito não funcional gere alguma restrição para um requisito funcional.
    • Exemplo: Deve funcionar em dispositivos móveis com Android a partir da versão 5.0.
    • Exemplo: Login no sistema deverá ser feito apenas de forma biométrica.

Entender profundamente os requisitos iniciais do seu projeto é vital para as primeiras tomadas de decisão sobre ele – e também sofre o futuro dele.

Em um primeiro momento você pode ter o impulso de tentar detalhar o máximo possível de requisitos, antecipando até mesmo situações ou desenvolvimentos que devem ocorrer bem adiante no projeto.

Essa situação pode até ser necessária em projetos como construção de prédios, onde você precisa ser muito bem definido, não podendo começar a construir sem saber como ele vai terminar. Mesmo em projetos assim você pode aplicar conceitos ágeis nas etapas de projetos com escopo tão tradicional.

Começando pelo Fim

Ao planejar o desenvolvimento do seu projeto com base nestes requisitos, procure “começar pelo fim”. Estou falando sobre ROI (Retorno sobre o Investimento). Comece por aquilo que agregará mais valor ao seu projeto. Um exemplo clássico e básico é o desenvolvimento de um sistema de vendas.

Usualmente você deve pensar que, para ter este sistema, precisará criar antes toda a parte de cadastros, inclusão de fornecedores, clientes, produtos, usuários, etc. Porém, o cliente não perceberá valor nisso mas sim no sistema de vendas que ele adquiriu. Então, comece o desenvolvimento pelo processo de vendas!

Estes cadastros e informações você poderá alimentar exemplos (ou até mesmo dados reais) direto no banco de dados. O sistema de vendas funcionando com estas informações, você já terá algo para mostrar no início do projeto, gerando um retorno muito mais rápido ao cliente do investimento que ele fez.

Quando você estiver no processo de coleta de requisitos, não busque apenas escutar o cliente e sim compreender as reais necessidades de todas as partes interessadas envolvidas. Pode ser difícil no início, mas conhecer e compreender seu cliente aumentará e muito as chances de sucesso do seu projeto.

Validação: Requisitos bons e ruins

Basicamente você poderia validar os requisitos considerando 3 fatores: Necessário, Verificável e Atingível.

• (Verificável + Atingível) – Necessário (Aquele Requisito Desejável):
  • Se ele não é necessário, não é um bom requisito! Não misture desejos com reais necessidades do seu projeto.
• (Necessário + Atingível) – Verificável (Aquele Requisito Fácil):
  • Para verificar você precisa de algo para examinar, testar, comprovar ou demonstrar. Se o requisito é subjetivo não é verificável.
• (Verificável + Necessário) – Atingível: (Aquele Requisito do Milagre):
  • Sabe aquele requisito que você consegue comprovar, é necessário mas custa Um Trilhão de Dólares? Então, ele não é um requisito! Se você já sabe que não conseguirá atingir o determinado requisito, então ele não é um requisito!

Pode até parecer simples, mas a maioria dos requisitos levantados em projetos erram nesta classificação. Resultado? Um requisito mal definido pode se tornar aquela famosa discussão em que o cliente diz: “Mas eu tinha entendido isso, pensei que estivesse incluso”. Ele também pode se tornar um risco ou até mesmo impactar no tempo/custo do seu projeto desnecessariamente.

Coleta de Requisitos X Elicitação de Requisitos

Explicando de uma maneira simples:

• Coleta de Requisitos (Gathering)
  • É como pegar conchas na praia
  • Você pega o que você vê
  • Mais reativo, menos proativo
• Elicitação de Requisitos
  • É como arqueologia
  • Planejado, uma busca proposital
  • Mais proativo, menos reativo.

Para um bom levantamento, sem dúvidas a elicitação é o estilo ideal. Você perguntar pra alguém “E ai, o que você acha que o sistema deve fazer” é bem diferente de você reunir os envolvidos em uma sala, com uma série de perguntas e um guia com tópicos importantes e buscar um entendimento em comum do que o sistema realmente deve fazer.

Algumas técnicas

Seria necessário um artigo para cada técnica, portanto, irei resumir algumas das mais conhecidas que irão ajudá-lo em um processo de Elicitação de Requisitos:

• Entrevistas
  • Técnica Direta: Usada para entender os problemas reais e soluções em potencial na perspectiva da parte interessada. Nesta fase você pode ter uma demonstração do processo que a pessoa realiza ou de sua necessidade geral para o produto do seu projeto.
• Questionários
  • Perguntas bem definidas. Apresenta-se uma lista de questionamentos relevantes de acordo com o projeto e o processo ao qual esta parte interessada está envolvida. O ideal é formalizar este questionário após uma entrevista inicial. Lembre-se: Ao ler as perguntas, o ouvinte poderá ouvir da maneira dele, suprimindo uma boa análise. Precisa ter um foco adicional em compreender e ser compreendido.
• Casos de Uso
  • Você discute com o cliente o que o seu produto fará para ele, o que o sistema irá entregar. Identifique quem irá interagir com o produto do seu projeto e quais as interfaces ou conexões seu produto fará com outros. Forte apelo visual dos requisitos mais relevantes ao cliente.
• Jogo de Funções
  • Você assume a função do usuário ou cliente do seu produto, fazendo o processo no lugar dele. Desta forma você poderá ter uma visão bem melhor das reais necessidades e problemas que ele enfrenta.
• Brainstorming
  • Uma coleta massiva de idéias. Você coloca os participantes envolvidos em um mesmo local, traça um objetivo da sessão e gera quantas idéias forem possíveis. Deixe a imaginação fluir. Não permita durante a sessão debates, críticas ou discussões sobre as idéias. Incentive a participação de todos. Depois, ajuste e combine as idéias para extrair os requisitos.
• Workshop de Requisitos
  • Parecido com o Brainstorm. É um momento muito focado entre os participantes, onde um facilitador conduzirá a reunião. Todos terão obrigatoriamente sua vez de falar e você deve ter ao fim do Workshop a lista de requisitos. Neste momento você pode aplicar ao mesmo tempo outras regras de elicitação, tanto as mencionadas quanto outras!

Existem muitas outras técnicas como prototipagem, análise de documentos, observação, pesquisa de mercado, etc. Vale a pena pesquisar e entender outras técnicas que possam ser úteis ao seu projeto.

Manifesto Ágil e os Requisitos

Voltando a falar do retorno sobre investimento (ROI), onde buscamos entregar aquilo que agrega valor antes. Veja os 4 itens do Manifesto Ágil e como considerá-los quando tratamos dos requisitos:

• Indivíduos e interação entre eles mais que processos e ferramentas
  • Não considere apenas as entrevistas individuais. Pense no coletivo, busque entender a integração entre as pessoas que utilizarão seu produto ou sistema. Não adianta ter um excelente processo de vendas e um sistema maravilhoso se as pessoas não se falam.
• Software em funcionamento mais que documentação abrangente
  • Uma documentação, um bom manual pode até ser requisito para alguns tipos de projetos. Apesar disso, não vale investir em um manual maravilhoso, com vídeos, imagens 3D, diagramas, etc, se o software for péssimo. Isso vale até para outros tipos de projetos: Do que adianta uma caixa maravilhosa se o produto interno é uma porcaria?
• Colaboração com o cliente mais que negociação de contratos
  • Seu projeto é longo e os requisitos mudaram ou aumentaram? Lide com isso rapidamente e agregue valor ao cliente. Não apele dizendo “mas isso não constava no documento que você assinou 3 anos atrás”.
• Responder a mudanças mais que seguir um plano
  • Adapte-se! A regra de negócio de um cliente pode mudar em 6 meses e seu produto não atendê-lo da forma que ele foi planejada. Pare, reflita, discuta e busque uma solução ideal para ambos de modo a atender e implantar as mudanças no seu projeto.

Para finalizar o artigo, deixo a clássica imagem abaixo. Afinal, um artigo sobre levantamento de requisitos sem ela não é um artigo completo!

Espero que tenha gostado do artigo e que ele o ajude em seus projetos.

Quer comentar, sugerir ou discutir o assunto? Use os comentários! No próximo pretendo falar um pouco sobre como gerenciar suas atividades diárias em projetos, abordando algumas ferramentas de mercado e dicas simples para se organizar no dia-a-dia.

Publicação Original: http://www.vignado.com.br/?p=428