Ser ágil é preciso

Por Tiago Flores Dias

É sempre um desafio escrever sobre como alguém deve ou não fazer para obter sucesso em seu negócio, sobretudo quando falamos de um setor tão dinâmico como o mercado de agências digitais.

Fonte: Baguete – 27/01/2009

Tentar escrever sobre um assunto no qual existe tantas pessoas com idéias interessantes, as quais ja tiveram várias iniciativas criativas na tentativa de mapear os processos de trabalho e desenvolvimento de suas empresas, sempre gera polêmica e questionamentos que talvez eu ainda não consiga responder. Mesmo assim tomei a iniciativa de desafiar este “corredor polonês” para expor alguns conceitos que julgo interessantes, com a idéia de que sejam avaliados, mais como uma tentativa de um fórum de discussões, do que propriamente referência de alguma coisa.

Todas as agências digitais em seu processo de maturação ja experimentaram, umas mais que outras, o envolvimento com alguma metodologia e processo de gerenciamento de projetos. Por um bom tempo o PMI serviu de diferencial, quase que um selo de qualidade para algumas empresas, mesmo pouco se aplicando de seus conceitos.

A esta altura pode-se imaginar, que este seja mais um texto de critica a esta postura, podem estar certos que não é. Primeiro, porque acredito que todas elas o fizeram realmente buscando melhorar seus processos internos, otimizar custos e melhor a qualidade do trabalho desenvolvido. Segundo, porque sei bem que é inviável se aplicar um processo convencional de gerenciamento de projetos em uma agência digital. Mas então sobre o que é este texto? Algum tipo de pratica niilista que leva a lugar algum? Também afirmo que não é isto, e sim uma atitude progressiva, no intuito de buscar uma solução inovadora para o setor e para o perfil de negócio que vem crescendo absurdamente nos últimos anos.

Imaginem uma empresa de internet estruturada, com Atendimento, Planejamento, Gerenciamento de Projetos, Gerenciamento de Tecnologia, Direção de Criação, Produção de Design e Tecnologia. Imaginem neste mundo perfeito, o projeto entrando com estimativa de esforço qualificada, termo de abertura (Project Charter) identificando os responsáveis pelo projeto (stakeholders), passando por uma declaração preliminar de escopo, depois por um documento de gerenciamento de tempo, escopo, riscos, custos, qualidade, integração, comunicações, aquisições, um extenso WBS (Estrutura analítica do projeto) gerenciando os entregáveis que compõe o produto final deste projeto.

Agora… imaginem este diálogo:

tuúúúúu …. túuuuuuuu ….

Interlocutor1: – Alo?

Interlocutor2: – Alo? Tiago? E aí Mestre, Blz?

Interlocutor1: – Blz!

Interlocutor2: – Aqui é o Johny da XwZY Comunicação, blz? To te passando um briefing, super tranquiloooooo, por e-mail, me passa até meio dia o custo deste Hotsite, superrrrr fácilll.

Interlocutor1: (Neste momento, mil coisas passam pela mente humana antes do conformismo selado por um estridente )- beeeeeleeeeezaaaa!

Evidentemente, não me cabe mudar a cultura geral do mercado. Defendo a cultura de respeito e entendimento do cliente no mercado de internet, mas vivemos o dia-a-dia e é tendo em vista a realidade e não o mundo ideal, que pratico esta análise.

Não bastasse o fato de assumirmos projetos com prazos absurdos e escopos mal formatados, ainda assim, cobramos uma postura pró-ativa do recurso sem ao menos lhe dar a possibilidade de compreender o contexto do projeto no qual estão inseridos, para que eles mesmos compreendam que os custos não justificam o esforço ou demandam um esforço mais do que, o que atualmente esta sendo dispendido.

É preciso compreender as expectativas do cliente, as necessidades internas dos recursos e conciliar este universo em uma solução imediata.

Em uma metodologia convencional de gerenciamento de projetos, nos preocupamos demais com o processo e esquecemos as pessoas que executam o trabalho. As metodologias ágeis são focadas em quem executa o trabalho: seus talentos, a própria formação do time, são requisitos básicos do Scrum Agile Process, metodologia a qual pretendo focar minhas aferições.

Adaptar-se é regra, sem exceções

Não pretendo ser menos óbvio! Nós nos adaptamos ao perfil do mercado, não impomos um modus operandi, não dizemos a quem investe naquilo que fazemos, que ele deve fazer um curso intensivo de processo de produção em internet para entender a complexidade de mensurar custos e alocar recursos qualificados para executar o trabalho. O problema não está em quando aceitamos que o cliente não enxergue a complexidade de nosso trabalho, mas sim, quando nós mesmos esquecemos o quão complexo ele é.

Orçar é preciso! Leis de Mercado operam sem dar satisfação para ninguém

Não importa o quanto falte informação ou quanto risco se corra, o orçamento sempre sai, e esta para mim tem sido a parte mais divertida de trabalhar com internet. Ja peguei empresas de perfil semelhante, bem posicionadas no mercado, orçando projetos parecidos de 6.000 a 60.000, jogando dados com os custos ou desesperados para cumprir metas comercias absurdas, algumas outras reduzem o custo de ultima hora:

- Olha amigo te orcei o projeto em 25 mil, mas consegui um super desconto com a diretoria e irei fazer para ti, somente para ti, por 5.700.

Não importa o quanto isto pareça irônico, não é uma critica a postura comercial destas empresas, é a denúncia de um problema maior que é o de não enxergarmos o custo real do nosso trabalho e de não conseguirmos nos posicionar com relação as praticas absurdas do mercado. E quando não enxergamos o quanto valemos, nos igualamos àqueles que “queimam mercado” com praticas anti-profissionais.

