Em busca da produtividade

Já há um bom tempo venho procurando formas de melhorar a minha produtividade. E ao longo desse tempo, encontrei soluções interessantes, algumas coloquei em prática e deu certo, outras não.

A motivação para escrever esse post, é compartilhar a minha atual receita para a produtividade e também fazer alguns comentários sobre o assunto. Porém, já vou avisando, que não há uma receita de produtividade que funcione para todos, o segredo é a combinação e adaptação de técnicas existentes.

Simples mas nem tanto

A minha receita possui três ingredientes principais, que são bem simples de se encontrar. No entanto, há alguns temperos que já não são tão fáceis assim.

Mas vamos aos três ingredientes:

  • Quebrar o seu tempo em timeboxes (“caixas de tempo”) – para isso eu utilizo a técnica Pomodoro (até já coloquei uma apresentação que fiz sobre ela no blog);
  • Uma boa trilha sonora: esse já é um ingrediente pessoal e não tão comum nas listas do pessoal. Esse ingrediente pode não ser útil para alguns, pois há pessoas que não conseguem se concentrar escutando música.  No meu caso eu sou 8 ou 80 em relação a esse ingrediente: para me concentrar ou preciso de “muito barulho” (música) ou de silêncio pleno (que em cidades grande só é encontrado à noite);
  • Ficar sozinho – não estou dizendo para ficar trancado na sua sala, mas sim que é importante ficar concentrado durante um timebox, para quem usa a técnica Pomodoro esse timebox é de 25 minutos (um pomodoro), sem nenhuma interrupção externa.

Agora vamos ao porquê do uso de cada ingrediente, lembrando que essa é uma receita caseira e que está funcionando bem para mim atualmente, mas isso não significa que irá funcionar perfeitamente para você (até acho difícil), mas pode servir de base/inspiração.

Tempo X Tarefas

Utilizando a técnica Pomodoro, aprendi a dividir e priorizar melhor as minhas tarefas ao longo do tempo. Um dos grandes benefícios do uso do Pomodoro na minha opinião, é que ele força você a ser “mono-tarefa”, e ao contrário do que se pensa, isso é muito bom.

É importante também saber priorizar as suas tarefas, colocando um peso sobre cada uma, ou simplesmente colocando-as na ordem. Lembrando que não é possível abraçar o mundo e por isso precisamos fazer o que é mais prioritário.

Em relação as ferramentas, eu utilizo o Focus Booster (que é um “contador de pomodoros”) e uma planilha no Google Docs para registrar minhas tarefas e o tempo que gasto em cada uma.

Rock’n Roll

A música me ajuda tanto para evitar as interrupções, por exemplo: evita ouvir outras conversas e querer participar delas, durante o pomodoro, e também me ajuda na concentração. Como tenho um gosto musical variado, e nem todas músicas me ajudam (ex.: bandas como o Mamonas Assassinas e Cuio Limão), acabei criando uma lista de músicas específica para ouvir durante os pomodoros, geralmente com as mais pesadas (ex.: One – Metallica) e as que mais gosto (ex.: It’s My Life – Bon Jovi).

Além disso, como gosto bastante de ouvir música, as tarefas acabam se tornando até mais agradavéis ao ouvir uma boa música (imagina o contrário, você trabalhando ouvindo músicas do ritmo que menos gosta).

Aqui no trabalho o ambiente não é dos mais silenciosos, e não acho ruim, pelo contrário (tem horas que até eu ajudo a bagunçar rs), porém não consigo um bom nível de concentração num ambiente barulhento, por isso a música por mais estranho que pareça, também me ajuda nesse quesito, além é claro de auxiliar na solitude.

Solitude

Muitas pessoas se sentem mais produtivias ou preferem trabalhar a noite, e um dos motivos para isso é que a noite geralmente há menos barulho e pessoas no escritório. No meu caso, não tenho uma preferência por dia e noite, embora concorde que seja mais fácil se concentrar a noite.

É importante lembrar que este ingrediente pode ser útil ou não, dependendo do tipo de atividade que será executada, do perfil da pessoa e das funções que exerce. Eu mesmo no começo não gostava/conseguia ficar queto durante muito tempo, mas quando você percebe a diferença na produtividade, acaba vendo o quanto é bom ficar “na sua” de vez em quando.

Mas por favor, não entendam errado, não quero dá a impressão que devemos nos isolar e cada um ficar na sua baia calado. Até porque isso não é bom num ambiente criativo, como deve ser o de uma equipe de desenvolvimento de software. O que acredito é que há o tempo certo para cada coisa, por isso que o ambiente de trabalho não deve ter o silêncio mórbido de um cemitério, nem o barulho de uma feira, devemos buscar o equilíbrio.

