Brasil Júnior

"Há muito tempo atrás, numa galáxia muito distante..." eu também trabalhei em uma empresa júnior. Eram tempos mais simples, não lidávamos com a complexidade que hoje existe ao tentarmos gerenciar um projeto. Equipes geograficamente distribuídas e a necessidade da comunicação remota, por exemplo, a gente via como algo que a tecnologia iria resolver no futuro. O fato é que não resolveu. Continuamos a lidar com as dificuldades, mesmo tendo Instant Messenger e Videoconferência. Em um projeto recente em que trabalhei, tínhamos reuniões quase diárias com o cliente utilizando esse recurso, e, ainda assim, ruídos emergiam; uma semana trabalhando in locono cliente entretanto, e voltávamos com acordos e alinhamentos que não pareciam possíveis utilizando a tecnologia. Coisas de seres humanos. Há algo na interação face-a-face, mensagens que são trocadas no âmbito das expressões corporais, que ajudam a construir confiança e parceria. Meu ponto é: não são os projetos apenas que são complexos; quem adiciona uma camada extra de complexidade e aumenta os desafios somos nós, seres humanos.

Há alguns anos conheci algo que mudaria minha percepção sobre como gerenciar a maior parte das rotinas do dia-a-dia em um projeto: Agile. O que você precisa entender é que, como muitos, eu fui educado na escola tradicional de gerenciamento de projetos. Isso significa controlar escopo, mitigar riscos e ter contingências casos eles ocorram, utilizar ferramentas para aferir a qualidade do projeto (sempre tem um quê de subjetividade do cliente), planejar aquisições e realizá-las, comunicar, realizar o gerenciamento dos "recursos humanos", controlar o cronograma, os custos, gerenciar as partes interessadas (esse último se sobressai mais recentemente) e, por fim, realizar isso tudo de forma integrada e consolidada em um Plano de Projeto. Tudo que aprendi estava certo. Não sou daqueles que critica o PMBOK (Project Management Body of Knowledge), muito pelo contrário.O que eu descobriria mais tarde que a aplicação desses conhecimentos, ferramentas e técnicas nessas áreas de conhecimento de forma irrestrita no contexto das Tecnologias da Informação e Comunicação (minha área de trabalho) não seria, necessariamente, sempre a melhor opção.

Meu ambiente era curioso: nossas metas e objetivos eram alvos-móveis, mudando de lugar todo o tempo, muitas vezes aumentando em complexidade muito rapidamente. Isso não acontecia porque não planejávamos bem; era a característica da indústria que no espaço de um ano mudava radicalmente as tecnologias utilizadas. Outra característica interessante era o acordo entre os requisitos. Esses sim nos davam confiança e certeza; certeza de que iriam mudar. Havia um sentimento entre nós de que o cliente não sabia bem o que ele queria, e mudava de opinião o tempo todo sobre as especificidades do produto. O fato que não considerávamos na época, é que o cliente sabia exatamente o que ele NÃO queria; em outras palavras, era preciso mostrar algo, obter o feedback e realizar ajustes antes de seguir em frente. Em um paradigma com um controle formal de mudanças rígido e negociação contratual, implementar essas mudanças não era muito trivial e requeria muito tato. Adicionando a essa receita pessoas, quanto mais delas houvesse, mais complexas as coisas se tornavam. O paradigma vigente era fabril, de manufatura, processo e engenharia, a coordenação era feita por gerentes em uma hierarquia piramidal de vários níveis. Em resumo, um ambiente de negócios turbulento, onde a incerteza em relação à tecnologia é normalmente alta e o desacordo em relação aos requisitos também. A isso juntemos vinte, quarenta, sessenta pessoas trabalhando em um projeto e você tem uma receita para um ambiente complexo, onde o planejamento não pode ser preditivo, sobre premissas e restrições não validadas ou com um horizonte muito longo. Uma abordagem empírica era necessária, dado o alto grau de complexidade. Eu estava falando de TIC (Tecnologia da Informação e Comunicação), mas você já viu isso antes e sabe do que estou falando, certo?

Como Agile ajuda a enfrentar esses desafios?

Gerente é importante, membros de um time com uma mentalidade de gestão é mais importante.

