A produtividade da equipe de desenvolvimento

Você é programador e no seu trabalho é você quem atende o cliente no telefone para discutir regras de negócio. Recebe e-mail dos usuários pedindo suporte e ainda visita clientes com frequencia, onde você, com o seu notebook, faz programação “in-loco”. Além disso, diversos usuários vão até você para tirar dúvidas e reclamar sobre a dificuldade de utilizar o sistema.

Dos 30 clientes que a empresa possui, você tem absoluta certeza de que pelo menos 20 deles possuem versões diferentes do mesmo sistema. Quando não é versão diferente de executável é versão diferente de banco de dados.

Já aconteceu de um dia resolver um bug de um cliente e na próxima atualização descobrirem que a correção de um cliente gerou problema em outro que não tinha nada a ver com o que foi feito no passado.

Além de você, a empresa possui outros 17 programadores, divididos em células de trabalho que atendem produtos específicos mas pode-se observar que o problema acima acontece com todos os produtos da empresa.

Com tantos programadores, o sócio-diretor não entende porque a empresa leva tanto tempo para liberar uma nova versão ou corrigir um bug no sistema e então resolve que todo mundo deve começar a preencher uma planilha contendo a data e hora de início e fim de cada atividade que faz, a fim de ter certeza de que os funcionários não estão desperdiçando tempo com Google, Orkut e Messenger e tornar mais evidente aquilo que estão fazendo.

Após muita revolta, todos os funcionários passam a preencher esta tal planilha, ainda que com dados fictícios ou com pouca ou nenhuma fidelidade, o que mostra ao dono do empreendimento que a estratégia não funcionou.

Após conversar com alguns amigos diretores de grandes empresas e com a ajuda de uma consultoria externa, decide que é hora de implantar o CMMI para padronizar as rotinas de trabalho e também um sistema moderno de gerenciamento de helpdesk, baseado no ITIL, com medição de SLA (qualidade de serviço) etc.

Duas semanas de visitas dos consultores externos para disseminar o CMMI e ITIL e no mês seguinte entra em vigor o novo método de trabalho.

O que será que deu errado?

É o diretor quem pergunta, furioso e decepcionado por ter investido milhares de reais em siglas super modernas e ver a qualidade da sua equipe, que parecia ruim, piorar de vez.

Entenda o que poderia ter sido feito diferente.

1. Não faça microgerenciamento de funcionários

O gerenciamento do tempo é indispensável para oferecer previsão nos projetos, mas cuidado.

Estou cansado de ver empresas que não conseguem (ou não querem) alocar um gestor capacitado a coordenar toda a área de desenvolvimento, definindo quem fará o quê e quando e monitorando entregas para saber se estão ou não no prazo. Em vez disso, se limitam a delegar (ou delargar) a responsabilidade de gerente para o próprio funcionário, fazendo com que o funcionário (e não o gerente) seja o responsável por preencher planilhas com o que está fazendo, quando fez, quanto tempo durou, porque fez assim, onde mexeu, etc etc.

Sob o ponto de vista do funcionário, isto soa como microgerenciamento. Segundo o autor Mc Gregor (Teoria Comportamental do X e Y), esta técnica não deve ser empregada em atividades que requeiram criatividade, como desenvolvimento de software, pois causa desconfiança e um sentimento ruim de trabalho monitorado com controles rígidos.

Encontre um bom gestor. Se não quiser buscá-lo no mercado, desenvolva um plano em conjunto com o colaborador que tenha maior vocação para administração e gestão. Não cometa o erro de promover uma pessoa absolutamente técnica para gerente somente pelo tempo de casa, pois ao invés de gerenciar ela vai querer programar, que é o que no fundo ele gosta de fazer, pois será péssimo para a sua empresa/projeto.

2. Siglas como CMMI, ITIL e PMI não vão resolver o problema

Revistas, jornais e a internet não param de falar em siglas que melhoram produtividade, dão consistência e melhoram o controle sob os processos de desenvolvimento. Mas não cometa o erro de achar que somente a sigla vai causar uma revolução na sua empresa ou departamento.

Todas as siglas trazem sugestões de trabalho excelentes mas que nem sempre precisam ser seguidas à risca. Evite pescar algumas siglas, buscar consultores externos para implantação e achar que vai tudo ser resolvido do dia para a noite.

É a mentalidade dos colaboradores que precisa mudar e isso não vai acontecer do dia para a noite, portanto…

3. Quando for implantar uma metodologia ou modelo de trabalho, faça gradativamente

Jamais implante um modelo de trabalho do dia para a noite. Já vi caso em que a empresa fechou numa sexta-feira sem nenhum controle e quis iniciar segunda-feira com o modelo proposto pelo PMI 100% funcionando.

Não é porque você contratou um excelente gerente de projetos, com anos de experiência em diversas empresas e setores, que a implantação das práticas propostas pelo PMBOK vai acontecer do dia para a noite.

