Mudando uma Pequena Empresa

Novo blog no ar!

2009-06-12T02:29:00.001-03:00

Caríssimo amigo!

Este blog não será mais atualizado. Visite o meu novo blog:

WWW.AGILEWAY.COM.BR

Aguardo você lá!

Novo blog saindo do forno

2009-04-24T19:42:00.003-03:00

Pessoal, o novo blog está saindo do forno. Está em fase de desenvolvimento.

Ficou lindão :D

O nome dele vai mudar também. Ficará bem mais "aderente" à proposta.

Agora estou nas mãos do programador :)

Aguardem...

Abraços!!

Excelente entrevista sobre RESILÊNCIA

2009-03-11T13:02:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Segundo o dicionário, a resiliência é definida como um processo da física que remete à elasticidade, poder de recuperação e resistência ao choque.

No entanto, aplicada ao RH, a ferramenta pode tornar-se uma arma em tempos de crise. Para saber mais sobre o tema, a entrevistada da semana é Cátia Venturella, psicóloga e coordenadora do MBA em Gestão de Pessoas na Unisinos. A profissional - que também é diretora da consultoria Ecovivencial - discute as melhores formas de identificar e desenvolver a competência. Confira.

O que é resiliência?

É uma característica de pessoas que reagem positivamente às mudanças do ambiente, interagindo como agentes das mesmas. A pessoa resiliente se coloca em sintonia com as coerências e incoerências dos mecanismos de mudança e se faz presente de forma propositiva.

De que forma a resiliência pode ser aplicada ao mundo corporativo?

Nas organizações, as pessoas resilientes não são aquelas que discordam, reclamam, resistem às mudanças propostas. Mas também não são aquelas que concordam com tudo que a organização altera ou propõe como diferente. Na verdade, resiliente é aquele que orienta-se pelos resultados a longo prazo, enxerga à frente. Esta característica contribui para que novos rumos sejam traçados e até permite que se corrija certos erros estratégicos em processos de mudança.

A resiliência pode ser desenvolvida? Como fazê-lo?

Claro que sim. Para desenvolver uma competência tão pessoal, é preciso investir em autoconhecimento. Conhecer a si mesmo, identificando seus pontos fortes, tornando visíveis seus pontos cegos e melhorando aspectos que estão enfraquecidos em nosso jeito de ser é o caminho para se tornar mais competente em termos de características pessoais e atitudes necessárias ao ambiente corporativo. Especificamente com a resiliência, é preciso desenvolver-se em cinco tópicos: positividade, foco, organização, pro ação e flexibilidade. Positividade ao enxergar os aspectos positivos do furacão emocional que envolve toda mudança importante. Foco para determinar seu curso de atuação. Organização para priorizar os passos a serem dados. Pro ação para tomar as rédeas das situações e ser efetivamente um agente das mudanças. E finalmente, flexibilidade para discernir o que se quer ou não mudar e conseguir lidar com as adversidades do processo.

Em tempos de crise, a resiliência torna-se mais importante no ambiente empresarial?

Não diria em tempos de crise, mas em tempos de mudanças aceleradas e significativas. A flexibilidade e a tranqüilidade que a pessoa resiliente apresenta, mesmo em meio ao eminente caos, tornam-se um diferencial no mercado de trabalho. Os próprios treinamentos proporcionados pelas organizações têm focado bastante esta característica, percebo isto pela minha experiência como consultora. Há cursos diretamente relacionados ao tema ou que contem o desenvolvimento desta competência em seu conteúdo programático, todos de caráter prioritariamente comportamental, vivencial.

O que caracteriza um profissional resiliente?

Nas organizações, é a pessoa que percebe o mundo como uma série de oportunidades, das quais se escolhe participar ou não. Sabe o que quer e gosta de desafios e imprevisibilidade. Vê a mudança como algo que pode ser difícil e adverso, ou agradável e simples, mas sempre aprende com ela. Principalmente, é um agente de mudanças.

Competitividade é sinônimo de resiliência?

Não é sinônimo propriamente dito, mas claro que ser resiliente aumenta a competitividade em relação ao mercado de trabalho, pois aceitação consciente e coerente frente a desafios são aspectos muito procurados pelas organizações.

---------------

E aí? Isso pode ser considerado uma habilidade a ser desenvolvida por todos nós? Eu acho que sim.

Novo blog

2009-03-02T23:15:00.003-03:00

Pessoal,

estou organizando uma nova versão do blog, mais colaborativa do que este. Por questões óbvias, o nome do blog também irá mudar. Estou vendo como manter o histórico de posts na nova versão, aparentemente é possível.

Então tenham a certeza de que o blog não morreu. Estou apenas trabalhando em cima da nova versão :)

Aguardem!

O gerente e a ansiedade

2009-03-02T22:43:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Muitos antropólogos costumam dizer que a ansiedade é a doença do futuro. Outros, mais realistas, afirmam que ela é a doença do presente.

Nós, profissionais de TI principalmente, passamos o dia sob estímulos de dados e informações. Temos que absorvê-los, compreendê-los, comunicá-los e geralmente tomar decisões. Quase sempre sob intensa pressão.

Isso gera ansiedade. Numas pessoas mais, noutras menos.

Ansiedade, na definição no Wikipédia é "uma característica biológica do ser humano, que antecede momentos de perigo real ou imaginário, marcada por sensações corporais desagradáveis, tais como uma sensação de vazio no estômago, coração batendo rápido, medo intenso, aperto no tórax, transpiração etc".

Quem nunca passou por essa sensação no trabalho? Se você respondeu que não, ou você está mentindo ou pior, não admite que possui mesmo que seja um grau tolerável. Algumas pessoas não sentem os efeitos no curto prazo, mas a somatização dessas angústias acabam aparecendo anos mais tarde com dores nas costas, hérnias, etc. E isso é sério.

Os gerentes e líderes são as principais vítimas deste mal, pelo simples fato de que estão no "recheio" do sanduíche organizacional. Sofre pressões do nível estratégico e do nível operacional. E precisa balancear ambos para que a empresa funcione corretamente. Não é fácil, como todos nós sabemos.

O primeiro passo para lidar e, por que não, lutar contra esse problema é encará-lo de frente. Ao assumir isso, você estará se conscientizando de que você não é imune a ele. E poderá dar o segundo passo, que é procurar entender como a ansiedade se manifesta em você. Dores no estômago? Intestino? Fígado? Costas? Cabeça? Coração? Sensação de pânico?

O terceiro passo é procurar ajuda. Muitas vezes teimamos em achar que "é só uma dorzinha passageira". E na verdade tudo é controlado pela nossa cabeça. Um psiquiatra, de preferência com especialidade na área, saberá receitar a você os medicamentos devidos. Pois sim, acredite, normalmente a ansiedade é uma questão química do nosso cérebro.

O quatro passo é procurar formas de contornar o problema. Apenas os remédios não irão resolver o problema. Você precisa se tornar forte para saber como evitar e como reagir quando o problema surgir. Saber qual o seu limite e não forçar a barra, dependendo do caso. Pessoas com ansiedade extrema, como a síndrome do pânico, podem trabalhar normalmente desde que saibam seus limites. O último passo é viver, apesar do problema, uma vez que você terá todo o apoio necessário para enfrentar a ansiedade.

Neste momento alguns leitores devem estar pensando: "Mas o que este post tem a ver?". Eu respondo: TUDO.

De nada adianta um gerente de projetos ou líder que seja um excelente técnico, mas que não tenha um equilibrio emocional ou que ao menos não esteja lutando para atingí-lo. De nada adianta você ler todo este blog e descobrir que não tem forças para encarar os desafios, pois no primeiro momento em que a bomba estourar, a sua ansiedade o deixará paralisado.

A ansiedade é um problema real e extremamente comum. Infelizmente ainda é um tabu em muitas empresas. As pessoas não comentam ou escondem. Tenha a certeza que pelo menos 70% das pessoas com as quais você trabalha, tem ansiedade num grau igual ou maior ao seu. Portanto, não deixe que isso afete a sua carreira. Conviva com a ansiedade.

E respondendo a sua pergunta (que com certeza deve estar se fazendo agora), SIM! Eu sofro de ansiedade. E estou procurando conviver com isso :)

Promoção do blog

2009-02-06T00:39:00.002-02:00

Um blog como este pode criar uma promoção para agitar os gerentes de projetos?

Aguarde algumas semanas e você verá.

Quantos lados tem uma empresa?

2009-02-05T23:33:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Responda rápido. Quantos lados tem a sua empresa?

Tempo.... quase lá... BOING!

E ai? Respondeu?

A não ser que você tenha sido óbvio ao responder "lado de fora e lado de dentro", você errou. Pois se você pensou e respondeu alguma outra coisa, você está cometendo um erro bastante comum no mundo das empresas: achar que existem lados!

Quantas vezes dentro da sua empresa, nas conversas de corredor, não escutou coisas como "aquele pessoal do comercial", "aqueles diretores" ou "aqueles programadores nefastos"? Sempre com ar pejorativo, como se fossem uma célula terrorista inimiga, pronta para arquitetar planos diabólicos contra o SEU lado.

Uma das coisas mais complexas de se mudar numa cultura de empresa, na minha opinião, é exatamente esse sentimento de que existem "lados" dentro do ambiente de trabalho. As decisões precisam ser transparentes para todos. As informações precisam iniciar numa ponta e chegar até o seu destino sem ser podada pelo AI-5. As pessoas precisam ter a noção de que seu trabalho, por mais simples que seja, está fazendo parte de um todo que é a engrenagem que move a empresa. E também que todas pessoas saibam se o cliente está ou não satisfeito com o trabalho.

Vejam, coisas simples, triviais até. E que contribuem bastante para acabar com as barreiras que formam os "lados". Porém, infelizmente nem todas as empresas agem dessa forma. Muitas por medo de que informações possam ser mal-interpretadas, outras por simplesmente acharem que tal informação não precisa chegar a todos. Portanto é lógico perceber que os lados começam a ser criados de cima pra baixo, normalmente.

E o que se pode fazer para mudar isso? Nós, como gerentes, podemos contribuir sim. Primeiramente deixando claro que nós não fazemos parte de nenhum lado. E não por estarmos em cima do muro, mas sim por sermos exatamente o meio de campo da empresa. Aqueles que são responsáveis por garantir que os patrocinadores, clientes e sócios estejam felizes e ao mesmo tempo que a equipe esteja feliz. Pois nós, mais do que ninguém, sabemos o prejuízo que se tem com essas subdivisões.

Buscar conscientizar as pessoas, seja numa conversa informal, seja com atitudes, irá contribuir bastante para começar a mudar isso. Mostrar que aquelas pessoas do comercial não são chatas porque nasceram assim: eles estão representando o cliente, dentro da empresa. Mostrar que os programadores não complicam acima do aceitável. Eles querem trabalhar de forma a garantir que o trabalho saia com qualidade. Que tal criar um breve workshop para que cada área apresente seu dia-a-dia? Ou quem sabe criar um vídeo mostrando o dia-a-dia de cada setor? Ou ser mais radical ainda, fazer uma espécie de "intercâmbio", colocando pessoas de áreas diferentes para trabalharem um dia em outro setor? São algumas sugestões que podem ser aplicadas. Mas existem dezenas de outras.

Se você, amigo gerente, percebeu já que a sua empresa é composta por lados, ajeite as mangas e comece hoje mesmo a mudar isso. Tenha a certeza que se você não for devidamente valorizado por isso, ao menos estará contribuindo para um ambiente de trabalho melhor.

Um grande abraço a todos!

Postagens ...

2009-01-21T12:59:00.002-02:00

Prezados, como é período de férias, as postagens ficaram mais escassas. Vou manter uma média de um post a cada semana, ao menos. Mas aproveite este tempo e navegue pelos posts antigos. Tem bastante coisa que você não deve ter lido e com certeza irá lhe interessar ;)

Um grande abraço

Muitos projetos

2009-01-21T12:50:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje na hora do almoço encontrei um colega do meu MBA na rua. Ele me perguntou sobre o meu trabalho e eu falei que estava bem puxado, pois estava com oito projetos. Disse que era difícil se aprofundar em alguns, o que eu considero ruim.

Ele então me disse que na empresa dele, ele está com apenas... quarenta. QUARENTA. Como uma pessoa pode gerenciar QUARENTA projetos?

Eu me pergunto as vezes o que essas empresas esperam de um gerente de projetos. Normalmente somos responsáveis por grande parte do projeto, tendo que conhecer cronograma, escopo, garantir qualidade, etc. Fazer isso em um ou dois projetos já é complexo. Imaginem QUARENTA?

O que esperar de situações assim? O gerente de projetos será apenas um "administrador", delegando praticamente tudo para suas equipes. Não vai se aprofundar em praticamente nenhum projeto, manter uma relação mais próxima ao cliente, entender as suas necessidades e garantir que o projeto satisfaça o máximo possível.

Qual seria a capacidade ideal de projetos para um gerente? E qual seria a sua?

Pensar nisso nunca é demais :)

Abraços

Agilistas-san

2009-01-06T22:46:00.005-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Cena 1:

Daniel Larusso, cansado de ser um cara que apanha de todos, procura Sr. Kesuke Miyagi. Quer aprender Karatê para se defender. O Sr. Miyagi reluta mas aceita.

Cena 2:

Daniel-san chega no primeiro dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda polir os carros. Em movimentos circulares. O dia todo.

Cena 3:

Daniel-san chega no segundo dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda pintar a cerca. De cima para baixo, com calma. O dia todo.

Cena 4:

Daniel-san chega no terceiro dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda varrer o deque de madeira. De um lado para o outro. O dia todo.

Cena 5:

Daniel-san chega no quarto dia puto da cara. Quer aprender Karatê, e não ficar pintando, polindo ou varrendo. Xinga o Sr. Miyagi e diz que é tudo uma bobagem.

Cena 6:

Sr. Miyagi o manda repetir cada um dos movimentos dos três dias. E aplica golpes de Karatê em Daniel-san. Os movimentos de polimento, pintura e varredura, são os mesmos usados na defesa dos golpes. O que parecia inútil, foi o início e a pedra fundamental para Daniel-san aprender, sem saber, Karatê.

Sim, se você percebeu esse é o filme "Karatê Kid".

A famosa cena 6, em vídeo:

Qual a analogia que podemos fazer com agile? Simples.

Quantos "agilistas-san" você conhece? Aqueles que conhecem SCRUM / XP / TDD / LEAN ou qualquer outro processo ou corrente ágil, e resolve implantá-la achando que terá resultados da noite pro dia?

Quantas vezes você já ouviu donos de empresa falarem "Agora faremos SCRUM!" e obrigarem as equipes a praticarem processos ágeis, sem que eles entendam o por quê?

Para ter sucesso com qualquer processo ágil, é preciso trabalhar com calma, ponto a ponto. "Wax on, Wax off", como o Miyagi diz no filme. Entender o processo... diagnosticar problemas... melhorar a comunicação... valorizar as pessoas... fazer sua equipe entender que mudanças vão acontecer... fazê-los perceber porque reuniões diárias, taskboards, etc são benéficas... tentar criar um projeto piloto... enfim.

Se você achar que pode simplesmente implantar agile (ou aprender Karatê) apenas lendo um livro e atropelando tudo, ou você sofrerá uma grande decepção com os processos ágeis (ou levará uma grande surra!).

Agora, toda vez que algum conhecido seu se afobar com processos ágeis, peça para ele assistir ao filme Karatê Kid. Afinal de contas, é um bom divertimento também.

Um grande abraço

2009!

2009-01-06T22:43:00.000-02:00

De forma atrasada, mas de coração:

FELIZ 2009 PARA TODOS VOCÊS!

Muita saúde, alegrias e, principalmente, bom humor!

Ouvindo as bases...

2008-12-22T21:12:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Semana passada fiz algo que eu considero muito importante para todos gerentes e líderes: ouvir as bases, ou seja, ouvir a sua própria equipe.

Como estamos finalizando um dos projetos, resolvi conversar com todos com quem tive maior contato durante esse período. E quis escutá-los sobre como eles viram os processos, a organização do projeto, a equipe e, principalmente, como eles me viram.

O feedback que eu tive foi muito bacana. Apontaram alguns problemas que eu já imaginava, mais relativos ao projeto, como por exemplo, na ânsia de entregar o meu primeiro projeto da melhor forma possível, fiz o bom e velho "gold plating" o que gerou um trabalho muito maior e dificultou a nossa vida.

Já quanto a mim, disseram que estavam gostando muito e que não tinham nenhuma crítica ou observação a fazer.

Eu deixei claro que era importante esse tipo de conversa até para que eu pudesse reduzir e melhorar as minhas deficiências e potencializar as qualidades. E que procuraria fazer essa reunião a cada período de tempo. Também reforcei que a minha idéia é sempre equalizar da melhor forma os três lados: empresa, cliente e equipe. E principalmente, deixei bem claro para eles que a cada vez que eles receberem uma tarefa, nunca apenas abaixem a cabeça e a façam. O ideal é sempre discutir o real objetivo e, se possivel, propor outras soluções. Vejam: não é uma reunião de retrospectiva, mas uma de feedback!

O interessante é escutar como as pessoas estão nos vendo, principalmente aquelas que convivem no dia-a-dia com a gente. As vezes podem surgir surpresas que nós nem havíamos nos dado conta. Sejam elas boas ou ruins.

O fato é: se você não ouvir o que a sua equipe tem para lhe dizer, você pode estará se fechando apenas no seu mundo. E deixará de perceber mais cedo coisas importantes que possam estar acontecendo.

Não tenha medo de sua equipe! Experimente amanhã mesmo: chame sua equipe e peça um feedback simples: "Como vocês estão vendo o meu trabalho? Como eu posso melhorar?".

Um abraço!

Scrum e XP direto das trincheiras

2008-12-19T23:54:00.005-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sim!! O melhor livro para se aprender SCRUM agora está em português!

Leia mais aqui.

Você pode fazer download diretamente aqui.

Aproveitem. Agora não há mais desculpa!

Mudar de empresa é difícil. De área então......

2008-12-16T23:56:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Certa vez estava ouvindo um podcast do Ricardo Viana Vargas, e ele comentou uma coisa que na hora me soou meio forçado, mas que agora vivo na prática. Ele disse que nós precisamos estar preparados não para só atender projetos de TI, ou de engenharia, ou de comunicação. Mas sim, estarmos abertos e preparados para atuar em várias áreas.

Aconteceu isso comigo, como você já sabe. Saí de uma pequena empresa de TI e fui para uma média empresa de comunicação. Apesar de ter uma veia de TI, é impressionante a diferença no dia-a-dia e no fluxo de trabalho.

A mudança de área é bacana, mas costuma nos levar a cometer erros primários... muito até por insegurança, na maioria das vezes. Uma decisão que tomávamos rapidamente, agora ficamos inseguros... pedimos opiniões...

Uma coisa que mudou radicalmente pra mim foi a forma de encarar o projeto. O meu primeiro projeto eu adotei como um filho, lógico. Quis entregar o melhor que eu podia e agradar ao máximo o cliente. Fizemos o site quase totalmente modular e orgânico. E eu me orgulhei bastante disso. Mas ao mostrar para o cliente, notei que ele não deu muita atenção. Por quê? Ora, pois para ele o mais importante naquele caso é o layout, as imagens, o texto...

Quanta diferença! Antigamente a coisa era a funcionalidade. O layout era deixado quase sempre de lado. Agora isso inverteu radicalmente! Felizmente agora já estou mais acostumado e adaptado. Inclusive me envergonhando cada dia mais das interfaces que fazíamos na outra empresa... hahaha :)

Outra coisa que tenho sentido muito é quanto as responsabilidades. Algumas coisas que antes para mim eram transparentes, agora são super importantes. E isso pesa demais no resultado final. São lições que estou tendo que aprender e assimilar o mais rápido possível, de forma a entrar realmente neste novo rítmo.

Enfim, o Ricardo Viana Vargas tinha razão. Não podemos pensar que vamos sempre viver na mesma área. Temos que estar preparados e procurar nos adaptar o quanto antes a qualquer nova realidade e desafio que teremos pela frente.

Mudar de empresa é difícil. Mudar de área é mais ainda.

Abraços!

"A nossa pressão"

2008-12-10T23:27:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

O Max Gehringer, em um podcast, comenta sobre três aspectos das empresas. A nossa missão, que mostra o que a empresa se compromete em oferecer; a nossa visão, que mostra o que a empresa pretende ser num prazo de tempo... e a nossa pressão. A nossa pressão é exatamente aquilo que faz a empresa se mover para atingir as duas anteriores.

Vou usar esse termo "a nossa pressão" para este rápido post, pois ele sintetiza bem a importância do nível tático dentro da empresa, ou seja, o nível gerencial.

Vejam minha situação: estou com um projeto que foi o primeiro que eu recebi. Logicamente, estou tratando este projeto com toda atenção e disposição que eu posso ter. O cliente não é estratégico para a empresa, mas para mim é: é o meu primeiro projeto. E eu quero que ele dê certo.

Acontece que ao mesmo tempo que é o meu primeiro projeto e que eu estou bastante dedicado, ainda tenho a que lidar com a minha curva de aprendizado. Estou numa área nova, estou cometendo alguns erros e acertos e, principalmente, buscando assimilar e aprender com tudo isso. E este projeto possui uma deadline fixa e imutável.

O projeto foi sendo conduzido e organizado de uma forma satisfatória. O problema é que temos muitos projetos e menos colaboradores do que poderíamos, teoricamente. E acho que essa equação está certa por questões administrativas, que não vem ao caso.

Pois bem, o projeto tem o prazo de entrega para segunda-feira. Ainda faltam algumas pendências do projeto e ele precisa ser encerrado no mais tardar na sexta pela manhã. Só que eu estou sem pessoas para auxiliarem no desenvolvimento. E tenho o cliente desesperado do outro lado.

A nossa pressão, neste caso, está partindo do cliente, da equipe, da empresa e de mim! Ao mesmo tempo, é preciso lidar com cada uma dessas partes de uma forma diferente, pois preciso satisfazer a todas elas.

O que eu quero concluir com tudo isso?

O nível tático das empresas, graças à "nossa pressão", se tornou nada mais, nada menos, do que a grande SOMATIZADORA organizacional. Nós apanhamos (no bom sentido) de todos os lados e não podemos transferir a paulada adiante... temos que amortecer, filtrar e repassá-la de forma mais... carinhosa.

Eu começo a achar que os livros de auto-ajuda são feitos para gerentes... nunca para a população do nível estratégico e operacional :)

Não entenda mal. Este é apenas um post "motivacional" para todos os gerentes! :)

Não, sério. Eu estava conversando com amigos e chegamos a essa conclusão... quis apenas externar aos meus leitores. Fica como um incentivo ao auto-conhecimento.

Um grande abraço

Why so serious?

2008-12-08T08:20:00.005-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

"Why so serious?"

Essa talvez tenha sido a frase do ano. Para quem não sabe, é uma das frases famosas do filme do Batman, pronunciada pelo Coringa.

Essa frase pode ser aplicada no nosso dia-a-dia de trabalho. Why so serious? Por que nós, gerentes, temos que ser tão formais ou frios com nossos subordinados?

Eu acredito que um bom ambiente de trabalho se inicia pela postura dos líderes ou, em alguns casos, chefes. Se você quer um ambiente descontraído é primordial que os líderes tenham uma postura mais descontraída. Um ambiente mais sério, pede líderes mais sérios. Isso depende de cada empresa e, principalmente, da cultura delas.

Onde eu trabalho temos a visão descontraída. Temos eventos descontraídos, temos líderes (gerentes e diretores) descontraídos, temos colaboradores descontraídos. E funciona! Salvo um ou outro caso de "esquecimento" da diferença entre descontração e profissionalismo (quando se confundem), o que é bastante raro.

Escrevo este post pois me deparo, de vez em quando, com pessoas em cargos de liderança e que acham que para ganhar o respeito de seus subordinados precisam ser (ou parecer) sérios, formais... as vezes até mesmo bravos (!). E então o ambiente de trabalho, que já é estressante por si só, acaba tendo mais uma carga de energia desnecessária, levando à insatisfação de todos os envolvidos. São pessoas que parecem ainda não entender a diferença entre líderes e chefes.

Você não sabe, também? Então vou citar quatro.

O líder delega. O chefe manda.

O líder escuta. O chefe fala.

O líder negocia. O chefe tem poder.

O líder inspira. O chefe amedronta.

O caso é que normalmente as pessoas seguem os líderes por acreditarem naquilo que ele acredita. Peguem como exemplo o caso de líder mais famoso da história: Jesus. Por acaso ele mandou que todos o seguissem, senão Deus demitiria os infiéis? :)

O líder precisa agir dessa forma sempre. Mas antes de tudo precisa de fato acreditar no que está fazendo, caso contrário ninguém mais o fará. Ser positivo é outra característica essencial. Mas atenção: ser positivo é diferente de ser otimista.

E é neste ponto que entra a frase "why so serious?". Se precisamos ser positivos, se precisamos garantir que nossos colaboradores estejam satisfeitos, por que temos que ser tão sérios e formais? Por que não causar alguns fatos novos e inesperados durante o dia-a-dia, por idéia nossa e sem visar notoriedade, mas sim o bem estar de todos?

Nesta última sexta-feira, por exemplo, eu planejei chegar mais cedo ao trabalho. Comprei 6 caixas de chocolate Bis e deixei dois tabletes na mesa de cada pessoa da empresa. Sem dizer nada para ninguém (apenas pedindo aos que já estavam no local que não dissessem que havia sido eu). O resultado foi muito bacana. Todos ficaram curiosos e especulando quem havia feito aquilo. Foram alguns reais que eu gastei do meu bolso, mas que gerou um resultado que valeu muitíssimo a pena. Não pretendo revelar que sou eu. Mas pretendo repetir isso periodicamente. Apenas pelo prazer de causar uma sensação diferente no ambiente de trabalho.

A minha empresa faz isso volta-e-meia. E como isso influencia no ambiente. Tanto é que as pessoas votaram como sendo uma das coisas que mais gostam no trabalho, exatamente o ambiente de trabalho. Isso não tem preço.

Mas a pergunta final fica para você: why so serious? Você já fez ou fará algo diferente pela sua equipe, apenas para vê-los felizes e estimulados?

Eu garanto, vale a pena! Para ambas as partes.

Uma ótima semana.

Comunicação interna - um velho problema

2008-12-02T20:49:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Ontem na Zero Hora, jornal de maior circulação aqui no RS, havia uma matéria bastante interessante na seção de Empregos. Falava sobre alguns dos grandes problemas que assolam a vida dos empresários. Segundo a pesquisa realizada, a comunicação interna continua sendo um dos grandes problemas das empresas.

Eu tenho conversado com alguns colegas gerentes, seja pelas listas, seja ao vivo, e esse sempre é um dos assuntos que acabamos comentando: como garantir a informação? Como corrigir isto? Como criar contingências, se necessário? Até que ponto devemos explicar e até que ponto devemos apenas citar?

Essa é uma discussão que depende de vários pontos de vista e depende principalmente da (adivinhem), cultura da empresa. Existem empresas onde a informalidade funciona muito bem. Outras, a formalidade excessivamente burocrática também funciona. Eu acho que, como em tudo na vida, o meio-termo é sempre a melhor opção.

A informalidade é excelente. É aquele bate-papo rápido, aquele pedido de tarefa pelo chat ou ao vivo, é o uso de um taskboard simples... por outro lado, a chance de que essa informação se perca é muito grande.

A formalidade é o oposto. São formulários, memorandos, intranet, papéis e papéis. As informações seguem um fluxo rígido e isso garante que ela raramente se perca. Existem várias pessoas que devem aprovar ou desaprovar algo. Há templates para tudo, que nem sempre são preenchidos, diga-se de passagem. Essa garantia de informação, por outro lado, leva a uma extrema falta de agilidade para resolver assuntos críticos.

Porém, eu tenho uma opinião formada sobre isso tudo. Muito se fala em "a culpa é da comunicação interna" como se ela fosse alguma entidade da empresa, que está lá só para atrapalhar. Quantos empresários será que param e analisam: "Ok, falhamos na comunicação neste projeto/tarefa/etc. Como isso aconteceu?" e dai pode-se usar desde o bom e velho diagrama de causa-efeito até um simples mind-map. Ir mapeando o fluxo da informação e ver onde foi o ponto de falha. Descobrir porque falhou. E buscar trabalhar para mitigar este tipo de problema das próximas vezes. Mas ao que parece é mais fácil culpar a entidade fantasma "comunicação interna".

Qual a relação disso com o Agile? Ora, um dos pontos principais do agile é pensar em melhoria contínua. É parar durante um momento, analisar o que foi feito e discutir como podemos melhorar, onde erramos e onde acertamos. E duvido que a grande maioria das empresas que acusam "comunicação interna" como problema, realmente fazem isso.

Para algumas empresas, porém, fazer uma retrospectiva é perder tempo e dinheiro. Será que é mesmo? Tirem suas conclusões. :)

Abraços

Tédio, tédio...

2008-12-01T20:34:00.004-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

É impressionante como quando fazemos o que gostamos, ficar em casa durante a semana é sinônimo de tédio.

Hoje precisei ir no oftalmologista. Estava com um problema nos olhos e pensei que poderia ser algo mais sério. Como das outras vezes, achava que só a manhã de folga seria o suficiente. Porém, acabaram usando dois colírios em mim (um para dilatar a pupila e outro que eu não sei o que era, mas ardeu a manhã toda) e o meu planejamento acabou indo por água abaixo. Fui recomendado a repousar o dia todo.

A primeira sensação é de "Oba!". Daí cheguei em casa (não conseguia abrir os olhos devido a claridade) e deitei para dormir. Lá pelas 13h acordei, pronto para ir pro trabalho. Sò que percebi que ainda não conseguia ir pra luz...

Então acabei ficando em casa. A contragosto. Sabia que havia muita coisa para fazer no trabalho, mas ainda assim eu não poderia ficar na frente do computador também. Peguei algumas coisas para ler, mas ainda assim o tédio falou mais alto.

