Eu tenho um caso de sucesso da aplicação de várias das boas práticas de gerenciamento de projetos, em um projeto que não tem nada a ver com a minha experiência e área de atuação, mas foi possível ser realizado com êxito: Um filme.

Bom, um filme é maneira de dizer, foi um mini curta metragem, se é que existe tal categoria, mas o mais importante é que deu certo e foi muito divertido.

A direção da empresa que eu trabalhava em 2008, teve uma idéia excelente para a festa de final de ano da empresa, um concurso de filmes entre as equipes da empresa, no qual o principal objetivo era promover a integração das equipes e “testar” as equipes no planejamento e execução de um projeto.

O desafio em forma de projeto foi lançado, e realmente era um desafio. As equipes precisavam montar o roteiro do filme com uma história que comportasse todos os membros da equipe, e principalmente que seguissem algumas regras fundamentais para a validade do filme, ou seja, era um filme, mas para nós era realmente um projeto que possuía requisitos bem definidos.

1. No máximo 5 minutos de duração;
2. Todos os integrantes da equipe precisavam aparecer no filme e utilizar um óculos de sol imitação do Ray-ban;
3. O tema do filme era “Tropa de Elite – O Filme”, e era precisa respeitar o tema e usar a música principal;
4. Entregar um Story Board, ou seja, um roteiro escrito, com história, diálogos, personagens entre outros detalhes;
5. E é claro, respeitar a data de início e a data de fim.

Eu sempre tive uma boa criatividade, e logo na primeira semana criei uma história e dei forma ao roteiro maluco que originou o filme de nome ETTE. Contei com a inestimável ajuda especial de um grande amigo também maluco chamado Frank Gindri, que além de comprar a minha idéia colaborou e muito com a sua criatividade estilo Tim Burton com pitadas de Stephen Spielberg (exagerado? nada, o Frank merece!)

O nome também foi uma certa maliquice, juntamos o tema “Tropa de Elite”, a nossa área de atuação na empresa que era “Energia”, ao animal preferido destacado pelo sócio majoritário da empresa (foi uma estratégia de marketing é claro) e o nome ETTE surgiu como abreviação de “Esquadrão Tubarão da Tropa de Energia”.

Como não podia ser diferente o logo da nossa tropa, e também mascote, era nada mais nada menos do que um Tubarão, como pode ser visto abaixo:

logo e mascote do ETTE

Bom, isso foi a parte criativa que depois deu origem a outros materiais promocionais e de lançamento do filme. Além de ter sido a base do nosso planejamento e a nossa linha de base de escopo.

A nossa equipe continha mais de 10 pessoas, e foi um desafio unir toda esta galera fora do horário do trabalho, e em alguns casos motivá-los e convencê-los a desembolsar grana do próprio bolso.

Neste momento apliquei da forma resumida e rústica os gerenciamentos de custo, escopo, recursos humanos e aquisições, porque tínhamos que trabalhar ao mesmo tempo mobilização da equipe, coleta de requisitos e definição do escopo, alinhamento do orçamento do projeto com os custos reais da realização de cenas que estávamos planejando realizar, e até a contratação de serviços de outras empresas para nos apoiar em algumas passagens do filme.

Além destas áreas todas que foram tratadas, trabalhamos o desenvolvimento da equipe, porque tivemos que nos auto-treinar em ferramentas de editoração de filmes e sons, porque tudo devia ser realizado por nós, neste caso a equipe envolvida com a imagem, som, edição e produção.

Outro grande desafio foi o gerenciamento da área de tempo, porque éramos muitos, e o filme só podia ser feito fora do horário de trabalho, então o cronograma foi um obstáculo a ser vencido a cada dia, principalmente porque o não cumprimento das etapas dentro do prazo, desclassificaria a equipe e o filme não seria julgado.

Principalmente devido ao tempo e a dificuldade de mobilização da equipe fora do horário comercial, então fizemos um grande gerenciamento de riscos baseado principalmente na linha de base de escopo e cronograma.

Tínhamos cenas planejadas para serem filmadas ao ar livre e em contato grande com a natureza, o que nos fez depender de condições climáticas, gerando diversos fatores de risco, e planos de resposta a estes riscos.

O filme tinha uma cena grande que passava em um rio, com equipamentos específicos e que precisávamos de uma empresa terceira para nos treinar e acompanhar durante as cenas. Não vou relevar o que foi feito no rio, para deixar a curiosidade de vocês forçar que assistam ao filme no final deste post.

Também bolamos um figurino simples composto por uma camiseta, mas era compra e se transformou em custo.

Nestes dois itens a serem comprados entrou forte a área de custo e escopo, porque tínhamos que cumprir os requisitos básicos solicitados no início do projeto ao menor custo possível.

Após todos os planejamentos terem sido realizados, partimos para a etapa de execução, filmamos horas e horas de imagens, fizemos dezenas de cenas, gravamos outras dezenas de vozes e diálogos … sem falar da parte da escolha da trilha sonora, e das narrações que nosso filme teve.

Foram centenas de horas divertidíssimas com uma equipe de analistas, programadores, DBAs, testers e um GP (eu), que durantes todas estas horas nos revezamos nos papéis de diretores, produtores, editores, cinegrafistas, câmeras, atores, dubladores, narradores, mocinhos e bandidos, que resultou em uma das experiências mais enriquecedoras da minha vida profissional.

Além do filme que era o requisito principal, fizemos uma campanha de pré-lançamento com 6 Teasers e 1 Trailer que disponibilizamos um a um em dias diferentes, antecedendo o dia oficial do lançamento. Para completar nossa campanha de marketing, nosso Movie Storyboard (Roteiro) foi entregue encadernado, nosso DVD foi adesivado, e teve uma capa como aqueles DVDs que vão para as locadoras, e a trilha sonora foi junto em CD, ou seja, foi ou não foi um projeto de sucesso digno de Holywood?

Material de divulgação do filme ETTE

Para os mais atentos será possível observar ao longo do filme, pequenas pitadas de conceitos e boas práticas de gerenciamento de projetos, além de técnicas e ferramentas. É bem sútil, mas não foi deixado de lado porque um dos objetivos era a aplicação de gerenciamento de projetos e liderança de equipe.

Foram 5 equipes, que produziram cada uma 1 filme. O nosso filme ETTE, além de ter sido entregue no prazo, seguido todos os requisitos determinados pelo cliente, ganhou o prêmio de cinema de curta metragem da empresa naquele ano. Fomos premiados também com um trófeu imitação do Oscar e um valor em dinheiro para fazermos um churrasco para toda a equipe campeã.

Este foi um sucesso de projeto que teve a participação de várias práticas de gerenciamento de projetos, mostrando que é possível gerenciar diversos tipos de projetos se boas práticas forem seguidas. É claro que se não for a nossa área de atuação principal seremos mais limitados, mas é possível vencer desafios e ganhar prêmios como foi mostrado aqui.

Gostaria de deixar o meu agradecimento a empresa Paradigma por ter proporcionado esta experiência fantástica, e a toda a minha equipe na época, que mostraram união, entrosamento, e principalmente trabalho em equipe.

