Você não é simplesmente um profissional de TI

Chamativo o título? :)

Se você trabalha desenvolvendo software, você é um realizador de sonhos. Isso mesmo, bem filosófico, mas já parou para pensar o que REALMENTE você realiza? Esse projeto que você está exatamente agora serve pra que? Que serve pra que? Que serve pra que? (...) No fim, projetos são sonhos, ou partes de sonhos (sejam eles bons ou maus, não vou entrar nesse mérito).

O ponto que quero chegar é que deveríamos estar preocupados muito mais com o valor que estamos gerando a partir das nossas atividades do que somente (não que isso não seja essencial) realizá-las com perfeccionismo.



Um caso verídico :)

O cliente teve problemas com um fornecedor A e sondou seu outro fornecedor B ( \o/ )sobre uma possível re-análise do trabalho realizado por eles. Fui consultada nesse momento sobre a atividade e as minhas considerações.

A primeira resposta foi “Olha.. Se é simplesmente pra deixar o pessoal alocado, com atividades, é isso sim. Se for para deixar o cliente feliz, se for pra atender o que ele realmente quer, vai precisar de mais algumas outras coisas.” Ah! Isso é um problema muito sério, de tirar sono e dar muita dor de cabeça. É um verdadeiro trabalho de vidente (obviamente carregado de experiência) entregar pro cliente o que ele quer, especialmente porque num grande número de casos, nem ele sabe.



Ok, falando praticamente. O fornecedor fez um trabalho de especificação de negócio, geração de documento de padrões, casos de uso, e mais outros artefatos. Até ai parece perfeito. Exceto pela qualidade da documentação produzida que ficou deixando a desejar bastante, com requisitos que não aparecem nos casos de uso e outras atrocidades.

A pergunta era: podemos fazer uma reengenharia dos casos de uso e elaborar um documento de requisito de acordo com os nossos padrões?

Resposta de alguém focado em suas atividades, sem olho no cliente (por melhor técnico que seja): Sim.

Resposta dada: Que dá, dá. Mas pra que o cliente quer isso? Por mais que não esteja nos nossos padrões, eles têm uma especificação. A gente vai formatar dentro do template? Fazer trabalho de formatação e era isso? Porque não dá se basear só nos UCs, já que tem informação faltando neles. É melhor se basear no documento de especificação de negócio, ou seja, transcrevê-lo pro template. (Vulgo trabalho burro)

P.: Ok, e o que você sugere?

R.: Qual é o problema? Do que o cliente ta sentindo falta? Por que ele nos pediu pra fazer isso? Ele certamente não quer pagar nossas horas de consultores porque não gostou da cor do documento. Do que temos conversado em reunião e do que temos analisado com essa documentação, sabemos que o cliente não tem rastreabilidade alguma do que está sendo implementado e isso sim é um diferencial. Podemos catalogar decentemente os requisitos atribuindo IDs e outras propriedades, dentro do nosso template, mas mais que isso, podemos dar ao nosso cliente visibilidade, controle, conhecimento. Podemos dar a ele uma ferramenta de verificação se o que ele ta pedindo dos outros fornecedores está realmente sendo atendido.

Isso mesmo, uma matriz de rastreabilidade. Quem já fez isso na mão, ainda mais pra projeto grande deve estar tendo calafrios. É bem xarope mesmo. :) Feliz de quem tem ferramentas que geram isso automaticamente.

Pensem bem o valor que isso agrega! O diretor de TI do cliente XYZ tem que controlar vários fornecedores fazendo as atividades todas em separado. Um time gera especificação, outro codifica, outro gera analise de teste, outro testa e no fim o pobre do diretor não sabe se todo mundo ta usando todos os 647832483278947329 de documentos que deveriam para gerar tudo isso. O que sai no final? Só Deus sabe.

Agora imagina se ele pode ter uma ferramenta que diz pra ele: O requisito 123 está mapeado nos casos de uso A1, B2, C3 e D4. O caso de uso A1 é coberto pelos testes CTA1, CTA2, CTA3; e o B2 pelos CTB1, CTB2...

Há uma idéia bem mais concreta que o requisito realmente foi implementado. Consegue-se avaliar posteriormente o impacto de uma mudança, pode-se gerar vários indicadores como por exemplo o número de defeito por funcionalidade, avaliar a complexidade de uma funcionalidade, entre várias e várias outras coisas.

Virou um post sobre rastreabilidade :) Mas voltando ao título do post, fica um incentivo a não se limitar somente ao que lhe foi pedido para fazer. Questione, pense como fazer melhor, como gerar valor pra sua organização, pro seu cliente, pra você mesmo. Lembre-se que o que você produz vai em algum momento da cadeia estar realizando sonhos.