Quando entramos em um rítmo como é no meu trabalho e, principalmente, quando gostamos do que estamos fazendo, nós acabamos não nos sentindo bem ficando em casa "descansando". O descanso vira tédio. Eu acabei me sentindo meio inútil!

Isso me fez lembrar de uma frase que eu achei sensacional do Max Gehringer e que tem tudo a ver com essa situação. Era mais ou menos assim:

Como você sabe se está gostando do seu trabalho? A diferença entre um e outro está no seu pensamento ao olhar o relógio, no trabalho, e ver que são 18h. Se você pensar "Puxa vida, já são 18h??" você está bastante satisfeito com seu trabalho. Se você pensar: "Oba! Hora de ir!" você provavelmente está encarando o trabalho como obrigação. A sensação temporal é inversamente proporcional à sua satisfação e motivação no trabalho.

Eu confesso que nunca imaginei que fosse trabalhar 9-10 horas por dia, algumas vezes, e nem me preocupar com isto. E exatamente por isso que tirar uma folga forçada e ficar em casa, o dia todo, pasmem, se tornou enfadonho para mim.

E vocês? Já tiveram sensação parecida?

Um abraço

A geração que veio para ficar

2008-11-27T22:41:00.004-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Existem dezenas e dezenas de revistas que abordam o tema da geração Y, a geração de pessoas que está entrando no mercado, desde o início dos anos 2000.

São jovens inquietos, ansiosos, tidos como incapazes de se aprofundarem em assuntos, mas que desenvolveram uma forma totalmente diferente de lidar com problemas e com o dia-a-dia no trabalho.

Nas minhas duas empresas, a antiga e atual, eu tive a oportunidade de trabalhar com essas pessoas e pude notar algumas coisas que gostaria de citar aqui. Só esclarecendo que eu me considero da geração X/Y, ou seja, posso me considerar parte Y e parte X, pois nasci em 1980 a época em que dizem que a geração Y iniciou.

1) A geração Y é ansiosa, sim! É impressionante que, seja num ambiente competitivo (atual) ou num ambiente de menos competitivo (universidade) as pessoas dessa geração são muito ansiosas. Ansiosas por resultados imediatos, ansiosas para pensar, ansiosas para planejar... isso normalmente tende a problemas comuns, como a famosa programação de sistemas via "tentativa e erro" ao invés de parar por alguns minutos e esboçar uma estrutura do que será desenvolvido. Pensar faz bem. Aliás, essa ansiedade a flor da pele me faz pensar que a geração Y tenderá a sofrer de problemas como crise do pânico e ansiedade com uma frequência muito maior. Observem.

2) A geração Y funciona de forma multi-tarefa, e funciona bem! Não adianta, meus amigos. Insistir para uma pessoa dessa geração fazer uma coisa de cada vez é pedir para ter uma pessoa infeliz e improdutiva. Eu me considero até certo ponto um tanto multi-tarefas, mas ainda prefiro tentar me focar em algo. A geração Y consegue falar por mensagem instantânea, ler um texto na internet, ver um vídeo no Youtube e desenvolver um programa AO MESMO TEMPO. E, pasmem: o fazem geralmente com grande qualidade. Já me deparei com desenvolvedores, no meu antigo trabalho, que eu achava que haviam passado o dia inteiro na internet fazendo bobagens, para no final do dia eles me apresentarem o resultado das suas tarefas prontas... e excelentes!

3) A geração Y se motiva e desmotiva com uma velocidade muito maior do que a normal. E é por isso que a grande maioria das empresas está repensando seu planejamento de RH, de forma a garantir que chefes passem a valorizar os bons trabalhos e a corrigir rumos, sem ser rudes demais. Por incrível que pareça, já percebi que a grande maioria das pessoas da geração Y preferem receber um feedback (mesmo que negativo) do que não receber nenhum estímulo.

4) Dinheiro não é tudo para a geração Y. Esse é um dos grandes paradigmas que estão sendo quebrados com essa geração: a visualização de que esses jovens preferem trabalhar em locais onde se sintam valorizados e motivados, do que em locais onde apenas ganhem mais... mas não tenham a valorização que acham que merecem. E aí vem a grande questão: muitos ACHAM que merecem. Neste caso, leia o item 3!

5) A geração Y entra de sola para mudar. Muito devido à ansiedade, os jovens costumam ser bastante inquietos quando a mudanças. Este é um dos principais pontos de conflitos com as demais gerações e é aqui que nós, gerentes e gestores, temos que trabalhar muito bem: ambas as gerações se contrabalançam assim. De um lado, aqueles que normalmente acham que o continuísmo é a melhor solução, e do outro lado, aqueles que acham que a mudança é a solução. Os conflitos e discussões, se bem tratados, levarão a avaliação de diversas situações por ângulos não pensados antes.

Por fim, como tudo na vida, lembre-se: existem os bons e os maus exemplos. A geração Y, com pessoas incapazes, tende a produzir resultados muito ruins... talvez até mais do que com outras gerações. Por outro lado, pessoas responsáveis e tecnicamente capazes serão excelentes exemplares para sua empresa.

Cabe a você conseguir escolher as pessoas certas. Mas tenha a certeza: a geração Y veio para ficar. Jogue conforme as regras do jogo e não contra elas.

Um forte abraço!

Cadê as mensagens do dia-a-dia?

2008-11-24T20:21:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal,

como vocês devem ter notado, não tenho mais colocado mensagens do dia-a-dia da empresa.

O motivo alguns devem ter imaginado: a empresa fez uma solicitação para que eu não fizesse isso. Até por alguns motivos justos, já que estou agora em um mercado bastante competitivo (mídia). Então poderiam surgir algumas coisas estratégicas.

Eles se colocaram a disposição para autorizar alguns posts, quando eu achar interessante. Pretendo então ainda postar algumas coisas a respeito... só que como dependerá de aprovação, e o pessoal tem um dia bastante corrido, não cabe eu fazer frequentemente isso.

Sei que o blog perde um pouco da sua mágica de anteriormente, mas podem deixar que sempre que eu puder, farei esse tipo de postagem que já se tornou típico :)

Um abraço!

Scrum vs. cultura da empresa

2008-11-24T19:55:00.005-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje numa lista saiu este post do Rodrigo Lima. Achei bem pertinente e selecionei algumas respostas.

Pessoal,

Eu trabalhei um tempo atrás com Scrum, tenho um conhecimento prático grande, leio bastantes, etc. Atualmente estou num empresa que tem um forma de gerenciamento totalmente "torta".

Tem um projeto rolando, começou em setembro e com prazo pro final de dezembro. Pelo que eu to vendo o projeto está caminhando pro fracasso, a empresa tem pessoas muito boas tecnicamente, mas não tem um time de desenvolvimento. É um projeto em que a pressão por resultado está grande, cliente cobrando, pressionando, etc.

Queria saber dos mais experientes da lista se é uma boa oportunidade pra iniciar com scrum na empresa. Tenho medo que se no final der errado, a culpa seja colocada no scrum e não de tudo de errado que aconteceu no projeto anteriormente.

O que falo de dar errado é, não conseguir entregar as coisas nos prazos que já estão acordados e não podem ser redefinidos.

Qual a opinião de vocês em relação a isso?

Este tipo de mensagem é bastante recorrente nas listas. As respostas costumam ser praticamente as mesmas.

"Faça isso! Faça aquilo! Não faça isso!"

Mas uma pessoa (Fabiano Milani) postou uma mensagem que realmente trata da realidade nua e crua:

Bom, gostaria de dar a minha opiniao sobre o assunto, e deixando claro que é apenas a minha opinião e não que eu tomo ela como verdade, li todos os post do mesmo e vou fazer um comentário a respeito dos comentários.

Primeiramente gostaria de lembrar 2 pontos extremamente importantes :
1) Não podemos esquecer do fator principal que é a CULTURA DA EMPRESA, e isso meu amigo Rodrigo Lima, você melhor que ninguém que vivencia o dia a dia da empresa pode analisar e ver a real possibilidade ;
2) Levando em consideração a CULTURA da empresa podemos dizer que, não há a menor chance de funcionar a implantação na sua empresa se você tentar implantar Scrum da mesma forma que eu fiz na minha, ou o Wescley, Raony, Kerber fizeram na deles, podemos pegar algumas dicas e como cada projeto é um projeto, cada implantação do Scrum será uma também;

Infelizmente, por mais que todos nós fiquemos felizes em ajudar, temos que ter a convicção de que assim como cada projeto é um projeto, cada empresa é uma empresa. Parecidas, mas nunca iguais.

Eu tive recentemente um problema de falta de comunicação na minha empresa atual, onde todos querem implantar métodos ágeis, mas ao mesmo tempo tem algum receio de seguir em frente. E apesar de eu tentar demonstrar que a mudança seria gradual, por algum motivo demonstrei que queria fazer a mudança de forma "radical".

O que eu estou fazendo então? Por acreditar nos métodos ágeis estou buscando exercitar as práticas do agile antes de mais nada: valorizar as pessoas e a comunicação (embora já tenha ocorrido alguns problemas de comunicação - alguns até mesmo meus), focar em entregar partes do sistema funcionando em iterações, tentar a colaboração com o cliente e reagir às mudanças, ao invés de achar que tudo é imutável. E estou com a plena consciência de que estou aprendendo diariamente. Procuro tentar aprender algo de cada erro e acerto, mesmo que ainda não seja um hábito.

Tenho tido bons resultados até o momento. Tivemos um pequeno atraso de dois dias em um dos projetos devido a pessoa que está o tocando ser nova na empresa. E mesmo assim foi excelente para ele aprender o framework já do começo ao fim, e de forma iterativa... ao invés de fazer TODO site.

É importante perceber que para começar a usar o SCRUM nós temos duas maneiras de iniciar:

a) Tentando praticá-lo com a base, ou seja, com os desenvolvedores do projeto.
b) Tentando vender a idéia para nossos chefes.

Ambos os casos tem vantagens e desvantagens. Mas dependendo da cultura da empresa, um será mais benéfico do que o outro.

Então a minha sugestão é simples: avalie BEM a cultura da sua empresa. Sua equipe de desenvolvimento é resistente? Tente a abordagem com seus chefes ou busque aliados estratégicos. Seus chefes são tradicionais? Tente a abordagem com sua equipe.

Sua equipe é resistente e seu chefe é tradicional? Bom... daí você tem duas outras opções. Chutar o balde e tentar pisar nos calos das pessoas da empresa, mostrando como o agile pode ajudar (neste caso, vale muito a pena ter dados concretos, como valores) ou... sair da empresa. Mas essa última opção, sabemos que não é tão simples. Porém, sabemos que também você encontrará com certeza um mercado de empresas "ágeis" que vão recebê-lo de braços abertos.

Ultimo lembrete: lembre-se que a cultura da empresa não é aquilo que ela FALA que faz. Mas sim aquilo que ela REALMENTE É.

Dinâmica de aviões - PUCRS 2008/2 (com fotos e vídeos!)

2008-11-18T21:22:00.008-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Como eu havia dito, no último dia 11/11 realizei novamente a convite do prof. Rafael Prikladinicki a dinâmica dos aviões em uma turma de gerenciamento de projetos da graduação da PUCRS (Sistemas de Informação).

Essa foi uma das melhores turmas que eu ministrei a dinâmica: todos, sem exceção, demonstraram enorme interesse não só na dinâmica, mas nos resultados e discussões que fizemos após. O fato é que a aula acaba as 22h30, mas eram 22h35 e eu terminava de falar e ainda TODOS estavam em sala de aula. Este é o melhor feedback que uma turma pode dar.

Se você não conhece a dinâmica, clique aqui.

Desta vez, por lição aprendida, não utilizei os cartões para definir os papéis. Isto pois quando a turma é muito grande, temos alguns problemas com um lendo o cartão do outro ou então um não se segurando e falando o que tem que fazer. Ao invés disso, o Rafael chamou um de cada equipe, discretamente, e passou a idéia desta pessoa ser o gargalo do time.

Pela primeira vez desde que comecei a aplicar a dinâmica, as TRÊS equipes produziram o protótipo bem próximo da realidade, mas claro, sempre esquecendo de alguns detalhes "pega-ratão" ;)

E felizmente, todos os erros de estimativas iniciais e as correções posteriores, ocorreram de forma ideal. Uma equipe falou que produziria muito a mais da sua capacidade (por não conhecer seu limite) e quando percebeu que não entregaria isso, reduziu a estimativa... mas nem por isso deixou de tentar superar este limite posteriormente. Ou seja, aplicaram exatamente o conceito do PDCA. Em todas as equipes o resultado foi similar, o que demonstrou que os três grupos estavam bastante maduros em relação a este ponto central da dinâmica.

E o gargalo? Ahh o gargalo. Os três gargalos das três equipes foram perfeitos. E mais perfeitos ainda foram os demais integrantes da equipe (e Scrum Master) que perceberam o gargalo e reduziram o trabalho neles. É essa a intenção: fazer a equipe perceber o problema e superá-lo de alguma forma.

Enfim, a dinâmica foi uma das melhores, na minha opinião. Os principais eventos da dinâmica para causar uma bela discussão no final do processo, aconteceram. E graças a ele eu senti que os principios do agile foram bem assimilados e bem praticados. Tomara que futuramente eu pegue turmas no mesmo nível ou, se der sorte, melhor do que esta.

Abaixo, curta algumas fotos e um vídeo desta dinâmica.

A Scrum Master corre contra atrás de matéria prima para atingir a meta da equipe.

O Scrum Master dá uma discreta conferida na equipe adversária.

Linha de produção em pleno vapor. Um membro do time fica de pé sendo elemento móvel.

Linha de produção em ação.

Vista geral da sala. Três equipes.

Apresentação dos protótipos iniciais (com pouquíssimo escopo). O momento mais divertido.

Adivinhem quem é o gargalo deste time? hehe

Reunião de replanejamento de processo.

Apesar de tudo, essa foi a equipe vencedora! Não parece... mas se puxaram! :)

Planilha com as estimativas iniciais e o previsto/realizado de cada equipe, por sprint.

Aviões prontos para serem avaliados por mim ao final do sprint.

Os vídeos!

Português

2008-11-15T01:10:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal, eu normalmente não releio as mensagens quando eu escrevo. Deveria fazer, eu sei, mas não faço. Por quê? Pois acredito que assim elas perdem um pouco da naturalidade com que escrevo e com que eu guio este blog. A idéia dos posts é exatamente mostrar como o dia-a-dia de um gerente é essencialmente igual para todos: desafios, conflitos, lições aprendidas e ensinadas...

Agora a pouco eu reli um post meu e acabei mudando diversas palavras por encontrar erros de português. E acabei perdendo um bom tempo corrigindo e mudando até o sentido de algumas frases. Percebi então que estava matando um pouco da característica coloquial do blog.

Portanto, peço que vocês não me crucifiquem caso encontrarem um erro de português, até porque nossa gramática já é bastante chata ;)

Só quis postar ESTA mensagem para deixar claro isso hehe

Um abraço!

Colaboração do cliente = feedback mais cedo!

2008-11-15T00:55:00.004-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje eu tive uma prova de como é importante fazer o possível para o cliente participar o mais cedo possível de qualquer decisão e qualquer desenvolvimento de sistemas.

Estávamos elaborando um website para uma empresa. Na reunião inicial, eles nos passaram diversas informações e referências de sites que poderíamos nos basear.

Fizemos o protótipo (ou seja, apenas o esqueleto do site) baseado nas sugestões deles. Foram duas semanas desenvolvendo este protótipo, que estava bem embasado. Só que quando apresentamos ao cliente, ele demonstrou que não era aquilo que estava esperando. E então nos deu diversas outras informações adicionais (inclusive com OUTROS sites de referência). Em suma: o protótipo era totalmente inválido.

Daí vem dois pontos de vista: o protótipo foi perda de tempo ou ajudou a colocar os pingos nos i's?

Eu acredito que o protótipo foi excelente. Pois possibilitou apresentar uma prova ao cliente para ele visualizar o que estávamos propondo. E com isso visual, ele conseguiu ver que estávamos seguindo uma outra linha diferente do que eles queriam. E corrigiu nossa rota.

Foram duas semanas de trabalho perdidos. Porém, se não tivéssemos este ponto de interação com o cliente, poderiam ter sido 1 mês ou até mais.

Como existiam dúvidas, talvez devessemos ter feito essa interação bem mais cedo, assim que tivéssemos a primeira tela do protótipo. Só ali já teríamos um excelente feedback que poderia ter salvado vários dias de trabalho perdido. Essa lição que eu aprendi hoje, pretendo aplicar na medida do possível nos meus projetos seguintes.

Vejam, estou falando de duas semanas. Isso pode ser considerado cedo. Eu já participei de um projeto em outra empresa que perdemos nada menos do que SEIS MESES de trabalho, por estarmos totalmente ilhados em relação ao cliente. E o escopo havia mudado totalmente... e não nos informaram.

Quando o agile fala em "Colaboração do cliente é mais importante do que negociar contrato" é exatamente isso que quer dizer: possibilitar um feedback mais cedo para corrigir os rumos o quanto antes. E isso pode ser aplicado em qualquer tipo de projeto, seja agile, seja waterfall, seja o que for.

Um grande abraço e bom final de semana a todos.

O desafio do agile

2008-11-13T07:39:00.005-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Atualmente estou tendo pouco tempo para participar mais ativamente das listas. Porém, encontrei este tópico e achei muito interessante. Uma colega da lista teve sérios problemas em implantar o SCRUM em sua empresa. Por quê? Resistência ferrenha dos seus colegas mais antigos.

Este é um dos maiores desafios do agile: mudar a cultura das pessoas. E não pensem que é fácil. A mensagem da Lívia e as respostas dos colegas que se sucedem retratam bem essa situação:

Olá pessoal,

Já aviso que é um post negativo e triste... :(

Tentei implantar scrum onde trabalho. Após muitas palestras, leituras de livros e listas de discussão, tínhamos uma equipe motivada a usar Scrum.
Mas acho que fomos vencidos pela outra equipe, os seres que já estavam aqui antes de nós: os analistas "experientes".

Não nos deram a chance de testar, boicotaram nossas reuniões diárias, ignoraram o sprint backlog, pensaram em fazer um sistema muito além do escopo definido pelo usuário, não estudaram a metodologia e, para melhorar, fecham-se a coisas novas.

E agora estamos aqui. Após 1 mês e meio de trabalho, tínhamos planejado e estimado uma tarefa simples de criação de um cadastro, mas nem terminamos a modelagem. 1 mês e meio para realizar uma modelagem... de um cadastro...

Depois de tanto ponto negativo, pergunto-lhes: O que me resta? Sentar e chorar?

Att,
Lívia. Triste. Muito triste.

--
Lívia Silva Santos

Resposta do Antônio Carlos Zegunis Filho:

Olá, Livia!

Acho que podemos fazer algumas ponderações e quem sabe te oferecer alguma alternativa.

De qual nível da empresa partiu a idéia de utilizar Scrum? Foi do pessoal da área operacional (desenvolvedores, analistas, etc)?

Se sim, as áreas interessadas em $$$ (tática e estratégica) ficaram sabendo do objetivo da troca de metodologia? Acho válido que esse tipo de movimento parta do pessoal operacional, mas é importantissimo que quem manda na conta bancária da empresa não fique de fora, pois a idéia é que esses caras obtenham a maior parte dos benefícios oferecidos pelo Scrum que é o foco em
ROI.

Talvez uma alternativa que você tenha é em caso do pessoal da grana não estar sabendo desse tipo de movimento, preparar um pequeno estudo e fazer uma apresentação que mostre quanto $$$ potencialmente pode ser economizado com essa estratégia nova.

Uma vez que esses caras estejam convencidos e você tenha alguma liberdade pra tocar pra frente o Scrum ai você pode tentar ver se o pessoal das antigas se adapta a nova forma de trabalho ou então trocar cada um que não se adaptar.

Agora...se o pessoal que pensa em $$$ ficou sabendo e mesmo assim a coisa foi pro brejo das duas uma: ou vocês acabaram pisando na bola em um determinado ponto (talvez conversando com a gestão isso seja esclarecido) ou então o pessoal não quer economizar $$$ e sua melhor opção é de fato procurar outro lugar pra trabalhar...

Nem todas as empresas estão preparadas pra esse tipo de mudança, mesmo que só traga melhorias.

Att.,
Antonio Carlos Zegunis Filho

Resposta do Wescley Costa:

Oi Lívia... não acho que seja o momento de sentar e chorar... mas sim de repensar, reorganizar e tentar novamente, porém, da forma certa.

Faz um tempo que venho planejando usar Scrum onde trabalho, mas devido ao que aconteceu com vc, e vários artigos, pdfs, e etc que li por aí, aprendi que existe o momento e lugar certo para se fazer isso.

Na minha opinião, oq aconteceu com vc é normal, vc pode ter se precipitado, na ansiedade de começar logo não esperou o momento ideal, e nisso os tradicionais(analistas experientes) se aproveitaram da situação para derrubar sua iniciativa, e talvez o objetivo deles foi alcançado
né, pois vc já pensa em sentar e chorar, ou seja, desistir.

Quer um conselho? não dê esse gostinho a eles... analise melhor as coisas na sua empresa, molde as coisas pouco a pouco e na hora certa, tente novamente... vá incentivando todos aí que será
melhor para a empresa usar Scrum e quando todos estiverem de acordo, comece...

ou então, consiga montar uma equipe onde todos estejam realmente interessados em adotar as práticas ágeis... oq é a melhor opção. E relaxa... raramente alguem consegue o sucesso na primeira tentativa!

Att,
Wescley Costa

Resposta do Adail Retamal:

Lívia,

Enquanto não estivermos preparados para explicar, claramente:
* Por que mudar?
* O que mudar?
* Para o que mudar?
* Como causar a mudança?

não conseguiremos superar as várias camadas de resistência à mudança.

Tenho usado a TOC (Teoria das Restrições) justamente para me auxiliar nesse processo de convencimento e de transição, pois as empresas estão fartas de mudanças que não necessariamente se traduzem em melhorias. Essa resistência à mudança tem seus motivos... As pessoas não são idiotas (ok, algumas nos levam a pensar que sim)...

Veja um pouco aqui: www.heptagon.com.br/toc

Se puder ajudar em algo, pode me procurar...

Heptabraço,

Adail Muniz Retamal

Resposta do Manoel Pimentel:

Olá Lívia,

Na verdade isso é muito comum (muito mesmo), então talvez seja o caso de você rever a estratégia e tudo aquilo que os colegas da comunidade já falaram nesse tópico.

Mas, permita lhe dar só duas sugestões:

1) Leia o livro: O livro "A quinta disciplina" de Peter Senge, que além de você ver que "Quando mais você empurra, mais o sistema empurra de volta", você verá que talvez sua empresa tenha um sério problema de aprendizagem e que precisa ser resolvido, através de injeções à questões que vão além da proposta do Scrum.

2) E também é importante que você faça as seguintes perguntas:
- Por quê implantar Scrum nessa empresa?
- Existem algum problema que justifique usar Scrum nela?
- E outra, essa empresa, merece usar Scrum (eheheh)???

Grato,
Manoel Pimentel

Então a Lívia se revitalizou um pouco e explicou melhor a sua situação:

Olá pessoal,

Nossa, fiquei mais animada depois das mensagens.

Vou tentar explicar um pouco mais a minha situação. Trabalho em um hospital de clínicas de uma universidade estadual...

Situação atual (que queremos reverter): Os analistas desenvolvem aplicações pro hospital em cobol e db2, usando mainframe. Cada um é dono de um sistema, e todos torcem para ninguém sair de férias. Quando alguém sai, o sistema fica literalmente parado por 1 mês pois ninguém mais quer colocar a mão. Existem ilhas de conhecimento, não há cooperação. Não há o conceito de equipe. Ninguém gosta de expor o próprio código.

Porém, a universidade quis mudar a plataforma de desenvolvimento e escolheu java por N motivos. O primeiro desafio foi informar a mudança. Houve um choque! Passado o choque, fizeram cursos. Mais de um ano depois, ninguém desenvolveu nada na tecnologia nova por não conseguir, não entender e não ter apoio da diretoria da informática. Depois do desastre, começaram a contratar uma equipe para trabalhar com java. Eu fui a segunda pessoa a ser contratada no ano passado. A equipe já conta com 4 analistas e 1 programador novos.

A universidade também tentou utilizar o RUP, mas parece que não deu muito certo. Usaram o RUP para justificar as falhas. Por exemplo: "Fulano, por que você não perguntou isso para o cliente?"... "Ah, porque o RUP não fala que eu tenho que fazer isso!"

O problema: Unir essas duas equipes para trabalharem em projetos novos. Quando nós soubemos como eles trabalhavam, não achamos legal continuar nesse esquema. Além disso, há outro agravante: muitos analistas estão para aposentar em até 5 anos. Ou seja, o conhecimento deles tem que ser passado aos poucos para os outros. A diretoria de informática ainda não tinha pensado nisso. Ano passado, eu e outro analista novo fomos ao Java Brasil e voltamos cheios de idéias. Scrum e XP nos trouxeram um pouco de esperança por alguns motivos, tais como:

-trazer de volta o trabalho em "equipe", acabando assim com as ilhas de conhecimento (pensamos muito na programação em par e em como isso poderia nos ajudar);
-conseguir aumentar nossa produção, já que a equipe antiga demorava até 4 meses apenas levantando requisitos (e para variar, quando entregavam o produto, muito tempo depois, muita coisa tinha mudado e eles faziam os clientes aceitaram do jeito errado mesmo por medo de fazer alterações);
-melhorar o gerenciamento e fazer a diretoria do hospital entender que mesmo que trabalhemos em um órgão público, há SIM gastos e custos;
-melhorar a integração dos novos com os que já trabalhavam aqui para disseminar o conhecimento de java e para nós, os novos, aprendermos as regras do negócio que só eles sabiam...

Explicamos para a diretoria de informática, que comprou a idéia. Chegou inclusive a pagar um treinamento para dois analistas.

O problema que eu já apontei e entendi depois de ler alguns posts: realmente, houve imposição da utilização dessa metodologia. Os analistas que já trabalhavam aqui não acreditam, não apoiam e não querem usar. A diretoria pediu que nos dessem uma chance para tentar testar e ver se realmente funciona. Mas acredito que enquanto houver resistência á tentativa, nada sairá do papel.

Por mais que a gente explique para os outros analistas o que é o scrum e como ele poderia nos ajudar e facilitar nossas vidas em vários aspectos, também tentamos informar os pontos em que talvez ele não se aplique aqui. Mas esses analistas não se interessam, não estudam a metodologia, não se esforçam para fazer funcionar.

Essa modelagem do sistema novo está demorando tanto porque estão agindo como faziam antigamente: querem prever tudo o que o sistema pode ter, aumentar o escopo do projeto, demorar para definir as coisas. Nós queremos feedback, queremos que o usuário aprenda sobre o sistema enquanto o fazemos. Mas todos aqui tem medo, muito medo, de mudanças, de todos os tipos: código, conceitual, paradigma...

Ana, falei da tarefa para o cadastro, mas me enganei. Era realmente uma história. A modelagem é que era uma tarefa. Sei que com certeza erramos em vários pontos na implantação do scrum. Afinal, foi nosso primeiro, e já esperávamos ter que corrigir coisas no meio do caminho. Mas acho que aqui a gente luta por algo não tão no nível do scrum.

Estou chegando à conclusão que o problema não foi só o scrum dar errado. Talvez o problema esteja mais embaixo. :(

Obrigada a todos pelas dicas!

[]s
Lívia

O que eu posso dizer sobre isso? Mudar um processo é difícil. Conscientizar as pessoas é mais difícil ainda. Você poderá ser mal comprendido, poderá ser visto como revolucionário. E com certeza escutará coisas do tipo: "Você não conhece os processos" ou então "Isso não vai funcionar aqui... é outra realidade".

Embora o sentimento seja de desistir, temos que aprender e retomar as tentativas. E mostrar que tudo o que queremos é, na verdade, AJUDAR a empresa a se adequar ao futuro.

No meu MBA um dos meus professores falou sobre empresas orgânicas, que isto é a tendência do futuro para todas organizações de todos os tipos. A maioria dos princípios são aderentes ao do agile. Mas isso é assunto para outro post :)

Abraços

Dinâmica dos aviões

2008-11-13T07:37:00.004-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Terça-feira, dia 11, realizei novamente a convite do professor Rafael, na disciplina de Gerência de Projetos, na PUC-RS, a dinâmica dos aviões para que o pessoal vivenciasse alguns conceitos do agile na prática.

A dinâmica foi um sucesso! Uma das melhores turmas, com certeza. Fiz algumas fotos e vídeos. Devo postá-los entre hoje e amanhã :)

Aguardem!

Eventos empresariais: por que ficar na mesmice?

2008-11-10T21:36:00.003-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Volta e meia eu fico me perguntando: por que será que a grande maioria das empresas trata seus eventos (ou rituais, como também são chamados) como um "mal necessário"? Ou seja, fazem aquela reunião em que todos da empresa se encontram e convivem, normalmente por um dia em algum lugar fora da cidade, como uma "obrigação" ou tedioso.

Na empresa onde estou, atualmente, na minha segunda semana de trabalho tivemos um evento bastante diferenciado. Não só pela organização, mas também pelo conteúdo.

Durante toda a semana, passamos no suspense do sábado que estava vindo. Só sabíamos que tínhamos que estar na frente da empresa às 7h30. Num sábado. Todos especulavam dentro da empresa: rafting? sítio? paintball? trabalho escravo em uma mina de carvão?

Até que no dia acabamos indo para um sítio, nos arredores de Porto Alegre. Um local muito bacana, muito verde e bastante relaxante. Para mim já seria um evento importante pela possibilidade de me enturmar um pouco mais com meus colegas. Mas acabei descobrindo que o evento era mais do que isso.

Os diretores utilizaram aquele dia para apresentar aos funcionários a nova visão e missão da empresa, bem como seus novos valores. E tudo foi feito de uma forma bem divertida, com vídeos produzidos por eles mesmos. Ao final, presentearam a todos com uma camiseta personalizada da empresa. O resto do dia foi de interação entre todos.