A melhor forma para permitir que a mentalidade dos colaboradores acompanhe as mudanças que serão introduzidas com as novas metodologias é fazer com que sua implantação seja feita por partes.

Inicialmente converse com a equipe. Deixe claro que mudanças vão acontecer e determine um prazo viável para concretizar a implantação do modelo de trabalho.

Esqueça a ideia de que será em semanas ou poucos meses. Trabalhe com prazos médios e, dependendo da mentalidade dos seus funcionários, seja realista. O prazo para a mudança será longo, mas ela deve acontecer, ainda que gradualmente.

O segundo passo é começar a documentar, mas ainda sem métricas ou processos muito rígidos e detalhados. Cobre documentos e exija que sejam utilizados, depois siga para a próxima etapa e assim sucessivamente, até que quando você menos esperar a produtividade da equipe estará em níveis excelentes.

Uma sugestão é segmentar ainda mais este processo implantando inicialmente somente em uma equipe ou em um projeto e depois estenda a toda a empresa. Utilize as pessoas que participaram da implantação como disseminadores de conhecimento e vendedores da ideia e de que o modelo dá certo.

Não deixe de sempre medir o resultado do trabalho, mas…

4. Não use os resultados das métricas como arma para criticar os seus colaboradores

Um erro muito comum é verificar que as métricas não estão indo bem e convocar reunião para aterrorizar os colaboradores cobrando melhoras imediatas.

Métricas ruins em geral são sinais de que o modelo implantado não está de acordo com o nível de maturidade da empresa. Reavalie imediatamente o que está sendo cobrado e verifique se os colaboradores sabem exatamente como funciona o processo e se a qualidade e o nível das documentações que estão sendo geradas estão de acordo com o esperado pela equipe de desenvolvimento.

Não deixe de verificar o nível de envolvimento da equipe com o projeto e principalmente a motivação do gestor da área.

Utilize o resultado das métricas para descobrir onde estão as falhas no processo e corrija-as imediatamente.

5. Participe com toda a equipe da implantação

Não faça reuniões fechadas apenas com os líderes para saber como está a implantação. Em geral, se existir algum problema e eles não se sentirem plenamente seguros em relação as mudanças, eles tentarão acobertar por medo de saber qual será a reação da empresa.

Convoque todo o batalhão de colaboradores para discutir e deixe claro que o objetivo não é criticar o erro mas sim detectar falhas que possam ser aprimoradas para que o projeto de melhoria contínua possa seguir adiante e jamais desista no primeiro obstáculo.

fonte: Webinsider de Renato Ucha

Faça parte deste artigo compartilhando comigo experiências de implantação de metodologias e modelos de trabalho enviando e-mail para falecom@renatoucha.com.br.

Comunicação versus documentação em projetos

Todos os que se interessam por gerenciamento de projetos já ouviram que entre 80 e 90% do tempo de um gerente de projetos é gasto em comunicação.

O PMBOK em sua 4ª edição (versão 2008) afirma, na página 338 (versão em português) que: “A comunicação foi identificada como a maior razão de sucesso ou fracasso de um projeto”.

Apesar disso, dentro da gigantesca bibliografia de gerenciamento de projetos, é extremamente difícil encontrar bons livros falando sobre o assunto. Confirmei isso recentemente, ao iniciar a orientação de uma aluna em seu TCC de Pós Graduação em Gestão de Projetos. Mesmo o PMBOK, depois de afirmar a sua importância através da frase citada acima, dedica apenas 21 de suas 336 páginas ao gerenciamento da comunicação – e vale ressaltar que isso significa um avanço em relação à versão 2003, que dedicava apenas 14 páginas…

O grande problema que percebi em várias metodologias de desenvolvimento / gerenciamento com as quais trabalhei é que se confunde documentação com comunicação.

Documentação é importante sim – para que todos saibam o que está acontecendo, para nivelar informações e para sinalizar o acompanhamento do projeto.

Dentro da área de conhecimento de gerenciamento da comunicação, o PMBOK em sua 4ª Edição (2008) define cinco processos:

1. Identificar partes Interessadas

2. Planejar as comunicações

3. Reportar o desempenho

4. Gerenciar as expectativas das partes interessadas

5. Distribuir Informações

Em minha experiência de projetos, gerenciando e sendo gerenciado, pude perceber que os processos que recebem maior atenção são reportar o desempenho e distribuir informações, muito provavelmente porque esses elementos são, basicamente, processos de documentação.

Ouvi certa vez de um superintendente, em reunião para gerentes de projeto, a seguinte frase: se falharmos na documentação do que ocorreu durante o projeto, ficamos sem defesa, nas mãos do cliente…

Realmente isso é verdade, se não está documentado, não temos defesa, mas… precisamos mesmo nos defender sempre?

Para mim essa metodologia devia se chamar COASS (Cover Our ASS!).

