Livro de referência para SCRUM

Este é o livro.

[Henrik Kniberg] Scrum and XP from the Trenches.pdf

Podem imprimir à vontade: ele é "open source" ;)

Ele tem uma sugestão para o painel de atividades que eu gostei muito! É o que eu pretendo usar como "template". O que acham?

Tem tudo bem visível e organizado. Realmente simpatizei com essa sugestão :)

Abraços

SCRUM para projetos impossíveis

Hoje começou um novo dia-a-dia no meu trabalho. Implantamos de vez os conceitos de SCRUM para resgatar o projeto. Basicamente, vamos tentar finalizar em UM MÊS o que não fizemos em SEIS MESES. Foi uma reunião de 4h30, mas foi MUITO produtiva e todos que estiveram nela sairam satisfeitos.

Tratei de comprar alguns salgadinhos e água, para já dar uma animada no pessoal. E fizemos uma pausa durante a reunião, para descansarmos também. Aliás, minha idéia era que a reunião continuasse no dia seguinte, mas a equipe quis finalizar tudo hoje. Gostei disso!

Reuni toda a equipe do projeto e o nosso chefe-cliente-especialista, que agora se tornou o "Product Owner". Primeiramente, discutimos a situação atual, de que teríamos UM MÊS (ou seja, dois sprints) para finalizar o melhor que pudermos do projeto. Portanto, o foco era ter alguma coisa, dentro da nossa realidade.

Planejei para que pudessemos hoje levantar todas as funcionalidades que já pensamos para o sistema. Esse seria nosso "Product Backlog". Para facilitar a visualização disso, utilizei um conceito que li em um livro (veja o post acima deste) em que o autor apresenta o que chama de "Index cards". Ele é mais ou menos como o que eu fiz abaixo:

É composto por 6 campos para serem preenchidos. Se você quiser, pode baixar o arquivo em PPT (dois index cards por folha A4) neste link aqui. Os campos são preenchidos da seguinte forma:

Backlog item: Nome da funcionalidade. Ou, no nosso caso, alguns requisitos não-funcionais importantes (que posteriormente podem virar funcionalidades);

Prioridade: Eu estimei com base no livro. De 1 a 150, baixa para alta prioridade. Por que este intervalo? Pois simplesmente definir "alto", "médio", "baixo" pode levar a ter muitas funcionalidades de nível "médio". E daí perder mais tempo decidindo qual é a mais prioritária das "médias". Com este intervalo, conseguimos facilmente identificar.

User stories: o conceito de User Stories é bastante interessante. Aprendi no curso que fiz de SCRUM e achei bem interessante pelo fato de nos fazer pensar de fato em como um ator do sistema teria valor com essa funcionalidade. Basta usar COMO UM QUERO PARA . Então, por exemplo: "como um correntista quero sacar dinheiro do caixa automático para colocar na minha carteira e gastar". Pode ser algo bem neste nível mesmo. Outra coisa boa, é a possibilidade de otimizarmos e identificarmos requisitos "escondidos".

Estimativa: A estimativa é medida em "tamanho da funcionalidade". Usamos a série Fibonacci para mensurá-la: 1, 2, 3, 5, 8, 13, 21, mais do que isso é inviável. Usei o planning poker para estimar. O livro que me baseei usa cartas outros valores como 1/2, "?" e até um "café" para indicar que a pessoa está cansada. Mas preferi ficar só na série mesmo.

Como funcionará: Uma breve descrição do que a funcionalidade fará. Algo bem alto nível: usuário faz isso, depois isso, o sistema verifica isso e retorna isso. Pense em um "diagrama de atividades" BEM resumido. Essa é a idéia.

Notas sobre o item: Espaço para colocar observações. Eu usei bastante quando estávamos debatendo sobre a funcionalidade. Por exemplo, num item que coletava dados do sistema, o pessoal estava discutindo se o sistema teria memória interna para todos os dados... e se a velocidade do veículo influenciaria. Anotei isso ali. Facilitou na hora de fazermos nosso "WBS".

