Páginas

sexta-feira, 17 de dezembro de 2010

Dicas Exame PMP

Você estava procurando por dicas para estudar para a prova do PMI (Project Manager Institute)?

Pois acabou de achar… acabei de fazer o exame (17/12/2010). Como procurei muitas informações sobre o assunto, achei importante publicar aqui no Blog as minhas considerações.
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.
Assim que terminei a pós-graduação em gestão de projetos de TI, decidi que queria me preparar para obter a certificação PMP, para tanto segui o seguinte roteiro:
1.    Inscrevi-me para fazer o curso de preparação para a certificação oferecida pela minha organização (o curso não era o que eu esperava, mas ajudou!);
2.    Terminado o curso, adquiri o Livro da Rita (todos falam que é o melhor... Que Deus a tenha.);
3.    Iniciei uma rotina de estudos de 20h semanais, onde estudava um capítulo do PMBOK (O livrinho difícil de estudar), o seu correspondente no livro da Rita e uma bateria de exercícios simulado.
4.    Eu tinha que fazer um simulado de fim de curso na minha organização, após 30 dias depois do curso o fiz e aceitei 87% (1º Alivio)... Logo após, Marquei a prova para 1 mês e meio depois;
5.    Após o simulado do curso, intensifiquei nos estudos, fazia revia um capitulo e fazia 100 questões do capitulo correspondente a cada 2 dias;
6.    Fiz três simulados de 200 questões, com as seguintes notas: 8.50; 8.65 e 8.60;
7.    Ao final de cada simulado eu analisava os erros e os acertos, numa espécie de revisão da matéria;
8.    Neste ponto eu me dei conta de que a maioria das questões que eu estava errando eram as questões ditas subjetivas. E o pior era que em algumas vezes eu não concordava com o gabarito;
9.    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 mais de três meses de estudos(incluindo o curso);
10.    Fiz um último simulado onde obtive a nota 8,60 e fui fazer a prova (muito nervoso).

Sobre a prova