Em especial deixo o meu abraço ao Frank Gindri e Gabriel Verani que foram meus companheiros de virada de madrugada para finalizarmos a edição do filme, e foram os principais co-diretores, co-produtores, co-roteiristas, dubladores e é claro, nas horas vagas, atores.

Parabéns a todos nós que fomos produtores, diretores e atores de finais de semana.

Abaixo vocês podem curtir os Teasers, Trailer e o filme ETTE completo.

ETTE – Esquadrão Tubarão da Tropa de Energia – Um curta metragem amador e independente que conta a história de Crono e Grama, duas forças que podem construir ou destruir todo o universo.

Click here to view the embedded video.

Teaser é uma palavra em inglês que significa ”aquele que provoca”, e para o marketing o Teaser é uma técnica usada para chamar a atenção para uma campanha publicitária, aumentando o interesse de um determinado público alvo a respeito da sua mensagem, por intermédio do uso de informações enigmáticas no início da campanha. (fonte Wikipedia)

Foi justamente o que fizemos no início da campanha promocional do filme ETTE, ao produzirmos e lançarmos os nossos Teasers.

Para a campanha criamos um canal no YouTube chamado ETTEONLINE, e 2 semanas antes do lançamento do filme começamos a disponibilizar pouco a pouco, e um a um, os Teasers, enviando emails ao público alvo com os links para acesso e chamadas provocativas.

Click here to view the embedded video.

Click here to view the embedded video.

Click here to view the embedded video.

Click here to view the embedded video.

Click here to view the embedded video.

Click here to view the embedded video.

Um Trailer de um filme costuma apresentar cenas escolhidas, com frases de efeito sobrepostas às cenas ou um narrador, motivando o espectador a assisti-lo. Trata-se então, também, de um Teaser. (fonte Wikipedia)

Click here to view the embedded video.

A área Scrum pode ser acessada através do menu superior deste blog, e contém páginas que resumem todos os papéis, artefatos e cerimônias que abrangem o framework Scrum. Este material fornece um resumo do framework Scrum, além de ser recheado com boas práticas das comunidades ágeis, dicas e exemplos.

Este resumo foi originado a partir da minha participação em um workshop vivenciado no gerenciamento de projetos com Scrum, e completado a partir de estudos mais aprofundados que realizei.

Atualmente continuo usando este material para a minha própria referência, no dia-a-dia em projetos ágeis. Faça você também desta área o seu material de referência, e volte sempre.

Use o menu abaixo para acessar as páginas da área exclusiva e dedicada ao Scrum.

___________________________________________________________________________
Introdução | Papéis e responsabilidades | Artefatos Scrum | Planejamento da Entrega | Sprint | Planejamento da Sprint
Estimativas | Reunião Diária | Revisão da Sprint | Retrospectiva da Sprint | Manifesto Ágil

Os títulos, certificações e curriculuns longos não podem tomar o lugar das atitudes, e as experiências vivências a partir de atitudes corretas são as mais indicadas para se tornar preparado para o mercado de trabalho real.

Ainda é fácil encontrar gerentes de projeto que se acham “deuses“, ou “super homens“, e que acreditam que podem resolver tudo sozinhos. Estes “super homens” geralmente não dão ouvidos a ninguém, inclusive aos membros da sua própria equipe, por acreditar que o único dono da verdade é ele próprio.

Estas atitudes são como bombas relógio armadas e em contagem regressiva. O gerente que acredita ter super poderes e que pode resolver tudo sozinho comete alguns erros básicos de gerenciamento que podemos listar resumidamente:

• Absorve mais tarefas do que é possível realizar, inclusive tarefas que não são de responsabilidade do gerente;
• Não delega o suficiente;
• Não confia em ninguém, nem mesmo na sua própria equipe;
• Apesar de acreditar ser um super homem, com o tempo deixará de transmitir confiança, porque fará parte do seu histórico não entregar trabalhos acordados, ou completar atividades comprometidas. Justamente porque não conseguirá dar conta de tudo sozinho;
• Não ouve ninguém, e sempre se porta como o dono absoluto da razão;
• Contribuirá para a geração de ambientes hostis, criando mais “inimigos” do que “amigos”;
• Não compartilhando, não terá com quem trocar experiências para aprender com os próprios erros e com os erros de seu time; e,
• Continua a cometer sempre os mesmos erros.

Estes são apenas alguns problemas e falhas básicas que um gerente estilo bomba relógio acumula ao longo da sua vida em projetos. Não precisam acontecer todos juntos, nem em ordem, e outros podem fazer parte desta lista. O mais importante é, que se você conseguir se enxergar em um destes itens, pode ser que sua bomba relógio já esteja armada e pronta para explodir.

Um dos erros ainda muito comuns e que de uma certa maneira acarretam outros, inclusive estes listados acima, é a falta de transparência, clareza e até honestidade dos gerentes de projeto.

Esta falha é tão básica, mas ao mesmo tempo tão grave que foi ela que deu o nome a este post, pois é o erro que serve de exemplo mais forte e mais impactante de uma bomba relógio.

Quando o gerente de projeto acredita que pode resolver tudo e que é um super homem, ele não admite que erra, e que precisa de ajuda. Ai a bomba é armada e a contagem regressiva começa, porque este tipo de GP não vai assumir que o seu projeto tem um problema, que um gatilho de um risco foi acionado, ou que até mesmo uma falha dele, ou uma falha que ele não viu irá gerar um impacto no projeto.

Quem nunca conheceu aquele gerente que todos os seus Status Reports estão verdes, e sempre que alguém pergunta sobre o projeto ele responde que está tudo bem, porém sem mais nem menos o cliente coloca a boca no trombone e ele volta dizendo: “veja bem …“.

Esta é uma das mais perigosas atitudes de um GP, porque ao pensar desta maneira, ele não levará o problema ao cliente, a sua equipe, e muito menos a sua gerência sênior interna. A maioria dos GPs super homens acredita que se ele esconder o problema por um tempo, ele conseguirá resolvê-lo sozinho e ninguém irá perceber que houve uma falha em seu projeto. Neste momento é como se um desarmador de bombas cortasse o fio errado, lembram-se dos filmes onde aparece aquela dúvida, do fio vermelho ou preto, então, neste caso não importa qual é o fio certo, o GP terá cortado o fio errado e a contagem regressiva acelerará.

A regra básica para se resolver problemas e tratá-los imediatamente, este é um dos motivos do gerenciamento de riscos. A equipe de gerenciamento tenta prever riscos e se preparar para eles, porém, é impossível prever, mitigar ou eliminar todos os riscos. Por isso eles vão aparecer em forma de problemas ou mudanças não previstas em qualquer projeto, e isso não significa falha de gerencimento e incompentência do GP.

Eu ouvi a pouco tempo do COO da empresa em que trabalho, que um gerente de projeto nunca deve ser demitido por trazer um problema a tona e pedir ajuda para resolvê-lo, mas com certeza será, se ele esconder ou não tratar o problema imaginando ou esperando que ele se resolverá sozinho.

