Vamos conversar antes de começar
Imagine que alguém chega até você e diz: “Precisamos de um sistema.”
A primeira vontade pode ser perguntar qual linguagem vamos usar, como será a tela ou onde os dados ficarão guardados.
Mas e se o problema nem estiver claro ainda?
Então analisar vem antes de programar?
Na maior parte das vezes, sim.
Analisar é tentar entender uma situação antes de sair construindo uma solução para ela.
É quase como quando alguém leva um notebook para conserto. Um bom técnico não troca peças aleatoriamente. Primeiro pergunta o que aconteceu, observa os sintomas, testa possibilidades e procura evidências.
Na Análise de Sistemas fazemos algo parecido, só que olhando para o trabalho de uma empresa, as pessoas, as informações, as regras e os problemas que aparecem no dia a dia.
Em uma frase
Análise de Sistemas é investigar um problema, entender como o trabalho acontece e organizar o que precisa mudar antes de decidir como construir a solução.
Software também precisa de planejamento
Pense em qualquer coisa que precise ser construída com cuidado: uma casa, uma ponte, uma viagem longa, um laboratório.
Ninguém deveria começar pela última etapa.
Antes de construir uma casa, alguém precisa entender o terreno, as necessidades de quem vai morar ali, o orçamento, as medidas, as limitações e o que realmente precisa existir.
Com software não é diferente.
Antes de programar, precisamos entender problemas, pessoas, processos, informações, regras, requisitos, riscos e prioridades. Depois disso fica muito mais seguro decidir o que será construído e como.
Planejar não é adivinhar o futuro
Planejar é tomar decisões melhores com o que sabemos agora — e estar preparado para revisar essas decisões quando surgirem novas evidências.
Mas por que isso virou uma área?
Nos primeiros anos da computação comercial, muitos programas cuidavam de tarefas mais isoladas: cálculos, registros, folhas de pagamento, estoques e outros trabalhos bem definidos.
Com o tempo, os sistemas cresceram, passaram a envolver vários setores e começaram a representar decisões importantes das empresas.
Aí ficou evidente uma coisa: programar certo não adiantava se estivéssemos programando a coisa errada.
Foram surgindo maneiras mais organizadas de estudar processos, dados, regras e necessidades. Vieram técnicas de análise estruturada, diagramas de fluxo de dados, modelagem de processos, linguagens de modelagem como a UML — Linguagem de Modelagem Unificada, métodos ágeis e prototipação.
As ferramentas mudaram bastante. A pergunta principal, nem tanto:
O que precisamos entender antes de construir?
Essa pergunta vai acompanhar você pelo módulo inteiro.
Isso não vira burocracia?
Pode virar, se a equipe produzir documentos e desenhos só porque “o método manda”.
Mas uma boa análise faz o contrário: ela tenta evitar retrabalho.
Se uma conversa de dez minutos revela que entendemos errado uma regra, ótimo. É muito mais barato descobrir isso antes de programar dezenas de telas.
Por isso, neste módulo, uma ferramenta só aparece quando existe uma pergunta que justifique usá-la.
A história do balanço: todo mundo ouviu, mas cada um entendeu uma coisa
Existe uma história clássica usada há muitos anos para explicar problemas de comunicação em projetos. Vamos contá-la do nosso jeito.
Uma pessoa pede algo simples: “Quero um balanço para uma criança brincar no quintal.”
Até aqui parece fácil. Mas imagine o que pode acontecer:
Quem ouviu o pedido
Entendeu que seria melhor fazer uma estrutura grande e resistente, “para garantir”.
Quem planejou
Imaginou várias crianças usando ao mesmo tempo e acrescentou mais coisas.
Quem construiu
Seguiu o que recebeu, mas interpretou alguns detalhes de outra forma.
O resultado
Ficou caro, complicado e muito diferente do que a pessoa tinha imaginado.
E talvez, no fim, o que a criança realmente quisesse fosse apenas um pneu preso com segurança por uma corda numa árvore.
O problema não foi falta de esforço. Todo mundo trabalhou. O problema foi outro: ninguém garantiu que todos estavam entendendo a mesma necessidade.
É aqui que a análise faz diferença
Antes de construir, precisamos descobrir o que a pessoa realmente precisa, confirmar o entendimento e transformar isso em algo claro o suficiente para que a solução entregue continue resolvendo o problema original.
Vamos trazer isso para uma situação real
Segunda-feira, 9h20
Um cliente telefona para a Assistência Técnica Conecta e pergunta: “Meu notebook já ficou pronto?”
O atendente procura uma ficha de papel, abre mensagens no celular e chama o técnico. Cinco minutos depois, ainda não consegue responder com segurança.
Perceba uma coisa importante: o cliente não pediu um aplicativo. Não falou em banco de dados. Não falou em nuvem.
Ele só queria saber onde estava o notebook.
É aí que começa a análise.
O problema não é automaticamente “falta de sistema”
Talvez falte organização. Talvez a informação esteja espalhada. Talvez ninguém saiba quem deve atualizar cada etapa. Talvez existam várias causas ao mesmo tempo.
Se começarmos fazendo telas agora, podemos apenas transformar um processo confuso em uma confusão digital mais bonita.
O proprietário da Conecta olha para a situação e diz: “Então precisamos de um sistema.”
Pode ser que sim. Mas essa ainda é uma hipótese de solução. Antes dela vêm as perguntas.
É por isso que o analista pergunta tanto
Não é para complicar. É para evitar adivinhação.
Se o cliente liga várias vezes, podemos perguntar:
Vamos investigar juntos
- Por que o cliente liga? Porque não sabe o andamento.
- Por que não sabe? Porque não existe um acompanhamento confiável.
- Por que o atendente demora? Porque procura em papel, mensagens e pessoas.
- Por que a informação está espalhada? Porque cada etapa registra de um jeito.
- Por que isso importa? Porque gera espera, retrabalho e risco de informação errada.
Esse jeito de aprofundar uma pergunta é conhecido como 5 Porquês. O número cinco não é uma obrigação. A ideia é simples: não parar no primeiro sintoma.
Antes das ferramentas, veja o caminho que vamos percorrer
Você não precisa decorar os nomes abaixo. Eles aparecem aqui apenas para você enxergar o mapa da viagem. Mais adiante, cada um voltará quando realmente fizer falta.
1. Entender o cenário
Quem participa? Quem conhece o problema? Até onde vai o que estamos estudando?
Aqui aparecem stakeholders — as partes interessadas —, escopo e levantamento.
2. Enxergar como o trabalho acontece hoje
Onde há espera, decisão, retrabalho ou informação perdida?
Aparece o AS-IS, expressão que significa “como está”, além de fluxogramas e formas de acompanhar processos e dados.
3. Pensar numa forma melhor de trabalhar
Quem deveria fazer cada parte? Onde uma decisão precisa ficar registrada?
Aqui surge o TO-BE, “como será”, e pode aparecer a BPMN, uma notação padronizada para representar processos de negócio.
4. Dizer claramente o que a solução precisa fazer
O sistema deve fazer o quê? Que regra não pode ser quebrada? Como saberemos se funcionou?
Entram requisitos, regras de negócio e critérios de aceitação.
5. Olhar o sistema por outros ângulos
Quem usa? Para quê? Como uma ação acontece? Quais conceitos se relacionam?
É aí que aparecem Casos de Uso e diagramas da UML — Linguagem de Modelagem Unificada quando realmente ajudarem a responder uma pergunta.
6. Testar ideias antes de construir tudo
O que precisa entrar primeiro? A pessoa consegue usar? Há risco, custo ou integração complicada?
Entram o backlog — a lista organizada do que pode ser feito —, o MVP — Produto Mínimo Viável, protótipo, qualidade, viabilidade, riscos e rastreabilidade.
Não se preocupe se alguns nomes ainda parecem estranhos. Eles deixarão de parecer quando nascerem de uma situação que você já entendeu.
Agora sim: acompanhe o notebook desde que ele chega
A cliente Ana chega à Conecta, entrega o notebook e conta que ele não liga depois de uma queda de energia. O atendente recebe o equipamento, anota os dados e registra o problema. Depois o notebook segue para diagnóstico, orçamento, possível reparo, teste e devolução.
Repare como fica mais fácil entender quando contamos primeiro o que aconteceu:
Recebimento não é a mesma coisa que entrada de dados
Aqui vale uma distinção importante.
Quando Ana entrega o notebook, estamos falando do recebimento do equipamento, uma etapa real do atendimento.
Ao mesmo tempo, quando o atendente registra nome, telefone e descrição do defeito, essas informações passam a ser dados de entrada para o registro do atendimento.
Recebimento do equipamento
É o acontecimento no processo: o notebook chega à assistência e passa a ficar sob responsabilidade da empresa.
Entrada de dados
São as informações fornecidas ou registradas para que o sistema consiga trabalhar: nome, telefone, equipamento, defeito relatado etc.
Assim evitamos misturar duas ideias diferentes só porque a palavra “entrada” poderia servir para ambas.
E o que acontece com essas informações?
O atendente registra. O técnico diagnostica. A empresa prepara um orçamento. Ana decide se aprova. Se aprovar, o reparo pode continuar. Depois o equipamento é testado e entregue.
Quando os dados são usados para produzir alguma coisa nova — uma situação da ordem, um diagnóstico, um orçamento ou uma decisão registrada — existe algum tipo de processamento.
E quando o trabalho produz um resultado que pode ser consultado ou entregue, temos uma saída. Por exemplo: “orçamento aguardando decisão”, “equipamento pronto para retirada” ou o próprio equipamento devolvido ao cliente.
Por enquanto basta enxergar a diferença entre o equipamento chegando, as informações entrando, o trabalho acontecendo e um resultado sendo produzido.
E se alguma coisa fizer o caminho voltar?
Imagine que o teste final falhou. O notebook não pode simplesmente ser entregue. Ele volta para o reparo.
Ou Ana recusa o orçamento. Essa decisão muda o caminho da ordem.
Quando um resultado retorna e influencia o que acontece depois, podemos falar em feedback, palavra inglesa que significa retorno.
Perceba como o nome aparece só depois de entendermos a situação.
Do problema ao software funcionando
Se colocarmos a viagem inteira em uma linha, ela se parece mais ou menos com isto:
O software funcionando é importante, claro. Mas ele não é o ponto em que paramos de aprender.
A análise não acaba quando o sistema entra no ar
Depois que as pessoas começam a usar o software, aparecem informações que antes simplesmente não existiam.
- um botão pode confundir usuários;
- uma regra da empresa pode mudar;
- um erro pode aparecer só em determinada situação;
- um serviço externo pode mudar;
- o volume de clientes pode crescer;
- uma tecnologia pode ficar obsoleta;
- uma nova necessidade pode surgir.
Isso significa que um produto pode terminar uma versão, uma entrega ou uma fase, mas a necessidade de analisar continua existindo.
Por isso a análise é um ciclo
Entendemos, decidimos, construímos, observamos o resultado e voltamos a analisar quando a realidade muda ou revela algo novo.
É esse o jeito que vamos estudar
Primeiro o problema. Depois o nome.
Se aparecer uma sigla, um símbolo ou um diagrama, procure primeiro responder: que dúvida da Conecta fez isso se tornar necessário?
Você não precisa entrar neste módulo já sabendo Análise de Sistemas. A ideia é justamente construir esse olhar aos poucos.
Uma pergunta simples sobre viabilidade
Antes de investir tempo e dinheiro numa solução, também precisamos perguntar se vale a pena seguir.
Viabilidade é isso: verificar se uma ideia pode ser realizada de uma forma que faça sentido.
Por enquanto, pense apenas:
- esse problema realmente acontece?
- acontece com frequência suficiente para merecer atenção?
- melhorar isso ajudaria clientes e equipe?
Mais adiante vamos acrescentar custo, prazo, risco e questões técnicas.
Antes de seguir, tente contar com suas palavras
- Por que não começamos simplesmente programando o sistema da Conecta?
- O que a história do balanço ensina sobre entender uma necessidade?
- Qual é a diferença entre o cliente entregar o notebook e fornecer dados para o atendimento?
- O que um analista tenta descobrir antes de escolher uma solução?
- Por que a análise pode continuar mesmo depois de o software estar funcionando?
O que estamos tentando entender?
Registre, com suas palavras, por que um software precisa de análise e planejamento antes de ser construído e por que o uso real pode iniciar uma nova rodada de análise.
Agora começa a investigação de verdade
Já sabemos por que analisar antes de construir. Mas ainda falta uma pergunta importante: quem conhece esse problema por dentro?
Quem recebe o equipamento? Quem diagnostica? Quem toma decisões? Quem será afetado se mudarmos o processo?