Uma gestão ágil de projetos começa com um princípio fundamental: somos todos responsáveis pela gestão. Algo deu errado? Não tem gerente para assumir a responsabilidade junto ao cliente, a gente faz isso. Algo deu muito certo? Não tem gerente para colher os louros junto ao cliente, a gente faz isso. O Jurgen Appelo (1), em seu livro Management 3.0, já avisa que gestão é importante demais para estar nas mãos de uma só pessoa. Como assim? E o Gerente, onde é que fica? De acordo com Gary Convis (2), President da Toyota Motor Manufacturing Kentucky, o papel de gerentes em um ambiente de trabalho saudável e bem sucedido é “modelar a organização não através de força de vontade ou ditando o que deve ser feito, mas através do exemplo, do coaching e da compreensão, ajudando outros a atingirem suas metas.” O esforço é do time, e se alguém do time consegue oferecer serviços de gerenciamento de projetos, mas ainda assim ser um membro da equipe, vai funcionar melhor. Eu sei, eu sei, é polêmico, mas experimente antes de desconsiderar. Você ficaria surpreso em quanto os membros de uma equipe podem se desenvolver em um curto espaço de tempo sem alguém dando ordens ou assumindo compromissos em nome dos mesmos. O Gary está certo: gerentes tem que ser menos gerentes, afinal você gerencia rotinas, materiais, inventários, e precisam ser mais líderes, pois pessoas você não gerencia, você lidera; e isso é feito com exemplo, coaching (adiciono aqui o mentoring também) e a compreensão. Títulos e cargos aqui, são irrelevantes.

Somos poucos. Times pequenos conseguem alcançar o sucesso e agilidade de forma mais efetiva.

Quanto mais gente na iniciativa, mais ela vai requerer esforços de coordenação, e mais chance haverá de ruídos na comunicação. Equipes de cinco a dez pessoas, trabalhando no mesmo local simplificam a comunicação e garantem que todos estão na mesma página. Esse intervalo não é cabalístico, poderia ser de seis a onze, por exemplo. Tenha em mente, no entanto que, quanto mais gente, maiores suas chances de não ser efetivo. Uma observação: se você tem um número maior de pessoas, considere a alternativa de criar mais times e investir tempo na coordenação e comunicação entre eles.

Trabalhamos com auto-organização.

Equipes auto-organizáveis não nascem assim; elas precisam ser construídas com as ideias mencionadas no item um. No entanto, um bom começo é entender a regra de ouro da auto-organização: a equipe tem total liberdade de modificar seus processos de trabalho. Em outras palavras, para ser mais claro: ninguém pode dizer à equipe COMO fazer seu trabalho, ela vai descobrir sozinha. Líderes ajudarão provendo direção e alinhando as restrições organizacionais junto ao time, dizendo O QUÊ, mas o mesmo tem autonomia sobre sua forma de trabalho. Se algo não está funcionando, podemos mudar a forma de fazer até encontrarmos algo que funcione a contento. Alguns podem perguntar: e quanto às regras organizacionais? Requisitos regulatórios e normas tem o seu papel e deverão ser cumpridas, o que o time deve perguntar sempre é: existe uma forma melhor de fazermos isso e ainda assim cumprirmos as regras? Ou mesmo questionar as regras. Você ficaria surpreso quanta coisa muda quando você começa a perguntar "Por que isso é feito assim?". Muitas regras estão lá e já nem valem mais, só que ninguém se incomodou em questioná-las.

Trabalhamos com transparência, inspeção e adaptação.

Esses vieram diretamente do Scrum (3), um dos frameworksmais populares entre os adeptos de Agile. Transparência significa que temos a coragem de falar a verdade, que as informações sobre o nosso progresso estão disponíveis às pessoas que necessitam acesso, sem maquiagens ou camuflagem. Se estamos indo bem, está visível. Se estamos indo mal, também. Transparência requer que o cliente trabalhe próximo da equipe e acompanhe o desenvolvimento de seu produto, mas acima de tudo que o cliente confie na equipe. Deixe eu repetir de novo, pois isso é muito importante: mas acima de tudo que o cliente confie na equipe. Essa confiança desde já é merecida por que somos profissionais, não trabalhamos para prejudicar o cliente mas para ajudá-lo a alcançar seus objetivos. Nessa jornada, percalços ocorrerão, mas acima de tudo é preciso que o cliente confie na equipe. Acredite quanto nós dissermos que não vai dar pra fazer tudo aquilo que você está pedindo nesse prazo, e não tente nos forçar a que nos comprometamos com algo que não acreditamos. Por outro lado, pode ter certeza de que se terminarmos mais cedo, vamos procurar você para pedir mais serviço, afinal nosso progresso é transparente para você.