Inicialmente, com essas index cards, cada um que fosse lembrando de alguma funcionalidade preenchia tudo (menos a estimativa). Conseguimos em torno de 12 index cards. Não discutimos prioridades ainda.


Então passamos para a estimativa. Primeiro pegamos a funcionalidade daquelas que seria a mais fácil de ser implementada. E marcamos "2" para ela, por default. O livro que eu usei cita para que se marque "3" e outros falam em "1". Acho que "2" é um bom número, assim temos ainda algo que possa ser MAIS fácil ainda, se decidirmos depois.


Com isso, tínhamos uma base para nos basearmos para as próximas estimativas. E começou o planning poker. A cada rodada, se havia uma discrepância grande (sempre acontece algo como alguém colocar 2 e outro colocar 13) os extremos discutiam porque escolheram aquilo. Algumas funcionalidades nós discutimos antes de estimá-la, o que foi o correto. Assim identificamos outras variáveis envolvidas em cada uma... o que pesou nas estimativas. Por exemplo, uma interface gráfica que inicialmente foi estimada em 5, após a discussão passou para 13 por diversos fatores que não dependiam da gente.


Feitas as estimativas, agora discutimos as prioridades. Pudemos ver que haviam "baixas prioridades" importantes e que haviam "altas prioridades" irrelevantes. Isso foi corrigido e aprovado pelo Product Owner.


Aliás, o Product Owner entendeu tanto a complexidade que, pela primeira vez em UM ANO de projeto, ele aceitou que tivéssemos um protótipo ao invés de um produto. Inclusive sugeriu uma solução que nem nós poderíamos sugerir melhor: ao invés de usar um hardware que seria montado, vamos usar um notebook! Isso nos resolveu MUITOS problemas, e fez todo o time quase se abraçar e chorar de emoção!! (ok, essa parte eu exagerei...)


Agora tínhamos o seguinte cenário:


- Itens do backlog (funcionalidades), a maioria com algumas observações relevantes
- Prioridades
- Estimativas iniciais


Faltava criar o escopo de atividades, ou tasks... ou WBS. Colocamos na parede pendurados, lado a lado, usando o seguinte critério:


<----- mais importante ------------menos importante ------>


As folhas ficaram lado a lado para serem quebradas em tasks (como fizemos uma pausa para descansar, notem como as observações foram importantíssimas para nos lembrarmos depois).

Definimos o que seriam tasks. Falei que o ideal, para o gráfico do sprint burndown, era que as tasks fossem atividades pequenas. No nosso caso, que trabalhamos meio-turno, ficaria difícil de fazer uma atividade de meio-turno. Aliás, é preciso lembrar que existem horas produtivas e não-produtivas. Usualmente se usa a idéia de que 25% do tempo de trabalho é usado com bobagens. Então, no nosso caso, temos apenas 3 horas produtivas.


Definimos então que nossas tasks teriam DOIS dias (ou seja, 6 horas). Essa seria nossa medida padrão para todas as tasks que fossemos criando, mesmo que fossem menores do que isso. Eu pretendia depois refinar isso com eles, mas pra falar a verdade, como sei que tarefas não-planejadas irão surgir com o tempo, essa "gordura" será queimada. Então vou manter tudo como 2 dias, para o sprint burndown.


Fizemos toda a quebra, começando pelas menos prioritárias (e menos granularizadas no momento). Quando chegamos na tarefa prioritária, levantamos atividades não só relativas a aquela funcionalidade, como também atividades relativas ao projeto, tais como reavaliar todos nossos códigos, identar, documentar, etc.


Falando em documentar, definimos que teremos DOIS documentos apenas. O de hardware (um dos mais importantes do projeto) que será desenvolvido mais pro final e o de software que será desenvolvido dentro do próprio código usando softwares como o Oxygen, que gera a documentação com base nos comentários do código. Assim evitamos de ter duas fontes para atualizar.


Ainda não decidimos se TODOS da equipe se focarão nas atividades exclusivas daquela funcionalidade, ou se um do time pode começar outra atividade paralela. Eu acredito que o ideal seja todos se focarem numa funcionalidade, assim todos vivenciam o máximo de "teamwork".

