Cada um de nós deve ter ouvido a mesma pergunta de nossos pais ou amigos, e não da “festa do programador”: “O que você está fazendo aí?”
Geralmente, após uma tentativa de resposta, segue-se um comentário inalterado: "Ah, seu programador, você não pode nem consertar a geladeira". O que podemos dizer sobre analistas de negócios que realmente não conseguem explicar aos colegas o que estão fazendo?
Eu mesmo frequentemente ouço essa pergunta do meu pai, mas ainda não consigo encontrar a resposta certa. E a verdade é o que fazemos no trabalho - analisamos!
Em que um analista de TI gasta tempo?
Especialmente neste artigo, eu tive que cavar minuciosamente os arquivos do JIRA dos últimos três locais de trabalho. Não posso garantir a precisão absoluta (sim, também não gosto de pintar todas as minhas aulas até o último minuto), mas o quadro geral realmente coincide com meus próprios sentimentos em relação às tarefas desempenhadas.
A distribuição aproximada do trabalho pode ser descrita da seguinte forma:
- Reuniões - 20%
- Documentação - 30%
- Trabalho em equipe - 25%
- Teste - 5%
- Viagens de negócios - 5%
- Autodesenvolvimento - 15%
E aqui está o número exato de horas nos últimos 3 meses:
Como você pode ver, a imagem é realmente semelhante. Pequenas diferenças - a ausência de viagens de negócios e horas de trabalho mais longas com a equipe - surgem devido à recente mudança no local de trabalho e, consequentemente, ao processo de integração no novo ambiente.
Agora vamos ver cada item com mais detalhes.
Reuniões
Vamos começar com o mais importante - com o que, de fato, a análise de negócios começa com reuniões de negócios, que incluem reuniões com clientes e reuniões internas com a equipe.
Primeiro de tudo, esta é a análise da área de assunto e a coleta de requisitos. É aqui que descobrimos o que o cliente quer que façamos, que problemas ele tem, oferecemos as primeiras idéias para implementação e juntos elaboramos um plano preliminar do projeto.
Outros elementos importantes das reuniões com os clientes são a discussão do trabalho concluído, o planejamento de mudanças, as apresentações e os treinamentos, onde explicamos como usar o produto proposto.
Talvez sejam as reuniões que são a base do nosso trabalho, eles fornecem aos analistas e suas equipes tarefas adicionais, por isso vale a pena se preparar para eles com mais cuidado.
Trabalhar com documentação
Eu diria que, se o analista não estiver na reunião, ele estará sentado e trabalhando com a documentação. Não me interpretem mal, isso não significa que você só precisa bater estupidamente no teclado, pelo contrário - é aqui que você deve usar todas as capacidades do nosso intelecto, esta parte é a que exige mais trabalho.
Aqui estão apenas alguns exemplos do que você deve lidar regularmente:
- A especificação de requisitos é a transformação de uma fuga livre dos pensamentos do cliente em um documento estruturado que descreve claramente o que a equipe precisa fazer. Posteriormente, este documento é aprovado com o cliente e forma a base do projeto em andamento.
- Solicitação de mudança (Change Request) - o processo iniciado pelo cliente no caso de serem necessárias alterações no produto após o início do desenvolvimento ou mesmo após sua conclusão. O documento descreve qual parte do sistema e como ele deve ser modificado contém uma avaliação do desempenho do trabalho em tempo e custo.
- Manual do usuário e outros materiais de treinamento - é óbvio que, após o final do projeto, você precisará escrever uma documentação para o cliente, que descreverá como usar o sistema, fornecerá dicas e respostas a perguntas comuns.
Cada analista tem seu próprio kit de ferramentas favorito para trabalhar com a documentação - alguém gosta de desenhar diagramas e alguém escreve uma tela de texto no Word. De qualquer forma, aconselho que você se familiarize com os conceitos básicos de UML, BPMN, os conceitos de Histórias de Usuário e Critérios de Aceitação. É provável que sejam encontrados em todos os empregadores.
Trabalho em equipe
Em maior medida, para a equipe, é o analista - a voz do cliente. Em qualquer situação incompreensível, eles chegarão a ele com as perguntas "O que se quis dizer aqui?" e será com ele que eles confirmarão se o cliente deseja.
Eu sempre digo que os analistas de negócios em TI desempenham o papel de uma espécie de ponte entre desenvolvedores e negócios, sendo capazes de falar simultaneamente as linguagens de clientes e programadores. No trabalho diário, temos que discutir conjuntamente requisitos, planejar e distribuir tarefas e responder às perguntas atuais dos programadores.
Muitas vezes acontece que um analista de negócios passa muito tempo com cada membro da equipe e desempenha um papel peculiar como vice-chefe. Na minha prática, houve até casos em que um gerente me procurou para discutir quais colegas deveriam dar um prêmio e quem não deveria.
Teste
É óbvio que, o melhor de tudo, entendendo os requisitos do cliente, teremos que verificar os resultados do trabalho dos programadores.
Espera-se que um analista de negócios execute os chamados testes de aceitação do usuário - testes de aceitação do usuário. Ninguém precisa escrever scripts automatizados ou verificar os tamanhos e cores dos botões no site. Tudo o que é necessário é se apresentar como usuário e tirar proveito do produto acabado. Verifique se há algum inconveniente ao usá-lo, se o sistema funciona em geral como o usuário queria, se há erros óbvios ou inconsistências com os requisitos.
Um ponto importante! É preciso lembrar que os analistas passam o tempo todo com a equipe, participam de discussões, conhecem os vários "hacks" e gargalos do programa. Ao mesmo tempo, ao executar testes, devemos entender que o cliente não possui esse conhecimento, ele não sabe onde clicar e onde não. É absolutamente necessário avaliar o sistema com a mente aberta e apontar todos os erros para os desenvolvedores - quanto mais cedo eles forem identificados, mais fácil será corrigir.
Auto-desenvolvimento
Eles dizem que, para acompanhar todas as novas tecnologias de programação, você precisa aprender novas estruturas quase todos os dias, experimentar novas versões de seus idiomas favoritos e seguir as melhores práticas de todo o mundo.
Felizmente, os fundamentos da análise de negócios não mudam com tanta frequência. No entanto, como eu disse no meu último artigo, para se destacar da multidão de analistas de negócios, você precisa ser o especialista mais abrangente.
Você também precisa monitorar as mudanças na TI, desenvolver suas habilidades pessoais, aprender gerenciamento de negócios, noções básicas de finanças, entender as áreas de assunto dos clientes e assim por diante. Em geral, acontece que você frequentemente precisará de mais tempo para treinar do que outros programadores.
Concluindo, darei conselhos sobre o autodesenvolvimento - aceite sua necessidade e discuta com seu líder. Para o desenvolvimento de negócios, é extremamente importante não entrar na estrutura dos processos estabelecidos, porque amanhã um novo cliente e um novo projeto de uma esfera completamente diferente aparecerão. Um analista de negócios deve poder se acostumar rapidamente a um ambiente em mudança e se preparar para trabalhar com uma nova área de assunto. É aqui que todo o tempo que você passou expandindo seus horizontes virá em seu auxílio.