Esta é a mais pura verdade. Não há como os problemas se resolverem sozinhos, e dificilmente um gerente de projeto conseguirá resolver todos os problemas por conta própria, mesmo porque não há motivo para isso. O GP precisa auxiliar a equipe na identificação de problemas, na monitoração destes, e se por ventura eles ocorram, o GP deve acionar os melhores profissionais para resolvê-los, e nunca esconder a sujeira embaixo do tapete.

Portanto, pense realmente como um gerente de projetos, e um coordenador de ações e equipes. Se um problema aparecer, mobilize a equipe, exponha o problema, peça opiniões, escute o que os membros da sua equipe tem a dizer, e em equipe discuta e decida a melhor solução e trace um plano de ação para mitigar ou eliminar o problema.

Em alguns casos como problemas ou falhas na gestão ou execução que possam gerar requisições de mudança, e que possam afetar o custo e o cronograma do projeto, escale o problema, leve ao conhecimento da sua gerência sênior, pois eles também fazem parte da sua equipe e podem ajudá-lo a análisar e aprovar a mudança juntamente com o cliente. A gerência sênior e seu cliente devem ser seus parceiros, e não seu concorrentes.

Com estas últimas atitudes, aquela lista de falhas são facilmente corrigidas e vários aspectos do gerenciamento vão melhorar, principalmente a confiança e a credibilidade do gerente de projeto.

Lembre-se: Escondendo os problemas embaixo do tapete, vão apenas postergar o aparecimento dos mesmos, e quanto mais se demora para resolver um problema, maior ele se torna, mais difícil será a sua resolução e maior ainda será o seu impacto.

Por isso eu fiz a analogia com a bomba relógio, pois esconder um problema é armar a sua própria bomba relógio, e se a bomba vir a explodir possivelmente os estragos serão irreversíveis, tanto no seu projeto, quanto na sua carreira.

Então, trabalhe com a sua equipe, e mesmo que a bomba relógio se arme, ou já esteja armada ai no seu projeto, chame o esquadrão anti-bomba, grite para todos a quantidade de explosivo que tem na bomba, e nunca se esqueça que o quanto antes você pedir ajuda, mais tempo sobrará para desarmar a bomba, e cortar o fio correto.

No ano passado eu publiquei aqui neste blog informações detalhadas sobre a nova versão Scrum Guide 2011 de Ken Schwaber e Jeff Sutherland, que pode ser revisitado a partir do seguinte link http://www.fabiocruz.com/2011/07/nova-versao-do-guia-scrum-2011/.

Até aquele momento só havia a versão inglês do guia disponibilizada pelos autores no site da Scrum.org.

De julho a outubro do ano passado a versão original do Scrum Guide 2011 foi enviada as equipes de tradução espalhadas pelo mundo. Várias equipes trabalharam voluntariamente na tradução dos guias para os seus respectivos idiomas nativos.

O trabalho de tradução oficial do Guia do Scrum 2011 do inglês original para o português do Brasil ficou sob minha responsabilidade, com autorização direta dos autores e supervisão de uma equipe direta da Scrum.org.

“Este guia foi traduzido da versão original em inglês, fornecido por Ken Schwaber e Jeff Sutherland. Os colaboradores desta tradução incluem Fábio Rodrigues Cruz, Rafael Sabbagh”. pag 17, Guia do Scrum 2011 versão português BR.

O meu trabalho de tradução foi revisado pelo Rafael Sabbagh da Scrum em Ação, e juntos finalizamos uma versão para aprovação da Scrum.org em novembro de 2011. Devido a alguns problemas e desencontros demoramos um pouco para liberar a versão oficial do Guia do Scrum 2011 em português Brasil, mas neste último final de semana obtivemos a publicação oficial no site da Scrum.org e a disponibilização para divulgação do guia dentro da comunidade Scrum no Brasil.

Sendo assim é com felicidade que divulgo a versão oficial do Guia do Scrum 2011 em português do Brasil, com uma grande participação minha na tradução oficial, que pode ser baixada nos seguintes links:

- Na Scrum.org, mantenedora oficial do Guia do Scrum, diretamente pelo link Scrum Guide.

- A versão PDF está disponível neste blog através do link ao lado: Scrum_Guide_2011 – Portuguese BR Version – Scrum-org

Nesta pequena série de artigos serão abordadas as possibilidades de união e aliança entre os modelos ágeis e os modelos tradicionais, sempre visando o objetivo de entregar projetos com sucesso, e para isso será mostrado exemplos e sugestões de como tirar o melhor proveito de cada uma das práticas.

Nesta edição falo especificamente dos Artefatos do Scrum unido a algumas Ferramentas, Técnicas e Documentos de comunicação do gerenciamento de projetos tradicional, visando principalmente melhorar e facilitar a comunicação geral dentro de um projeto.

Este artigo pode ser lido na íntegra na edição 43 da revista Engenharia de Software Magazine, que já está disponível no site da DevMedia. O artigo pode ser acessado diretamente clicando no link ao lado: Scrum e o gerenciamento de projetos – parte 3.

Informações sobre a revista Engenharia de Software Magazine

A Engenharia de Software Magazine (ESM) é uma revista mensal publicada pela DevMedia, e suas edições não são impressas e disponibilizadas para compra nas bancas de jornal. A ESM é uma revista digital que pode ser lida pela internet através do site da própria editora DevMedia.

Para a leitura das revistas digitais da DevMedia, como a ESM, é necessário realizar uma assinatura digital. Uma das opções é realizar uma assinatura anual e receber acesso para leitura de 12 edições por ano.

Acompanhe esta série de artigos, e vários outros ligadas à engenharia de software na ESM.

Os benefícios já são bem aceitos e sentidos na comunidade de gerenciamento de projetos, principalmente na área de tecnologia da informação, onde o ágil tem conquistado cada vez mais força. Então, não vou falar aqui das vantagens ou desvantagens do gerenciamento ágil, mas vou falar especificamente de como a cerimônia Standup Meeting pode atingir diversos tipos de projetos, e como pode ser aplicada em projetos grandes e globais.

Projetos globais são aqueles em que temos equipes espalhadas em várias localidades, incluindo outros países. Sendo que estes projetos podem dividir tanto a equipe do cliente quanto a equipe da executora. Normalmente estes projetos são grandes e envolvem alguns milhões de doláres, algumas dezenas de pessoas e vários meses de projetos. Então vou tentar ajudar a responder a pergunta de como rodar frameworks ágeis, como o Scrum, em cenários como este?

A Standup Meeting se caracteriza por ser uma reunião diária realizada com toda a equipe envolvida com o desenvolvimento da Sprint, e a sua duração deve ser de 15 minutos, onde um líder reconhecido por todos controla a reunião e dirige três perguntas básicas a todos os participantes da reunião:

1 – O que foi feito no dia anterior desde a última reunião diária?

2 – O que será feito no próximo dia até a próxima reunião diária?