Os temperos

Na minha experiência, alguns temperos podem tornar mais eficiente essa receita e outros são essênciais:

  • Autoconhecimento: esse é essencial, pois a implementação e combinação das técnicas existentes dependerá muito do tanto que você se conhece. O autoconhecimento é primordial para conseguir uma boa receita de produtividade para você, e por isso também que a receita irá sempre sofrer modificações (a busca pela produtividade é contínua), pois além da nossa rotina ir mudando ao longo do tempo, vamos nos conhecendo melhor também (ou deveríamos);
  • Organização: é fundamental, tanto em relação as suas coisas (um exemplo que parece até bobo: a sua área de trabalho) quanto as suas tarefas/agenda;
  • Disciplina: esse é difícil, principalmente no começo, pois várias técnicas que ajudam a obter mais produtividade exigem disciplina, por exemplo, a própria técnica Pomodoro. Eu mesmo, não sou nem de longe o melhor praticante desta técnica, pois demorei um bom tempo para usá-la todos os dias, e ainda hoje, em alguns momentos é difícil usar;
  • Uma boa máquina: esse é básico, não tem como ser produtivo trabalhando numa máquina que trava toda hora;
  • Usar dois monitores: pode parecer frescura, mas dois monitores podem ajudar bastante na produtividade. E hoje em dia, com os preços bem mais acessíveis do que antigamente, não é mais um luxo ter dois monitores. Mas confesso que demorei um bom tempo para começar a usar, pois no começo achava estranho, mas hoje o uso de dois monitores facilita bastante a execução de várias tarefas;
  • Caça aos “comedores” de tempo: quando não usamos nenhuma técnica de gerenciamento do tempo, acabamos nem sabendo onde gastamos o mesmo, e em muitos casos, perdemos uma boa porção de tempo em atividades não tão importantes assim. Exemplo clássico são aqueles joguinhos do Facebook, nada contra jogos, mas que eles são grandes “comedores” de tempo, isso eles são, e o valor agregado é quase nulo, tirando a diversão;
  • Fazer o que gosta: esse é ESSENCIAL, se há um segredo para a produtividade deve ser esse. O tempo voa quando você está fazendo uma tarefa empolgante, e isso é muito bom.

Como puderam perceber o segredo dessa receita está no tempero, e cada um pode dá o seu toque especial. ;)

E você, usa alguma técnica para aumentar a sua produtividade ou tem alguma dica?

Fique por dentro das novidades, assine o feed do QualidadeBR.

  • Usar dois monitores: pode parecer frescura, mas dois monitores podem ajudar bastante na produtividade. E hoje em dia., com os preços bem mais acessíveis do que antigamente, não é mais um luxo ter dois monitores. Mas confesso que demorei um bom tempo, para começar a usar, pois no começo achava estranho, mas hoje o uso de dois monitores facilita bastante a execução de várias tarefas;

Como ser produtivo? Contando tomates

Ontem realizei uma apresentação com o título “Como ser produtivo? Contando tomates”. A palestra foi feita no 2º Desembucha Aí!, um evento que ocorre aqui na Voice Technology, no qual são realizadas palestras rápidas, de no máximo 25 minutos sobre determinado tema.

O objetivo dessa palestra foi apresentar em 1 pomodoro, o que é a técnica Pomodoro e como ela pode te ajudar a ser produtivo.

Abaixo, compartilho a apresentação utilizada no evento:

Muito obrigado a todos que estiveram no evento! :)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

A 16ª Mesa Redonda DFTestes teve  como tema “Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?”. A discussão teve 12 respostas e 6 participantes, sendo eles: eu, Elias Nogueira, Marcelo Andrade, Sarah Pimentel, Felipe Silva e o Rodrigo Almeida de Oliveira.

A seguir faço um “resumo” do que foi discutido na mesa redonda, quem quiser conferir a discussão na íntegra pode acessar esse link (é necessário cadastro).

Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

O Elias Nogueira deu a sua resposta dizendo:

Olha, esse é um tema bem amplo e geralmente o terror de muitos testadores…
Já ví muitos “chefes” querendo medir a produtividade de um Analista de Teste pela quantidade de Casos de Teste criados, e isso é totalmente errôneo no meu ponto de vista.

A medição de produtividade, também ao meu ver, deve ser feita através de bases históricas, relacionando o tempo que um Analista de Teste levou para criar o Caso de Teste e quanto tempo um Testador levou para testar ou retestar. Só que precisamos dessas métricas, logo para ter uma estimativa aceitável para que eu possa chegar num Analista ou Testador e dizer que ele não está produzindo eu preciso de algo que me diga prove isso.

