A coluna de hoje tem a informalidade de uma conversa no Gtalk, que foi de fato onde ocorreu a entrevista com Franklin Amorim, DBA (Database Administrator) da globo.com e professor da disciplina de "Metodologias Modernas de Desenvolvimento de Software" da pós-graduação em Análise e Projeto de Sistemas da Universidade Gama Filho, no Rio de Janeiro.

Mais uma vez, busquei uma solução pronta que resolvesse todos os meus problemas com o mínimo de esforço e, também mais uma vez, confirmei minhas ideias de que (1) a vida é esforço – ainda estou no início do The Lazy Project Manager, de Peter Taylor – e (2) o que me resta é produzir com minha equipe a melhor metodologia para nosso trabalho diário, tendo por base todas as metodologias que conhecemos.

Uma coisa é certa. Se somos uma equipe, temos que ter uma metodologia para a equipe. Se cada um tem sua forma de trabalhar, como, por exemplo, avaliar o trabalho de fornecedores, salvar arquivos, oferecer trabalhos para frilas, pautar capa, produzir cronogramas, vamos continuar gerenciando projetos no nível que Darci Prado chama de “boa vontade”. Isto é, não há um plano a seguir, tudo fica baseado no “achômetro”, com muitos ruídos na comunicação, e é praticamente uma sorte algum produto ficar pronto no prazo...

E por que é necessário ficar pronto no prazo? Bem, prazos são naturais para tudo. Mesmo as batatas, os poemas e os bebês têm um prazo para ficarem prontos. Os produtos que possuem uma cadeia de pessoas/empresas que os transportam desde sua criação até o consumidor final têm não apenas um prazo, mas muitos! E todos interligados (se um atrasa, atrasa toda a cadeia) e muitas vezes intransferíveis. Com o livro não seria diferente, mas, por ser um produto feito a partir do intelecto (e/ou da emoção) de diversos fornecedores, o imenso desafio é saber prever, o quanto antes, o tempo de gestação de cada livro, levando em consideração desde antes do início de sua produção as personalidades, ameaças e oportunidades congênitas de cada um.

A produção de qualquer coisa me encanta e eu fico sempre querendo saber o “making of” de cada coisa que encontro. Mas um dia percebi que, além de ser divertido saber o método de produção das coisas, isso pode ser extremamente útil para melhorar minha produção de livros. Essa é a primeira coluna investigando a produção de outras indústrias, mas certamente farei outras.

Aí vai a conversa-entrevista.

Cindy Leopoldo: Ei, Franklin, tudo bem? Vou aproveitar que hoje é domingo, dia em que ninguém quer pensar em trabalho, e lançar logo um desafio pra você. Amanhã de manhã, quando você chegar no trabalho, vai saber o que tem que fazer?

Franklin Amorim:Sim. Quando chegar no trabalho vou participar de uma reunião rápida e em pé na frente do Kanban, onde ficam todas as tarefas do sprint atual do nosso projeto. Eu vou dizer que terminei minha tarefa de sexta e vou pegar uma tarefa pra segunda.

CL:O que é sprint?

FA:Em resumo, vai ser uma reunião de status update, conhecida no Scrum como Daily Meeting. Um projeto é dividido em sprints. Ele tem duração de 2 a 4 semanas. Nos planejamos em mais detalhes para o sprint, e não para o projeto todo. O objetivo de um sprint é entregar os produtos acordados na reunião de Planning.

Funciona assim:

No começo de um projeto, o cliente escreve todas as histórias que ele quer que sejam entregues. Cada "feature" do sistema é uma história (no seu caso, uma história provavelmente seria um livro...). Então, depois que todas as histórias são escritas, fazemos uma reunião, chamada Planning, para definir o que vamos fazer no primeiro sprint. Esse Planning é dividido em duas partes.

Na primeira (Planning I), o cliente se reúne com a equipe que vai fazer o projeto e define quais as histórias mais importantes e que ele quer que sejam feitas primeiro. A equipe vai negociar e dizer quantas e quais histórias ela consegue fazer nesse primeiro sprint. Depois de fechado esse escopo, o cliente sai da reunião e o time sozinho detalha cada uma das histórias em tarefas (Planning II).

Tarefas são as ações necessárias para entregar uma história. O ideal é que as histórias sejam "quebradas" em tarefas de no máximo um dia, podendo ser menores. Depois que todas as histórias são detalhadas, podemos montar o quadro (kanban) para começar o sprint.

CL:Com os post-its?

FA:Isso. Tudo (histórias e tarefas) são escritas em post-its.

CL:Eu fico sempre com algumas dúvidas quando você me explica isso (e acredito que essa seja a oitava vez que você faz isso...), mas tem uma coisa em particular que não entra na minha cabeça: como vocês sabem o que dura um dia? Imagino que para você essa seja a pergunta mais besta do mundo, mas como você foge dos telefonemas, das interrupções todas e consegue controlar seu tempo tão bem?

FA:Bom, a gente nunca sabe. Na verdade, os métodos ágeis partem do pressuposto de que é melhor confiar mais nos nossos instintos e experiências, já que, apesar de todo o trabalho científico para tentar medir com perfeição quanto tempo se demora pra fazer alguma coisa em engenharia de software, continuamos atrasando as entregas. Isto é, se mesmo com todos os PMIs, pontos de função e gráficos de Gantt, continuamos atrasando, vamos parar de gastar tempo com isso e fazer as coisas em passos menores. Eu não sei quanto tempo exatamente vai demorar uma tarefa, mas minha experiência me ajuda a dar um chute. E, conforme vou trabalhando, eu vou ficando melhor nessa coisa de chutar. Até porque eu não tenho que chutar se meu projeto vai demorar 10 ou 15 meses, eu tenho que chutar se essa tarefa fica pronta até amanhã, e isso é muito mais fácil.