Ufa! Finalizamos tudo isso em aproximadamente 4h30. Tivemos nossa experiência com uma primeira "Scrum meeting estratégica" de fato. E aprendemos conforme foi acontecendo. Eu, por exemplo, por diversas vezes me vi não como um "scrum master", mas sim como um "gerente de projetos tradicional": influenciei em alguns resultados e idéias. Em pelo menos duas vezes eu consegui me tocar disso e ainda comentei: "desculpem, estou me metendo e isso é com vocês".

Enfim, posso dizer que foi muito legal. Pudemos ter tudo isso de forma mais tangível e visual. Assim conseguimos tomar diversas decisões.


O comentário, ao final da reunião, foi único entre a equipe: se tivéssemos aplicado isso alguns meses antes, hoje estaríamos apenas mexendo em funcionalidades não prioritárias. Realmente, é difícil de não concordar vivenciando uma metodologia ágil em um ambiente de caos e incertezas.

E você? Já fez seu SCRUM? :)

Abraços

Quarta-feira é dia de "meeting" !!

Pois é, aplicando o processo de SCRUM, nessa quarta-feira iremos levantar todas as funcionalidades do sistema e priorizá-las. Será nosso primeiro backlog.

Teremos... dois sprints para cumprí-lo. Um mês (duas semanas por sprint).

Quero só ver..........

Nota interessante...

Vocês já perceberam que o que o SCRUM sugere para o "Scrum Master" é mais ou menos o que o livro "O Monge e o Executivo" sugere? O fato do SM ser um líder servidor.

Mais do que nunca, se você pretende aplicar SCRUM, leia este livro. E pesquise bastante sobre "clima organizacional", "motivação" e "relações humanas". O foco é bastante nisso!

Ta aí porque me apaixonei pelo SCRUM desde o primeiro dia hehehe

A dura realidade...

É triste chegar ansioso para o trabalho, louco para começar apresentar para a equipe as novidades do curso de SCRUM... e notar que estou de volta à realidade.

Essa segunda-feira era o dia que os membros das equipes tinham mais provas, então de 7 pessoas, só 2 estavam no local. Além disso, eu fiquei hoje fora do laboratório preparando a dinâmica que pretendo aplicar na sexta-feira (calma, ela será BEM detalhada aqui posteriormente ;).

E mesmo assim era possível escutar as conversas e risadas vindas do laboratório. O ambiente de trabalho está em clima de festa demais. Como se não houvessem prazos a serem cumpridos. Infelizmente eu não tenho poder sobre este ambiente, já que boa parte da "festa" é feita pelos outros membros de outras equipes.

Eu tenho certeza que quando eu aplicar o SCRUM "in fact" na minha equipe, o resultado será bem legal. Mas não posso esconder a decepção que é voltar cheio de idéias e levar o choque da realidade...

SCRUM... formalizado.

Foi amor à primeira vista. O SCRUM definitivamente fecha completamente com a minha visão de gerência de projetos:

+ Integração da equipe
+ Responsabilidade e compromisso
+ Motivação
+ Ciclos iterativos
+ E, principalmente, SIMPLICIDADE

Hoje no curso não chegamos a entrar ainda bem na parte técnica, mas pelas discussões eu pude ver que adaptei a metodologia ágil do SCRUM, na minha empresa, de uma forma que não seria a mais correta. Não estávamos focados em "funcionalidades". Isso causava um problema: as reuniões diárias eram apenas um "hoje eu fiz isso, amanhã faço aquilo e tenho (ou não) impedimento". Mas não havia uma integração da equipe nesse momento, da forma como o SCRUM prega.

Enfim... estou ansioso para amanhã. E para chegar segunda-feira!

Abraços!

ÊÊÊÊÊÊÊ!! Consegui um curso de SCRUM!!!!!

E não é que Deus olhou pra mim esta semana? Só pode!

Estava eu pensando essa semana como achar tempo para pesquisar mais sobre o SCRUM (que foi a base da metodologia que eu implantei no trabalho e o principal motivo da realização deste blog) quando um antigo colega meu da faculdade me liga.

