Só para avisá-los: a nova edição do podcast será publicada em breve. Não desisti da idéia ;)
Abraços
segunda-feira, 19 de novembro de 2007
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
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
terça-feira, 13 de novembro de 2007
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
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
segunda-feira, 12 de novembro de 2007
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.
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.
sexta-feira, 9 de novembro de 2007
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
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
quarta-feira, 7 de novembro de 2007
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.
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.
terça-feira, 6 de novembro de 2007
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!
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!
Assinar:
Postagens (Atom)
Postagens
