Por: Ariane Ferreira Izac

Algo que tem chamado minha atenção em projetos são fatores comportamentais.

Quando participa de um projeto qual sua postura? Ser reativo ou proativo?

Proativo: “Que se comporta ou pensa de modo antecipado; que busca identificar e resolver possíveis problemas com antecedência, por antecipação”[1]

Reativo: 1. que faz reagir, que suscita reação

2. que reage

3. referente a reação

4. que se define por uma reação [2]

Sugiro uma reflexão bem simples. Imagine o seguinte cenário: existe uma vela próxima a uma janela e que devido a um forte vento, a cortina balança incansavelmente, e ela está bem próxima da vela.

Qual é a melhor decisão a tomar diante de tal situação? Tirar a vela de perto da cortina, colocando-a em cima da mesa para evitar que a casa seja incendiada ou ligar para o bombeiro apagar o incêndio? Acabar com foco do incêndio ou andar sobre os destroços? Inalar a fumaça do fogo ou agir para que o fogo não se alastre?

Fazendo um paralelo com projetos a ideia é a mesma. É muito mais fácil tratarmos algumas situações antes que se transformem de fato em um problema, antes de “explodir” e ter de tratar quando ele já tomou grandes proporções. Às vezes podemos tomar a simples decisão de sermos proativos para evitar chamar o bombeiro antes que a vela incendei a casa toda. Cabe ainda dizer que nesse cenário sempre podemos ter visões diferentes, por exemplo, poderia ter alguém que opinaria que não deveria haver preocupação, já que o vento na verdade apagaria a vela ao invés de incendiar casa.

Vamos trazer o cenário para um projeto que use scrum, cenário de uma sprint[3]. Por diversas vezes nós até identificamos algumas situações que são potenciais problemas para a conclusão da sprint, impedimentos ou obstáculos, como queira chamar. Muitas vezes somos passivos a essas situações por vários fatores, seja por achar que não é seu papel “cobrar” o outro, ou por achar que concluir a sua atividade proposta para o dia é suficiente. Mas e o todo? Estamos olhando “com carinho” para ele? Ou será que estamos esperando que o outro olhe?

Citarei alguns exemplos simples de proatividade que podem fazer a diferença em nosso dia a dia:

Sinalizar atrasos\problemas: O seu problema não é só seu, é do time caso ele impacte a entrega. Então nada mais justo que você compartilhe seus atrasos para que o time em conjunto tente achar uma solução para que isso não tome proporções maiores. Nunca fique patinando mais de 30 minutos (acho que chutei alto ainda) em um mesmo problema. Às vezes existe uma vírgula, ou a falta dela que você não está enxergando que o outro que veio te ajudar consegue identificar isso mais rapidamente, por ser uma visão de fora. Quando você narra o problema para o outro você mesmo pode achar a resposta. Outro detalhe importante é que não precisa esperar até a daily[4] para sinalizar que está com impedimento em sua atividade. Grite, mande sinal de fumaça, e-mail, skype, slack, hangouts, enfim, independente de qual seja o meio de comunicação utilizado no projeto, utilize com antecedência. Só não sofra calado!

Comprometer-se com datas: Temos consciência de que nem sempre as coisas acontecem como planejamos, podemos nos deparar com imprevistos. No entanto, é importante comprometer-se e principalmente cumprir com as datas prometidas de nossas atividades. Uma atividade com atraso faz com que a seguinte consequentemente já nasça atrasada e por ai vai. Perceba que aplicar o item anterior pode colaborar para que esse tópico seja cumprido dentro do previsto ou mais próximo dele.

Posicionar-se mais: Principalmente nas dailys. Sinalize atrasos, questione atrasos e principalmente questione sobre quais serão as ações para minimizá-los. É importante também nesse contexto que forneça sugestões para o time. Quanto a erros encontrados que nem sempre são corrigidos dentro da sprint, principalmente quando são pré-existentes é necessário posicionar-se também. Se o defeito identificado faz parte do fluxo básico da funcionalidade, por que não corrigir antes que o cliente abra um chamado daquele caso? Não digo somente do ponto de vista de um testador identificando um cenário com o erro, mas o próprio desenvolvedor que consegue identificar problemas de codificação. Lembre-se, sejamos proativos.

Sentir-se dono da sprint: Sentir-se dono da coisa faz com que cuidemos melhor dela. Isso é realmente verdade, as pessoas cuidam bem de suas próprias coisas, sentir-se parte não só como membro da equipe mas sentir-se dono daquilo faz com que tenhamos mais cautela e zelo para que tudo corra bem, dentro do planejado.

Em resumo os itens citados foram mais comportamentais, perceba que foram pequenos exemplos citados mas que aplicados no dia a dia fazem a diferença. Tente tender sempre para ser mais proativo do que reativo. As situações expostas em um “time reativo” correriam atrás do atraso próximo da entrega, mas qual o custo disso? A qualidade não seria comprometida? E o desgaste que pode surtir no time?

Ser reativo é sentir-se vítima do cenário vivido, é assistir de camarote os problemas nascerem e esperar que alguém os solucione. Ser proativo é fazer parte da mudança, é ação, é simplesmente fazer acontecer.

Para finalizar, deixo uma frase da postura do reativo e proativo para reflexão

“Um proativo é parte da solução. Um reativo é parte do problema!”

Lembrando que esses conceitos podem ser aplicados para qualquer profissão, não se restringem somente a projetos de TI.

E por fim, qual sua escolha para hoje? Será reativo ou proativo?

CADASTRE-SE no Blog Televendas & Cobrança e receba semanalmente por e-mail nosso Newsletter com os principais artigos, vagas, notícias do mercado, além de concorrer a prêmios mensais.