Ou seja, ao invés de ser apenas "mais um evento", eles conseguiram transformá-lo em algo sensacional. Se antes todos estavam se sentindo mal por terem que acordar cedo demais num sábado, no fim do dia a sensação era de que aquele havia sido um dos eventos mais bacanas de muitos anos na empresa.

Diversas outras empresas utilizam eventos empresariais para inovar e causar comoção e incentivo aos seus funcionários. Uma empresa multinacional, por exemplo, anualmente faz a sua premiação dos funcionários destaques. A festa era um porre. Só quem curtia eram os funcionários destaques, seus familiares (se muito) e o presidente, que tinha o momento para "brilhar" com seus discursos e apertar a mão dos funcionários, que eram chamados um a um ao palco... e lá pelo décimo nome todos já estavam quase mortos de tédio.

O departamento de RH decidiu inovar então. Naquele ano, resolveram fazer uma surpresa aos funcionários destaques. Atrás do palco, havia uma cortina enorme. O presidente então avisou que naquele ano faria diferente, e pediu para todos os funcionários destaques se levantarem e virem ao mesmo tempo até o palco e sentarem nas cadeiras marcadas com seus nomes, viradas ao público.

Quando eles terminavam de se acomodar, tambores tocaram e as cortinas de abriram. Atrás delas, exatamente atrás de cada cadeira, havia um boneco enorme caricato de cada um dos funcionários. Foi uma comoção geral. Os funcionários destaques se emocionavam, os familiares corriam para abraçá-los e tirar fotos junto aos bonecos, os demais funcionários davam risadas e se divertiam com as caricaturas.

O evento foi um sucesso. Todos falavam nele durante o ano e a busca pelo destaque se tornou muito maior, mas sempre com respeito. O departamento de RH teve que procurar inovações ano a ano... o que parece um problema, mas na verdade era um grande desafio que todos adoravam enfrentar.

Até quando as empresas começaram a se dar conta que podem tornar seus eventos mais interessantes? Isso é valorizar seus colaboradores. Isso é se diferenciar. Infelizmente poucas realmente pensam dessa forma.

E a sua empresa, caro leitor? Já realizou um evento diferenciado para vocês, funcionários? Ou usa e abusa destes lugares comuns? Conte para nós!

Um grande abraço

Férias forçadas

2008-11-06T22:15:00.001-02:00

Caros leitores,

estarei em férias forçadas num rápido período de tempo :)

Na segunda-feira estou postando de novo.

Abraços!

Teoria x Prática

2008-11-01T11:53:00.004-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Numa das minhas aulas de MBA, o meu professor mencionou um artigo do colunista da Veja Stephen Kanitz. O artigo é excelente e mostra como muitas empresas lidam com as pessoas (como recursos). E como a prática é bem diferente da teoria.

Você é diretor de uma indústria de geladeiras. O mercado vai de vento em popa e a diretoria decidiu duplicar o tamanho da fábrica. No meio da construção, os economistas americanos prevêem uma recessão, com grande alarde na imprensa. A diretoria da empresa, já com um fluxo de caixa apertado, decide, pelo sim, pelo não, economizar 20 milhões de dólares. Sua missão é determinar onde e como realizar esse corte nas despesas.
Esse é o resumo de um dos muitos estudos de caso que tive para resolver no mestrado de administração, que me marcou e merece ser relatado. O professor chamou um colega ao lado para começar a discussão. O primeiro tem sempre a obrigação de trazer à tona as questões mais relevantes, apontar as variáveis críticas, separar o joio do trigo e apresentar um início de solução.
"Antes de mais nada, eu mandaria embora 620 funcionários não essenciais, economizando 12 200 000 dólares. Postergaria, por seis meses os gastos com propaganda, porque nossa marca é muito forte. Cancelaria nossos programas de treinamento por um ano, já que estaremos em compasso de espera. Finalmente, cortaria 95% de nossos projetos sociais, afinal nossa sobrevivência vem em primeiro lugar". É exatamente isso que as empresas brasileiras estão fazendo neste momento, muitas até premiadas por sua "responsabilidade social".
Terminada a exposição, o professor se dirigiu ao meu colega e disse:
-Levante-se e saia da sala.
-Desculpe, professor, eu não entendi - disse John, meio aflito.
-Eu disse para sair desta sala e nunca mais voltar. Eu disse: PARA FORA! Nunca mais ponha os pés aqui em Harvard.
Ficamos todos boquiabertos e com os cabelos em pé.
Nem um suspiro. Meu colega começou a soluçar e, cabisbaixo, se preparou para deixar a sala. O silêncio era sepulcral.
Quando estava prestes a sair, o professor fez seu último comentário:
-Agora vocês sabem o que é ser despedido. Ser despedido sem mostrar nenhuma deficiência ou incompetência, mas simplesmente porque um bando de prima-donas em Washington meteu medo em todo mundo. Nunca mais na vida despeçam funcionários como primeira opção. Despedir gente é sempre a última alternativa.
Aquela aula foi uma lição e tanto. É fácil despedir 620 funcionários como se fossem simples linhas de uma planilha eletrônica, sem ter de olhar cara a cara para as pessoas demitidas. É fácil sair nos jornais prevendo o fim da economia ou aumentar as taxas de juros para 25% quando não é você quem tem de despedir milhares de funcionários nem pagar pelas conseqüências. Economistas, pelo jeito, nunca chegam a estudar casos como esse nos cursos de política monetária.

Leia o artigo completo aqui.

Excelente, hein? :)

Por que agile é TÃO legal

2008-10-28T21:53:00.006-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Falei da reunião, certo?

Num determinado momento nós iríamos simular alguns processos. Dessa forma saberíamos as disposições, os recursos atuais, projetos por equipe e onde faltam recursos. Logicamente, como eu já tive algumas experiências anteriores, eu sabia que uma reunião que teria tudo para se tornar monótona e sem graça, precisava de um toque especial... um toque agile.

E então eu criei cartões sobre os processos e afins. E com post-its fomos preenchendo o resto. A reunião ficou tão divertida, que um dos diretores pegou a máquina e fotografou.

Sim, eu sou o laranjão.

Agile é legal porque é VISUAL.
Quanto mais VISUAL, mais INTERATIVO.
Quando mais INTERATIVO, mais COLABORATIVO e INFORMATIVO.

Por isso que usar dinâmicas, post-its, taskboards, burndowns, planning poker, etc. é tão importante. Motiva e cativa as pessoas.

Eis ai um exemplo BEM prático :)

Como cometer suicídio numa entrevista de emprego

2008-10-27T23:02:00.004-02:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Eu já falei sobre entrevistas de emprego aqui (procure nos posts). Dei até algumas dicas do que NÃO fazer.

Mas jamais, JAMAIS faça o que o candidato que eu entrevistei hoje, fez.

Entrevistamos, eu e um colega, um candidato. O cara chamou muito a atenção. Parecia ser um bom candidato, estava muito interessado em entrar na empresa. Hoje seria a segunda entrevista dele, agora com um dos diretores junto.

Daí o diretor fez uma pergunta comum, que simplesmente fez o candidato cometer suicídio.

"Qual o seu maior defeito?"

E o cara me sai com essa.

"Olha, eu sou muito preguiçoso... mais pela manhã."

COMO É?!??! Me deu vontade de me levantar e sair nessa hora. Que queimação de filme. Eu e o meu colega nos olhamos constrangidos. Fizemos o maior cartaz do cara "Esse é um dos melhores que entrevistamos" e o cara me larga essa.

Sinceramente, tem gente que realmente pede pra morrer na praia.

Abraços

Marketing de relacionamento

2008-10-14T23:27:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Leia o trecho abaixo e confesse: você NUNCA pensou em fazer algo igual né?

Relatou o case impressionante de uma empresa de jardinagem que, via Google Maps, calculou a área de todos os quintais e jardins das casas de uma cidade. Cada vez que uma pessoa ligava para orçar o serviço (quer era cobrado por m2), o atendente já respondia na hora qual o custo. Para propagar o serviço, criaram freesbies que eram jogados nos quintais das casas. Cada um dos discos, continha o endereço da casa em que foi jogado e o custo que eles cobrariam para fazer o serviço.

Isso foi apresentado em uma palestra em São Paulo sobre comunicação digital. A originalidade da proposta da empresa deve ter garantido um retorno próximo de 100% na clientela. Isso se chama "marketing de relacionamento". Esse é um caso extremo, lógico. Mas você, que presta algum tipo de serviço, nunca ouviu falar nisso? Preocupe-se.

Diferenças entre uma micro e uma pequena empresa.

2008-10-14T23:00:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje completei uma semana na nova empresa. Foi uma semana em que eu fui de dias relativamente tranquilos (os primeiros) até dias cheios. Apesar da minha carga horária ter aumentado bastante e apesar de eu ter superestimado a empresa (isso é normal, a gente sempre superestima hehe) eu estou bastante feliz.

Como é bom trabalhar em projetos que tem um "time-to-market" mais curto. É desafiador. É motivador. É saber que em pouco tempo estaremos entregando um projeto! Tendo um feedback mais rápido. Vendo o resultado acontecer mais rápido.

Além disso, tem o desafio interno. A empresa está crescendo muito, acredito que já está na transição de pequena para média empresa. E isso acarreta em mudanças de processos internos... os quais eu quero muito participar também.

Mas o que eu pude perceber de diferente entre uma micro e uma (ainda) pequena empresa? Abaixo vou listar alguns ítens. E digo que não é baseado em nenhuma teoria. São apenas minhas percepções... não é certo nem errado :)

1) Portfolio de projetos. Essa é a diferença mais gritante de todas. Numa micro empresa, todo projeto é atacado com unhas e dentes, independente da sua origem. A pequena empresa já começa a se dar ao luxo de pensar duas vezes antes de aceitar alguns projetos.

2) Foco no negócio principal da empresa. Pode-se até pegar projetos que fujam do escopo da empresa (como vai acontecer com um que irei gerenciar). Mas isso acontece por questões estratégicas (querer trabalhar com determinado cliente). Uma micro empresa normalmente atira para o lado que puder... e fica sem foco e, normalmente, sem identidade e posicionamento.

3) Processos internos. Nenhuma micro empresa começa pensando nos seus processos. Elas começam pensando em entregar projetos... de alguma forma. Uma pequena empresa já pode avaliar e formalizar seus processos, para ter mais produtividade e, consequentemente, trabalhar melhor a gestão do conhecimento.

4) Foco nas pessoas. Essa é uma percepção que estou tendo na empresa onde estou e pode variar muito dependendo da cultura da empresa. Mas é fato que a partir do momento em que uma empresa deixa de pensar externamente, ou seja, em buscar clientes, ela pode começar a pensar internamente. E começa-se a pensar em como valorizar seus funcionários. Aí surgem os rituais (festas, eventos) e benefícios (planos de carreira).

5) Infra-estrutura. Essa é outra coisa gritante. No começo, tudo é corte de custo. Uma salinha basta. Tudo é free. O diretor é secretário-gerente-desenvolvedor-contador. Quando a empresa cresce, o espaço físico começa a fazer diferença... a segmentação das atividades toma forma...

Claro que existem inúmeros outras características que diferenciam. Acredito que eu tenha citado as cinco mais evidentes. É interessante começar a perceber isso, pois muitas vezes se uma empresa começa a pensar em melhorar estes itens, é porque ela dá sinais de que está (e principalmente, QUER) crescer.

Por outro lado... quantas empresas crescem e não pensam nisso? O resultado a gente costuma adivinhar facilmente...

Um abraço

Um peixe fora da água... e perdido.

2008-10-09T22:53:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

É exatamente assim que eu me sinto. Um peixe fora da água e perdido.

Mas quem não se sente assim no novo emprego?

Saimos de um lugar onde já somos conhecidos, respeitados e reconhecidos. Mudamos para um local totalmente novo, com novas rotinas, processos e novas pessoas.

Estes três dias foram bastante exaustivos. Os dois primeiros praticamente eu só tentei me posicionar no ambiente de trabalho. Hoje comecei a trabalhar de fato, e tive que fazer o meu primeiro cronograma. E fazer um cronograma sem saber quem alocar e, em alguns casos, sem saber ao certo o que significa cada processo, é bastante desgastante.

"Produção web" é um trabalho que até agora eu tenho minhas dúvidas do que se trata. Aloco ou não aloco no projeto?

Fiz uma reunião e chamei uma pessoa que era desnecessária no momento. Ok, a princípio ela poderia ser necessária, mas depois se viu que não seria. Com um pouco mais de vivência eu já poderei aprender isso.

Enfim, hoje foi um dia cheio. Cheio de novidades. Cheio de novas obrigações. E cheio de novos desafios. Além de aprender os processos, as funções, os nomes, os termos, os atalhos, os skills... ainda tenho que fazer ELES aprenderem sobre mim.

E agora vou dormir. Pois o meu corpo ainda precisa aprender a se adequar a nova rotina de horário.... hehe

Abração a todos.

Colaboração do cliente

2008-10-08T21:22:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

O agile tem quatro princípios bem "revolucionários" em sua proposta. Maximizar a comunicação, valorizar as pessoas, reagir à mudanças, software funcional e ... colaboração do cliente.

Todos estes envolvem uma mudança cultural, mas somente um deles trata de algo externo à empresa. Sim, você já adivinhou qual é.

Hoje estávamos em reunião na empresa e um colega que entrou esta semana, vindo de outra empresa, contou uma história que me deixou pensando como existem clientes que são impossíveis de serem "colaboradores".

Diz que a agência dele trabalhou na realização de um hotsite (aqueles sites promocionais) de um produto estilo "toddyinho", mas que era uma marca pouco conhecida inclusive na praça onde eles trabalhavam (região sudeste). Eles quiseram promover o produto criando um hotsite para crianças e adolescentes, que consistiria em um jogo com alguma complexidade e os vencedores ganhariam algum tipo de prêmio.

O hotsite foi um sucesso. Receberam acessos inclusive de outras regiões do Brasil, batendo a incrível marca de um milhão de acessos. Porém, como o jogo era complexo, a empresa recebeu VINTE emails reclamando do hotsite. E o cliente foi pra cima da agência dizendo que "nunca antes recebemos tantas reclamações como agora".

Vinte emails de uma população de um milhão de visitantes. Isso daria algo como 0,00002% de reclamantes. Mas como o cliente tinha um site que nunca era visitado, isso deve ter representado um aumento de 200% em suas reclamações.

Como "colaborar" com um cliente assim?

O que é dito lá no trabalho, que é bastante comum, é o cliente ter um prazo para entregar seu material para a criação dos sites. Porém eles atrasam a entrega. Só que depois vêm pra cima da agência querendo explicações dos motivos dos atrasos no cronograma, acusando a agência de ter atrasado a entrega.

Enfim, eu confesso que me assusto ao pensar que é ESSE tipo de colaboração que nós agilistas temos que conseguir. Na teoria é muito bonito. Na prática, talvez só VINTE clientes de um milhão colaborem hehe

Abração

O primeiro dia na nova empresa

2008-10-07T21:30:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

O nervosismo do primeiro dia. Fazia tempo que eu não sentia isso.

Pois lá estava eu, no saguão do prédio, esperando o elevador. Ansioso. Junto a mim, uma mulher e um homem. Entramos no elevador mudos, cada um apertou um andar. Até que a mulher comentou: "Hoje é o meu primeiro dia". E o homem falou que era o primeiro dia dele também. E eu completei que era o meu também! A ansiedade acabou ali. :)

Ao chegar no andar, fui direto conversar com os diretores. Me apresentei, conversei rapidamente e já fui indicado para ir conversar com os gerentes. Lá, novamente uma rápida conversa e já pude ter contato com o ambiente dinâmico que é uma agência de publicidade/conteúdo para web. Muitas pessoas, bastante comunicação, bastante descontração e ... muito trabalho.

Após algumas reuniões na manhã com os gerentes, para eles me passarem uma visão macro do funcionamento e também alguns acompanhamentos de outras reuniões, à tarde eu passei praticamente todo o período pesquisando e buscando material para me interar dos processos e documentos. Achei bastante coisa que eu pretendo ler amanhã pela manhã.

Enfim, um primeiro dia onde eu me deparei com uma realidade bem diferente da que eu tinha antes. Mas que será um excelente desafio.

Podem deixar que eu continuarei postando :)

Um grande abraço!

Último dia de trabalho...

2008-10-06T23:20:00.002-03:00

E foi um dia comum. Reuniões, passagem de conhecimento, bate papo...

E bastante ansiedade para o dia de amanhã. O primeiro dia no novo trabalho :)

Um abraço

Entrevistando ... pessoas.

2008-10-05T22:24:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Quando fazemos entrevistas costumamos buscar identificar algumas atitudes e perfis das pessoas. Mas muitas vezes acabamos cometendo um erro bastante comum: guiar as entrevistas de forma padronizada.

Pessoas são ... pessoas! São diferentes umas das outras. Tem reações, sentimentos e desejos completamente diferentes.

Um exemplo bem típico disto eu vou citar durante as entrevistas que fizemos na sexta-feira.

Entrevistamos 8 pessoas durante o dia. Três delas estavam completamente nervosas! E isso é uma das coisas mais comuns e não costuma dizer nada sobre a pessoa. O que nós resolvemos fazer (estávamos em três, entrevistando os candidatos) foi tentar descontrair a entrevista para acalmá-los.

Falávamos de futebol, faculdade e demais assuntos corriqueiros. E isso soltava o candidato. Ajudou a gente a escolher inclusive um, que mudou bastante quando deixou de ficar nervoso.

Decidimos então que a última candidata (a única menina da seleção) iríamos começar a entrevista já descontraindo. O currículo dela dizia que ela falava fluentemente francês. O meu chefe fala também, então ele iria começar falando em francês com ela.

Dito e feito. Ambos bateram um papo em francês, e nós nos mostramos surpreendidos com a fluência dela. Sorrimos e brincamos, mas ela não pareceu muito confortável. Então o meu colega perguntou "Para qual time tu torces?" e ela respondeu, já meio impaciente: "Acho que isso não vai fazer nenhuma diferença aqui". O meu colega prontamente respondeu "Muito bem!" e aplaudimos ela.

A idéia era criar um ambiente mais tranquilo, com base na nossa experiência anterior com os outros candidatos que vieram até então. Só que com ela o tiro saiu pela culatra.

Ela comentou em seguida que aquela vaga era importante para ela. Pois ela era formada em direito e agora fazia Sistema de Informação... só que nas últimas três entrevistas que ela havia feito, o entrevistador havia sido extremamente infeliz. Um deles perguntou inclusive se "ela era especialista em Word". Ninguém a levava a sério, embora ela já estivesse empregada mas não queria permanecer como desenvolvedora.

Ou seja, para ela, aquela nossa abordagem "descontraída" era quase que uma nova ofensa!! Ela acho que estávamos menosprezando ela. Felizmente conduzimos bem a entrevista e no final ela até largou uma daquela pérolas que todos gostam de ouvir: "As outras pessoas do ambiente de trabalho são agradáveis como vocês?".

Veja como uma abordagem "pré-definida" que achávamos que seria excelente foi um desastre!

Enfim, entrevistar pessoas é um processo bastante complexo. Eu sigo a abordagem do "bate-papo" ao invés de usar perguntas padrões. Mas ainda sinto que tenho uma dificuldade grande: costumo simpatizar (ou não) com os candidatos durante a entrevista. E isso costuma afetar a decisão, algumas vezes. Fica aquela coisa de "ah, vamos dar uma chance"...

Mas jamais use perguntas padrões. Lembre-se que cada pessoa é diferente. Por mais óbvio que isso pareça, muitos costumam esquecer!

Abraços

Currículos, como NÃO montar o seu!

2008-10-05T11:31:00.006-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Não sou um especialista em currículos. Aposto que até mesmo o meu contém algumas coisas que não deveriam conter. Mas a partir do momento em que nós vivenciamos a experiência de selecionar pessoas, passamos a entender e enxergar a montagem de um currículo de uma forma diferente.

Este post não pretende funcionar como um "how to CV", mas sim passar algumas impressões pessoais sobre o que pôr e o que não pôr em seus currículos. Sendo impressões pessoais, não leve como verdade absoluta. Mas reflita um pouco!

Vou alavancar algumas coisas que vi em currículos durante a seleção que fiz.

1) Não colocar email para contato no currículo. Peguei dois currículos assim. Num deles simplesmente não havia email de contato. No outro, o email colocado voltou como "inexistente". Ora, sabendo que o email é a forma de contato mais comum nos dias de hoje, não atentar a estes dois detalhes é cometer suicídio na vaga, como de fato ocorreu.

2) Encher o currículo de siglas e frases de efeito. Nós temos essa mania de encher nossos currículos com siglas e até mesmo frases e expressões de efeito. Não tenho nada contra isso, mas é extremamente terrível quando uma pessoa coloca como sendo "pró-ativa" e na entrevista se demonstra uma pessoa sem atitude. Ou como "trabalho em equipe" e nas entrevistas fala muito mais dos SEUS feitos do que os feitos de sua EQUIPE. E as siglas? Muitas vezes colocar que mexeu na ferramenta TIS 2.0 (Totalmente Inútil System), que é utilizada só na sua empresa, não é um diferencial: é encher o currículo de linguíça.

3) Abrir um programa vira "experiência no sistema TIS 2.0". Isso é outra coisa terrível. Diversos dos candidatos que entrevistei falavam que haviam mexido com tal e tal ferramenta, mas quando perguntei um pouco sobre a ferramenta, das duas uma: ou eles se atrapalhavam na hora de explicar ou então assumiam que apenas haviam "mexido". Causa má-impressão. Vale a pena ser honesto ou nem mencionar já no currículo.

4) Falta de data de nascimento. Eu considero isso uma informação importantíssima. Existem vagas que nós pensamos em preencher com pessoas com mais idade e vivência.

5) Falta de experiência profissional. Veja, aqui eu não estou falando se a pessoa TEM experiência profissional. Eu falo do fato incrível de uma pessoa que chamamos e que no currículo não havia NENHUMA experiência. Quando ele veio para a entrevista (ele acabou selecionado por acidente, acredite!) ele começou a mencionar os locais que havia trabalhado e tudo mais. Era um rapaz com boa experiência e conhecimento! Só que por "esquecer" de mencionar isso no seu currículo, por muito pouco não perdeu a vaga. Eu o aconselhei disso no final da entrevista. Inacreditável!

6) Currículos com textos longos e explicativos. O meu currículo atualmente tem este problema, e na seleção eu percebi como é terrível isso! E como a gente não se dá conta. Quando estamos vendo diversos currículos, queremos algo o mais sucinto possível. Eu tentei deixar no máximo 3 linhas por item, mas ainda assim tem muita explicação. Eu percebi que o ideal é ter somente o necessário para passar a informação e usar a entrevista para expôr tudo o que desejamos. Peguei currículos com textos loooongos e que realmente não existe a menor possibilidade de leitura.

7) Falta ou inexistência de formatação no currículo. Como é legal pegar um currículo sem total coerência em espaçamento, tabulação ou ordenação. São informações jogadas a esmo e que torna a leitura desagradável.

8) Currículos com mais de duas páginas. Nada pior do que currículos com muitas páginas. Muito ligado aos itens 2, 3, 6 e 7 (citados aqui), estes currículos se tornam impraticáveis. Ninguém quer ler um livro! Eu peguei currículos com SEIS páginas. SEIS!!! Com informações completamente inúteis.

9) Informações redundantes. Quando não sabemos o que pôr para encher linguiça, costumamos encher com informações redundantes. O que seria isso? Dizer que mexe com pacote Office, Windows 98, 2000, XP, Linux, etc. Ora, isso por acaso é importante para alguém que está concorrendo a uma vaga na área de tecnologia?! Como desenvolvedor ou analista?! Até minha sobrinha sabe mexer nisso!

10) Informações sem nexo algum. Colocar no final do seu currículo uma seção com "informações adicionais" pode ser interessante, mas lembre-se de SEMPRE orientar isso à sua vaga. Se você quer ser desenvolvedor, vale a pena mencionar que fez um curso de "fotografia de natureza"? Eu peguei um currículo (sem mentira!) que continha o seguinte parágrafo nas "informações adicionais", para uma vaga de desenvolvedor:

Hobbies: Pratico futebol, volei e basquete entre outros. Gosto de punk rock e de músicas com melodia agradável. Toco violão e guitarra.

O que dizer disso?! Imaginem uma empresa maior pegando um currículo desses? Vai ser motivo de chacota! O meu currículo possui uma menção a um negócio que eu tenho no sistema do Second Life, o qual tive bastante sucesso e levo tranquilamente me dedicando apenas uma hora por dia. Como eu concorro a vagas para gerente/gestor, eu coloco este fato até para puxar assunto sobre o assunto de gerir um negócio. Até hoje tem funcionado, mas muito porque é algo relacionado à área que desejo atuar. Se alguma vez eu notar que aquilo virou supérfluo, eu tiro.

11) Enviar currículo a esmo. Esse é o pior erro de todos. Abrimos, por exemplo, uma vaga para gerente de projetos com todas as habilidades que julgamos necessárias expostas no aviso. Recebemos currículos de jovens de 18 e 20 anos sem sequer experiência profissional concorrendo para a vaga. Ou então quando abrimos vaga para desenvolvedor, testador, analista e webdesigner, e uma pessoa entra para concorrer a todas elas. Essas pessoas sequer são consideradas.

12) Línguas. Mentir que o seu inglês é intermediário ou avançado é terrível. Mencionar que você domina a língua portuguesa, é contraproducente. Arranhar no portunhol e colocar como "conhecimentos básicos em espanhol" também não ajuda em nada.

Enfim, estes são alguns dos erros que eu notei durante a escolha dos currículos. Já fizemos entrevistas e muitas pessoas, mesmo sem experiência, agradaram. Isso se deve a duas coisas que todos nós precisamos ter em mente, não só quando concorremos a uma vaga mas também quando estamos selecionando alguém.

a) O currículo representa o que a pessoa fez até aquele momento. Precisamos tentar descobrir o que a pessoa pode fazer no FUTURO!

b) Um currículo mostra os conhecimentos e habilidades da pessoa. Mas a atitude não podem ser apenas palavras. E atitude é MUITO mais importante do que qualquer conhecimento ou habilidade. Atitude não se aprende.

Um forte abraço e espero que as dicas ajudem alguns leitores :)

A difícil decisão da troca de emprego

2008-10-03T12:28:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Caros leitores, sei que alguns devem ter estranhado que este blog está bem desatualizado! Confesso que ocorreu uma coisa nas últimas semanas que me balançou demais: uma proposta para trocar de emprego.

Este é um post bastante grande, mas se você passa pela indecisão de trocar o emprego, talvez lhe ajude a refletir...

A proposta...

Na semana passada, um colega meu agilista (possivelmente após ler o meu post sobre a negociação dos salários hehe) me enviou um email solicitando o meu currículo, para repassar a uma vaga que ele estava sabendo. Ele queria me indicar. Enviei o currículo, sem muita pretensão. Apesar dos pesares, meu planejamento era permanecer no meu emprego atual por mais um período para depois sim sair.

Recebi o chamado de um dos sócios da empresa para ir até lá. Resolvi aceitar a entrevista, até como forma de ver como eu estava no mercado, enfrentar uma entrevista, etc. Acho que, inclusive, todos nós devemos fazer isso de vez em quando para ver se ainda estamos falando o mesmo idioma... principalmente em casos como o meu, que estava havia 3 anos no mesmo local.

Pesquisei um pouco sobre a empresa na internet, de forma a entender o território que estaria pisando. Para minha surpresa, a empresa tem um bom nome no mercado onde atua (conteúdo para internet, um mix de publicidade/tecnologia/etc) e as referências encontradas eram bastante interessantes.

A primeira entrevista...

Claro, apesar de não ser mais um garoto em busca de estágio, estava bem ansioso e nervoso. Mesmo colocando na cabeça: "Calma, vamos lá sem pretensão nenhuma. Só ouvir a proposta, conversar, etc". Cheguei ao local e me deparei com um dos melhores prédios de uma zona nobre aqui de Porto Alegre. Soube que eles estavam com um andar inteiro. Subi até o local, e me identifiquei para a entrevista. Aguardei alguns minutos e pude ver como o ambiente é despojado e informal. Eu me identifico com locais assim, pois acho que na nossa área de atuação (onde a criatividade e o conhecimento são oriundos de pessoas), precisamos criar um ambiente propício para que essas pessoas se sintam bem e produzam.

Vou dizer que não existe momento pior de uma entrevista do que o momento em que aguardamos. Para pessoas ansiosas como eu, é nesse momento em que a gente tem que respirar fundo, se acalmar e se focar. Digo isso, pois vejo muitas pessoas que ficam realmente preocupadas em acharem coisas do tipo "só acontece comigo". Que nada... a grande maioria, sem exceção, fica nervosa e ansiosa nesses momentos. O grau com que isso acontece é que varia... então se você acha que é excessivo demais, procure alguma ajuda. De verdade :)

Fui chamado então pelo sócio da empresa que havia feito o convite. Fomos até uma das salas de reunião e ele foi vendo o meu currículo e discutimos sobre os meus projetos anteriores, minha formação, minhas possíveis qualidades para a vaga, etc. Eu notei que o fato de eu trabalhar em um grupo de pesquisa acabou gerando uma certa desconfiança. Certamente é pela visão distorcida que todos nós temos de grupos de pesquisa unversitários, mesmo que envolvam empresas como no meu caso.

Ainda assim, conversamos por aproximadamente uma hora. E eu senti que agradei. Inclusive mostrei este meu blog que ele achou bastante interessante. Em seguida ele solicitou que os gerentes se juntassem a nós para conversar e também me conhecerem. Os outros dois sócios também vieram, mas eu acabei não percebendo que eram eles. Daí foi mais uma meia hora de sabatina de perguntas! Desde aquelas clássicas de qualquer entrevista de RH até conversas mais abertas. No total, ficamos em torno de uma hora e meia conversando, e acredito que finalizamos mesmo por já estarmos estourando o horário do almoço.

