Se você estivesse lendo este texto no LinkedIn, seriam grandes as chances de ter checado, antes de clicar, o tempo de leitura do artigo indicado pelo site ali ao lado do meu nome. O recurso está longe de ser exclusivo, já que outras plataformas digitais, como o Medium por exemplo, também apresentam essa informação para ajudar o leitor a se programar. Uma curiosidade interessante a esse respeito é que, muitas décadas antes do digital reinar, a revista semanal impressa O Cruzeiro, que circulou no Brasil entre 1928 e 1975, já demonstrava essa preocupação em informar a quem lia o tempo que deveria ser investido para o consumo de seu conteúdo (como conta este post no Medium que leva só 2 minutinhos pra ler).
De volta aos tempos atuais, com infinitas possibilidades digitais para entretenimento e trabalho, o gerenciamento do tempo se consolidou como uma das capacidades mais importantes que alguém pode ter. E isso vale tanto no campo profissional, seja na vida pessoal, e, mais especificamente, para conseguir conciliar as duas coisas. Não surpreende, portanto, a naturalização de um feature como “tempo de leitura”, que, aliás, poderia muito bem ser estendido para outras esferas. Eu mesma já imagino isso aplicado em e-mails, apresentações…
E as reuniões? Sabemos que elas, na teoria, muitas vezes já têm hora certa para começar e terminar. Porém, nem sempre a duração estipulada para uma reunião é o tempo que de fato passamos nela. Por conta da minha experiência como analista de projeto e performance, esse é um ponto crucial e uma das fundamentações do meu trabalho, mas vou deixar isso de lado por um momento. Sabemos que, mesmo com tantos recursos disponíveis, a pontualidade e a concisão ainda são qualidades um tanto quanto raras no geral. Já eram quando os colaboradores de uma empresa se reuniam a portas fechadas em uma mesma mesa. E continuam sendo nesses tempos em que uma “sala de reunião” consiste em um invite, um link e um grupo de pessoas encarando cada um a sua própria tela.
Arrisco dizer que, se por um lado a coisa melhorou — menos tempo gasto em deslocamentos, encontrar uma sala vaga etc. —, por outro, a competição pelo nosso tempo também aumentou drasticamente. Quem aí, que está trabalhando em home office, já não teve que participar de reuniões e mais reuniões? E, ainda, com a diferença de que agora elas são marcadas sem um minuto sequer de intervalo entre uma e outra? Nesse contexto, cinco minutos de atraso significam um caos progressivamente maior conforme o dia avança. E, ao final, cadê o tempo para fazer todo aquele trabalho que foi se acumulando?
Só é Agile se for ágil mesmo
No universo do desenvolvimento de produtos digitais, a preocupação com o tempo — entre outros fatores — e com entregas faseadas, que agreguem valor em cada etapa, fez nascer a filosofia Ágil (ou Agile, no original, em inglês). Ela é resumida no Manifesto para o Desenvolvimento Ágil de Software, criado em 2001, a partir do encontro de 17 profissionais que já usavam métodos ou frameworks. Neste caso, usavam, por exemplo, Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development e Pragmatic Programming. Essa filosofia uniu os pontos em comum dessas diferentes abordagens em quatro valores e 12 princípios fundamentais.
Como meu objetivo aqui é falar especificamente do fator tempo (e para economizar o seu), não vou me deter em explicar Agile ou SCRUM (o framework que eu emprego particularmente no meu dia a dia). Para quem ainda não está familiarizado, recomendo os links do próprio manifesto, acima, e esses dois, que trazem um resumo didático sobre ambos. Mas, resumindo bem (bem mesmo), a principal diferença dos métodos ágeis para o modelo anterior, da metodologia em cascata, é que os projetos ágeis são desenvolvidos de forma “fatiada” e muito mais flexível (portanto, ágil, mesmo em casos de mudanças). E além disso o foco é ter um produto “rodando” o mais rápido possível, sempre focando em entrega de valor. Você também pode ler um pouco mais sobre as diferenças entre as metodologias aqui (em inglês).
Note que só com uma descrição superficial das abordagens já dá pra perceber que o tempo é um fator importantíssimo de diferenciação entre elas. Isso no macro. Mas hoje estou aqui pra falar que o tempo deve ser tratado como uma das prioridades em cada ritual que compõe o processo de desenvolvimento.
Pra quem não conhece SCRUM (e ainda não teve tempo ou disposição de checar os links), projetos conduzidos com esse framework contam com cinco eventos, ou cerimônias, principais:
- Sprint Planning (planejamento daquilo que será realizado pelas próximas 2 ou 4 semanas, durante a Sprint em si, que nada mais é que uma etapa de trabalho);
- a própria Sprint, como descrita anteriormente;
- Daily Scrum Meeting (reuniões diárias de 15 minutos, em média, para discutir o que foi feito no dia anterior, o que será feito naquele dia e quaisquer impedimentos ao trabalho);
- Sprint Review (reunião em que o time discute o que foi feito na Sprint e que dura 8 horas para Sprints de 4 semanas e menos tempo para Sprints menores)
- e Sprint Retrospective (na qual se revisa a Sprint sob o ponto de vista da melhoria de processos, da comunicação e da interação entre as pessoas, com duração similar à da Sprint Retrospective).
Note que todos esses eventos têm uma coisa em comum: tempo determinado de duração (e também data e horário certos pra acontecer, embora eu não tenha destacado isso no texto anteriormente). Além de ser uma necessidade para a eficiência do projeto (e para que ele possa ser chamado de ágil, de fato), o ato de “encaixotar” os rituais nessas restrições de tempo, criando assim a expressão Time Box (como veremos mais adiante), se relaciona diretamente com um dos valores principais da filosofia Ágil e, por consequência, muitos de seus princípios: indivíduos e interações mais que processos e ferramentas. Pode parecer um contrassenso, uma vez que o Time Box pode ser encarado por muitos como um processo ou ferramenta. Mas na verdade ele é um conceito. E um conceito que justamente reverbera o respeito pelos indivíduos e suas interações dentro do processo de trabalho.
Time Box: controlando o tempo para não ser controlado por ele
Se já concordamos (espero que sim), lá pelo primeiro parágrafo, que o tempo é um bem cada vez mais escasso e valioso apesar do digital – e ao mesmo por causa dele –, assumir o controle do investimento do tempo é, no mínimo, emancipador. É claro que não é possível escolher no que investir todo o nosso tempo, afinal, na maioria das vezes respondemos a demandas que não estão sob nosso controle. Mas ter previsibilidade a respeito de como nosso tempo será alocado em processos relacionados ao trabalho é o mais próximo que conseguimos chegar disso atualmente.
Time Box, ou Timebox, é definido da seguinte forma no glossário da Agile Alliance, com nota minha entre colchetes:
“Timebox é um período de tempo combinado previamente durante o qual uma pessoa ou equipe trabalha continuamente [e com dedicação exclusiva, idealmente] para atingir um objetivo. Em vez de permitir que o trabalho continue até que o objetivo seja completado para então avaliar o tempo gasto, a abordagem timebox consiste em parar o trabalho quando o limite de tempo é atingido e avaliar o que foi realizado.”
O Time Box é um recurso das abordagens Agile mais tradicionais, como SCRUM e Extreme Programming. Porém, suas origens são até mais antigas, já que o conceito é descrito em trabalhos e metodologias datadas do fim da década de 1980. De qualquer forma, a regra mais importante do Time Box é que o trabalho deve parar ao final desse período que foi combinado e então passar por uma avaliação: o objetivo foi atingido, ou parcialmente atingido, no caso de múltiplas tarefas? E isso vale para todas as instâncias do processo, como vimos anteriormente na descrição das cerimônias do SCRUM, por exemplo.
Sei que sou extremamente suspeita para falar, mas só vejo vantagens nessa abordagem, conforme destaca esse post do Tmetric:
- Otimiza o tempo dedicado a cada tarefa ou reunião (adeus, reuniões de uma hora que poderiam ser resolvidas por e-mail; no máximo você gasta 15 minutos e sai de lá com a questão resolvida ou pelo menos encaminhada).
- Ajuda a manter o controle de cada “iteração” (repetição; versão) de um projeto mais longo.
- Colabora com a resolução de problemas, uma vez que podem ser alocados períodos curtos de tempo especificamente para lidar com aquela questão.
- Minimiza o tempo perdido em “tentativa e erro”, já que simplesmente não há tempo para ficar encarando uma tela em branco.
Em um artigo tão breve quanto brilhante, Johanna Rothman, autora, consultora de gestão e voz atuante na comunidade Agile, destaca outras vantagens de aplicar o conceito de Time Box no trabalho (e até mesmo fora dele, se pensarmos bem), ainda que você não seja Agile:
“Timeboxes não são novidade no agile. Elas são um velho “truque” ou dica de gestão de projetos. Se você se vir sob pressão, considere seus entregáveis. No que você pode focar agora – sem interromper-se por um curto período – para então entregar? Você encontrou o segredo: entregáveis em timeboxes curtas.”
E para concluir, reforçando mais uma vez que Time Box é um conceito e não uma ferramenta ou processo. Deixo aqui também alguns caminhos com dicas de como aplicar, além de apps e outros softwares para te ajudar a controlar seu tempo. Mas confesso: o que eu uso, e basta, é olho no relógio.
Numa próxima a gente fala mais sobre isso porque eu sou apaixonada pelo tema, mas, até por isso mesmo tenho que encerrar aqui. Respeito ao meu tempo. E ao seu. 
O post Em defesa do tempo: a importância do Time Box no trabalho com metodologias ágeis apareceu primeiro em E-Commerce Brasil.
Na próxima semana farei mais um review com depoimento e resenha sobre Em defesa do tempo: a importância do Time Box no trabalho com metodologias ágeis. Espero ter ajudado a esclarecer o que é, como usar, se funciona e se vale a pena mesmo. Se você tiver alguma dúvida ou quiser adicionar algum comentário deixe abaixo.
Nenhum comentário:
Postar um comentário