Essa frase parece afirmar que o projeto terá problemas, que o cliente ficará insatisfeito e que precisamos nos resguardar. Fiquei com vontade de perguntar (mas não o fiz, eu um raro momento de lucidez):

- Não seria melhor evitar a insatisfação do cliente? Gerenciar suas expectativas, para que no final, pelo menos na maioria dos projetos, não ser necessária uma defesa?

Não estou dizendo que a documentação não é importante, apenas que existem outros processos tão (ou mais) importantes que a documentação.

O grande problema é que documentar é fácil (chato e trabalhoso, mas fácil). Basta ser metódico e organizado, atualizar um cronograma, escrever um report e disponibilizá-lo, fazer atas de reunião… Não existe um segredo para isso, um bom template e algumas explicações e qualquer gerente flanelinha consegue realizar.

Já o processo “gerenciar as expectativas das partes interessadas” é muito mais complicado. Afinal, é preciso primeiro saber quem são as partes interessadas e quais são suas expectativas. E também se são viáveis e estão dentro do escopo do projeto.

Note que o verbo empregado é gerenciar e não atender e muito menos superar.

Gerenciar expectativas exige uma atitude muito difícil. É preciso se relacionar com a parte interessada, é preciso saber negociar, influenciar e, raras vezes, impor limites.

E se, e sempre tem um “e se…”, com tudo isso, o cliente ainda tiver uma expectativa inviável, seja em termos de prazo, em termos de custo ou de escopo?

Infelizmente essa situação é mais comum do que o desejado. O gerente de projetos é alocado pela organização executora, que vendeu a um cliente um projeto inviável, ou o cliente solicitou um produto e na verdade deseja outro…

Esse é um caso clássico de conflito de expectativas. É exatamente nesse contexto que o gerenciamento das expectativas é fundamental. As partes precisam saber que as expectativas são incompatíveis – é preciso negociar, tentar influenciar ou até mesmo impor limites.

Claro que tudo isso precisa ser documentado, mas se as expectativas forem gerenciadas, a documentação pode sim funcionar como defesa. Mas pelo menos nenhuma das partes interessadas poderá dizer que foi uma surpresa.

É mais complicado que simplesmente documentar? Sim, muito mais complicado. Talvez por isso gerentes de projeto ganham mais que documentadores.

Fonte: [Webinsider]

O mercado de TI no Rio de Janeiro

Eu sou o retrato vivo da notícia abaixo, que achei no iMasters. Fui do Rio para Brasília e retornei. Concordo que o mercado está aquecido e acho salutar que se mantenha assim.

Aqui no Rio de Janeiro sempre nos vangloriamos da mão de obra formada pelo setor de informática. Contando com universidades de primeira linha num perímetro relativamente reduzido, além de empresas que absorvem recém-formados com uma velocidade incrível proporcionando complemento na formação com experiência de mercado profissional, o Rio sempre foi referencia nacional.

Infelizmente, passamos por alguns anos de completa degradação da economia fluminense, foram anos de descaso, e isso acarretou numa fuga muito grande de empresas do Rio para outros locais do Brasil, especialmente para São Paulo. Esse movimento não ficou restrito a área empresarial, teve reflexos no mercado de mão de obra, vimos diversos profissionais valorosos do Rio de Janeiro procurando oportunidades em outros estados - é comum encontrar grande comunidades cariocas em São Paulo. A escassez de mão de obra no Rio era conseqüência de diversos fatores entre eles está a imigração profissional.

Hoje o cenário mudou um pouco, a economia do Rio dá sinais de recuperação muito por conta da indústria de petróleo, que movimenta toda a cadeia produtiva da cidade e do estado, a autoestima voltou também e, com ela, o Rio conquistou ser sede dos Jogos Militares, da Copa e das Olimpíadas, para falar apenas dos eventos mais conhecidos. Isso tudo mexeu no equilíbrio de forças dentro do mercado de TI, as empresas estão crescendo, empreendendo e inovando mais do que nunca, a mão de obra formada pelas universidades e escolas técnicas do Rio está sendo retida e aproveitada na região, e já é possível perceber um movimento de "repatriamento" de empresas e profissionais cariocas que estão voltando.

Os eventos de TI também estão acontecendo novamente e tomando vulto na cidade: o Interact aporta no Rio em julho, o Rio Info terá sua maior edição em agosto, e, além disso, pela primeira vez, será realizada uma edição fora do Rio - o Rio Info Porto. O evento no Porto, em Portugal, é uma conseqüência do alto interesse das empresas européias em conhecer a capacidade e qualificação dos brasileiros. Serão seminários, rodadas de negócios e encontros empresariais envolvendo não apenas brasileiros e portugueses, mas participantes de toda a Europa. Depois do Rock in Rio Lisboa é a vez do Rio Info Porto.

Parabéns Rio por voltar a ocupar o espaço que sempre foi seu não só no cenário nacional como internacionalmente.

Fonte: Alberto Blois do iMasters