A impressão inicial que eu tive de todos foi muito boa. Eles me fizeram perguntas para me testar, como quando me solicitaram para contar alguns momentos de pressão que eu havia tido, algumas atitudes que eu havia tido, etc. São perguntas que deixam o entrevistado desconfortável, e com certeza muitos ficam sem ter o que dizer.

No fim das contas, eu acho que fui muito bem. Fiz uma "auto-avaliação" e percebi que ao menos consegui deixá-los na dúvida, pois conversei num nível muito bom com eles, discutimos sobre assuntos importantes como liderança, cobranças, prazos, processos e em todos eu me senti bastante a vontade para falar.

Foi ótimo para mim também, pois eu percebi que sim, eu estava ainda bastante alinhado com o mercado. Muito disso devido a eu gostar muito de estudar, ler e até mesmo ouvir sobre o assunto (livros, listas de discussão, artigos, podcasts, vídeos, etc) além do meu MBA estar me reforçando demais algumas arestas sobre gestão que eu não tinha conhecimento completo.

Sai da empresa bastante satisfeito por saber que havia deixado ao menos eles na dúvida. Mas ainda mantinha o meu planejamento de ficar no meu emprego atual.

A segunda entrevista...

Passados um ou dois dias, recebi outro email do sócio da empresa que havia conversado comigo. Ele me chamou para conversarmos um pouco mais. Aceitei novamente, já imaginando que poderia ser a proposta. Decidi que seria legal saber como eles estariam me avaliando, se eu realmente havia agradado, etc.

Neste período, eu ainda estava bastante convicto de não sair do meu emprego. Fui até lá para ouvir a proposta mesmo. Chegando lá, passei novamente por este momento de nervosismo (um pouco menor), que antecede a entrevista (sim, leitor! Reforço que isso é normal!). Então entramos numa das salas de reunião onde ele e outro sócio me fizeram a proposta. Financeiramente falando, em valores brutos, o valor era bastante superior. Além disso, ele reforçou que se eles não tivessem gostado de mim, eu não estaria ali :)

Agradeci e disse que iria pensar e ainda naquela semana daria o retorno. Mas poxa, aquilo mexeu demais comigo. Receber uma proposta, ainda mais reforçando que eles realmente queriam contar comigo, num local onde eu sempre gostaria de trabalhar, onde as pessoas são realmente valorizadas e possuem um ótimo ambiente de trabalho, onde todos os gestores possuem uma idade próxima da minha e, com isso, possuem algumas idéias e valores próximos dos meus... mexeu bastante.

Sai de lá sem saber ao certo o que fazer. Aquela minha convicção de que seguiria o meu plano não era mais tão forte.

A indecisão... parte 1

A primeira coisa que eu fiz foi conversar com o meu colega no trabalho. Estamos atuando como GP's juntos há mais de 1 ano e meio, mas já trabalhamos juntos há mais de 2 anos. É daquele tipo de colega de trabalho que transcende um pouco para a figura de amigo. Conversamos longamente e ele me disse que também ficaria indeciso.

Onde estávamos, já somos reconhecidos. Todos sabem da nossa capacidade e já nos valorizam. O projeto que esperamos quase um ano para sair, finalmente estaria iniciando em outubro. As tecnologias com as quais trabalharíamos eram excelentes (RFID, GPS, etc) todas elas na "crista" da onda. Temos também uma enorme flexibilidade na carga horária (30hs) e a possibilidade de erguer uma empresa e o próprio grupo de pesquisa.

Por outro lado, a empresa que me fez a proposta já está estabelecida no mercado. Eles transcenderam a luta pela sobrevivência para agora pensarem nos seus processos internos, em como valorizar sua equipe, em como tornar o ambiente agradável... além disso, é uma empresa com uma cultura bastante atual e muito próxima (se não igual) dos valores que eu acredito. Mesmo trabalhando com uma tecnologia sem grandes novidades (web), os projetos envolvem clientes grandes e são projetos de duração de 1 a 3 meses. Nada melhor para um gerente do que participar de projetos onde a gente ENTREGA resultados, ao invés de ficar em projetos looooongos que parecem que não tem fim.

E ai? Lendo isso, você, caro leitor, poderia ter uma decisão? :)

Enfim, eu conversei bastante... e tomei uma decisão (relutante). Ficaria onde estava.

Liguei para o sócio que havia feito a proposta e falei que preferiria manter meu planejamento pessoal e profissional e que iria negar a proposta, mas tentando deixar claro que seria algo temporário. Ele sentiu a minha relutância e insistiu: "Cara, pensa um pouco mais e conversamos melhor no final da semana ok?". Aceitei.

Foi um final de semana do cão! Não deixei de pensar no que fazer por quase nenhuma hora.

A indecisão... parte 2

Resolvi pesar a questão financeira. Foi aí que vi que proporcionalmente falando, valor hora, eu estaria ganhando menos na atual empresa. Então tentei negociar esta variável com a empresa, pois valores são binários... fáceis de mensurar. A empresa acabou mantendo a posição da proposta inicial, mas me explicou sobre alguns benefícios indiretos que eu teria (desconto em plano de saúde, estaciomento e, principalmente, o plano de carreira deles). Dai eu percebi que a segunda entrevista foi tão rápida que eu não havia perguntado diversas coisas! Não sabia quais seriam minha funções e responsabilidades. Nem mesmo o funcionamento deste plano de carreira.

Acabei falando com o responsável pelo setor financeiro e também com um dos gerentes. Ambos foram muito solícitos e me explicaram sobre os assuntos. Com o gerente eu conversei bastante sobre questão dos processos, dia-a-dia, decisões, enfim... percebi que mesmo sendo uma área menos técnica da qual estou acostumado, ainda assim eu teria total capacidade para enfrentá-la.

Fiquei pesando os prós e os contras durante uns quatro dias. Quatro LONGOS dias. Todas as pessoas com as quais eu conversava e consultava se demonstravam indecisos... ora para um lado, ora para outro. Minha namorada me falou que jamais havia me visto tão indeciso em alguma coisa! Percebi como é difícil tomar uma decisão de deixar um emprego onde gostamos e enfrentar um desafio num local onde provavelmente também iremos gostar!

Acabei tomando a decisão de enfrentar o desafio. Mas aí faltava o momento mais temerário para mim. Comunicar os meus chefes.

Avisando da saída...

Durante todo este período de indecisão eu continuei trabalhando. Estávamos planejando o início do projeto e o meu chefe já havia me delegado diversas atividades. A grande vantagem da minha saída neste momento seria que o projeto nem teria equipe definida nem conhecimento adquirido. Tudo o que tínhamos era bem alto nível.

Tomei coragem e bati na porta do meu chefe. Falei que tinha uma notícia bastante ruim, mas que eu havia recebido uma proposta para ir para uma empresa e que eu havia relutado muito, mas havia acabado aceitando após refletir demais. Achei que o meu chefe teria um chilique, ficaria bravo, triste, ou algo do tipo. Não!

Ele ficou surpreso mas conversou na boa comigo. Disse que sabia que em algum momento isso iria ocorrer pois sendo um grupo de pesquisas, ele não poderia me dar estabilidade... temos sempre que ficar na torcida de conseguir projetos como este. E sempre haveria o problema dos valores salariais, já que eu nunca poderia receber um valor real de mercado (incluindo aí os benefícios). Conversamos bastante sobre o que fazer, falei que eu havia solicitado uma semana para finalizar minhas tarefas e ele me pediu para tentar conseguir alguém para a minha vaga. Felizmente já indiquei diversos bons candidatos.

E o principal, a frase que eu queria MUITO ouvir dele: que as portas estariam sempre abertas para se eu quisesse voltar algum dia. Essa frase, por mais "default" que pareça, demonstrou que eu poderia sair de consciência tranquila e também que eu havia feito um trabalho que eles haviam gostado muito. Deixar as portas abertas na empresa onde estamos saindo é uma das melhores coisas que podemos fazer.

Conclusões...

Ufa! Pronto, estava agora de consciência BEM tranquila para comunicar a minha decisão. Agora estou no período da ansiedade para iniciar os trabalhos. Sei que terei que me adaptar a um novo rítmo de trabalho, com um time-to-market bem mais rápido... sei que terei que liderar uma equipe de perfil completamente diferente... enfim, só terei desafios no novo emprego. Mas sem dúvida nenhuma, serão desafios que eu irei enfrentar com a mesma paixão e vontade que eu enfrentei todos até agora.

O que se pode tirar de lição desta minha experiência, tão comum entre muitos leitores daqui?

1) Se você está realmente indeciso, procure pensar a longo prazo. A empresa vai te oferecer oportunidades, desafios e conhecimentos para o objetivo que você tem a longo prazo?

2) Se desligar da sua empresa atual parece difícil, mas não é. Se você é uma pessoa íntegra e ética, seus chefes saberão disso. Precisamos esquecer essa idéia de que iremos "trair" a empresa ao sair. Mais profissionalismo e menos emoção... (eu sei que é difícil, mas precisamos tentar!).

3) Escolha sempre a empresa que mais fecha com os seus valores. Se você é do espírito que busca desafios, busque empresas com um time-to-market mais curto. Se você gosta de flexibilidade, procure empresas mais despojadas.

4) A questão financeira é importante. No meu caso, eu acabei tentando utilizá-la como peso para medida... mas muito por não ter conhecimento do plano de carreira, dos benefícios, enfim. Não se surpreenda se muitos conhecidos aceitarem trocar de emprego para ganhar menos.

5) Não prolongue demais a sua decisão. Não faça como eu, que passei dias me remoendo para tomar a decisão. É terrível e você afeta inclusive a sua vida pessoal e profissional. Por mais difícil que seja, tome uma decisão assim que pesar e obter o máximo de informações.

Ufa... como eu disse, um post enorme. Mas que tem como função auxiliar os possíveis indecisos a refletirem um pouco também sobre esse tipo de decisão :)

Um forte abraço a todos

Atualização...

2008-09-29T23:55:00.002-03:00

Caríssimos,

estou um pouco desatualizado devido a uma proposta que recebi de emprego :) Estou estudando-a com muito carinho buscando alinhar com todas as necessidades.

Amanhã quero postar para vocês algumas passagens e informações extraidas de currículos que eu recebi para uma vaga no meu trabalho atual. É legal para refletirmos sobre coisas que a gente as vezes nem percebe que coloca no curriculo. Mas lógico que isso depende para cada pessoa... alguém pode pegar o meu e dizer "Que informação inútil isso!" hehehe

Mas amanhã expresso aqui.

CSM em Porto Alegre (Outubro e Novembro)

2008-09-25T10:37:00.002-03:00

Gaúchos, meus conterrâneos.

Haverá o curso de Certified Scrum Master em outubro e novembro em Porto Alegre. É o momento para nos encontrarmos e aprendermos mais sobre o assunto.

Além disso, está se tentando organizar um AGILE DAY também. Tomara!

CSM - Caelum (Alexandre Magno)

Prepare-se para Metodologia Ágil com Scum!

Turma em Porto Alegre 13 e 14 de outubro

O treinamento de CSM- Certified ScrumMaster você terá experiências com Hands-on usando Scrum, aprenderá aplicar a metodologia Scrum se tornará Certified ScrumMaster oficial, credenciamento por um ano como membro da Scrum Alliance, acesso a um material exclusivo aos CSMs, usando material em português, experiências reais do dia-a-dia.

Você irá aprender

A utilização prática de Scrum;
A essência de como conduzir um projeto da forma correta;
Como criar um Product Backlog;
Porque um Gerente de Projetos não pode simplesmente gerenciar cronogramas;
Como liderar times experientes e novatos;
Como escalar Scrum em projetos multi-sites com times com milhares de participantes envolvidos;
Dicas de como conduzir a aplicação de Scrum na sua empresa;

Ciclo de vida de um projeto usando Scrum

Carga Horária: 16 horas aula

Pré-requisitos: participação no processo de desenvolvimento de um projeto, não há necessidade de já ter gerenciado um projeto anteriormente.

Sobre o instrutor

Alexandre Magno é líder de projetos de software onde utiliza principalmente metodologias e processos ágeis. Atua na área de software há mais de 15 anos, já tendo participado de projetos de variadas dimensões de lead time, escopo e investimento. Foi o primeiro, e atualmente o único, Certified Scrum Trainer da América Latina, possuindo ainda certificações dos fornecedores IBM e Borland, e dos grupos OMG e PMI. Magno é o fundador do grupo Scrum-Brasil e atualmente é responsável pela área de Agile da Caelum.

Investimento: R$ 1.990,00 em 4 vezes sem juros ou à vista com 10% de desconto. (Descontos especiais para grupos)

Consulte-nos!!

http://www.caelum.com.br

-------------------------------------------------------------

CSM - Teamware (Juan Bernabó)

O Gerenciamento de Projetos Ágeis com Scrum precisa de um Scrum Master que possua os conhecimentos e habilidades necessárias para auxiliar no sucesso da equipe. Variantes de Scrum tem sido amplamente adotadas com muito sucesso em projetos no mundo inteiro por empresas como Fuji-Xerox, Cannon, Honda, NEC, Epson, Brother, 3M, Xerox e Hewlett Packard. Neste workshop ensinaremos como implementar Scrum, como ser um Scrum Master e como lidar com seus clientes e a sua organização. Gerenciamento de projetos ágeis é tão radicalmente diferente de gerenciamento de projetos tradicionais, como os processos ágeis são diferentes das metodologias tradicionais. Ao invés de planejar, instruir e direcionar, o gerente de projetos ágeis lidera. Esta pessoa é chamada de Scrum Master. O Scrum é utilizado atualmente como fundamento para os mais importantes frameworks de processos de desenvolvimento de software do mercado. Ele é a base da disciplina de gestão de projetos da instãncia open source do RUP, o OpenUP. É também utilizado como base da gestão de projetos do processo da Microsoft, o MSF Agile. Os participantes aceitos aprendem como se tornar um Scrum Master e como fazer uma equipe de desenvolvimento, um projeto ou uma organização ser ágil e ter sucesso. Exercícios, estudos de caso, e exemplos são usados para entender como ser um Scrum Master. Objetivos Cada individuo será treinado para ser capaz de assumir as seguintes responsabilidades: Remover as barreiras entre o desenvolvimento e o cliente, para que o cliente dirija o desenvolvimento. Ensinar o cliente como maximizar o ROI e alcançar os seus objetivos através de Scrum. Melhorar a vida da equipe de desenvolvimento através da liberação da criatividade e o fortalecimento. Melhorar a produtividade da equipe de desenvolvimento de todas as formas possíveis Melhorar as práticas de engenharia e suas ferramentas, para que todo incremento de funcionalidades seja potencialmente entregável. Metodologia de Treinamento Usaremos muitos exercícios durante o treinamento. Depois do treinamento não somente você entenderá Scrum, como sentirá a diferença. Este treinamento oferecerá o sentimento do Scrum em si mesmo. O primeiro dia é dedicado ao porquê e à Filosofia do Scrum. Durante o segundo dia cobriremos as ferramentas e o Como do Scrum. Usando estórias, estudos de caso e experiências ensinaremos a metodologia Scrum e como aplicá-la para ser um gerente de projetos ágeis, um Scrum Master. Graduação Na graduação, ao término de um treinamento de sucesso, cada participante recebe uma licença e uma cópia da metodologia Scrum, materiais de treinamento de Scrum e software de gestão de projetos com Scrum. Também, Certified Scrum Masters são autorizados a participar no desenvolvimento "aberto" da metodologia e do software, assegurando o crescimento do corpo de conhecimento a partir de um grupo competente e qualificado de profissionais certificados. Participantes que tenham sido treinados com sucesso tambem serão adicionados na lista de Certified Scrum Master em www.ScrumAlliance.org. AGENDA Fundamentos de agilidade e Scrum, executando projetos com Scrum, planejando e escalando projetos Scrum, desenvolvimento offshore usando Scrum, orçando contratos de preço e data fixos, assegurando as práticas de engenharia. O que é Scrum? Porque Scrum funciona O que é a arte do possivel? O que é o fluxo do Scrum? O que significa desenvolvimento iterativo e incremental? O jogo Scrum 59 Planejamento e estimativas ágeis Retrospectivas de Sprints Como implementar Scrum a partir de uma posição sem poder A diferença entre planejamento e uma reunião de planejamento Planejamento estrategico e planejamento tático A reunião do Scrum e como trabalhar com uma lista de tarefas O jogo da Velocidade - planejando e fazendo em ação Escalando Scrum Onde e Quando? Dias 17 e 18 Novembro de 2008 As classes iniciam as 8:30 com o registro No primeiro dia a aula termina às 18:00 e no segundo dia às 17:30 Coffe-break Materiais do curso Toda a metodologia e materiais de treinamento serão disponibilizados. Uma licença individual para o uso destes materiais será fornecida aos participantes que completarem o programa de certificação com sucesso. Os materiais estão em inglês e são atualizadas a cada treinamento. O material é melhorado usando mais slides, videos e fotos caso o treinador creia que seja útil durante a aula. Certificação A certificação como um Scrum Master significa que alguem que implementou e provou ser capaz de usar Scrum em diferentes contextos treinou você. Ele experimentou Scrum no mundo real e tem a confiança de Ken Schwaber como alguém capaz de oferecer este conhecimento aos seus alunos. Investimento O investimento para este workshop e a certificação é de R$ 2300,00. Inclui todos os materiais, licenças, certificação, materiais de treinamento, coffe-breaks. Ver formas de pagamento no formulário de inscrição Maiores informações envie suas duvidas e informações de contato para eventos@teamware.com.br Informações sujeitas a mudança sem previo aviso Formulário de Inscrição
Data & Hora:	Monday, 17 November 2008, 8:30 — Tuesday, 18 November 2008, 18:00
Local:	Porto Alegre,
Prazo para Registos:	16 de November de 2008

Uma grande decepção

2008-09-23T10:49:00.002-03:00

Eu sou daqueles que me sinto um idiota quando noto que alguma convicção minha vai por água abaixo. Principalmente com relação à pessoas.

Lembro que no meu último semestre da faculdade, enquanto fazia o meu trabalho de conclusão, estava fazendo apenas uma disciplina. E o professor da disciplina era daqueles professores que encantavam na aula: falava muito bem, dominava o assunto como ninguém, trazia situações e cases de empresas, etc. Mais ou menos o perfil de um professor de MBA, como estou tendo hoje.

O professor era tão bom que decidimos, em unanimidade, que ele seria o paraninfo da nossa turma que iria se formar. E foi, de fato.

Após a faculdade, procurei de alguma forma manter contato com ele. Lembro de ter tentado organizar uma palestra dele, sobre segurança na internet, para um evento que tentei organizar, online. Ele se mostrou bastante solícito e aceitou, mas infelizmente o evento acabou não saíndo.

Sempre vi nele o tipo de profissional que vale quanto pesa. Não digo que foi um modelo que eu segui, mas era um profissional que eu admirava.

Ele então se tornou presidente de uma grande organização estatal aqui no RS. E foi então que a minha convicção começou a ruir. Começou a ter o seu nome envolvido em escândalos... o último, publicado na Veja desta semana. Um colega do MBA que o conhece há algum tempo, afirmou que infelizmente isso tem tudo para ser verdade, devido ao seu comportamento anterior a este cargo.

E aí? Como se sentir vendo que aquele profissional que a gente admira age na verdade como alguém sem ética e responsabilidade?

Eu atualmente estou me sentindo um pouco como um idiota. Como se tivesse sido enganado... a mesma situação que todos nós sentimos quando elegemos e acreditamos em políticos e eles nos racham a cara. O problema foi descobrir que alguém tão perto é assim.

Uma pena. De verdade.

Posicionamento... você sabe qual é o seu?

2008-09-22T09:55:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Estávamos discutindo numa das aulas de marketing no MBA sobre um assunto que está diretamente ligado ao nosso marketing pessoal: posicionamento.

O assunto iniciou com o conceito de posicionamento, no Marketing tradicional, ou seja, como as empresas querem ser vistas pelos seus clientes. Foram demonstrados alguns exemplos de marcas e tínhamos que falar a primeira coisa que viesse na cabeça. Exemplo:

Brastemp: Qualidade, "Não é uma Brastemp"

CCE: Tecnologia ruim, equipamento popular

Mastercard: "Não tem preço"

FEDEX: Agilidade, qualidade, "Wilson e Náufrago"

Então começamos a discutir sobre o posicionamento na nossa vida profissional. E isso está ligado diretamente a como as pessoas nos vêem. Se você lembrar da janela de Johari, conceito de feedback, seria o quadrante "como os outros nos vêem / desconhecido para nós". Você já parou para pensar nisso?

Quando alguém menciona o seu nome, para alguma atividade, como os outros reagem? Pense na situação a seguir: seus chefes estão discutindo sobre sua nova alocação e um deles o sugere para um projeto novo e desafiador. Qual seria a reação do outro chefe?

Pois esta reação é exatamente o nosso posicionamento. E mudá-la é uma tarefa que depende exclusivamente da gente. Ou vocês acham que uma "CCE" não luta com todas as forças para fugir do esteriótipo que recebeu?

Agora numa coisa nós todos temos que concordar. Pior do que ter um posicionamento negativo é simplesmente NÃO TER um posicionamento. Já pensou se quando comentam sobre seu nome, ninguém consegue classificá-lo? "O Flávio? Ahmm... pois é."

Uma boa coisa para pensarmos para essa semana.

Um abraço!

Propaganda

2008-09-17T12:11:00.002-03:00

Coordenador de Projetos (pleno)
Requisitos: Ter atuado como Coordenador no mínimo em dois projetos. Conhecimento de Gerenciamento de Projetos, Coordenação de Equipes, Framework (Struts , Axis), Servidores de Aplicação (Websphere), conhecimento de SOA, conhecimento de Portais, Padrões de Projetos e boas práticas de JAVA (MVC,Conceito de Camadas), Redes, Orientação a Objetos,Metodologias ágeis, SQL ou PL/SQL, Sistemas De versionamento Subversion e CVS. Inglês Fluente. Ensino Superior Completo , desejável Pós-Graduação. Remuneração a combinar

Faltou um "Desejável ser parente de Deus". Mas o mais divertido é saber tudo isso e "remuneração a combinar". Sabemos o que isso significa né? hehe

Negociação de salário

2008-09-16T23:03:00.006-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

EDITADO: Estou mudando a minha forma de expressar os valores, pois houve muita confusão (que idéia absurda a minha fórmula). Parece que eu aceitei redução salarial hehe OBS: Nosso salário anterior era bem inferior ao mercado, então os aumentos não são abusivos, pode acreditar.

Hoje tive um dia tenso e importante. O dia da negociação do meu salário. Esse é um dos momentos mais complicados no mundo corporativo. É difícil imaginar que todos entrem na reunião tranquilos de suas posições. O atrito sempre vai ocorrer, embora no meu caso o atrito tenha sido bem pouco.

Anteriormente a reunião, eu e o meu colega havíamos combinado nossa posição. Usei algumas técnicas de negociação para isso.

QUEREMOS: 94% de aumento por 8 horas (X+3)

NOSSO OBJETIVO É: 66% por 8 horas (X)

ACEITAMOS: 55% por 6 horas (X-1)

ACEITAMOS: 38% por 4 horas (X-2)

CAIMOS FORA: 27% ou menos (X-3)

O que isso significa?

"Queremos" indica o valor que iremos começar a reunião. É aquele valor que indica nossa aspiração futura, mas sabemos que será difícil de atingir. "Nosso objetivo" indica o valor com o qual iremos fincar nossa posição. Iremos lutar MUITO para conseguir isso. "Aceitamos" indica aqueles valores um pouco abaixo, que a gente até aceita, mas deixamos claro que não ficamos satisfeitos ou que merecíamos mais. "Caimos fora" são os valores que a gente nem considera... já que a própria empresa está nos desvalorizando.

Eu e o meu colega nos armamos com alguns dados interessantes. Se você quiser, pode baixar na seção de downloads do site as médias salariais de gerentes de projetos e de profissionais de TI (esse último, eu confesso que está bem inflacionado!). Além disso, nos preparamos levantando questões como a nossa formação, nosso tempo de casa e resultados no período, projetos, etc.

Depois, analisamos quais seriam as situações que enfrentaríamos. Sempre consideramos o caso ruim, onde eles ofereceriam 38% por 8 horas. Nossa meta seria tentar chegar o mais próximo do nosso objetivo, que era 66% por 8 horas. Caso não houvesse acordo, iríamos trabalhar na segunda variável, as horas de trabalho.

Então, fomos convocados pelos diretores. Na planilha que enviamos para eles, o valor que sugerimos para nós era de 94% por 8 horas ("queremos"). A idéia era realmente mostrar e justificar as nossas expectativas, que era um valor aderente ao mercado.

Eles nos chamaram. Ao entrarmos na sala, notei que os três diretores estavam meio desconfortáveis... um olhava para o celular, outro mexia as mãos e o outro estava bem irriquieto. Era um sinal de que nosso 94% não seria o oferecido... a dúvida era, qual será o valor então?

Começamos a reunião com os diretores fazendo aquela milonga de "vocês são muito importantes, por isso a reunião é delicada, queremos mantê-los, não é que não vamos valorizá-los... achamos que vocês merecem aquilo que pediram... bla bla bla". Discutimos sobre questões mais macro por alguns minutos... inclusive sobre equipes que comporão o projeto. Discutimos como funcionarão as atividades... enfim, um legítimo balão para justificar valores.

E então, o valor. E eles deram mais uma enrolada e falaram:

"Bem, na atual situação, como temos uma verba de projeto que deverá compor boa parte do RH, o valor que conseguimos chegar para vocês foi de 66% por 8 horas."

Sim, exatamente o LIMIAR INFERIOR do nosso "aceitamos", com a diferença na carga horária (maior do que prevíamos). Na hora já demonstramos um pouco de descontentamento. Comentamos sobre mercado, responsabilidades... mas infelizmente não entramos na questão de formação/experiência (acho que teria sido interessante).

Eles então vieram com a idéia desse valor ir aumentando conforme a produtividade. Foi uma deixa legal para mim.

Fiz a simples questão: "Ok, mas o que vocês consideram produtividade? Como isso vai ser medido? Vai funcionar para a empresa e para o grupo?".

E então dai todos opinaram e deram suas posições, mas claramente NINGUÉM soube responder isso. Eu citei então que até mesmo empresas como AMBEV e GERDAU, que são enormes multinacionais, tem algumas dificuldades para definir indices de produtividade. Além disso, comentei de um projeto em que eu e o meu colega estávamos. Eu e ele saimos de um cliente e no dia seguinte passamos a limpo a reunião, discutimos a proposta e... nada. Só depois de UM MÊS é que os diretores solicitaram o nosso documento para fazer uma proposta ao cliente. Ou seja, como avaliar uma produtividade se o gargalo será sempre da (des)organização da empresa?

O meu colega então resolveu participar falando diretamente sobre os valores. Perguntou se a proposta era final ou se iríamos negociar. E eles falaram que não havia como negociar... aquele valor era o final. Aqui foi um dos momentos mais difíceis da reunião. Havíamos combinado que fincaríamos o pé para tentar subir o salário. Só que acabamos descobrindo que a oferta inicial deles seria de 27%!!!!!! Então eles subiram para 38% pouco antes da reunião. Por MUITA sorte deles, eles não ofereceram esse 27%, pois senão também seria inegociável para nós... iríamos cair fora, com certeza.

O meu colega esperava que eu ficasse ao lado dele para negociar um aumento. Só que para mim, havia ficado bastante claro que eles não aumentariam. Nós iríamos brigar pelo aumento, mas nunca chegaríamos em 66%. Na minha opinião a gente passaria de 38% para 40% ou 42%. E sinceramente, eu não acho que valeria criar um atrito por tão pouco.

Como eles comentaram que a idéia é de que a cada 6 meses / 1 ano ocorra um reajuste, eu assumi para mim o seguinte: dentro de 6 meses irei solicitar o reajuste. E isso que me guiará nas decisões futuras.

Eu resolvi então adequar a proposta ao mais próximo do nosso limiar. 38% por 8h era inviável. Então comentei que nossa proposta seria de 38% por 6h (no início, seria 4h, mas obviamente, nas circunstâncias apresentadas, isso não aconteceria). Foi um momento de desconforto para os diretores, agora... eles ficaram se entreolhando, conversaram um pouco... e aceitaram.

Logo, acabamos fechando por 38% por 6 horas. Só que na minha visão, dentro de 6 meses eu estarei batendo na porta deles, solicitando um reajuste para 66%. E daí sim serei bastante exigente.

Algumas coisas que foram ditas na reunião pelos diretores e que valem a pena serem registrados aqui. Obs: eu não lembro se cheguei a falar alguma coisa que me arrependi... acho que me arrependi de não ter replicado alguma das frases abaixo.

a) "Vocês tem que lembrar que também existem muitas pessoas que tem muito mais experiência que vocês e que estão ganhando mais, no mercado".

RESP: EU NÃO RESPONDI ESSA!!! Nossa, como eu me arrependo. MUITO. A resposta seria simples: Como é?? Eu sinceramente não conheço NINGUÉM em TI do nosso nível que esteja ganhando menos. NINGUÉM. A nossa proposta objetivo era simplesmente a média do mercado. O que eles nos ofereceram era MUITO INFERIOR. Mas aceitamos por motivos alheios, além da redução da carga horária. Ah sim, e por favor... eu também conheço muita gente que está trabalhando de graça. Isso é parâmetro? Numa reunião de TI usar essa frase é dar cinco tiros no pé. E EU NÃO APROVEITEI!!!!

b) "A produtividade não pode ser medida por projetos finalizados. Senão vai gerar conflito... o Flavio vai querer saber porque o colega dele tem mais projetos, ou vice-versa".

RESP: Droga, outra que eu não respondi. Essa foi dita até de forma "inocente", assim por dizer. Pois não é nada que iria ocorrer. Só que, como assim "conflito"? Poxa, eu me senti comparado com uma criança mimada brigando com o irmão por um brinquedo. Mas ok, essa até não me arrependo pois não influenciaria em nada.

