Get best of the week

Análise de folhas de dicas: como "desenterrar" um sistema

Na Conferência de analistas dos dias 10, o arquiteto fez uma apresentação sobre como desenterrar o sistema legado sem documentação ou se há documentação conflitante ("4 regras de um arqueólogo: como desenterrar" o sistema, Evgeny Aslamov). Ótimo relatório.

Quando um analista chega a uma nova empresa para um produto mais ou menos formado ou mesmo para um sistema legado (nesse caso, eu nem sei se o analista teve ou não sorte), ele também é frequentemente forçado a coletar uma descrição da funcionalidade, como quebra-cabeças (nas empresas em que trabalhei e onde a entrevista foi descrita o produto era quando? Quase nunca. Talvez eu tenha tido azar, mas talvez vice-versa).



Eu tive de fazer isto. Em algum lugar intuitivamente, havia um entendimento sobre quem perguntar. Às vezes, alguém da equipe do projeto sugeria. Foi assim que você aprendeu sobre algum tipo de gatilho em sua funcionalidade após um incidente do departamento de suporte. Algo foi esclarecido como parte da atualização da funcionalidade. Bem, o mais alto nível é o autoteste e o uso do produto.

Tendo analisado tudo isso, tive a idéia de escrever uma espécie de cábula para analistas, de onde sair.

Somente não haverá quatro regras, como no relatório do arquiteto, mas quatro etapas:

Etapa número um. Colete toda a documentação para a solução implementada.


1. Idealmente, se ele contém para cada bloco funcional:

  • uma descrição da necessidade dessa funcionalidade em qualquer ferramenta (apenas texto, etiquetas, alguns esquemas em qualquer notação);
  • descrição frontal: comportamento do elemento, usuário wf;
  • descrição das costas: serviços internos, descrição do banco de dados e componentes;
  • Descrição dos serviços de integração, incluindo exemplos de solicitações e respostas, status de respostas.

2. Toda a documentação regulamentar e regulamentar que define os limites dos produtos: lei federal, regulamentos, pedidos, projetos.

3. Especificações TK / TP / (sublinhe o necessário) - um documento no qual os requisitos de funcionalidade foram descritos.

4. Contratos registrados nos quais você pode rastrear qualquer desejo não realizado.

5. Manual / instruções do usuário, caso não haja descrição da necessidade, a fim de entender como o usuário deve trabalhar com o sistema.

Etapa número dois. Teste


Independentemente da existência ou não dos documentos acima, a próxima etapa deve ser testar o produto.

Apenas sente-se e comece a cutucar em todos os lugares e observe como o sistema reage. Ao mesmo tempo, você registra o comportamento e observa momentos duvidosos para esclarecimento entre os detentores de conhecimento secreto.

Etapa número três. Questões


Você descobre com o chefe (linha, gerente de projeto, líder, etc. - sublinhe o que é necessário) quem pode aconselhar sobre os problemas. Você está preparando uma fatura de perguntas. Peça, esboce a resposta. Você vai deixar tudo passar por você.

Etapa número quatro. Consiga o que você tem


Você processa as informações recebidas da maneira prescrita em sua empresa. Isso pode ser a atualização de documentos ou a criação de uma base de conhecimento em confluência, talvez até a atualização de tickets pai no rastreador de tarefas - em geral, um local conveniente para você.

De uma maneira boa, os próximos passos devem ser: ir trabalhar


Mas o que realmente quero dizer no final do artigo: a tarefa do analista é deixar as informações estruturadas para trás.

Licença - isso significa emitir e colocar em um local público. E não descubra como um estudante com novos conhecimentos e deixe-os com você.

Informações estruturadas - isso significa colocar nas prateleiras tudo o que foi ruim para você.

Não tenha medo e vá em frente!

More articles:


All Articles