segunda-feira, 28 de abril de 2008

Comunicação? Não... não é tão importante. E também: o guri de 18 anos.

Semana passada implantei a metodologia de SCRUM para atacar um dos principais problemas do laboratório: COMUNICAÇÃO. Pois não é que hoje eles conseguem me pregar mais uma peça?!

Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:

- E ai, Flavio, amanhã vamos apresentar o sistema então?

- Hein? Qual sistema? (surpreso)

- O da administração da universidade, para o controle de ativos!

- Não estou sabendo de nada!!! (aflito)

- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.

- Ah... tá bem, mas estou sabendo por ti agora. (resignado)

O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.

De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.

----------------------------------

Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...

Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.

O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).

Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.

Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.

Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!

Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?

Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!

Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".

Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!

Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.

Um comentário:

Anônimo disse...

Sobre o último parágrafo, duas idéias, "Conquiste seus funcionários, antes dos clientes". E, qual a motivação que eu tenho de fazer algo do qual não participei da concepção e/ou não acredito e/ou não escolhi? Lembrando que dinheiro não é um bom motivador, principalmente para jovens técnicos...