c) "O valor de X+3 que vocês querem, se conseguirmos alavancar a empresa, vocês poderão estar recebendo ao final do projeto, daqui 3 anos".

RESP: Opa, essa eu me arrependi também! A resposta é bem fácil também. Senhores, dentro de três anos eu espero estar ganhando 122%!

Enfim... fazendo um balanço da reunião, acredito que não conseguiria definir como ganha-ganha, perde-ganha, ganha-perde. Foi um empate com ligeira vantagem para eles. Só que com a diferença de que dentro de 6 meses iremos bater na porta deles. Para chegar em 66%. E daí seremos incisivos.

Eu considero que fui tranquilo. Estava mais tranquilo do que eu imaginei. Talvez por estar ciente da minha posição e também ver que o nervosismo era DELES e não nosso.

Espero que essa minha pequena história de negociação de salário possa dar uma luz para meus leitores que possam vir a passar por essa situação.

O que eu posso dar como dicas finais são:

1) Tente definir uma estrutura similar aquela que eu descrevi. Queremos, objetivo, aceito e caio fora. Isso vai ajudar vocês a se balisarem nas suas decisões.

2) Procure levantar dados do mercado e dados concretos sobre suas contribuições. Vale número de projetos, resultados alcançados, tempo de casa, habilidades, etc.

3) Com base no cenários do item 1 levante cenários. "Se eles oferecerem isso, o que faço? O que apresento? Como argumento?". Defina principalmente como agirá para os casos terríveis, como eles te oferecerem o "caio fora".

4) Tente de toda a maneira embasar a posição do valor "objetivo". Mas comece sempre citando o valor "queremos/quero". Se você começar direto pelo "objetivo", você corre o risco do seu chefe achar que você está dando o valor máximo e daí nunca vai chegar nele. Use o "queremos/quero" como base de que você merece. E tente ser difícil para aceitar o objetivo. E dai aqui sim, seja bem incisivo. Só baixe disso, se conseguir outras vantagens (como no meu caso, carga horária).

5) Se por ventura o seu chefe chutar o limiar baixo, e disser que é inegociável, daí você poderá tentar arriscar o item 4 ou então negociar somente benefícios e perspectivas. "Ok, aceito temporariamente. Mas dentro de 3/6 meses quero negociar".

6) Seja sempre honesto e transparente. Argumente e questione. A reunião ideal é que seja um GANHA-GANHA, com todos saindo da reunião com a sensação de que estão satisfeitos.

7) E nunca, mas NUNCA leve a reunião para o lado emocional. NUNCA! Evite a todo o custo usar frases como "eu estou me esforçando muito aqui dentro" e afins. Você perde toda a credibilidade... esse foi uma das primeiras coisas que eu e o meu colega cortamos fora da nossa pauta: nada de emocional.

Eu não sou um especialista no assunto, mas com base no que li e que vivenciei hoje, principalmente, posso deixar essas dicas para vocês.

Espero que gostem.

Um grande abraço

Efeito globalização

2008-09-16T12:44:00.002-03:00

A globalização tem efeitos engraçados nas nossas vidas.

O caso do meu cunhado: ele trabalha em uma consultoria multinacional. Passou a segunda-feira INTEIRA sem poder trabalhar. Motivo: a sede da empresa que gerencia todas as contas de emails e intranet, nos EUA, foi afetada por um desses furacões que ocorreram lá. Caiu todas as conexões e como eles usam muito o webmail, ficaram sem internet!!

Absurdo isso, não? Agora vem a pergunta... será que isso foi levantado na questão de "riscos"?

Agora a outra pergunta: será que VOCÊ levantaria essa situação como um risco?? hehehe

Abraços!

Renault x GM

2008-09-16T00:42:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Carlos Bichara Ghosn é um dos grandes executivos e líderes mundiais. Ele foi o responsável pela milagrosa ação para salvar a Nissan, intitulada NISSAN 180. Hoje é presidente da Renault.

Durante uma aula do MBA, discutíamos sobre tomadas de decisão de executivos. O professor comentou que o Carlos BG costuma tomar decisões em minutos. Uma equipe vem sugerir um novo modelo e ele apenas aprova ou não.

Daí uma colega perguntou:

- Professor, por que a GM demorou tanto para entrar no mercado de utilitários?

E ele respondeu:

- A Renault trabalha na forma que citamos. O Carlos BG aprova ou não as decisões em 5 minutos, no máximo com base em várias informações de qualidade (e também por estar cercado de pessoas exemplares). A GM, cada sugestão como a inclusão de um novo modelo, passa por uma comissão de avaliação, tem um vasto estudo, etc.

Para pensar... :)

-----------------

EDITADO: uma entrevista (em inglês) com o Carlos BG

"15 anos de casa..." e outros chavões dos chefes..

2008-09-15T11:26:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Na sexta-feira eu e o meu colega tivemos uma reunião bem informal com o meu chefe. Estávamos discutindo sobre o novo projeto que entrou (e que o pagamento já foi feito). Discutimos sobre a equipe, perfil, valores (salários da equipe e nosso), etc. Sem se aprofundar muito, bem informal mesmo. Tanto que em seguida já estávamos falando de outros assuntos.

O que me chamou a atenção foi que por diversas vezes o meu chefe utilizou a expressão "Olha, eu tenho 15 anos de casa", também variando para "15 anos de janela" ou "15 anos vendo isso acontecer". Isso me chamou a atenção mais ainda quando ele brincou sobre as reuniões que eu estava organizando (usando o SCRUM). "Me assusto só de ver aquele monte de papel que tu usa!", foi um dos comentários.

Felizmente eu tenho a certeza que em pouco tempo ele vai começar a entender o motivo da papelada. É aquele conceito do "always visible", ou seja, escrevemos user stories em papel, criamos a taskboard física e tudo mais, exatamente pela simplicidade de acessar os dados e informações. Nada melhor do que ter tudo isso fisicamente presente ao lado da equipe. E daí fica aquela questão: valeria a pena passar tudo para o computador, e depender de que o time veja isso diariamente? Eu tenho dúvidas que isso aconteceria ("pelos meus 4 anos de casa" hehe).

Voltando a essa frase, eu comecei a pensar quantas pessoas devem possuir chefes que realmente pensam e agem dessa forma.

Eu tenho xx anos de casa, portanto...

... sei que isso não irá funcionar!
... não sei para que manter essa mudança!
... conheço todos os processos!
... acho que as coisas funcionam da forma que estão!

E assim vai.

Será isso arrogância? Auto-suficiência? Resistência à mudança? Acho que depende de chefe para chefe. O meu eu acredito que não seja nenhum desses, mas ele costuma utilizar outra frase que me deixa realmente LOUCO nas reuniões.

"Para desenvolver esse [sistema/banco de dados/tarefa/etc] eu acho que uma semana está mais do que bom".

O pior é que ele costuma falar que "Nos meus pequenos conhecimentos de banco de dados..." e dai depois termina com um "acho que o desenvolvimento dele é simples e demora 3-5 dias".

Enfim, chefe que é chefe vive de chavões. O grande problema é quando ele leva isso tudo a sério demais. E quando nós, os gerentes e colaboradores, somos efetivamente cobrados devido a esses chavões...

Rápido resumo da semana

2008-09-12T00:44:00.003-03:00

Pois então, essa semana foi bastante corrida, vou resumi-la aqui em poucas frases:

+ O meu chefe (aquele do email ... ), não é que ele colocou os pingos nos i's para os outros diretores? Falou da necessidade real de marcarmos uma reunião para discutir equipe, comunicação, motivação, etc. EXCELENTE!

+ O meu projeto atual está recebendo muitos elogios por estar totalmente nos trilhos. E isso não significa "controle" mas sim que o projeto está agradando aos diretores E principalmente ao cliente! E eles me vêem bastante motivado no projeto, o que passa uma sensação de que tudo está muito bem. E atualmente está! :)

+ O nosso projeto de pesquisa foi aprovado!! A verba acabou de ser depositada. Aleluiaaa! Agora poderemos montar uma equipe de verdade!

+ No meu MBA estou tendo aula de Marketing de Negócios com um excelente professor. Marketing por si só já é interessantíssimo. Quando o professor ainda é ótimo e traz cases sensacionais, a aula me faz sair de casa às 19h numa noite chuvosa e com transito transtornado, para ir até o MBA e assistí-la.

+ Meu home-theater chegou!!! :) Agora finalmente terei mais vontade para assistir a filmes na televisão!!

Enfim. Tudo está legal! Tão legal que dá até medo do que vem pela frente.......... hehehe

Abraços!

Enferrujado!

2008-09-09T20:02:00.002-03:00

Eita, hoje eu vi como estou enferrujado!

Resolvi pegar o meu projeto atual e transformar todas as funcionalidades em user stories. Quando comecei a explicar para os meus dois colaboradores, eu comecei a ver como eu estava bem enferrujado devido a mais de três meses sem praticar.

O resultado foi a discussão de detalhes excessivos em alguns casos! Detalhes técnicos!!!! E no início do projeto!!!!

Quando me dei por conta, já havíamos perdido boa parte da reunião e então continuei apenas tentando listar e quebrar as funcionalidades em estórias. Deixei o detalhamento de lado. Ainda bem!

Não adianta, as técnicas de agile acabam sendo como tênis: se não praticar, a gente acaba ATÉ jogando... mas bem meia-boca! :)

Anyway, hoje recebi a notícia de que nosso projeto de pesquisa teve a parte financeira aprovada!! Ou seja, poderei começar a pensar na equipe definitiva! Aleluia!

Ah sim, essa semana vou começar a planejar a adaptação do Zoho Projects para SCRUM. Vai ser uma coisa bem adaptada, mas vai dar certo, pelo menos na teoria!

Abraços!

Situações... você se identifica com alguma?

2008-09-08T18:48:00.003-03:00

Situação 1

A sua diretoria acerta um projeto com um cliente e então o aloca para "gerenciar" o projeto. Você acaba trabalhando com uma equipe que não é a mais indicada para o projeto e o resultado é uma sucessão de bugs no sistema. O cliente começa a ficar descontente. Porém, ao invés de resolver as pendengas com quem acertou diretamente com ele (a diretoria), o cliente desconta no gerente! Liga a toda hora para reclamar, esbravejar, etc. O gerente acaba recebendo a culpa por um projeto já fadado à morte.

Situação 2

A diretoria então "aprendeu" com esse "erro" acima. Agora, isola o gerente do cliente. Qualquer dúvida técnica é para perguntar diretamente para os diretores. Eles entrarão em contato com o cliente (assim que puderem) e questionarão a dúvida repassada. Se for necessário um outro esclarecimento, todo o processo é refeito. Esse processo, aliás, que poderia ser resolvido em menos de uma hora, acaba levando uma tarde, um dia, uma semana... mas tudo para proteger o gerente.

Situação 3

A diretoria deixa um assunto estourar no prazo. Então passa a bola para os gerentes. "Vocês podem pegar o equipamento no cliente, já que eles não estão mais usando, até amanhã de manhã no máximo? Vamos precisar para apresentar outro projeto". Ok. Vamos até o cliente - cujo projeto em que envolvia os equipamentos foi fracassado - e tentamos retirar o equipamento. Os responsáveis dizem que não foi avisado nada de retirada e que sem ter o aval do diretor deles, não podem fazer nada. Os gerentes ficam de mão atadas, novamente.

Situação 4

A diretoria deixa outro projeto estourar no prazo. Então aloca um gerente e uma equipe para um projeto, de uma hora para a outra. Passam as informações do projeto em uma hora de reunião e esperam o projeto pronto em, no máximo, UMA SEMANA. Qualquer tentativa de analisar mais a fundo o projeto é vista como desnecessária. "Vocês já tem as informações que precisam". A equipe enlouquece e dois abandonam o barco por não concordar com a situação. O gerente acaba sendo desenvolvedor, analista, DBA, testador e, se sobrar um tempinho, até gerente!

Situação 5

A diretoria reconhece que os processos e projetos estão mal-conduzidos e que muito é por culpa deles. Eles afirmam que isso não pode mais acontecer e cobram-se, uns dos outros. Entendem que os gerentes estão fazendo o possível para resolver os problemas dos projetos. Se comprometem em mudar a situação, principalmente quando a coisa começa a doer no pior lugar de todos (no bolso). Infelizmente, essa situação 5 acaba acontencendo normalmente ANTES das situações 1, 2, 3 e 4. Ou seja, a aclamada mudança não ocorre.

Conclusão

Se você, caro leitor, já vivenciou situações parecidas deve saber que muitas vezes nossos superiores acabam se esforçando para complicar mais do que apoiar. A pergunta mais difícil a ser respondida (talvez tanto quanto "De onde viemos e para onde vamos?") é:

Como mudar essa mentalidade e cultura?

Recomendaria ao PMI a inclusão de mais uma área de conhecimento. LIDANDO COM OS CHEFES.

Protótipo e o cliente

2008-09-05T21:23:00.003-03:00

Uma das coisas mais discutidas no mundo da TI é a utilização ou não de protótipos para apresentar ao cliente. Eu particularmente sou contra. O motivo é simples: clientes, em TI, tem expectativas altas! Se a gente apresenta algo que não condiz com a realidade, podemos ter situações como as que eu cito abaixo:

Situação 1

Desenvolvedor: Queremos mostrar para vocês o que estamos pensando sobre o sistema para vocês. Aqui a gente tem a tela de cadastros... mas ela não está funcionando...

Cliente: Como assim???

Desenvolvedor: É que nós achamos que não seria interessante implementar agora.

Cliente: Hmmmmmmmmm...

Situação 2

Desenvolvedor: Teste o sistema de navegação do site, por favor.

Cliente: Claro! Poxa, tá bem bonito. Vou clicar aqui e... ué. Nada aconteceu!

Desenvolvedor: Ah sim, é que... bem, isso é um esqueleto do sistema, só para avaliação da interface.

Cliente: Hmmmmmmmmmmmmmmmmmmm...

Quem nunca passou por isso? É normal! E mesmo assim a gente continua trabalhando com protótipos. Hoje, por exemplo, fomos demonstrar o nosso protótipo para o cliente. E tivemos SUCESSO! Eles gostaram bastante do que viram. E era um protótipo.

Dai vão dizer: "Ahh o Flávio tá se contradizendo!". Que nada! Os clientes aprovaram o sistema, mas se tivessemos demonstrado já algo funcional e que gerasse valor a eles, o resultado não seria um "OHHH!" de boca aberta e emocionado?? Com certeza sim. Quando a gente trabalha com protótipos, normalmente estamos nas fases iniciais do projeto. Onde a relação com o cliente ainda não está bem firme. É importante conseguir encantá-lo logo cedo para conquistá-lo. E dessa forma se tivermos futuros problemas tudo poderá ser bem mais facilmente administrado.

Además, o meu projeto não é um projeto ainda. Foi uma "batata quente" que eu recebi para descascar e dar um jeito. Fiz o que eu pude, no curto prazo. E graças às pessoas competentes que estão desenvolvendo ("Hurra!") tivemos algo bem bacana.

O grande e principal problema de um protótipo como o nosso? Todo ele foi "fake". Isto é, iremos aproveitar bem pouco dele. Foi feito numa realidade onde precisávamos cumprir um prazo para apresentar algo pro cliente, e não houve tempo de modelar todo o sistema final. Então fizemos "módulos" para apresentar como cada um funcionaria. Quase sem nenhuma integração entre um e outro.

Ufa! Apesar de tudo valeu. Mas eu já cobrei do cliente, para a próxima reunião, a priorização das funcionalidades por ordem de valor e importância. Assim começaremos a trabalhar de fato no que realmente vale a pena!

E assim acaba mais uma semana.

Um grande abraço e ótimo final de semana pra vocês. Descansem! :)

Revista Época Especial - As 100 melhores empresas para se trabalhar

2008-09-03T23:58:00.002-03:00

Se você procura algo legal para ler, sugiro a edição especial da Época, que traz as 100 melhores empresas para se trabalhar.

Uma excelente forma de conhecer as culturas e práticas destas empresas. A revista traz algumas matérias e destaca as melhores práticas de cada uma delas.

Vale a leitura!

Contrastes

2008-09-03T21:53:00.003-03:00

Hoje eu vivi dois contrastes ao mesmo tempo.

Enquanto o meu projeto está nos trilhos, com meus dois colaboradores trabalhando com as tecnologias que conhecem e gostam, o meu colega está em apuros.

Ele está fazendo a implantação de um sistema em um cliente de forma "sob demanda", isto é, eles desenvolvem, vão lá, implantam, coletam os bugs, voltam, desenvolvem, implantam... e assim vai.

Só que ele está com dois colaboradores que não tem a menor vontade de trabalhar em rítmo de empresa. Eles querem trabalhar com pesquisa. Então o comprometimento é quase inexistente.

Dai eu pergunto: de quem é a culpa?

Eu me atrevo a dizer que na atual situação, não é de ninguém... mas é de todos. Não é de ninguém pois atualmente o grupo está dependendo do projeto que irá ser aprovado em breve. Esse "em breve" já dura alguns meses, mas a esperança é a última que morre.

É de todos pois foram alocados para o projeto duas pessoas que não queriam trabalhar neste projeto. E também porque toda negociação com o cliente foi horrível... esse processo que está sendo feito para desenvolvimento é muito ruim! É o legítimo "queima-empresa".

Um grupo de pesquisas que tenta trabalhar como empresa vai sofrer sempre com essa crise de identidade, e porque não dizer, de competências.

Valorizando a comunicação!

2008-09-02T12:16:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Eu não estou me baseando em nenhuma pesquisa da Chaos Report ou afins. Estou falando pelo meu feeling com base no que converso com colegas e também no que leio por aí.

Eu diria sem medo que 90% das causas de falhas em projetos estão diretamente ligadas a comunicação. Eu considero isso como sendo:

- Falta de comunicação entre cliente / equipe
- Falta de definição correta de requisitos
- Falta de comunicação entre diretoria / gerência
- Falta de comunicação entre gerência / equipe
- Falta de comunicação entre equipe / equipe

Ufa, a lista seria grande. Sabendo disso, penso que seja essencial que pessoas que trabalham e lidam com pessoas diariamente invistam no aprimoramento da comunicação. Eu fiz isso este final de semana!

Realizei um curso, aqui em Porto Alegre, de "Dicção, desnibição e oratória", ministrado pela fonoaudióloga Bianca Aydos. Um curso de três dias (sexta à noite, sábado e domingo à tarde). E posso dizer que foi uma das melhores decisões que tive no período!

O curso me possibilitou identificar algumas falhas na comunicação que eu possuo (como falar muito rápido e não articular as palavras corretamente) além de vislumbrar que eu consigo passar (na forma "não-verbal") a mensagem corretamente, seja por gestos, seja pela maneira como eu interajo com os interlocutores.

O bacana da realização de um curso deste é que nossos colegas também estão lá pelo mesmo motivo. Portanto eles acabam nos auxiliando e incentivando para evitarmos os vícios de linguagem ("né", "ããããhm", entre outros) e também a desnibir, já que muitos procuram o curso exatamente pelo pavor que tem em falar em público.

O curso não te deixa 100% melhor, nem poderia prometer isso. A idéia é mostrar que há sim um caminho para a mudança. Aprendemos técnicas, postura, formas de enfatizar a mensagem, maneiras de driblar a ansiedade e a timidez... Se não nos melhora 100%, nos prepara para isso.

O curso foi excelente e recomendo a todos que busquem um curso similar. Agrega MUITO para nossa vida pessoal e profissional.

A foto da turma:

De pé: Leonardo, Renato, Daniela, Jaqueline, Joice, Flávio, Marcos.
Agachadas: Bianca, Luciana e Vanessa.

Enfim, para quem é de Porto Alegre e região, recomendo o curso com a Bianca :)

Um abraço e boa semana.

Relato de um "recém-PMP"

2008-09-01T19:04:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Este relato eu tirei de uma das listas que eu assino. É do Newton Chaves Krás Borges, que recém virou PMP e contou o seu relato para servir como lição aprendida. Achei tão interessante que resolvi publicá-lo aqui no Blog. O relato foi dado na lista da empresa que ministrou o curso (que eu já fiz), portanto não omiti o nome por achar que a PmTech realmente merece ser citada.

Como todo processo que termina em uma prova trás alguma ansiedade, gostaria de compartilhar a minha experiência com os demais membros do grupo.

Espero assim desmistificar um pouco todo o processo e mostrar, que qualquer um que tenha um plano e esteja comprometido com ele pode obter a certificação PMP sem problemas.

Não tenho a pretensão de criar uma receita, mas sim um relato que sirva de benchmark para outras pessoas.

Quando decidi que queria desenvolver uma carreira como gerente de projetos, fiz um curso sobre a metodologia de gerenciamento de projetos do PMI. No final do mesmo, como estava trabalhando num projeto que me tomava muito tempo, e por que não dizer estava com preguiça de estudar, não quis fazer aprova.

Passados dois anos e meio e agora já com alguma experiência e com algum tempo de sobra para me preparar, decidi obter a certificação PMP, para tanto segui o seguinte roteiro:

1. Associei-me ao PMI e comprei a versão impressa do PMBOK;
2. Comprei o Livro "Certificação PMP" do Armando Monteiro, Editora Brasport;
3. Iniciei uma rotina de estudos de 20h semanais, onde estudava um capítulo do PMBOK (O livrinho difícil de estudar) e o seu correspondente no livro do Armando Monteiro;
4. Finalizado esta etapa, me inscrevi para fazer o curso da PMTech;
5. Durante o curso, segui com a mesma rotina de 20h semanais de estudos. Só que agora eu estudava pela apostila do curso e pelo livro "Como se Tornar um Profissional em Gerenciamento de Projetos" da editora Qualitymark;
6. Após o final do curso e depois de terminar a parte teórica dos meus estudos, comecei a fazer os simulados;
7. Fiz três simulados, do programa oferecido pela PMTech, com as seguintes notas: 7,2; 7,24; 7,2 e 8,15;
8. Ao final de cada simulado eu analisava os erros e os acertos, numa espécie de revisão da matéria;
9. Neste ponto eu me dei conta de que a maioria das questões que eu estava errando eram as questões ditas subjetivas: a melhor, a primeira, etc. E o pior era que em algumas vezes eu não concordava com o gabarito;
10. Percebi também que o esforço para melhorar o meu desempenho não valia a pena, uma vez que o negócio era passar na prova e não tirar 10. Afinal já se passavam dois meses de estudos;
11. Marquei a prova e iniciei uma rápida revisão, relendo a apostila do curso e o livro do Armando Monteiro;
12. Fiz um último simulado onde obtive a nota 8 e fui fazer a prova.

Sobre o curso da PMTech:

O curso é muito bom e realmente prepara para a prova de certificação. É incrível como quase todas as questões e assuntos vistos no curso caem na prova da maneira como são abordados no mesmo.

Parabéns pela forma como o curso está estruturado, o material utilizado é muito bom, as aulas são muito interessantes e instrutivas e o programa de simulados é excelente.

Com relação ao programa de simulados, cabe aqui um registro à parte. Ele está bem parecido com a realidade que você irá encontrar no dia da prova, pelo menos para mim eu não vi nenhuma diferença entre a prova real e os simulados, e para dizer a verdade eu achei os simulados mais difíceis do que a prova.

Sobre a prova

A prova não estava difícil, pelo menos a que eu fiz. A maioria das questões tinha um enunciado curto e direto, mesmo as situacionais. As questões "matemáticas" eram simples e exigiam mais o conhecimento em GP do que em cálculos matemáticos.

O tempo não é problema. Durante os simulados eu terminava a prova entre 30 a 40 minutos antes do término, e adotei a estratégia de controlar o tempo utilizando a métrica de 50 questões por hora.

No dia da prova, ao finalizar a questão número 100, eu estava 15 minutos adiantados e parei para ir ao banheiro e tomar um cafezinho, que está disponível na sala ao lado. No final já estava cansado e decidi diminuir o ritmo terminando 20 minutos antes.

Não marquei nenhuma questão para revisão, não vi necessidade, pois ou a resposta estava clara para mim ou ficava em dúvida entre duas opções e já escolhia na hora.

O que mata a pessoa é o número de questões e o tempo da prova. É muito cansativo. O ambiente é bem confortável e o pessoal é bem prestativo, eu fiz a prova em Porto Alegre, mas acredito que todos os sites tenham o mesmo padrão.

Ao terminar a prova você é convidado a preencher uma pesquisa de satisfação, e só ao final da mesma é fornecido o resultado.

Enquete deste mês

2008-08-29T13:16:00.003-03:00

Olhem que curioso. A enquete deste mês, aqui do blog, foi uma espécie de auto-reflexão de cada visitante.

Notem que tivemos (neste momento em que escrevo) 34 participantes.

44% (15 pessoas) deles estão empregados e DESCONTENTES!

Infelizmente é difícil de inferir sobre o motivo disso. Mas será que é devido a cultura da empresa? Relacionamento no trabalho? Falta de desafios? Subvalorização? Salário baixo?

Confesso que fiquei curioso... mas ao mesmo tempo espero que essa simples enquete (e mesmo o blog) sirva para estes colegas refletirem um pouco mais. Será que não vale a pena trocar de emprego, e sair da zona de conforto? Será que não vale a pena aparecer um pouco mais na empresa, ser mais visto para ser valorizado? Será que esse descontentamento não tem um pouco de nós mesmos?

Enfim, leia este post, em que eu reflito um pouco sobre isso também :)

Um grande abraço e ótimo final de semana.

Curso de dicção, oratória e desnibição

2008-08-29T00:55:00.001-03:00

Finalmente irei fazer o curso! Neste final de semana :)

Ao final do curso, eu vou ver se consigo publicar o vídeo do "antes" e "depois". E daí os meus leitores que tirem as suas conclusões se vale ou não a pena investir num curso de comunicação ;)

Abraços

Ok, eu me rendo!

2008-08-29T00:53:00.001-03:00

Já que ninguém falou nada, eu me rendo sozinho.

Como eu posso falar de "administração contemporânea" e continuar chamando minha equipe de "funcionários"?

O hype agora é COLABORADORES :)

Portanto, me corrijam se virem isso de novo ok??

Abraços

Prova PMP com questão maluca!

2008-08-27T00:25:00.001-03:00

Recebi este email da lista da empresa onde eu fiz o curso de PMP (quando eu aprendi mais sobre o PMBoK). Quem escreve é o Mauro Sotille. Olhem que maluquice o que o PMI fez...

Pessoal,

O debate hoje nos fóruns de discussão sobre a certificação PMP é uma pergunta que tem caído no exame PMP, sobre um tema que praticamente ninguém tinha ouvido falar: BIPERT Float (Flutuação BIPERT).

A primeira resposta é que BIPERT seria simplesmente um erro tipográfico no exame. Posteriormente, começamos a receber relatos que realmente existiria uma flutuação BIPERT e que isto estaria caindo no exame.

Um aluno que fez o exame em 31 de Julho viu esta questão. Foi apresentado um diagrama de rede (PDM – atividade no nó), com aproximadamente 25 atividades e se solicitou encontrar uma atividade BIPERT!!!

Outro aluno fez a prova em 09 de Junho e caiu a mesma questão: Um diagrama atividade-no-nó perguntando qual dos 4 nodos tinha uma “flutuação BIPERT”

Assim começou uma procura louca, a nível mundial, nos inúmeros fóruns de debate, sobre o que seria a flutuação BIPERT.

