Estratégia para Entrevistas – LTI – Levantamento Técnico Inicial

Por Fabio Camara
MCP, MCSA, MCAD Charter, MCDBA e MCSD.NET. Escreveu os livros “Projetos com Windows DNA e .NET” e “Orientação a Objeto com .NET” dentre outros, editados pela Visual Books Editora. Pode ser contatado pela home page C# Br (http://www.csharpbr.com.br).

Fonte: http://www.linhadecodigo.com.br/artigos_impressao.asp?id_ac=916

Esse guia tem como objetivo esclarecer quais são as informações que devem ser extraídas das pessoas entrevistadas em um LTI – Levantamento Técnico Inicial.

Perfil dos entrevistados

Cada pessoa entrevistada tem uma visão diferente do sistema, logo devemos considerar que a forma de abordagem nas entrevistas será diferente, bem como as informações coletadas terão um valor diferente para o levantamento.

Sponsor:

É o responsável pelo negócio que o sistema se propõe a automatizar, geralmente é um gerente, diretor, coordenador ou supervisor de departamento ou área. Essa pessoa tem as informações em um nível gerencial e deverá descrever como o sistema irá contribuir para o negócio de forma estratégica, isto é, que informações o sistema deve disponibilizar em um nível estratégico.

Em alguns sistemas a preocupação do Sponsor pode ser aumentar a agilidade do departamento ou área e eliminar o trabalho manual – conceitos de automação – objetivando melhores e mais confiáveis resultados, porém sempre essa preocupação tem uma conotação estratégica dentro do seu trabalho.

Outra visão, ele(a) é a pessoa que, de alguma forma, está pagando pelo sistema, logo também é de seu interesse o tempo em que a solução será desenvolvida, os custos envolvidos e a qualidade do produto entregue. Muito provavelmente o Sponsor não é responsável só por uma área ou departamento, nesses casos será possível extrair dele, a nível corporativo, qual e á importância do sistema para a empresa.

IT-Manager:

Essa é a pessoa que conhece todo o parque tecnológico da empresa, as informações sobre tecnologias e plataformas existentes virão dessas pessoas, e direcionarão a decisão sobre como vai ser a arquitetura da solução proposta.

Todas as configurações de servidores bem como a topologia da rede e os ambientes (Desenvolvimento, Testes e Produção) existentes devem ser identificados nessa entrevista.

Também saberemos se a TI do contratante tem padrões a serem seguidos e quais são, se existe alguma metodologia e se deverá ser integrada com a nossa. Outro importante ponto é como está estruturada a equipe técnica e quem são as pessoas que estarão interagindo no processo de desenvolvimento, facilitando assim a identificação dos papéis necessários para o projeto em questão.

Usuário:

O usuário é a pessoa que realmente irá utilizar o sistema, que estará em pleno contato com o produto gerado. As entrevistas com o usuário, são chamadas requirements workshop e os produtos dessas reuniões serão: diagrama macro funcional, modelo de negócios, os esboços das telas do sistema e todos os requisitos não funcionais necessários ao sistema. Esta é uma sugestão genérica, dependendo da especialidade do projeto devemos incluir outros documentos ou extrair estas informações do pessoal de IT também.

Os esboços de tela irão garantir que você (analista) identificou boa parte da tamanho do sistema, sendo que nessa atividade de levantamento das telas, devemos ser bastante práticos, re-aproveitando o conhecimento de sistemas anteriores caso seja conveniente ou representando telas através de formulários que fazem parte do processo de negócio estudado.

Outros:

Para alguns casos, se fará necessária a entrevista com outras pessoas envolvidas com o sistema, por exemplo, no caso de um projeto de otimização e manutenção de um sistema, muito provavelmente entrevistaremos o programador que mantém o sistema atualmente, e tentaremos extrair dele, quais são as dificuldades enfrentadas durante as atividades de manutenção do sistema e os pontos de “gargalo” identificados. Estas pessoas recebem o nome de “stakeholder” que por definição seriam interessados ou pessoas que exercem influência no projeto. Particularmente considero extremamente salutar classificar todos os possíveis stakeholder antes de iniciar o projeto. Para saber mais sobre stakeholder visite o site http://en.wikipedia.org/wiki/Stakeholder

Perguntas Chave

Sponsor:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Quais informações estratégicas deverão estar disponíveis pela solução?

ü   Qual é a importância da solução para a empresa como um todo?

ü   Como a solução interage com outras aplicações do empreendimento?

ü   Qual a visão de longo prazo para o produto?

ü   Em quanto tempo seria ideal a conclusão do projeto?

ü   Qual é a previsão desse investimento? (levantar em unidade monetária ou horas de projeto)

IT-Manager:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Em que ambiente essa solução deverá funcionar?

ü   Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução?

ü   Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)?

ü   Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc…);

ü   Como serão as integrações entre os sistemas?

ü   Haverá migração de dados ? Em que estrutura estão esses dados?

ü   Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue?

ü   Como esta estruturada a equipe de TI?

Usuário:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Que facilidades você espera do sistema?

ü   Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)?

ü   Quais são as macro funcionalidades necessárias para os sistema?

ü   Quais são os atores que se relacionam com o sistema?

ü   Quais são as telas imaginadas para o sistema (modelo de negócio)?

ü   Como são as telas imaginadas para o sistema (esboços de telas)?

ü   Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar o layout dos arquivos / fontes de dados)?

Outros:

Manutenções:

ü   Quais são as dificuldades de manutenção do sistema?

ü   Qual é a qualidade das estruturas do banco de dados?

ü   Qual é a qualidade do código fonte do aplicativo?

ü   A documentação do sistema é suficiente e compreensível?

ü   Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)?

 ü   Quais são os pontos de “gargalo” do sistema atual?

Anúncios

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s