3 – Existem impedimentos para a realização das tarefas planejadas?

Em projetos normais a Standup Meeting proporciona que todos os participantes se juntem em um mesmo local físico, de preferência olhando uns para os outros e de pé. Isso mesmo, de pé, justamente por isso a reunião leva o nome de Standup Meeting. Porém em projetos globais não é possível reunir toda a equipe em uma mesmo local físico, salvo raras exceções.

Então como fazer esta reunião acontecer diariamente, sem falhar as regras, sem exceder o tempo e continuando a ser um evento útil e produtivo? Bom, é ai que o gerenciamento tradicional pode nos ajudar, e principalmente a tecnologia.

Com o gerenciamento tradicional podemos planejar como a equipe irá se distribuir e se encontrar para as reuniões. Se estamos falando de projetos globais teremos pessoas espalhadas por vários cidades dentro de um mesmo país, e também em países diferentes. Em ambos os casos teremos diferenças de fuso horário, e este é o primeiro item a se considerar.

É muito importante que o gerente de projetos consulte todos os envolvidos e decida pelo melhor horário para todos, ou o que costuma acontecer, o horário que menos prejudica a todos. Por exemplo, os brasileiros podem atrasar em 1 hora o almoço e os britânicos adiar em 1 hora, note que o prejuízo foi compartilhado e provavelmente a equipe não verá isso como prejuízo, mas sim como uma alternativa para se juntarem.

O segundo ponto é o idioma, todos que se encontrarem na Standup Meeting precisam se entender, e para isso precisam falar o mesmo idioma. Na maioria dos casos vemos o inglês dominar estes cenários, mas também podemos ver o próprio português, o francês, o alemão, o espanhol e o chinês. Então a segunda missão do gerente é selecionar as pessoas que possam se comunicar em um mesmo idioma.

Por fim, precisamos das estrutura físicas e dos meios comuns de comunicação entre todos. O mais comum ainda é o telefone, porém em muitos casos ainda é o mais caro, ainda mais em ligações internacionais, e quando temos profissionais trabalhando em escritórios diferentes, andares diferentes, Home Office ou aqueles que viajam muito e estáo sempre em áreas DDD ou DDI.

Outra boa alternativa atualmente é o Skype, onde é possível realizar reuniões diretamente pela internet com todos conectados em VOIP, além do compartilhamento de telas entre computadores e de video conferência. No entanto nem sempre a internet é a melhor alternativa, ainda temos limitações de banda e problemas técnicos em algumas regiões do Brasil, que cortam as vozes durante a fala ou impedem o uso de video e voz ao mesmo tempo, ou até mesmo de voz e compartilhamento de telas simultaneamente.

Por fim, uma das melhores alternativas nos dias atuais é uma ferramenta conhecida como Readytalk. O Readytalk permite que uma pessoa presida a reunião abrindo uma conferência através de um número de telefone 0800. Este “presidente” (Chair) será o único que irá pagar a conta, que é uma espécie de assinatura mensal com créditos, limites ou outras configurações. Todos os demais participantes da reunião, ligam para o mesmo 0800, digitam uma senha enviada pelo Chair através de um agendamento de reunião via email, e entram na conferência gratuitamente.

O próprio Readytalk controla a conferência colocando todos os participantes em uma mesma sala virtual de conferência, permitindo que todos liguem de telefones convencionais fixos, de celular, ou até do Skype com créditos para ligações normais. O Readytalk também disponibiliza uma ferramenta web (www.readytalk.com), onde o Chair acessa e compartilha a tela do seu computador, ou várias telas, e os participantes usam a mesma senha do telefone para se conectar neste site da web e ver a tela compartilhada pelo Chair.

Após o gerente do projeto organizar tudo isso, disponibilizar uma ferramenta similar ao Readytalk, definir o horário das Standup Meetings, controlar os convites e a participação remota de todos, a reunião diária pode acontecer tranquilamente sem maiores interferências ou diferenças entre uma Daily Meeting convencional.

Com todos conectados no Readytalk, o Chair pode compartilhar em sua tela do computador o Taskboard e o Burndown, usar estes dois artefatos do Scrum para guiar a Standup Meeting, e fazer as três perguntas para todos os que se juntaram a reunião diária. Lembrando que todos também poderão ver a mesma tela que o Chair através da web.

Obs: Existem diversas ferramentas para montar o Taskboard e o Burndown, eu uso bastante o RTC (Rational Team Concert) da IBM, mas você pode usar qualquer outra que seja de sua preferência.

Sendo bem gerenciado e seguindo as regras do Scrum, como por exemplo, somente os desenvolvedores podem falar e com o foco de responderem apenas as três perguntas, até a duração da Standup Meeting poderá ser mantida.

Para finalizar, posso comentar sobre um projeto razoavelmente grande considerando projetos de tecnologia da informação, onde temos quase 20 desenvolvedores de mais de 5 origens de países diferentes, com a sua maioria européia. Somente em torno de 25% tem a língua inglesa como nativa, sendo que os demais falam o inglês como segunda língua, Mesmo neste cenário conseguimos realizar as Standup Meeting todos os dias, com todos os integrantes, e levando apenas 20 minutos de duração.

As reuniões são muito produtivas por serem rápidas e manterem a essência do Scrum, sendo que os benefícios são enormes, principalmente por estarmos separados. Incluindo que todos conseguem:

1 – Entender em que os demais estão trabalhando;

2 - Rapidamente conseguem identificar problemas;

3 – Rapidamente conseguem vizualizar possibilidades de ajudar uns aos outros.

Neste projeto conseguimos aplicar todas as regras, cerimônias e papéis do Scrum, mas isso é uma outra estória.

Lembrete: Como precisamos de computador e telefone, não aplicamos o “de pé” da Standup Meeting que acontece no formato presencial, mas conheço empresas que o fazem e funciona muito bem. Então vale a dica de que a melhor forma para a sua empresa, será a melhor forma para a você.

Muitas empresas ainda se perdem em seus projetos, e muitas destas se perguntam o que fazem de errado para gerar tantos problemas.

Bom, atrasos, ausência de informação, falta ou perda de equipe qualificada, descontrole de custos e outros problemas, são muito mais comuns do que imaginamos. O pior, ou quem sabe o melhor, é que grande parte destas falhas podem ser evitadas seguindo regras básicas, assim como faz um jogador de Xadrez.

Preparando o início do jogo

Bom, quem já jogou Xadrez faltando uma ou mais peças? Ou quem já jogou com dois conjuntos de peças brancas, ou apenas com peões, ou para realizar o sonho de muitos, só com rainhas? Ou a minha preferida, quem já jogou Xadrez com as peças colocadas em qualquer lugar ou ao gosto de cada jogador?

Se alguém já fez ou já viu isso, com certeza era qualquer outra coisa, menos Xadrez.

O mesmo deveria ser feito com os projetos. Um gerente de projetos quer entregar o seu projeto com sucesso, assim como um jogador de Xadrez quer ganhar o seu jogo. Então o gerente precisa seguir regras básicas antes de iniciar o seu projeto.