"Flávio, aqui na empresa vamos fazer um curso de SCRUM, mas precisamos de mais uma pessoa. Tu tens interesse, agora que tu é gerente de projetos?"

Quase enfartei! Caiu literalmente do céu essa oportunidade. Eu estava prevendo para ter o meu curso de oratória e dicção neste final de semana, mas expliquei para a fonoaudióloga e combinamos que deixaríamos para mais adiante.

Então é isso. Nesta sexta e sábado passarei o dia imerso no curso de SCRUM da Teamware. Tenho até pena dos meus colegas na empresa... voltarei cheio de idéias!! Muhahaha (risada sarcástica)

Abraços!

Ambiente de trabalho

Quem acompanha meu blog sabe o quanto eu estou procurando sempre melhorar todas as variáveis possíveis do clima organizacional da empresa onde trabalho, pois sou da tese de que funcionário feliz produz mais. O problema é até que ponto temos que ir para que esse ambiente saudável não se torne uma baderna.

O laboratório onde estamos trabalhando (junto com outros dois grupos de pesquisa) é terrível. Primeiro a infra-estrutura: bons computadores, boas cadeiras... mas um ambiente totalmente aberto, com um do lado do outro, sem NENHUMA divisória. Além disso, um dos grupos (cuja a pesquisa encerra neste mês de dezembro) está sem um gerente, e consequentemente, sem tarefas e obrigações. Acrescentem ainda a péssima escolha do perfil dos bolsistas (muitos deles não apenas não tem a capacidade necessária, como são extremamente dispersivos e inconvenientes). Mais ainda a falta de uma presença maior dos demais gerentes e também responsáveis (coordenadores) dos projetos. Mais ainda a falta de cobrança pelos resultados. E por fim, como a cereja da torta, a imagem de que pesquisa na universidade é diferente de uma pesquisa em uma empresa. Ah, e ainda estamos em época de provas finais...

Hoje passei um dia de trabalho inteiro (que na verdade significa uma tarde) no laboratório, do início ao fim. É um ambiente INSUPORTÁVEL para trabalho. Até mesmo aqueles meus subordinados que eu considerava muito bons, se tornaram dispersos hoje.

Eu confesso que me senti impotente diante daquele cenário. Hoje, há de se dizer, foi um dia em que quase todos estavam em prova e/ou trabalhos da faculdade. Então 90% do tempo eles dedicaram a isto. E MESMO ASSIM eles passaram a maioria do tempo falando sobre outros assuntos.

Eu olho então para o nosso projeto, que está se encerrando, e começo a ver o porque nós não temos praticamente NADA pronto. O meu otimismo deu lugar ao realismo, há algum tempo. E agora estou virando pessimista. Teremos que fazer o trabalho de 4-5 meses em duas semanas (em dois turnos, isso já foi combinado).

O pior é que em todas nossas reuniões em que levantamos as coisas "ruins" do nosso dia-a-dia, o ambiente de trabalho é sempre citado como sendo um problema. Mas eu começo a ver que os guris também fazem parte deste ambiente, e não são apenas "contaminados" por ele.

E pensar que quando estávamos na empresa, o resultado estava MUITO bom.

A questão é: fazemos uma mudança radical no laboratório ou algo gradual, a longo prazo? A minha opinião é que deveria ser radical. Tem gente ali dentro que está merecendo ser posta no lugar. Mas essa mudança não deve ser só em atitude. Deve ser também na infra-estrutura. E aí que mora o problema... não depende só de nós.

Enfim, o ambiente de trabalho é uma das questões mais importantes para se ter produtividade. Saber dosar um ambiente saudável com um ambiente formal, é a grande equação que um administrador deve resolver.

Abraços!

A importância de ter métricas...

Cada dia eu vejo o quanto é importante ter uma métrica para acompanhar o projeto. Seja a EVA (técnica do valor agregado), seja o Sprint Burndown (do SCRUM), ou qualquer outra métrica que mostre o andamento do projeto.

