Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Há algum tempo atrás recebi este email em uma das listas que participo (restrita a um curso que eu fiz). Esse assunto é recorrente em outras listas, sendo uma thread criada quase que semanalmente.
Resolvi então criar um PDF com base no email que continha as informações e estou disponibilizando no blog para download, para quem tiver interesse. No documento estão descritos os critérios desta pesquisa (CLT, sem bônus, etc).
Eu vou ver se acho outro que fala sobre os profissionais de TI para publicar também em breve.
Use este link para fazer o download do PDF com os valores.
Ou use a seção de downloads. Está localizado dentro da pasta "Material de Apoio MPE".
--------
EDITADO:
--------
Consegui uma versão da média de profissionais de TI. Mas não tem os critérios. O link do site da Info é este. Ou se preferirem fazer download, o link é este.
Um abraço e aproveitem
quarta-feira, 30 de abril de 2008
terça-feira, 29 de abril de 2008
Implantando o sistema em um cliente
Após o aviso de que teríamos uma implantação do sistema em um dos nossos clientes (como descrito no post anterior), hoje foi o dia da correria.
A reunião de apresentação era as 14h. Cheguei no laboratório às 13h. O meu colega estava desesperado... já estava me dizendo que não daria para ser naquele dia. Ele estava pessimista.
Eu achei que poderíamos cumprir o prazo. E em 1 hora conseguimos configurar o ambiente, testar e validar o sistema remotamente, na máquina do cliente! Claro, metade das coisas eu e o meu colega tivemos que dizer ("eles tem o JRE lá? A base tá ok lá?"), mas isso a gente já está acostumado.
No fim das contas, a reunião não foi de apresentação do sistema, mas foi importantíssimo termos participado. Pois conseguimos reaver um cliente quase perdido e também nos alinhamos melhor com eles, ao invés de ter a comunicação intermediada pelos coordenadores.
Me senti satisfeito por ter conseguido recuperar isso, pois todos estavam pessimistas. Amanhã iremos levantar mais requisitos junto a eles.
SCRUM? Nada... ainda não deu tempo ;/
Abraços
A reunião de apresentação era as 14h. Cheguei no laboratório às 13h. O meu colega estava desesperado... já estava me dizendo que não daria para ser naquele dia. Ele estava pessimista.
Eu achei que poderíamos cumprir o prazo. E em 1 hora conseguimos configurar o ambiente, testar e validar o sistema remotamente, na máquina do cliente! Claro, metade das coisas eu e o meu colega tivemos que dizer ("eles tem o JRE lá? A base tá ok lá?"), mas isso a gente já está acostumado.
No fim das contas, a reunião não foi de apresentação do sistema, mas foi importantíssimo termos participado. Pois conseguimos reaver um cliente quase perdido e também nos alinhamos melhor com eles, ao invés de ter a comunicação intermediada pelos coordenadores.
Me senti satisfeito por ter conseguido recuperar isso, pois todos estavam pessimistas. Amanhã iremos levantar mais requisitos junto a eles.
SCRUM? Nada... ainda não deu tempo ;/
Abraços
segunda-feira, 28 de abril de 2008
"O cliente sempre tem a razão"
Dizem que essa carta é real. Pelo texto, dá pra ver que é de Portugal.
Verdade ou não, é muito engraçado para dar uma aliviada no stress :)
Verdade ou não, é muito engraçado para dar uma aliviada no stress :)
Comunicação? Não... não é tão importante. E também: o guri de 18 anos.
Semana passada implantei a metodologia de SCRUM para atacar um dos principais problemas do laboratório: COMUNICAÇÃO. Pois não é que hoje eles conseguem me pregar mais uma peça?!
Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:
- E ai, Flavio, amanhã vamos apresentar o sistema então?
- Hein? Qual sistema? (surpreso)
- O da administração da universidade, para o controle de ativos!
- Não estou sabendo de nada!!! (aflito)
- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.
- Ah... tá bem, mas estou sabendo por ti agora. (resignado)
O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.
De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.
----------------------------------
Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...
Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.
O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).
Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.
Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.
Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!
Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?
Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!
Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".
Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!
Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.
Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:
- E ai, Flavio, amanhã vamos apresentar o sistema então?
- Hein? Qual sistema? (surpreso)
- O da administração da universidade, para o controle de ativos!
- Não estou sabendo de nada!!! (aflito)
- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.
- Ah... tá bem, mas estou sabendo por ti agora. (resignado)
O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.
De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.
----------------------------------
Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...
Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.
O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).
Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.
Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.
Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!
Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?
Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!
Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".
Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!
Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.
sábado, 26 de abril de 2008
Produtividade x internet
Mais uma do Dilbert, que é excelente.
De tempos em tempos, um dos meus chefes volta com sua idéia mirabolante de cortar a internet do laboratório. Diz ele que todos seriam mais focados, pois não haveria MSN, páginas e afins. "Estão com alguma dúvida? Que busquem um livro então!".
Os outros coordenadores não levam essa idéia a sério. Também, gostaria de saber como um laboratório de pesquisa poderia produzir pesquisa SEM internet? Ou emails? Essa charge abaixo traduz isso perfeitamente!
De tempos em tempos, um dos meus chefes volta com sua idéia mirabolante de cortar a internet do laboratório. Diz ele que todos seriam mais focados, pois não haveria MSN, páginas e afins. "Estão com alguma dúvida? Que busquem um livro então!".
Os outros coordenadores não levam essa idéia a sério. Também, gostaria de saber como um laboratório de pesquisa poderia produzir pesquisa SEM internet? Ou emails? Essa charge abaixo traduz isso perfeitamente!
Distrações no ambiente de trabalho
Uma das melhores coisas dessa semana foi que três membros do laboratório sairam para fora da sala, para o setor onde os mestrandos e doutorandos ficam. Casualmente eram as três pessoas que mais distraiam o pessoal com conversa e afins. São gente boa, mas para trabalhar parece que falta essa maturidade.
Essa charge do Dilbert mostra o tipo de funcionário que toda empresa deveria ter, para lidar com situações como as de distrações. Aproveitem!
Essa charge do Dilbert mostra o tipo de funcionário que toda empresa deveria ter, para lidar com situações como as de distrações. Aproveitem!
Implantação do SCRUM no laboratório - Parte X
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Sexta-feira foi o nosso último dia da dinâmica de uma semana de SCRUM.
Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.
Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.
Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.
A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.
Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.
De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.
De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.
O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)
De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.
O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!
E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:
TO DO --- DOING --- VERIFY --- DONE
O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.
Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!
Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.
E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.
Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.
Abraços!
Sexta-feira foi o nosso último dia da dinâmica de uma semana de SCRUM.
Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.
Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.
Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.
A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.
Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.
De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.
De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.
O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)
De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.
O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!
E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:
TO DO --- DOING --- VERIFY --- DONE
O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.
Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!
Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.
E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.
Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.
Abraços!
sexta-feira, 25 de abril de 2008
Implantação do SCRUM no laboratório - Parte IX - a
Falei que ontem de noite eu havia enviado um email para os meus chefes explicando o porque eu preferia que eles não fossem os "clientes" dessa dinâmica, pois temia que eles não entendessem que utilizamos a semana para eles vivenciarem o SCRUM e desenvolverem pequenas partes dos projetos em que atuam.
Recebi essa resposta por email:
"(...) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (...)".
A dificil arte de agradar gregos e troianos.
PARTE X
Recebi essa resposta por email:
"(...) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (...)".
A dificil arte de agradar gregos e troianos.
PARTE X
quinta-feira, 24 de abril de 2008
Implantação do SCRUM no laboratório - Parte IX
Segundo dia de sprint. Hoje eu já tentei deixá-los mais "a vontade". Em praticamente todos os grupos surgiram impedimentos, mas só em um deles era um impedimento real. Nos demais eu deixei claro a diferença entre impedimento e pró-atividade, novamente.
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana... parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas... muito por culpa do "cliente" deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um "gurizão" (como chamamos aqui no Sul :), já que tem menos de 20 anos, ele ainda está naquela fase de insegurança... o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer "Ok, tu tens que fazer isso, isso e aquilo" eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto :)
Aliás, estou fazendo jus aquela máxima que diz que "o gerente de projetos é sempre aquele que nunca está na sua mesa". Estou sempre em reunião, em contato com meus subordinados, colegas, chefes... ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
------------------------------------------------
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los... tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os "entregáveis" são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um "checklist" de perguntas que farei ;)
----------------------------------------------------
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda... mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Abraços a todos!
PARTE IX - a
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana... parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas... muito por culpa do "cliente" deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um "gurizão" (como chamamos aqui no Sul :), já que tem menos de 20 anos, ele ainda está naquela fase de insegurança... o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer "Ok, tu tens que fazer isso, isso e aquilo" eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto :)
Aliás, estou fazendo jus aquela máxima que diz que "o gerente de projetos é sempre aquele que nunca está na sua mesa". Estou sempre em reunião, em contato com meus subordinados, colegas, chefes... ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
------------------------------------------------
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los... tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os "entregáveis" são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um "checklist" de perguntas que farei ;)
----------------------------------------------------
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda... mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Abraços a todos!
PARTE IX - a
quarta-feira, 23 de abril de 2008
Implantação do SCRUM no laboratório - Parte VIII
Primeiro dia oficial do sprint relâmpago. Algumas constatações:
- Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
- Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um "report" em breve.
- Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos "chickens" (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais "dentro" do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que "ele só fica na internet, não trabalha", mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
- Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico... testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a "user story" deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
==========================================
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários... lembram daquela máxima: "Traga-me soluções e não problemas"? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Abraços
PARTE IX
- Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
- Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um "report" em breve.
- Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos "chickens" (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais "dentro" do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que "ele só fica na internet, não trabalha", mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
- Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico... testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a "user story" deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
==========================================
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários... lembram daquela máxima: "Traga-me soluções e não problemas"? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Abraços
PARTE IX
terça-feira, 22 de abril de 2008
Implantação do SCRUM no laboratório - Parte VII
Hoje foi o primeiro dia da "dinâmica".
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas... só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento... é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio... é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
AMARELO (padrão) : tarefas planejadas (planned tasks)
LARANJA : user stories
ROSA : tarefas não planejadas (unplanned tasks)
RECICLADOS : impedimentos
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios... além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos... essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados... sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um "ante-projeto" destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
"O usuário pode depositar o dinheiro na conta"
"O usuário pode definir quais são as pessoas que podem visualizar seu perfil"
"O usuário pode buscar livros pelo autor, nome do livro e código"
São coisas bem específicas e fáceis de visualizar. Mas um dos "projetos" é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API's.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos...
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação...
Será que consigo mudar? O tempo dirá.
Um abraço a todos!
PARTE VIII
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas... só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento... é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio... é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
AMARELO (padrão) : tarefas planejadas (planned tasks)
LARANJA : user stories
ROSA : tarefas não planejadas (unplanned tasks)
RECICLADOS : impedimentos
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios... além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos... essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados... sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um "ante-projeto" destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
"O usuário pode depositar o dinheiro na conta"
"O usuário pode definir quais são as pessoas que podem visualizar seu perfil"
"O usuário pode buscar livros pelo autor, nome do livro e código"
São coisas bem específicas e fáceis de visualizar. Mas um dos "projetos" é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API's.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos...
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação...
Será que consigo mudar? O tempo dirá.
Um abraço a todos!
PARTE VIII
sábado, 19 de abril de 2008
Implantação do SCRUM no laboratório - Parte VI
Conforme o planejado, hoje foi o dia em que sentamos com cada uma das equipes (definimos que teremos CINCO projetos) e definimos quais seriam as user stories que eles teriam que cumprir até o fim.
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fazer algo de alto nível]".
Ou seja, por exemplo:
* Um usuário pode clicar em diversos pontos do simulador e o sistema irá apresentar as curvas paralelas resultantes (user story de um dos projetos)
* Um usuário pode passar diversos objetos na antena e o sistema apresentará os resultados
Como somos um grupo de pesquisa e a maioria dos projetos envolve hardware ou software de baixo nível, precisamos adequar as User Stories à nossa realidade. A maioria dos livros tratam as user stories como software de mais alto nível ("Um usuário pode buscar pelo nome de um livro" ou "Um usuário pode excluir seus dados pessoais"). Então temos que tentar buscar uma forma de manter o conceito mas adaptando ao máximo para nossa realidade.
Tivemos dificuldades em abstrair isso, mas é assim que a gente aprende: na prática!
Só não conseguimos fechar as user stories de dois projetos. Um pelos membros não terem aparecido e o outro pelo assunto ser muito técnico e nebuloso. Iremos tentar achar alguma parte que possamos apresentar.
Como eu disse, a idéia é fazê-los vencer essa etapa e não sofrer uma nova derrota.
========================================================
No fim do dia, eu e o outro gerente também discutimos a respeito da nova ordem de comunicação que implanteremos. Atualmente vivemos algo como três níveis de hierarquia:
COORDENADORES
GERENTES
EQUIPES
A comunicação correta seria de que os gerentes fossem um filtro. No máximo, na minha opinião, as equipes pudessem consultar os coordenadores. Porém, é comum os coordenadores comunicarem diretamente com as equipes, deixando os gerentes de mãos atadas.
Hoje ocorreu um caso típico: soubemos que um dos recursos de um projeto seria desligado do laboratório e passaria para a empresa parceira. Fomos os últimos a saber, lógico. E contávamos com ele para o nosso planejamento.
Com o SCRUM, a nossa idéia é criar mais um nível hierárquico, algo assim:
CLIENTES / COORDENADORES (stakeholders ou "chickens")
PRODUCT OWNERS
SCRUM MASTERS
EQUIPE
A primeira coisa que você deve estar pensando, aposto, é: "Pô, eles tão tornando tudo mais burocrático aumentando a hierarquia". Eu digo que não, e vou explicar o porque.
Primeiro, pois na nossa visão estaremos deixando os coordenadores apenas como "chickens", ou seja, apenas como envolvidos no projeto e não mais comprometendo eles. Nossos coordenadores já estão com demandas e tarefas até o pescoço! São professores universitários, então eles tem que orientar doutorado, mestrado, dar aulas, corrigir TCC, auxiliar os projetos, etc. Muita coisa!
Segundo, pois isolando os coordenadores, estaremos obrigatoriamente dando os poderes de decisão aos product owners. A minha idéia é que eu e o outro gerente nos transformemos nestes product owners. Porém, lógico, para que isso aconteça, precisamos encontrar scrum masters adequados. E isso vai demandar tempo.
Terceiro, pois criando mais uma hierarquia, deixamos muito mais difícil a comunicação direta entre os coordenadores e as equipes, o caso mais problemático. Em contrapartida, se isso ocorrer, serão DOIS níveis que estarão sem essa "informação".
Ainda assim, acredito que valerá a pena. Os coordenadores trabalharão como clientes ou com os clientes. E caberá aos P.O.'s fazerem essa interface com as equipes e manter os clientes/coordenadores informados do andamento das coisas.
Enfim, iremos apresentar essa proposta de mudança e eu tentarei expôr exatamente o que estou dizendo aqui. Precisaremos do comprometimento deles em acatar isso e não cobrarem as equipes diretamente, ou pior, dar demandas diretamente. Os recursos estão ficando escassos, se eles nos jogarem mais este problema no colo, a situação ficará difícil!
==================================================================
Também ao final da reunião expressei ao outro gerente qual é o meu plano para longo prazo, para o laboratório: torná-lo uma referência dentro da universidade. Como iremos fazer isso?
Bom, um passo de cada vez. Primeiro vamos nos tornar produtivos. Depois vamos buscar começar a aparecer de alguma forma. Os frutos começarão daí.
==============================================================
Terça-feira de manhã iremos adequar todo o laboratório com as taskboards prontas para receberem as user stories e atividades. Terei que comprar todo material de escritório necessário. Vou bancar do bolso, nesse primeiro momento. Depois eu peço um reembolso ;)
Um ótimo final de semana a vocês.
Abraços
PARTE VII
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fazer algo de alto nível]".
Ou seja, por exemplo:
* Um usuário pode clicar em diversos pontos do simulador e o sistema irá apresentar as curvas paralelas resultantes (user story de um dos projetos)
* Um usuário pode passar diversos objetos na antena e o sistema apresentará os resultados
Como somos um grupo de pesquisa e a maioria dos projetos envolve hardware ou software de baixo nível, precisamos adequar as User Stories à nossa realidade. A maioria dos livros tratam as user stories como software de mais alto nível ("Um usuário pode buscar pelo nome de um livro" ou "Um usuário pode excluir seus dados pessoais"). Então temos que tentar buscar uma forma de manter o conceito mas adaptando ao máximo para nossa realidade.
Tivemos dificuldades em abstrair isso, mas é assim que a gente aprende: na prática!
Só não conseguimos fechar as user stories de dois projetos. Um pelos membros não terem aparecido e o outro pelo assunto ser muito técnico e nebuloso. Iremos tentar achar alguma parte que possamos apresentar.
Como eu disse, a idéia é fazê-los vencer essa etapa e não sofrer uma nova derrota.
========================================================
No fim do dia, eu e o outro gerente também discutimos a respeito da nova ordem de comunicação que implanteremos. Atualmente vivemos algo como três níveis de hierarquia:
COORDENADORES
GERENTES
EQUIPES
A comunicação correta seria de que os gerentes fossem um filtro. No máximo, na minha opinião, as equipes pudessem consultar os coordenadores. Porém, é comum os coordenadores comunicarem diretamente com as equipes, deixando os gerentes de mãos atadas.
Hoje ocorreu um caso típico: soubemos que um dos recursos de um projeto seria desligado do laboratório e passaria para a empresa parceira. Fomos os últimos a saber, lógico. E contávamos com ele para o nosso planejamento.
Com o SCRUM, a nossa idéia é criar mais um nível hierárquico, algo assim:
CLIENTES / COORDENADORES (stakeholders ou "chickens")
PRODUCT OWNERS
SCRUM MASTERS
EQUIPE
A primeira coisa que você deve estar pensando, aposto, é: "Pô, eles tão tornando tudo mais burocrático aumentando a hierarquia". Eu digo que não, e vou explicar o porque.
Primeiro, pois na nossa visão estaremos deixando os coordenadores apenas como "chickens", ou seja, apenas como envolvidos no projeto e não mais comprometendo eles. Nossos coordenadores já estão com demandas e tarefas até o pescoço! São professores universitários, então eles tem que orientar doutorado, mestrado, dar aulas, corrigir TCC, auxiliar os projetos, etc. Muita coisa!
Segundo, pois isolando os coordenadores, estaremos obrigatoriamente dando os poderes de decisão aos product owners. A minha idéia é que eu e o outro gerente nos transformemos nestes product owners. Porém, lógico, para que isso aconteça, precisamos encontrar scrum masters adequados. E isso vai demandar tempo.
Terceiro, pois criando mais uma hierarquia, deixamos muito mais difícil a comunicação direta entre os coordenadores e as equipes, o caso mais problemático. Em contrapartida, se isso ocorrer, serão DOIS níveis que estarão sem essa "informação".
Ainda assim, acredito que valerá a pena. Os coordenadores trabalharão como clientes ou com os clientes. E caberá aos P.O.'s fazerem essa interface com as equipes e manter os clientes/coordenadores informados do andamento das coisas.
Enfim, iremos apresentar essa proposta de mudança e eu tentarei expôr exatamente o que estou dizendo aqui. Precisaremos do comprometimento deles em acatar isso e não cobrarem as equipes diretamente, ou pior, dar demandas diretamente. Os recursos estão ficando escassos, se eles nos jogarem mais este problema no colo, a situação ficará difícil!
==================================================================
Também ao final da reunião expressei ao outro gerente qual é o meu plano para longo prazo, para o laboratório: torná-lo uma referência dentro da universidade. Como iremos fazer isso?
Bom, um passo de cada vez. Primeiro vamos nos tornar produtivos. Depois vamos buscar começar a aparecer de alguma forma. Os frutos começarão daí.
==============================================================
Terça-feira de manhã iremos adequar todo o laboratório com as taskboards prontas para receberem as user stories e atividades. Terei que comprar todo material de escritório necessário. Vou bancar do bolso, nesse primeiro momento. Depois eu peço um reembolso ;)
Um ótimo final de semana a vocês.
Abraços
PARTE VII
sexta-feira, 18 de abril de 2008
Implantação do SCRUM no laboratório - Parte V - a
Uma coisa que esqueci de comentar e acredito que seja muito importante.
É preciso fazer com que as user stories que levantaremos para cada um dos projetos (os seis deles) sejam pequenas e, principalmente, que sejam factíveis de serem feitas três dias de trabalho.
Caso contrário, o resultado do sprint "zero" será a vivência deles no que eles estão acostumados há tempos: o fracasso!
Muito cuidado nessa hora...
PARTE VI
É preciso fazer com que as user stories que levantaremos para cada um dos projetos (os seis deles) sejam pequenas e, principalmente, que sejam factíveis de serem feitas três dias de trabalho.
Caso contrário, o resultado do sprint "zero" será a vivência deles no que eles estão acostumados há tempos: o fracasso!
Muito cuidado nessa hora...
PARTE VI
quinta-feira, 17 de abril de 2008
Implantação do SCRUM no laboratório - Parte V
Tcharam!
O dia da apresentação chegou.
Procurei chegar um pouco mais cedo no trabalho, com o intuito de já ir adiantando a preparação do notebook, projetor, etc. O horário era 13h45.
Entrei no auditório do prédio, instalei algumas coisas e fui verificar se estava tudo ok com a apresentação. Nisso chegou o meu colega que será o meu braço direito nesse processo todo. Conversávamos enquanto eu fui fazendo isso. O horário era 13h55.
As 14h05 chegou a primeira leva do guris. Um terço deles, dá pra dizer. Às 14h15 chegou a segunda leva. Às 14h20 chegaram os coordenadores e o resto do pessoal.
Enfim, comecei a apresentação às 14h30. Era o horário que eu queria ter marcado, MAS um dos coordenadores falou que era melhor começar as 14h........ :/
Como eu havia pensando, avisei no início que quem tivesse dúvidas que escrevesse em um papel para perguntar ao final da apresentação. Por que? Para evitar que gerasse uma discussão paralela no meio da apresentação.
A apresentação transcorreu muito bem. Achei que eu ficaria um tanto perdido em algum momento, mas o único momento em que eu senti que me embananei um pouco, foi ao explicar a tirinha dos "porcos e galinhas". Acho que quis explicar demais e acabei enrolando. Nada que afetasse.
Procurei colocar algumas interações com o grupo, para não ficar só uma falação. E foi legal para descontrair.
Ah, como eu mencionei no post anterior, coloquei um slide para falar a respeito dos resultados da minha "pesquisa com os grupos" de ontem. Iniciei falando sobre o que é um projeto, quais são as suas características... e daí expus o motivo daquilo. Os problemas que estavam acontecendo lá e que eu consegui identificá-los de forma explícita.
A apresentação original estava prevista para ter 25 slides. Mas, comecei a perceber que ela poderia vir a ser uma referência para o pessoal, posteriormente, ao ser impressa em PDF. Portanto acabei deixando ela bem completa, com alguns exemplos para contextualizar situações.
No fim, acredito que todos ficaram satisfeitos. Notei, na prática, que alguns itens estavam fora de ordem (falava sobre previsto x realizado antes de falar de sprint, por exemplo). Mas, como eu disse, nada que fosse tão ruim a ponto de deixá-los perdidos.
Acredito que vendi o peixe! Ao final da apresentação, todos se mostravam dispostos a experiementar o SCRUM... a vivenciar a dinâmica que aplicaremos de 6a a 6a feira. Agora terei BASTANTE trabalho pois atuarei como coach, scrum master e product owner ao mesmo tempo! Mas vai valer a pena!
Espero que na outra sexta-feira eu esteja aqui escrevendo os resultados sensacionais que tivemos. Espero mesmo!
Para quem quiser fazer download, o link está aqui embaixo. A apresentação em PDF :)
DOWNLOAD DA APRESENTAÇÃO EM PDF
Ou entrem na seção de downloads e vão em "Material de apoio MPE" :)
Abração
PARTE V - a
O dia da apresentação chegou.
Procurei chegar um pouco mais cedo no trabalho, com o intuito de já ir adiantando a preparação do notebook, projetor, etc. O horário era 13h45.
Entrei no auditório do prédio, instalei algumas coisas e fui verificar se estava tudo ok com a apresentação. Nisso chegou o meu colega que será o meu braço direito nesse processo todo. Conversávamos enquanto eu fui fazendo isso. O horário era 13h55.
As 14h05 chegou a primeira leva do guris. Um terço deles, dá pra dizer. Às 14h15 chegou a segunda leva. Às 14h20 chegaram os coordenadores e o resto do pessoal.
Enfim, comecei a apresentação às 14h30. Era o horário que eu queria ter marcado, MAS um dos coordenadores falou que era melhor começar as 14h........ :/
Como eu havia pensando, avisei no início que quem tivesse dúvidas que escrevesse em um papel para perguntar ao final da apresentação. Por que? Para evitar que gerasse uma discussão paralela no meio da apresentação.
A apresentação transcorreu muito bem. Achei que eu ficaria um tanto perdido em algum momento, mas o único momento em que eu senti que me embananei um pouco, foi ao explicar a tirinha dos "porcos e galinhas". Acho que quis explicar demais e acabei enrolando. Nada que afetasse.
Procurei colocar algumas interações com o grupo, para não ficar só uma falação. E foi legal para descontrair.
Ah, como eu mencionei no post anterior, coloquei um slide para falar a respeito dos resultados da minha "pesquisa com os grupos" de ontem. Iniciei falando sobre o que é um projeto, quais são as suas características... e daí expus o motivo daquilo. Os problemas que estavam acontecendo lá e que eu consegui identificá-los de forma explícita.
A apresentação original estava prevista para ter 25 slides. Mas, comecei a perceber que ela poderia vir a ser uma referência para o pessoal, posteriormente, ao ser impressa em PDF. Portanto acabei deixando ela bem completa, com alguns exemplos para contextualizar situações.
No fim, acredito que todos ficaram satisfeitos. Notei, na prática, que alguns itens estavam fora de ordem (falava sobre previsto x realizado antes de falar de sprint, por exemplo). Mas, como eu disse, nada que fosse tão ruim a ponto de deixá-los perdidos.
Acredito que vendi o peixe! Ao final da apresentação, todos se mostravam dispostos a experiementar o SCRUM... a vivenciar a dinâmica que aplicaremos de 6a a 6a feira. Agora terei BASTANTE trabalho pois atuarei como coach, scrum master e product owner ao mesmo tempo! Mas vai valer a pena!
Espero que na outra sexta-feira eu esteja aqui escrevendo os resultados sensacionais que tivemos. Espero mesmo!
Para quem quiser fazer download, o link está aqui embaixo. A apresentação em PDF :)
DOWNLOAD DA APRESENTAÇÃO EM PDF
Ou entrem na seção de downloads e vão em "Material de apoio MPE" :)
Abração
PARTE V - a
quarta-feira, 16 de abril de 2008
Implantação do SCRUM no laboratório - Parte IV
Véspera do dia da apresentação!!! Os tambores batem (tum-tum-tum-tum!).
Hoje tirei o dia para fazer duas coisas:
MAPEAR A ORGANIZAÇÃO
E foi o que eu fiz. Chamei todos os membros e questionei eles o seguinte.
a) Projeto
b) Equipe
c) Responsáveis
d) Objetivos
e) Data início
f) Data fim
g) Envolvidos (pessoas que seriam afetadas pelo resultado do projeto - stakeholders)
Por fim, listei as atividades de cada um desde janeiro até hoje (menos de 3 meses de trabalho, contando que fevereiro não houve atividades).
A idéia central era que ELES respondessem essas perguntas. Eu queria saber o que passava na cabeça DELES sobre os projetos em que atuam.
Meus caros leitores, vocês não tem noção do que eu descobri.
São seis "projetos" que o pessoal está envolvido atualmente. Destes seis, três NÃO são projetos, pois são demandas que surgiram para "tapar" algum buraco ou apagar algum incêndio.
Destes seis "projetos", as pessoas envolvidas não sabiam a data de término em CINCO deles. E em DOIS eles não tinham certeza de quando havia sido iniciado.
Destes seis "projetos", cinco deles não tinham certeza em quem eram os envolvidos. Dois deles não tinham certeza dos responsáveis. Um deles não sabia ao certo a equipe que atuava com ele. E um deles não tinha um gerente de projetos definido.
Destes seis "projetos", em dois deles eles não tinham noção ao certo de quais eram os objetivos gerais do projeto (não sabiam ao certo o que tinham que entregar ou porque estavam fazendo aquilo). Quatro deles não citaram objetivos específicos, apenas o objetivo geral (criar um protótipo é um geral, por exemplo. Mas existem marcos até chegar lá...).
Por fim, destes seis "projetos", identifiquei que em pelo menos três deles haviam pessoas que já haviam atuado em pelo menos outros DOIS projetos nesses 3 meses. E três recursos já haviam atuado em até QUATRO projetos em três meses.
Um recurso levantou que "felizmente" algumas demandas externas haviam diminuido. Outro citou que trabalhou em atividades ligadas à organização e outras que não tinham qualquer relação! E duas pessoas citaram que ao encerrarem um dos projetos anteriores, reclamaram da ociosidade! Isso mesmo, eles tiveram uma ociosidade forçada!
O que dizer disso?! A falta de comunicação é total!! TOTAL! É um problema crítico que deve ser resolvido para ontem!
Caros leitores, desafio vocês a pegarem um dia e fazerem essa mesma entrevista nas equipes das suas empresas. Vocês vão se assustar!! Mas ao mesmo tempo, vão ter TODOS os argumentos para implantarem a mudança que quiserem.
======================================================
PREPARAR A APRESENTAÇÃO
Depois de ter me assustado com o mapeamento, sentei na cadeira e ajeitei a minha apresentação de SCRUM. A primeira versão tinha 25 slides e tratava do SCRUM de uma forma bem macro, abordando apenas alguns pontos chave. A versão final agora tem 45 slides.
"O que, 45 slides? O pessoal vai morrer de tédio!" você deve ter pensado :)
Não. A idéia principal é a de não expôr o SCRUM apenas. Mas sim mostrar algumas situações. Então usei uns 10 slides só com exemplos de taskboards (para mostrar como é fácil identificar o status do projeto - 1o dia, 2o dia, ultimo dia, falta de prioridades, atividades não-planejadas que matam o projeto) e outras com exemplos ilustrando impedimentos, o backlog, o burndown chart... enfim.
Essa não é a versão final, pois preciso ensaiar para ver se consigo finalizar em uma hora. Caso contrário terei que cortar uma ou outra coisa.
Mas realmente acredito que ficará uma apresentação bem abrangente e bem dinâmica, apesar de aparentemente parecer longa. O negócio é refinar ao máximo as frases, para não ficar aquela enormidade de texto.
E, sim, irei disponibilizá-la para vocês depois. Em PDF, claro ;) hehe
Um abração!
PARTE V
Hoje tirei o dia para fazer duas coisas:
MAPEAR A ORGANIZAÇÃO
E foi o que eu fiz. Chamei todos os membros e questionei eles o seguinte.
a) Projeto
b) Equipe
c) Responsáveis
d) Objetivos
e) Data início
f) Data fim
g) Envolvidos (pessoas que seriam afetadas pelo resultado do projeto - stakeholders)
Por fim, listei as atividades de cada um desde janeiro até hoje (menos de 3 meses de trabalho, contando que fevereiro não houve atividades).
A idéia central era que ELES respondessem essas perguntas. Eu queria saber o que passava na cabeça DELES sobre os projetos em que atuam.
Meus caros leitores, vocês não tem noção do que eu descobri.
São seis "projetos" que o pessoal está envolvido atualmente. Destes seis, três NÃO são projetos, pois são demandas que surgiram para "tapar" algum buraco ou apagar algum incêndio.
Destes seis "projetos", as pessoas envolvidas não sabiam a data de término em CINCO deles. E em DOIS eles não tinham certeza de quando havia sido iniciado.
Destes seis "projetos", cinco deles não tinham certeza em quem eram os envolvidos. Dois deles não tinham certeza dos responsáveis. Um deles não sabia ao certo a equipe que atuava com ele. E um deles não tinha um gerente de projetos definido.
Destes seis "projetos", em dois deles eles não tinham noção ao certo de quais eram os objetivos gerais do projeto (não sabiam ao certo o que tinham que entregar ou porque estavam fazendo aquilo). Quatro deles não citaram objetivos específicos, apenas o objetivo geral (criar um protótipo é um geral, por exemplo. Mas existem marcos até chegar lá...).
Por fim, destes seis "projetos", identifiquei que em pelo menos três deles haviam pessoas que já haviam atuado em pelo menos outros DOIS projetos nesses 3 meses. E três recursos já haviam atuado em até QUATRO projetos em três meses.
Um recurso levantou que "felizmente" algumas demandas externas haviam diminuido. Outro citou que trabalhou em atividades ligadas à organização e outras que não tinham qualquer relação! E duas pessoas citaram que ao encerrarem um dos projetos anteriores, reclamaram da ociosidade! Isso mesmo, eles tiveram uma ociosidade forçada!
O que dizer disso?! A falta de comunicação é total!! TOTAL! É um problema crítico que deve ser resolvido para ontem!
Caros leitores, desafio vocês a pegarem um dia e fazerem essa mesma entrevista nas equipes das suas empresas. Vocês vão se assustar!! Mas ao mesmo tempo, vão ter TODOS os argumentos para implantarem a mudança que quiserem.
======================================================
PREPARAR A APRESENTAÇÃO
Depois de ter me assustado com o mapeamento, sentei na cadeira e ajeitei a minha apresentação de SCRUM. A primeira versão tinha 25 slides e tratava do SCRUM de uma forma bem macro, abordando apenas alguns pontos chave. A versão final agora tem 45 slides.
"O que, 45 slides? O pessoal vai morrer de tédio!" você deve ter pensado :)
Não. A idéia principal é a de não expôr o SCRUM apenas. Mas sim mostrar algumas situações. Então usei uns 10 slides só com exemplos de taskboards (para mostrar como é fácil identificar o status do projeto - 1o dia, 2o dia, ultimo dia, falta de prioridades, atividades não-planejadas que matam o projeto) e outras com exemplos ilustrando impedimentos, o backlog, o burndown chart... enfim.
Essa não é a versão final, pois preciso ensaiar para ver se consigo finalizar em uma hora. Caso contrário terei que cortar uma ou outra coisa.
Mas realmente acredito que ficará uma apresentação bem abrangente e bem dinâmica, apesar de aparentemente parecer longa. O negócio é refinar ao máximo as frases, para não ficar aquela enormidade de texto.
E, sim, irei disponibilizá-la para vocês depois. Em PDF, claro ;) hehe
Um abração!
PARTE V
terça-feira, 15 de abril de 2008
Implantação do SCRUM no laboratório - Parte III - a
Bom, acabei fazendo do limão que me tocaram, uma limonada.
A dinâmica de 1h que estava prevendo para fazer durante o dia da apresentação, foi adaptada de uma forma mais eficiente e produtiva.
Eles terão a semana que vem inteira para escolher uma ou duas estórias dos projetos deles mesmo e irão trabalhar com o SCRUM em cima delas. Iremos fazer todo o ciclo em uma semana, e ao final eles estarão entregando alguma coisa produtiva realmente, ao invés de apenas um produto "fantástico" que eu iria criar para eles.
Vai ser bacana, eu acredito.
Só aquele meu cronograma para mapear tudo.... bom, foi pro lixo. Os incêndios do dia-a-dia prejudicaram bastante. Então o negócio é apenas fazer a apresentação e fazer o que eu tinha planejado (o mapeamento) na 6a feira mesmo.
-----
Hoje um dos guris levou outro puxão de orelha. Mas confesso que foi merecido. A pró-atividade dos funcionários é ZERO. Eles seguem estritamente o que passamos, sem questionar. O guri teve 3 semanas para fazer alguns testes. Eu esperava que ele tivesse bastante coisa, mas ele havia feito apenas CINCO testes!!! Enquanto ele ia apresentando, eu quase fui me escondendo na cadeira.
Um erro meu, de não estar mais junto a ele para cobrar e solucionar os problemas que ele teve, mas erro dele também pela pró-atividade e comprometimento em níveis bem abaixo do que o esperado.
PARTE IV
A dinâmica de 1h que estava prevendo para fazer durante o dia da apresentação, foi adaptada de uma forma mais eficiente e produtiva.
Eles terão a semana que vem inteira para escolher uma ou duas estórias dos projetos deles mesmo e irão trabalhar com o SCRUM em cima delas. Iremos fazer todo o ciclo em uma semana, e ao final eles estarão entregando alguma coisa produtiva realmente, ao invés de apenas um produto "fantástico" que eu iria criar para eles.
Vai ser bacana, eu acredito.
Só aquele meu cronograma para mapear tudo.... bom, foi pro lixo. Os incêndios do dia-a-dia prejudicaram bastante. Então o negócio é apenas fazer a apresentação e fazer o que eu tinha planejado (o mapeamento) na 6a feira mesmo.
-----
Hoje um dos guris levou outro puxão de orelha. Mas confesso que foi merecido. A pró-atividade dos funcionários é ZERO. Eles seguem estritamente o que passamos, sem questionar. O guri teve 3 semanas para fazer alguns testes. Eu esperava que ele tivesse bastante coisa, mas ele havia feito apenas CINCO testes!!! Enquanto ele ia apresentando, eu quase fui me escondendo na cadeira.
Um erro meu, de não estar mais junto a ele para cobrar e solucionar os problemas que ele teve, mas erro dele também pela pró-atividade e comprometimento em níveis bem abaixo do que o esperado.
PARTE IV
Implantação do SCRUM no laboratório - Parte III
Santo de casa não faz milagre, já dizia o ditado.
Mandei um email para os meus chefes, explicando da apresentação e da dinâmica. Já fizeram cara feia pelo fato de durar o dia todo. "Acho que poderia ser 1 hora de reunião apenas".
Ou seja, eles querem que eu apenas faça a apresentação, sem a dinâmica. Dai eu começo a me perguntar: alguém realmente vai aprender isso se não tiver contato nenhum com as ferramentas?
A dinâmica seria algo bem simples. Apenas algum problema para cada grupo resolver usando o SCRUM. Index cards, planning poker, reuniões, retrospectiva, taskboard... eles teriam pelo menos um contato com essas ferramentas.
Mas, já vou ter que adaptar isso para uma nova realidade.
O problema é que os males perduram. A visão de que "reunião é perda de tempo" é a pior delas. Quero só ver a cara dos coordenadores quando eu falar que teremos reuniões diárias, reuniões para avaliação, reuniões de estimativas, reuniões de retrospectivas...
Conseguir o comprometimento da direção. Esse é o maior desafio, sem dúvida alguma.
PARTE III-a
Mandei um email para os meus chefes, explicando da apresentação e da dinâmica. Já fizeram cara feia pelo fato de durar o dia todo. "Acho que poderia ser 1 hora de reunião apenas".
Ou seja, eles querem que eu apenas faça a apresentação, sem a dinâmica. Dai eu começo a me perguntar: alguém realmente vai aprender isso se não tiver contato nenhum com as ferramentas?
A dinâmica seria algo bem simples. Apenas algum problema para cada grupo resolver usando o SCRUM. Index cards, planning poker, reuniões, retrospectiva, taskboard... eles teriam pelo menos um contato com essas ferramentas.
Mas, já vou ter que adaptar isso para uma nova realidade.
O problema é que os males perduram. A visão de que "reunião é perda de tempo" é a pior delas. Quero só ver a cara dos coordenadores quando eu falar que teremos reuniões diárias, reuniões para avaliação, reuniões de estimativas, reuniões de retrospectivas...
Conseguir o comprometimento da direção. Esse é o maior desafio, sem dúvida alguma.
PARTE III-a
segunda-feira, 14 de abril de 2008
Implantação do SCRUM no laboratório - Parte II - a
Seguindo a minha agenda, conforme eu havia previsto, acabei não fazendo o que deveria. Por dois motivos:
Primeiro para resolver problemas de projetos que aconteceram durante o dia.
Segundo, pois precisava interar o outro gerente de todo o processo do SCRUM, ao menos para ele ter uma noção geral do que se trata. Aliás, essa reunião acabou durando o dia todo :)
----------
Me perguntaram se irei disponibilizar a apresentação. Posso disponibilizar, sem problemas. O problema é que está tudo bastante conceitual, então quem não conhece o SCRUM vai ter que se esforçar em dobro :)
Abraços
PARTE III
Primeiro para resolver problemas de projetos que aconteceram durante o dia.
Segundo, pois precisava interar o outro gerente de todo o processo do SCRUM, ao menos para ele ter uma noção geral do que se trata. Aliás, essa reunião acabou durando o dia todo :)
----------
Me perguntaram se irei disponibilizar a apresentação. Posso disponibilizar, sem problemas. O problema é que está tudo bastante conceitual, então quem não conhece o SCRUM vai ter que se esforçar em dobro :)
Abraços
PARTE III
Implantação do SCRUM no laboratório - Parte II
TO-DO LIST
Hoje fiz uma lista de "coisas para fazer" até o fim da semana, para garantir o sucesso da implantação. Aqui estão elas:
SEGUNDA-FEIRA
- Marcar reunião. Aqui é óbvio, né. Se ninguém souber da reunião, não haverá implantação :) Já sei os dias e horários em que a maioria pode.
- Mapear recursos, projetos e responsáveis. Esta tarefa tem o objetivo de identificar quais são os recursos reais do laboratório (sejam eles humanos ou físicos), identificar os projetos ativos (data de início e fim, objetivos) e responsáveis (stakeholders). Dessa forma já será possível, inclusive, identificar superalocação e subalocação de recursos.
- Mapear os canais de comunicação. Identificar o que está sendo usado para a comunicação nestes projetos, do tipo documentos, emails, avisos, quem responde pelo que, etc.
TERÇA-FEIRA
- Levantar infra-estrutura e solicitar o necessário. Aqui é simples: ver o que temos e solicitar o que não temos. E isso vale para o material SCRUM (flipchart, post-its, canetas, lápis, etc).
- Preparar material para a reunião. Ajustar os powerpoints da apresentação e da dinâmica sobre SCRUM :)
- Discutir as idéias a serem implantadas com os coordenadores. Isso é importantíssimo, né. Evitar que eu fale uma coisa na reunião e os coordenadores digam "Mas isso é impossível!". Já pensaram?
- Preparar o coach. Aqui é um ponto bem importante. No começo, terei que ser uma espécie de "Master Scrum Master" hehehe. Vou ter que atuar junto a todos os grupos para mostrar, no primeiro sprint, o que um Scrum Master precisa fazer. Nesse período, pretendo já definir quem será o Scrum Master da equipe (caso consiga) e treiná-lo para assumir a função. Tenho quase que certeza que eu acabarei sendo o Product Owner, pois os coordenadores possuem pouco tempo disponível para dispender.
QUARTA-FEIRA
- Revisar a apresentação e dinâmica. Repassar tudo o que foi escrito e pensado.
- Encomendar comes e bebes para a reunião. Isso é importante, garantir um coffee break ou confraternização ao final da reunião. Motiva o pessoal.
QUINTA-FEIRA
- Apresentação. Minha idéia inicial: começar às 14h30 e até as 15h45 fazer a apresentação. 15 minutos para um break. Das 16h as 17h a dinâmica. Depois, a confraternização. Muitos tem aula as 17h30, então é preciso garantir que tudo corra nos conformes.
SEXTA-FEIRA
- Adequação do ambiente. Aqui é apenas revisar com cada grupo de projeto se eles entenderam o que foi passado, esclarecer dúvidas mais pertinentes e pessoais e preparar tudo para que na semana seguinte (terça-feira, já que segunda é feriado) já possamos iniciar nosso SPRINT ZERO (para ambientá-los).
----
Este é o meu plano. Pode ser que mude alguma coisa até o fim da semana. Mas acredito que será pouca coisa.
O que acharam? Comentem ai :)
PARTE II - a
Abraços
Hoje fiz uma lista de "coisas para fazer" até o fim da semana, para garantir o sucesso da implantação. Aqui estão elas:
SEGUNDA-FEIRA
- Marcar reunião. Aqui é óbvio, né. Se ninguém souber da reunião, não haverá implantação :) Já sei os dias e horários em que a maioria pode.
- Mapear recursos, projetos e responsáveis. Esta tarefa tem o objetivo de identificar quais são os recursos reais do laboratório (sejam eles humanos ou físicos), identificar os projetos ativos (data de início e fim, objetivos) e responsáveis (stakeholders). Dessa forma já será possível, inclusive, identificar superalocação e subalocação de recursos.
- Mapear os canais de comunicação. Identificar o que está sendo usado para a comunicação nestes projetos, do tipo documentos, emails, avisos, quem responde pelo que, etc.
TERÇA-FEIRA
- Levantar infra-estrutura e solicitar o necessário. Aqui é simples: ver o que temos e solicitar o que não temos. E isso vale para o material SCRUM (flipchart, post-its, canetas, lápis, etc).
- Preparar material para a reunião. Ajustar os powerpoints da apresentação e da dinâmica sobre SCRUM :)
- Discutir as idéias a serem implantadas com os coordenadores. Isso é importantíssimo, né. Evitar que eu fale uma coisa na reunião e os coordenadores digam "Mas isso é impossível!". Já pensaram?
- Preparar o coach. Aqui é um ponto bem importante. No começo, terei que ser uma espécie de "Master Scrum Master" hehehe. Vou ter que atuar junto a todos os grupos para mostrar, no primeiro sprint, o que um Scrum Master precisa fazer. Nesse período, pretendo já definir quem será o Scrum Master da equipe (caso consiga) e treiná-lo para assumir a função. Tenho quase que certeza que eu acabarei sendo o Product Owner, pois os coordenadores possuem pouco tempo disponível para dispender.
QUARTA-FEIRA
- Revisar a apresentação e dinâmica. Repassar tudo o que foi escrito e pensado.
- Encomendar comes e bebes para a reunião. Isso é importante, garantir um coffee break ou confraternização ao final da reunião. Motiva o pessoal.
QUINTA-FEIRA
- Apresentação. Minha idéia inicial: começar às 14h30 e até as 15h45 fazer a apresentação. 15 minutos para um break. Das 16h as 17h a dinâmica. Depois, a confraternização. Muitos tem aula as 17h30, então é preciso garantir que tudo corra nos conformes.
SEXTA-FEIRA
- Adequação do ambiente. Aqui é apenas revisar com cada grupo de projeto se eles entenderam o que foi passado, esclarecer dúvidas mais pertinentes e pessoais e preparar tudo para que na semana seguinte (terça-feira, já que segunda é feriado) já possamos iniciar nosso SPRINT ZERO (para ambientá-los).
----
Este é o meu plano. Pode ser que mude alguma coisa até o fim da semana. Mas acredito que será pouca coisa.
O que acharam? Comentem ai :)
PARTE II - a
Abraços
sábado, 12 de abril de 2008
Implantação do SCRUM no laboratório - Parte I
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Assim como fiz na minha experiência, na empresa, vou fazer o mesmo para o laboratório: irei descrever como irei implantar a cultura do SCRUM no dia-a-dia das pessoas.
Muitas pessoas já me solicitaram para fazer isso, e acho que é uma ótima idéia e que irá inspirar muitos a fazerem o mesmo.
Só lembro que eu não sou o dono da verdade nem minha implantação está livre de erros. Irei adaptar apenas de acordo com a minha visão, no ambiente particular que trabalho e com meus objetivos específicos. Portanto, não sigam isso como "a verdade absoluta" ou "como fazer o mesmo na minha empresa". Usem como referência, não como manual :)
Irei marcar a reunião de apresentação na próxima quinta-feira, o que me dá (contando apenas os dias úteis) quatro dias para me preparar.
A minha idéia será de realizar uma apresentação do SCRUM. Mostrar a nossa situação atual (caótica) e apresentar a proposta do SCRUM. E deixar bem claro o que eu pretendo atingir: comunicação, comprometimento e produto.
Além disso, minha idéia é acrescentar o conceito do gerente-minuto. Como irei fazer isso?
O SCRUM será adotado para gerenciar e organizar o laboratório. Mas os processos falam muito em EQUIPES e pouco em INDIVÍDUOS. É exatamente isso que eu quero atacar com os conceitos do gerente-minuto, que são três (para relembrar): objetivos para cada indivíduo, feedback positivo e "disciplinador" (ainda não achei um termo melhor).
Após a apresentação teórica, quero realizar uma dinâmica mais abrangente do que aquela dos aviões. A idéia é fazê-los praticar pelo menos dois sprints como o SCRUM sugere, ou seja, estimar, priorizar, fazer e repensar. Tudo isso usando os modelos de artefatos que irei criar (index cards, planning poker, burndown chart, post-its, etc).
Após a apresentação, a implantação se seguirá aos poucos. Não quero mudar radicalmente o dia-a-dia deles, mas sim fazê-los vivenciar aos poucos os benefícios do SCRUM. Dessa forma, menos informação eles terão para absorver e, por consequencia, poderão digerir com mais facilidade. Até porque eles notarão rápido os benefícios dessas mudanças.
Enfim, terei quatro dias para criar todo o "background" (ambiente) para que tudo flua da forma correta. E prometo descrever isso aqui.
Então, espero que acompanhem :)
Abraços
PARTE II
Assim como fiz na minha experiência, na empresa, vou fazer o mesmo para o laboratório: irei descrever como irei implantar a cultura do SCRUM no dia-a-dia das pessoas.
Muitas pessoas já me solicitaram para fazer isso, e acho que é uma ótima idéia e que irá inspirar muitos a fazerem o mesmo.
Só lembro que eu não sou o dono da verdade nem minha implantação está livre de erros. Irei adaptar apenas de acordo com a minha visão, no ambiente particular que trabalho e com meus objetivos específicos. Portanto, não sigam isso como "a verdade absoluta" ou "como fazer o mesmo na minha empresa". Usem como referência, não como manual :)
Irei marcar a reunião de apresentação na próxima quinta-feira, o que me dá (contando apenas os dias úteis) quatro dias para me preparar.
A minha idéia será de realizar uma apresentação do SCRUM. Mostrar a nossa situação atual (caótica) e apresentar a proposta do SCRUM. E deixar bem claro o que eu pretendo atingir: comunicação, comprometimento e produto.
Além disso, minha idéia é acrescentar o conceito do gerente-minuto. Como irei fazer isso?
O SCRUM será adotado para gerenciar e organizar o laboratório. Mas os processos falam muito em EQUIPES e pouco em INDIVÍDUOS. É exatamente isso que eu quero atacar com os conceitos do gerente-minuto, que são três (para relembrar): objetivos para cada indivíduo, feedback positivo e "disciplinador" (ainda não achei um termo melhor).
Após a apresentação teórica, quero realizar uma dinâmica mais abrangente do que aquela dos aviões. A idéia é fazê-los praticar pelo menos dois sprints como o SCRUM sugere, ou seja, estimar, priorizar, fazer e repensar. Tudo isso usando os modelos de artefatos que irei criar (index cards, planning poker, burndown chart, post-its, etc).
Após a apresentação, a implantação se seguirá aos poucos. Não quero mudar radicalmente o dia-a-dia deles, mas sim fazê-los vivenciar aos poucos os benefícios do SCRUM. Dessa forma, menos informação eles terão para absorver e, por consequencia, poderão digerir com mais facilidade. Até porque eles notarão rápido os benefícios dessas mudanças.
Enfim, terei quatro dias para criar todo o "background" (ambiente) para que tudo flua da forma correta. E prometo descrever isso aqui.
Então, espero que acompanhem :)
Abraços
PARTE II
sexta-feira, 11 de abril de 2008
Semana de decisão!!
Hoje aconteceu uma coisa chata. Um dos meus chefes veio cobrar resultado de dois funcionários, pois o projeto em que eles estão é de extrema importância para os nossos outros. Ele é quase que a principal dependência.
O chefe falou que desde quarta-feira vê os guris na mesma, sem avançar. E quer saber o motivo. E pior: quer que segunda-feira as 14h eles na reunião mostrem o que fizeram e se não fizeram, apresentem os problemas técnicos que enfrentaram.
O problema disso?
Esses dois guris são dedicados. Eles trabalham bastante e sempre estão envolvidos em projetos complexos. 99% dos projetos que eles participaram, não deram em nada. Eles já tem este problema e agora ainda vão sofrer pressão por outro projeto difícil?
Infelizmente a imagem do laboratório fez com que eles entrassem na "fatia ruim" do bolo. Uma pena.
Mas isso mostrou uma coisa: temos uma GRANDE falta de comunicação lá. Não sabemos o que fazemos ao certo, onde cada recurso está alocado, quais os objetivos de cada, etc. etc.
Tudo falta de quê? COMUNICAÇÃO.
E foi por isso que decidi que na próxima quinta-feira irei aplicar o SCRUM em todo o laboratório. Meu primeiro ataque será de definir objetivos para TODOS, metas para TODOS e facilitar a comunicação de TODOS.
Vou começar aos poucos, mas a COMUNICAÇÃO vai ser o primeiro passo de tudo.
Até mais e me desejem boa sorte!
O chefe falou que desde quarta-feira vê os guris na mesma, sem avançar. E quer saber o motivo. E pior: quer que segunda-feira as 14h eles na reunião mostrem o que fizeram e se não fizeram, apresentem os problemas técnicos que enfrentaram.
O problema disso?
Esses dois guris são dedicados. Eles trabalham bastante e sempre estão envolvidos em projetos complexos. 99% dos projetos que eles participaram, não deram em nada. Eles já tem este problema e agora ainda vão sofrer pressão por outro projeto difícil?
Infelizmente a imagem do laboratório fez com que eles entrassem na "fatia ruim" do bolo. Uma pena.
Mas isso mostrou uma coisa: temos uma GRANDE falta de comunicação lá. Não sabemos o que fazemos ao certo, onde cada recurso está alocado, quais os objetivos de cada, etc. etc.
Tudo falta de quê? COMUNICAÇÃO.
E foi por isso que decidi que na próxima quinta-feira irei aplicar o SCRUM em todo o laboratório. Meu primeiro ataque será de definir objetivos para TODOS, metas para TODOS e facilitar a comunicação de TODOS.
Vou começar aos poucos, mas a COMUNICAÇÃO vai ser o primeiro passo de tudo.
Até mais e me desejem boa sorte!
quinta-feira, 10 de abril de 2008
Inteligência emocional... de novo
Não adianta. Estou cada vez mais me dando conta que é preciso cuidar MUITO da nossa saúde (física e mental) se quisermos ser bons gerentes.
Hoje eu tive uma noite do cão. Acordei diversas vezes durante e dai acordei de manhã caindo de sono. Não consegui mais dormir. Graças a isso, passei o dia todo sonolento, pedindo para que o dia acabasse logo para chegar em casa.
Quando estou assim e vou pro trabalho, acabo fugindo ao máximo de reuniões e de contatos com os funcionários (para discutir coisas técnicas, principalmente). É difícil de se concentrar e assim, é difícil de planejar direito. Daí acabo fazendo algumas tarefas ordinárias, como arrumar algum documento ou powerpoint... isolado na minha baia.
Em compensação existem dias em que estou ultra-motivado. Felizmente geralmente estou assim, pois gosto muito do que faço. Senão acharia que eu era bipolar :)
Preciso arrumar minha agenda para praticar esportes, principalmente. É algo que eu sempre gostei e que é ótimo para descarregar. Aliás, estou realmente muito desorganizado... fazendo as coisas meio que "sob demanda". Mas isso é outra história!
PS: Desculpem pela música que ficou um pouco alta, no podcast (como alguns mencionaram). Realmente foi um erro meu, devido ao programa "free" que usei para editá-lo.
PS2: Recebi poucos feedbacks... gostaria de saber mais sobre os visitantes do blog! Vamos lá, pessoal. Mandem nem que seja um "Alouu!" :)
Abração
Hoje eu tive uma noite do cão. Acordei diversas vezes durante e dai acordei de manhã caindo de sono. Não consegui mais dormir. Graças a isso, passei o dia todo sonolento, pedindo para que o dia acabasse logo para chegar em casa.
Quando estou assim e vou pro trabalho, acabo fugindo ao máximo de reuniões e de contatos com os funcionários (para discutir coisas técnicas, principalmente). É difícil de se concentrar e assim, é difícil de planejar direito. Daí acabo fazendo algumas tarefas ordinárias, como arrumar algum documento ou powerpoint... isolado na minha baia.
Em compensação existem dias em que estou ultra-motivado. Felizmente geralmente estou assim, pois gosto muito do que faço. Senão acharia que eu era bipolar :)
Preciso arrumar minha agenda para praticar esportes, principalmente. É algo que eu sempre gostei e que é ótimo para descarregar. Aliás, estou realmente muito desorganizado... fazendo as coisas meio que "sob demanda". Mas isso é outra história!
PS: Desculpem pela música que ficou um pouco alta, no podcast (como alguns mencionaram). Realmente foi um erro meu, devido ao programa "free" que usei para editá-lo.
PS2: Recebi poucos feedbacks... gostaria de saber mais sobre os visitantes do blog! Vamos lá, pessoal. Mandem nem que seja um "Alouu!" :)
Abração
quarta-feira, 9 de abril de 2008
Calvin & Haroldo e a síndrome do estudante
Essa sequência de tirinhas do Calvin (a tirinha que eu acho mais sensacional de todos os tempos) mostra de forma prática a famosa teoria da "Sindrome do Estudante", que é comum em qualquer projeto. Quem nunca sofreu isso com seus subordinados e seu cronograma? Trata-se da idéia de deixar tudo para a última hora, ou seja, realizar a tarefa apenas quando ela se tornar urgentíssima.
A sequência é hilária. Quem não conhece o Calvin e Haroldo, vale explicar que trata-se de uma criança de 8 anos extremamente imaginativa (o Haroldo, seu tigre, é um tigre de pelúcia que é o melhor amigo dele). Leiam a histórinha e se divirtam!
A sequência é hilária. Quem não conhece o Calvin e Haroldo, vale explicar que trata-se de uma criança de 8 anos extremamente imaginativa (o Haroldo, seu tigre, é um tigre de pelúcia que é o melhor amigo dele). Leiam a histórinha e se divirtam!
segunda-feira, 7 de abril de 2008
Podcast #2 - Feedback, com Claudia Peruzzato
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Prezados leitores e ouvintes!
Finalmente consegui editar o podcast e disponibilizá-lo (com um dia de atraso, queria ter feito isso ontem). O resultado pode ser conferido agora.
A entrevistada desta edição é a consultora Cláudia Peruzzato, especialista na área de gestão empresarial, principalmente em atendimento ao cliente, comunicação interna e marketing pessoal. O site da empresa é www.peruzzatoconsultores.com.br.
Aproveite para aprender mais sobre feedback, como implantá-lo, como utilizar o seu melhor (e o seu pior), dicas, etc.
Acessem pelo site:
Download do podcast #2 no 4shared
E, quem não escutou a edição #1, pode fazer download por aqui.
E deixem SEUS feedbacks :)
Abração
Prezados leitores e ouvintes!
Finalmente consegui editar o podcast e disponibilizá-lo (com um dia de atraso, queria ter feito isso ontem). O resultado pode ser conferido agora.
A entrevistada desta edição é a consultora Cláudia Peruzzato, especialista na área de gestão empresarial, principalmente em atendimento ao cliente, comunicação interna e marketing pessoal. O site da empresa é www.peruzzatoconsultores.com.br.
Aproveite para aprender mais sobre feedback, como implantá-lo, como utilizar o seu melhor (e o seu pior), dicas, etc.
Acessem pelo site:
Download do podcast #2 no 4shared
E, quem não escutou a edição #1, pode fazer download por aqui.
E deixem SEUS feedbacks :)
Abração
Enquete e o dia-a-dia
Confesso que quando publiquei a enquete deste mês de abril (sobre o que você acha que precisa melhorar) eu me admirei como eu mesmo nunca havia me perguntado isso.
Nessa mesma reunião de sexta-feira (citada abaixo) percebi como o analista lidava com sua equipe: "Cara, tu podes ver isso hoje (17h30) para que na segunda a gente possa trabalhar com mais calma?" ele falou a um dos bolsistas. A resposta foi positiva, é claro.
Eu me perguntei por que não consigo falar o mesmo. Notei que tenho problemas de comunicação (essa foi a opção que eu escolhi na enquete) e até o momento outras pessoas também o tem.
É difícil de exigir de uma equipe, falar olho no olho, se a gente tem um histórico de timidez e inibição. Estou disposto (já comentei isso no blog em outras vezes) a buscar formas de melhorar isso, de me sentir mais a vontade para falar.
O engraçado é que eu me sinto mais a vontade para falar com meus chefes do que com meus funcionários. Não sei se a falta de comprometimento deles acabou me fazendo perder a confiança e inibiu essa cobrança mais ainda(aquela coisa do "ah, não adianta falar").
O fato é: eu vivo e viverei sempre de comunicação. Preciso ser mais instintivo de vez em quando, falar e não pensar 3x antes. Pensar 3x já demonstra insegurança... e isso eu notaria se alguém fizesse comigo.
O meu foco para este ano é: melhorar a comunicação. E pretendo fazer o possível para isso. E você? Comente aí suas idéias baseado no que você votou na enquete! :)
Nessa mesma reunião de sexta-feira (citada abaixo) percebi como o analista lidava com sua equipe: "Cara, tu podes ver isso hoje (17h30) para que na segunda a gente possa trabalhar com mais calma?" ele falou a um dos bolsistas. A resposta foi positiva, é claro.
Eu me perguntei por que não consigo falar o mesmo. Notei que tenho problemas de comunicação (essa foi a opção que eu escolhi na enquete) e até o momento outras pessoas também o tem.
É difícil de exigir de uma equipe, falar olho no olho, se a gente tem um histórico de timidez e inibição. Estou disposto (já comentei isso no blog em outras vezes) a buscar formas de melhorar isso, de me sentir mais a vontade para falar.
O engraçado é que eu me sinto mais a vontade para falar com meus chefes do que com meus funcionários. Não sei se a falta de comprometimento deles acabou me fazendo perder a confiança e inibiu essa cobrança mais ainda(aquela coisa do "ah, não adianta falar").
O fato é: eu vivo e viverei sempre de comunicação. Preciso ser mais instintivo de vez em quando, falar e não pensar 3x antes. Pensar 3x já demonstra insegurança... e isso eu notaria se alguém fizesse comigo.
O meu foco para este ano é: melhorar a comunicação. E pretendo fazer o possível para isso. E você? Comente aí suas idéias baseado no que você votou na enquete! :)
A diferença de trabalhar com pessoas comprometidas
Sexta-feira passada, durante uma reunião com membros do laboratório que eram de outro projeto, senti a diferença de trabalhar com pessoas comprometidas.
Para o projeto de Maio, eu terei como braço direito o ex-gerente deste outro projeto antigo. Ele será o analista senior do projeto e tenho certeza que me auxiliará bastante.
O que eu achei engraçado é que no meu projeto antigo (que ainda está em vigência) a minha equipe eu tinha que praticamente assumir diversas responsabilidades que não seriam da minha área. Acabei meio que me acostumando com isso.
Na reunião de sexta, com esses outros membros, achei engraçado sair da reunião sem ter que falar muito (só dando minha visão de algumas situações que eu concordava ou não) e ver que o analista assumiu o papel quase de gerente operacional.
Confesso que sai com um misto de alívio e de desconforto... aliviado por saber que estou ao lado de gente comprometida e capaz e desconfortado por me sentir "inutil", já que eu pouco participei hehehe
Do outro lado, dois dos bolsistas que já eram meus subordinados e que constantemente estavam desmotivados, na sexta vieram conversar comigo sobre as descobertas que eles tem feito na antena que precisam estudar. Já se dispuseram a me ajudar a rever alguns cronogramas e afins. Motivação 101%, visivelmente.
Se eu conseguir manter esse espírito em 70% do tempo no laboratório, teríamos um resultado tão bom no final de cada projeto.......
Para o projeto de Maio, eu terei como braço direito o ex-gerente deste outro projeto antigo. Ele será o analista senior do projeto e tenho certeza que me auxiliará bastante.
O que eu achei engraçado é que no meu projeto antigo (que ainda está em vigência) a minha equipe eu tinha que praticamente assumir diversas responsabilidades que não seriam da minha área. Acabei meio que me acostumando com isso.
Na reunião de sexta, com esses outros membros, achei engraçado sair da reunião sem ter que falar muito (só dando minha visão de algumas situações que eu concordava ou não) e ver que o analista assumiu o papel quase de gerente operacional.
Confesso que sai com um misto de alívio e de desconforto... aliviado por saber que estou ao lado de gente comprometida e capaz e desconfortado por me sentir "inutil", já que eu pouco participei hehehe
Do outro lado, dois dos bolsistas que já eram meus subordinados e que constantemente estavam desmotivados, na sexta vieram conversar comigo sobre as descobertas que eles tem feito na antena que precisam estudar. Já se dispuseram a me ajudar a rever alguns cronogramas e afins. Motivação 101%, visivelmente.
Se eu conseguir manter esse espírito em 70% do tempo no laboratório, teríamos um resultado tão bom no final de cada projeto.......
sexta-feira, 4 de abril de 2008
O que não fazer com sua micro empresa.
Desculpem a demora para novos posts. Estava com problemas particulares e profissionais (muito trabalho hehe). O podcast 2 sai nesse findi!
-----------------------
Ontem durante uma reunião com um dos coordenadores, recebemos uma missão: tentar salvar um projeto junto a uma entidade parceira. O motivo? O projeto foi entregue em uma versão completamente incipiente, cheia de bugs e sem sequer uma interface com o usuário.
O resultado disso foi que já perdemos um projeto graças a isso.
Eu comecei a pensar então em como isso deve acontecer com micro e pequenas empresas. Na ânsia de ter um ROI o mais cedo possível, acabam se envolvendo em projetos que não possuem a capacidade para cumprir! E ainda por cima, sem uma equipe preparada para desenvolvê-lo.
Quando vamos a um cliente mostrar um DEMO de algum produto, temos que ter em mente que o cliente quer ver O QUE o sistema faz e não COMO o sistema faz. Sendo assim, imaginem o impacto que foi ao apresentar o produto que não tinha sequer uma interface com o usuário? Nem uma listagem de atividade simples, nem um campo de prenchimento... nem um aviso sequer. Nada!
O coordenador contou também que recentemente esteve em São Paulo para fazer uma demonstração. A idéia era mostrar o produto na versão WEB para uma platéia de 30 pessoas. Ele faria a conexão direto na empresa onde um estagiário iria interagir com ele, ao vivo. Essa interação resultaria em resultados que seriam apresentados na tela web.
Dez minutos antes da apresentação iniciar, o coordenador tentou testar o sistema. Problema: a conexão não foi possível de ser estabelecida. Correria na empresa, e eles então conseguiram ao menos conectar... a uma velocidade baixíssima.
Resultado? A apresentação foi improvisada com algumas screenshots do sistema. E portanto, o coordenador estava mostrando COMO o produto era feito e não O QUE fazia. Não soube o que os presentes comentaram, mas aposto que não devem ter ficado satisfeitos.
Quantas empresas vivem uma situação parecida? Infra-estrutura ruim, equipe inexperiente, ansiedade por um ROI rápido... e se envolvendo em projetos que não tem como dar conta?
Eu confesso que fiquei realmente muito abismado com o que escutei ontem. Nossa missão é em uma semana tentar lançar uma release do sistema (demo) para tentar salvar esse projeto. Conseguiremos, sem dúvida. Só acho que o estrago já terá sido feito.
Ficam as lições aprendidas: nunca prometer o que não se pode cumprir; mostrar valor ao (futuro) cliente; ter uma equipe com pelo menos alguém confiável para dar conta do recado... enfim.
Pés no chão para começar com um passo atrás do outro. O resultado pode demorar, mas será muito mais produtivo do que tentar correr atrás do pote de ouro.
Abraços!
-----------------------
Ontem durante uma reunião com um dos coordenadores, recebemos uma missão: tentar salvar um projeto junto a uma entidade parceira. O motivo? O projeto foi entregue em uma versão completamente incipiente, cheia de bugs e sem sequer uma interface com o usuário.
O resultado disso foi que já perdemos um projeto graças a isso.
Eu comecei a pensar então em como isso deve acontecer com micro e pequenas empresas. Na ânsia de ter um ROI o mais cedo possível, acabam se envolvendo em projetos que não possuem a capacidade para cumprir! E ainda por cima, sem uma equipe preparada para desenvolvê-lo.
Quando vamos a um cliente mostrar um DEMO de algum produto, temos que ter em mente que o cliente quer ver O QUE o sistema faz e não COMO o sistema faz. Sendo assim, imaginem o impacto que foi ao apresentar o produto que não tinha sequer uma interface com o usuário? Nem uma listagem de atividade simples, nem um campo de prenchimento... nem um aviso sequer. Nada!
O coordenador contou também que recentemente esteve em São Paulo para fazer uma demonstração. A idéia era mostrar o produto na versão WEB para uma platéia de 30 pessoas. Ele faria a conexão direto na empresa onde um estagiário iria interagir com ele, ao vivo. Essa interação resultaria em resultados que seriam apresentados na tela web.
Dez minutos antes da apresentação iniciar, o coordenador tentou testar o sistema. Problema: a conexão não foi possível de ser estabelecida. Correria na empresa, e eles então conseguiram ao menos conectar... a uma velocidade baixíssima.
Resultado? A apresentação foi improvisada com algumas screenshots do sistema. E portanto, o coordenador estava mostrando COMO o produto era feito e não O QUE fazia. Não soube o que os presentes comentaram, mas aposto que não devem ter ficado satisfeitos.
Quantas empresas vivem uma situação parecida? Infra-estrutura ruim, equipe inexperiente, ansiedade por um ROI rápido... e se envolvendo em projetos que não tem como dar conta?
Eu confesso que fiquei realmente muito abismado com o que escutei ontem. Nossa missão é em uma semana tentar lançar uma release do sistema (demo) para tentar salvar esse projeto. Conseguiremos, sem dúvida. Só acho que o estrago já terá sido feito.
Ficam as lições aprendidas: nunca prometer o que não se pode cumprir; mostrar valor ao (futuro) cliente; ter uma equipe com pelo menos alguém confiável para dar conta do recado... enfim.
Pés no chão para começar com um passo atrás do outro. O resultado pode demorar, mas será muito mais produtivo do que tentar correr atrás do pote de ouro.
Abraços!
Assinar:
Postagens (Atom)
Postagens