A prova estava difícil, pelo menos a que eu fiz. A maioria das questões tinha um enunciado direto(mas a opções era de f*##@$), mesmo às situacionais.

O tempo não é o maior 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 10 minutos adiantados e parei para ir ao banheiro e comer algo. No final já estava cansado e decidi diminuir o ritmo terminando 25 minutos antes.
Marquei algumas questões para revisão, pois queria vê depois. E de fato eu revisei algumas, mas em um dado momento decidi finalizar o exame sem apreciar o restante.

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 Brasília, mas acredito que todos os locais tenham o mesmo padrão.

Ao terminar a prova você é convidado a preencher uma pesquisa de satisfação, e só ao final da mesma (após longos segundos)  é fornecido o resultado. (Neste momento, passa um filme na cabeça... E se eu não passar?
Como poderei reunir forças para voltar a estudar? E se passar, como comemorarei? E etc.... RS..rs..rs);

No fim, o mais importante é visualizar as palavras: congratulations(…) PASS!

É isso aí pessoal...Não há segredos, mas a prova merece uma preparação prévia e disciplina.

Simulado: http://www.issoe.com.br/issoe/index.php/simulado-pmpcapm.html

Um abraço.

Mauricio Paiva, PMP, CSM

quarta-feira, 14 de julho de 2010

Falta Bom-Senso

 O texto original deste trabalho, em espanhol, circulou entre os alunos do curso de pós-graduação da Universidade de Piracicaba em 1981. A sutileza com que o autor satiriza um dos problemas de nossos tempos fez com que imediatamente o texto chamasse a atenção de alunos e professores, convertendo-se em tema de conversas e debates. Aos leitores, a Fábula dos Porcos Assados:

Uma das possíveis variações de uma velha história sobre a origem do assado é a seguinte: Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir daí, toda vez que queriam comer porco assado, incendiavam um bosque... até que descobriram um novo método.
Mas o que quero contar é o que aconteceu quando tentaram mudar o SISTEMA para implantar um novo. Fazia tempo que as coisas não iam lá muito bem: às vezes os animais ficavam queimados demais ou parcialmente crus. O processo preocupava muito a todos, porque se o SISTEMA falhava, as perdas ocasionadas eram muito grandes - milhões eram os que se alimentavam de carne assada e também milhões os que se ocupavam com a tarefa de assá-los. Portanto, o SISTEMA simplesmente não podia falhar. Mas, curiosamente, quando mais crescia a escala do processo, tanto mais parecia falhar e tanto maiores eram as perdas causadas.
Em razão das inúmeras deficiências, aumentavam as queixas. Já era um clamor geral a necessidade de reformar profundamente o SISTEMA. Congressos, seminários, conferências passaram a ser realizados anualmente para buscar uma solução. Mas parece que não acertavam o melhoramento do mecanismo. Assim, no ano seguinte repetiam-se os congressos, seminários, conferências.
As causas do fracasso do SISTEMA, segundo os especialistas, eram atribuídas à indisciplina dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou ainda às árvores, excessivamente verdes, ou à umidade da terra, ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas...
As causas eram, como se vê, difíceis de determinar - na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: maquinário diversificado; indivíduos dedicados exclusivamente a acender o fogo - incendiadores que eram também especializados (incendiadores da Zona Norte, da Zona Oeste, etc., incendiadores noturnos e diurnos - com especialização e matutino e vespertino - incendiador de verão, de inverno, etc.). Havia especialista também em ventos - os anemotécnicos. Havia um Diretor Geral de Assamento e Alimentação Assada, um Diretor de Técnicas Ígneas (com seu Conselho Geral de Assessores), um Administrador Geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias (ISCUTA) e o Bureau Orientador de Reforma Igneooperativas.
Havia sido projetada e encontrava-se em plena atividade a formação de bosques e selvas, de acordo com as mais recentes técnicas de implantação - utilizando-se regiões de baixa umidade e onde os ventos não soprariam mais que três horas seguidas.
Eram milhões de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente, etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.
Foram formados professores especializados na construção dessas instalações. Pesquisadores trabalhavam para as universidades para que os professores especializados na construção das instalações para porcos; fundações apoiavam os pesquisadores que trabalhavam para as universidades que preparavam os professores especializados na construção das instalações para porcos, etc.
As soluções que os congressos sugeriam eram, por exemplo, aplicar triangularmente o fogo depois de atingida determinada velocidade do vento, soltar os porcos 15 minutos antes que o incêndio médio da floresta atingisse 47 graus, posicionar ventiladores-gigantes em direção oposta à do vento, de forma a direcionar o fogo, etc. Não é preciso dizer que os poucos especialistas estavam de acordo entre si, e que cada um embasava suas idéias em dados e pesquisas específicos.
Um dia, um incendiador categoria AB/SODM-VCH (ou seja, um acendedor de bosques especializado em sudoeste diurno, matutino, com bacharelado em verão chuvoso), chamado João Bom-Senso, resolveu dizer que o problema era muito fácil de ser resolvido - bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor - e não as chamas - assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o Diretor Geral de Assamento mandou chamá-lo ao seu gabinete, e depois de ouví-lo pacientemente, disse-lhe:
·    Tudo o que o senhor disse está muito bem, mas não funciona na prática. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? Onde seria empregado todo o conhecimento dos acendedores de diversas especialidades?
·    Não sei - disse João.
·    E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadores automáticas de ar?
·    Não sei.
·    E os anemotécnicos que levaram anos especializando-se no exterior, e cuja formação custou tanto dinheiro ao país? Vou mandá-los limpar porquinhos? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Heim?
·    Não sei - repetiu João encabulado.
·    O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê, que , se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo atrás? O senhor com certeza compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas! O que o senhor espera que eu faça com os quilômetros e quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? Vamos, diga-me.
·    Não sei, não senhor.
·    Diga-me, nossos três engenheiros em Porcopirotecnia, o senhor não considera que sejam personalidades científicas do mais extraordinário valor?
·    Sim, parece que sim.
·    Pois então. O simples fato de possuirmos valiosos engenheiros em Porcopirotecnia indica que nosso sistema é muito bom. O que eu faria com indivíduos tão importantes para o país?
·    Não sei.
·    Viu? O senhor tem que trazer soluções para certos problemas específicos - por exemplo, como melhorar as anemotécnicas atualmente utilizadas, como obter mais rapidamente acendedores de Oeste (nossa maior carência), como construir instalações para porcos com mais de sete andares. Temos que melhorar o sistema, e não transformá-lo radicalmente, o senhor, entende? Ao senhor, falta-lhe sensatez!
·    Realmente, eu estou perplexo! - respondeu João.
·    Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério e complexo do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia - isso poderia trazer problemas para o senhor no seu cargo. Não por mim, o senhor entende. Eu falo isso para o seu próprio bem, porque eu o compreendo, entendo perfeitamente o seu posicionamento, mas o senhor sabe que pode encontrar outro superior menos compreensivo, não é mesmo?
João Bom-Senso, coitado, não falou mais um "A". Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.

Fonte: http://www.marcoscintra.org/fabula_porcos.asp

quarta-feira, 30 de junho de 2010

Metodologias Ágeis: um caminho para a eficiência. Será?


Essa semana eu vi a seguinte frase na empresa em que trabalho: “Fazer mais, melhor e mais rápido: este é o objetivo de toda organização que oferece um produto ou serviço para os consumidores (....). Por isso, para oferecer maior eficiência e eficácia em suas atividades, uma novidade vem sendo introduzida nas atividades de desenvolvimento de sistemas. São as metodologias ágeis.(...)”

Gerentes de projetos que atuam na área de desenvolvimento de software convivem com desafios de liderar projetos com cronogramas apertados, metas audaciosas, constante mudanças de requisitos, novas tecnologias e sistemas de informações que cada vez mais suportam a tomada de decisão e os processos chave de negócio das empresas. Em um cenário como esse, ser ágil é crucial, todavia ser ágil não necessariamente é ser mais rápido.
          Porém ser ágil acima de tudo é:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”


O termo "ágil", nas metodologias ágeis, significa basicamente aderir aos princípios estabelecidos no manifesto ágil (http://www.agilemanifesto.org/)
Não tem necessariamente a ver com mais rápido. Note que é apenas 
uma palavra, escolhida por um grupo de desenvolvedores de software, 
para representar um conjunto de idéias. Infelizmente, somos levados a 
olhar para o significado habitual da palavra, ou seja, velocidade. 
Porém, em desenvolvimento de software ser rápido engloba um 
significado muito maior, como por exemplo: maturidade da equipe com a tecnologia envolvida, projeto com o mínimo de integrações possíveis, processo de desenvolvimento de software clean e maduro na organização, etc...


    Enfim, o "Ser ágil" está sintetizado na imagem abaixo. Afinal, para você quem é mais rápido e quem é mais ágil?

terça-feira, 27 de abril de 2010

Os 5 objetivos que precisam ser perseguidos nos projetos de TI

Recentemente os capítulos do PMI no Brasil divulgaram os resultados do Estudo de Benchmarking em GP que envolveu cerca de 300 empresas dos setores de tecnologia da informação, Consultoria, Serviços, Indústria, Engenharia e EPC, Governo.

O relatório é o resultado do trabalho voluntário de vários profissionais de todo o país, representando suas respectivas seções regionais do Project Management Institute - PMI.

O CEO/EUA publicou ontem uma matéria falando sobre: Os cinco objetivos que precisam ser perseguidos nos projetos de TI

Dicas, alguns resultados do estudo e considerações pessoais, você encontra aqui. Boa leitura!
 

Os gerentes de projeto têm a responsabilidade de gerir todos os aspectos das atividades que estão supervisionando, desde recursos e suprimentos até custos de projetos e equipamentos. No começo, parece difícil, mas basta seguir uma metodologia de trabalho que consiste em seguir objetivos relacionados ao projeto. Confira os cinco objetivos que você deve perseguir para alcançar sucesso em cada novo projeto.

1 – Termine no prazo
Esse é o mais velho dos objetivos, mas ainda assim o mais difícil de cumprir, em se tratando de gerenciamento de projetos. A dificuldade está nas constantes mudanças de requisitos e por conta do otimismo exagerado da agenda inicial.
O PMI em seu estudo comentado no inicio deste post fez a segunte pergunta:A Organização costuma ter problemas no cumprimento dos Prazos estabelecidos para os projetos? 72% das empresas de TI responderam sim para essa pergunta.

Para cumprir esse objetivo, o profissional deve gerenciar seu escopo muito cuidadosamente. A primeira coisa é criar um controle de alterações no projeto para gerenciá-los adequadamente. Sempre mantenha seu plano atualizado, com registros do progresso atual em relação ao que estava planejando. Identifique rapidamente qualquer desvio e trate de consertá-lo.

2 – Finalize o projeto dentro do orçamento
Para ter a certeza de que os custos do projeto não subam à estratosfera, você precisa ganhar visibilidade sobre custos logo no início para manter o controle. O budget deve ser elaborado incluindo todos os custos do projeto, não importando se tem a ver com pessoas, equipamentos, fornecedores ou materiais. Saiba, então, o custo de cada tarefa do planejamento e mantenha o controle para observar qualquer desvio.
A Organização costuma ter problemas no cumprimento dos Custos estabelecidos para os projetos? 59% das empresas de TI responderam sim para essa pergunta.

Com essa postura, se você gastar demais em alguma tarefa, consegue corrigir o orçamento gastando menos em outras. Só dessa forma é possível garantir que o projeto fique dentro do orçamento, ou até abaixo dele.

3 – Conheça os requisitos
Não importa qual é o objetivo do projeto, ele deve produzir soluções que atendam a 100% do que foi requisitado. O truque aqui é garantir a existência de uma lista bem detalhada dos requisitos necessários e ter a certeza que todos foram bem compreendidos. Isso porque requisitos ambíguos, que antes pareciam um pequeno fragmento do projeto, podem se tornar enormes, tomando tempo e recursos não esperados.
Adiciono a dica do CIO/EUA, a utilização do Product Backlog pregado pelo Scrum, que nada mais é que uma lista dos requisitos de forma priorizada. Assim o desenvolvimento, adotando um ciclo de desenvolvimento iterativo e incremental, poderá desenvolver primeiro os requisitos de maior prioridade para o cliente, obtendo mais rapidamente a satisfação dos usuários e o ROI para a organização.


4 – Mantenha os clientes felizes
Você pode até ter conseguido terminar o projeto a tempo, abaixo do orçamento e atendido 100% dos requisitos, mas ainda assim ter clientes infelizes. Isso pode acontecer porque suas expectativas mudaram desde que o projeto foi iniciado e não foram devidamente gerenciadas.

Para garantir que os patrocinadores do projeto, usuários e outros stakeholders fiquem felizes na entrega, algumas atitudes são necessárias. A primeira é ter certeza de que todos fiquem bem informados do progresso do projeto. Mantenha todos com o pé no chão com uma visão transparente do que está acontecendo.

Deixe que todos expressem suas preocupações e idéias com regularidade. Diga-lhes com antecedência se há algum problema com relação ao prazo de entrega ou quando mudanças são necessárias. Abertura, honestidade e clareza nas informações são sempre as melhores ferramentas para manter o projeto alinhado com as expectativas dos clientes.


5 – Zele pela felicidade da equipe do projeto
Se você conseguiu preencher os quatro objetivos anteriores com um time feliz, a disposição para repetir tudo em uma próxima vez será bem maior, assim como a disposição da equipe.

A melhor forma de manter a equipe motivada é reconhecer e premiar os bons trabalhos. Delegue atividades de acordo com os pontos fortes de cada um e conduza exercícios de equipe para aumentar a confiança. Divulgue metas e objetivos, promova, mesmo que de forma contida o autogerenciamento e a troca de informações do time.

Para finalizar, o estudo do PMI revelou também que para a maioria das empresas do ramo de TI, o maior problema enfrentado nos seus projetos é a: COMUNICAÇÃO.

Sendo assim, mais um ponto para as reuniões diárias de 15 minutos na qual cada membro da equipe deve responder a 3 (três) perguntas:

    O que cada um fez desde a última reunião?
    O que pretende fazer até a próxima reunião?
    Teve ou está tendo algum impedimento?

    Através desta reunião o time(equipe) obtém uma maior visibilidade de como está o projeto e se estão de fato alinhados com as metas e objetivos.

Até mais!

 


Fontes:
1) Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2009, Project
Management Institute – Chapters Brasileiros.

2) Matéria disponível em: http://cio.uol.com.br/gestao/2010/04/26/os-cinco-objetivos-que-precisam-ser-perseguidos-nos-projetos-de-ti/

