Levantamento de informações na definição de sistemas

Apoie nosso trabalho,
doe um libre!

“Você é que não sabe pedir!”

Poucas frases mais estúpidas podem sair da boca de um gerente de sistemas

A análise de sistemas envolve várias etapas. Diferentes autores divergem em quais são elas e como se deve dar o ciclo de desenvolvimento, mas todos concordam em um aspecto: o primeiro passo é entender perfeitamente o que o usuário precisa, para não ter dores de cabeça depois.

Quanto mais sucesso você obtiver nessa etapa, menos trabalho você terá com seu usuário e mais suave será a implementação. As técnicas para isso vão desde uma simples entrevista com quem está solicitando o sistema até fazer um estudo detalhado de usabilidade, passando dias presenciando e filmando como as pessoas de “chão de fábrica” trabalham com o sistema atual, seja ele automatizado ou manual.

Pode parecer meio óbvio que você tem que saber o que fazer para poder fazer bem feito, mas alguns gerentes cabeçudos insistem em que o usuário é quem tem que saber pedir direito. O problema se agrava quando o usuário é um cliente interno, porque ter problemas em atendê-lo aparentemente não representa perda de dinheiro.

Até a balconista do lugar onde eu costumo tomar café sabe que, quando um cliente pede um café, ela precisa perguntar se ele quer puro ou com leite. E ela nem precisou fazer faculdade para isso. Se ela tenta adivinhar o que eu quero e me traz um café puro, “porque é o que todo mundo pede”, ela pode ter que jogar aquele fora e fazer outro, se o que eu queria era com leite. Talvez tenham explicado para ela uma vez ou duas quando ela foi introduzida na difícil arte de apertar os botões da máquina, talvez ela tenha tido que jogar alguns cafés fora, mas o fato é que ela aprendeu.

Mas tem gente que não aprende. Algumas pessoas têm o péssimo hábito de entender de tudo, mesmo do que não é de sua área. Sejamos francos: eu não sei os detalhes do que o funcionário do departamento de vendas faz no dia a dia, assim como ele nem imagina os detalhes do que eu faço. Por isso a etapa de levantamento é importante. O gerente de vendas sabe muito bem como convencer as pessoas a comprarem seu produto, mas não faz a menor idéia de qual é a melhor maneira de registrar essas vendas em um sistema informatizado. Ele sabe que no final do mês precisa ter relatórios de quanto cada vendedor vendeu, como as vendas se distribuíram ao longo do ano, qual o produto mais vendido, etc. É isso que ele vai te dizer ao pedir o sistema.

Ele não dirá logo de cara: “Meus 357 vendedores registrarão no sistema uma média de 20 vendas cada um, todos os dias, mas no Natal esse valor triplica. Por isso, preciso de um servidor de banco de dados do tipo XY.” Ele vai te pedir um relatório e você é quem deve perguntar quanto os vendedores costumam vender, quantos vendedores ele tem, se tem alguma época do ano em que as vendas aumentam muito e qualquer outra informação que influencie no desenvolvimento do sistema. Um bom questionamento nesse caso seria perguntar se os vendedores vendem na rua e trazem uma planilha com as vendas anotadas ou se eles vendem por telefone e ficam sentados na frente do micro, podendo consultar o estoque e digitar a venda no momento em que ela é efetuada. Isso representará uma diferença fundamental na definição do sistema.

Uma das regras de ouro que eu ensino aos funcionários das equipes que eu gerencio é nunca suponha nada. Na dúvida, pergunte. Nada de supor que o usuário vai usar o sistema só de dentro da empresa: pergunte se não vai ter gente precisando usar na rua. Nada de supor que as informações que vão popular inicialmente as bases de dados serão todas digitadas: pergunte se já existem dados em Excel, no Word ou algum outro formato que possa ser convertido. Nada de supor que o processo de entrada de dados que existe hoje atende a todas as necessidades do cliente: pergunte se tem algum tipo de informação que o sistema não aceita e que ele está precisando controlar em um caderninho.

