Hoje é a palestra que irei dar ao público aqui em Porto Alegre entitulada: "SCRUM IN HELL - Uma abordagem prática da aplicação do SCRUM em ambientes difíceis". O nome é mesmo para instigar :)
Irei conceituar o que eu chamo de ambientes difíceis (micro e pequenas empresas e, no meu caso, grupo de pesquisa universitário) e depois apresentarei o que eu fiz para iniciar a implantação do SCRUM no ambiente de trabalho. Não será uma palestra que fala sobre a metodologia do SCRUM, mas sim uma visão de como ela pode nos ajudar no dia-a-dia.
Espero que consiga passar a mensagem para o público e que pelo menos alguns, se animem a tentar mudar em suas empresas :)
Depois conto como foi.
---------------------------
Essa é a semana decisiva do projeto Agritec. Semana passada os guris acabaram queimando um pequeno circuito da placa, que já foi trocado (felizmente não foi nada grave). Essa semana faremos os testes e depois prepararemos a apresentação que será feita na outra segunda-feira.
Tomara que tudo corra nos conformes...
segunda-feira, 30 de junho de 2008
sexta-feira, 27 de junho de 2008
Correria... e o blog desatualizado
Desculpem, pessoal. Sei que o blog tem bastante gente que acompanha diariamente. Mas estou na correria aqui para finalizar o nosso projeto, tenho provas e ainda a apresentação de segunda-feira :)
O projeto é que tá tomando mais tempo. Quando tu parecia ir bem, a equipe acabou queimando acidentalmente um componente importante do hardware. Faltando uma semana para a apresentação do mesmo (deadline MESMO).
Corda no pescoço... mas vamos tirar de letra (espero!).
Abraços!
O projeto é que tá tomando mais tempo. Quando tu parecia ir bem, a equipe acabou queimando acidentalmente um componente importante do hardware. Faltando uma semana para a apresentação do mesmo (deadline MESMO).
Corda no pescoço... mas vamos tirar de letra (espero!).
Abraços!
quarta-feira, 25 de junho de 2008
Evento de Metodos Ágeis em Porto Alegre - 30/06
No próximo dia 30/06 (segunda-feira) o Grupo de Usuários de Metodos Ágeis do RS (GUMA) estará promovendo um encontro com os interessados em conhecer um pouco mais sobre SCRUM, XP, e outros métodos.
Eu farei a segunda palestra, sobre "SCRUM IN HELL - uma abordagem prática da aplicação da metodologia ágil em ambientes difíceis", um nome bem-humorado para mostrar algumas dificuldades que passei na tentativa de implantação da metodologia no meu trabalho.
Fica o convite para quem quiser assistir, trocar algumas idéias e conversar. Você, de Porto Alegre e região, não deixe de ir.
Mais informações no site: http://www.rs.sucesu.org.br/inscricao/guma_30-06
Horário: 18h30min
Local: Auditório 517 da Faculdade de Informática da PUCRS (prédio 32)
Eu farei a segunda palestra, sobre "SCRUM IN HELL - uma abordagem prática da aplicação da metodologia ágil em ambientes difíceis", um nome bem-humorado para mostrar algumas dificuldades que passei na tentativa de implantação da metodologia no meu trabalho.
Fica o convite para quem quiser assistir, trocar algumas idéias e conversar. Você, de Porto Alegre e região, não deixe de ir.
Mais informações no site: http://www.rs.sucesu.org.br/inscricao/guma_30-06
Data: 30 de junho de 2008
Horário: 18h30min
Local: Auditório 517 da Faculdade de Informática da PUCRS (prédio 32)
segunda-feira, 23 de junho de 2008
Implantando o SCRUM a conta-gotas.
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Não existe dúvida que a implantação de qualquer metodologia (ou prática ou padrão) requer um pré-requisito principal para funcionar: o apoio da direção.
De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.
Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.
Observação importante: essa é a minha opinião :)
Vamos lá
1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.
2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.
3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.
4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).
5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.
E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.
Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)
São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!
Abraços
Não existe dúvida que a implantação de qualquer metodologia (ou prática ou padrão) requer um pré-requisito principal para funcionar: o apoio da direção.
De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.
Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.
Observação importante: essa é a minha opinião :)
Vamos lá
1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.
2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.
3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.
4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).
5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.
E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.
Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)
São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!
Abraços
sexta-feira, 20 de junho de 2008
Auto-crítica
Se vocês tiverem oportunidade, procurem o livro intitulado "Aprendendo a lidar com pessoas difíceis" dos autores Rick Brinkman e Rick Kirschner. Eu pude ver um vídeo deles, há tempos atrás (uma fita de videocassete!!) em que eles abordavam os perfis de pessoas. Eu tenho que dizer que eles realmente foram ótimos nos perfis que fizeram!
Vou citar um, para exemplificar:
Eu vou fazer uma auto-crítica. Eu vi muito de mim nessa descrição. Eu sou um pouco desorganizado ainda (não sou extremamente!), tenho um perfil para lidar com pessoas (realmente gosto disso) e normalmente sou uma pessoa que se preocupa em aceitar as coisas com um "sim"... e realmente isso pode trazer problemas, de vez em quando. Normalmente faço isso com os meus chefes e algumas poucas vezes com os clientes (com eles eu me sinto mais disposto a negociar melhor).
Talvez o grande problema disso seja o fato de inconscientemente eu ter uma certa necessidade de gratidão com os meus chefes, por eles terem me dado a oportunidade de me tornar o gerente do grupo. Então costumo aceitar até mesmo algumas coisas que depois eu me pergunto: "por que diabos estou aceitando isso?".
Eu percebi isso fortemente em uma reunião. Estávamos discutindo um destes "projetos-demanda" que surgem para última hora. Ao final da exposição do que era, o chefe me olhou com aquela cara de "e ai?" e eu falei: "Certo... vamos cumprir sim".
Nesse momento, um dos desenvolvedores pediu a palavra e falou "Olha eu acho que a coisa não é tão simples assim, hein". E explicou a visão dele. Nesse momento eu vi que realmente eu disse um "sim" sem avaliar com cautela algumas nuances.
O chefe que será o meu chefe direto neste próximo projeto (o do email...) é daqueles extremamente pragmáticos. Se tu for conversar com ele e quiser contextualizar uma situação, ele já fica impaciente e pede para ir ao ponto. Essa ansiedade exarcebada dele é algo que intimida um pouco, não no sentido de "medo". Mas intimida ao debate... pois se tem a noção de que ele não vai ouvir e que a posição dele será mantida.
Talvez se eu me acostumar e me adaptar melhor a esse estilo dele, eu consiga dizer "sim" apenas depois de ter certeza disso. Aliás, pretendo me policiar desde já com relação a isso.
Enfim, me identifiquei um pouco com esse perfil de pessoa... e percebi como as vezes posso estar sendo inconsequente comigo e com minha equipe. Fica uma auto-crítica minha. Para tentar me lembrar que eu preciso mudar isso, o quanto antes.
Abraços
Vou citar um, para exemplificar:
A PESSOA "SIM"
As pessoas que só dizem "sim" são extremamente desorganizadas e freqüentemente se sobrecarregam na tentativa de conduzir a vida de acordo com os desejos das outras pessoas. Elas tem um direcionamento para lidar com pessoas e não com tarefas. E, as vezes, não sabem o que fazer para cumprir as suas promessas, nem pensam nas consequencias daquilo que se comprometeram a fazer.
Eu vou fazer uma auto-crítica. Eu vi muito de mim nessa descrição. Eu sou um pouco desorganizado ainda (não sou extremamente!), tenho um perfil para lidar com pessoas (realmente gosto disso) e normalmente sou uma pessoa que se preocupa em aceitar as coisas com um "sim"... e realmente isso pode trazer problemas, de vez em quando. Normalmente faço isso com os meus chefes e algumas poucas vezes com os clientes (com eles eu me sinto mais disposto a negociar melhor).
Talvez o grande problema disso seja o fato de inconscientemente eu ter uma certa necessidade de gratidão com os meus chefes, por eles terem me dado a oportunidade de me tornar o gerente do grupo. Então costumo aceitar até mesmo algumas coisas que depois eu me pergunto: "por que diabos estou aceitando isso?".
Eu percebi isso fortemente em uma reunião. Estávamos discutindo um destes "projetos-demanda" que surgem para última hora. Ao final da exposição do que era, o chefe me olhou com aquela cara de "e ai?" e eu falei: "Certo... vamos cumprir sim".
Nesse momento, um dos desenvolvedores pediu a palavra e falou "Olha eu acho que a coisa não é tão simples assim, hein". E explicou a visão dele. Nesse momento eu vi que realmente eu disse um "sim" sem avaliar com cautela algumas nuances.
O chefe que será o meu chefe direto neste próximo projeto (o do email...) é daqueles extremamente pragmáticos. Se tu for conversar com ele e quiser contextualizar uma situação, ele já fica impaciente e pede para ir ao ponto. Essa ansiedade exarcebada dele é algo que intimida um pouco, não no sentido de "medo". Mas intimida ao debate... pois se tem a noção de que ele não vai ouvir e que a posição dele será mantida.
Talvez se eu me acostumar e me adaptar melhor a esse estilo dele, eu consiga dizer "sim" apenas depois de ter certeza disso. Aliás, pretendo me policiar desde já com relação a isso.
Enfim, me identifiquei um pouco com esse perfil de pessoa... e percebi como as vezes posso estar sendo inconsequente comigo e com minha equipe. Fica uma auto-crítica minha. Para tentar me lembrar que eu preciso mudar isso, o quanto antes.
Abraços
quinta-feira, 19 de junho de 2008
Água fria nas idéias... pelo menos por enquanto.
É impressionante o mundo corporativo (seja uma empresa, seja um grupo de pesquisa). Cheguei no trabalho com a idéia que mencionei no post anterior, de tentar criar o conceito de gestão por competências.
Conversando com o meu colega, contei a história da Nissan para expressar a essência deste conceito. Ele achou bacana. Mas nesse momento, fomos interrompidos por um dos meus chefes.
Ele me disse que eles todos estavam em reunião e tiveram algumas decisões:
+ Eles querem equipes bem centradas e experientes, e com isso pode haver uma reformulação total na equipe do laboratório. Pior do que isso, dependendo do que eles entendem por "experientes" podemos ter um acréscimo que não foi previsto na folha de pagamento.
+ Eles simplesmente definiram que um dos meus subordinados atuais faria o papel de gerente de projetos de hardware e analista de processos, nas empresas. OPA! Peraí!! Como é? Eles escolheram a pessoa mais introvertida, entre os que estão ali. Um cara muito técnico com bons conhecimentos, só que não tem na comunicação o seu forte. E querem que ele vire GERENTE? E pior, que ele visite empresas e identifique processos?! Isso me soou de uma insanidade que só demonstra como os responsáveis por essas decisões não conhecem a equipe que tem.
+ O meu colega, analista e que faria a função de gerente, foi nomeado como analista de processos da empresa. Obviamente, ele foi o último a saber. Avisaram ele hoje, sem saber se ele tinha interesse ou não. Pela reação dele, no momento e depois da reunião, notei que ele estava meio puto da cara. Pois sabe que está se metendo numa encrenca daquelas... ele sabe que vai ter que acompanhar o tiroteio da empresa, que ao invés de se focar em uma tecnologia para se especializar e oferecer serviços, está tentando pegar tudo o que pode (projetos espaciais, de RFID, de software, de sistemas embarcados, etc).
+ Eu fui mantido de gerente de projetos do grupo de pesquisa. Aqui foi a notícia boa. Eu pretendo, posteriormente, alcançar posições mais altas (obviamente não será no grupo e nem na empresa que tem uma hierarquia pequena e monolítica), mas nem por isso vou pular degraus. Quero gerenciar mais alguns projetos (este principalmente, que terá um apelo bem interessante) para acumular experiência e me preparar para os novos desafios.
Enfim, novamente houve uma mistura enorme entre empresa e grupo de pesquisa. Eu vou exigir, antes de começar o projeto, que os papéis e responsabilidades estejam BEM DEFINIDOS. Isso significa que não haverá possibilidade de alguém que tem o foco só no grupo, tenha que prestar algum serviço para a empresa. Vou ser bem incisivo nisso. Se eu vou realmente ser do grupo, vou representar o GRUPO e não a empresa.
Apesar dessa reunião ter demonstrado algumas decisões que eu não concordo (como a saida do meu colega contra a vontade dele - aparentemente - para a empresa e a nomeação do gerente de projetos de hardware de uma pessoa sem o perfil) eu ainda acho que consigo transformar o laboratório em um local para a gestão de competências. A proposta só sofreu um adiamento... mas eu não vou desistir, pois acho que o conceito é o que nós realmente precisamos. Só vou precisar vender a idéia para os meus chefes.
Enfim... o alinhamento estratégico é inexistente ou está misturado. O que pode acontecer?
Conversando com o meu colega, contei a história da Nissan para expressar a essência deste conceito. Ele achou bacana. Mas nesse momento, fomos interrompidos por um dos meus chefes.
Ele me disse que eles todos estavam em reunião e tiveram algumas decisões:
+ Eles querem equipes bem centradas e experientes, e com isso pode haver uma reformulação total na equipe do laboratório. Pior do que isso, dependendo do que eles entendem por "experientes" podemos ter um acréscimo que não foi previsto na folha de pagamento.
+ Eles simplesmente definiram que um dos meus subordinados atuais faria o papel de gerente de projetos de hardware e analista de processos, nas empresas. OPA! Peraí!! Como é? Eles escolheram a pessoa mais introvertida, entre os que estão ali. Um cara muito técnico com bons conhecimentos, só que não tem na comunicação o seu forte. E querem que ele vire GERENTE? E pior, que ele visite empresas e identifique processos?! Isso me soou de uma insanidade que só demonstra como os responsáveis por essas decisões não conhecem a equipe que tem.
+ O meu colega, analista e que faria a função de gerente, foi nomeado como analista de processos da empresa. Obviamente, ele foi o último a saber. Avisaram ele hoje, sem saber se ele tinha interesse ou não. Pela reação dele, no momento e depois da reunião, notei que ele estava meio puto da cara. Pois sabe que está se metendo numa encrenca daquelas... ele sabe que vai ter que acompanhar o tiroteio da empresa, que ao invés de se focar em uma tecnologia para se especializar e oferecer serviços, está tentando pegar tudo o que pode (projetos espaciais, de RFID, de software, de sistemas embarcados, etc).
+ Eu fui mantido de gerente de projetos do grupo de pesquisa. Aqui foi a notícia boa. Eu pretendo, posteriormente, alcançar posições mais altas (obviamente não será no grupo e nem na empresa que tem uma hierarquia pequena e monolítica), mas nem por isso vou pular degraus. Quero gerenciar mais alguns projetos (este principalmente, que terá um apelo bem interessante) para acumular experiência e me preparar para os novos desafios.
Enfim, novamente houve uma mistura enorme entre empresa e grupo de pesquisa. Eu vou exigir, antes de começar o projeto, que os papéis e responsabilidades estejam BEM DEFINIDOS. Isso significa que não haverá possibilidade de alguém que tem o foco só no grupo, tenha que prestar algum serviço para a empresa. Vou ser bem incisivo nisso. Se eu vou realmente ser do grupo, vou representar o GRUPO e não a empresa.
Apesar dessa reunião ter demonstrado algumas decisões que eu não concordo (como a saida do meu colega contra a vontade dele - aparentemente - para a empresa e a nomeação do gerente de projetos de hardware de uma pessoa sem o perfil) eu ainda acho que consigo transformar o laboratório em um local para a gestão de competências. A proposta só sofreu um adiamento... mas eu não vou desistir, pois acho que o conceito é o que nós realmente precisamos. Só vou precisar vender a idéia para os meus chefes.
Enfim... o alinhamento estratégico é inexistente ou está misturado. O que pode acontecer?
Gestão por competências ... um conceito bem aderente ao agile!
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Estou tendo no meu MBA a disciplina de "Gestão de Competências". Estou achando um assunto sensacional! Tudo porque ele é extremamente aderente ao que o agile pressupõe para uma gestão efetiva de projetos, pessoas e objetivos.
Basicamente, o que pressupõe a gestão de competências? A competência de uma pessoa pode ser mensurada com três conceitos indissociáveis, o chamado CHA sendo:
C = Conhecimento (know-how)
H = Habilidade (saber fazer, utilizar o conhecimento para obter resultados)
A = Atitude (pró-atividade, entusiasmo, paixão)
Essas três características são de duas distintas naturezas chamadas de natureza técnica (CH) e natureza cognitiva (A). Podemos facilmente visualizar que a principal carência do mercado atual reside nas natureza cognitivas. Existem muitas pessoas com conhecimento e/ou habilidade... e muitas delas sem atitude para realizar suas tarefas ou, como se diz muito por aí, vestir a camisa da empresa.
As empresas estão percebendo isso. E muitas estão começando a vislumbrar no conceito da gestão de competências, que o maior ativo de qualquer empresa são as pessoas (e eu acrescentaria, o conhecimento - principalmente no mundo da tecnologia). Logo, como criar um ambiente onde o CHA aflore de uma maneira que permaneça na empresa por muito tempo?
A gestão de competências possui três pré-requisitos básicos, como proposta para criar essa cultura:
1 - A capacidade dos gestões e líderes traduzirem a visão de futuro da empresa em um propósito estratégico desafiante e motivador.
Isso parece fácil, mas existe uma nuance muito, mas muito importante a ser considerada: é preciso saber responder a pergunta, que muitos funcionários farão, que é: "o que eu ganho com isso?". Logo, é preciso fazer com que o propósito tenha um objetivo claro e desafiador para todos na empresa... para que todos tenham a real noção do que ganharão atingindo os resultados. E isso só se consegue obtendo um bom feedback de todos os níveis da empresa.
Mas o que seria um propósito estratégico? Basicamente é a tradução da visão de futuro da empresa. Lembram daquela famosa frase "Nossa visão"? Pois bem, ela nunca foi tão importante agora. Mas não é apenas isso. Existem três conceitos que precisam existir nesse propósito: é preciso ter claramente um PRAZO para ser atingido. É preciso ter um SLOGAN que seduza a todos - e que seja fácil de lembrar. E é importante ter uma espécie de PLACAR ELETRÔNICO dos macro-objetivos para saber se estamos atingindo ou não.
(Aqui abro um parênteses. Esses três conceitos não são a cara do agile?)
Um dos exemplos mais clássicos que existe é o caso da empresa japonesa Nissan. Atolada em dívidas, ela foi comprada no início dos anos 2000 pela Renault. Um brasileiro chamado Carlos Ghosn assumiu a presidência e recebeu a missão de reerguer a empresa. Após meses de estudo sobre todos os setores, áreas e níveis da empresa, foi criado em conjunto o famoso slogan da empresa: NISSAN 180.
Além da fácil associação do 180 com a idéia de "dar uma guinada 180 graus" estes três números possuem três objetivos estratéticos da empresa. A missão deles era de, em cinco anos:
1 = Atingir a marca de 1 milhão de carros produzidos e vendidos
8 = Atingir a marca de 8% de rentabilidade ao ano
0 = Atingir o feito de zerar a dívida (que estava na faixa de 15 bilhões de dolares)
Logicamente uma mudança cultural e estrutural ocorreu na empresa. Muitos foram demitidos, estratégias foram tomadas. O Carlos se tornou uma daquelas pessoas que os japoneses (sabidamente nacionalistas) passaram a ver com desconfiança. Mas o fato é que da previsão de atingir o resultado em 5 anos, eles conseguiram fazer isso em TRÊS anos. A empresa saiu do buraco e o Carlos hoje é celebridade no país... apesar de ter assumido a presidência da Renault.
Enfim, notem como foi importantíssimo a criação de um slogan, um prazo e um placar eletrônico (eles desenvolveram isso não só visualmente - com um placar mesmo - como com a utilização de BSC). Se vocês tiverem interesse, procurem a respeito deste case na internet. É sensacional.
2 - O segundo pré-requisito para a criação de uma gestão de competências é a capacidade de estruturar um mapa de competências organizacional. E é aqui onde são identificadas as carências, as necessidades, o como agir e com base nele é feito o plano para atuar.
Não vou detalhar muito isso, mas acredito que se possa encontrar um template deste mapa na internet. A identificação das competências necessárias podem ser observadas pelo próprio slogan (que é o ideal). Por exemplo o caso da NISSAN 180.
Se o "1" indica produzir e vender carros, podemos ver que é preciso ter os melhores operários e processos para construção, e os melhores vendedores para vender os carros (e aqui entra vendas, marketing, alinhamento com o mercado, etc). No caso do "8" de rentabilidade de 8%, podemos visualizar que deve-se ter a certeza de que todos da empresa estejam alfabetizados com conceitos de contabilidade. E por fim, o "0" de zerar a dívida, indica que todos precisam estar cientes de como atuar para reduzir os custos da empresa.
Portanto aí podemos evidenciar diversas necessidades que precisam ser atacadas. Facilmente identificadas pelo slogan da empresa.
3 - O terceiro pré-requisito, e o mais complicado deles, é a capacidade de despertar e manter a postura de ATITUDE COLETIVA na empresa.
Esse sem dúvida é o mais crítico deles. E aqui podemos ver como é importante alinhar os objetivos (a visão) da empresa em algo que beneficie a todos. Se o objetivo representa uma necessidade pessoal do presidente da empresa ou de um pequeno grupo, isso será facilmente percebido pelos demais em pouco tempo. E a atitude coletiva vai cair drasticamente.
Um exemplo bem interessante foi discutido na aula. A AmBev criou um slogan chamado "AMBEV MAIS (A+)". A empresa tinha como meta "tornar-se em 5 anos a empresa de bebidas mais competitiva da face da Terra". Um objetivo bem desafiador. Quem não gostaria de fazer parte de algo grandioso? Ainda assim, muitos perguntaram: "O que eu ganho com isso?". Então foi dito que aqueles que liderassem suas equipes de uma forma a atingir os resultados, ganhariam uma bolada de 14 salários. Foi uma festa! Mas, com o tempo, foi visto que a coisa não era bem assim. A idéia da empresa era estimular a competitividade entre o nível tático. E isso seria medido em um ranking... onde só 60% deles receberiam essa premiação. As nuances existiam, portanto. Ainda assim, porém, a pergunta de "o que eu ganho" estava respondida.
Um detalhe curioso: o dono da AmBev tinha um objetivo maior com isso. Ele queria mesmo era figurar entre os 100 mais ricos do mundo, na Forbes, e poder voltar a morar na Europa. Logicamente se ele dissesse isso na empresa jamais teria o apoio que teve. Já imaginaram uma atitude coletiva para atingir um objetivo destes?
---------------
Essa é a essência da gestão de competências: criar uma atitude coletiva na empresa para atingir uma visão de futuro. O entendimento de que isso só será possível com a correta gestão de pessoas é importantíssimo, pois são estas pessoas que irão empurrar a roda para que o objetivo maior seja atingido.
Eu escutava isso durante a aula e não podia deixar de fazer analogia com o agile. Afinal, ambos os conceitos vão de encontro pois tem o foco na valorização das pessoas e equipes para atingir um resultado.
Pretendo, na medida do possível, aplicar este conceito no meu trabalho. Será uma tarefa difícil, mas eu vejo isso como um norte que eu precisava. Eu já possuia alguns objetivos que pretendia que fossem atingidos tais como transformar o laboratório de pesquisa em referência dentro da universidade. Visualizei na gestão de competências o conceito ideal para aplicar isso com uma mecânica certa e bem definida.
Portanto, meus amigos, se tudo der certo eu começarei a divulgar aqui no blog todo o que tenho feito para implantar e trabalhar com este conceito no meu trabalho. E vamos ver que resultados eu irei atingir. Espero que seja uma nova fonte de lições aprendidas para todos nós.
Se você gosta de agile, tenho certeza que quando procurar na internet um pouco sobre gestão por competências, vai se apaixonar mais ainda. :)
Um abraço
Estou tendo no meu MBA a disciplina de "Gestão de Competências". Estou achando um assunto sensacional! Tudo porque ele é extremamente aderente ao que o agile pressupõe para uma gestão efetiva de projetos, pessoas e objetivos.
Basicamente, o que pressupõe a gestão de competências? A competência de uma pessoa pode ser mensurada com três conceitos indissociáveis, o chamado CHA sendo:
C = Conhecimento (know-how)
H = Habilidade (saber fazer, utilizar o conhecimento para obter resultados)
A = Atitude (pró-atividade, entusiasmo, paixão)
Essas três características são de duas distintas naturezas chamadas de natureza técnica (CH) e natureza cognitiva (A). Podemos facilmente visualizar que a principal carência do mercado atual reside nas natureza cognitivas. Existem muitas pessoas com conhecimento e/ou habilidade... e muitas delas sem atitude para realizar suas tarefas ou, como se diz muito por aí, vestir a camisa da empresa.
As empresas estão percebendo isso. E muitas estão começando a vislumbrar no conceito da gestão de competências, que o maior ativo de qualquer empresa são as pessoas (e eu acrescentaria, o conhecimento - principalmente no mundo da tecnologia). Logo, como criar um ambiente onde o CHA aflore de uma maneira que permaneça na empresa por muito tempo?
A gestão de competências possui três pré-requisitos básicos, como proposta para criar essa cultura:
1 - A capacidade dos gestões e líderes traduzirem a visão de futuro da empresa em um propósito estratégico desafiante e motivador.
Isso parece fácil, mas existe uma nuance muito, mas muito importante a ser considerada: é preciso saber responder a pergunta, que muitos funcionários farão, que é: "o que eu ganho com isso?". Logo, é preciso fazer com que o propósito tenha um objetivo claro e desafiador para todos na empresa... para que todos tenham a real noção do que ganharão atingindo os resultados. E isso só se consegue obtendo um bom feedback de todos os níveis da empresa.
Mas o que seria um propósito estratégico? Basicamente é a tradução da visão de futuro da empresa. Lembram daquela famosa frase "Nossa visão"? Pois bem, ela nunca foi tão importante agora. Mas não é apenas isso. Existem três conceitos que precisam existir nesse propósito: é preciso ter claramente um PRAZO para ser atingido. É preciso ter um SLOGAN que seduza a todos - e que seja fácil de lembrar. E é importante ter uma espécie de PLACAR ELETRÔNICO dos macro-objetivos para saber se estamos atingindo ou não.
(Aqui abro um parênteses. Esses três conceitos não são a cara do agile?)
Um dos exemplos mais clássicos que existe é o caso da empresa japonesa Nissan. Atolada em dívidas, ela foi comprada no início dos anos 2000 pela Renault. Um brasileiro chamado Carlos Ghosn assumiu a presidência e recebeu a missão de reerguer a empresa. Após meses de estudo sobre todos os setores, áreas e níveis da empresa, foi criado em conjunto o famoso slogan da empresa: NISSAN 180.
Além da fácil associação do 180 com a idéia de "dar uma guinada 180 graus" estes três números possuem três objetivos estratéticos da empresa. A missão deles era de, em cinco anos:
1 = Atingir a marca de 1 milhão de carros produzidos e vendidos
8 = Atingir a marca de 8% de rentabilidade ao ano
0 = Atingir o feito de zerar a dívida (que estava na faixa de 15 bilhões de dolares)
Logicamente uma mudança cultural e estrutural ocorreu na empresa. Muitos foram demitidos, estratégias foram tomadas. O Carlos se tornou uma daquelas pessoas que os japoneses (sabidamente nacionalistas) passaram a ver com desconfiança. Mas o fato é que da previsão de atingir o resultado em 5 anos, eles conseguiram fazer isso em TRÊS anos. A empresa saiu do buraco e o Carlos hoje é celebridade no país... apesar de ter assumido a presidência da Renault.
Enfim, notem como foi importantíssimo a criação de um slogan, um prazo e um placar eletrônico (eles desenvolveram isso não só visualmente - com um placar mesmo - como com a utilização de BSC). Se vocês tiverem interesse, procurem a respeito deste case na internet. É sensacional.
2 - O segundo pré-requisito para a criação de uma gestão de competências é a capacidade de estruturar um mapa de competências organizacional. E é aqui onde são identificadas as carências, as necessidades, o como agir e com base nele é feito o plano para atuar.
Não vou detalhar muito isso, mas acredito que se possa encontrar um template deste mapa na internet. A identificação das competências necessárias podem ser observadas pelo próprio slogan (que é o ideal). Por exemplo o caso da NISSAN 180.
Se o "1" indica produzir e vender carros, podemos ver que é preciso ter os melhores operários e processos para construção, e os melhores vendedores para vender os carros (e aqui entra vendas, marketing, alinhamento com o mercado, etc). No caso do "8" de rentabilidade de 8%, podemos visualizar que deve-se ter a certeza de que todos da empresa estejam alfabetizados com conceitos de contabilidade. E por fim, o "0" de zerar a dívida, indica que todos precisam estar cientes de como atuar para reduzir os custos da empresa.
Portanto aí podemos evidenciar diversas necessidades que precisam ser atacadas. Facilmente identificadas pelo slogan da empresa.
3 - O terceiro pré-requisito, e o mais complicado deles, é a capacidade de despertar e manter a postura de ATITUDE COLETIVA na empresa.
Esse sem dúvida é o mais crítico deles. E aqui podemos ver como é importante alinhar os objetivos (a visão) da empresa em algo que beneficie a todos. Se o objetivo representa uma necessidade pessoal do presidente da empresa ou de um pequeno grupo, isso será facilmente percebido pelos demais em pouco tempo. E a atitude coletiva vai cair drasticamente.
Um exemplo bem interessante foi discutido na aula. A AmBev criou um slogan chamado "AMBEV MAIS (A+)". A empresa tinha como meta "tornar-se em 5 anos a empresa de bebidas mais competitiva da face da Terra". Um objetivo bem desafiador. Quem não gostaria de fazer parte de algo grandioso? Ainda assim, muitos perguntaram: "O que eu ganho com isso?". Então foi dito que aqueles que liderassem suas equipes de uma forma a atingir os resultados, ganhariam uma bolada de 14 salários. Foi uma festa! Mas, com o tempo, foi visto que a coisa não era bem assim. A idéia da empresa era estimular a competitividade entre o nível tático. E isso seria medido em um ranking... onde só 60% deles receberiam essa premiação. As nuances existiam, portanto. Ainda assim, porém, a pergunta de "o que eu ganho" estava respondida.
Um detalhe curioso: o dono da AmBev tinha um objetivo maior com isso. Ele queria mesmo era figurar entre os 100 mais ricos do mundo, na Forbes, e poder voltar a morar na Europa. Logicamente se ele dissesse isso na empresa jamais teria o apoio que teve. Já imaginaram uma atitude coletiva para atingir um objetivo destes?
---------------
Essa é a essência da gestão de competências: criar uma atitude coletiva na empresa para atingir uma visão de futuro. O entendimento de que isso só será possível com a correta gestão de pessoas é importantíssimo, pois são estas pessoas que irão empurrar a roda para que o objetivo maior seja atingido.
Eu escutava isso durante a aula e não podia deixar de fazer analogia com o agile. Afinal, ambos os conceitos vão de encontro pois tem o foco na valorização das pessoas e equipes para atingir um resultado.
Pretendo, na medida do possível, aplicar este conceito no meu trabalho. Será uma tarefa difícil, mas eu vejo isso como um norte que eu precisava. Eu já possuia alguns objetivos que pretendia que fossem atingidos tais como transformar o laboratório de pesquisa em referência dentro da universidade. Visualizei na gestão de competências o conceito ideal para aplicar isso com uma mecânica certa e bem definida.
Portanto, meus amigos, se tudo der certo eu começarei a divulgar aqui no blog todo o que tenho feito para implantar e trabalhar com este conceito no meu trabalho. E vamos ver que resultados eu irei atingir. Espero que seja uma nova fonte de lições aprendidas para todos nós.
Se você gosta de agile, tenho certeza que quando procurar na internet um pouco sobre gestão por competências, vai se apaixonar mais ainda. :)
Um abraço
terça-feira, 17 de junho de 2008
Seleção de pessoal. Uma tarefa difícil!
Pois então.
O projeto de três anos foi aprovado. Agora terei a missão de formar uma equipe talentosa e capaz de realizar o projeto da melhor maneira possível.
Minha grande dúvida é: como identificar os aspectos comportamentais de um candidato? Lancei a pergunta na lista de "Agile-Brasil" e recebi algumas respostas bacanas. Vou compartilhar com vocês.
O Daniel Wildt respondeu o seguinte:
O Manoel Pimentel respondeu:
O Rodrigo Araújo:
O Roberto Brum:
Por fim, o MT veio com uma resposta bacana:
Enfim. Se você está pensando em selecionar os seus candidatos, vale a pena ler as sugestões e adaptar da melhor forma na sua empresa. Acredito que o ideal seja não decidir com base em UMA entrevista e com UMA opinião. As percepções podem enganar e nos fazer realizar escolhas que depois iremos nos arrepender...
Abraços!
O projeto de três anos foi aprovado. Agora terei a missão de formar uma equipe talentosa e capaz de realizar o projeto da melhor maneira possível.
Minha grande dúvida é: como identificar os aspectos comportamentais de um candidato? Lancei a pergunta na lista de "Agile-Brasil" e recebi algumas respostas bacanas. Vou compartilhar com vocês.
O Daniel Wildt respondeu o seguinte:
Qual o teu foco de contratação? Estagiários? Pessoas com experiência em TI? CLT? PJ? Consultor? Tudo isto vai influir em que perguntas devem ser feitas.
Lembrar que a pessoa deve se ambientar ao time e vice-versa. Teu time será efetivo e vai entregar software se as pessoas saberem trabalhar como uma equipe. A pessoa deve ajudar e buscar ajuda. A pessoa deve ser crítica com relação ao que faz e saber sugerir melhorias e indentificar algo que não esteja de acordo no trabalho sendo desenvolvido, para permitir a geração de ações de melhoria contínua. Que excelência técnica deve ser buscada por todo o time. Deve gostar de se comunicar com o cliente, e também com os colegas de trabalho, para poder conhecer mais do que deve ser desenvolvido e entregue para o cliente.
Vais procurar por softskills, isto é um problema em muitos dos casos de entrevistas. Em uma entrevista, a pessoa pode estar nervosa ou ter um curso de teatro e tudo pode parecer maravilhoso ou horrível.
Resumindo tudo isto... tomar cuidado com uma seleção estilo "blink". Evita os pré-julgamentos.
http://en.wikipedia.org/wiki/Blink_(book)
Uma referência legal:
http://webinsider.uol.com.br/index.php/2006/10/09/identificar-contratar-e-reter-talentos/
O Manoel Pimentel respondeu:
Olá Flávio, legal sua questão.
Creio que só uma entrevista simples não lhe revelará esses traços,
portanto, de repente você poderia fazer dinâmicas de grupo com os
candidatos, com objetivo de identificar esses perfis desejados.
Mas caso não seja possível aplicar essas dinâmicas, talvez seja
interessante, fazer no lugar de uma entrevista formal, uma espécie de
bate-papo informal, para analisar quais as reações dos candidatos as
diversos tipos de questões e principalmente observar se eles terão a
iniciativa de "puxar" algum assunto novo dentro do tema em questão e
de que forma eles se comportam dentro de um diálogo, inclusive você
pode simular questões de concordância e questões de divergências de
idéias para instanciar diferentes climas durante a conversa, assim
será possível avaliar as reações dos candidatos a situações normais e
a situações tensas.
Agora caso queira algo mais formal e com técnica (porém mais difícil
de aplicar), uma boa alternativa é o teste de PI(Predictive Índex),
que é um forma bem técnica e embasado por princípios de psicologia
para identificar e avaliar perfis (ver mais informações nesse fórum:
http://www.via6.com/topico.php?tid=41689).
O Rodrigo Araújo:
Olá Flávio, aqui no Centro de Informática da UFPE nos temos um grupo de pesquisa com o professor Fábio Queda que aborda justamente esse ponto de formação de times baseados em perfis. Em quase todos nossos trabalhos temos nos baseados nos perfis de Belbin (http://www.belbin.com/), porém o acesso aos questinários para avaliação dos perfis é pago. Se você ou mais alguém se interessar pelo assunto posso passar links para artigos e teses que temos publicado a respeito desse assunto.
O Roberto Brum:
Se você será o responsável, você deverá se sentir bem com ele, deve ter empatia. Faça perguntas abertas para fazê-lo falar.
Sugestão (se você nunca fez entrevista de emprego): Comece falando da empresa, dos produtos, da política, para ver se interessa ao candidato. Não adianta contratar alguém muito bom se ele não se sentir bem no ambiente. Depois de apresentar a empresa, você pode ir lendo o currículo e fazendo perguntas como:
Por que você saiu desta empresa?
O que você mais gostou quando trabalhou lá?
O que menos gostou?
E o que te deixou orgulhoso neste emprego?
Por fim, o MT veio com uma resposta bacana:
Algumas dicas que aprendi nos meus tempos de Rational Software:
1 - Envolva mais pessoas. Não sei se é possível agora, mas ter pelo
menos 3 pessoas em cada entrevista dilui riscos e permite que
aspectos sutis sejam captados com mais facilidade. Quando o candidato
sair, façam o "debriefing" imediatamente e anote na ficha do cara.
2 - A palavra final deve ser de quem vai trabalhar com o candidato.
3 - Elabore uma lista de características que vc quer, separando-as
por categoria. Ex: Conhecimento Técnico, Habilidades Interpessoais,
Iniciativa e Liderança, etc. Tente, em cada categoria, fazer uma
lista de "features" que essa pessoa deve ter. Ex: em Liderança, ver
se já participou de gremio ou centro academico. É sindico do predio?
Já foi orador da turma? etc,etc, etc. Vc tem que dar "notas"
ou "ok's" para esses pontos durante a entrevista.
4 - Use uma abordagem "comportamental". Existe uma técnica
chamada "behaverial interview", que usa o passado da pessoa para
saber como ela é. Em vez de perguntar "como vc lida com conflitos"
ou "se houver um conflito com outra pessoa, como vc resolve?", vc
pergunta assim, como quem não quer nada "me conte, vc já teve alguma
discussão no trabalho? Já enfrentou algum tipo de problema com algum
colega? Conte-me mais, como foi? Conte o 'causo' em detalhes". E vá
explorando a história, perguntando detalhes do que o candidato fez na
situação. A idéia é que as pessoas não mudam muito e o que o cidadão
fez no passado é um sinal muito bom do que ele fará no futuro na
mesma situação.
Um exemplo interessante: uma vez, fui entrevistar um candidato em
cujo curriculo as palavras "lider" ou "liderança" apareciam um monte
de vezes. Perguntei-lhe se ele já tivera a experiência de 2 membros
da equipe dele discutirem ou discordarem em algo. Depois, perguntei o
que ele fez para solucionar a questão. Resultado: ele, mesmo, nunca
resolveu nenhum conflito de colegas ou subordinados, sempre levou
para a gerência. Que tipo de liderança esse cara mostrou?
A lista de características combinada com a abordagem comportamental é
uma ferramenta muito poderosa.
Finalmente, considere ter 2 ou 3 entrevistas, sendo uma geral, uma
técnica e uma para aspectos pessoais.
Enfim. Se você está pensando em selecionar os seus candidatos, vale a pena ler as sugestões e adaptar da melhor forma na sua empresa. Acredito que o ideal seja não decidir com base em UMA entrevista e com UMA opinião. As percepções podem enganar e nos fazer realizar escolhas que depois iremos nos arrepender...
Abraços!
sábado, 14 de junho de 2008
Porto Alegre Agile Meeting 1
Sexta-feira tive a oportunidade de conhecer e papear com algumas pessoas fantásticas. Ocorreu em Porto Alegre o treinamento de CSM (Certified Scrum Master) pela Teamware. Eu havia conversado com o Juan, que estava promovendo o curso, da possibilidade de fazermos um encontro após o curso (que eu não pude participar). Ele então achou ótima a idéia e ajudou a divulgar. Saiu então o primeiro "Porto Alegre Agile Meeting", que infelizmente só teve presença de 5 pessoas, incluindo eu.
Estavam presentes dois alunos do curso (agora certificados!), o Juan, o canadense Robin Dymond (instrutor do curso) e eu. Cheguei atrasado, pois precisava buscar a namorada na rodoviária (e ela acabou indo e achou bastante interessante devido a sua área de interesse ser de RH e o Agile ter uma forte presença nessa área). Encontrei o pessoal e pudemos papear (meio em português, meio em inglês para o Robin participar) sobre Agile e até mesmo assuntos banais. Pude conversar com o Robin um pouco e foi bem legal pois ele já trabalhou com sistemas embarcados em hardware, o que me ajudou bastante a entender algumas idéias para aplicar no meu trabalho!
O bacana foi a possibilidade de trocar experiências e lições aprendidas, discutir conceitos, concordar, discordar, fazer networking, enfim. É exatamente o tipo de evento que eu sempre busco organizar!
Portanto, preparem-se os moradores de Porto Alegre e região, pois tentarei organizar estes encontros pelo menos 1x por mês.
A foto dos "mosqueteiros" que foram ao encontro está abaixo:
Da esquerda para a direita: Eduardo Bobsin Machado (da Human Mobile), Juan Bernabo (da Teamware), Flávio Steffens (eu!), Marcos Moraes (da Suryatec) e Robin Dymond (da Innovel).
Estavam presentes dois alunos do curso (agora certificados!), o Juan, o canadense Robin Dymond (instrutor do curso) e eu. Cheguei atrasado, pois precisava buscar a namorada na rodoviária (e ela acabou indo e achou bastante interessante devido a sua área de interesse ser de RH e o Agile ter uma forte presença nessa área). Encontrei o pessoal e pudemos papear (meio em português, meio em inglês para o Robin participar) sobre Agile e até mesmo assuntos banais. Pude conversar com o Robin um pouco e foi bem legal pois ele já trabalhou com sistemas embarcados em hardware, o que me ajudou bastante a entender algumas idéias para aplicar no meu trabalho!
O bacana foi a possibilidade de trocar experiências e lições aprendidas, discutir conceitos, concordar, discordar, fazer networking, enfim. É exatamente o tipo de evento que eu sempre busco organizar!
Portanto, preparem-se os moradores de Porto Alegre e região, pois tentarei organizar estes encontros pelo menos 1x por mês.
A foto dos "mosqueteiros" que foram ao encontro está abaixo:
Da esquerda para a direita: Eduardo Bobsin Machado (da Human Mobile), Juan Bernabo (da Teamware), Flávio Steffens (eu!), Marcos Moraes (da Suryatec) e Robin Dymond (da Innovel).A dispensa
Conforme eu mencionei em um post anterior, sexta-feira foi o dia em que eu tive que dispensar um funcionário do grupo. Então como prometido, vou contar como foi.
Cheguei no trabalho por volta das 13h30, pois tinha uma reunião importante às 14h. O funcionário já estava lá. Falei que queria conversar com ele, mais tarde. Como havia gente em volta, falei que era a respeito do projeto.
Então fui conversar com um dos meus chefes e falei da minha decisão. Ele concordou e me listou os trâmites para oficializar isso: cancelar o acesso dele no andar, pegar o crachá, etc.
Pelas 17h, chamei o funcionário para conversar. Então falei, já na sala de reuniões, que eu tinha duas notícias ruins. A primeira, a respeito do projeto em que ele estava trabalhando... que havia sido modificado totalmente e que, portanto, tudo o que ele havia feito não teria mais utilidade. Decidi por falar isso como forma de já deixá-lo desmotivado e para que ele entendesse o motivo da segunda noticia ruim...
Então falei que a notícia era que eu havia decidido pela dispensa dele do grupo. Na hora eu notei que foi aquela surpresa para ele. Ele realmente não esperava.
Comecei a parte chata, a da justificativa. Eu considero "chata" pois por mais que a gente fale, sempre fica a impressão de que a gente está mentindo ou falando por falar... por mais sincero que seja.
Disse para ele que infelizmente os projetos que viriam a seguir iriam exigir uma equipe que tivesse experiência em programação. E que ele não tinha essa experiência ainda. Logo, ele sofreria uma pressão enorme para cumprir coisas que ele não teria o preparo necessário. E infelizmente não teríamos como treiná-lo para fazer as coisas.
Falei que eu estava fazendo aquilo para preservá-lo, por mais estranho que parecesse. Eu comentei que já havia vivenciado essa situação em que ele se encontrava: entrar num emprego num projeto, ver o projeto morrer e dai ficar um "severino" dentro da empresa, ou seja, um aparador de arestas, um faz-tudo sem objetivo concreto. E, ao contrário do que aconteceu comigo, eu preferia cortá-lo agora do que deixá-lo cozinhando nessa situação expondo ele a conflitos desnecessários. Ele não ia aproveitar em nada o período lá.
Ou seja, seria ruim para a empresa/grupo (que não poderia contar com as tarefas dele sendo finalizadas), ruim para mim (que seria o responsável por "não cobrar ele") e ruim para ele (que não conseguiria atingir os objetivos e veria sua auto-confiança ser esmagada).
É claro que eu não consegui falar isso de uma forma tranquila, pois eu estava um pouco nervoso (não no sentido de bravo) e quando fico assim tendo a falar e repetir demais algumas coisas. Mas sempre deixei claro pra ele que ele não estava sendo dispensado por ser incompetente (e ai eu quis ressaltar bastante isso), mas sim por causa do perfil dele não se encaixar nos próximos projetos.
Terminei falando pra ele desabafar, caso tivesse algo para dizer. Alguma reclamação quanto a mim ou aos demais, ou a forma como havia sido conduzido tudo. Ele disse que só havia ficado meio desmotivado no inicio do ano, quando foi o pico da vida de "severino" dele. Eu concordei e reforcei que era exatamente disso que eu queria preservá-lo, novamente. Pois fatalmente ele cairia nessa situação. Então ele disse que fora isso ele achava que tudo havia ocorrido da forma certa, para ele.
Então disse que se ele precisasse de referências ou de alguma ajuda, que podia contar comigo, pois faria o possível para ajudá-lo. Me despedi dele e falei para segunda-feira ele ir até a empresa para encerrar o contrato e fazer a burocracia.
Me despedi e ele voltou para o laboratório. Notei que parecia que ou a ficha dele não havia caído, ou que ele estava se sentindo mais leve... pois ele conversava com os demais como se nada tivesse acontecido. Achei isso um bom sinal, demonstrando que ele não estava bravo ou insatisfeito.
Enfim, afora o meu nervosismo na hora de comunicar ele (afinal, é uma situação ruim de lidar), acho que fiz o que eu podia para amenizar essa situação ruim. E acho que funcionou. É a segunda vez que dispenso alguém... e dessa vez a coisa foi melhor.
Um dos meus chefes aparentemente não gostou muito da situação. Ele estava viajando e só soube quando a coisa já havia acontecido. Mas como ele é mais apaziguador, eu acredito que ele deve estar pensando que "talvez se déssemos outra chance pra ele" ou coisa similar. Mas, como eu disse, eu tenho CERTEZA de que isso só atrasaria a vida do funcionário.
Ele é novo, tem menos de 20 anos. Nós não poderíamos ajudá-lo a crescer ali dentro, então nada melhor do que fazê-lo ter oportunidades melhores e reais em outros locais. Acredito que ele será um excelente profissional e torço para isso. Só que infelizmente temos que tomar esse tipo de decisão, algumas vezes. Temos que pensar na empresa e nos interesses de cada um (meu e dele, por exemplo). Logo, se duas dessas três variáveis dizerem que temos que dispensar alguém, é melhor fazer logo. Adiar, normalmente é a pior decisão de todas.
Um dia intenso... mas com um bom aprendizado.
Abraços
Cheguei no trabalho por volta das 13h30, pois tinha uma reunião importante às 14h. O funcionário já estava lá. Falei que queria conversar com ele, mais tarde. Como havia gente em volta, falei que era a respeito do projeto.
Então fui conversar com um dos meus chefes e falei da minha decisão. Ele concordou e me listou os trâmites para oficializar isso: cancelar o acesso dele no andar, pegar o crachá, etc.
Pelas 17h, chamei o funcionário para conversar. Então falei, já na sala de reuniões, que eu tinha duas notícias ruins. A primeira, a respeito do projeto em que ele estava trabalhando... que havia sido modificado totalmente e que, portanto, tudo o que ele havia feito não teria mais utilidade. Decidi por falar isso como forma de já deixá-lo desmotivado e para que ele entendesse o motivo da segunda noticia ruim...
Então falei que a notícia era que eu havia decidido pela dispensa dele do grupo. Na hora eu notei que foi aquela surpresa para ele. Ele realmente não esperava.
Comecei a parte chata, a da justificativa. Eu considero "chata" pois por mais que a gente fale, sempre fica a impressão de que a gente está mentindo ou falando por falar... por mais sincero que seja.
Disse para ele que infelizmente os projetos que viriam a seguir iriam exigir uma equipe que tivesse experiência em programação. E que ele não tinha essa experiência ainda. Logo, ele sofreria uma pressão enorme para cumprir coisas que ele não teria o preparo necessário. E infelizmente não teríamos como treiná-lo para fazer as coisas.
Falei que eu estava fazendo aquilo para preservá-lo, por mais estranho que parecesse. Eu comentei que já havia vivenciado essa situação em que ele se encontrava: entrar num emprego num projeto, ver o projeto morrer e dai ficar um "severino" dentro da empresa, ou seja, um aparador de arestas, um faz-tudo sem objetivo concreto. E, ao contrário do que aconteceu comigo, eu preferia cortá-lo agora do que deixá-lo cozinhando nessa situação expondo ele a conflitos desnecessários. Ele não ia aproveitar em nada o período lá.
Ou seja, seria ruim para a empresa/grupo (que não poderia contar com as tarefas dele sendo finalizadas), ruim para mim (que seria o responsável por "não cobrar ele") e ruim para ele (que não conseguiria atingir os objetivos e veria sua auto-confiança ser esmagada).
É claro que eu não consegui falar isso de uma forma tranquila, pois eu estava um pouco nervoso (não no sentido de bravo) e quando fico assim tendo a falar e repetir demais algumas coisas. Mas sempre deixei claro pra ele que ele não estava sendo dispensado por ser incompetente (e ai eu quis ressaltar bastante isso), mas sim por causa do perfil dele não se encaixar nos próximos projetos.
Terminei falando pra ele desabafar, caso tivesse algo para dizer. Alguma reclamação quanto a mim ou aos demais, ou a forma como havia sido conduzido tudo. Ele disse que só havia ficado meio desmotivado no inicio do ano, quando foi o pico da vida de "severino" dele. Eu concordei e reforcei que era exatamente disso que eu queria preservá-lo, novamente. Pois fatalmente ele cairia nessa situação. Então ele disse que fora isso ele achava que tudo havia ocorrido da forma certa, para ele.
Então disse que se ele precisasse de referências ou de alguma ajuda, que podia contar comigo, pois faria o possível para ajudá-lo. Me despedi dele e falei para segunda-feira ele ir até a empresa para encerrar o contrato e fazer a burocracia.
Me despedi e ele voltou para o laboratório. Notei que parecia que ou a ficha dele não havia caído, ou que ele estava se sentindo mais leve... pois ele conversava com os demais como se nada tivesse acontecido. Achei isso um bom sinal, demonstrando que ele não estava bravo ou insatisfeito.
Enfim, afora o meu nervosismo na hora de comunicar ele (afinal, é uma situação ruim de lidar), acho que fiz o que eu podia para amenizar essa situação ruim. E acho que funcionou. É a segunda vez que dispenso alguém... e dessa vez a coisa foi melhor.
Um dos meus chefes aparentemente não gostou muito da situação. Ele estava viajando e só soube quando a coisa já havia acontecido. Mas como ele é mais apaziguador, eu acredito que ele deve estar pensando que "talvez se déssemos outra chance pra ele" ou coisa similar. Mas, como eu disse, eu tenho CERTEZA de que isso só atrasaria a vida do funcionário.
Ele é novo, tem menos de 20 anos. Nós não poderíamos ajudá-lo a crescer ali dentro, então nada melhor do que fazê-lo ter oportunidades melhores e reais em outros locais. Acredito que ele será um excelente profissional e torço para isso. Só que infelizmente temos que tomar esse tipo de decisão, algumas vezes. Temos que pensar na empresa e nos interesses de cada um (meu e dele, por exemplo). Logo, se duas dessas três variáveis dizerem que temos que dispensar alguém, é melhor fazer logo. Adiar, normalmente é a pior decisão de todas.
Um dia intenso... mas com um bom aprendizado.
Abraços
sexta-feira, 13 de junho de 2008
Grandes verdades da humanidade: bugs em tecnologia
Não importa quantos testadores experientes você tenham e sua equipe. A sua mãe sempre vai achar um bug impensável!
Pelo menos a minha mãe consegue fazer coisas no Windows que nem o Bill Gates sonha! haha
Hoje vai ser um dia .... ruim.
A vida de um gerente tem o lado bom e o lado ruim.
Normalmente podemos dizer que o lado ruim depende de um ponto de vista... podemos transformar dificuldades em desafios e oportunidades. Discussões e conflitos sempre vão existir e cabe a cada um saber lidar com isso da melhor forma possível. Como dizia aquela frase clássica do Che Guevara, que todo mundo copia: "Hay de endurecer, pero sin perder la ternura".
Pois bem... hoje vai ser um dia em que o lado ruim não tem lado bom. É ruim mesmo. Será o dia em que eu terei que dispensar um funcionário.
Acho que cabe contextualizar a situação desse funcionário. Ele é bem jovem, está no terceiro semestre da faculdade. Eu mesmo fui o responsável por contratá-lo, para um outro projeto. Ainda me lembro que na seleção ele me chamou a atenção por participar de diversas atividades extra-curriculares, que envolviam robótica, no colégio dele. Me chamou a atenção mesmo e não nego que isso foi um diferencial dele para os demais.
O projeto em que ele participaria envolveria o desenvolvimento de uma aplicação para um Palmtop, utilizando uma linguagem de programação recente. Logo, ele aprenderia a linguagem e desenvolveria um sistema iterativo, começando pelo básico até chegar em algo mais robusto. O prazo era grande, não haveria tanta pressão. Infelizmente o projeto acabou morrendo. O possível cliente perdeu o interesse.
O que aconteceu então? O funcionário passou o resto dos meses pulando de projeto em projeto. Fazendo atividades monótonas e sem valor algum. Obviamente a motivação dele foi lá para baixo. Eu já vivi essa situação em uma empresa e sei como é ser sub-utilizado. É desmotivador na sua essência!
Então surgiu a oportunidade de utilizar ele em um outro projeto (daqueles de última hora que nos jogam). Ele desenvolveria um simulador para dispositivo móvel. Novamente pude ver como ele se motivou para fazer isso. Ele estava sempre trabalhando e buscando uma forma de fazer o simulador da melhor forma. Porém, o escopo foi modificado e o simulador foi deixado de lado (isso ele ainda não sabe).
Como a perspectiva dos próximos projetos são de que precisemos de pessoas com bastante experiência em desenvolvimento, eu e o meu colega conversamos ontem e concluímos que realmente não haveria como utilizar esse funcionário. Ele perderia tempo demais para aprender a programar da forma correta, utilizando os conceitos de mercado. E, além disso, concluí que mantê-lo para fazer com que ele fique de "severino" da empresa seria apenas atrasar demais o lado profissional dele.
Decidi, então, que o melhor seria desligá-lo do grupo. E hoje, se ele for no trabalho, irei dar a notícia.
É lógico que eu espero uma reação de surpresa e até com um pouco de indignação. Mas eu prefiro mil vezes cortá-lo agora, de uma forma mais sincera e sutil, do que mantê-lo e obrigá-lo a sofrer uma pressão e uma cobrança por algo que ele não terá capacidade de desenvolver. E eu sei que essa pressão vai existir no projeto. E fazê-lo passar por isso será pisar na motivação e, quem sabe, na auto-confiança dele.
É duro ter que dispensar alguém. Mas as vezes é melhor fazer isso logo, do que tentar insistir em algo que vai prejudicar a todos: eu, ele e o grupo.
Eu posto depois como foi a dispensa, como conduzi isso. Se tudo der certo, ainda hoje.
Abraços
Normalmente podemos dizer que o lado ruim depende de um ponto de vista... podemos transformar dificuldades em desafios e oportunidades. Discussões e conflitos sempre vão existir e cabe a cada um saber lidar com isso da melhor forma possível. Como dizia aquela frase clássica do Che Guevara, que todo mundo copia: "Hay de endurecer, pero sin perder la ternura".
Pois bem... hoje vai ser um dia em que o lado ruim não tem lado bom. É ruim mesmo. Será o dia em que eu terei que dispensar um funcionário.
Acho que cabe contextualizar a situação desse funcionário. Ele é bem jovem, está no terceiro semestre da faculdade. Eu mesmo fui o responsável por contratá-lo, para um outro projeto. Ainda me lembro que na seleção ele me chamou a atenção por participar de diversas atividades extra-curriculares, que envolviam robótica, no colégio dele. Me chamou a atenção mesmo e não nego que isso foi um diferencial dele para os demais.
O projeto em que ele participaria envolveria o desenvolvimento de uma aplicação para um Palmtop, utilizando uma linguagem de programação recente. Logo, ele aprenderia a linguagem e desenvolveria um sistema iterativo, começando pelo básico até chegar em algo mais robusto. O prazo era grande, não haveria tanta pressão. Infelizmente o projeto acabou morrendo. O possível cliente perdeu o interesse.
O que aconteceu então? O funcionário passou o resto dos meses pulando de projeto em projeto. Fazendo atividades monótonas e sem valor algum. Obviamente a motivação dele foi lá para baixo. Eu já vivi essa situação em uma empresa e sei como é ser sub-utilizado. É desmotivador na sua essência!
Então surgiu a oportunidade de utilizar ele em um outro projeto (daqueles de última hora que nos jogam). Ele desenvolveria um simulador para dispositivo móvel. Novamente pude ver como ele se motivou para fazer isso. Ele estava sempre trabalhando e buscando uma forma de fazer o simulador da melhor forma. Porém, o escopo foi modificado e o simulador foi deixado de lado (isso ele ainda não sabe).
Como a perspectiva dos próximos projetos são de que precisemos de pessoas com bastante experiência em desenvolvimento, eu e o meu colega conversamos ontem e concluímos que realmente não haveria como utilizar esse funcionário. Ele perderia tempo demais para aprender a programar da forma correta, utilizando os conceitos de mercado. E, além disso, concluí que mantê-lo para fazer com que ele fique de "severino" da empresa seria apenas atrasar demais o lado profissional dele.
Decidi, então, que o melhor seria desligá-lo do grupo. E hoje, se ele for no trabalho, irei dar a notícia.
É lógico que eu espero uma reação de surpresa e até com um pouco de indignação. Mas eu prefiro mil vezes cortá-lo agora, de uma forma mais sincera e sutil, do que mantê-lo e obrigá-lo a sofrer uma pressão e uma cobrança por algo que ele não terá capacidade de desenvolver. E eu sei que essa pressão vai existir no projeto. E fazê-lo passar por isso será pisar na motivação e, quem sabe, na auto-confiança dele.
É duro ter que dispensar alguém. Mas as vezes é melhor fazer isso logo, do que tentar insistir em algo que vai prejudicar a todos: eu, ele e o grupo.
Eu posto depois como foi a dispensa, como conduzi isso. Se tudo der certo, ainda hoje.
Abraços
quinta-feira, 12 de junho de 2008
Dia de decisões
Acho que nunca tive um dia tão cheio de decisões quanto hoje!
Parece que todos os projetos que estou envolvido decidiram ter o "Dia da decisão" ao mesmo tempo. Eu saia de uma reunião e ia para outra. Todas para decidir algo importante para o projeto.
Confesso que fiquei zonzo.
Então desculpem não postar nada mais hoje... amanhã prometo postar em dobro :)
Abraços!
Parece que todos os projetos que estou envolvido decidiram ter o "Dia da decisão" ao mesmo tempo. Eu saia de uma reunião e ia para outra. Todas para decidir algo importante para o projeto.
Confesso que fiquei zonzo.
Então desculpem não postar nada mais hoje... amanhã prometo postar em dobro :)
Abraços!
terça-feira, 10 de junho de 2008
SCRUM como cultura... e não superficial
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
É comum a gente encontrar artigos na internet criticando o Agile e até mesmo o próprio SCRUM, em particular. Até mesmo em discussões esse assunto é recorrente. Eu considero que quem critica o SCRUM, na maioria dos casos (vale ressaltar), tem uma visão MUITO superficial do que os processos ágeis sugerem.
Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.
Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!
Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.
Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.
Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.
Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.
Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...
Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.
Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:
Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.
SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.
É comum a gente encontrar artigos na internet criticando o Agile e até mesmo o próprio SCRUM, em particular. Até mesmo em discussões esse assunto é recorrente. Eu considero que quem critica o SCRUM, na maioria dos casos (vale ressaltar), tem uma visão MUITO superficial do que os processos ágeis sugerem.
Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.
Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!
Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.
Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.
Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.
Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.
Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...
Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.
Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:
- Nao vi nenhum de voces acompanhando o desenvolvimento disto com o Beltrano e/ou Sicrano (os dois da equipe atual) na ultima semana. Nao adianta simplesmente passar as tarefas para eles e nao acompanhar o desenvolvimento diario delas, assim como as dificuldades que eles estao tendo. Onde esta o scrum?
- Voces como gerente de projetos devem saber como as coisas sao/foram implementadas, pois voces sao a memoria da equipe. Se desenvolvedores saem da equipe, isto, em principio, nao deveria afetar em nada o trabalho em relacao a parte tecnica.
- Sempre falei que qq sistema deveria ser modular e de facil re-adaptacao. O codigo objeto deve ser realizado segundo as metodologias de projeto adequadas para que isto nao ocorra mais. Nao podemos ficar sempre tendo que reaprender codigo de outros. Onde foram para as metodologias de projeto? engenharia de sw?
Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.
SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.
segunda-feira, 9 de junho de 2008
Grandes verdades da humanidade: é impossível trabalhar em casas.
Se existe uma verdade absoluta e universal (diria até cósmica) é a impossibilidade de se trabalhar em casa (nem mesmo descansar!).
Na semana passada, estava meio ruim da gripe e decidi ficar em casa (quarta-feira). Pensei: "Vou adiantar alguns trabalhos pendentes, preparar um material e ler um texto".
Resultado: pela manhã fiquei resolvendo um problema no meu notebook (do trabalho!) e uma conta que a operadora de cabo havia feito cobrança indevida. Pela tarde, li UM PARÁGRAFO do texto e tive que resolver pelo menos dois problemas para a minha mãe e ainda lidar com a falta de internet (que me impossibilitou de ler os emails).
Não adianta. Você pode fazer o que quiser para tentar trabalhar em casa. Mas com certeza será exatamente no dia em que todos os planetas do sistema solar se alinharão e se voltarão contra você, fazendo TUDO dar errado.
Existe uma série no Multishow chamada "Cilada", que eu acho muito divertida. Um episódio o ator aborda exatamente isso, como é difícil tirar um dia de semana em casa para descansar ou trabalhar. Assistam e me digam se é ou não é verdade :)
Parte 1
Parte 2
Na semana passada, estava meio ruim da gripe e decidi ficar em casa (quarta-feira). Pensei: "Vou adiantar alguns trabalhos pendentes, preparar um material e ler um texto".
Resultado: pela manhã fiquei resolvendo um problema no meu notebook (do trabalho!) e uma conta que a operadora de cabo havia feito cobrança indevida. Pela tarde, li UM PARÁGRAFO do texto e tive que resolver pelo menos dois problemas para a minha mãe e ainda lidar com a falta de internet (que me impossibilitou de ler os emails).
Não adianta. Você pode fazer o que quiser para tentar trabalhar em casa. Mas com certeza será exatamente no dia em que todos os planetas do sistema solar se alinharão e se voltarão contra você, fazendo TUDO dar errado.
Existe uma série no Multishow chamada "Cilada", que eu acho muito divertida. Um episódio o ator aborda exatamente isso, como é difícil tirar um dia de semana em casa para descansar ou trabalhar. Assistam e me digam se é ou não é verdade :)
Parte 1
Parte 2
Em algum lugar do Brasil...
Mensagem da listeira "Keylla", na lista E-Plan. Uma realidade não tão distante... para ler e pensar.
Sim, Keylla... TODOS nós já vivemos situações parecidas. Ou não é?
Fui contratada por uma empresa, que não possui um histórico de gerência de projetos, para ajudar a colocar um projeto no trilho. Este projeto já está em andamento há uns 4 anos e já teve várias renegociações de prazos de entrega.
Desde que eu entrei para o projeto obtivemos consideráveis melhorias no seu gerenciamento, entretanto, chegamos em um ponto que tem me deixado sem ação (e me tirado o sono, também).
Este projeto, que é de desenvolvimento de software, tem sofrido com graves problemas técnicos: erros, usabilidade ruim e baixa performance. A cada dia que passa um novo problema surge, gerando um novo retrabalho. Por causa disso, apesar de ter conseguindo inserir um certo nível de planejamento e acompanhamento, confesso estar sem controle sobre o projeto, pois a cada dia precisamos alterar as prioridades das atividades dos membros da equipe para refazer alguma coisa que já estava pronta causando atrasos e mais atrasos.
Em outras palavras, a cada dia que passa novas atividades precisam ser inseridas no projeto, empurrando o final do projeto sempre para mais longe.
Gostaria de saber se alguém já passou por uma situação parecida e quais ações poderiam ser tomadas para gerenciar de forma mais efetiva esses projeto.
Sim, Keylla... TODOS nós já vivemos situações parecidas. Ou não é?
sexta-feira, 6 de junho de 2008
O dedo de Deus
Essa semana foi finalizada com o dedo de Deus.
O que eu temia que aconteceria, aconteceu: eu tentei enrolar, mas acabei marcando com o cliente a apresentação do sistema para a quinta-feira passada. Obviamente nosso desenvolvedor part-time não havia conseguido finalizar o sistema.
Eu já estava perdendo os cabelos com isso, pensando no que eu faria para resolver.
Então o dedo de Deus entrou em ação. Deu um "peteleco" no responsável pela homologação, lá no cliente, e ele me enviou um email dizendo:
E eu respondi: "Poxa, que pena, Márcio. Tudo bem então. Aguardo teu contato na semana que vem".
YES!!!! YES!!!!
Foi a melhor notícia que eu poderia ter tido. Sensacional.
Essa realidade é triste, analisando friamente. Mas na realidade em que eu vivo, situações como essa são de uma alegria inimaginável. Pelo menos até termos verba para montarmos a equipe de software!
Abraços
O que eu temia que aconteceria, aconteceu: eu tentei enrolar, mas acabei marcando com o cliente a apresentação do sistema para a quinta-feira passada. Obviamente nosso desenvolvedor part-time não havia conseguido finalizar o sistema.
Eu já estava perdendo os cabelos com isso, pensando no que eu faria para resolver.
Então o dedo de Deus entrou em ação. Deu um "peteleco" no responsável pela homologação, lá no cliente, e ele me enviou um email dizendo:
Flavio,
Devido a outras atividades terei que desmarcar a reunião de amanhã as 14:00, assim que possível retorno para combinarmos uma outra data, provavelmente no começo da semana que vem.
E eu respondi: "Poxa, que pena, Márcio. Tudo bem então. Aguardo teu contato na semana que vem".
YES!!!! YES!!!!
Foi a melhor notícia que eu poderia ter tido. Sensacional.
Essa realidade é triste, analisando friamente. Mas na realidade em que eu vivo, situações como essa são de uma alegria inimaginável. Pelo menos até termos verba para montarmos a equipe de software!
Abraços
quinta-feira, 5 de junho de 2008
Brasil x resto do mundo
Um assunto que costuma gerar situações inusitadas (que vão desde engraçadas até trágicas) geralmente está relacionado à diferença cultural entre dois povos. Hoje durante a aula conversei com alguns colegas a respeito e queria citar alguns aqui. Só por curiosidade e para pensarmos como é cada vez mais importante para nós que vivemos em um mundo globalizado e amanhã poderemos estar negociando com outras culturas.
+ Recentemente, troquei alguns emails com uma empresa indiana para tentar fazer uma parceria de outsourcing com eles. Lá pelas tantas, o CEO da empresa me falou: "Flavio, I will send you my picture with my son. Can you send yours?". Aquilo me soou TÃO estranho, que eu confesso que até hoje o indiano deve estar esperando a foto. Não sei ao certo o que isso tem a ver, mas ele mandou a foto dele com o filho... talvez seja um sinal de confiança. Não sei. Mas nós, brasileiros, dificilmente trocamos fotos entre homens!
+ Ainda sobre indianos, soube que certa vez uma executiva indiana esteve no Brasil. Ela gostava muito de fotografar. Lá pelas tantas, ela viu um prédio muito bonito em São Paulo e decidiu fotografar. Sua câmera não pegava todo o prédio, então ela decidiu ir andando pra trás... até chegar no meio da rua e morrer atropelada. Detalhe: na Índia, parar no meio da rua é algo que não costuma ser fatal.
+ Em uma convenção de executivos, um brasileiro e um português conversavam para trocar contatos. O brasileiro então falou: "Qual é o teu telefone?". E o português respondeu animado: "Nokia! E o seu?". O brasileiro então pensou... e deu uma gargalhada. O português fez cara de poucos amigos. Depois de algumas explicações, tudo ficou melhor. Mas o fato é que nós brasileiros temos a mania de querer que os nossos interlocutores ADIVINHEM o que queremos. "Qual é o teu telefone" é um diminuitivo para "Qual é o número do teu telefone". Os portugueses pensam de forma bem objetiva (e óbvia). Todo cuidado é pouco!
+ Certa vez li que um executivo estava em um hotel, em Portugal, e decidiu pedir uma pizza. Ele então pediu uma grande meia calabreza e meia muzzarela. O atendente falou que não havia pizza de muzzarela. "Como não?!?" gritou o brasileiro. Depois de muita briga, o brasileiro decidiu facilitar a vida do português: "Bem, amigo. Me dá então uma pizza inteira de calabreza, só que metade dela SEM calabreza". E o português respondeu: "Ok! Obrigado pela compreensão".
+ Quando você for para o Japão negociar com executivos japoneses, muito cuidado! Um executivo havia ido até lá para negociar com uma grande montadora, em uma viagem de cinco dias. Chegando lá, pretendia iniciar logo a reunião. Os japoneses quiseram fazer um tour pela cidade no primeiro dia. No segundo e terceiro dia, os japoneses mostraram todas as fábricas, passaram por todos setores de produção, mostraram os detalhes das suas empresas. No quarto dia, ofereceram um espetáculo cultural a ele. No quinto e último dia, no retorno para o aeroporto, o executivo japonês indagou o brasileiro: "Então, qual a sua proposta?". Resultado: o brasileiro, cansado e tonto com tanta coisa, acabou fazendo todas as vontades do japonês.
+ O povo alemão costuma ter origens fortes e são normalmente bastante resistente à mudanças. Em uma fábrica alimentícia no RS, um dos supervisores era alemão genuíno. Fazia todo o processo no olho, sabia exatamente a quantidade exata de cada porção. Ainda assim, de vez em quando falhava. A fábrica decidiu instalar uma máquina mais moderna, onde ele simplesmente entraria com o valor da quantidade e só precisava monitorar de tempos em tempos, se tudo estava ok. Para a surpresa da diretoria, descobriram que o alemão continuou fazendo tudo no olhômetro, dizendo que a máquina não era precisa e fazia tudo errado. A fábrica decidiu ouvir o alemão.
+ Um dos cases mais estudados no mundo é a volta por cima da Nissan, empresa japonesa comprada pela Renault, que estava indo para o buraco. Mas graças a um brasileiro, a empresa em 3 anos voltou a ser referência mundial. Uma das primeiras grandes medidas desse brasileiro foi acabar com um dos maiores paradigmas culturais do Japão: o conceito de que todos trabalham na mesma empresa por toda a vida. Para reduzir custos, foi preciso demitir milhares de japoneses e implantar uma mudança de conceito, onde a promoção não ocorreria mais por tempo de cargo, mas sim por resultados. O brasileiro (chamado Carlos Ghosn) enfrentou uma cultura milenar e, após ser visto com desconfiança (e até ódio) por parte dos japoneses, virou uma celebridade na terra do sol nascente.
+ Por fim, uma que não é sobre o mundo coorporativo, mas fala muito sobre a essência e sobre a cultura japonesa. O jogador e atual técnico da seleção Dunga, um dos primeiros brasileiros a ir jogar no incipiente futebol japonês, contou que certa vez o seu time se preparava para fazer a barreira em uma cobrança de falta do time adversário. O juiz marcou a posição da barreira e apitou a cobrança. O Dunga então começou a mandar todos da barreira avançarem, para dificultar a cobrança. E ouviu dos japoneses do próprio time: "Não! Não pode! Não pode!".
Causos de diferenças culturais existem aos montes. E isso mostra como é importante saber pelo menos um pouco em que território estamos pisando.
E você, caro leitor, conhece uma história divertida que envolve diferenças culturais? Conte para nós!
Um abraço
+ Recentemente, troquei alguns emails com uma empresa indiana para tentar fazer uma parceria de outsourcing com eles. Lá pelas tantas, o CEO da empresa me falou: "Flavio, I will send you my picture with my son. Can you send yours?". Aquilo me soou TÃO estranho, que eu confesso que até hoje o indiano deve estar esperando a foto. Não sei ao certo o que isso tem a ver, mas ele mandou a foto dele com o filho... talvez seja um sinal de confiança. Não sei. Mas nós, brasileiros, dificilmente trocamos fotos entre homens!
+ Ainda sobre indianos, soube que certa vez uma executiva indiana esteve no Brasil. Ela gostava muito de fotografar. Lá pelas tantas, ela viu um prédio muito bonito em São Paulo e decidiu fotografar. Sua câmera não pegava todo o prédio, então ela decidiu ir andando pra trás... até chegar no meio da rua e morrer atropelada. Detalhe: na Índia, parar no meio da rua é algo que não costuma ser fatal.
+ Em uma convenção de executivos, um brasileiro e um português conversavam para trocar contatos. O brasileiro então falou: "Qual é o teu telefone?". E o português respondeu animado: "Nokia! E o seu?". O brasileiro então pensou... e deu uma gargalhada. O português fez cara de poucos amigos. Depois de algumas explicações, tudo ficou melhor. Mas o fato é que nós brasileiros temos a mania de querer que os nossos interlocutores ADIVINHEM o que queremos. "Qual é o teu telefone" é um diminuitivo para "Qual é o número do teu telefone". Os portugueses pensam de forma bem objetiva (e óbvia). Todo cuidado é pouco!
+ Certa vez li que um executivo estava em um hotel, em Portugal, e decidiu pedir uma pizza. Ele então pediu uma grande meia calabreza e meia muzzarela. O atendente falou que não havia pizza de muzzarela. "Como não?!?" gritou o brasileiro. Depois de muita briga, o brasileiro decidiu facilitar a vida do português: "Bem, amigo. Me dá então uma pizza inteira de calabreza, só que metade dela SEM calabreza". E o português respondeu: "Ok! Obrigado pela compreensão".
+ Quando você for para o Japão negociar com executivos japoneses, muito cuidado! Um executivo havia ido até lá para negociar com uma grande montadora, em uma viagem de cinco dias. Chegando lá, pretendia iniciar logo a reunião. Os japoneses quiseram fazer um tour pela cidade no primeiro dia. No segundo e terceiro dia, os japoneses mostraram todas as fábricas, passaram por todos setores de produção, mostraram os detalhes das suas empresas. No quarto dia, ofereceram um espetáculo cultural a ele. No quinto e último dia, no retorno para o aeroporto, o executivo japonês indagou o brasileiro: "Então, qual a sua proposta?". Resultado: o brasileiro, cansado e tonto com tanta coisa, acabou fazendo todas as vontades do japonês.
+ O povo alemão costuma ter origens fortes e são normalmente bastante resistente à mudanças. Em uma fábrica alimentícia no RS, um dos supervisores era alemão genuíno. Fazia todo o processo no olho, sabia exatamente a quantidade exata de cada porção. Ainda assim, de vez em quando falhava. A fábrica decidiu instalar uma máquina mais moderna, onde ele simplesmente entraria com o valor da quantidade e só precisava monitorar de tempos em tempos, se tudo estava ok. Para a surpresa da diretoria, descobriram que o alemão continuou fazendo tudo no olhômetro, dizendo que a máquina não era precisa e fazia tudo errado. A fábrica decidiu ouvir o alemão.
+ Um dos cases mais estudados no mundo é a volta por cima da Nissan, empresa japonesa comprada pela Renault, que estava indo para o buraco. Mas graças a um brasileiro, a empresa em 3 anos voltou a ser referência mundial. Uma das primeiras grandes medidas desse brasileiro foi acabar com um dos maiores paradigmas culturais do Japão: o conceito de que todos trabalham na mesma empresa por toda a vida. Para reduzir custos, foi preciso demitir milhares de japoneses e implantar uma mudança de conceito, onde a promoção não ocorreria mais por tempo de cargo, mas sim por resultados. O brasileiro (chamado Carlos Ghosn) enfrentou uma cultura milenar e, após ser visto com desconfiança (e até ódio) por parte dos japoneses, virou uma celebridade na terra do sol nascente.
+ Por fim, uma que não é sobre o mundo coorporativo, mas fala muito sobre a essência e sobre a cultura japonesa. O jogador e atual técnico da seleção Dunga, um dos primeiros brasileiros a ir jogar no incipiente futebol japonês, contou que certa vez o seu time se preparava para fazer a barreira em uma cobrança de falta do time adversário. O juiz marcou a posição da barreira e apitou a cobrança. O Dunga então começou a mandar todos da barreira avançarem, para dificultar a cobrança. E ouviu dos japoneses do próprio time: "Não! Não pode! Não pode!".
Causos de diferenças culturais existem aos montes. E isso mostra como é importante saber pelo menos um pouco em que território estamos pisando.
E você, caro leitor, conhece uma história divertida que envolve diferenças culturais? Conte para nós!
Um abraço
terça-feira, 3 de junho de 2008
SCRUM "aways visible" ou também chamado de "low-tech" :)
Uma pergunta bem interessante levantada pelo colega Ronan, na lista "SCRUM-BRASIL".
Eu sou meio contra utilizar o SCRUM com alguma ferramenta computacional. O legal do SCRUM é o fato de promover a iNteração entra as pessoas. Uma ferramenta computacional já é um passo para começar a voltar ao bom e velho método da comunicação pela internet/rede.
Se alguém quiser adotar alguma ferramenta, eu sugiro que seja apenas para você mesmo. Ou seja, crie uma planilha para fazer um tracking do andamento, levantar métricas para usar nos planejamentos, anotar lições aprendidas para posteriormente divulgar... enfim. Evite ao máximo fazer com que sua equipe tenha que diariamente acessar algum sistema para ler/entrar com alguma informação ou dado. Dependendo do local onde você trabalha, esse tipo de coisa tende a começar a ceder em menos de duas semanas.
Para a organização do seu backlog, utilize as index cards. Eu já postei um exemplo aqui, mas novamente eis uma imagem de exemplo de uma index card:
Baixe aqui
Eu utilizo exatamente esse index card. Com o tempo, vamos adequar ao que precisamos. Mas é possível manter um histórico de tudo, saber o "Definition of Done" de cada atividade e também alterar estimativas e prioridades.
Enfim. Seja bem cético quanto a usar programas para "controlar" o seu dia-a-dia no SCRUM. Normalmente as pessoas tendem a deixá-los de lado. Use uma boa e velha taskboard para criar o conceito de "Always visible" :)
Abraços
Como vocês costumam administrar os Backlogs?
Pergunto isso porque o quadro branco "armazena" apenas as tarefas da Sprint atual, certo? Mas como gerenciar as estórias pedentes e suas prioridades/estimativas?
Sei que existem ferramentas como o ScrumWorks, mas queria saber como a comunidade "costuma" de fato gerenciar isto.
Estou pensando em desenvolver essa funcionalidade no sistema da empresa.
Eu sou meio contra utilizar o SCRUM com alguma ferramenta computacional. O legal do SCRUM é o fato de promover a iNteração entra as pessoas. Uma ferramenta computacional já é um passo para começar a voltar ao bom e velho método da comunicação pela internet/rede.
Se alguém quiser adotar alguma ferramenta, eu sugiro que seja apenas para você mesmo. Ou seja, crie uma planilha para fazer um tracking do andamento, levantar métricas para usar nos planejamentos, anotar lições aprendidas para posteriormente divulgar... enfim. Evite ao máximo fazer com que sua equipe tenha que diariamente acessar algum sistema para ler/entrar com alguma informação ou dado. Dependendo do local onde você trabalha, esse tipo de coisa tende a começar a ceder em menos de duas semanas.
Para a organização do seu backlog, utilize as index cards. Eu já postei um exemplo aqui, mas novamente eis uma imagem de exemplo de uma index card:
Baixe aqui
Eu utilizo exatamente esse index card. Com o tempo, vamos adequar ao que precisamos. Mas é possível manter um histórico de tudo, saber o "Definition of Done" de cada atividade e também alterar estimativas e prioridades.
Enfim. Seja bem cético quanto a usar programas para "controlar" o seu dia-a-dia no SCRUM. Normalmente as pessoas tendem a deixá-los de lado. Use uma boa e velha taskboard para criar o conceito de "Always visible" :)
Abraços
Alinhando o planejamento estratégico com o tático
Como eu sinto falta de saber o que os diretores da empresa e os coordenadores do grupo estão pensando. É impressionante como falta comunicação na maioria das vezes.
Essa semana irei apresentar o sistema para o cliente que eu atrasei na semana passada (que gerou o email da confusão). Dai tenho que sair correndo atrás dos meus chefes para saber qual é o plano deles para o seguimento desse projeto. Continuaremos fazendo protótipos? Vamos propôr um sistema já? Vamos deixar em stand-by?
Como eu posso ir para uma reunião com o cliente sem saber o que posso "prometer"?
É complicado. Não adianta, sem um bom plano de comunicação vai ser beeeem difícil.
Essa semana irei apresentar o sistema para o cliente que eu atrasei na semana passada (que gerou o email da confusão). Dai tenho que sair correndo atrás dos meus chefes para saber qual é o plano deles para o seguimento desse projeto. Continuaremos fazendo protótipos? Vamos propôr um sistema já? Vamos deixar em stand-by?
Como eu posso ir para uma reunião com o cliente sem saber o que posso "prometer"?
É complicado. Não adianta, sem um bom plano de comunicação vai ser beeeem difícil.
segunda-feira, 2 de junho de 2008
A dura realidade de um grupo de pesquisa...
Eu já havia dito anteriormente que uma das coisas mais terríveis de gerenciar um projeto em um grupo de pesquisa é ter a disposição normalmente uma equipe composta por bolsistas nos primeiros semestres, sem experiência e tudo mais.
Porém, outra coisa que é terrível, sem duvida nenhuma, é o outro lado da moeda: encontrar boas pessoas para trabalhar e ver elas indo embora sem ter uma chance de lutar contra.
A equipe que o meu colega dirigiu, no projeto dele, era sensacional. Era formada por um desenvolvedor multiplicador (daqueles que não só faz as coisas bem, mas também influencia e treina os demais) e outros bons desenvolvedores. Todos sairam ao final do projeto para a empresa parceira do projeto (que infelizmente não é a que eu trabalho). O único restante, que dava uma baita mão para nós, vai viajar para a Austrália no fim da semana que vem.
Agora, da minha equipe, tenho três bons desenvolvedores. São tecnicamente muito bons, mas tendem a se dispersar facilmente, um dos únicos defeitos deles. Um deles, o mais "geniozinho", recebeu uma proposta para ir para uma empresa. Hoje me mandou um email querendo conversar...
Ele está com vontade de ficar, caso trabalhe com hardware (coisa que não conseguiu fazer nesse nosso projeto). Eu não sei o que responder, pois o novo projeto só será aprovado daqui um mês, mais ou menos. E não vou ser desonesto prometendo algo e fazendo ele perder uma oportunidade.
Estou sentindo que infelizmente perderei outro bom funcionário.
É a dura e triste realidade de um grupo de pesquisa. E também das micro e pequenas empresas... manter seus cérebros. Uma pena.
Porém, outra coisa que é terrível, sem duvida nenhuma, é o outro lado da moeda: encontrar boas pessoas para trabalhar e ver elas indo embora sem ter uma chance de lutar contra.
A equipe que o meu colega dirigiu, no projeto dele, era sensacional. Era formada por um desenvolvedor multiplicador (daqueles que não só faz as coisas bem, mas também influencia e treina os demais) e outros bons desenvolvedores. Todos sairam ao final do projeto para a empresa parceira do projeto (que infelizmente não é a que eu trabalho). O único restante, que dava uma baita mão para nós, vai viajar para a Austrália no fim da semana que vem.
Agora, da minha equipe, tenho três bons desenvolvedores. São tecnicamente muito bons, mas tendem a se dispersar facilmente, um dos únicos defeitos deles. Um deles, o mais "geniozinho", recebeu uma proposta para ir para uma empresa. Hoje me mandou um email querendo conversar...
Ele está com vontade de ficar, caso trabalhe com hardware (coisa que não conseguiu fazer nesse nosso projeto). Eu não sei o que responder, pois o novo projeto só será aprovado daqui um mês, mais ou menos. E não vou ser desonesto prometendo algo e fazendo ele perder uma oportunidade.
Estou sentindo que infelizmente perderei outro bom funcionário.
É a dura e triste realidade de um grupo de pesquisa. E também das micro e pequenas empresas... manter seus cérebros. Uma pena.
Assinar:
Postagens (Atom)
Postagens