3) http://www.scrumalliance.org/

segunda-feira, 29 de março de 2010

Ferramenta de Software Livre para Gestão Ágil de Projetos

Pessoal,

Em uma pesquisa na web encontrei um software chamado "ponto", ele é voltado para o gerenciamento ágil de projetos, vale a pena testar.

Um pouco da histórica do "ponto".

O projeto "Pronto" surge no final do ano de 2008 como um trabalho de conclusão do curso Sistemas de Informação da FIAP - Faculdade de Informática e Administração Paulista.

Foi idealizado por Luiz Faias Jr e André Faria Gomes, com a orientação do Prof. MSc. Jakov Trofo Surjan.

Em junho de 2009 entrou em produção como o sistema de gestão do trabalho da Bluesoft, em substituição ao software Trac.

Sua apresentação ocorreu em 07/12/2009 com aprovação pela banca examinadora.

A versão final da monografia encontra-se disponível no formato PDF.

O Sistema e a monografia podem ser acessados pelo site: http://pronto.bluesoft.com.br/Home

Bons testes. opa eu já fiz uns... muito bacana por sinal.


quarta-feira, 10 de março de 2010

Trabalhando com equipes ágil

Tradução livre (Com adaptações) de trecho do artigo “The Agile Project Manager” escrito por Mike Cottmeyer e publicado pela VersionOne.com.