O normal que eu vejo é utilizar o bom senso em equipes que não possuem um base para estimativa e definir metas diárias ou semanais de execução e acompanhar o andamento, não em termos de cobrança mas para resolver os problemas que possam ocorrer e que geram uma parada nestas atividades.

O Elias ainda resumiu a sua opinião dizendo:

-> Só se pode medir produtividade se sabemos realmente quanto tempo é gasto na atividade (necessidade de base histórica);
-> Muitos problemas ocorrem durante essa fase (design e execução de teste) que influenciam, como requisitos mal escritos ou a falta dele, e até o não entendimento dos requisitos pela equipe;
-> Medir produtividade por quantidade de Casos de Teste criados não é legal!

A Sarah Pimentel fez a seguinte explanação sobre a questão:

Se determinada métrica é sentida pelo time como um objeto de pressão, talvez algo precise ser readequado, a métrica ou até mesmo a sua interpretação. O mais importante ai é que números são apenas números e sem explicações, sem o background de um cenário, eles não dizem muita coisa e o que dizem ainda pode estar errado.

Primeiro, pra que você quer medir a produtividade do seu time?

Crie uma resposta humana para essa pergunta e atenha-se a ela quando quiser medir a produtividade.

Medir a quantidade de casos de teste produzidos por dia (e agora sem considerar por analista) pode me ajudar a ver o percentual consumido do meu schedule até então e me ajudar a replanejá-lo, se for o caso,  para que as atividades sejam finalizadas.

Medir a quantidade de casos de teste produzidos por analista em um dia pode me ajudar a identificar problemas/dificuldades que não me foram diretamente sinalizadas por um membro da minha equipe quando sua média estiver muito aquém da margem dos seus colegas.  Ou se estiver muito além pode sinalizar um problema na elaboração dos casos (alguém já viu gente que cria um caso de teste de um step e dá ele como finalizado?).

Lembrando que existe uma média de produção diária, existem ocorrências que aceleram ou retardam essa produção, e existe a capacidade de produção de cada um que é diferente. Uns demoram mais, outros menos, e isso deve ser perfeitamente natural e aceitável em qualquer atividade.

Como medir produtividade de um time? Com alguém que entenda além de números e métodos estatísticos, de pessoas!

O Felipe Silva respondeu a questão dizendo:

Eu não conheço uma boa. A principal que conheço quantidades de TCs criados ou executados por determinado tempo. Sou totalmente contra este tipo de avaliação, pois desconsidera quase todos os fatores influenciadores, o primeiro desconsiderado nesta métrica é a qualidade, é fato que um teste feito com qualidade leva mais tempo que um teste feito de qualquer jeito (o que é facilmente descoberto quando os bugs que deveria ter sido pegos aparecem), ou fator desconsiderado é a complexidade da funcionalidade sob teste, testar 50PF (isso quando existe um tipo de métrica como PF) não é o mesmo que testar 5PF e também não é o mesmo que testar 5 funcionalidades de 10PF, e o terceiro fator desconsiderado que penso de primeira instancia é a qualidade inicial do código, pois testar uma funcionalidade que “funciona” é mais rápido do que testar uma que não funciona (tempo para relatar defeito, lerdeza da funcionalidade, fluxos que não funcionam e etc)

Não me perguntem uma forma de avaliar individualmente cada testador, pois não conheço um jeito justo e fácil (que não leve muito tempo para coletar), se for para avaliar “A equipe”, ai sim daria para calcular uma produtividade média.

O Rodrigo Almeida compartilhou como ele avalia a produtividade da sua equipe:

Aqui eu meço a produtividade da equipe baseado nas atividades entregues, tempo por atividade (gravação de caso de teste, execução dos testes manual/automatizado). E também avalio alguns itens subjetivos como postura profissional, trabalho em equipe, relacionamento, etc.

A Sarah ainda fez algumas sugestões de métricas que podem ser usadas:

Percentual de consumo de schedule :
-> para elaboração de casos de teste
->para execução de casos de teste no ciclos
Esse percentual pode ser medido levando em consideração:
-> quantidades (quantos casos de teste tenho a elaborar, quantos casos de teste tenho a executar, …), que não é muito real, mas ajuda;
-> tamanho (em relação ao tamanho total do software quanto você já cobriu considerando a representatividade do requisito coberto em UCPs ou FPs)
-> risco (utilizando o fator de risco de cada requisito)
Na minha opinião a “melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores” é a que traga bons resultados e incentive a melhoria contínua na sua equipe. :D
Pode ser tanto usando métricas, quanto pelo feeling. Uma junção dos dois pode ser interessante.