Vejam o desalento do Andrew Stellman, autor dos livros “Head First” (muito bons, por sinal (http://www.amazon.com/Head-First-PMP-Brain-Friendly-Professional/dp/0596102348 ) : “ Ilooked through the various project management textbooks that I have, and I couldn't find a single reference to anything called "bipert". It doesn't appear anywhere in the PMBOK(r) Guide. There's nothing about it in Wikipedia. It may be an important project management concept that none of us have heard of. If so, I'm not sure how to learn about it. (Every PMP exam has 25 questions that don't count towards the score -- they're experimental questions used by PMI to gauge the exam. I wonder if the bipert question was one of these. I suspect that if you see bipert on the exam, there's a good chance that particular question won't count towards your score... but that is just a guess on my part.) I have no idea how you'd apply that to project management, and I'm surprised it ended up in a question on the PMP exam. If I were taking the exam today and had to know about BIPERT, I'd get that question wrong.”

O que é Flutuação BIPERT?

A resposta certa parece ser que seria a de indicar a atividade com links em ambas as direções.

Até agora há somente um artigo, entitulado "Workload Modeling for Parallel Processing Systems" (escrito em 1995 por Gabriele Kotsis para sua tese de Doutorado – Universidade de Viena), com referências a Bipert. Até 30 de Junho este era o único documento a fazer referência a este termo. A referência a BIPERT pode ser encontrada somente na bibliográfica da tese de 201 páginas. Isto é o que está escrito:

"BIBLIOGRAPHY

P. H. Cubaud. “Evaluation of Parallel Programs Completion Time using Bilogic PERT Networks.” Tech. Rep. 91-7, EHEI, Ecole des Hautes Etudes en Informatique, 45, rue des Saints-Peres, 75006 Paris France, September 1991. In this article a bilogic extension of PERT networks (called BIPERT) is proposed as a suitable model for parallel programs. An example of modeling a parallel wave equation algorithm using GERT networks described in SLAM can be found in [Sinz 93] In [Cuba 91] a bilogic extension of PERT networks (called BIPERT) is proposed as a suitable model for parallel programs. In a BIPERT network, ingoing and outgoing links may either be inclusive (IN) or exclusive (EX), thus allowing to represent amongst parallelism also conditional branches and alternative parallelism, but also dead ends (if a node spawns several inclusive outgoing links, which are collected later on in an exclusive ingoing). Graphs containing such dead constructs are prohibited and called unlegal. A network where all nodes are IN/IN or EX/EX types, belongs to the class of series_parallel graphs, where exact analytic solution techniques are feasible. All other networks are to be solved using simulation or approximation techniques.

“Em uma rede BIPERT, os links de entrada (ingoing) e saída (outgoing) podem ser inclusivos ou exclusivos, desse modo permitindo a representação de paralelismo e de ramos condicionais ....”; ou seja, BIPERT é um tipo de PERT booleano: verdadeiro/falso : vai acontecer ou não este evento.. Assim seria muito difícil calcular a solução analítica exata.

As questões que começaram então a ser feitas:

Porque este termo entrou em um exame PMP?

Resposta: Mistério. Um termo obscuro e não utilizado, que não está no PMBOK.

É parte das 25 questões de teste?

Resposta: Não sabemos

Este tópico tem alguma importância, de modo que o candidato deva aprende-lo?

Resposta: BIPERT não é uma técnica de análise de diagrama de rede e, de qualquer modo, está ultrapassado devido ao uso de ferramentas e técnicas mais modernas de simulação

Este tópico vai estar no PMBOK 4a Edição?
Resposta: Este tópico não está no PMBOK 4a Edição. PERT somente é referenciado no que diz respeito às estimativas de 3 pontos.

Nós (e o mundo), vamos continuar procurando pela resposta correta: Por enquanto a mais certa parece que seria a de indicar a atividade com links em ambas as direções.

Isto É ed. 2024 (Capa do Michael Phelps)

2008-08-23T23:48:00.002-03:00

A IstoÉ da semana passada (esta que é descrita no tópico) traz uma reportagem na página 64 muito interessante e que vale a pena ser lida por todos nós, principalmente aqueles que lideram ou lidam com pessoas.

O título é "Você é o que você fala" e traz algumas dicas para ser ouvido e compreendido num mundo em que cada palavra conta.

Na verdade o texto fala sobre neurolinguistica, uma corrente que muitas pessoas tem restrições. Eu já li um livro curto sobre o assunto e posso dizer que achei bem interessante.

Vamos ao que interessa: a reportagem traz algumas dicas interessantes sobre como mudar a sua forma de se comunicar. Uma simples mudança de palavras já modifica completamente o contexto e a mensagem que estamos passando. Um exemplo simples que a reportagem traz é trocar o "eu acho" por "penso que". Quem nunca recebeu um olhar de desaprovação e desconfiança quando lhe foi solicitado para emitir alguma opinião e a nossa resposta foi "eu acho que até o fim da semana está pronto"? E se você trocasse por "penso que até o fim da semana teremos isto pronto"? Não soa melhor? Sim! Pelo simples fato que "achar" tende a demonstrar incerteza e "pensar" sugere uma elaboração.

Existem na reportagem outros exemplos... vale a pena dar uma olhada.

Só vale ressaltar uma coisa: lembre-se que a comunicação não vive só de palavras. Entonação da voz, expressão corporal... tudo isso passa mais a mensagem do que palavras. Logo se você falar "penso que até o fim da semana teremos o sistema pronto" mas mantiver aquele rosto com a testa franzida, olhar perdido pra cima e algum cacoete como coçar a cabeça, de nada vai adiantar :)

Nós, quando lidamos com pessoas, percepções e expectativas, precisamos MUITO passar confiança no que fazemos. Eu estou buscando mudar bastante isso. Nessa semana, por exemplo, o meu chefe me perguntou do sistema abaixo, se até sexta-feira teríamos ele pronto. Eu falei "Olha, acho que sim". ÓBVIO que o resultado foi que o meu chefe me olhou com aquela cara de "ih, não vai ficar pronto". Vendo a "pataquada" que eu havia cometido, tentei consertar com um "... depende do que tu queres pronto!". Não foi a melhor resposta possível, mas ajudou a minimizar o estrago! Mas de qualquer forma, como você pode ler no post anterior, não só entregamos o sistema como encantamos os meus chefes ;)

Fica a sugestão da reportagem. Comunicar-se bem é algo que devemos estar sempre buscando. Não acham?

Abração e bom domingo.

Sexta-feira, o dia do "yes!"

2008-08-23T23:25:00.002-03:00

Nesta última sexta-feira aconteceu uma coisa que eu merecia (sem falsa modéstia).

Vocês que acompanham o blog sabem que eu sempre costumo expressar minhas opiniões sobre comunicação, liderança, gestão, etc. Porém, sabem também o quanto eu tenho de problemas no trabalho, devido a falta de uma cultura de projetos, principalmente.

O que estava acontecendo então? Eu me sentia aquele cara que sabe tudo na teoria, mas que nunca consegue colocar as coisas em prática. É um sentimento muito ruim, desmotivador, inclusive.

Desde que eu assumi esse "projeto" (já que me foi jogado no colo para eu "resolver") eu tive um pequeno desacerto com o meu chefe, vi meus antigos funcionários cairem fora, recebi um novo funcionário (indicação de outro chefe) e tive diversos problemas com os requisitos do projeto.

Eu estava crente que seria mais um projeto que iria para o lixo, sem chance alguma de sucesso, qualquer que fosse o meu esforço. Eu me senti como se estivesse numa competição do "Aprendiz" em que o Trump ou o Justus me jogam para a arena com uma espada de madeira para lutar com uma dezena de gladiadores e leões. Embora a analogia seja meio pobre, posso dizer que mostra o sentimento de impotência que eu estava sentindo.

Porém, algo me motivou. Inicialmente eu comecei a pensar que de nada adiantaria eu ficar em cima do muro, fazendo apenas o necessário para depois dizer "eu avisei que não ia dar certo". Eu precisava encarar isso como um desafio e fazer o que fosse possível para resolver a situação. Junto a isso, e que foi um daqueles suplementos alimentares na minha motivação, o fato do novo funcionário ser um jovem de excelente competência técnica, me mostrou que SIM eu posso obter ótimos resultados tendo uma equipe razoável e um desafio pela frente.

Nesta sexta-feira os meus dois chefes me solicitaram para ver o projeto, onde estávamos, o que havíamos feito, etc. E o que eu apresentei a eles, não apenas solucionou os problemas propostos como ainda consegui ir além.

Desenvolvemos em uma semana: um software para o celular (a melhor solução possível para um problema crítico deste projeto - que envolve um processo específico), dois sistemas de relatórios via web (para demonstrar o que podemos manipular em nível de dados), além de uma pesquisa sobre os processos envolvidos, com soluções propostas e vantagens e desvantagens. Tudo isso em um Powerpoint para ser apresentado ao cliente. O que eu fiz, basicamente, foi tentar orientar essa "demanda" em um projeto. E espero fazer isso após a reunião com o cliente.

A reação dos meus dois chefes foi daquelas de deixar qualquer subordinado animado. Eles sairam felizes! A sensação foi de que superamos as expectativas deles. Lógico que a expectativa deles também não era muito alta, pois eles sabem o histórico ali do laboratório... mas ainda assim foi uma das únicas vezes que eu vi os meus chefes realmente satisfeitos com o que viram (de cabeça, eu lembro da vez que apresentamos o antigo projeto na feira, que o meu chefe ficou muito feliz também, mas apenas um deles... o outro não estava envolvido).

Enfim, a sexta-feira foi a recompensa que eu há muito estava buscando. O resultado da minha superação em atingir um resultado e superá-lo, inclusive. Fui gerente de projetos, analista, desenvolvedor e DBA (analista de banco de dados). Não é o que eu quero que se repita - e irei deixar isso claro futuramente - mas o esforço valeu a pena.

Por pior que seja o nosso ambiente de trabalho (o meu é ruim apenas na questão organizacional, vale ressaltar) nós sempre temos um objetivo em comum: encantar nosso cliente. Seja ele o cara que compra o seu produto ou mesmo o cara que paga o seu salário. Nada melhor do que atingir isso.

A lição que dá pra tirar disso é: se você está desmotivado, busque motivação. Se você quer passar uma mensagem, a melhor forma de fazer isso é motivado, atingindo um bom resultado... e depois apresentar uma forma alternativa de superar aquilo. Nenhum chefe vai dar atenção a alguém que falha (para depois dizer "eu avisei") e se demonstra desmotivado. Porém, se você tiver os holofotes por algo bom que tenha feito, sua mensagem será potencializada. Tenha a certeza disso.

Sexta-feira: o dia em que eu esperei por um bom tempo chegou. E o seu? Lute para que ele chegue o mais cedo possível.

Apresentação: Essência de Gerenciamento de Projetos

2008-08-23T23:15:00.003-03:00

Prezados,

conforme eu havia prometido, aqui está o pdf com a apresentação que eu fiz na turma de gerenciamento de projetos, na turma de graduação da PUCRS, no dia 19/08.

Foi muito legal a apresentação. A receptividade da turma foi excelente. Eu estourei bastante o tempo e ainda assim notei muita gente interessada na palestra. Essa é a força de trazer "cases" e situações para nossas palestras, além de ser um pouco teatral também :)

Também consegui trazer uma visão "agilista" de gerenciamento de projetos, sem ser radical ou aparentar fazer "lavagem cerebral". Acho que essa abordagem também foi bastante eficiente.

Faça o download aqui

Ah, e sempre reforço que no icone do menu direito (seção de downloads) você pode baixar as outras apresentações além dos podcasts, videos, documentos, artigos, etc. Faça bom proveito.

Revista MundoPM Ago/Set 08

2008-08-22T10:07:00.002-03:00

Eu assinei por um bom tempo essa revista. Mas o excesso de artigos extremamente técnicos e fora da minha área específica (TI) fizeram eu optar por não renovar a assinatura. Os artigos possuem uma linguagem bastante técnica e alguns são intragáveis. Costumava ler um ou dois artigos, no máximo.

Porém, a edição deste mês (ago/set) possui três artigos BEM interessantes!

O primeiro trata sobre o novo processo do PMBOK, "Coletar requisitos". E ali traz algumas informações bacanas (técnicas e ferramentas, principalmente). Vale a pena dar uma olhada.

O melhor de tudo, porém, é que a edição possui DOIS artigos sobre processos ágeis.

O primeiro artigo, de autoria de Otávio Ritter dos Santos, é excelente. Além de abordar os processos ágeis de uma forma bem abrangente ele ainda apresenta todos os métodos na forma das disciplinas do PMBOK (custos, integração, escopo, etc). Se você pretendia convencer alguém a experimentar métodos ágeis, esse artigo vai ajudar muito. Principalmente o pessoal familiarizado com o PMBOK.

O segundo artigo, de autores internacionais, fala mais especificamente do SCRUM, abordando algumas questões de equipe. Bastante interessante a leitura também.

Enfim, comprem essa edição. Eu recomendo. Seja você de TI ou outros :)

Um abraço

Semana pesada

2008-08-22T09:52:00.003-03:00

Devem ter percebido que eu não tive quase tempo para postar aqui. Pois é, essa semana foi bastante corrida.

Afora o trabalho, onde tínhamos um prazo pra hoje (que acabou sendo estendido devido a impossibilidade de reunião com o cliente), ainda fiz uma palestra para a graduação (disciplina de gerência de projetos - falando sobre a essência de projetos) e também um trabalho no meu MBA!

Quero ver se hoje, sem falta, eu publico aqui o material dessa palestra.

Como eu disse no post anterior, é impressionante a mudança que se tem no andamento do projeto quando se atua com as pessoas certas. Estamos desenvolvendo um software... com uma pessoa de software! Pode parecer óbvio, mas lá no trabalho isso era encarado como "Ah, os outros tiveram uma disciplina de programação, como é que não conseguem fazer algo direito?!".

O grande erro, na minha opinião, é que estamos fazendo protótipos. De novo. Devido ao tempo, à falta de comunicação com o cliente (o meu chefe fala que ele sabe tudo o que precisa... mas alguém acredita?)... então novamente estamos perdendo recursos (tempo e dinheiro) fazendo algo que será apenas para mostrar a idéia para o cliente e não algo já com valor.

Eu estou tentando mudar isso, mas é complicado.

Trabalhando com gente competente!

2008-08-18T21:47:00.002-03:00

Nossa, como faz diferença trabalhar com gente competente.

Sexta-feira eu havia pedido para o novo funcionário para realizar um módulo do sistema. Eu tava acostumado a esperar uma semana para ver resultados... mas o cara terminou HOJE!! Levei um susto hehe

Enfim, valorizar as competências tem que ser a primeira coisa a ser feita, em uma empresa. Seja grande ou pequena.

Desculpem pelo post rápido, mas estou meio na corrida!

Abraços

Porque eu escrevo este blog

2008-08-14T00:43:00.003-03:00

Por causa do Rogério:

Bom Flavio,

se vc deseja um feedback, aqui vai o meu:
como disse em outro comentário que fizacho o seu blog muito legal, pois vc cita coisas que acontecem no dia a dia de cada um de nos que trabalhamos com tecnologia, e muitas vezes nos faz parar e pensar: "putz, igual ao que acontece aqui comigo!". Comigo me leva a refletir como tenho que melhorar muito ainda, seja profissionalmente ou na vida pessoal mesmo.
Levar na cabeça é normal, embora muitas vezes nós não estamos preparados para lidar com determinadas situações, por mais que nos esforcemos estudando sobre determinado assunto e como reagir a ele.
So posso te desejar boa sorte e que vc consiga ajudar a empresa onde trabalha a melhorar a sua forma de pensar o trabalho e o ramo de mercado que atuam, para que ela possa crescer cada vez mais.

Do Cesar:

Muito, muito, muito bom mesmo! Flavio, vou repercutir este teu post lá no i-scrum.ning.com e botar um link permanente para o teu blog, pode ser? Abraços!

Da Yanina:

Oi,Flávio. Eu sou Yanina, uma argentina que por acaso caiu no seu blog há um tempo e gostou bastante por duas razões: a primeira, meu namorado é gerente de prójetos de uma pequena empresa de desenvolvimento de software aqui em Buenos Aires e foi muito engraçado ler os mesmos problemas que ele tem todos os dias...a segunda razão, e peço desculpas pelo atrevimento,é que eu estou lecionando português nessa e em outra empresa que trabalha para o Brasil e estou utilizando alguns dos teus posts para todo tipo de exercícios...

Talvez não tenha nada a ver, mas estava me sentindo em falta utilizando o teu blog sem te avisar...

Qualquer dúvida, ou se você tem problemas com que eu continue "roubando" os teus posts, é só avisar...

abraços... yan

Da Fabiana:

Essa figura passa com exatidão a diferença entre uma e outra.

Muito show o blog estou sempre passando por aki e lendo os materiais.

Parabéns Flávio!

Do Wili:

Grande Flávio!
Já leu o livro "Seja Assertivo!"?
É de um pouco disso que você tá precisando (todos nós precisamos).
Dá uma lida e depois me fala.

Abraço
Willi

E de tantos outros leitores que deixam sempre o seu feedback aqui. Seja para acrescentar, corrigir, discordar, concordar, observar, refletir... enfim.

Um grande abraço aos leitores e comentaristas :)

E se você lê o blog, não hesite de deixar um alô com alguma experiência sua. Quero ver esse post bater o recorde de comentários. Será que conseguimos?

Vou deixar este post até domingo :)

Quero que VOCÊ, leitor, se apresente e conte algum fato que ocorreu com você recentemente. Vamos lá, duas frases. Não custa nada!

Abraços!

Dia desorganizado!

2008-08-12T20:31:00.002-03:00

Eu não sei qual é a impressão que eu passo para os meus leitores aqui. Muitas vezes escrevo algumas coisas como desabafo ou como alguma observação pessoal sobre trabalho e afins. Não sei se alguém possa pensar "pô, esse cara sabe das coisas!". Espero que não! :)

Na verdade eu sou um gerente de projetos que está no seu terceiro ano de projetos. Levei muito na cabeça para aprender e continuo levando e aprendendo. Mas procuro transformar esses hematomas em lições para não cometer o mesmo erro. A idéia do blog, em si, era demonstrar que você, caro leitor, não está sozinho neste mundo. Existe também um gerente de projetos como você, que também erra. E muito!

Hoje por exemplo. Era um dia em que começava no trabalho um novo funcionário.

O meu chefe me avisou disso na quinta-feira passada. Ontem eu recepcionei ele, conversei MUITO brevemente e acertamos algumas coisas burocráticas (horario, valores, etc). Ele é um rapaz bastante "cru", será sua primeira experiência profissional. Mas senti fé nele, parece ser bastante interessado. Inclusive comentei com ele que para mim a atitude costuma ser mais importante que o simples conhecimento. Marcamos que ele começaria hoje.

Então... para começar cheguei atrasado no trabalho. Ele ficou 15 minutos meio perdido lá no trabalho, sem saber o que fazer. Levei ele na sala de reuniões para explicar o projeto, mas expliquei de uma forma tão apressada que nem eu mesmo entendi os meus raciocínios! Depois fui colocá-lo em uma estação de trabalho e então eu simplesmente percebi que não tinha planejado NADA para ele fazer. NADA! Ficou uma situação bem cômica, eu pensando: "Ahm... tu podes fazer.... vamos ver....". Pedi então para ele buscar a respeito de um programa que iremos utilizar.

Depois aproveitei que um dos envolvidos no projeto estava no laboratório e pedi para ele explicar como funcionava o banco de dados do sistema. Ao invés de ajudar, acho que confundi mais ainda o novato!

Em seguida chegou um dos outros envolvidos no projeto. Pedi para eles se alinharem. Mas foi tudo meio "engembrado". Não sei ao certo o que os dois conversaram.

Pra completar, estive em reunião e não consegui ver o que ele fez até o fim do dia. Enfim, não quero nem imaginar a imagem que ele teve do seu primeiro dia de trabalho: um gerente de projetos atrapalhado, um bando de doidos como colegas, um projeto impossível.

Enfim, foi um dia que deu TUDO errado!

Amanhã espero tentar apagar um pouco essa sensação terrível que ele deve ter sentido hoje. Ou talvez nem sentiu, já que nunca teve outra experiência profissional. Bom, vamos ver amanhã...

O que se pode concluir? Leia o meu blog, se divirta e reflita sobre o que eu escrevo. Faça o que eu digo, mas não faça o que eu faço, já diria o ditado. Mas não tire o que eu digo aqui como "verdade" ou "fundamentação". Jamais! :)

Um grande abraço

Choque cultural e falta de identidade...

2008-08-12T12:08:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sexta-feira perdi dois ex-funcionários meus. Motivo? Eles diziam que não queriam seguir o rítmo que estava sendo impondo e muito menos ficar trabalhando em projetos "batata assada".

Um projeto estilo "batata assada", como eu chamo, é aquele projeto em que a diretoria te aloca sem te dar nenhuma explicação maior (faz uma reunião explicando o que é o projeto, o que deve ser entregue) e te dá um prazo "para ontem". Outras características: não temos poder para definir escopo, prazo, equipes e muito menos planejamento. Tudo é inferido pela diretoria: eles acham que somos capazes, eles acham que a equipe porque trabalhou no projeto A vai aprender o projeto ABC em dois minutos, etc.

O rítmo de trabalho que está sendo imposto é o comum de algumas empresas. Cobrança por resultados, desenvolvimento de produtos ao invés de protótipos e pesquisas, padronização de alguns comportamentos, "comando & controle", mais horas trabalhadas, etc.

Agora vamos analisar. Considerando que estamos em um grupo de pesquisa, normalmente em projetos de pesquisa (mesmo que alguns envolvam empresas), com pessoas com mentalidade de pesquisa e num ambiente onde não existe perspectivas de crescimento profissional, como é que a diretoria realmente quer comprometimento do pessoal simplesmente fazendo as mudanças descerem goela abaixo?

Eu não tenho a menor dúvida do que irá acontecer: assim como meus ex-funcionários sairam, outros vão se dar conta e sair fora. Entre receber X reais em um grupo de pesquisa e X reais em uma empresa, para onde vocês acham que as pessoas boas e inteligentes vão preferir ir?

É uma pena. Mas ao que parece a diretoria não está pensando estrategicamente. Muitas coisas poderiam ser feitas para tornar o grupo de pesquisa um centro de excelência. Mas dessa forma... acho difícil.

Abraços

Correções de links

2008-08-10T22:58:00.000-03:00

Acabo de descobrir que alguns links para download (principalmente os mais antigos, como os do podcast) estão quebrados. Estou corrigindo todos, mas peço aos leitores que se identificarem algum problema, postem comentários avisando ok? :)

Abraços!

Dinâmica: fábrica de aviões versão 2.0

2008-08-07T12:00:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal, com atraso estou publicando para vocês a dinâmica da fábrica de aviões que apliquei na turma de "Especialização em gerenciamento de projetos" na PUCRS. A idéia da dinâmica é vivenciar os conceitos do SCRUM, de forma prática, facilitando a visualização dos benefícios. Usamos bastante o conceito PDCA e processos empíricos, que são algumas das bases do SCRUM.

Esta dinâmica foi desenvolvida com base na primeira versão, só que agora ela se tornou mais "ágil" e divertida. Por quê? Inseri algumas novas variáveis e situações que tornam ela mais aderente ao que desejamos passar, ou seja, o conceito do SCRUM.

Para acompanhar este post, é legal você primeiro baixá-la no link abaixo.

Baixar a dinâmica (PDF)
Baixar a tabela em excel (XLS)
Baixar as fichas de responsabilidades (PPT)

Qual a essência da dinâmica? Criar uma linha de produção de aviões de papel que segue uma regra bem simples: a folha de papel começa numa ponta e "termina" avião na outra ponta. Na dinâmica que eu apliquei, foram 3 equipes com 7 membros cada. Se você tiver mais gente envolvida, tente manter no máximo 4 equipes com os membros necessários. Assim você consegue fazer o papel de Product Owner, avaliando o que foi produzido. Crie nomes do alfabeto grego para as equipes (no meu caso foram Sigma, Omega e Gama. Você já verão o por quê disso.

Avise as equipes que a forma como eles se organizarão para fazer a engenharia é com eles. Se quiserem ficar de pé, organizar as mesas em círculos, etc. é problema deles. DESDE QUE o produto comece numa ponta e acabe na outra. Além disso, a outra restrição é que não pode haver estocagem de material, ou seja, cada grupo só pode pegar mais 10 folhas quando a última folha entrar em produção. Isso existe só para tornar o processo mais difícil e para dar trabalho ao Scrum Master, na hora dos sprints :)

A estrutura da dinâmica é simples: as equipes tem três minutos para discutir o processo (retospectiva e planejamento) e ao final do tempo passam a estimativa de produção. Depois elas tem três minutos para produzir o que prometeram, conforme as definições do escopo solicitadas. E assim por diante (ciclo PDCA).

Neste primeiro momento, os papéis não existem ainda. O cliente fictício é a Força Aérea. É informado que a organização quer um novo avião e entrou em contato com as empresas deles. Então a organização quer saber das equipes quantos aviões eles produzem em três minutos. E eles tem UM minuto para dar a estimativa.

Isso mesmo, curto e grosso assim. Qual a idéia por trás? Quantas vezes nossos clientes e chefes chegam para nós: "Quanto tempo a gente entrega um sistema de cadastro e relatórios para o cliente XYZ?". "Bem... depende, como é o escopo?". "Escopo? É um sistema de cadastro e relatórios!! Quanto tempo?". Notaram a semelhança? É exatamente essa. Dar uma estimativa de algo que não se tem a menor idéia. No fim da dinâmica, na retrospectiva, isso serve para avaliar como as estimativas melhoram quando a equipe trabalha e conhece sua capacidade.

Enquanto as equipes fazem as estimativas, abra a planilha Excel para fazer o controle do "previsto / realizado". E marque ali assim que eles derem as estimativas.

Continuando, passe para eles que a Força Aérea gostou das estimativas. E vai abrir concorrência. Agora, a organização passou o escopo do avião. Com base no escopo, as equipes terão 3 minutos para produzir um protótipo. O escopo é bem simples:

- O avião deve possuir 12 janelas
- Deve possuir uma cabine
- Deve possuir o logotipo da empresa que está produzindo, nas asas e na cauda (o logotipo tem que ser o símbolo do Sigma, Gama, Omega - aqui é outra pegadinha!)

Note que não é dito "que tipo de avião" deve ser produzido. A idéia é mesmo que as equipes quebrem a cara na hora de apresentar o protótipo. Esse é o momento mais divertido da dinâmica. Se as equipes perguntarem algo mais sobre o escopo, diga que você não sabe... a organização não passou mais informações.

Cuidado para não passar o próximo slide, onde tem o projeto que a Força Aérea quer. Esse slide é para depois das apresentações!!

Após a produção, peça para um de cada equipe vir até a frente e apresentar o avião. No final, faça o teste do vôo. Não esqueça de solicitar os aplausos para cada apresentação :)

Depois das apresentações, passe o feedback de cada avião. Compare os protótipos com a idéia do que o cliente queria (o slide que mostra isso). Uma coisa que quase nenhuma equipe coloca é PORTA. Pergunte: "Como o pessoal vai entrar no avião???". Se eles reclamarem que isso não foi dito no escopo, fale: "Mas precisava dizer?!". Aqui é a velha demonstração das expectativas do cliente versus produção. :)

Pronto. Agora eles já sabem o que deve ser produzido. Então as linhas de produção vão começar. Diga que eles terão 3 minutos para avaliar a engenharia que irão utilizar para o processo e ao final, passarão a estimativa de produção. Eles deverão produzir os aviões criteriosamente conforme o escopo passado. Aqueles que, ao final dos três minutos do sprint, não estiverem de acordo (faltou uma janelinha, faltou o logotipo correto, etc) não contam como finalizados, mas podem voltar para a linha de produção para serem finalizados. Essa regra é importante e segue os princípios do SCRUM.

Antes de começar, porém, é preciso definir os papéis. Utilize as fichas que estão ali em cima para download (imprima mais fichas "membro da equipe"). Diga que você irá passar para cada um dos membros das equipes uma ficha contendo o papel deles na equipe. Invente que as equipes serão multi-funcionais e cada um terá um papel para desempenhar. Diga que eles devem ler a ficha e atuar conforme está escrito ali e não devem comentar com ninguém quais são suas atribuições.

Por que dessa cena toda? Porque os papéis nas equipes são: SCRUM MASTER (não pode produzir, deve cuidar do time, avaliar o processo, remover impedimentos e buscar matéria-prima), MEMBRO DO TIME (produzirá o produto e avaliará o processo) e ... ELO FRACO.

Cada equipe tem UM Scrum Master e UM Elo Fraco (se você quiser colocar dois por equipe, dependendo do tamanho, é uma idéia interessante também). O Elo Fraco tem como função principal ser exatamente a pessoa que atrasa o processo todo. Aquele cara descompromissado, que destoa dos demais. É o gargalo do time. Mas ele participará do time como se quisesse melhorar o processo (dará sugestões, etc), mas na produção será sempre o gargalo. Ele tem que ser um bom ator e não pode deixar ninguém saber que ele está atuando assim, dai a importância de deixar claro que ninguém pode ler a ficha do outro (se possível, recolha as fichas após eles lerem).

Sabendo disso, diga que o SCRUM MASTER deverá sair da linha de produção e ficar de pé, auxiliando o time nas suas funções. Ele, lógico, pode dizer o que pode ou não fazer.

Feito isso, as regras estão expostas, o escopo é sabido e os papéis e responsabilidades são conhecidos. Dê o start para que eles comecem a planejar o processo e ao final passar a estimativa.

Uma sugestão que causa um efeito psicológico bacana: Durante esses períodos de planejamento, controle o tempo e passe para eles quanto tempo falta para encerrar. Mas nos sprints não avise o tempo, só diga quando encerrou. A idéia é que o Scrum Master ou a equipe percebam que eles que tem que controlar o tempo.

Ao final do planejamento, eles começam os sprints de 3 minutos. Repita daí o processo de "planejamento/estimativa 3 minutos" e "sprint 3 minutos". São três sprints (um número ideal para ninguém cansar ou encher o saco!).

Quando as equipes passarem as estimativas, marque na planilha Excel, na coluna "previsto". Quando você fizer a contagem dos produtos finalizados (que devem estar totalmente de acordo com o escopo) marque na outra coluna "realizado". Assim até acabarem os sprints.

Ao final do terceiro sprint, veja qual foi a equipe vencedora (a que entregou o maior número de produtos). Entregue algum prêmio, como uma caixa de "Bis" para motivá-los :)

Encerrada a dinâmica, avalie com o pessoal como foi o processo. Revele os papéis "obscuros" que existiam nas equipes (os elos fracos) e questione se a equipe havia percebido isso e se tomaram alguma atitude para contornar o problema. Avalie a questão do protótipo versus expectativa do cliente... a questão do trabalho em equipe... a identificação do limite de produção da equipe... o desafio de superar esse limite... a questão do empowerment (onde os membros da equipe avaliavam o processo e tinham poder de sugerir mudanças)... os benefícios da inspeção e adaptação com base na experiência... e encerre comentando a idéia de usar sprints de trabalho.

Faça a pergunta que contém no slide: "Seria melhor entregar todos os aviões em 10 minutos ou % deles a cada 3 minutos?". Dificilmente alguém dirá que o ideal será a primeira opção. Lembre da teoria do estudante (deixar tudo para a última hora), a motivação que será alta nos primeiros minutos e depois cairá com o tempo (afetando a produção).

Antes de terminar, abra a segunda aba da planilha Excel, onde tem o gráfico baseado nas estimativas passadas. Demonstre que o primeiro ponto representa a estimativa quando eles não sabiam NADA do que tinha que ser feito (quando a Força Aérea pediu estimativa sem passar nada). As outras estimativas já foram com base na experiência e no conhecimento do escopo. Possivelmente você terá um gráfico que começa mais alto ou baixo e que depois tende a ficar parecido com uma reta, estabilizando. A idéia é que a gente erra nas estimativas iniciais em +400% e -20%, normalmente. E com o tempo, conhecendo o escopo e nossos limites de produção, as estimativas tendem a ser mais próximas à realidade e tendem a estabilizar. Comente que se houvessem novas sprints, o gráfico se estabilizaria de vez, cabendo à equipe e ao Scrum Master a idéia de tentar encontrar soluções para superar aos poucos estes limites.

Por exemplo, se as equipes produzissem 15 aviões no máximo, o que eles teriam que fazer para otimizar o processo para produzirem 17-18? E assim sucessivamente, quando conseguissem atingir os resultados.