Trabalhando com equipes ágil



Não é sempre que uma equipe irá exigir um gerente de projetos dedicado. Muitos projetos ágeis contam com membros da equipe que pode executar mais de uma função. Um membro da equipe de desenvolvimento ou um Product Owner pode servir como o Gerente de Projeto para uma pequena equipe ágil. Entretanto, um gerente de projetos pode ser convidado para assumir um papel na equipe com o objetivo de ajudar a preencher uma lacuna entre a equipe e a empresa ou para gerenciar as atividades que acontecem fora do próprio time.

O Gerente de Projeto pode ser convidado a trabalhar em um projeto ágil porque há necessidade de definir um plano de comunicação, uma abordagem de gerenciamento de risco, ou de coordenar as atividades de diversas equipes que trabalham em conjunto para entregar um grande projeto ou carteira de projetos.

O Gerente de Projeto deve tornar-se parte da equipe e envolver outros membros na criação de planos e artefatos do projeto. Isso ajuda manter um ambiente de alta confiança e da garantia as membros do time.

A iteração Agile começa com um período intenso de colaboração seguido por mais interações ad-hoc entre os membros da equipe. O gerente de projeto pode ajudar a equipe se aglutinam em torno de iteração e das metas, garantindo que os compromissos sejam razoáveis e baseados em um ritmo sustentável e métricas de monitoramento dentro da iteração e global através de iterações.