“E perguntem para mim, nada de programador ficar ligando o dia todo para o usuário porque ele tem mais o que fazer”. O gerente deve centralizar essas dúvidas, para não perguntar a mesma coisa duas vezes, não perder o tempo do cliente com coisas estúpidas e perguntar tudo de uma vez. E, principalmente, para aprender com essas dúvidas e saber que tipo de informação deve ser levantada da próxima vez.

Um erro comum é imaginar que aquilo que você considera como o melhor fluxo de trabalho vai resolver o problema do cliente. Fazer um sistema de publicação de conteúdo em um site, em que as matérias inseridas pelos jornalistas devem ser conferidas e aprovadas por um editor, é muito bonito e atende à necessidade de muita gente, porque mantém o controle da publicação centralizado nos editores. É muito interessante para quem tem estagiários que colocam um texto meia-boca no sistema, que precisa ser temperado por um jornalista mais experiente.

Mas se você faz isso sem perguntar e entrega o sistema assim, terá uma bela surpresa quando vir que todos os usuários estão sendo criados como editores, porque o responsável pela publicação confia no trabalho de toda sua equipe e quer agilidade na publicação de matérias. E esse é um exemplo inócuo, no qual você apenas perdeu tempo seu e da sua equipe resolvendo problemas que não existem. Em muitos casos você vai ter que jogar metade do trabalho fora e fazer tudo de novo, com o prazo já estourado.

Entenda o que o usário precisa e anote tudo; explique para ele o que você pretende fazer; se precisar mudar o fluxo de trabalho, avise e explique porque; quando houver mais de uma opção, ofereça escolha; e nunca mude o processo que será automatizado sem avisar. Você pode até estar certo em alterar o processo para otimizar algumas coisas, mas se você não explicar isso *antes*, vai deixar o cliente com a sensação de “quem esse cara pensa que é para mudar o jeito como eu trabalho assim sem mais nem menos”? Lembre-se que um dos problemas de rejeição à automação é o medo de não ter capacidade para trabalhar com o sistema automatizado. Mostre que a automação está lá para ajudar e não para tornar as coisas mais complicadas.

Gostou da matéria? Doe um libre
e ajude nosso projeto a continuar!

4 comentários para Levantamento de informações na definição de sistemas

  • Tânia

    Tá, tudo bem….tentando ser criativa…(tá certo que eu queria dizer mesmo que gostei muito do seu blog…é que sou caloura, tenho visitado “n”…e a maioria não é nada interessante)…Assuntos variados, inteligente, adulto (bênção!)…Você escreve bem (ih..estou falando que seu blog é legal…mas pode deixar que não vou pedir para que visite o meu…se bem que quem vai sair perdendo é você, mas…seu desejo é uma ordem)…
    Ah, tá…o comentário teria que ser sobre o texto?.. Gostei(“ir até aonde o povo está”…”amar se aprende amando”… “cada um com seu cada um”…”o que é bom pra mim, nem sempre o é para o outro”…”as máquinas não mordem”…).
    Nem posso dizer que você escreve bem?…Tá.
    Então, só me resta deixar um beijo (isso pode?).

    http://www.flordapele.blig.ig.com.br

    (o endereço do meu blig é a assinatura…Nem te convidei)

    Thumb up 0 Thumb down 0

  • +crux+

    Um amigo meus disse ser a favor de que os programadores entrem em contato diretamente com o usuário. A meu ver isso só funciona se o programador tiver um “skill” de analista suficiente para não fazer bobagem quando você tirar ele da coleira, ou quando você tem um líder de projeto cuidando de uma sub-equipe.

    Ou seja, se você tiver uma pessoa competente a quem possa delegar esse contato.

    Thumb up 0 Thumb down 0

  • Capitu

    “clap, clap, clap!*

    Thumb up 0 Thumb down 0

  • Ju

    Não só concordo com tudo o que foi dito aqui, como quero tirar o chapéu para sua análise e perguntar “porque todo mundo não é assim???????????”
    Posso usar seu texto no meu blog? Dando a fonte, claro!

    Thumb up 0 Thumb down 0

Enviar resposta

Você pode usar estas tags HTML

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>