Eu sinto muita falta disto. Principalmente para a equipe sentir como anda a produtividade.

Minha idéia é aplicar o Sprint Burndown, pois me pareceu o mais simples e honesto com a realidade (embora o EVA seja muito bom também).

Vamos ver se consigo!

Abraços

Cinco revistas interessantes para um gerente de projetos ler (ou folhear)

Já que eu sugeri livros, porque também não sugiro algumas revistas?

Eis cinco que eu costumo dar uma olhada:

Mundo PM (http://www.mundopm.com.br/default.jsp)
Esta revista eu assino e recomendo. Traz artigos publicados por pessoas da nossa área. É EXCELENTE e eu acredito que é daquelas que todo gerente deve ler.

Você S/A (http://vocesa.abril.com.br)
A Você S/A eu comecei a ler recentemente e gostei. Embora balanceie bastante matérias para subordinados e para chefes, sempre traz dicas e matérias bem interessantes. Assinei também!

Info Corporate (http://info.abril.com.br/corporate)
Esta é bem específica para quem trabalha com TI, como é o meu caso. Comprei uma usada, em um saldão, e gostei tanto que assinei também (eita!). É focada para quem deseja se formar CIO, pelo que pude ver.

Istoé Dinheiro (http://www.terra.com.br/istoedinheiro)
Traz algumas reportagens interessantes, além de cases. Muitos reclamam que a Dinheiro e a Exame tem muitas matérias pagas, mas mesmo assim sempre agregam alguma coisa para quem quer aprender.

Exame (http://portalexame.abril.com.br)
Não leio muito a Exame, mas é inegável que é uma boa indicação também.

Resenha do livro "O monge e o executivo" de James C. Hunter

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

Este foi um dos primeiros livros sobre liderança que eu li. Ganhei ele quando me formei, em dezembro de 2006. Até então, a maioria dos livros sobre gerenciamento de projetos que eu tinha eram mais técnicos, apenas para consulta.

Após ler "O monge e o executivo", comecei a pegar gosto por ler este tipo de livro. Ele conta uma história de um executivo de uma empresa que, no limite do stress, é inscrito pela mulher em um programa para reflexão em um monastério. Lá, o monge que recebe o executivo (e os outros personagens) é um ex-presidente de uma multinacional, mega bem-sucedido mas que decide largar tudo para viver como monge.

O livro traz alguns conceitos muito bacanas sobre como de fato liderar. O fato de ser uma estória, contribui para o aprendizado. Os personagens secundários, que participam do "seminário", representam vários setores de mercado ou onde a liderança é aplicada. Existe uma professora, um militar, um pastor evangélico, uma treinadora de esportes... Eles são responsáveis pelas discussões acerca dos preceitos que o monge Simeão (o monge do título) apresenta.

O conceito principal é a "liderança servidora", ou seja, o lider deve garantir que seus subordinados estejam sempre bem servidos para que o resultado final seja excelente para todos: chefe, empregado e empresa. Obviamente os debates acalorados entre o monge e o militar (em uma passagem ele afirma: "Devo pedir 'por favor, tropa, atravessem o campo minado?') são excelentes e servem como contrapontos entre a teoria.

Eu considero a idéia do livro muito boa para ser aplicado a quem tem subordinados. Não é novidade que melhorar o clima organizacional motiva e melhora a produtividade. Porém, a forma como isso tudo é abordado no livro é de fato muito interessante e proveitosa. Mesmo quem não gosta de ler, vai gostar do livro. Eu garanto! Talvez seja por isso que está sempre entre os mais vendidos... possuindo até uma versão em áudio.

BOM PARA: quem procura alguma idéia para motivar e melhorar o clima organizacional da sua empresa, não importando o tamanho. É ótimo para ler por ser simples e direto.

RUIM PARA: quem não gosta de ler sober liderança.

RECOMENDADO PARA: Gerentes e executivos, juniores ou seniors. Ou então para quem tem subordinados. Aliás, é recomendado para todos que trabalham em alguma empresa!

AVALIAÇÃO FINAL: 5/5.

Confira esta resenha no meu novo blog:

http://www.agileway.com.br/2008/09/30/resenha-do-livro-o-monge-e-o-executivo-james-hunter/

Podcast...

Só para avisá-los: a nova edição do podcast será publicada em breve. Não desisti da idéia ;)

Abraços

Preparando a próxima confraternização do grupo

Dia 30/11 teremos nova confraternização na empresa. Dessa vez, pretendo organizar uma ou duas dinâmicas de grupo para integrar e "ensinar" o pessoal. Acho que será bem bacana, tomara que funcione como eu estou esperando.

A grande idéia é colocá-los em situações comuns no gerenciamento de projetos, para que possamos discutir ações/problemas/reações/sentimentos que cada situação gera. Gostei de três que eu encontrei, que focam bem nesse quesito de projetos:

Numa, temos duas ou mais equipes com 5 pessoas, sendo uma o líder. Essa pessoa deve organizar as outras 4 pessoas de forma a produzir um produto qualquer. Só que este líder não saberá que cada uma das outras quatro pessoas terão papéis bem definidos: um será o produtivo, outro será o preguiçoso, outro será o presunçoso (aquele que critica tudo e não faz nada) e o outro será o gozador (aquele que só faz piada mas não produz). Quem nunca viveu situações assim?

Outra diz respeito a organizar duas equipes e definir que cada uma delas recebeu um apartamento e deve mobiliá-lo da melhor forma possível. Lá pelas tantas, chegamos e falamos: "pessoal, por motivos obscursos, agora teremos UM apartamento só". Então, as duas equipes devem negociar para chegar em um acordo comum.

Por fim, um bem legal. A equipe é contratada para desenvolver um produto (no caso um carro) para um caso bem específico (definir tudo: cenário, características do motorista, público, etc). E depois uma ou duas pessoas avaliam e definem quem venceu. É uma boa dinâmica para adaptar e torná-la mais interessante, como por exemplo: tentar definir necessidades que devem ser buscadas pelas equipes. É legal para trabalhar bem a questão "escopo x qualidade".

Enfim, minha idéia é aplicar dinâmicas que de fato sejam descontraídas mas também ensinem a todos nós.

E vocês, já aplicaram algo similar em suas equipes? Comentem! Estou sentindo falta de comentários!

Abraços

Documentação

Eu já havia comentado anteriormente, mas volto a bater neste ponto. A necessidade da empresa em reter o seu bem mais valioso: a informação.

No mundo de TI, principalmente, a rotatividade do RH costuma ser grande. Muitos trabalham por projetos (como PJ) e, como consequencia disso, acabam permanecendo na empresa por 2 ou 3 anos, em média.

E se a empresa não reter toda informação gerada neste período? Podemos dizer que ou a empresa gosta de ter produtos "caixa-preta" (onde não se sabe ao certo como funciona tudo, pois os responsáveis foram embora), ou a empresa fica refém de seus funcionários (se eles forem embora, a informação vai junto).

Notem a importância de se ter uma documentação sobre tudo o que está sendo gerado. É importante, não acham?

Temos então um cenário que podemos chamar de "gestão da informação". E este cenário, no universo de TI, não é dos mais favoráveis. Abaixo, listo alguns problemas relativos a isto:

1) Como documentar? Um dos principais problemas em TI é a falta de uma padronização para a documentação. Existem modelos, mas falta capacidade para adaptar isto para a realidade da empresa. Pegue um documento de visão do RUP (Rational Unified Process) e use ele completo em um projeto pequeno de sua microempresa. Não dá! Você está fazendo um "gold plating" na sua documentação, preenchendo informações que não seriam relevantes.

2) Qual a granularidade do documento? Outro grande problema é a visão que cada um tem da documentação. Um desenvolvedor tem o cacoete de abstrair muita informação. Geralmente a justificativa é "mas isso é óbvio!". É um erro grande, pois ele está assumindo que quem irá ler o documento está a par de tudo. Por outro lado, um especialista irá encher de detalhes o documento. O meu chefe certa vez falou "escreva como se fosse um manual para sua mãe ler e montar todo o sistema". Também eu considero um erro, pois apesar da máxima de que "quanto mais informação, melhor", alguns níveis de detalhes não são relevantes.

3) Como documentar um sistema? A palavra sistema geralmente está atrelada a software. Mas a bem da verdade é que sistema indica o TODO que envolve o projeto. Um sistema pode ser um leitor de código de barras que envia os dados para o servidor, armazena no banco de dados e depois fornece informações através de um (aí sim) sistema de informação. Então temos um problema bem grande aí: como documentar um sistema desses? Fazer um documento geral? Dividir em hardware, software? Dividir por áreas como requisitos, arquitetura, desenvolvimento, testes?

4) Como documentar com os recursos umanos? Calma, o erro de português é proposital :) Um dos grandes problemas de TI é de fato encontrar pessoas técnicas que tenham uma boa redação. Ao menos uma redação razoável. No meu projeto, felizmente toda equipe tem uma redação razoável, daqueles que a gente lê o documento e, apesar de alguns pequenos erros e omissões de dados, entendemos o sentido e podemos delegar sem problemas. Em um outro projeto, o gerente amigo meu está enlouquecido com o que está lendo nos documentos. Ontem mesmo ele me mostrou uma frase escrita por uma das pessoas. Eu não consegui acreditar que um universitário havia escrito aquilo. Não tinha pé nem cabeça, começo nem fim. Em TI, se você sabe escrever, vale a pena colocar isso em seu currículo.