Por fim conclua, demonstrando que eles vivenciaram a essência do SCRUM, ou seja, um ciclo PDCA onde eles planejaram o que fariam, realizavam as tarefas, checavam e avaliavam o processo e por fim tomavam decisões de mudança com base nisso, para alimentar o planejamento.

Termine desafiando: "E se usássemos isso na produção de um software?". Aí é discussão para não acabar mais :)

Ufa! Apesar deste texto longo, eu tenho certeza que você conseguirá aplicar essa dinâmica com o mesmo sucesso que eu tive ao aplicar na turma de especialização em gerenciamento de projetos, na PUCRS. Ali foi muito bacana. Os momentos mais divertidos foram na prototipação e durante os sprints (tive a sorte de escolher bem quem seriam os elos fracos - que foram excelentes atores!).

Ao final da dinâmica, todos entenderam a essência do SCRUM. A mensagem foi passada com total sucesso e tenho a certeza que abriu um novo horizonte para aqueles que não conheciam essas práticas.

Use essa dinâmica como um reforço para passar a mensagem do SCRUM ou mesmo para vender a idéia para sua diretoria. Apesar do pretexto bobo (criar aviões de papel) tenha a certeza de que ao final todos vão ficar bastante satisfeitos com o resultado.

Peço encarecidamente que, quem for aplicar a dinâmica, me envie um email contando como foi a experiência :)

Um grande abraço e façam bom uso!

Decisões nem sempre populares...

2008-08-06T18:55:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje tive que tomar uma decisão nada popular para a equipe. Sabendo que o projeto em que estávamos estava encerrado (pelo menos na minha visão) e que a equipe ficaria o mês de julho ociosa... e sabendo ainda que o projeto não tem mais verba, tive que tomar a decisão que considerei mais justa para a empresa e para a equipe: fazer o pagamento dos salários de meio mês de trabalho.

O problema: a equipe acabou sabendo disso HOJE quando recebeu.

Por quê? Simplesmente o meu chefe não se decidia. Eu tentava falar com ele pedindo uma decisão, e ele não respondia objetivamente. Então hoje abracei a idéia e tomei a atitude que considerei a melhor, dadas as circunstâncias.

A equipe não recebeu bem a notícia, claro. Mas tratei de conversar com eles e explicar os motivos da minha decisão e assumir a decisão como sendo minha. Notei que isso, apesar do impacto negativo da atitude, melhorou um pouco a percepção deles... uma vez que joguei em pratos limpos com eles.

O segundo problema: eles vão trabalhar este mês em outro projeto... e vão receber como? Isso é outra história. Que possivelmente será bem enrolada também.

Enfim, lá vou eu falar a palavrinha mágica que originou este problema todo: COMUNICAÇÃO. Sempre.

Dinâmica 2.0

2008-08-06T11:25:00.001-03:00

Pessoal, ainda hoje eu publico pra vocês a dinâmica "Fábrica de aviões 2.0" que é uma versão bem melhor da dinâmica que eu havia criado anteriormente, para vivenciar SCRUM.

Introduzi algumas variáveis e situações bacanas, que tornam a dinâmica mais "ágil" e divertida.

Vão gostar :)

Abraços

Just a "perfect" day...

2008-08-05T23:43:00.002-03:00

Hoje foi mais um daqueles dias típicos de uma pequena empresa e (des)organização.

Ontem mobilizei novamente a equipe do meu projeto, pois o meu chefe disse que queria finalizar o projeto com os testes no trator (do nosso protótipo) sendo aprovados. Então mobilizei a equipe para que eles estudassem o que precisaríamos para completar o projeto. Em paralelo, tive uma bomba para resolver: os pagamentos. Nosso projeto de pesquisa está sem verbas. Logo, o pagamento sairá do bolso da empresa. Prevendo isso, eu desmobilizei a equipe fazendo-a trabalhar apenas 15 dias. Assim negociei com os meus chefes do pagamento apenas destes 15 dias, reduzindo o impacto do custo no bolso deles.

Hoje, eu estava trabalhando no planejamento dos próximos 15 dias de projeto, até o teste no trator. Recém havia enviado um email para o meu chefe, e o meu outro chefe passou na minha mesa e falou: "Flávio, preciso falar contigo e com a tua equipe". Ok, fui até o laboratório e chamei a todos. Fomos para a sala de reunião.

Qual foi a pauta da reunião?

- Vocês foram alocados para outro projeto, que está crítico e precisamos finalizá-lo.

Foi aquele "hã??" geral na equipe. Mas a reunião seguiu com a explicação do tal projeto. 60% de software e uns 40% de hardware. O engraçado é que a minha equipe atual é composta de estudantes de ENGENHARIA da computação, ou seja, software não é a praia deles. Mas durante a reunião o nosso chefe teimava em abordar mais os aspectos de software e também lembrava que "eles já haviam mexido com GPS e então teriam um aprendizado rapidíssimo, de 15 minutos, no projeto".

Um parênteses: eu acho sensacional esse conceito que meus chefes tem, e que é muito comum por aí. Se nós trabalhamos com uma tecnologia em algum projeto, isso nos torna especialistas em qualquer projeto que envolva a mesma tecnologia. Ou seja, a equipe trabalhou com GPS para auxilio de guia de um trator... e agora vai aprender rapidíssimo tudo o que envolve o projeto de GPS para rastreamento de veículos (inclusive com banco de dados e interface gráfica). É aquela mesma história que a gente que cursou informática sofre quando alguém vem e pergunta algo como "tu sabes fazer um índice no Word? Não??? Pô, mas o que vocês fazem nessa faculdade??!".

Ao final da reunião, como de praxe, este nosso chefe definiu que espera resultados já para a próxima sexta-feira. Resultados e decisões "triviais", que envolvem variáveis complexas. Afora o exagero na exigência, toda equipe admitiu que é melhor trabalhar com este chefe, pois ao menos ele é bem objetivo :)

Enfim, até as 15h eu estava planejando um projeto com a equipe. Às 15h05 já estávamos alocado, sem mais nem menos, em outro projeto. E a importância dos testes no trator, que teríamos que fazer? Bem... inexplicavelmente virou secundário.

Uma pequena empresa normalmente possui um ambiente propício para a comunicação, pois é relativamente simples (pouca gente, processos informais, etc). Mas é impressionante a tendência que as pessoas tem de complicar. A previsibilidade é ZERO no meu trabalho. As decisões são tomadas e apenas nos informadas quando a batata já assou. Daí eles jogam no nosso colo e falam "é para ontem!". Mas falar de comunicação lá no meu trabalho é bater na mesma tecla, sempre... infelizmente.

Abraços

Comunicação x Percepção

2008-08-01T23:58:00.003-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Existem diversas formas de passar uma mensagem. Podemos ser tendenciosos ou não. Um bom líder precisa garantir que a mensagem esteja sendo passada da forma correta, sem que haja má interpretação. Já pensou se você quisesse fazer um elogio e o seu subordinado entendesse como uma crítica?

Eu vinha há algum tempo pensando em criar uma forma de mostrar a questão da percepção de uma forma prática. Tive uma idéia de modificar o trailer de um filme mudando totalmente o contexto (uma comédia para um filme de terror, por exemplo). Mas eu as vezes esqueço que, na era da internet e da informação, quando nós pensamos em uma coisa, outros 100.000 já estão colocando em prática.

Vejam os dois exemplos abaixo. Uma versão do trailer original e uma versão "modificada" por... gente com muito tempo livre :)

E se vocês procuravam uma forma de mostrar a importância entre a mensagem e a percepção que ela gera, vocês tem abaixo.

Peguei dois filmes, os excelentes "Rain Man" (um drama) e "O iluminado" (um terror sensacional).

RAIN MAN ORIGINAL

RAIN MAN TERROR

O ILUMINADO ORIGINAL (trailer meia-boca já que é quase impossível achar o original!)

O ILUMINADO COMEDIA ROMANTICA

Ótima notícia para a comunidade de SCRUM

2008-07-31T17:48:00.003-03:00

O grande Henrik Kniberg, autor do excelente livro prático de SCRUM "SCRUM and XP from the trenches" (baixe aqui) divulgou em seu blog que uma versão do livro em português está a caminho.

Os brasileiros que tem dificuldade com inglês possuiam pouquíssimo material de apoio no assunto, e agora teremos um bem bacana. O livro é sem dúvida alguma um dos melhores sobre SCRUM que existem, pois basicamente ele passa a visão prática dele. O subtítulo é "How we do scrum", ou seja, "como usamos o scrum".

Se você quer começar a utilizar, siga os processos propostos pelo Henrik e adapte com a necessidade à sua empresa.

Enfim, a tradução do livro é uma excelente notícia para todos.

Post original.

Abraços!

PMBOK x Agile

2008-07-31T17:42:00.005-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Bem interessante a comparação entre o PMBoK e os métodos ágeis (SCRUM, XP, etc). Discordo de um ou outro conceito, mas a essência é essa :)
Tirei do blog do Abu.

Think simple!

2008-07-30T16:00:00.002-03:00

Essa imagem é uma das que mais traduzem a realidade.

Tá bem, eu sei que ninguém aqui faz isso :)

A volta do que não foi...

2008-07-30T15:52:00.003-03:00

Enviei um email para o meu chefe ontem, com duas perguntas. A primeira a respeito do final do nosso projeto, se estava finalizado ou não. Falei que como ele não havia me dito nada mais, tomei a liberdade de desmobilizar a equipe. Falei bastante sobre isso neste post. Aproveitei para lembrar da questão da reunião do próximo projeto, já que ninguém havia dado nenhuma notícia.

A resposta do meu chefe foi bastante interessante:

Minha ideia é continuar o projeto até termos o teste no trator aprovado. Vou conseguir verba para isso.

Bom, de fato o teste do trator pode ser interessante. Só que vai ser esse mesmo o deadline? Esse projeto terá algum dia um fim?! Eu, sinceramente, já não sei mais o que fazer... sabe aquele projeto "interminável"? Pois estão diante de um hehe

E sobre a reunião, nenhuma palavra.........

Abraços

Desenvolvimento incremental x iterativo

2008-07-29T14:02:00.002-03:00

Um exemplo prático :)

[Editado: resolvi colocar a explicação do Abu, que é muito boa]

Quando eu era mais novo e possuía uma empresa de desenvolvimento de software, eu costumava ir ate o cliente, fazer o levantamento de requisitos, o entendimento de cada requisito, prototipação das telas, rascunho do banco de dados, etc etc etc. Minhas atividades tinha o objetivo de sair com todas as informações necessárias para a construção do sistema inteiro (quando ele era pequeno) ou de alguns módulos (quando o sistema tinha um porte maior).
Mas este trabalho tinha o foco de garantir que a minha entrega não teria retrabalho, isto é, após eu entregar o sistema o cliente estaria satisfeito e eu receberia a minha recompensa ($$$).
O problema desta técnica é que ela exigia do cliente uma visão muito assertiva do que ele realmente desejava, mas nem sempre o cliente tinha total informação e visão do que ele desejava de sistema.
O cliente passava a ter uma noção do que ele realmente queria quando estava utilizando o software e desta maneira ele passava a gerar solicitações de mudança.
O sistema nem tinha nascido direito e já estava com solicitações de modificação, e vinha a minha pergunta, onde eu errei na analise ou o cliente não sabe o que deseja.
Este modelo de desenvolvimento de software é o que se chama de “Incremental”.
Já no desenho de baixo é mostrada a pintura de forma “Iterativa”, onde as definições dos requisitos são realizadas junto com o desenvolvimento do software. Nesta técnica não quer dizer que nos não sabemos do que se trata o sistema e passamos a descobrir no decorrer do desenvolvimento. Vocês podem observar que o esboço da pintura já existia, isto é, “ESCOPO INICIAL”.
Mas os detalhes de cada item do sistema são definidos conforme o sistema vai sendo desenvolvido, isto é, a pintura tem que ter olhos e dois olhos, porem a cor de cada olho e os seus detalhes serão definidos no decorrer do desenvolvimento.
A pintura tem que ter boca, mas se ela vai sorrir ou vai ficar seria, é uma opção definida no decorrer da execução da pintura. Desta maneira podemos ate mesmo tentar qual fica melhor, sorrindo ou serio.
A diferença entre as duas técnicas esta no fato do cliente saber tudo o que ele deseja com o mínimo dos detalhes desde o inicio do projeto (Incremental) ou ir colocando os detalhes na execução do projeto (Iterativo).
Ambas as técnicas podem levar ao resultado final, sim, podem, porem devemos lembrar que os requisitos (Itens de Backlog) sempre mudam, a questão é como vamos trabalhar com esta mudança. Na técnica Iterativa nos conseguimos absolver as mudanças com um impacto menor, pois esta técnica já é feita para se trabalhar com as mudanças.

Extraído do blog do Abu

Distração...

2008-07-29T13:57:00.003-03:00

Essa eu tinha que mostrar para o meu chefe. Ele quase sempre reclama das distrações no trabalho, reclamando da internet (msn, email, páginas na internet, etc). Acho que essa charge foi para mostrar que a distração transcende a tecnologia. É uma questão cultural....

Retrospectiva do projeto (lições e prática)

2008-07-28T17:36:00.007-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Conforme dito, vou passar aqui alguns itens citados na retrospectiva do meu projeto.

A retrospectiva abrangiu o projeto como um todo (2 anos) e infelizmente não pôde contar com todos os envolvidos (faltou o chefe/cliente e um membro da equipe).

Apresentação

O processo da retrospectiva foi realizado em dois momentos. No primeiro momento, uma linha do tempo que abrangia todo o projeto foi desenhada. A partir disso, foram sendo citados os eventos que ocorreram durante o projeto, numa espécie de brainstorming. Estes eventos eram colocados em ordem da data em que aproximadamente ocorreram.

Após este levantamento, alguns eventos foram excluídos por serem “duplicatas” ou então por serem conseqüências de alguns itens citados.

O segundo momento foi a divisão entre o que foi bom e o que não foi legal no projeto, e a classificação de cada um dos eventos nesse quadro comparativo. Para cada evento também eram analisados alguns fatos, como comentários sobre o evento, causas e conseqüências. Alguns eventos também foram discutidos pela equipe, apenas como relembrança.

Ambos os processos foram fotografados para posterior documentação. Este documento apresenta estes eventos classificados em “o que poderia ter sido melhor” e “o que foi bom”, com comentários do autor do documento (Flávio, gerente do projeto). Alguns outros itens foram incluídos pelo gerente posteriormente.

A figura abaixo demonstra a organização da retrospectiva.

Este post pode (e deve) ser usado como referência para futuras tomadas de decisão, sendo um excelente repositório de lições aprendidas na prática. Use-o para refletir se suas decisões e atitudes podem ou não causar os mesmos estragos ou oportunidades aqui descritos.

--------------------------

O que poderia ter sido melhor

Utilização do conceito Waterfall, como engenharia. A utilização do waterfall (concepção, análise, desenvolvimento e finalização) se mostrou bastante inútil para nosso projeto. Houve uma perda de tempo enorme uma vez que o desenvolvimento já poderia ter sido iniciado muito anteriormente.
A não utilização do Wiki como ferramenta. A idéia do Wiki como repositório de conhecimento foi muito boa. A ferramenta é fácil de usar e bastante simples. Infelizmente não houve uma cultura (e cobrança) para que o uso fosse disseminado.
Muito tempo na fase de concepção. Seguindo o modelo Waterfall, a equipe acabou levando muito tempo na fase de concepção. Houve muita desorganização, apesar do documento de concepção ser bem completo (e boa parte estar defasada já).
Equipe muito grande. Houve muita desorganização no começo. O projeto começou inicialmente com 8 desenvolvedores, um gerente e um coordenador. Ficou evidente que o ideal seria uma equipe com 4 desenvolvedores no máximo (finalizamos com 3).
Software poderia ter iniciado logo depois da concepção. Perdeu-se muito tempo para modularizar e definir de fato o software embarcado, uma vez que tivemos muito foco no hardware. Posteriormente ficou evidente que pelo menos dois ou três módulos poderiam ter sido iniciados logo após a concepção.
Utilização do Status Report semanal. O documento, apesar de boa intenção para identificar as tarefas realizadas pela equipe, se mostrou bastante burocrático e ineficaz. Boa parte do resultado que desejava se atingir com ele, poderia ter sido feito com mais reuniões e com a cobrança da gerência.
Escopo muito solto. Por muito tempo o projeto teve um escopo muito “solto”, ou seja, não se sabia ao certo o que iríamos produzir. Isso custou tempo, foco e afetou a produtividade. Deveria ter havido mais cobrança junto ao cliente para formalizar o escopo.
Tentativa de utilização de um TCC como hardware do projeto. Perdeu-se algum tempo com a idéia de usar como placa-mãe um trabalho de TCC de alunos. A idéia era muito boa, mas mostrou-se ineficiente (já que os alunos pediram um valor altíssimo pelo projeto).
Falta de datas (deadlines). Por diversas vezes a equipe sentiu a necessidade de vislumbrar uma data final para a realização de alguma atividade. Faltou cobrança e planejamento, muito devido ao escopo “solto”. Isso acabou levando a equipe a também se comportar de forma mais “solta”.
Curso extraprojeto com membros da equipe. O curso, além de ser muito ruim – na opinião dos dois – ainda demandou que dois membros da equipe saíssem por alguns dias do projeto para aprenderem sobre uma tecnologia que nada agregaria ao projeto. Além disso, o projeto em que seria usado o que foi aprendido no curso, acabou sendo abandonado.
Documentação do projeto. Por diversas vezes a equipe foi cobrada para realizar a documentação do projeto. O documento foi desenvolvido, mas sempre foi desaprovado pelo cliente. Infelizmente faltou, por muitas vezes, um norte para que a equipe desenvolvesse o que o cliente queria (lhes foi dito que a documentação deveria permitir que até mesmo uma empregada pudesse montar o sistema). A falta de norte também levou a produção de uma documentação acadêmica e desnecessária, que não agregariam nada ao projeto em si. Perderam-se meses nesta documentação, levando a desmotivação de todos (equipe e cliente). Por diversas vezes a aprovação da documentação ficou pendente por muito tempo, levando todos a questionar se essa documentação era realmente importante.
Falta de definição de papéis. O coordenador do projeto trabalhou no projeto como coordenador, especialista e cliente. Isso confundiu bastante a equipe e o próprio coordenador, por diversas vezes.
Coordenador segurou as compras durante o desenvolvimento. Apesar de ter sido uma ótima decisão no início do projeto, a insistência na decisão de só comprar os componentes após a documentação ter sido finalizada acabou atrasando bastante o projeto, uma vez que a documentação foi problemática (conforme citado anteriormente). Alguns módulos e ferramentas poderiam ter sido adquiridos para o início da produção. Essa falta de materiais “tangíveis” do projeto, gerou um pouco de desmotivação no projeto.
Falta de aproximação do coordenador com a equipe. Por ser o especialista do projeto, poderia ter tido uma participação mais efetiva no projeto, onde algumas coisas poderiam ter sido agilizadas.
Reuniões sem agenda. Diversas reuniões foram realizadas sem uma agenda para ser seguida, o que levou a falta de foco e decisões.
Reuniões de acompanhamento e de escopo. Por diversas vezes as reuniões de acompanhamento (onde também eram discutidas algumas idéias de escopo) foram muito problemáticas. Por um período grande, o cliente decidia por uma funcionalidade ou componente, para na outra semana desistir. Ou então sugeria algumas funcionalidades interessantes, mas que fugiriam do real objetivo do projeto (ex: capacete 3D!). A desmotivação de ambas as partes, ao final das reuniões, era visível.
Mudança da empresa para o laboratório. Essa decisão foi bastante criticada por todos os integrantes da equipe. Na empresa, a equipe mantinha-se mais focada e produtiva. No período ainda estava sendo implantado o SCRUM, o que causou uma grande mudança no projeto. A mudança para o laboratório reduziu muito a concentração, foco, comprometimento e a produtividade da equipe. Isso foi dito pelos próprios.
Comunicação ineficaz. A comunicação foi sempre um problema no projeto. Diversas decisões eram tomadas sem que os envolvidos tivessem conhecimento. Recursos específicos do projeto eram solicitados para outros projetos, decisões de escopo eram tomadas sem consulta a equipe e gerência, poucos sabiam ao certo o que o outro deveria fazer, papéis e responsabilidades eram incertos. A comunicação foi bastante maximizada com a utilização do SCRUM, isto sendo bastante evidenciado pela equipe.
Mau uso de alguns recursos. Por diversas vezes ocorreu um mau uso dos recursos do projeto. Financeiramente falando, o projeto poderia ter sido mais bem planejado e executado (algumas compras foram feitas na correria, devido aos prazos). Também ocorreram situações onde recursos do projeto (materiais e humanos) foram usados em outros projetos, com perda de foco e tempo. Além disso, a equipe poderia ter utilizado com mais responsabilidade alguns recursos do projeto, como ocorreu no caso onde o Valter, por acidente, formatou o seu “home” do computador. Não ocorreu uma perda crítica de conhecimento, porém o tempo para restaurar isso foi bastante grande para a situação em que o projeto se encontrava.
Aumento dos salários como motivação. Isso foi uma lição aprendida na prática, embora pudesse ter sido evitada. O aumento dos salários, que foi usado como questão motivacional, não surtiu o efeito desejado. Em um projeto como o Agritec, o impacto só foi sentido devido ao atraso no cronograma. Porém, deve-se evitar isso. A motivação se dará por diversos outros fatores como técnicas de empowerment, feedback, etc.
O projeto em segundo plano, em algumas vezes. Por diversas vezes, mesmo com alguns prazos apertados, a equipe decidiu por dar prioridade aos estudos e a questões pessoais em detrimento ao projeto. Isso gerou por um período, um certo mal estar, mas por pelo menos uma vez, um feedback da gerência foi suficiente para a retomada. Porém, o sentimento de que “poderia ter havido maior comprometimento” ficou evidente.

O que foi bom

O coordenador segurou as compras no início. A decisão de segurar as compras no início do projeto, indo contra a ansiedade da equipe, foi excelente. Diversos componentes solicitados, na época, se mostraram inúteis no projeto, o que seria um gasto desnecessário.
Saída de alguns membros da equipe. Alguns membros da equipe (não terão os nomes citados) reduziram os conflitos dentro do projeto, o que melhorou o foco e a cumplicidade.
Mudança do laboratório (antigo) para a empresa. A mudança para a empresa possibilitou a equipe sentar junto. A comunicação melhorou e o comprometimento também, apesar de algumas ressalvas no período “pré-SCRUM”. O ambiente de trabalho melhorou consideravelmente.
Reunião semanal de pesquisa. Uma reunião semanal, no início do projeto, foi uma idéia válida para alinhar a pesquisa de todos. Infelizmente algumas pessoas não levavam a sério, o que tornava esta reunião apenas uma burocracia. A idéia foi melhorada posteriormente.
Mudança do foco (não produzir o GPS). A idéia inicial de produzir um GPS felizmente foi abortada. Dificilmente teríamos uma precisão decente para o projeto. A idéia foi abortada logo, o que evitou a perda desnecessária de tempo.
Produção do documento de concepção. Embora tenha sido detalhado demais, o documento possibilitou naquele momento a consolidação da pesquisa inicial realizada. Além disso, serviu como nivelamento para possíveis novos integrantes. De ruim, apenas o tempo que se levou produzindo o mesmo e também o caráter “completo” que ele possuía, com muitas informações que não seriam aplicáveis com o tempo.
Feedback aplicado na parte inicial do projeto. Infelizmente por apenas uma vez, o Flávio e o coordenador realizaram um feedback com a equipe. A idéia foi de entrevistar cada membro da equipe para identificar problemas e necessidades que a equipe enfrentava. Foi interessante e útil para identificar conflitos, até então não conhecidos. A idéia de usar o feedback foi elogiada pela equipe.
Primeira versão do SCRUM. A implantação do SCRUM pelo Flávio teve um impacto extremamente positivo. Ficou muito mais claro para todos quais eram suas responsabilidades, quem estava sub ou super alocado, a comunicação melhorou muito e a freqüência também. A primeira versão do SCRUM foi uma versão adaptada (que não é exatamente como deveria ser o SCRUM) com uma taskboard onde havia nomes (linhas) e situação da tarefa (colunas). Reuniões diárias e retrospectivas foram utilizadas com sucesso (veja abaixo).
Reuniões diárias. As reuniões diárias foram uma das grandes mudanças que ocorreram para maximizar a comunicação do projeto. Através das três perguntas que cada pessoa da empresa respondia (na 1ª versão, inclusive os não integrantes do projeto) que eram “O que você fez ontem? O que pretende fazer para hoje? Quais seus impedimentos?” possibilitou criar cumplicidade na equipe e também a realidade de todos saberem o que o colega ao lado estaria fazendo. A implantação de um horário fixo para a reunião, no início dos trabalhos, fez com que a freqüência passasse a ser muito maior, evitando o “trabalho em casa”. Foi possível identificar alguns focos de problemas também, que foram resolvidos com o tempo. Além disso, segundo a própria equipe, as reuniões melhoraram a cobrança interna entre eles.
Descontração no ambiente de trabalho. O “carro-chefe” desse item é o cofrinho em forma de porco, que foi comprado com a idéia de que quem chegasse atrasado nas reuniões pagaria 50 centavos ao porco. O dinheiro, no final do mês, era revertido na compra de comes e bebes para uma confraternização e retrospectiva do projeto (que ocorreu muito pouco, apenas duas vezes). O porco serviu para deixar o ambiente mais leve e divertido, e contribuiu muito para manter a moral da equipe elevada. Deve-se estudar para buscar alternativas!
Retrospectivas. As primeiras retrospectivas foram importantíssimas para avaliar a situação do projeto, seja em relação ao escopo, cronograma e processos, seja em relação a equipe, comunicação e infra-estrutura. Logo na primeira retrospectiva foi evidenciado que a infra-estrutura da empresa, para a produção do projeto, era quase nula. Faltavam ferramentas e materiais simples (como canetas para o quadro branco). Também foi possível identificar as necessidades das equipes (descontentamentos, por exemplo) às necessidades do projeto, sempre que possível. As retrospectivas, posteriormente, acabaram ERRÔNEAMENTE ficando em segundo plano. Mas a última, que avaliou o projeto e gerou este documento, foi muito bem sucedida.
Melhora na infra-estrutura. Este era um dos maiores problemas do projeto: a falta de material e ferramentas para a realização de diversas tarefas. Por muito tempo, por exemplo, ocorreu uma improvisação absurda com a utilização de canivete suíço e até moedas, como chave de fenda. A partir da primeira reunião de retrospectiva onde isso ficou evidente, o Flávio solicitou a equipe que levantassem tudo o que precisaria para o projeto. Após a listagem completa, deliberadamente foi com um membro da equipe até uma loja especializada onde comprou todos os itens da lista. De um dia para o outro a empresa possuía ferramentas para o projeto (e outros também). Isso ocorreu por diversas outras vezes. Talvez não tenha sido a forma ideal (pode-se ter gasto a mais em alguns itens – o ideal seria pesquisar preços), mas naquela situação específica a mudança precisava ser rápida. E o resultado foi excelente.
Visita do pessoal da agricultura (clientes finais). A possibilidade de conversar diretamente com os usuários finais do projeto fez com que fosse possível ter uma visão bem mais próxima da real necessidade do projeto. O escopo foi priorizado e modificado para atender ao máximo as necessidades dos agricultores. Ter uma aproximação junto aos usuários finais é sempre uma excelente idéia para agregar aos projetos. Graças à visita foi possível identificar que as trajetórias retilíneas não poderiam atender as necessidades deles. Essa informação possibilitou a abertura do escopo para trajetórias curvilíneas.
Visita à Empresa Especializada no assunto. Assim como no caso do pessoal da agricultura, a empresa especializada foi uma grande parceira no projeto, trazendo idéias inovadoras que o produto poderia possuir. A maioria acabou não podendo ser implantada, mas possibilitaram a citação como funcionalidades futuras, dando um caráter inovador ao produto.
2ª versão do SCRUM. A implantação da segunda versão do SCRUM, agora mais aderente a prática real, tornou o processo mais auto-suficiente e seguro. Algumas técnicas novas foram aplicadas e garantiram excelentes resultados.
Planning Poker. Essa foi uma das técnicas que foram utilizadas na 2ª versão do SCRUM. Foi usada apenas uma vez, mas possibilitou a visualização por parte da equipe e do cliente de como os dois pensamentos da complexidade do projeto estavam distantes. A maioria das funcionalidades era tida como “simples” pelo cliente e como “difíceis” pela equipe. Essa técnica auxiliou o cliente a desistir de algumas idéias e funcionalidades para a versão inicial do projeto.
Finalização do 1º protótipo do painel. A realização deste primeiro protótipo começou a ser definida com a melhora na infra-estrutura do projeto. Foi um grande marco no projeto ter esse protótipo funcionando, pois evidenciou que estávamos no caminho certo e que toda pesquisa não havia sido em vão. A necessidade de ter algo tangível em um projeto ficou claramente exposta aqui. Além disso, possibilitou a realização dos primeiros testes reais.
Contato com empresas para solução Kalman. O contato com empresas especializadas, em forma de parceria, possibilitou o abandono da idéia de usar a tecnologia de Kalman no projeto o que, segundo os próprios donos da empresa, era inviável devido ao alto custo e complexidade.
Uso do Doxygen como documentação de software. A utilização do sistema “Doxygen” para documentar o software do projeto foi muito boa. O sistema gera uma documentação com base nas funções e comentários direto no código, o que facilitou muito a manutenção do projeto. Ele também acabou forçando a equipe a comentar muito o código, o que tornou um código que seria bastante complexo em algo um pouco mais “tragável”.
Mudanças internas no laboratórioA mudança de alguns mestrandos de dentro do laboratório para fora tornou o ambiente um pouco mais favorável à concentração. Infelizmente, segundo a equipe, ainda não está o ideal.
O sucesso da feira que apresentou o produto. A realização de um evento como marco no projeto, como foi a feira realizada no início de Julho/08 se mostrou como uma excelente forma de motivar o time a atingir o resultado. O bom planejamento que foi realizado para o dia, com a finalização do protótipo físico (para demonstração), a criação de um programa que simulava o projeto, textos e banners informativos e um vídeo demonstrando todo o processo de criação tornou o projeto um dos mais bem planejados e representados na feira, sendo bastante elogiado pelos avaliadores.
O comprometimento com a deadline, pela equipe. Nos dias finais que antecederam a feira citada acima, a equipe não se preocupou em trabalhar inclusive à noite e sábados e domingos para entregar o projeto funcional. Isso demonstrou uma capacidade de comprometimento da equipe, com o projeto, que deveria ser um exemplo. A decisão de fazer isso partiu da própria equipe. Muito embora por diversas vezes o projeto tenha ficado em segundo plano (devido a situações pessoais e de estudos), essa demonstração de comprometimento demonstrou como um projeto pode deixar de ser apenas trabalho para se tornar parte da realização pessoal de uma equipe.

