domingo, 3 de julho de 2011

Mudanças à vista

Agora faltam poucos dias para mudar de endereço comercial. Novo ambiente de trabalho, nova equipe, nova função e muitos desafios. 

Acho que é normal o medo do novo. Geralmente eu me acostumo com o que faço, mas não suporto a ideia da rotina. Todos os dias a mesma coisa, sem novidades, sem desafios, sem possibilidade de criar. Sou o tipo de profissional que não me nego em pegar uma bomba para resolver, pelo contrário, adoro! Gosto de quebrar meus limites e sentir a necessidade de ser testada. Quando eu chego a minha zona de conforto, fico desanimada. 

Eu preciso de inspiração, não que eu trabalhe com criação que tenha a necessidade de algo que me motive a criatividade. Creio que isso é em qualquer função, aquele desejo de inovar, de fazer algo que seja o diferencial. 

Hoje as pessoas me perguntam: “O que você faz?” Minha resposta tem sido: “De tudo um pouco e às vezes eu faço testes”. Fui contratada para ser analista de testes, porém precisei me adaptar as demandas do projeto que já peguei em andamento. Com a fusão das empresas, o projeto ficou com prazo reduzido. Tive que aprender em pouco tempo a lidar com gerenciamento da equipe, fazer curso de MS Project, saber que para o usuário tudo é urgente. – Para mim, se tudo é urgente, nada é urgente! – Lidar com usuário é o que eu faço de mais difícil e delicado. Alguns usuários têm a ideia de que uma fábrica de software é um balcão de lanchonete, eles fazem o pedido via e-mail, muitas vezes não sabem bem o que querem e acham que serão atendidos em minutos. 

Alguns pontos que aprendi nesta minha nova função.
Sempre estimar um prazo levando em consideração os riscos e eventuais atrasos; 
Nunca deixar o usuário sem feedback do andamento de uma solicitação feita por ele, nem que seja para negociar a deadline e sempre ter argumentos convincentes. Pior que não entregar no prazo, é reestimar várias vezes;
Desenvolvedor é um ser sensível, nem todos os dias eles estarão tão produtivos;
Apesar das reuniões de Scrum serem pela manhã, a equipe só está de corpo presente depois que chega a garrafa de café, ou seja, depois das 9h, antes disso é inútil pedir feedback das atividades de ontem;
Nunca dê bypass no seu superior, mesmo que seja algo necessário, faça ao máximo para que ele participe de qualquer decisão tomada no projeto;
Se algo é urgente, ou é uma mudança de impacto, não espere o retorno de um e-mail. Use o e-mail para registro e ligue para o usuário; 
É gigantesca a diferença entre o nosso entendimento técnico e o que foi levantado no requisito. Em requisito não cabem as palavras: “Acho”, “Talvez”, “Parece”, “Penso” e outras derivantes de suposições. Nunca deixe de perguntar algo que parece ser óbvio. 
Nem todos da equipe têm o mesmo ritmo e sabem o que significa prioridade. Têm desenvolvedores e pessoas que acham que é melhor jogar tudo fora e fazer tudo novo, porque é difícil para ele aceitar um código que não foi ele quem fez. Identificar isso é crucial;
Saber cobrar. Acho que não tem nada mais chato que receber uma atividade ou demanda e alguém ficar a cada 10min perguntando: “E aí? Como estamos?”
  • Primeiro: não “estamos” porque você não está fazendo nada.
  • Segundo: é para isso que tem reunião de Scrum. Existe um momento para cobrar e uma maneira correta de como deve ser cobrado. Cobrar de forma errada é dá um tiro no próprio pé. Todos sabem o que deve ser feito, pois delegar é ter confiança.

Motivar a equipe é o mais difícil. A motivação pode ser até um lanche no fim da tarde, ou simplesmente largar um pouco mais cedo na sexta-feira se conseguir concluir tudo no prazo. A motivação depende das necessidades da equipe e precisa ter feelling para identificar a necessidade de cada um.

Controle e comunicação. Não tem nada mais dispendioso que falha na comunicação. O tal telefone sem fio, ruídos que causam atrasos ou até entendimentos divergentes entre os membros da equipe, ou entre as definições tomadas. Quando isso ocorre é fato que vamos ter problemas. Para evitar isto, todos devem ter ciência do que devem fazer e como devem fazer. Caso haja qualquer impedimento, os interessados devem ser avisados o quanto antes.

Controlar é algo que requer trabalho e atualização, de nada adianta não ter registro da baseline. Um relatório baseado em informações desatualizadas não passa de dados empíricos, um relatório atualizado são informações empíricas que podem ser usadas na tomada de decisão, inclusive para decidir se vale à pena ou não realizar uma atividade.

Essas são poucas as coisas que aprendi sendo um pouco a líder da equipe, ainda tenho muito que aprender. Lidar com pessoas é algo que transcende o nosso entendimento. Hoje já penso em investir nesta função que aos pouco vou sendo convidada a conhecer e assumir.

Não sei ainda se no meu novo local de trabalho vou ter a mesma abertura e a mesma oportunidade. Mas uma vez ouvir uma amiga dizer que as oportunidades são criadas mesmo onde parece não haver possibilidades.

E o mais importante disso tudo é a humildade de assumir os erros. Perguntar quando não souber e reconhecer que o trabalho é fruto do trabalho em equipe.

Lição do dia: Oportunidades são criadas mesmo onde parece não haver possibilidades.

Um comentário:

  1. Acabei finalmente de ler o texto do seu Blog sobre sua mudança. Desejo, como sempre, muita sorte pra você.
    Perceba que a maioria dos pontos que você cita no seu post têm a ver com pessoas, que eu percebo que são a chave do sucesso (ou do fracasso) de qualquer projeto.
    Quanto aos Stakeholders (ou clientes, como você cita), tenho percebido que uma forma interessante de tratá-los é trazê-los pra "dentro" do projeto, deixando claro pra eles a fila de prioridades, demandas e atividades, explicando por quê a atividade que ele solicitou tem um prazo X e não Y. E, caso ele exija prioridade acima das demais, estipular uma política de pedir então que ele solicite a todos os demais da fila que deixem ele passar na frente. Tive bons resultados com isso. :)

    ResponderExcluir