5) Como fazer a manutenção da documentação? Sabemos que documentar é uma das coisas mais detestáveis por qualquer pessoa ligada a TI (salvo exceções, como eu! hehe). Então geralmente a tarefa de documentação é feita OU antes OU depois do desenvolvimento. Por quê? Pois ninguém vai ter saco de atualizar esta documentação. Então se foi feito antes, eles vão atualizar só o que foi crítico (mudança de classes de projeto, por exemplo). Se foi depois, aquela será a versão "final" do documento, aconteça o que acontecer. No fundo, sabemos que isso é errado. A documentação tem que estar sempre atualizada, para garantir a informação correta. Bem como ela deve estar sempre bem armazenada, de fácil localização.

Volto a ressaltar que o gerente de projetos deve estar bem atento a essa questão. De nada vai adiantar o projeto gerar um super-mega-produto, sem que depois não se saiba como este produto foi feito. A informação é o bem mais precioso da empresa. Cabe a nós sermos responsáveis por isto.

E isso que eu nem falei sobre a gestão da informação gerada nos projetos...... mas acho que isso todos nós sabemos né? :)

Abraços

Resenha do livro "Construindo uma vida" de Roberto Justus

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

Comprei este livro esperando aprender um pouco com a carreira vencedora do "Donald Trump brasileiro" Roberto Justus.