Conclusão

Apesar de esta retrospectiva ter sido realizada pelo gerente do projeto e por dois membros da equipe, com a ausência do coordenador e de outro membro, ficou demonstrada a importância da realização de uma retrospectiva para analisar o projeto durante um período. Diversas questões problemáticas poderiam ter sido solucionadas se fossem identificadas mais rapidamente. E diversas questões benéficas poderiam ter sido potencializadas se tivessem sido percebidas com mais antecedência.

Para os próximos projetos as retrospectivas devem ser feitas mais frequentemente e, além disso, as lições relevantes devem ser documentadas e divulgadas para as demais equipes. Algumas lições poderão auxiliar a todos a atingirem um padrão de processo, além de evitar erros comuns que já possam ter sido cometidos por outras equipes.

Neste processo de retrospectiva do projeto poderia ter identificado planos de ação para os problemas levantados, mas nessa retrospectiva específica isso não foi utilizado. Porém é importante pensar em planos de ação para evitar que problemas ocorram ou voltem a ocorrer, funcionando como uma espécie de gestão de riscos do projeto.

No final, a equipe que participou da retrospectiva levantou 24 problemas e 27 coisas boas que ocorrem no projeto (algumas não citadas aqui no post do blog).

O case que me inspirou

2008-07-27T22:43:00.002-03:00

Este post foi um dos que me inspiraram a usar o SCRUM. Confesso que, junto com um artigo que eu li na época, fiquei fascinado com os resultados que eu poderia atingir com o SCRUM. Não vi apenas o lado técnico do projeto, mas muito mais a questão anímica (comportamental) que a mudança causaria.

O Phillip Calçado publicou este relato que até hoje é citado como referência.

Felizmente, o meu blog também tem tido o mesmo reconhecimento. E a idéia é realmente essa: mostrar a todos interessados que aplicar SCRUM (ou mesmo alguns conceitos dele) não é nenhum bicho de sete cabeças. Qualquer um pode e o resultado quase sempre será bacana.

O post é este aqui:

http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

Excelente exemplo sobre "aproximar o cliente"

2008-07-27T22:33:00.004-03:00

Roubei esta historinha do blog do Alexandre Magno . É excelente para mostrar a importância de se trazer o cliente para junto da equipe.

----------------

Estou no aeroporto de Congonhas aguardando que você traga para mim alguns documentos que tenho que levar em uma viagem importante. Você está na região da Av. Paulista e precisa chegar o quanto antes no aeroporto.

SITUAÇÃO 1

Decide então pegar um táxi, chama o taxista mais próximo e pergunta:

- Sr., daqui para o aeroporto de Congonhas quanto tempo levaria – qual sua estimativa?

O taxista provavelmente olharia no relógio, no máximo consultaria pelo rádio sobre como o trânsito está naquela região (não, ele não usaria APF) e, de acordo com sua experiência, lhe daria uma estimava:

- Olha, nesse horário creio que em 30 minutos estejamos por lá.

Você acha a estimativa satisfatória e pega o táxi. Ao chegar no aeroporto você percebe que o táxi levou 80 minutos para chegar até o destino, e ao invés de custar R$ 35 (como previsto), custou R$ 90.

Qual seu sentimento com relação ao motorista?

Você estava dentro do táxi o tempo todo e percebeu que ele fez o possível para chegar a tempo, se esforçou. Você viu que o trânsito estava ruim e que um grave acidente no meio do caminho piorou as coisas. Você viu que quando isso aconteceu o taxista tentou pegar um outro caminho para fugir do trânsito e, por mais que a estratégia tenha sido boa, não foi suficiente para chegar a tempo.

Há, portanto, uma probabilidade muito grande de você, mesmo chateado, pagar o taxista e entender o lado dele, afinal você viu o quanto ele se esforçou para cumprir o prometido.

SITUAÇÃO 2

Mesmo cenário. Porém, imagine que ao invés de ir no táxi, você apenas contrata o taxista para levar os documentos para o aeroporto. Ele lhe deu a mesma estimativa de tempo e custo.

No entanto, 80 minutos depois ele lhe liga e diz: “Olha, o trânsito estava muito complicado... só cheguei agora, o custo foi R$ 90 ao invés de R$ 35”.

Qual será sua reação agora? O que você pensará?

Você não viu o que o motorista fez, não soube de nenhum acidente que possa ter causado um desvio, não sabe se ele se esforçou ou não, apenas está ouvindo o relato de alguém que diz que atrasou. Possivelmente, sejamos sinceros, iremos pensar: "Esse cara está me enganando!".

Moral da história

Coloque seu cliente “dentro do táxi” sempre, só assim ele entenderá o seu processo e suas dificuldades para alcançar o sucesso do projeto. Mantendo-o de fora ele sempre achará que você está querendo “se dar bem”.

Criando falsas (ou nem isso) expectativas...

2008-07-27T21:07:00.002-03:00

Pessoal, desculpem! Desculpem mesmo. Havia prometido para a semana passada que tornaria o blog diário novamente e que postaria o resultado da palestra para a turma de pos (que foi bem legal) e também o resultado da minha retrospectiva com o pessoal do trabalho.

Infelizmente acabei me enrolando e não consegui finalizar os dois. Quero ver se amanhã sem falta posto, ok?

-------------

Vou falar sobre a criação de expectativas, muito graças a comunicação ineficiente que ainda existe no meu trabalho. Vejam a minha situação e reflitam se vocês não vivem a mesma coisa ou pior: se vocês não estão fazendo isso.

Lembram quando eu falei que para iniciar o próximo projeto, os meus chefes queriam fazer uma reunião para definir a parte financeira (RH) do projeto? Cheguei a publicar um post falando disso.

Pois bem. Esperamos naquela quarta-feira. E nada. Dois dos envolvidos sequer avisaram que não poderiam comparecer na reunião. Desde aquele dia (9/7/2008) não teve mais nenhuma palavra a respeito da reunião. Nenhuma! Nem previsão de dia, nem justificativa, nada.

Pior: o meu projeto, que apresentamos na feira, não teve oficializado uma deadline. Ou seja, eu não sei se ele está ativo ou não!! E o pior mesmo? É que os gastos de RH deste projeto já acabaram. Então eu acabei fazendo a minha equipe trabalhar por 15 dias neste mês (para finalizar a documentação) e eu nem sei se eles irão receber por isso.

Poxa, não é uma falta total de respeito com a equipe e com os gerentes, isso? Os meus chefes e os demais envolvidos que tanto falam que temos que mudar a imagem do grupo, que nós temos que trabalhar bastante, etc. dão uma demonstração claríssima de falta de comprometimento e boa vontade com a gente.

O que eu fiz? Bom, fechados os 15 dias, desmobilizei a equipe. Falei que não sabia se o projeto havia sido oficialmente finalizado e então disse que por via das dúvidas eles já haviam feito o que deveriam ter feito. Ponto. Um problema é que a equipe do meu projeto seria a equipe de hardware do próximo projeto... e eles também estavam impacientes sobre os rumos do projeto. Se amanhã eu não obtiver resposta dos meus chefes, vou dar como encerrado o assunto e vou liberar a equipe para que eles procurem emprego em outro local, caso não queiram esperar sentados pela famigerada reunião.

Já eu, fiquei mais alguns dias lá e como não obtive nenhum aceno sobre a reunião, eu mesmo me desmobilizei e não compareci na 5a e 6a. Fiz isso propositalmente, para tentar emitir um sinal indireto de que não estou satisfeito com a situação. Lógico, eu também estou arriscando aqui, seria muito mais simples eu simplesmente perguntar "E ai? E a reunião?". Mas seria a terceira vez neste mês. Tem um momento que a gente cansa e parte para o "semancol".

Eu realmente tenho interesse em permanecer lá por causa deste projeto, pois eu ajudei a elaborá-lo, vou ter maior liberdade para tomar decisões (até onde eu sei) e também será um projeto que eu acredito que tenha um impacto social e tecnológico bastante grande. Aquele legítimo projeto que vale a pena ter no currículo. São exatamente estes fatores que me fazem permanecer no grupo de pesquisas. Caso contrário, sinceramente, já tinha saído fora.

O fato é que eles criaram expectativas muito grandes durante a elaboração deste projeto e mesmo posteriormente. Falaram da reunião como sendo algo importantíssimo, que marcaria o começo do projeto e a mudança do perfil do grupo (ah, vale ressaltar: essa mudança de perfil eles estão considerando como idéia deles - embora eu já tenha demonstrado que iria fazer isso antes). E depois, deram claríssimas demonstrações de que a reunião estava em "segundo plano", pois sequer justificativas para as ausências e reagendamentos a gente teve.

A falta de comunicação nas empresas costuma gerar essa mazela, chamada de "falsas expectativas". É assim que surgem os boatos. É assim que surgem os conflitos. É assim que a desmotivação, o descompromisso e o descontentamento se tornam enormes problemas no emprego.

Por isso, caro leitor, reflita um pouco. Será que a sua empresa vive uma situação parecida? Será que seus chefes usam e abusam do famoso bordão "faça o que eu digo, mas não faça o que eu faço"? Será que você também não está criando falsas expectativas nos seus subordinados?

Enfim... não custa se comunicar. Por pior que seja a mensagem, ao menos ela evitará problemas maiores.

Um abraço e bom início de semana.

Semana boa :)

2008-07-22T23:02:00.002-03:00

Essa semana começou bem.

Hoje, terça-feira, fiz com a minha equipe (desfalcada, pois um dos integrantes está viajando de férias) uma retrospectiva final do projeto, abrangendo os dois anos que estivemos juntos. Algumas coisas interessantes aconteceram :) Vou listá-las amanhã para vocês (hoje estou moído!).

E na sexta-feira irei fazer uma "palestra-dinâmica" para uma turma de pós, na universidade. Será legal ter um público diferente. Para isso, estou adaptando a dinâmica para funcionar melhor. Depois posto ela aqui para vocês utilizarem. Acho que ficará mais divertida :)

Abração

Voltando...

2008-07-21T11:06:00.002-03:00

Pois então, pessoal. Estou de volta.

Semana passada foi meio crítica. O meu pai, no sábado, baixou hospital com algumas dores abdominais, que foram identificadas como uma infecção no local onde ele havia feito uma cirurgia há meses atrás. É um fato raro de acontecer, mas aconteceu.

Deu tudo certo! Na sexta passada ele saiu do hospital e está novo em folha! :)

Mas são nestes momentos que a gente percebe como somos frágeis neste mundo. De uma hora para a outra, podemos estar deitados em uma cama de hospital. A gente começa a refletir um pouco sobre nossos hábitos, sobre a beleza das pequenas coisas, como estar em família. Tirei a semana de folga no trabalho, pois não conseguiria me concentrar sabendo que o meu pai estava hospitalizado. E meus dois irmãos (irmão e irmã) também. Logo, convivemos todos (mais a minha mãe) como antigamente, os cinco juntos. Coisa assim era bastante corriqueira: janta, um final de semana na praia, etc. Mas a semana inteira não :)

E como é bom isso. A gente percebe como a família é mais importante do que tudo.

Refletindo um pouco, a gente as vezes pensa em quantas vezes passamos horas e horas na frente do computador trabalhando. E em quantos momentos já deixamos de fazer algo com a família ou com a gente mesmo, para se dedicar um pouco mais ao trabalho. Por mais que a gente goste de trabalhar, talvez algumas vezes devessemos repensar nossas prioridades. Será que perder uma sexta-feira a noite, ou um final de semana, adiantando trabalho vale a pena? Será que não poderíamos usar esse tempo para nos dedicar a família?

Muito se fala em qualidade de vida. Eu acho que a qualidade de vida está entre balancear corretamente a nossa vida no trabalho com a vida pessoal.

Numa palestra com o Daniel Wildt, no mesmo dia em que eu fiz a palestra sobre o "Scrum in Hell", ele falou uma coisa que acho que mostra a essência de como um processo como o SCRUM pode melhor inclusive a nossa vida pessoal: ele disse que em uma empresa, havia um analista cujo horário de trabalho normalmente ia até as 21h. Então ele tomou este cara como exemplo e desafio e prometeu para ele: "uma das minhas funções aqui é fazer com que tu saia do trabalho às 18h". E conseguiu! Ou seja, o SCRUM (e o agile como um todo) com certeza ajudou a dar mais qualidade de vida para este analista :)

Enfim, estou voltando. E espero voltar a manter a periodicidade diária do blog. Podem me cobrar ;)

Um grande abraço

Ausência forçada por alguns dias mais...

2008-07-15T14:15:00.002-03:00

Caríssimos,

estou enfrentando um problema familiar (cirurgia do meu pai) e por isso não estou podendo postar. Quero ver até o final da semana tudo está resolvido e volto a periodicidade diária do blog :)

Enquanto isso, sugiro que vocês leiam os posts anteriores, principalmente os "recomendados" aqui no menu direito. Tem os podcasts também para quem não ouviu.

Até breve :)

Sugestão para "intranet"

2008-07-10T21:11:00.001-03:00

Amigos,

estamos aqui no trabalho precisando de uma ferramenta para fazer as vezes de "intranet". Tentamos usar os wikis, que são poderosos, mas ao mesmo tempo não são tão intuitivos.

Encontrei essa ferramenta, já consideravelmente conhecida, chamada Zoho Projects (www.zoho.com). Criei um projeto para ver como funciona e gostei muito do que eu vi.

Pode ser adaptada pro SCRUM tranquilamente. É bem simples e bem funcional! Vale a pena e fica a minha sugestão. Algumas features que ela provê:

- Quatro tipos de usuários (admin, contractor, manager, employee) com visões e atribuições diferentes.
- Forum para discussões
- Visualização de o usuário está online ou não (faltou um chat integrado)
- Cadastro de horas trabalhadas (para empresas mais rígidas)
- Controle de arquivos (com versionamento)
- Agendamento de reuniões
- Criação de milestones que contem grupo de tarefas e que contem tarefas. Aqui, basta mudar para sprint (milestone), user story e impediment backlog (grupo de tarefas) e tarefas. As tarefas podem ficar sem atribuições de pessoas, podendo ser atualizada durante a daily meeting.
- Feed RSS para aviso de mudanças
- Log com mudanças que ocorram na página
- Possibilidade de inserir notas em tarefas, reuniões, etc.

Enfim, para quem procura uma ferramenta bem simples e gratuita para controlar o seu projeto, eu recomendo esta.

Fica a sugestão :)

Navegação no blog melhorada!

2008-07-10T01:49:00.003-03:00

Caros leitores,

a navegação no blog ficou facilitada com a inclusão dos links rápidos no menu esquerdo :)

Vocês podem achar facilmente os posts que eu destaquei, as resenhas dos livros sobre projetos e liderança (minhas resenhas, claro) e também os podcasts do blog.

Espero que gostem!

Abraços

--------------

Editado: Menu DIREITO, lógico!! O que é o efeito do sono! haha

Reunião importante nesta quarta-feira

2008-07-08T21:34:00.004-03:00

Quarta feira, 17 horas.

Esse é o horário da reunião mais importante deste ano. Será a reunião onde será decidido como será o nosso próximo projeto. Iremos focar, principalmente, no perfil das equipes. Eles, meus chefes, pretendem mostrar que querem uma mudança radical de atitude das pessoas do laboratório.

Será a minha chance para apresentar a questão da gestão por competências.

O que me deixa meio preocupado é que eles querem mudar... não mudando. Ou seja, vão aproveitar muitos dos que já estão no laboratório e, além disso, querem manter os salários (as bolsas) das pessoas no mesmo nível atual. Daí eu pergunto: se eles realmente querem mudar o perfil, por que agem CONTRA isso?

Mas o ponto mais tenso da reunião será quando falarmos de salários. O salário dos gerentes.

Um dos meus chefes havia me dado a incumbência de fazer o planejamento financeiro de RH do projeto. Eu fiz, prevendo diversas variáveis (inclusive o valor que fica aplicado no banco, gerando rendimentos financeiros). Para o meu salário, peguei a média dos gerente de projetos e taquei ali: R$ 3700,00.

Numa primeira reunião, entre eu, meu colega e meus dois chefes, já houve um princípio de divergência. "Não estão inflacionando o mercado, com este valor?". Eu fui firme: "Não. É o valor de mercado". Deu pra ver que eles não ficaram muito satisfeitos.

No outro dia, marcaram uma nova reunião (essa agora) em que eu e o meu colega estaremos junto com meus dois chefes, mais um coordenador e um diretor da empresa. Ou seja, o cenário está todo armado para que nós façamos uma revisão dos nossos salários.

É claro que eu vou considerar que o ambiente é acadêmico e que a empresa é microempresa. A carga horária também é menor (6h). E quero ouvir deles, quais serão nossas responsabilidades.

Agora, sinceramente, eles também tem que valorizar E MUITO nosso trabalho. Eu e o meu colega recebemos este ano duas ou três tijoladas (projetos incendiários) em que tivemos que agir e recuperá-los. Eu consegui resgatar o meu projeto atual, e o meu colega terminou o dele com antecedência. Temos que lidar com o pessoal do laboratório diariamente, liderando e mantendo a motivação do pessoal. Além disso, eu sou o "escritor oficial" de projetos do laboratório. Sempre que há um edital de projeto, eu sou convocado a auxiliar os meus chefes para escrever. Este que irá começar, de RFID, eu fui o responsável por boa parte do projeto. Também nunca deixamos eles na mão. Sempre fomos integros e honestos. E, por fim, este ano estou fazendo três anos na empresa!

São motivos mais do que de sobra para ter uma remuneração compatível com o mercado. Minha meta é ficar na proximidade de 3000-3200. Abaixo disso, eu já vou pensar muito se fico ou não.

Quero tratar este projeto como meu filho, isso eu já falo há tempos. Irei fazer o possível para entregá-lo em um ano (e alguns meses). Irei me dedicar muito ao projeto. Sei que será um excelente projeto para se ter no currículo, inclusive.

Mas preciso pensar na parte financeira também. Auto-realização não é só fazer o que gosta. É também receber o que se merece.

Enfim. Amanhã é o dia. Vamos ver como estamos cotados lá dentro.

Abraços!

E na reta final... uma ultrapassagem perfeita!

2008-07-08T21:10:00.003-03:00

Como é o destino...

Meus dois últimos posts foram bem pessimistas. Disse inclusive que o meu projeto encerraria com 95% dele finalizado, apenas. Porém, desde o post, só aconteceram coisas boas! E o resultado é que o projeto está 99,9% entregue! :) Sim, teoricamente, mas parece que todo mundo resolveu dar um último gás no último segundo, e o panorama mudou.

Sexta-feira, o desenvolvedor da parte do software ficou até tarde trabalhando no laboratório. Queria tentar resolver os bugs que haviam aparecido nos testes. Enquanto isso, eu me dedicava a fazer o vídeo do nosso projeto. Ele estava irritado pois não achava o erro. E eu estava preocupado pois não encontrava vídeos onde pudessem aparecer cenas no campo, já que nosso projeto é de agricultura de precisão. Precisava de tratores, colheitadeiras, etc.

Sábado, envio um email para o meu chefe e ele me diz que encontrou umas fotos e vídeos antigos que fizemos quando fomos na fazenda dele, ainda no início do projeto. Bingo! Todo o material que eu precisava estava lá!! Ao mesmo tempo, o desenvolvedor de software voltou para trabalhar durante toda tarde no laboratório, para encerrar de uma vez o software. Ao final do dia, envia um email comemorando por ter resolvido (teoricamente) todos os bugs que tínhamos. E ainda deu tempo de fazer um sistema DEMO para rodar no dia da feira!

Domingo, finalizo o filme e um documento contendo todos os custos do nosso protótipo. Envio para o pessoal e todos ficam animadíssimos com o filme.

Então chega o dia da feira, segunda-feira. Acordo cedo, 6h30, para levar a namorada na rodoviária. Tinha que estar no trabalho às 8h30. Então durante uma hora e meia finalizo alguns outros materiais e corro para o trabalho. Lá apresento a versão final do filme e todos comemoram pois o resultado ficou realmente muito bacana! O documento dos custos é aprovado por todos também, pois era algo que iríamos precisar MUITO na feira.

Chegando na feira, diversas outras empresas já se encontravam lá. Arrumamos nossa mesa da seguinte forma:

- Notebook rodando o vídeo, em loop;
- Notebook rodando a demonstração do produto;
- Nosso protótipo (numa caixa e acabamento bem razoável) rodando o demo (acendendo luzinhas!);
- Um banner explicativo, bem bacana;
- Cartões de visita, folders, etc.

A nossa principal missão é agradar a comissão avaliadora, que veria os resultados produzidos pelo projeto. Organizamos nosso espaço de forma bem bacana e ainda tivemos sorte de que nossos vizinhos eram projetos extremamente simples (um era sobre abacates!!! Sabe-se lá o que era aquilo hehe).

Durante toda feira pudemos ver que das aproximadamente 20 empresas que estavam no local, éramos sem dúvida nenhuma a segunda melhor a apresentar seus produtos. Não fomos a primeira pois uma das empresas desenvolveu um scanner sensacional, e já estava em versão de produto... impossível competir com um produto tão perfeito, vamos ser sinceros. Fora isso, não tenho dúvidas que o nosso projeto era o que melhor foi divulgado lá.

Os resultados: várias pessoas interessadas em conhecer nosso produto, nenhum problema durante a apresentação, nenhum problema na avaliação (inclusive conseguimos encantar vários avaliadores). Internamente falando, TODA equipe de desenvolvimento estava satisfeita e orgulhosa do resultado. O meu chefe também ficou muito feliz e satisfeito. E eu, claro, me senti muito orgulhoso em ver que tudo havia dado certo. Tanto que não me preocupei em ficar aproximadamente seis horas de pé!

Essa semana iremos fazer a finalização do documento. E meu chefe agora se empolgou e quer fazer o teste final na fazenda, em um trator. Assim podemos ter um vídeo bem completo de todo o projeto. Além disso, a documentação do conhecimento adquirido no projeto será feita via vídeo também. Ninguém conseguirá escrever muito nessa semana, então decidi fazer vídeo. Não vai adiantar muito, mas pelo menos é alguma coisa.

Na sexta-feira faremos a retrospectiva final do projeto. Vamos analisar nossos erros, acertos, o que poderíamos ter feito de melhor, etc. Acho que isso será muito importante. Além disso, tentarei fazer uma sessão de feedback, para discutirmos a atuação individual de cada um. Isso também eu acho que será bem interessante.

Enfim. Essa reta final mostrou que quando um projeto deixa de ser apenas trabalho e passa a ser visto como uma realização pessoal, a coisa muda completamente de figura. Eu jamais imaginei que o desenvolvedor iria trabalhar um sábado inteiro para finalizar a parte dele. Essa foi uma das atitudes que mais me supreenderam nos últimos meses. Graças a ele pudemos ter algo bem tangível com relação ao nosso produto.

Foi uma prova de que se conseguirmos fazer essa mentalidade em toda a equipe, qualquer projeto que pegarmos será um sucesso. Agora, se tratarmos a equipe como "recursos" e um projeto como trabalho, realmente a coisa não irá fluir naturalmente. E o resultado tenderá ao fracasso.

Uma lição aprendida na prática.

Um grande abraço

Finalizando o projeto... infelizmente em 95%

2008-07-04T20:22:00.003-03:00

Pois é. O grande Murphy resolveu dar uma pitadinha de humor negro neste final de projeto.

É dose. Hoje fizemos o teste final, antes da apresentação na segunda-feira. E novamente alguns problemas (de algorítmo) surgiram. Como a semana que vem será "extra-oficial" para o projeto, eu posso dizer que finalizamos o projeto com algo como 95% dele finalizado.

Eu me sinto orgulhoso por conseguir entregar esses 95%, visto a situação em que ele se encontrava há pouco mais de 6 meses atrás. Porém, ainda assim, fica aquele gostinho de que eu poderia ter feito algo mais. Talvez não tecnicamente (já que eu não tinha quase nenhum domínio na tecnologia), mas poderia ter esticado a corda um pouco mais... fazer a equipe sair dos momentos de zona de conforto em que estiveram por longos períodos.

Essa semana, por exemplo, na 2a e 3a eles ficaram só estudando para as provas da faculdade. Hoje constatamos que se tivéssemos mais um dia para fazer os testes, quase certamente finalizaríamos o projeto. Ou seja, se eles tivessem se dedicado um pouco (2 horas que fosse) nestes dois dias, poderíamos ter avançado mais.

Não estou muito feliz, é lógico. Mas saio com a sensação de que fiz o possível e que tive uma boa participação para que este projeto não fosse mais problemático do que foi. Podia ter feito mais, mas também não vou me culpar demais.

Vou ver se essa semana faço uma "retrô" aqui para tentar expôr algumas lições aprendidas. Para vocês e para mim será bastante útil, com certeza :)

Um abraço

Murphy visitando o meu projeto

2008-07-03T23:49:00.002-03:00

Tem coisas que deixam a gente maluco.

Uma delas é quando as coisas dão erradas, quando precisam darem certas. Nosso projeto foi para teste de campo hoje. Os guris simularam desde ontem e tudo parecia perfeito. Levamos nosso equipamento para o estacionamento e começamos a testar.

E... ?

Problemas no LCD. Problemas nos LEDs. Problemas nos algorítmos. E isso com o meu chefe do lado. Ele estava empolgado no começo. Acabou, era visível o desânimo na cara dele (e na minha).

A situação é a seguinte: esse projeto precisa estar pronto para ser apresentado na segunda-feira!

Os guris prometeram que ficariam até tarde hoje finalizando as coisas. Eles diziam ter certeza de quais eram os problemas. Amanhã faremos novos testes... será que o nosso amigo Murphy vai nos visitar de novo?

Esse "cabra safado" que ouse! :)

Um abraço

Palestra "Scrum in Hell - Implantando agilidade em ambientes difíceis"

2008-07-01T23:45:00.004-03:00

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Salve pessoal,

Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.

O link para download é este.

Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.

A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)

Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.

No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.

Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.

Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!

O link para download da apresentação é este.

Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.

Um grande abraço

É hoje a palestra!

2008-06-30T11:54:00.002-03:00

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...

Correria... e o blog desatualizado

2008-06-27T11:03:00.002-03:00

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!

Evento de Metodos Ágeis em Porto Alegre - 30/06

2008-06-25T11:54:00.002-03:00

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

Data: 30 de junho de 2008

Horário: 18h30min

Local: Auditório 517 da Faculdade de Informática da PUCRS (prédio 32)

Implantando o SCRUM a conta-gotas.

2008-06-23T21:42:00.006-03:00

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

Mudando uma Pequena Empresa

Novo blog no ar!

Novo blog saindo do forno

Excelente entrevista sobre RESILÊNCIA

Novo blog

O gerente e a ansiedade

Promoção do blog

Quantos lados tem uma empresa?

Postagens ...

Muitos projetos

Agilistas-san

2009!

Ouvindo as bases...

Scrum e XP direto das trincheiras

Mudar de empresa é difícil. De área então......

"A nossa pressão"

Why so serious?

Comunicação interna - um velho problema

Tédio, tédio...

A geração que veio para ficar

Cadê as mensagens do dia-a-dia?

Scrum vs. cultura da empresa

Dinâmica de aviões - PUCRS 2008/2 (com fotos e vídeos!)

Português

Colaboração do cliente = feedback mais cedo!

O desafio do agile

Dinâmica dos aviões

Eventos empresariais: por que ficar na mesmice?

Férias forçadas

Teoria x Prática

Por que agile é TÃO legal

Como cometer suicídio numa entrevista de emprego

Marketing de relacionamento

Diferenças entre uma micro e uma pequena empresa.

Um peixe fora da água... e perdido.

Colaboração do cliente

O primeiro dia na nova empresa

Último dia de trabalho...

Entrevistando ... pessoas.

Currículos, como NÃO montar o seu!

A difícil decisão da troca de emprego

Atualização...

CSM em Porto Alegre (Outubro e Novembro)

Objetivos

Metodologia de Treinamento

Graduação

AGENDA

Onde e Quando?

Materiais do curso

Certificação

Investimento

Formulário de Inscrição

Uma grande decepção

Posicionamento... você sabe qual é o seu?

Propaganda

Negociação de salário

Efeito globalização

Renault x GM

"15 anos de casa..." e outros chavões dos chefes..

Rápido resumo da semana

Enferrujado!

Situações... você se identifica com alguma?

Protótipo e o cliente

Revista Época Especial - As 100 melhores empresas para se trabalhar

Contrastes

Valorizando a comunicação!

Relato de um "recém-PMP"

Enquete deste mês

Curso de dicção, oratória e desnibição

Ok, eu me rendo!

Prova PMP com questão maluca!

Isto É ed. 2024 (Capa do Michael Phelps)

Sexta-feira, o dia do "yes!"

Apresentação: Essência de Gerenciamento de Projetos

Revista MundoPM Ago/Set 08

Semana pesada

Trabalhando com gente competente!

Porque eu escrevo este blog

Dia desorganizado!

Choque cultural e falta de identidade...