A maioria das metodologias ágeis não defini explicitamente o papel de um
Gerente de Projetos. No Scrum muitas das responsabilidades do gerente de projetos foram distribuídas entre o papel do Product Owner e do ScrumMaster. Entender funções do projeto e ajudar a definir responsabilidades são atribuições importantes, típicas de um Gerente de projetos, principalmente quando há integração com uma equipe ágil de projetos.

Amigo “Líder”: Você seria liderado por si mesmo?

Texto de Manoel Pimentel


Há alguns anos atrás, gerenciava uma pequena equipe de TI numa indústria alimentícia. Foi um tempo muito bom e antes de toda a correria pré “bug do milênio”. As aplicações MS-DOS (Leia aplicações Clipper) reinavam e tecnologias como NOVELL e NT eram o grande paradigma em debate.

Nesse pequeno ambiente de TI (que na época chamávamos de CPD), tive uma oportunidade de num contexto extremamente caótico (sobre o ponto de vista organizacional) liderar essa equipe rumo a projetos de desenvolvimento de software ambiciosos para a época e conjuntura regional da empresa.

Como na época nem sonhávamos com algo chamado Agile, confesso que se fosse hoje, faria muita coisa diferente nesses projetos. Contudo, o objetivo desse artigo não é debater o processo, mas sim mostrar um aspecto cultural importante, que é exatamente a forma como os líderes pensam e atuam dentro das equipes.

