Estudo de Viabilidade

Já falamos um bocado de coisas sobre análise de requisitos de sistemas: o que são esses tais requisitos, como identifica-los e documenta-los.

Beleza, e agora?

Agora, eu quero voltar um pouco no tempo e perguntar uma coisa muito importante. Será que vale a pena desenvolver um sistema?

A resposta a princípio parece ser trivial, mas não é.

Se tomarmos como base uma empresa grande, com muitos funcionários e um orçamento bem gordinho, que tem parte de suas operações atreladas a planilhas de Excel, a resposta tende para o SIM. Mas, se mudarmos as condições, talvez o investimento em um sistema informatizado não se justifique (neste momento).

É por isso que existe uma técnica chamada de análise de viabilidade e que deveria ocorrer antes da concepção de qualquer projeto, ou quando se percebe a necessidade do tal projeto.

Daí você me fala, mas não sou eu que tenho que fazer isso. Meu trabalho só começa quando essa atividade já foi realizada e a resposta para a pergunta já foi dada.

E você tem razão. E responsabilidade disso é do dono do negócio ou do gestor da empresa. Mas se você faz parte da gerencia de TI da empresa, você pode ser convocado a dar uma ajudinha (se você for freelancer ou dono de uma empresa de desenvolvimento de software, não se preocupe com isso).

Mas é importante que entendamos o que é essa atividade, para podermos tirar proveito dela e não trata-la somente como mais uma atividade.

Partindo do início

Estudo de viabilidade, é o conjunto de tarefas que é responsável por analisar situações do negócio que envolvem problemas a serem resolvidos ou oportunidades a serem aproveitadas (essência do desenvolvimento de software). Quando esse estudo é bem feito você consegue tirar dele informações que podem facilitar a sua vida como desenvolvedor na análise de requisitos.

E o que ocorre na análise de viabilidade que pode ser útil?

A análise de viabilidade requer que várias tarefas sejam desenvolvidas afim de gerar um parecer concluindo se o projeto é financeiramente viável para a empresa. Uma delas, que é de interesse do analista, é a análise de situação de negócios para entender problemas e oportunidades. Esta tarefa possivelmente gerará "insight" para definição dos requisitos de negócios.

Uma outra tarefa necessária ao estudo é a definição do escopo da solução identificando os casos de negócio. Importante lembrar que o escopo da solução, neste caso, ainda é muito superficial a qual, poderá (e deverá) crescer durante o desenvolvimento. Durante o estudo de viabilidade é importante que se tenha ao menos um rascunho do escopo do projeto, o qual será incrementado, durante a fase de desenvolvimento, a cada ciclo de iteração.

Com isso é necessário também avaliar a capacidade que a empresa tem de acomodar as mudanças necessárias para que a nova solução adotada (ou implementada) seja utilizada pelos operadores. Não adianta muito investir uma fortuna na implantação de um sistema robusto para gerenciamento de estoque, sendo que a sua equipe de logística é engessada é avessa a mudanças. Neste caso, o estudo levantaria a necessidade da aplicação de um treinamento comportamental para a equipe, ou mesmo, concluiria que a solução não é viável e iria sugerir uma mais adequada, e ao final, desenvolver casos de negócio para a solução proposta.

Vale lembrar que tudo isso é preliminar ao desenvolvimento do sistema, anterior até mesmo ao levantamento de requisitos. Assim, é a partir das informações recebidas a partir do estudo de viabilidade que o analista de requisitos começa o seu trabalho para entender e classificar o domínio do problema e a visão da solução a ser implementada.

Então é fácil de supor que, se os gestores tiverem feito um bom serviço durante o estudo de viabilidade, uma boa parte do seu trabalho durante a fase de análise de requisitos já foi feita.

Atividades que geram produtos úteis para o analista de requisitos.
 

1- Definir casos de negócio
Determina as metas chave e as medidas de sucesso para um projeto. Podendo incluir:

• Benefícios quantitativos e qualitativos (financeiros ou não).Quantificação de benefícios e custos.
• Orçamento e fluxo de caixa esperados.
• Tempo de retorno e lucro esperado.
• Oportunidades e ameaças (riscos)
• Premissas e restrições

Outra técnica utilizada é a sentença de problema/visão, a técnica é desenvolvida em um quadro onde se projeta (ou desenha mesmo) um quadro onde serão incluídos:

• Declaração das necessidades de negócio
• Identificação dos stakeholders chave
• Descrição resumida do impacto que o alcance das necessidades de negócio tem sobre os stakeholders

Por exemplo:

Como você já deve ter percebido, a técnica se assemelha muito com as Histórias de Usuários que falamos em um post anterior, ou seja, estrutura de forma simples o que o cliente quer. 

 

2- Identificar partes interessadas (stakeholders)  

O estudo de viabilidade já faz um levantamento preliminar das partes interessadas no projeto durante o seu desenvolvimento, mas vale lembrar que o levantamento não é estático e uma das primeiras coisas a ser feita durante a fase de planejamento do projeto é o refinamento desta lista.

Assim o analista de requisitos pode aproveitar estas informações para identificar o subconjunto destas partes que é relevante para o sistema em desenvolvimento. Para tanto, o analista deve descrever os papéis dos stakeholders, suas responsabilidades e sua autoridade sobre os requisitos levantados. Essa informação é fundamental para que o analista de projetos saiba com quem conversar, facilitando (e muito) a aplicação das técnicas de levantamento de requisitos, uma vez que você deve identificar os stakeholders antes da aplica-las.

Assim como o escopo do projeto, a lista de partes interessadas não é estática, e será incrementada durante o desenvolvimento da história. Embora fosse ideal conhecer todos antes do início da implementação do projeto.

A identificação das partes interessadas no projeto não é um bicho de 7 cabeças não, mas exige um pouco de atenção, conhecimento e paciência (e nem tudo mundo tem).

Assim, se o estudo não lhe informou uma lista decente de stakeholders. Você pode usar de alguns artifícios para ter uma listagem básica.

• Modelo organizacional (organograma): listagem de pessoas com papéis e funções na organização apresentados hierarquicamente;
• Modelo de processo: pessoas envolvidas na execução dos processas;
• Modelo de escopo: o que não faz parte da solução;
• Matriz RACI: correlaciona atividades com recursos (indivíduos ou equipes).

3- Definição do escopo da solução

Definir a solução recomendada com detalhes suficientes que permita aos stakeholders compreender as novas capacidades do negócio e as versões que serão entregues a cada iteração do desenvolvimento, considerando que o sistema vai ser desenvolvimento em um ciclo iterativo e incremental.

Mais uma vez vale lembrar que este escopo não é estático e será incrementado a cada iteração do clico de desenvolvimento.

Este escopo inicial, e aconselhável que aborde:

• As principais características e funções que devem ser incluídas e as interações que a solução terá com as pessoas e sistemas;
• Principais dependências técnicas e de negócio (que pode ocasionar uma restrição para o desenvolvimento da solução);
• Unidades de negócio que serão envolvidas ou afetadas pelo sistema;
• Processos de negócio que serão melhorados ou redesenhados e seus proprietários;
• Sistemas de TI e outras tecnologias que provavelmente serão afetadas;

Uma forma comum de se demonstrar o escopo é através de modelos. Estes modelos determinam o que está dentro e fora do alcance de uma solução. Exemplos:

• Diagramas de contexto: representa o ambiente externo no qual a solução está inserida. É o diagrama de fluxo de dados de mais alto nível.
• Diagrama de casos de uso: representa visualmente os casos de uso apoiados por um sistema, os atores que acionam os casos de uso e relacionamentos entre os casos de uso. Destacam quem faz o quê na solução.
• Modelo de processo de negócios: modelo de alto nível para processos de negócio. Destacam papéis, tarefas, sequência e relação entre elas. Mais provável de ser usado no estudo de viabilidade.

Por hoje é só pessoal!