A realidade é que em internet muitos crescem de forma desregrada. Estes criam estruturas mal planejadas e obviamente, erram nos custos dos projetos, que acabam por virar prejuízos ambulantes, como morto-vivos que ninguém ousa falar o nome.

O que precisamos entender é que, embora o orçamento tenha que sair, podemos decidir o jeito e o que ele nos obriga a fazer. Mesmo que o cliente torça o nariz no inicio, eu tenho observado, isto em uma taxa de 90% das vezes, que honestidade é melhor do que ilusão.

Uma situação que pode bem ilustrar o que digo, é quando se fala de um projeto de sistema (adoro sistema!). Imagine que o cliente quer um cadastro de clientes, mas ele precisa do orçamento para hoje! Ele sabe te dizer quais os campos, interface, qual é o banco de dados, middleware, mas não sabe te dizer, quais as regras de negócio ocultas em um sistema XPTO, que tu “deve” replicar a inclusão.

A Resposta mais direta a este problema é KISS – KEEP-IT-SIMPLE-STUPID. Orce a implementação do cadastro todo funcional em um curto espaço de execução, gere um custo, aprove e execute o trabalho. Mantenha no Scrum (Equipe do Projeto) alguém como referência para estimar o esforço deste sistema XPTO, e no próximo meeting, ja com o cadastro funcional e aprovado pelo cliente, orçe o custo do que falta.

O Cliente não consegue enxergar o esforço de entendimento do projeto, se consegue, enxerga como um problema da empresa que produz (overhead), ou seja, zona morta de custo que não pode ser cobrada, e se o que ele quer, ele mal consegue explicar, muito provavelmente ele não precisa tanto assim daquilo imediatamente, ou seja, melhor dividir para conquistar.

Não digo que não exista a possibilidade de mensurar riscos ou estimar esforços baseado em impressões, apenas não acredito que isto possa vir a ser regra, e sim exceção e deve ser dada a máxima transparência ao cliente de tudo isto.

Em um processo ágil de desenvolvimento, o trabalho preliminar é executado enquanto a parte funcional conhecida é feita. Assim, o retorno ao investimento do projeto é rápido e o cliente é livre para executar com quem ele quiser a parte que quiser do escopo.

Menos documentos e mais rigidez

Bom, supondo que consigamos resolver o problema do orçamento, como se formaliza as informações? Pilhas de documentos? Em um processo ágil se perde pouco tempo com muitos documentos. Busca-se um meio termo entre o caos da burocracia e a ausência completa de processo, contudo a documentação que existe deve ser sempre atualizada e a rigidez das informações nela contidas devem ser sempre observadas. Resumidamente: os documentos devem sempre condizer com a realidade do projeto!

O Foco aqui é na iteração entre o cliente e o produto e no constante incremento deste. Atentar para a supervisão do trabalho dos recursos e acompanhamento eficaz das atividades, visando sempre eliminar os impedimentos. Burocracia leva as empresas, a projetos com grandes custos, longos prazos, baixa qualidade e lucratividade, sem falar em pouca ou nenhuma satisfação do cliente.

Super GP!

A figura do Gerente de Projetos é vital em um processo ágil, se não for com alto grau de poder de decisão no projeto, é carta fora do baralho. O GP é o responsável pelo sucesso e fracasso do projeto, principalmente quando se trata de internet, onde tudo é e muda muito rápido.

Se ele for apenas um mandatário e não achar que a pele dele está a prêmio caso o projeto dele vá para o buraco, é um mau negócio para a agência.

Por isto, em um processo ágil, como o Scrum, ele é o Scrum Master, lider do time, decisor entre os itens que compõe o projeto e as decisões que tem de ser tomadas para que tudo aconteça.

Versatilidade e Proximidade da equipe este é o caminho!

O Processo ágil opera com times pequenos e versáteis, para que todos os requisitos do produto (product backlog) sejam resolvidos dentro da equipe. O que precisa ser resolvido fora seja feito o mais breve possível pelo Scrum Master, com a mínima intervenção do cliente.

Um analista de sistemas de um projeto, pode muito bem ser o programador de seus componentes, se não for possível, ao menos a proximidade física entre eles fará com que tudo vá mais rápido

Cutting the bullshit off!

Não faça business Bingo, dê transparência ao recurso não dê cifras, mas dê sua expectativa de custos com o projeto (Ah ! Quero gastar pouco! Tem pouca verba). Uma criação leva de 1 a X dias, depende do feeling que tu passas para o recurso e, no momento que este feeling se perde no atendimento, toda a lucratividade do projeto pode estar comprometida.

As necessidades são infinitas, mas os recursos são limitados

Não existe Cauda Longa em se tratando de recursos humanos, e sim uma limitação natural de tempo que o recurso precisa ficar alocado no projeto. A melhor forma de otimizar a ociosidade é fazendo um acompanhamento rígido das atividades que são realizadas, e com uma equipe compacta no projeto, com um perfil semelhante. Mantê-los trabalhando sempre em projetos similares otimiza o tempo de resposta e faz com que tudo aconteça mais rápido.

Acima de tudo, incentive o envolvimento de todos com o resultado e com a concepção do projeto. Chamem o carinha da TI para ajudar a criar e deixem o carinha do DESIGN dar pitaco no sistema, aprendi com um amigo, que qualquer um pode surpreender, com tudo que se pode fazer quando os outros simplesmente acreditam em ti.