Outra coisa é o que você falou de distrações. Isso ainda pode acontecer, de fato, mas contra isso temos a figura do Scrum Master, que é responsável por evitar que isso aconteça. Ele é o protetor do time, o facilitador, aquele que resolve os impedimentos.

CL:Veja bem como é difícil transportar para a realidade do departamento editorial: nós nunca estamos fazendo um livro por vez. Estão todos acontecendo ao mesmo tempo, cada um em uma fase, às vezes um mesmo livro está em diversas fases. Não consigo me ver fazendo uma tarefa por dia...

FA:Então, acho que, no seu caso, o Scrum não faz muito sentido. Talvez o Kanban seja mais interessante. Nesse caso, você não tem histórias, só tarefas... No Kanban as coisas são bem simples. Você tem um quadro e esse quadro tem as fases pelas quais uma tarefa passa (ex.: to do, doing, done). Daí você limita quantas tarefas podem existir em uma fase. Por exemplo, 3 no "doing". E você vai puxando as tarefas do to do para o doing, mas no máximo só existirão 3 lá.

CL: Isso é por pessoa?

FA:Sim, pode ser por pessoa, mas pode ser por departamento também. Você decide.

CL: E tem que ser público? Todos têm que saber o que todos estão fazendo ou fizeram?

FA:Não, se você não quiser. Deve ser acessível para as pessoas envolvidas.

CL: Mas há uma figura como o Scrum Master que controla tudo?

FA:Então, o Kanban é MUITO mais simples que o Scrum, mas as pessoas pegam coisas do Scrum e juntam com o Kanban. Então a resposta é: depende de você. Como já te disse, o Desenvolvimento Ágil veio para resolver um problema comum na área de TI, mais especificamente na área de desenvolvimento de software, que é: sempre estamos fazendo algo que nunca fizemos antes. Pode ser parecido, mas nunca é igual. Isso é diferente do seu mundo. Fazer livro me parece uma tarefa bem controlada e com processos bem definidos. O que parece lhe interessar é como fazer isso da forma mais organizada e eficiente possível.

CL: Talvez seja como fazer prédio...

FA:Sim.

CL: Acho que eu posso ser até agredida na rua por dizer que fazer livro é como fazer prédio. Mas é. A partir do momento em que alguém entrega seu texto numa editora, cabe à editora fazer a obra com o tijolo e o cimento do autor.

FA:Sim, acho que é por aí. Você pode comparar com um monte de coisa.

CL: O fato é que é impressionante que algo tão finito como um livro tenha uma produção que pareça algo tão difícil de controlar...

FA:Qualquer processo de produção tem suas peculiaridades.

CL: Sim... O que é mais difícil de controlar no seu trabalho?

FA:Hum... Provavelmente as pessoas. Elas são bem complicadas de modo geral... :-)

CL: É, agora ficou claro por que livros atrasam tanto... São só pessoas. E cada pessoa que trabalha numa tarefa do livro entende que deve “esclarecer” a mensagem do autor de modo que ela se “transforme” na “real mensagem” que o autor quer passar para outra pessoa: o leitor. Meu Deus, se eu teorizar mais sobre meu trabalho vou começar a achar que ele é impossível de ser realizado, apesar de livros serem lançados todos os dias. Mas, de fato, são pessoas tentando esclarecer para outras milhares de pessoas a mensagem de uma pessoa. Óbvio que era uma péssima ideia, hahah...

FA:E seu processo é muito distribuído... Você não pode chegar no trabalho de manhã e ter uma reunião com toda a equipe que está cuidando do livro, porque essas pessoas trabalham em outros lugares.

CL: É, ainda tem isso, a produção remota.

FA:Acho que para melhorar, a primeira coisa que você precisa é de um bom sistema de controle de produção, um workflow, um sistema que te ajude, que te poupe trabalho. Em segundo lugar, você precisa que as pessoas entendam a importância do trabalho delas umas para as outras. Como o atraso de uma pode causar problemas para outra etc.

CL: Reuniões dão conta disso?

FA:Eu diria que reuniões são um mal necessário. Tem que tomar muito cuidado pra não desperdiçar tempo nelas. Reuniões têm que ser curtas e objetivas, e com o menor número de pessoas possível. Só devem participar de uma reunião as pessoas-chave pra discutir o assunto. Mas você conseguiria marcar reuniões com essas pessoas que trabalham remotamente?

CL: Vou te confessar: nunca tentei com afinco porque eles tendem a ser muito "temporários"... Não é fácil manter uma "fidelidade".

FA:Entendo.

CL: Isso dificulta muito qualquer controle... Talvez essa seja a terceira coisa: encontre e "fidelize" os fornecedores que mais tenham a ver com a editora.

FA:Sim.

CL: Para terminar, como era seu trabalho antes de ter uma metodologia de trabalho diário?

FA:Tinha uma metodologia. Mas era o que chamamos de Waterfall. Todas as etapas eram planejadas em detalhe antes de começarmos a escrever uma linha de código. Então já tínhamos a data de entrega de um projeto, mesmo que essa data fosse daqui a 12 meses. E tudo ficava em um grande gráfico de Gantt no MS Project. Obviamente as datas sempre atrasavam.

CL: Que coisa... Eu querendo controlar mais e mais a produção e você vem me dizer que, no seu ramo, quanto mais se tenta controlar, mais atrasado fica. Que frustrante...

:-/

FA:Sim, mas é isso mesmo. Mundos diferentes.