Com tanta coisa para fazer, por que eu ainda vou querer medir a produtividade dos testadores? Para fazer uma plaquinha de melhor testador do mês?

Segundo o Elias pode até ser feito bom uso da “plaquinha de melhor testador do mês”:

No termo da “plaquinha de funcionário do mês” dá pra fazer algumas coisas sim, e acho isso muito bom.

Um exemplo é ter a métrica de falsos-positivos por testador, que é, por exemplo, os bugs que são abertos que não são bugs ou mesmo a execução do Caso de Teste sem a devida atenção.

Outro é medir o tempo de reteste de um bug, onde tu vê se o testador está levando quase o mesmo tempo de execução do Caso de Teste.

Segue abaixo a minha resposta para a pergunta realizada.

Por que você é um gerente ausente?

Explicando melhor o motivo da minha pergunta.

Por que você é um gerente ausente?

Essa pergunta vale para quando essa necessidade de medir a produtividade vem do gerente/líder/coordenador da equipe.

A minha visão e opinião sobre uma pessoa que exerce um dos papéis citados acima, é que ela tem que interagir bastante com a equipe e conhecer bem ela.

Nos projetos que participei na empresa, que não é uma mega corporação, nunca tivemos a necessidade de medir a produtividade dos testadores, ou de qualquer outro membro da equipe. E isso deve ao fato de todos trabalharem juntos, fazerem reuniões periódicas sobre o andamento das tarefas, etc. Ou seja, todos atuando como um verdadeiro time.

E neste cenário os gerentes/líderes tem conhecimento de como estavam a produtividade de cada membro da equipe, e até os próprios membros da equipe tem essa informação, se eles se atentarem a ela.

Uma analogia que pode ajudar a entender melhor o que quero dizer:

Temos dois torcedores brasileiros: um vai assistir o jogo no estádio e o segundo vai ver pela TV.

No final do jogo quem terá uma melhor avaliação do desempenho da seleção brasileira?

O que viu no estádio, pois ele tem uma visão de todo o jogo e do comportamento dos jogadores quando estão sem a bola também. Na televisão a câmera foca onde está a bola, e assim o telespectador tem uma visão limitada do jogo.

Agora se a demanda por essa informação vem de outros e esses outros adoram métricas, o que é muito comum em nível gerencial, acredito que uma boa forma de informar essas métricas é através de resultados concretos obtidos pelos testadores, alguns exemplos:

  • Quantidade de casos de testes executados;
  • Número de bugs encontrados;
  • Quantidade de novos cenários de teste encontrados;
  • Quantidade de melhoria sugeridas.

Algo muito importante ao fazer um relatório sobre a produtividade do time é saber avaliar as métricas, pois números por si só são só números, nem sempre o testador que encontra mais bugs é o melhor ou mais produtivo.

E como disse antes, tentar medir trabalho cognitivo não é fácil e muitas vezes não é nem necessário utilizar métricas para isso, mas infelizmente muitas pessoas seguem o caminho da tirinha do Nerdson, compartilhada pelo Marcelo, que como um amigo meu diria, é uma verdadeira “PALHA-ASSADA”.

O Marcelo Andrade fez uma questão bem pertinente a discussão, sobre a definição de produtividade.

Afinal de contas, o que é “produtividade”?

A Sarah Pimentel respondeu a pergunta trazendo a definição da Wikipédia:

“A produtividade é basicamente definida como a relação entre a produção e os factores de produção utilizados. A produção é definida como os bens produzidos (quantidade de produtos produzidos). Os factores de produção são definidos como sejam pessoas, máquinas, materiais e outros. Quanto maior for a relação entre a quantidade produzida por factores utilizados maior é a produtividade.”

Sendo assim, a quantidade de casos de teste criados por um analista em um dia é sim uma métrica de produtividade. Se ela deve ser utilizada ou como ela deve ser utilizada é outro ponto.

Eu vejo que produtividade é: tempo de trabalho – tempo trabalhado  X resultados

Exemplo: o Zé trabalhou 8 horas, mas só durante 6 horas 100% focado no trabalho (1 de almoço e mais 1 de procrastinação) e nesta 6 horas ele conseguiu:

  • Preparar o ambiente de teste.
  • Executar os casos de testes da funcionalidade X e Y;
  • Reportar 6 bugs.

Mas e aí, o Zé foi produtivo ou não? Para saber é necessário ter uma base histórica, analisar as características das atividades (ex.: o ambiente de teste era Windows/Linux, quais softwares teve que instalar, etc). Ou seja, as métricas em si não são o fim, e sim o início para avaliar a produtividade do testador.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.