A equipe precisa estar montada de maneira correta de acordo com as necessidades do projeto, e estar disponível para quando for requisitada. Caso contrário erros básicos e praticamente inevitáveis ocorrerão.

Vamos usar um projeto de TI, mais especificamente de desenvolvimento de sistemas, para listar dicas simples e básicas, mas que podem evitar perdas enormes.

A – Um projeto que necessita de 3 analistas de negócio para realizar um trabalho durante 3 meses, não terá um resultado positivo com apenas 2 analistas, ou não será concluído em apenas 2 meses. Aqui eu lamento decepcionar alguns gerentes ou até membros do board diretivo, mas não adianta obrigar, ameaçar, forçar, espernear e dizer que a sua vontade é maior do que as leias da natureza. Se não é possível, não é possível.

B – Um projeto precisa de um gerente de projetos, e não adianta querer que o analista faça este trabalho part-time, ou como o projeto é pequeno deixar que o próprio programador se auto-gerencie. Isso não vai funcionar, é altíssimo o percentual de projetos fracassados devido a falta de gestão especializada e dedicada. Caso a sua empresa tenha vários projetos pequenos, tenha um gerente de projetos para realizar o gerenciamento de todos eles. Confie em mim, sairá mais barato pagar o salário do GP do que refazer todas as suas programações 3 ou 4 vezes, e arrastar um projeto de 6 meses para 2 anos. Sem contar que o seu cliente não voltará a trabalhar com a sua empresa se tais falhas ocorrerem.

Com estas duas dicas eu volto ao tabuleiro do Xadrez, onde o jogo só começa com todas as peças separadas, distribuídas e colocadas em seus respectivos lugares.

Jogando

Quem já jogou Xadrez, deve ter percebido que não é possível mover a rainha no primeiro movimento do jogo, é preciso realizar pelo menos um movimento, e na maioria das vezes o rei e a rainha são movidos apenas depois de várias rodadas, quando o jogador já colocou a sua estratégia em prática.

Nos projetos existem peças como o rei e a rainha, e fases que só devem ser realizadas após outras serem concluídas. No entanto, como nos projetos não há uma fileira de peões bloqueando todas as outras peças e obrigando que o jogador faça um movimento anterior, alguns gerentes teimam em pular etapas ou simplesmente começar pelo desenvolvimento de código diretamente.

Quem já jogou Xadrez, sabe do risco de no terceiro ou quarto movimento colocar a rainha no meio do tabuleiro e deixar ela lá, e quem já fez isso uma vez por inocência nunca mais repete o movimento porque a rainha será derrubada inevitavelmente. Então porque nos projetos alguns ainda insistem em sair desenvolvendo sem realizar etapas básicas antes da execução?

É preciso planejar, é preciso realizar trabalhos de análise de negócio e é preciso no mínimo documentar regras de negócio. Quando se executa diretamente, construindo códigos sem realizar as etapas anteriores corretamente o risco é altíssimo de retrabalho, atraso e estouro de custo. Eu ouço muitas reclamações de que o cliente muda tudo, não sabe o que quer e esquece tudo que pediu. Será? ou será que houveram conversas informais, por telefone, por email, documentos foram mal feitos, e códigos foram construídos aos montes esperando que o cliente simplesmente gostasse de tudo?

Cumpra etapas como planejamento, análise de negócio, análise de teste, análise de sistemas ou arquitetura, desenvolvimento, testes, homologação, não transforme tudo em uma coisa só e não reivente a roda.

Movimentos certos

Quem já não tentou mover uma torre na diagonal ou um bispo na vertical? Bom, quando se esta aprendendo a jogar Xadrez isso é normal, mas depois de dois ou três gritos do adversário dizendo que tal movimento não é permitido, você aprende e nunca mais move as peças de forma errada.

O mesmo deveria ocorrer com os projetos. Não se deve colocar pessoas especializadas em A para realizar B.

Ainda no exemplo de um projeto de TI, existem papéis bem definidos e essenciais para que um projeto seja executado com mais segurança e assertividade, e realmente não adianta querer colocar um testador para fazer análise de negócio, ou um analista para gerenciar. É possível que isso funciona algumas vezes por sorte, mas o risco é alto de falhas pela falta de experiência e Skills corretos para cada função.

Veja que não são muitas regras, e nem tão pouco complicadas. Esta já foi mencionada anteriormente e estou só reforçando. Defina todos os papéis e responsabilidades do projeto, e coloque cada pessoa para executar o que é destinado a ela. Não tente tapar buracos ou caçar com gatos, as chances do gato ser comido pela presa é muito alta.

Olhando para todo o tabuleiro

Um jogador de Xadrez olha para todo o tabuleiro e procura prever movimentos, tanto os próprios como os de seu adversário. Esta é uma excelente análise de risco, e que pode ser rápida e muito eficiente. Olhe para a frente, tente prever certas ocorrências fazendo exercícios básicos, como por exemplo: Se fizermos a ação A, poderá ocorrer a reação B, porém se usarmos o caminho C fugiremos do B e ainda poderemos ter uma reação positiva D.

Nos projetos há uma vantagem sobre o jogo de Xadrez, o xadrezista precisa fazer estas análises sozinho durante o jogo, já nos projetos o gerente não precisa realizar esta tarefa sozinho, pode usar parte do time ou até o time todo dependendo da situação.

Muitos gerentes, algumas vezes até pressionados pela gerência sênior, pensam que a análise e controle dos riscos é bobagem. Bom, experimente jogar Xadrez sem prever nenhum movimento sub-sequente, nem seu e nem do seu adversário. É quase certo que você irá perder peças valiosas e consequentemente o jogo. Nos projetos é exatamente isso que acontece quando os riscos são negligenciados, eles vão ocorrer e você não estará preparado para eles, e os estragos serão tão grandes quanto a importância dos riscos.

A pressa é a inimiga da perfeição

Para terminar deixei a estratégia mais famosa dos xadrezistas, a paciência para analisar todo o tabuleiro e possíveis jogadas, aliada a calma para realizar seu próprio movimento. Quem nunca perdeu uma peça importante por realizar um movimento rápido demais e não ter percebido que ao tirar um peão do adversário perderia uma rainha?

Então aqui vai a dica mais preciosa de todas, não se apresse. Cumpra as etapas como precisam ser cumpridas, planeje seu projeto seguindo boas práticas, monte sua equipe, deixe cada um executar suas tarefas, e a mais importante de todas, não arrisque executar sem planejar, o retrabalho será maior e mais caro do que fazer apenas uma vez após um bom planejamento.

Como gerente de projetos aproveite o que os xadrezistas desenvolveram ao longo de séculos vencendo jogos, e olhe para o seu projeto não como um quadrado único com apenas uma peça, olha para um tabuleiro repleto de caminhos, estratégias e peças cada uma com a sua função, qualidade e defeito.

Já tinha terminado, mas ao escrever este último paragráfo vi uma coisa muito importante e que vale a pena ser mencionado antes de encerrar.