O livro é bem fácil de ler, pois é bem informal na escrita. Conta um pouco da história da família dele, como ele começou a trabalhar na publicidade, as conquistas, decepções e um pouco sobre o "Aprendiz" (duas edições).

Eu achei uma leitura válida. É contando fatos e casos do dia-a-dia, que o Justus acaba passando algumas dicas para lidar com situações comuns de todo gerente ou tomador de decisão: como lidar com conflitos, clima organizacional, empreender, liderar, etc.

Para aqueles mais curiosos, ele também fala um pouco sobre sua vida pessoal... sobre sua relação com a Galisteu e a Eliana, entre outras.

Enfim, eu recomendo o livro para quem quer agregar alguma experiência vivida pelo Justus. Por ser de fácil leitura, é um bom livro para se ler despretenciosamente (assim como o do Max).

BOM PARA: ler a qualquer hora e aprender algumas dicas que podem ser aplicadas no seu dia-a-dia, mesmo não sendo da área da publicidade.

RUIM PARA: quem espera um livro "how to" ou "receita de bolo". As dicas estão nas entrelinhas. Através da leitura você acabará aprendendo.

RECOMENDADO PARA: Quem gosta de ler biografias de grandes empresários e para aqueles que procuram algo para ler sem precisar se concentrar muito.