Não que nessa época eu tenha sido um ótimo líder; Na verdade minha juventude e inexperiência ainda eram muito grandes (que saudade desse tempo...). Mas para compensar essas limitações, acabei construindo e adotando um pensamento que me foi extremamente útil na liderança desse time.

Esse pensamento é bem simples, pois consiste no seguinte auto questionamento: Eu aceitaria ser liderado por mim mesmo? Essa é uma pergunta extremamente simples e direta, porém, respondê-la a você mesmo é enormemente complicado.

Eu diria que essa pergunta me acompanha desde então, de forma que quanto mais eu fui interagindo com outras equipes (de diferentes lugares e tamanhos) e me aprofundando em meu trabalho de coaching, mais forte se tornou minha convicção que mesmo sendo complicado responder essa pergunta, é muito benéfico colocar o cérebro em busca dessa resposta.

Afirmo que é benéfico buscar por essa resposta, pois esse processo de procura, pode mexer de maneira desconfortável com a sua estrutura de crenças e valores. Esse desconforto acontece pois a busca por essa resposta, criará uma espécie que espelho no qual é possível refletir quais os seus valores e crenças e, as vezes a imagem refletida nesse espelho não é bonita.

Mas alem de refletir sobre seus valores e crenças, é muito importante também você procurar visualisar nesse espelho, o quanto esse conjunto de pensamentos estão limitado suas ações como um bom líder e consequentemente, impedindo a sua equipe de gerar melhores resultados.

Veja que buscar respostas para essa singela pergunta, já nos coloca num caminho de mudança de pensamento, contudo, existe uma lacuna entre o pensamento e a ação. Essa lacuna é preenchida com a emoção. Ou seja, mesmo que você mude seu pensamento, somente se houver alguma emoção, ele provocará ações para uma verdadeira mudança de comportamento.

Apesar de haver uma lista de emoções possíveis para ligar um pensamento a uma ação, todas elas são originárias de dois tipos de sentimentos: Dor ou Prazer. Ou seja, você só mudará realmente seu comportamento se houver uma dor atual suficientemente capaz de lhe motivar para uma ação de saída da dor, ou um desejo por um prazer (seja na meta fim ou processo meio) capaz também de o motivar a mudar suas ações .

Curiosamente as palavras emoção e motivação derivam da mesma origem latina que é a palavra movere, que trazendo para o português, teríamos algo como mover-se (existem outras variações também). Portanto, veja que despertar essa emoção em nós, é a chave para compreendermos e construirmos a motivação necessária para nos levar de um estado atual(ponto A) para um estado ideal(ponto B), assim, um líder, só será um excelente líder, se o mesmo tiver algum motivo que provoque essa mudança de pensamento e de comportamento (afinal líder é “gente” e também precisa de motivação) . E esse espelho criado quando fazemos esse questionamento, já é um bom ponto de partida para gerar essa emoção.

