Eita, hoje eu vi como estou enferrujado!
Resolvi pegar o meu projeto atual e transformar todas as funcionalidades em user stories. Quando comecei a explicar para os meus dois colaboradores, eu comecei a ver como eu estava bem enferrujado devido a mais de três meses sem praticar.
O resultado foi a discussão de detalhes excessivos em alguns casos! Detalhes técnicos!!!! E no início do projeto!!!!
Quando me dei por conta, já havíamos perdido boa parte da reunião e então continuei apenas tentando listar e quebrar as funcionalidades em estórias. Deixei o detalhamento de lado. Ainda bem!
Não adianta, as técnicas de agile acabam sendo como tênis: se não praticar, a gente acaba ATÉ jogando... mas bem meia-boca! :)
Anyway, hoje recebi a notícia de que nosso projeto de pesquisa teve a parte financeira aprovada!! Ou seja, poderei começar a pensar na equipe definitiva! Aleluia!
Ah sim, essa semana vou começar a planejar a adaptação do Zoho Projects para SCRUM. Vai ser uma coisa bem adaptada, mas vai dar certo, pelo menos na teoria!
Abraços!
terça-feira, 9 de setembro de 2008
segunda-feira, 8 de setembro de 2008
Situações... você se identifica com alguma?
Situação 1
A sua diretoria acerta um projeto com um cliente e então o aloca para "gerenciar" o projeto. Você acaba trabalhando com uma equipe que não é a mais indicada para o projeto e o resultado é uma sucessão de bugs no sistema. O cliente começa a ficar descontente. Porém, ao invés de resolver as pendengas com quem acertou diretamente com ele (a diretoria), o cliente desconta no gerente! Liga a toda hora para reclamar, esbravejar, etc. O gerente acaba recebendo a culpa por um projeto já fadado à morte.
Situação 2
A diretoria então "aprendeu" com esse "erro" acima. Agora, isola o gerente do cliente. Qualquer dúvida técnica é para perguntar diretamente para os diretores. Eles entrarão em contato com o cliente (assim que puderem) e questionarão a dúvida repassada. Se for necessário um outro esclarecimento, todo o processo é refeito. Esse processo, aliás, que poderia ser resolvido em menos de uma hora, acaba levando uma tarde, um dia, uma semana... mas tudo para proteger o gerente.
Situação 3
A diretoria deixa um assunto estourar no prazo. Então passa a bola para os gerentes. "Vocês podem pegar o equipamento no cliente, já que eles não estão mais usando, até amanhã de manhã no máximo? Vamos precisar para apresentar outro projeto". Ok. Vamos até o cliente - cujo projeto em que envolvia os equipamentos foi fracassado - e tentamos retirar o equipamento. Os responsáveis dizem que não foi avisado nada de retirada e que sem ter o aval do diretor deles, não podem fazer nada. Os gerentes ficam de mão atadas, novamente.
Situação 4
A diretoria deixa outro projeto estourar no prazo. Então aloca um gerente e uma equipe para um projeto, de uma hora para a outra. Passam as informações do projeto em uma hora de reunião e esperam o projeto pronto em, no máximo, UMA SEMANA. Qualquer tentativa de analisar mais a fundo o projeto é vista como desnecessária. "Vocês já tem as informações que precisam". A equipe enlouquece e dois abandonam o barco por não concordar com a situação. O gerente acaba sendo desenvolvedor, analista, DBA, testador e, se sobrar um tempinho, até gerente!
Situação 5
A diretoria reconhece que os processos e projetos estão mal-conduzidos e que muito é por culpa deles. Eles afirmam que isso não pode mais acontecer e cobram-se, uns dos outros. Entendem que os gerentes estão fazendo o possível para resolver os problemas dos projetos. Se comprometem em mudar a situação, principalmente quando a coisa começa a doer no pior lugar de todos (no bolso). Infelizmente, essa situação 5 acaba acontencendo normalmente ANTES das situações 1, 2, 3 e 4. Ou seja, a aclamada mudança não ocorre.
Conclusão
Se você, caro leitor, já vivenciou situações parecidas deve saber que muitas vezes nossos superiores acabam se esforçando para complicar mais do que apoiar. A pergunta mais difícil a ser respondida (talvez tanto quanto "De onde viemos e para onde vamos?") é:
Como mudar essa mentalidade e cultura?
Recomendaria ao PMI a inclusão de mais uma área de conhecimento. LIDANDO COM OS CHEFES.
A sua diretoria acerta um projeto com um cliente e então o aloca para "gerenciar" o projeto. Você acaba trabalhando com uma equipe que não é a mais indicada para o projeto e o resultado é uma sucessão de bugs no sistema. O cliente começa a ficar descontente. Porém, ao invés de resolver as pendengas com quem acertou diretamente com ele (a diretoria), o cliente desconta no gerente! Liga a toda hora para reclamar, esbravejar, etc. O gerente acaba recebendo a culpa por um projeto já fadado à morte.
Situação 2
A diretoria então "aprendeu" com esse "erro" acima. Agora, isola o gerente do cliente. Qualquer dúvida técnica é para perguntar diretamente para os diretores. Eles entrarão em contato com o cliente (assim que puderem) e questionarão a dúvida repassada. Se for necessário um outro esclarecimento, todo o processo é refeito. Esse processo, aliás, que poderia ser resolvido em menos de uma hora, acaba levando uma tarde, um dia, uma semana... mas tudo para proteger o gerente.
Situação 3
A diretoria deixa um assunto estourar no prazo. Então passa a bola para os gerentes. "Vocês podem pegar o equipamento no cliente, já que eles não estão mais usando, até amanhã de manhã no máximo? Vamos precisar para apresentar outro projeto". Ok. Vamos até o cliente - cujo projeto em que envolvia os equipamentos foi fracassado - e tentamos retirar o equipamento. Os responsáveis dizem que não foi avisado nada de retirada e que sem ter o aval do diretor deles, não podem fazer nada. Os gerentes ficam de mão atadas, novamente.
Situação 4
A diretoria deixa outro projeto estourar no prazo. Então aloca um gerente e uma equipe para um projeto, de uma hora para a outra. Passam as informações do projeto em uma hora de reunião e esperam o projeto pronto em, no máximo, UMA SEMANA. Qualquer tentativa de analisar mais a fundo o projeto é vista como desnecessária. "Vocês já tem as informações que precisam". A equipe enlouquece e dois abandonam o barco por não concordar com a situação. O gerente acaba sendo desenvolvedor, analista, DBA, testador e, se sobrar um tempinho, até gerente!
Situação 5
A diretoria reconhece que os processos e projetos estão mal-conduzidos e que muito é por culpa deles. Eles afirmam que isso não pode mais acontecer e cobram-se, uns dos outros. Entendem que os gerentes estão fazendo o possível para resolver os problemas dos projetos. Se comprometem em mudar a situação, principalmente quando a coisa começa a doer no pior lugar de todos (no bolso). Infelizmente, essa situação 5 acaba acontencendo normalmente ANTES das situações 1, 2, 3 e 4. Ou seja, a aclamada mudança não ocorre.
Conclusão
Se você, caro leitor, já vivenciou situações parecidas deve saber que muitas vezes nossos superiores acabam se esforçando para complicar mais do que apoiar. A pergunta mais difícil a ser respondida (talvez tanto quanto "De onde viemos e para onde vamos?") é:
Como mudar essa mentalidade e cultura?
Recomendaria ao PMI a inclusão de mais uma área de conhecimento. LIDANDO COM OS CHEFES.
Marcadores:
comunicação,
conflitos,
Dia-a-dia,
humor,
lições aprendidas,
mudanças,
reuniões,
sugestões
sexta-feira, 5 de setembro de 2008
Protótipo e o cliente
Uma das coisas mais discutidas no mundo da TI é a utilização ou não de protótipos para apresentar ao cliente. Eu particularmente sou contra. O motivo é simples: clientes, em TI, tem expectativas altas! Se a gente apresenta algo que não condiz com a realidade, podemos ter situações como as que eu cito abaixo:
Situação 1
Desenvolvedor: Queremos mostrar para vocês o que estamos pensando sobre o sistema para vocês. Aqui a gente tem a tela de cadastros... mas ela não está funcionando...
Cliente: Como assim???
Desenvolvedor: É que nós achamos que não seria interessante implementar agora.
Cliente: Hmmmmmmmmm...
Situação 2
Desenvolvedor: Teste o sistema de navegação do site, por favor.
Cliente: Claro! Poxa, tá bem bonito. Vou clicar aqui e... ué. Nada aconteceu!
Desenvolvedor: Ah sim, é que... bem, isso é um esqueleto do sistema, só para avaliação da interface.
Cliente: Hmmmmmmmmmmmmmmmmmmm...
Quem nunca passou por isso? É normal! E mesmo assim a gente continua trabalhando com protótipos. Hoje, por exemplo, fomos demonstrar o nosso protótipo para o cliente. E tivemos SUCESSO! Eles gostaram bastante do que viram. E era um protótipo.
Dai vão dizer: "Ahh o Flávio tá se contradizendo!". Que nada! Os clientes aprovaram o sistema, mas se tivessemos demonstrado já algo funcional e que gerasse valor a eles, o resultado não seria um "OHHH!" de boca aberta e emocionado?? Com certeza sim. Quando a gente trabalha com protótipos, normalmente estamos nas fases iniciais do projeto. Onde a relação com o cliente ainda não está bem firme. É importante conseguir encantá-lo logo cedo para conquistá-lo. E dessa forma se tivermos futuros problemas tudo poderá ser bem mais facilmente administrado.
Además, o meu projeto não é um projeto ainda. Foi uma "batata quente" que eu recebi para descascar e dar um jeito. Fiz o que eu pude, no curto prazo. E graças às pessoas competentes que estão desenvolvendo ("Hurra!") tivemos algo bem bacana.
O grande e principal problema de um protótipo como o nosso? Todo ele foi "fake". Isto é, iremos aproveitar bem pouco dele. Foi feito numa realidade onde precisávamos cumprir um prazo para apresentar algo pro cliente, e não houve tempo de modelar todo o sistema final. Então fizemos "módulos" para apresentar como cada um funcionaria. Quase sem nenhuma integração entre um e outro.
Ufa! Apesar de tudo valeu. Mas eu já cobrei do cliente, para a próxima reunião, a priorização das funcionalidades por ordem de valor e importância. Assim começaremos a trabalhar de fato no que realmente vale a pena!
E assim acaba mais uma semana.
Um grande abraço e ótimo final de semana pra vocês. Descansem! :)
Situação 1
Desenvolvedor: Queremos mostrar para vocês o que estamos pensando sobre o sistema para vocês. Aqui a gente tem a tela de cadastros... mas ela não está funcionando...
Cliente: Como assim???
Desenvolvedor: É que nós achamos que não seria interessante implementar agora.
Cliente: Hmmmmmmmmm...
Situação 2
Desenvolvedor: Teste o sistema de navegação do site, por favor.
Cliente: Claro! Poxa, tá bem bonito. Vou clicar aqui e... ué. Nada aconteceu!
Desenvolvedor: Ah sim, é que... bem, isso é um esqueleto do sistema, só para avaliação da interface.
Cliente: Hmmmmmmmmmmmmmmmmmmm...
Quem nunca passou por isso? É normal! E mesmo assim a gente continua trabalhando com protótipos. Hoje, por exemplo, fomos demonstrar o nosso protótipo para o cliente. E tivemos SUCESSO! Eles gostaram bastante do que viram. E era um protótipo.
Dai vão dizer: "Ahh o Flávio tá se contradizendo!". Que nada! Os clientes aprovaram o sistema, mas se tivessemos demonstrado já algo funcional e que gerasse valor a eles, o resultado não seria um "OHHH!" de boca aberta e emocionado?? Com certeza sim. Quando a gente trabalha com protótipos, normalmente estamos nas fases iniciais do projeto. Onde a relação com o cliente ainda não está bem firme. É importante conseguir encantá-lo logo cedo para conquistá-lo. E dessa forma se tivermos futuros problemas tudo poderá ser bem mais facilmente administrado.
Además, o meu projeto não é um projeto ainda. Foi uma "batata quente" que eu recebi para descascar e dar um jeito. Fiz o que eu pude, no curto prazo. E graças às pessoas competentes que estão desenvolvendo ("Hurra!") tivemos algo bem bacana.
O grande e principal problema de um protótipo como o nosso? Todo ele foi "fake". Isto é, iremos aproveitar bem pouco dele. Foi feito numa realidade onde precisávamos cumprir um prazo para apresentar algo pro cliente, e não houve tempo de modelar todo o sistema final. Então fizemos "módulos" para apresentar como cada um funcionaria. Quase sem nenhuma integração entre um e outro.
Ufa! Apesar de tudo valeu. Mas eu já cobrei do cliente, para a próxima reunião, a priorização das funcionalidades por ordem de valor e importância. Assim começaremos a trabalhar de fato no que realmente vale a pena!
E assim acaba mais uma semana.
Um grande abraço e ótimo final de semana pra vocês. Descansem! :)
quarta-feira, 3 de setembro de 2008
Revista Época Especial - As 100 melhores empresas para se trabalhar
Se você procura algo legal para ler, sugiro a edição especial da Época, que traz as 100 melhores empresas para se trabalhar.
Uma excelente forma de conhecer as culturas e práticas destas empresas. A revista traz algumas matérias e destaca as melhores práticas de cada uma delas.
Vale a leitura!
Uma excelente forma de conhecer as culturas e práticas destas empresas. A revista traz algumas matérias e destaca as melhores práticas de cada uma delas.
Vale a leitura!
Contrastes
Hoje eu vivi dois contrastes ao mesmo tempo.
Enquanto o meu projeto está nos trilhos, com meus dois colaboradores trabalhando com as tecnologias que conhecem e gostam, o meu colega está em apuros.
Ele está fazendo a implantação de um sistema em um cliente de forma "sob demanda", isto é, eles desenvolvem, vão lá, implantam, coletam os bugs, voltam, desenvolvem, implantam... e assim vai.
Só que ele está com dois colaboradores que não tem a menor vontade de trabalhar em rítmo de empresa. Eles querem trabalhar com pesquisa. Então o comprometimento é quase inexistente.
Dai eu pergunto: de quem é a culpa?
Eu me atrevo a dizer que na atual situação, não é de ninguém... mas é de todos. Não é de ninguém pois atualmente o grupo está dependendo do projeto que irá ser aprovado em breve. Esse "em breve" já dura alguns meses, mas a esperança é a última que morre.
É de todos pois foram alocados para o projeto duas pessoas que não queriam trabalhar neste projeto. E também porque toda negociação com o cliente foi horrível... esse processo que está sendo feito para desenvolvimento é muito ruim! É o legítimo "queima-empresa".
Um grupo de pesquisas que tenta trabalhar como empresa vai sofrer sempre com essa crise de identidade, e porque não dizer, de competências.
Enquanto o meu projeto está nos trilhos, com meus dois colaboradores trabalhando com as tecnologias que conhecem e gostam, o meu colega está em apuros.
Ele está fazendo a implantação de um sistema em um cliente de forma "sob demanda", isto é, eles desenvolvem, vão lá, implantam, coletam os bugs, voltam, desenvolvem, implantam... e assim vai.
Só que ele está com dois colaboradores que não tem a menor vontade de trabalhar em rítmo de empresa. Eles querem trabalhar com pesquisa. Então o comprometimento é quase inexistente.
Dai eu pergunto: de quem é a culpa?
Eu me atrevo a dizer que na atual situação, não é de ninguém... mas é de todos. Não é de ninguém pois atualmente o grupo está dependendo do projeto que irá ser aprovado em breve. Esse "em breve" já dura alguns meses, mas a esperança é a última que morre.
É de todos pois foram alocados para o projeto duas pessoas que não queriam trabalhar neste projeto. E também porque toda negociação com o cliente foi horrível... esse processo que está sendo feito para desenvolvimento é muito ruim! É o legítimo "queima-empresa".
Um grupo de pesquisas que tenta trabalhar como empresa vai sofrer sempre com essa crise de identidade, e porque não dizer, de competências.
terça-feira, 2 de setembro de 2008
Valorizando a comunicação!
Eu não estou me baseando em nenhuma pesquisa da Chaos Report ou afins. Estou falando pelo meu feeling com base no que converso com colegas e também no que leio por aí.
Eu diria sem medo que 90% das causas de falhas em projetos estão diretamente ligadas a comunicação. Eu considero isso como sendo:
- Falta de comunicação entre cliente / equipe
- Falta de definição correta de requisitos
- Falta de comunicação entre diretoria / gerência
- Falta de comunicação entre gerência / equipe
- Falta de comunicação entre equipe / equipe
Ufa, a lista seria grande. Sabendo disso, penso que seja essencial que pessoas que trabalham e lidam com pessoas diariamente invistam no aprimoramento da comunicação. Eu fiz isso este final de semana!
Realizei um curso, aqui em Porto Alegre, de "Dicção, desnibição e oratória", ministrado pela fonoaudióloga Bianca Aydos. Um curso de três dias (sexta à noite, sábado e domingo à tarde). E posso dizer que foi uma das melhores decisões que tive no período!
O curso me possibilitou identificar algumas falhas na comunicação que eu possuo (como falar muito rápido e não articular as palavras corretamente) além de vislumbrar que eu consigo passar (na forma "não-verbal") a mensagem corretamente, seja por gestos, seja pela maneira como eu interajo com os interlocutores.
O bacana da realização de um curso deste é que nossos colegas também estão lá pelo mesmo motivo. Portanto eles acabam nos auxiliando e incentivando para evitarmos os vícios de linguagem ("né", "ããããhm", entre outros) e também a desnibir, já que muitos procuram o curso exatamente pelo pavor que tem em falar em público.
O curso não te deixa 100% melhor, nem poderia prometer isso. A idéia é mostrar que há sim um caminho para a mudança. Aprendemos técnicas, postura, formas de enfatizar a mensagem, maneiras de driblar a ansiedade e a timidez... Se não nos melhora 100%, nos prepara para isso.
O curso foi excelente e recomendo a todos que busquem um curso similar. Agrega MUITO para nossa vida pessoal e profissional.
A foto da turma:
De pé: Leonardo, Renato, Daniela, Jaqueline, Joice, Flávio, Marcos.
Agachadas: Bianca, Luciana e Vanessa.
Enfim, para quem é de Porto Alegre e região, recomendo o curso com a Bianca :)
Um abraço e boa semana.
Marcadores:
comunicação,
lições aprendidas,
mudanças,
sugestões
segunda-feira, 1 de setembro de 2008
Relato de um "recém-PMP"
Este relato eu tirei de uma das listas que eu assino. É do Newton Chaves Krás Borges, que recém virou PMP e contou o seu relato para servir como lição aprendida. Achei tão interessante que resolvi publicá-lo aqui no Blog. O relato foi dado na lista da empresa que ministrou o curso (que eu já fiz), portanto não omiti o nome por achar que a PmTech realmente merece ser citada.
Como todo processo que termina em uma prova trás alguma ansiedade, gostaria de compartilhar a minha experiência com os demais membros do grupo.
Espero assim desmistificar um pouco todo o processo e mostrar, que qualquer um que tenha um plano e esteja comprometido com ele pode obter a certificação PMP sem problemas.
Não tenho a pretensão de criar uma receita, mas sim um relato que sirva de benchmark para outras pessoas.
Quando decidi que queria desenvolver uma carreira como gerente de projetos, fiz um curso sobre a metodologia de gerenciamento de projetos do PMI. No final do mesmo, como estava trabalhando num projeto que me tomava muito tempo, e por que não dizer estava com preguiça de estudar, não quis fazer aprova.
Passados dois anos e meio e agora já com alguma experiência e com algum tempo de sobra para me preparar, decidi obter a certificação PMP, para tanto segui o seguinte roteiro:
1. Associei-me ao PMI e comprei a versão impressa do PMBOK;
2. Comprei o Livro "Certificação PMP" do Armando Monteiro, Editora Brasport;
3. Iniciei uma rotina de estudos de 20h semanais, onde estudava um capítulo do PMBOK (O livrinho difícil de estudar) e o seu correspondente no livro do Armando Monteiro;
4. Finalizado esta etapa, me inscrevi para fazer o curso da PMTech;
5. Durante o curso, segui com a mesma rotina de 20h semanais de estudos. Só que agora eu estudava pela apostila do curso e pelo livro "Como se Tornar um Profissional em Gerenciamento de Projetos" da editora Qualitymark;
6. Após o final do curso e depois de terminar a parte teórica dos meus estudos, comecei a fazer os simulados;
7. Fiz três simulados, do programa oferecido pela PMTech, com as seguintes notas: 7,2; 7,24; 7,2 e 8,15;
8. Ao final de cada simulado eu analisava os erros e os acertos, numa espécie de revisão da matéria;
9. Neste ponto eu me dei conta de que a maioria das questões que eu estava errando eram as questões ditas subjetivas: a melhor, a primeira, etc. E o pior era que em algumas vezes eu não concordava com o gabarito;
10. Percebi também que o esforço para melhorar o meu desempenho não valia a pena, uma vez que o negócio era passar na prova e não tirar 10. Afinal já se passavam dois meses de estudos;
11. Marquei a prova e iniciei uma rápida revisão, relendo a apostila do curso e o livro do Armando Monteiro;
12. Fiz um último simulado onde obtive a nota 8 e fui fazer a prova.
Sobre o curso da PMTech:
O curso é muito bom e realmente prepara para a prova de certificação. É incrível como quase todas as questões e assuntos vistos no curso caem na prova da maneira como são abordados no mesmo.
Parabéns pela forma como o curso está estruturado, o material utilizado é muito bom, as aulas são muito interessantes e instrutivas e o programa de simulados é excelente.
Com relação ao programa de simulados, cabe aqui um registro à parte. Ele está bem parecido com a realidade que você irá encontrar no dia da prova, pelo menos para mim eu não vi nenhuma diferença entre a prova real e os simulados, e para dizer a verdade eu achei os simulados mais difíceis do que a prova.
Sobre a prova
A prova não estava difícil, pelo menos a que eu fiz. A maioria das questões tinha um enunciado curto e direto, mesmo as situacionais. As questões "matemáticas" eram simples e exigiam mais o conhecimento em GP do que em cálculos matemáticos.
O tempo não é problema. Durante os simulados eu terminava a prova entre 30 a 40 minutos antes do término, e adotei a estratégia de controlar o tempo utilizando a métrica de 50 questões por hora.
No dia da prova, ao finalizar a questão número 100, eu estava 15 minutos adiantados e parei para ir ao banheiro e tomar um cafezinho, que está disponível na sala ao lado. No final já estava cansado e decidi diminuir o ritmo terminando 20 minutos antes.
Não marquei nenhuma questão para revisão, não vi necessidade, pois ou a resposta estava clara para mim ou ficava em dúvida entre duas opções e já escolhia na hora.
O que mata a pessoa é o número de questões e o tempo da prova. É muito cansativo. O ambiente é bem confortável e o pessoal é bem prestativo, eu fiz a prova em Porto Alegre, mas acredito que todos os sites tenham o mesmo padrão.
Ao terminar a prova você é convidado a preencher uma pesquisa de satisfação, e só ao final da mesma é fornecido o resultado.
Marcadores:
lições aprendidas,
pensamentos,
sugestões
Assinar:
Postagens (Atom)