Já a inspeção e a adaptação, nos ajudam a gerenciar a complexidade que mencionei no início desse texto. Planejamos sobre um horizonte curto (até no máximo um mês, mas eu gosto de duas semanas), mas planejamos sobre coisas que estão logo à nossa frente e cujo grau de certeza é maior. Não sei o que vai acontecer nos próximos três meses, mas duas semanas, ah... duas semas a gente consegue controlar. Ao término desse período a gente pára, inspeciona o que foi feito, reflete sobre o que funcionou bem, e sobre o que gostaríamos de fazer diferente e, adapta o que estamos construído para as próximas duas semanas, com mudanças no produto e/ou no processo de produção. Ambos nos ajudam a reduzir a complexidade, planejando sobre fatos e experiências exitosas ou não.

Somos comprometidos com a excelência e entregas parciais e incrementais para que vocês possam ver ou experimentar o que está sendo feito.

Essa não é uma arena para gente que não está a fim de contribuir. Os membros do time assumem responsabilidade por seus resultados e ajudam seus colegas a vencerem seus medos, inibições e a desenvolverem novas capacidades que são fortalecidas pelo espírito de equipe. Sozinho é mais difícil, mas sabemos que podemos pedir ajuda toda vez que estivermos com um grande obstáculo à frente. A magia acontece quando você percebe que, aquilo que era muito difícil para um, pode ser vencido pelo pensamento e criatividade coletivos, algo que normalmente é limitado quando concentramos as decisões em uma autoridade central de planejamento, se conseguirmos construir um ambiente onde nossas virtudes são conhecidas, mas também nossas vulnerabilidades. Mais uma vez o papel do líder ou líderes na construção de um ambiente harmonioso onde equipes possam triunfar. Patrick Lencioni (4) fala sobre como a falta de confiança, o medo do conflito, a falta de compromisso, evitar assumir responsabilidades e prestar contas (accountability) e a falta de atenção a resultados interferem nos bons resultados de uma equipe e oferece algumas ideias para que o líder aja nesses contextos agindo primeiro ou tomando a frente, procurando pelos conflitos, forçando clareza e encerramento, confrontando as questões difíceis e orientando o foco para resultados coletivos, respectivamente.
Algumas certezas: você verá uma versão utilizável do seu produto logo, logo. Vai poder oferecer feedback e influenciar a construção, mas respeite o que está sendo feito no intervalo de tempo proposto. Tente fazer com que as coisas fiquem estáveis por pelo menos duas semanas, você consegue. A segunda certeza é a de que o que você está recebendo é feito com excelência. Times ágeis não entregam produtos com baixa qualidade, pois eles assinam e assumem a responsabilidade pelo produto que estão desenvolvendo. Trata-se de um grau de compromisso muito superior ao relacionamento contratual entre duas organizações.

Agile mata lobisomem?

A bala de prata é um instrumento interessante, pois você precisa de uma para matar um lobisomem. Fred Brooks (5), autor da engenharia de software, no entanto, ficou conhecido pela frase "No silver bullet" onde não existe essa bala de prata que resolverá todos os problemas e eliminará o mal que temos em nossos projetos. Agile não é a bala de prata. No entanto, nos traz uma melhor qualidade de problemas. Brooks acredita no desenvolvimento de software por incrementos, onde uma parte é feita, analisamos seus resultados e voltamos a construir novamente um novo incremento, que corrige vulnerabilidades do anterior e adiciona funcionalidades que não existiam antes. Sei que uma empresa junior não entrega, necessariamente, software em seus projetos, mas o poder de construir algo aos poucos, comprometendo o cliente e melhorando a entrega a cada ciclo, é tangível, e sem dúvida, parte das rotinas de vocês.