No Xadrez todas as peças tem qualidades e defeitos, por exemplo podemos considerar que é um defeito do peão andar só para frente e apenas uma casa por vez, porém nem por isso ele é retirado do Xadrez.

Um defeito não precisa ser apenas um defeito, pode ser uma característica, e um bom gerente deve saber enxergar e trabalhar as características de cada membro do seu time, e não simplesmente descartá-lo por um “defeito”. Nenhum jogador de Xadrez joga sem seus peões, porque apesar de limitados são fundamentais para a estratégia do jogo.

Dei continuidade a série de minha autoria onde falo sobre o “Scrum e a sua relação de aliança com o gerenciamento de projetos tradicional“. Nesta pequena série de artigos serão abordadas as possibilidades de união e aliança entre os modelos ágeis e os modelos tradicionais, sempre visando o objetivo de entregar projetos com sucesso, e para isso será mostrado exemplos e sugestões de como tirar o melhor proveito de cada uma das práticas.

Neste segundo capítulo da série, falo especificamente dos Eventos ou Cerimônias do Scrum aliado e complementado por Ferramentas e Técnicas existentes no gerenciamento de projetos tradicional. Este artigo pode ser lido na íntegra na edição 43 da revista Engenharia de Software Magazine, que já está disponível no site da DevMedia.

Informações sobre a revista Engenharia de Software Magazine

A Engenharia de Software Magazine (ESM) é uma revista mensal publicada pela DevMedia, e suas edições não são impressas e disponibilizadas para compra nas bancas de jornal. A ESM é uma revista digital que pode ser lida pela internet através do site da própria editora DevMedia.

Para a leitura das revistas digitais da DevMedia, como a ESM, é necessário realizar uma assinatura digital. Uma das opções é realizar uma assinatura anual e receber acesso para leitura de 12 edições por ano.

Acompanhe esta série de artigos, e vários outros ligadas à engenharia de software na ESM.

O futebol é um esporte fácil de entender, onde o objetivo é fazer gols, e ganha o jogo quem faz mais gols. Porém, por trás de um simples jogo há uma equipe de planejamento, de gerenciamento e de apoio. E sem querer gerar polêmica, mas nem sempre ganha que faz mais gols, depende do projeto em questão, ou melhor, do campeonato.

Transformando um campeonato em um projeto, os jogos em fases, os jogadores em executores, o técnico em gerente e a comissão técnica que apoia o técnico em uma equipe de gerenciamento de projetos, vou fazer uma brincadeira para explicar como poderíamos dividir as etapas de um mesmo projeto com gerenciamento Waterfall (tradicional) e o gerenciamento ágil (Scrum), e ao mesmo tempo unindo as forças destas duas abordagens em pró do resultado positivo: “Ganhar um campeonato”, ou se você preferir, “entregar um projeto com sucesso”.

Eu gosto muito de usar o futebol como analogia para esta união, porque é um exemplo que quase todo mundo conhece, e até quem não gosta de futebol consegue imaginar o seu funcionamento e transferir os conceitos teóricos para a execução de algumas práticas.

Bom, o que leva um time de futebol a ser campeão do estadual, do Brasileirão, e de outros torneios como o sulamericano ou o mundial de clubes? Resumindo em apenas uma palavra: “Planejamento”.

A Temporada

Eu vou denominar aqui o projeto como uma temporada. Geralmente o planejamento para um temporada começa antes mesmo dela iniciar, na fase que podemos chamar de pré-temporada.

Os Campeonatos

Os campeonatos que um mesmo time disputa em uma mesmo temporada, será conhecido aqui como fases, ou waves.

Direção do Clube e Torcedores

A direção do clube será o cliente, principalmente pelo fato de que o dinheiro para investimento é liberado por eles, e o dinheiro retornado para o clube, como investimentos de pré-temporada, e retornos de pós-temporada como novos patrocínios voltam para eles direta ou indiretamente.

Já os torcedores serão as partes interessadas do projeto, pois são diretamente influenciadores e afetados pelo desempenho do time. Em algumas situações também serão os avaliadores finais que vão determinar o sucesso ou não do projeto ao final de um campeonato ou temporada.

Comissão Técnica e Jogadores

A comissão técnica é composta pelo gerente do projeto e sua equipe de apoio. Já os jogadores serão nada mais nada menos que os executores, e junto com a equipe técnica serão os principais influenciadores para o sucesso do projeto.

Waterfall

As metodologias tradicionais de gerenciamento de projetos são visualizadas facilmente nas etapas de planejamento macro, ou macro gerenciamento, que costumam envolver:

• Orçamentos e custos para a próxima temporada;
• Contratações necessárias para compor um bom elenco;
• Parcerias e patrocínios;
• Preparação de infra-estrutura para atender a necessidade do clube;
• Planejamento dos campeonatos que serão jogados e qual o objetivo à atingir em cada um;
• Planejamento e execução de Aquisições;
• Planejamento de metas de qualidade;

Em uma analogia simples. Com o apoio da metodologia tradicional é possível definir quais campeonatos o time irá jogar e qual a meta de cada um, como por exemplo ser campeão ou ficar entre os dez melhores, ou seja, a declaração de trabalho (SOW) do projeto.

Antecipções

Nesta etapa que eu gosto de chamar de macro gerenciamento, a declaração de trabalho, é complementada pelo plano de gerenciamento de projeto, que irá detalhar como o time se comportará durante a temporada e quais serão as linhas de abordagem para os treinamentos com bola, concentrações, treinos coletivos, amistosos, viagens, entre outros como fortalecimento muscular, fisioterapia preventiva e apoio psicológico.

Umas das antecipações mais importantes para um time de futebol é a formação do elenco para a próxima temporada, contratações, seleção de jogadores de base para o time principal e trocas ou empréstimos entre times podem fazer toda a diferença e podem ser a chave para o sucesso da próxima temporada.

obs: Note que isso acontece em projetos normais, onde a seleção e montagem de uma equipe influência e muito no resultado de um projeto.

Ágil

Agora vem a etapa que ajuda a deixar mais claro a separação entre o gerenciamento tradicional e o ágil, e principalmente como eles funcionam bem juntos, e como o futebol pode servir como bom exemplo para estas práticas, suas uniões e complementações.

Adaptação

Somente quando o campeonato inicia e os times começam a se enfrentar é que se torna possível montar estratégias específicas para cada jogo, principalmente porque o Time A da temporada anterior pode estar completamente diferente da temporada atual, ou até mesmo se estiver com o mesmo elenco, o comportamento pode ser outro, devido a novas formações, alterações de títulares e até o resultado de campeonatos anteriores no psicológico do time.

Isso quer dizer que não dá para na pré temporada planejar todos os jogos olhando para a tabela, além de que vários campeonatos são formados por chaves com adversários desconhecidos até a rodada anterior. Por isso além de planejar, é preciso se adaptar mais rapidamente ao que está acontecendo no campeonato, e responder mais dinamicamente as mudanças, e ser mais ágil no planejamento, no controle e na execução.