AVALIAÇÃO FINAL: 3,5/5.

A empresa que queria abraçar o mundo....

Na nossa reunião de outubro, com toda a empresa, eu fiz questão de enfatizar aos nossos diretores, todos os projetos e áreas onde estamos atuando. Temos mais de 15 projetos (dentre os realizados, parados e em andamento) e atacamos áreas que vão de vendas até a área espacial.

Essa semana eu comecei a pensar para qual lado eu devo seguir. Qual projeto priorizar. E então me dei conta que os diretores, que haviam dito que iriam se reunir para definir prioridades, ainda não me passaram a resposta.

Como eu já havia dito, os dois diretores são professores-pesquisadores-doutores da universidade. Então, a área de P&D é ótima para eles... mas o fato é que em uma empresa a orientação é outra: sai a pesquisa e entra o produto!

Qual projeto eu priorizo? Essa resposta eu realmente não sei responder. O projeto "carro-chefe" da empresa é da área de agronegócio (agricultura de precisão). Uma área em que nós não temos a menor chance de competir.

E vocês, caros leitores, já passaram por essa crise de identidade nas suas empresas? Comentem!

Abração

Resenha do livro "Pergunte ao Max", de Max Gehringer

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

Vou começar a colocar minha resenha sobre alguns livros que ando lendo sobre gestão e gerenciamento de projetos.

O primeiro livro dos que eu comprei é o "Pergunte ao Max", da editora Globo.

Basicamente é um livro para se ler a qualquer hora do dia. Não possui história nem estória. É apenas uma coletânea de perguntas e respostas que o Max Gehringer respondeu durante o seu programa "Mundo Corporativo" na rádio CBN.

As perguntas estão divididas em capítulos que são os temas: chefiar, empreender, motivar, sonhar, etc. As respostas são sempre ótimas e servem muito para refletirmos sobre o que fazemos no nosso dia-a-dia. É bom para quem gosta do estilo do Max.

BOM PARA: ler a qualquer hora, sem se preocupar com histórias ou narrações.

RUIM PARA: quem já tem experiência e deseja se aprofundar nos assuntos. Tudo é respondido de forma bem superficial.

RECOMENDADO PARA: Novos gerentes e para aqueles que buscam um livro para ler despreocupadamente.

AVALIAÇÃO FINAL: 3,5/5.

O velho problema de escopo, de novo!

Segunda-feira... dia de reunião com a equipe do projeto relacionado ao agronegócio.

A idéia era apresentar para nosso diretor-cliente-especialista-pesquisador (neste projeto, este é o papel dele) como iremos desenvolver o software neste curto espaço de tempo que temos.

Mas ele voltou a mudar o escopo, dizendo que é importantíssimo que tenhamos um display de LCD para dar um diferencial ao produto. Realmente, observando de uma forma comercial, é muito mais vendável um projeto com este recurso.

Agora, isso demanda tempo. E nós não temos isso. Ele argumentou que irá alocar uma pessoa de fora do projeto para fazer isso (nosso eterno "Severino" pagou o pato) e que isso é relativamente simples de fazer.

O grande problema de ter um chefe que é DOUTOR na tecnologia é que ele acaba afetado pela visão de que tudo é "relativamente simples". Se ELE for desenvolver isso, de fato ele pode cumprir facilmente o prazo. Mas acontece que a tecnologia é alienígena para quem vai desenvolver... ele vai ter que aprender e só então fazer o módulo. E ainda tem que ter a INTEGRAÇÃO deste módulo com o da equipe.

Ou seja... se a coisa já estava feia, agora realmente entrou num poço sem fundo. Sinceramente, não vejo a hora deste projeto acabar hehehe

LIÇÃO APRENDIDA: Tomem MUUUUITO cuidado se a parte interessada (cliente, no caso) tem bons conhecimentos na tecnologia envolvida. A questão CRONOGRAMA e ESCOPO podem sofrer bastante!

Back from holiday

Bah, feriadão é dose!

Difícil voltar ao rítmo frenético da semana anterior hehehe

Vamos ver como vai ser essa semana :)