Sobre Gerentes de Projeto, Líderes Técnicos e Design

05 Mar 2014

 

O Que Eu Fiz nas Férias

Para evitar o clichê de começar com um post dando oi para o mundo e prometendo blogar frequentemente, optei por começar com algo mais útil e algo que eu aprendi a fazer na escola: Uma redação sobre as minhas férias.

Esse ano começou estranho, eu passei 3 semanas trabalhando no escritório da ThoughtWorks no Equador, seguido de 3 semanas de férias e isso gerou uma sensação que tudo que aconteceu até agora foi no vácuo que existe entre 2013 e 2014, mas é claro que não. O ano já andou, e eu aprendi e relembrei muitas coisas que vale a pena compartilhar.

O Arquiteto, o Gerente e o Elefante

Na minha estada no Equador, me pediram para fazer o papel de gerente em um projeto que já estava rodando quando eu comecei. Eu não gosto de ter o papel de gerente de projeto. É algo que não acho que faça bem e que não me permite fazer as coisas que realmente gosto, mas as vezes é bom sair da zona de conforto e era o que precisava ser feito, então abracei a tarefa e tentei fazer o melhor que pude.

Por outro lado, por não estar lá no começo do projeto, tinha uma visão apenas parcial do que havia acontecido até a minha chegada. Se por um lado é saudável estar ciente disso, por outro eu sempre estava com a impressão que havia algo faltando no projeto. A líder técnica que estava no projeto desde o início tinha esse contexto, mas estava sobrecarregada com obrigações tanto no projeto quanto fora dele, e assim a gente acabava só falando o absolutamente essencial.

Eu assumi que esse "algo faltando" era algo que aconteceu antes da minha chegada, mas na verdade era algo mais básico que isso. Apesar de termos objetivos bem definidos para o projeto, todas as conversas pareciam truncadas. O elefante na sala era uma tensão que eu nunca havia percebido, mas que é importante e saudável. O gerente de projetos tem uma responsabilidade principal: garantir que o projeto é entregue no prazo. O líder técnico tem uma responsabilidade principal: garantir a qualidade da arquitetura e do código. Muitas vezes esses objetivos são incompatíveis e o gerente e o líder técnico tem que conversar e entender o que importa no contexto em que estão. Talvez essa seja a decisão mais importante do projeto. Uma vez que tivemos a conversa, as nuvens clarearam e tudo ficou fácil.

Qualidade Clássica e Romântica

Nas minhas férias eu reli um dos "livros da minha vida": Zen e a Arte da Manutenção de Motocicletas. No livro o autor, Robert Pirsig, debate o que, de acordo com ele, é um dos "grandes temas da humanidade" nos anos 70, a aparente dicotomia entre a Arte e Ciência. Os "bacanas" desprezavam a ciência como algo "feio" e os "nerds" tomavam quem não apreciava a ciência por "burros".

Pirsig argumenta que os dois extremos estão unidos pela Qualidade - seja clássica (ciência) ou romântica (arte) - que não pode ser explicada por nenhum dos dois campos e que, na verdade "gera" ambos. Ele explica isso muito melhor que eu, é claro. Mas o que eu achei interessante em relação às ideias mais modernas no mundo da agilidade é que ele argumenta que qualidade é algo que não pode ser medido: "É só olhar que você vê!", e prevê a unificação dos dois campos.

Isso me lembrou muito as ideias mais modernas de design, que sugerem que a única medida de sucesso é o feedback do usuário - quando o usuário olha, ele vê se tem ou não tem Qualidade. O melhor design que vemos hoje é quando essas ideias são implementadas e realmente parece uma intersecção entre arte e ciência. Lendo o livro quase 40 anos depois que ele foi escrito, parece engraçado o quanto ele se adere a conceitos que não só seriam formalizados 15 anos atrás e popularizados muito depois.

E de certa forma me faz pensar que o que estamos fazendo faz sentido.