quinta-feira, 27 de novembro de 2008

A geração que veio para ficar

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!

segunda-feira, 24 de novembro de 2008

Cadê as mensagens do dia-a-dia?

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

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 É.

terça-feira, 18 de novembro de 2008

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

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.

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!





sábado, 15 de novembro de 2008

Português

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!

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.

quinta-feira, 13 de novembro de 2008

O desafio do agile

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

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!

segunda-feira, 10 de novembro de 2008

Eventos empresariais: por que ficar na mesmice?

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

quinta-feira, 6 de novembro de 2008

Férias forçadas

Caros leitores,

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

Na segunda-feira estou postando de novo.

Abraços!

sábado, 1 de novembro de 2008

Teoria x Prática

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? :)