Existem alguns cuidados a serem tomadas na implementação. O primeiro deles é: não faça sozinho. Procure ajuda, de um coach, ou alguém que realmente conheça os métodos e já tenha tido boas experiências em sua implementação. Esse apoio vai evitar erros que são danosos para as equipes, mas que poderiam ser facilmente evitados se você pudesse contar com um olhar mais experiente. Se isso não for possível, estude. Faça um curso sobre Agile, leia livros (o PMI - Project Management Institute(6) mantém uma lista de referência para a certificação sobre agilidade), leia blogs, e demais posts. O segundo cuidado é: não é porque você escolheu desenvolver um time e cultivar uma mentalidade ágil que a sua organização, como mágica, também tomou essa decisão. Espere problemas relacionados à cultura organizacional, política e procedimentos organizacionais que vão desafiar sua atitude resoluta. Enfrente esses desafios com bom humor, informação, e acima de tudo, resultados. Pequenas mudanças, gerarão resultados tangíveis em um curto período de tempo. Use-as para disseminar o conhecimento na sua organização. O terceiro e último cuidado é: não dá pra mudar fazendo do mesmo jeito. Esse poderia ser uma definição clássica da loucura. Entenda os papéis (o Scrum Guide é um bom começo) e respeite o frameworkaté que entenda o potencial dos eventos, artefatos e papéis. Com o tempo, e à medida que você e seu time amadurecerem, lembre-se da inspeção e adaptação e vá adicionando ou removendo componentes de sua rotina buscando sempre manter-se melhorando a qualidade, a motivação e a produtividade da sua equipe.

Por fim, Agile está por aí a mais ou menos 20 anos. Muita coisa está diferente do que aprendi no início de minha educação, e as coisas continuam sendo mudadas e refinadas de forma interativa. Todo ano temos novas distinções, ferramentas e práticas, mas defendo que o alicerce é mindset (mentalidade). Tem mais a ver com atitude, postura, maturidade do que frameworks, técnicas e post-it colados em quadros com colunas. No meu dia-a-dia, faço uso tanto de ideias que aprendi com os métodos ditos "tradicionais" quanto Agile. Penso nisso como duas caixas de ferramentas que carrego comigo e faço uso ora de forma separada, ora em conjunto. Mensagem a reter: esse tipo de mentalidade já está em uso em grandes empresas no âmbito mundial, por exemplo.Startups incubadas ou não, utilizam os princípios de Lean para terem sucesso. Enquanto meus clientes lá fora já entenderam, em muitos lugares aqui é como se eu pedisse para as pessoas acreditarem, que tivessem fé no que estou dizendo. Tem uma forma nova e diferente de fazer as coisas, e isso não é novidade. Ele resolve problemas antigos e traz consigo uma nova gama de problemas, mas uma MELHOR qualidade de problemas. Afinal não é isso que queremos? Acredite em ambientes de trabalho mais felizes e motivadores. A mudança com você, começa na sua mentalidade, que precisa se tornar mais ágil.

Obrigado pela leitura e sucesso em seus projetos!

REFERÊNCIAS:

Management 3.0, Jurgen Appelo. http://www.management30.com
Gary Convis, President da Toyota Motor Manufacturing Kentucky em “Role of Management in a Lean Manufacturing Environment”, em “Learning to think Lean”, agosto 2001, SAE International, http://www.sae.org/topics/leanjul01.htm.
Scrum Guide, Ken Schwaber e Jeff Sutherland. http://www.scrumguides.org
The five dysfunctions of a team, Patrick Lencioni
Brooks, Fred P. (1986). "No Silver Bullet — Essence and Accident in Software Engineering". Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.

Realização: GPjr – Gerenciamento de Projetos para Empresas Juniores

www.gpjr.com.br / www.facebook.com/gpjr10

O GPjr é um projeto que tem o objetivo levar a conhecimentos dos empresários juniores do Brasil as boas práticas em gerenciamento de projetos contidas no Guia de Conhecimento em Gerenciamento de Projeto (PMBOK®) que é a referência bibliográfica em GP (gerenciamento de projetos) mais difundida no mundo.

Escrito por: Ricardo Peters - Gerente de Projetos da CESAR - Centro de Estudos e Sistemas Avançados do Recife
https://br.linkedin.com/in/petersricardo
http://about.me/ricardo.peters