Na verdade a essência desse questionamento (Você seria liderado por si mesmo?) pode ser aplicado a vários outros contextos em nossas vidas, por exemplo, experimente responder para si mesmo algumas questões como: Você contrataria a si mesmo? Ou: Você usaria um produto feito por você? Ou mais profundo ainda: Você se casaria com consigo mesmo?

Finalizo esse breve texto lembrando que não estou aqui dizendo a você: “seja um líder tipo tal” ou “siga determinado estilo ou processo gerencial”, mas pretendo com esse texto estimular que você (líder) encontre seu próprio caminho rumo a sua visão daquilo que acredita ser um ótimo líder dentro do seu contexto. Também quero reforçar que idealmente esse tipo de questionamento não seja usado apenas uma única vez, mas sim de maneira constante e cíclica, pois assim, será possível criar um cenário propício para a tão sonhada melhoria contínua de indivíduos e de equipes. Dessa forma, para exemplificar a importância desse pensamento em minha vida, vou lhe compartilhar qual o meu pensamento final quando termino um artigo como esse: Eu leria um artigo escrito por mim mesmo?

domingo, 28 de fevereiro de 2010

Onde surgiram os métodos ágeis?

Em Janeiro de 1986 foi apresentado na Harvard Business Review um artigo chamado “The New New Product Development Game” (TAKEUCHI e NONAKA, 1986), onde os autores chamam a atenção dos gestores para perceberem que a tradicional abordagem seqüencial usada para desenvolvimento de novos produtos não funcionaria no cenário atual. Eles afirmaram que, os gestores de projetos devem adotar uma abordagem mais flexível, ou seja, uma estratégia global de desenvolvimento de produto em que uma equipe de desenvolvimento funciona como uma unidade para alcançar um objetivo comum. Compararam ainda o alto desempenho de equipes multifuncionais com formação Scrum usadas por equipes de um jogo chamado Rugby.
Tal publicação desencadeou uma serie de discussões no mundo acerca da necessidade de mudança na forma como se gerencia e desenvolve projetos.

Em 2001, Kent Beck e outros 16 famosos desenvolvedores, produtores e consultores de software assinaram o “Manifesto para o Desenvolvimento Ágil de Software”. Na época eles afirmaram que estavam descobrindo maneiras melhores de desenvolver software, fazendo e ajudando outros a fazê-lo. Por meio desse trabalho passaram a valorizar:

Indivíduos e interações em vez de processos e ferramentas;
Software funcionando em vez de documentação abrangente;
Colaboração do cliente em vez de negociação de contrato;
Responder a mudanças em vez de seguir um plano;

Isto é, embora haja valor nos itens em à direita, eles valorizam mais os itens à esquerda.
Segundo Ken Schwaber(2004), quanto mais complexo o projeto, mais necessário se torna para delegar a tomada de decisões a agentes independentes que estão perto do trabalho.

O documento “The New New Product Development Game” pode ser facilmente encontrado na internet.

Boa leitura a todos.

quinta-feira, 7 de janeiro de 2010

Departamento de Defesa americano está adequando sua legislação para agilizar suas contratações de TI.

Mais detalhes em:
http://www.jessefewell.com/2009/10/02/defense-procurement-goes-agile/


"In his presentation, he cited a number of points that reveal a growing consensus within the military that old ways of procurement are becoming less effective. He started by noting the key regulatory standard for procurement, DODD 5000.1, was originally developed in 1977 and has remained mostly unchanged since then.
(...) eventually the momentum became so great in 2008, Congress responded to these concerns by mandating a Defense Science Board (DSB) to study current policies and procedures. At the end of their analysis, they recommended a new IT iterative, incremental approach to project acquisition and execution. The DRB’s recommendations have been so compelling, they were invited this past May/June to testify to Congress about their strategy"

Penso que é hora do Brasil avançar neste sentido também...

Mais sobre o assunto em:
http://blog.seatecnologia.com.br/2009/12/16/o-problema-da-contratauao-de-ti