Bom, e onde o gerenciamento ágil aparece no futebol?

Fazendo uma brincadeira de comparar um jogo de futebol com uma iteração do Scrum, fica mais fácil de entender onde cada peça se encaixa.

Um jogo de futebol é como um projeto normal, ele não começa quando o juíz apita o início do primeiro tempo, ele começa antes. Já falamos sobre a pré-temporada, treinos e preparação física. Já um jogo propriamente dito começa no momento que você termina o jogo anterior e tem a definição do seu próximo adversário.

Vamos considerar um campeonato que os jogos ocorrem nos finais de semana, então nossa iteração terá a duração de 1 semana.

Preparação

A primeira ação a ser realizada na segunda feira, é reunir o time e conversar sobre o adversário do próximo domingo. Quais são as suas maiores fraquezas, forças, os craques, qual a formação ideal para jogar contra ele, além de detalhes do próprio time como condições físicas, contusões, suspensões.

Com isso é definido entre comissão técnica e jogadores, como serão os treinos da semana, que táticas ou técnicas serão mais treinadas, dias e horários para preparações específicas, ou seja, é ou não é parecido como uma reunião de planejamento da Sprint?

Execução

A partir disso o time começa a realizar treinos diários, além de trabalhos para melhorar condicionamento físico e treinos específicos que foram definidos na reunião de planejamento. Lembrando que alguns jogadores terão tarefas diferenciadas como goleiros, batedores de falta e penâlti, atacantes, defensores, além das famosas jogadas ensaiadas.

Juntamente com estes treinos diários acontecem reuniões diárias também, onde é avaliado por todos como foram os treinos do dia, o que precisa ser melhorado para o próximo treino, e se há impedimentos que antes não existiam, como contusões, brigas entre jogadores, riscos de contusões ou de falhas graves na defesa por exemplo.

Durante a semana ocorrem os planejamentos mais curtos, que podemos chamar de mais ágeis. Este planejamento envolve apenas um jogo em questão, o próximo.

Os titulares são definidos e os reservas também. Alguém já pensou o que seria dentro do gerenciamento de projetos a escalação e a existência de reservas? Pode ser parte do planejamento de uma substituição combinada, mas principalmente é o gerenciamento de riscos.

Dica: O goleiro por exemplo, raramente se planeja substituir um goleiro durante o jogo, mas sempre há pelo menos um reserva para o goleiro, porque pode haver uma contusão ou expulsão. Imagine o risco de não escalar um goleiro reserva e o títular for expulso ou se machucar? Você como técnica arriscaria aceitar um risco deste?

Super Onze - Desenho japonês onde o futebol é pura estratégia, amizade e "mágica"

O Jogo

Quando o jogo chega é que realmente fica perceptível o quanto ágil é um gerenciamento de um time de futebol durante os jogos de um campeonato.

Minutos antes do jogo acontece a famosa “Preleção”, que é uma reunião rápida onde todos relembram as principais estratégias definidas e recebem uma injeção motivacional voltada para a partida.

O jogo inicia e o time busca aplicar o que treinou, as orientações do técnico, mas também tem autonomia para colocar em prática ousadia, jogadas individuais, talentos próprios e principalmente buscar se adaptar a mudanças do time adversário e condições não previstas que não tinham como serem treinadas.

A comissão técnica, ou o gerente, definiu uma escalação que começa o jogo, porém um gol inesperado, uma expulsão ou um comportamento diferenciado do time adversário pode provocar substituições não planejadas, mas que precisam ser rapidamente pensadas, planejadas e executadas. Isso é adaptação e gerenciamento ágil, porque o técnico não pode esperar, seguir planos engessados ou marcar reuniões longas, o jogo dura apenas 90 minutos.

Intervalo de Jogo

No intervalo de jogo temos uma das reuniões mais importantes para o sucesso desta entrega que é o jogo. Podemos definir como uma reunião diária, conhecida também como uma Standup Meeting. Os jogadores e a comissão técnica discutem o que aconteceu durante o tempo anterior, e o que será feito para manter, ou reverter um resultado no próximo tempo.

Durante o intervalo também podem ser tomadas medidas para remover dificuldades, mudar a formação, realizar substituições, alterar táticas de defesa ou ataque, entre outras ações para combater riscos.

Lembrando que este período de intervalo tem apenas 15 minutos, ou seja, totalmente aderente ao Scrum por exemplo, e a sua cerimônia conhecida como reunião diária.

A Torcida

Assim como em projetos, quando os usuários finais do que está sendo construído criticam, influenciam negativamente ou pedem mudanças o tempo todo, os torcedores fazem o mesmo durante os jogos.

A torcida pode apoiar o seu time influenciando positivamente uma virada de placar, como pode empurrar o seu time para baixo com críticas, vaias ou até mesmo o não comparecimento ao estádio. Podem também pedir substituições, chamar o técnico de incompetente e pedir até a sua demissão. Isso tudo gera influência positiva ou negativa nos jogadores e comissão técnica ajudando o time a atingir o sucesso ou o fracasso.

Fim de Jogo

Com o fim de jogo, tendo um resultado positivo ou negativo, o time e a comissão técnica fazem uma retrospectiva de tudo que aconteceu durante o jogo, e trabalham justamente pontos que devem ser melhorados, mantidos por estarem dando certo e removidos por terem prejudicando o time.

Assim a iteração jogo chega ao fim e o time tem um novo adversário para a próxima semana, e a Sprint do futebol inicia novamente, da mesma maneira, com as mesmas regras, mas com certeza com micro planejamentos diferentes e estratégias definidas de acordo com o próximo adversário.

O futebol, projetos e o gerenciamento de projetos tem muita coisa em comum, e por isso pode ser um bom exemplo para se trabalhar metodologias, técnicas, práticas e analogias.

Como pode ser visto neste pequeno artigo, o gerenciamento tradicional serve de apoio para as áreas de gestão de um time que envolvem o que está envolta de um jogo, são planejamentos mais a longo prazo, mais ligados a dinheiro, a contratos de patrocínio ou parcerias e a contratações de jogadores e técnicos.

Já o gerenciamento ágil aparece muito durante os treinos e preparações para jogos específicos, e principalmente durante o jogo propriamente dito. Neste momento nada pode ser a longo prazo, a preparação para o jogo é curta, o próprio jogo é muito rápido e não há como refazer um jogo, a chance de acertar é apenas uma, entrando em ação principalmente a adaptação e a resposta rápida a mudanças.

Então é isso, espero que a partir de agora quando você assistir a um jogo de futebol você consiga visualizar as semelhanças entre o que acontece no campo entre jogadores, técnicos, torcida e adversários, com o que acontece em projetos entre equipes, gerentes, clientes e concorrentes. Este universo é muito vasto, o que eu coloquei aqui é apenas um pedaço pequeno e uma visão particular, contribua mais com este tema e publique suas impressões neste blog.

É claro, se o seu coração de torcedor deixar.

É reconhecido por praticamente todos da área, e por muitos que pretendem iniciar sua experiência profissional como gerente de projetos, que:

• Formações acadêmicas na área específica em que se pretende atuar, tais como TI ou engenharia, somam vários pontos ao curriculum;
• Certificações como a PMP, combinadas ou não com uma MBA ou pós graduação ainda são consideradas um destaque competitivo;
• Características de personalidade e competências que são especificamente consideradas favoráveis a esta área de atuação também compõem os pontos positivos; e,
• Experiências anteriores e vivências em ambientes de projetos são fundamentais para a formação de um gerente.

Porém, se me perguntarem se só isso basta, a resposta que me vem a cabeça rapidamente é que não. O mercado profissional de um modo geral está cada dia mais competitivo e feroz, e as empresas menos satisfeitas com seus profissionais anteriores, e mais exigentes em suas novas contratações.

Vou contar alguns dos desafios que estou vivendo atualmente na minha carreira, e que estão me mostrando que nunca é o suficiente e que temos que estar sempre buscando melhorar, evoluir, corrigir falhas, se aperfeiçoar e se adaptar a novos ambientes e as mudanças inevitáveis.

Este meu mais novo desafio, que posso confessar ser o maior que já enfrentei, se chama Projeto Internacional. Eu já havia passado por algumas experiências internacionais anteriores, mas nada que se compare ao que estou vivenciando agora.

Idioma

O primeiro de todos os desafios é o idioma. O caso que vou usar como base para este pequeno artigo está no seguinte cenário:

O cliente é uma grande empresa alemã com uma filial expressiva no Brasil. A empresa contratada também é uma multinacional, com equipes de várias filiais, espalhadas por diversos países, alocadas no projeto. Por isso o idioma oficial, inclusive no Brasil, é o inglês.

Todos os documentos oficiais do projeto que devem ser lidos e produzidos, todos os emails que circulam entre as equipes, todas as reuniões presenciais e virtuais (voz e video) são realizadas em inglês. No meu caso, mesmo eu já tendo vivenciado experiênciais reais com o idioma inglês, como um intercâmbio que fiz no Canadá em 2009, nada se compara a esta experiência.

Equipes virtuais

A experiência se torna ainda mais desafiadora quando combinamos o idioma as equipes virtuais que trabalham no projeto. Neste caso em especial o cliente fica em São Paulo, e as equipes de gerenciamento e execução ficam em Florianópolis (onde eu estou), Londres, Sérvia, EUA e provavelmente teremos equipes na Índia.

Os encontros e contatos não são exporádicos como alguns podem pensar. Imagine um projeto normal com toda a equipe local em um mesmo espaço físico, a frequência dos contatos é bem próximo a isso considerando as limitações de fuso horário e distância. Nossas principais ferramentas são o telefone, e a internet com video, voz e dados. Com exceção das equipes do cliente, eu sou o único brasileiro no projeto, e isso exemplifica bem uma situação de equipe virtual.

Diferenças de fuso horário

O gerenciamento muda em vários aspectos, e temos que passar a considerar as diferenças de fuso horário que afetam diretamente as agendas de toda a equipe. Sendo que esta questão é considerada um risco, e por isso gerenciada como tal e tratada como risco de médio para alto impacto.

Os sistemas de gerenciamento e mensagens, como email por exemplo, precisam estar bem configurados para não haver bagunça de fuso horário e confusões com agendas. Além de que precisamos ficar sempre atentos para a hora que estamos citando em comunicações ou até em contatos telefônicos. Por exemplo, quando marcamos algum compromisso as 9 horas, devemos citar qual o fuso horário de referência, caso contrário poderemos perder uma reunião importante por aparecermos as 9 horas do nosso fuso, sendo que a reunião ocorreu as 9 horas de Londres.

Diferenças culturais

As diferenças culturais são um dos itens que aparecem com grande força neste tipo de projeto internacional. Precisamos fazer com que a equipe trabalhe bem em grupo, e que apesar das diferenças existentes elas consigam atingir o mesmo objetivo comum. Então temos que prestar atenção em detalhes importantes da cultura de cada profissional envolvido, seja referente a religião, horários, costumes, características de alimentação, leis, família e comportamento.

Um item que destaco aqui é a pontualidade. Por diversas vezes tive experiências no Brasil com equipes que não se preocupavam muito com a pontualidade em reuniões, onde o atraso era levado na esportiva, e uma reunião marcada para as 10, começava as 10:15, 10:30 … 11:00, e em alguns casos até mais.

No caso dos canadenses, americanos e principalmente os europeus, a pontualidade é extremamente valorizada, e quando consideramos equipes virtuais esta questão se torna ainda mais importante. As situações em que várias pessoas, em diversas regiões diferentes, se conectam ao mesmo tempo por telefone ou internet se repetem ao longo de todo o projeto, praticamente todos os dias, fazendo do cumprimento dos horários um valor muito apreciado.

Orçamentos e custos

Nestes modelos de projetos normalmente haverão mais gastos com telefone e viagens, então é preciso dar uma atenção ainda mais especial ao gerenciamento financeiro do projeto. O desperdício não é bem vindo em nenhum projeto, porém neste caso desperdiçar uma viagem intercontinental pode representar uma perda bem maior do que uma corrida de taxi.

Conclusão

A experiência que se adquire em projetos internacionais é muito grande, muito valiosa e muito enriquecedora, tanto para a experiência profissional quanto para a vida pessoal.

A troca de experiências é intensa, conseguimos aprender muito com os estrangeiros e com certeza ensinar também. É muito interessante entendermos que muitas das nossas boas práticas aqui no Brasil são as mesmas que eles realizam lá fora, com algumas diferenças que podemos absorver e melhorar.

A dica que eu deixo para o final é que se for de seu interesse crescer nesta área de projetos e vivenciar experiências profissionais como esta, invista parte do seu tempo no estudo de idiomas como o inglês.

Para os profissionais competentes e bem qualificados o idioma se torna o único obstáculo para uma experiência internacional, principalmente porque o Brasil está em pé de igualdade com todos os outros países em matéria de tecnologia, boas práticas, metodologias, qualificações e educações especializadas. Por isso, com apenas algumas exceções, podemos trabalhar em projetos do mundo todo, desde que possamos nos adaptar a alguns dos pontos que mencionei neste artigo, e principalmente falar a língua oficial do projeto.

Bom, finalizando eu deixo mais um desafio, além de todos os outros que temos que vencer, para nos tornarmos bons profissionais da área de gerenciamento de projetos, nos tornarmos fluentes em pelo menos um idioma. Com certeza será um diferencial ter esta fluência, e a experiência profissional proporcionada por ela.

Dica: Como estímulo adicional, lembre-se que até para estudarmos e pesquisarmos mais profundamente alguns assuntos específicos nesta área apaixonante que é o gerenciamento de projetos, precisamos do inglês. Muitas bibliografias não possuem tradução para o português, e quando são originais de um outro idioma, como o Francês por exemplo, será mais fácil encontrar uma tradução para o inglês.

Lembre-se: Estude … and Study … et Étudiez