O que acontece muito nos dias de hoje é a contratação em massa de pessoas com a falsa impressão de que, produzindo-se no prazo X, a demanda Y com Z pessoas, basta duplicarmos Z que por consequência X será quebrado ao meio para a mesma demanda Y. Eis o grande erro: o trabalho é realizado por pessoas que não são uma ciência exata. Podemos confortavelmente dizer que, para cada novo membro, temos como resultado para equipe a soma de sua capacidade técnica e a subtração de sua personalidade.

Expliquemos de modo prático: mesmo sendo um profissional de alta qualidade, um novo membro na equipe trará ideias, metodologias e costumes conflitantes que deverão ser imediatamente identificados pelo gestor, que deverá ter jogo de cintura para administrar a situação e desconforto gerado na equipe. Isso impacta na produção da equipe como um todo, podem os teóricos levantar suas bandeiras da docência contrariando essa constatação que basta análise holística que veremos tratar de uma realidade.

Defendemos que uma equipe menor e coesa é, sem a menor sombra de dúvidas, mais produtiva que uma equipe maior e desconexa.

Portanto, meus caros, mais uma vez reforçamos, tratem do bem estar dos membros da sua equipe e pare de tentar impor seu sistema de trabalho errôneo em nome do suposto poder que detém. Obviamente que a equipe precisará crescer, mas que seja de maneira organizada e planejada não baseada na substituição e avaliação por tentativa e erro.

O autor consegue, de uma forma extraordinária, relatar o que de fato ocorre no cotidiano das empresas, que vai do momento da convocação do funcionário ao ser promovido a todas as tarefas, rotinas e desafios que o gerente de projeto tem que enfrentar para realizar as entregas definidas no escopo.

Este livro conta a história de um analista de sistema que inesperadamente ganha o privilégio de desempenhar a função de gerente de projetos. Função ou cargo que o próprio funcionário desconhece e nem mesmo sabe sobre quais de fato são os seus desafios, situação está freqüente em algumas empresas.

Atuar como gerente de projetos não é uma tarefa fácil pelo grau de complexidade das tarefas multidisciplinares em que o gestor tem que atuar, principalmente para o analista de sistemas do livro que possui como principal desafio aprender a se relacionar com pessoas, ou seja, ele tem que aflorar seu lado interpessoal sendo retirado da sua zona de conforto ao se deparar com os novos desafios.

Talvez a parte mais engraçada e interessante do livro ocorre quando o analista de sistema tenta explicar sobre sua promoção aos membros da família e todos não compreendem que raio de promoção e aquela que talvez nem possua benefícios financeiros.

Com bom humor e muita criatividade o autor consegue mostrar as facetas em desempenhar a função de gerente de projetos, além de ensinar alguns detalhes e macetes do cotidiano da profissão.

Entre os pontos fortes do livro se destacam:

• O bom humor da história ao relatar os problemas cotidianos;
• As dicas das muitas facetas da função\profissão;
• A importância da troca de experiências, o que não se torna difícil hoje graças à internet e aos diversos fóruns sobre o assunto, pois, a todo o momento tem alguém disposto a contribuir de alguma forma.
• As perguntas inteligentes da filha do analista, que leva a muitas reflexões;
• Aos desafios em conciliar a vida profissional e pessoal;
• O desafio de aprendizagem constante, pois cada projeto é único;
• A difícil tarefa de despedir uma pessoa da equipe;
• O respeito com os membros da equipe;

Este livro se destaca dos demais ao demonstrar ao futuro Gerente de projetos de uma maneira bem humorada os desafios e vantagens de exercer esta função ou carreira que se encontra presente nas organizações.

Obrigado aos que chegaram até o final deste texto.

Deixe seu comentário! Aceito recomendações para continuar o debate em textos futuros.

Referência: Livro: Gerente Também é Gente… ISBN8574522570

• Se você não utilizar tal metodologia não vai dar certo.
• Se você não for certificado não vai conseguir.
• Se você não seguir o que os especialistas falam não vai conseguir.

Que visão é essa?

Gerir projetos é muto mais do que metodologia.

Atualmente gerencio projetos em uma empresa da área de TI, onde aplico o que funciona!

Aplico o que minha equipe necessita, o que meu cliente precisa para ter os melhores resultados.

Utilizo práticas que combinam com o resultado que quero alcançar.

Gerenciar projetos é muito mais do que delegar tarefas para a equipe, gerenciar projetos é malabarismo constante de avaliação de prioridades, avaliação de recursos, prazos, riscos, resolução de problemas, entre tantas coisas que fazemos.

E quando temos a necessidade de gerenciar vários projetos ao mesmo tempo, e manter tudo alinhado, fica muito clara a necessidade da colaboração e da comunicação, alinhar equipe e interessados no projeto em busca do melhor resultado.

Gerentes de projeto não são independentes, nem fazem milagres, são totalmente dependentes do feedback das suas equipes e dos clientes. A comunicação tem papel chave nas tomadas de decisões, na identificação de riscos, na aprovação de solicitações.

Use modelos, mas não esqueça que de nada adianta a melhor metodologia se não tem profissionais comprometidos com o que fazem. Metodologias não salvam projetos. Projetos são etapas que possuem inicio e fim, e precisam de profissionais envolvidos com o que fazem.

De nada adianta ter um gerente de projetos certificado em várias tecnologias, se o mesmo não consegue se comunicar com eficaz com seu time de desenvolvimento. De nada adianta ter conhecimento das melhores práticas, se na hora de por a “mão na massa” não sabe qual a melhor decisão tomar.

Antes de entrar nessa linha de gestão de projetos, só enxergava pessoas com o perfil “gerentão”, sim, aquele que pensa que manda em todo mundo e que não faz nada para o bem do seu time e da organização. Depois que tive contato com essa área, conheci várias pessoas que estão envolvidas e conseguem fazer um ótimo trabalho deixando de lado aquela velha visão de um gerente de projetos que não faz nem a metade do que promete, e que sequer se importa de verdade com as pessoas envolvidas nos projetos que gerencia.

E essa experiência firma mais minha visão, de que boas metodologias não vão te salvar, se você não souber articular, perceber as atitudes, as emoções das pessoas envolvidas, se você não sentir na pele o que sua equipe está sentindo, não vai conseguir bons resultados.

Pessoas são a chave para o sucesso. Esqueça o gerentão, e direcione o foco na sua equipe, na boa comunicação com os envolvidos, na colaboração entre as funções. Nos resultados que podem ser alcançados se você conseguir liderar de forma saudável, sem prepotência, sem arrogância, apenas sendo um líder. Onde as pessoas acreditam no que você faz, e fazem junto com você, e o melhor de tudo, gostam do que fazem.

Me arrisco a falar que se você conseguir perceber as limitações da sua equipe, perceber as necessidades, se comunicar de forma clara, e dar autonomia para o time na medida que o mesmo for adquirindo maturidade, as coisas vão dar certo.

Nessa área, onde os riscos são gigantes e as pessoas são imprevisíveis, o melhor a fazer é manter a sinergia do time, alinhar os objetivos e por a mão na massa, de verdade.

Você pode me xingar no Twitter!

É impressionante como algumas pessoas se envaidecem pela função ou cargo que atua e esquecem que o trabalho de GP é ser um maestro e não um gerador de problemas, que para realizar as entregas nos prazos estabelecidos a pessoa tem que ter humildade, saber escutar e ter mais do que somente à técnica ou metodologia de projetos.

O GP deve aprimorar seu lado interpessoal tanto quanto as habilidades técnicas necessárias para poderem gerir um projeto, pois cabe a ele envolver todos os membros da equipe. Sem o apoio das pessoas os projetos falham. Se observar a literatura sobre o assunto a grande maioria dos problemas está relacionado à comunicação, ou seja, ouvir e comunicar, comunicar e ouvir.

Um líder deve instigar os envolvidos e saber tirar o melhor de cada membro da equipe, não pode jamais ficar envaidecido pela sua função, ele deve colher e avaliar as diversas variáveis internas e externas existentes sobre seu projeto em conjunto com sua equipe para tentar amenizar possíveis riscos. O trabalho em equipe serve para gerar um aprendizado coletivo onde a limitação é visão de um e superada com o apoio das percepções dos integrantes, onde o impossível se torna possível.

Um maestro não dita somente regras, ele ocupa a posição de líder e têm como obrigação ajudar, apoiar, aprender, ensinar e encontrar alternativas com sua equipe a se superarem e realizar as entregas conforme o ESCOPO. As entregas do ESCOPO são sua obrigação, mas para que elas sejam realizadas conforme a tríade (escopo, tempo e custo) o GP deve ocupar o mesmo degrau dos seus aliados e não estar em um pedestal acima.

Afinal o GP jamais deve esquecer que o insucesso do projeto significa o fracasso somente dele, pois ele é o Líder, mas o sucesso do projeto representa o “Sucesso da Equipe”.

E você, o que vem encontrando no seu dia a dia, Gerente de Projetos ou Gerente de Vaidades?

Obrigado aos que chegaram até o final deste texto.

Deixe seu comentário! Aceito recomendações para continuar o debate em textos futuros.

Existem muitas metodologias que podem ser aplicadas nessa área, porém, as boas práticas do PMI são reconhecidas em grande parte do mundo tornando-se, portanto, uma metodologia “universal”.

Há anos os profissionais do meio lidavam tranquilamente e executavam ótimos projetos sem essas metodologias – saudosos tempos em que não vivi. Porém, com o mundo globalizado e em um mercado altamente competitivo, tivemos as demandas quadriplicadas com prazos cada vez menores.

Diante dessa situação, surge a necessidade de um Gerente de Projetos nas empresas. Como um grande Mago, o Gerente é o responsável em fazer e acontecer, que vai do possível ao impossível. Se houve sucesso, parabéns à equipe. Do contrário, que gerente é você que não soube planejar o projeto? A magia – o sucesso – não está em ensinar e realizar novos truques ou montar novas poções, e sim, em permitir que o aprendiz de feiticeiro possa se desenvolver para que um dia também seja um Mago.

O profissional desse meio não precisa necessariamente ter conhecimento em uma área específica, mas, precisa conhecer as metodologias do PMI aplicadas ao plano de gerenciamento de projetos (Escopo, Tempo, Custo, Aquisição, RH, Qualidade, Riscos, Integração e Comunicação). É nesse momento em que o Gerente monta a sua equipe e passa a designar tarefas com base na EAP (Estrutura Analítica de Projetos) para que todos os interessados, sejam eles colaboradores ou clientes/patrocinadores, saibam exatamente quais tarefas deverão executar e o tempo estimado de entrega de cada pacote de trabalho com base no cronograma do projeto.

Dessa forma você estará envolvendo todos os membros da sua equipe, planejando os processos, prevendo os riscos, economizando tempo e muitas vezes, diminuindo os custos.

Não podemos esquecer que um gerente colherá bons frutos se no início do projeto tiver um bom conhecimento das regras, práticas e burocracias da empresa. Isso facilitará muito o seu trabalho e, por vezes, determinará o sucesso do projeto.

Para você que trabalha como freelancer, a necessidade é ainda maior em manter um controle total das tarefas, prazos e custos que serão repassados ao seu cliente e, principalmente, saber dar um feedback certo quando solicitado. Por isso, as boas práticas do PMI podem ser grandes aliadas do seu trabalho.

Imagine você que com esse controle todo logo mais terá de aumentar a sua equipe e ampliar os seus negócios, pois terá um aumento significativo na demanda de trabalho e será nesse momento que você dirá adeus às dores de cabeça por falta de controle e planejamento.

Perceba, não há mágica e sim, domínio de suas ações.

Como um aprendiz de feiticeiro – futuro gerente de projetos – os erros nem sempre são imediatos. Você nunca vai saber o efeito de uma pólvora se não colocar fogo em cima.

Então, aqui fica a dica: almejando o sucesso e menos problemas, esqueça a correria do dia-a- dia e reserve um tempo para planejar a execução do seu projeto. O tempo, aparentemente perdido para isso, será um ganho certo na entrega final do seu trabalho e a experiência adquirida a cada projeto fará de você um Mago capacitado a formar novos aprendizes.

Sucesso e bons negócios.

Quem gerencia projetos, ou já contratou empresas para executar projetos, sabe que podemos diminuir custos e diminuir prazos deixando de realizar fases importantes do mesmo, tais como fase de levantamento e análise de requisitos, design e documentação. Outra maneira é a de diminuir a própria qualidade do produto a ser desenvolvido, omitindo ou diminuindo a fase de testes.

É justamente aqui que vai se armando uma grande armadilha. Alguns envolvidos podem não estar cientes das consequências geradas para a empresa que estará recebendo o produto, pela decisão de omitir fases ou deixar de gerar documentação do projeto.

Para ilustração, comento que existem requisitos conhecidos como requisitos não funcionais, relacionados a características do software que estão embarcados na solução mas que não são funcionalidades utilizadas diretamente pelo usuário, descrevendo qualidades do sistema.

Um exemplo de requisito não funcional é o de confiabilidade, garantindo que as informações disponibilizadas pelo sistema a ser desenvolvido sejam fidedignas. Não conseguimos atingir esta meta se não realizarmos a fase de requisitos e de análise em nosso projeto.

Caso o projeto não atinja este quesito, apresentando informações consideradas não fidedignas pelos usuários, nenhum deles se interessará em utilizar o mesmo e o projeto fracassará, e todo o investimento será perdido. Tive a oportunidade de ver funcionários de uma grande empresa comentando justamente isto, que não utilizavam um sistema da mesma por não confiarem nas informações apresentadas.

Isto pode ser evitado caso o projeto utilize uma Metodologia de Desenvolvimento de Sistemas adequada.

Imagine agora um cenário de um sistema de Cobrança bancária, para o qual você poderia estar participando de um processo de manutenção corretiva, sem ter documentação do sistema e sem ter conhecimento das regras de negócio implementadas. Imagine também que esta manutenção está relacionada à correção de informações, que estão sendo geradas incorretamente Agora, para finalizar, imagine que o sistema possui milhares de linhas de código no paradigma procedural e você é novo na equipe e foi contratado recentemente, sendo que os programadores que implementaram o sistema não estão mais na empresa.

Por mais que este cenário seja assustador, podemos encontrá-lo neste exato momento em diversos lugares, enquanto você lê este parágrafo.

O que faltou no projeto de desenvolvimento deste tipo de sistema?

Entre outros, poderia citar:

• Utilização de Metodologia de Desenvolvimento de Software e os produtos de cada fase.
• Engenharia de Software e utilização de processos definidos.
• Utilização de paradigma de desenvolvimento Orientado a Objetos.
• Utilização de Design Patterns, caso coubesse.
• Documentação adequada.

Do lado humano, poderia citar:

• Participação no projeto de profissionais com conhecimento dos itens técnicos acima relacionados.
• Falta de percepção do sponsor responsável pelo projeto do valor e benefícios de se utilizar os itens acima relacionados.
• Falta de conhecimento dos envolvidos no projeto, das melhores práticas de mercado para desenvolvimento de software e de seus benefícios.

Já tive a oportunidade de presenciar de empresários e executivos, o seguinte comentário:

“Prefiro o desenvolvimento de software sem utilizar Orientação a Objetos e processos de desenvolvimento, pois é mais barato e mais rápido de se disponibilizar o sistema para os usuários.”

Desenvolver código baseado nesta ideia pode gerar as seguintes consequências:

• Implantação de sistemas cheios de erros, constantemente entrando em manutenção corretiva.
• Sistemas que podem não atender às expectativas dos Stakeholders.
• Softwares com alto custo de manutenção.
• Softwares difíceis de serem utilizados, não atendendo às necessidades dos StakeHolders.
• Grande insatisfação dos usuários.
• Fracasso do projeto.

O desenvolvimento de sistema sem utilizar processos, AD HOC, acaba custando muito mais caro, gerando insatisfação.

Já presenciei várias vezes, pessoas que simplesmente não queriam e não utilizavam sistemas disponibilizados pela empresa, por pelo menos um dos seguintes motivos:

• Não confiavam nos dados por eles apresentados.
• Porque não atendiam a suas expectativas e necessidades do dia a dia.
• Porque tinham usabilidade ruim.
• Porque viviam apresentando problemas de funcionamento.

O detalhe mais triste é que as empresas onde estas pessoas trabalhavam, investiram dinheiro e tentaram disponibilizar sistema para melhorar a produtividade e diminuir custos das mesmas. O resultado foi exatamente o contrário pois além de não diminuir custos, nem aumentar produtividade, as empresas perderam todo o investimento realizado e o sistema caiu em desuso, literalmente, sendo jogado fora.

Realizar um projeto omitindo fases cria uma grande armadilha, para a empresa que está adquirindo o sistema.

Para saber mais, leia o livro Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1

Sou programador de software. Digam-me a verdade, tem coisa mais inútil que projetos? Tem sim, gestão de projetos!

Vamos ser práticos, projetos só servem pra “encher linguiça”. O negócio é cumprir o que pedem. O cliente é quem manda! Se ele diz para fazer, vamos fazer, eu sei programar por que tenho que ficar fazendo um “monte de coisas inúteis” que não servem para nada. Isso mesmo, pra nada, vou explicar!

Levantamento de Necessidades: Isso eu mesmo faço, é simples, só anotar o que o cliente quer.
Documentação de Requisitos: Não precisa o cliente já disse o que quer, eu já sei tudo.
Diagramas de Casos de Uso, Sequência, Classes, Dados: Bobagem, já estou programando tudo.
Planejamento: Outra coisa inútil é só ir fazendo o que pedem.

Não sei por que, estes que se dizem “especialistas em projetos” ficam insistindo em planejar, comunicar, apurar custos, definir tempo, colocar um “método unificado”, besteira. Não vejo problemas em atender as necessidades do usuário sem usar nada disso.

O usuário já me conhece, somos amigos e fica mais fácil ele me pedir as coisas diretamente, não preciso informar ninguém. A qualquer momento (horário de almoço, corredor, por e-mail, até depois do expediente) ele me pede o que precisa e eu faço!

Não precisa avaliar os impactos, porque já conheço a estrutura do negócio e do sistema. É só programar o que o usuário pediu. Se por acaso depois que estiver pronto, o usuário pedir para mudar, não tem problema, afinal a idéia é ajudar o usuário e fazer o que ele quer. Isso não é “retrabalho”, é agradar o usuário.

Todas estas “balelas” de riscos, escopo, tempo e custo, não precisam ser considerados, já sei o que precisa fazer, não temos pressa e risco não tem, pois conheço tudo e confio muito no meu trabalho. Quanto à qualidade, ficará excelente, o programa vai ficar muito bom!

Durante meu dia-a-dia, vou escrevendo o código e testando, não precisa outra pessoa para fazer isso, afinal o grande teste será do nosso usuário. Quando terminar de fazer tudo e passar para o usuário, ele me passa se tiver algum problema e a gente vai arrumando tudo do jeito que o usuário quiser e desta forma vamos mantendo e arrumando o que for necessário, afinal não tem fim, por isso que não gosto de projetos, ou ter que ficar justificando meu trabalho para alguém que nem mesmo sabe programar.

FIM.

Depois desta breve estória de nosso programador egocêntrico, o que mais gostaria é que ninguém estivesse identificando esse personagem em sua equipe. Infelizmente não é bem esta a realidade de algumas empresas, na qual o EGO vale mais que os procedimentos e o profissionalismo, onde a exceção sempre vira regra.

A falta de pensamento sistêmico e visão estratégica fazem com que todas as técnicas e práticas do mercado vazem pelo “ralo” juntamente com a verba da empresa, porém, estas são “coisas” matérias que podem ser recuperadas, a pior perda é o conhecimento, capacidade e autonomia de profissionais preparados em detrimento de pessoas com o pensamento e comportamento do nosso programador egocêntrico.

Existem casos em que o falta de visão estratégica do cliente atrapalha muito os negócios e fazem com que o insucesso seja um companheiro quase que constante.

Quem faz parte de um grupo de “cabeças pensantes” tem que batalhar contra a falta de visão estratégica e mudar este cenário, caso não veja sucesso em suas investidas, chegou a hora de “startar” o projeto “vazari” (recolocação no mercado). Não fique vivendo muito tempo neste tipo de ambiente falido.

Tão comum quanto o estereótipo do programador egocêntrico nas equipes, encontramos profissionais desmotivados e fadados a serem considerados “meia-boca” porque seguem os procedimentos de mercado e não de amadores. Ocorre uma inversão de valores, onde o “certo está errado e o errado esta certo!”.

Não somos profissionais para fazer o que achamos certo ou errado, baseado em gostos pessoais, mas sim para fazer o certo, seguindo fluxos, hierarquia, regras, boas práticas e etc.

O conteúdo deste artigo pode causar diversos sentimentos, mas, por favor, não confundam firmeza com agressividade.

Sigam-me no twitter @malbertoti

Atualmente, é normal os gerentes, clientes, analistas, e etc…, envolverem e cobrarem os desenvolvedores por prazos cada vez menores e qualidade cada vez maior. Como consequência estamos ficando cada vez mais longe da combinação perfeita de prazo e qualidade. Para obter um resultado mais coerente, os envolvidos no projeto deveriam definir algumas diretrizes, um bom exemplo é o alinhamento dos usuários com os analistas e desenvolvedores. Existe um mito que o usuário não precisa conhecer algumas funcionalidades tecnicamente, mas temos que traduzir e explicar a complexidade de desenvolver determinadas funcionalidades e regras dentro do ambiente de desenvolvimento. Quando começarmos a mostrar a nossa realidade irão entender a complexidade do nosso trabalho e começarão a solicitar funcionalidades mais coerentes com o que podemos entregar efetivamente.

Os gerentes e líderes, por não conseguirem uma boa equação sobre Prazo x Qualidade e por falta de conhecimento técnico (alguns casos), acabam aceitando os prazos solicitados pelos usuários. Neste caso fica nítido que se houvesse comunicação entre os envolvidos, seria solucionado o problema do prazo. Quando envolvemos todos na obtenção de um resultado comum o comprometimento é maior, devido o sucesso ou fracasso do trabalho ter a assinatura de todos. Gerentes e analistas devem focar seus esforços em serem intermediários entre o cliente e o desenvolvedor, para retirar eventuais dúvidas durante o processo de desenvolvimento.

Nos projetos de TI estão envolvidos muitos profissionais da área de negócio e este apoio nos permitirá uma maturidade cada vez maior, além de ter um profissional que conhece e tem o papel de tradutor da área de negócio com a área técnica. Não temos ainda uma determinação de prazo perfeita, pois software tem seu funcionamento e comportamento diferente a cada dia, mas para ajudar o desenvolvedor na obtenção de melhores resultados e conseguir medir de uma forma mais precisa o seu esforço (devemos sempre acreditar que todos estão envolvidos e comprometidos com o projeto) e com isto os analistas e gerentes conseguirem cada vez mais conhecerem a velocidade de desenvolvimento da sua equipe e, consequentemente, poderão informar ao usuário que o prazo não será atendido (a partir daqui incluão o desenvolvedor na conversa), segue algumas diretrizes para serem seguidas e que ajudarão muito:

1. Definir a arquitetura de desenvolvimento de modo que possibilite ao desenvolvedor não ter a preocupação com validação de campos e controles de tela;
2. Criar ambiente de desenvolvimento igual ao ambiente de produção;
3. Não criar um ambiente de terrorismo aos envolvidos no projeto, onde devemos encarar que a mudança faz parte do negócio e irá comprometer o prazo;
4. Alinhar a solicitação do cliente com o que realmente o desenvolvimento possa atender;
5. Ter o usuário como aliado;
6. Equipe do projeto deve trabalhar de forma alinhada;
7. Possibilitar ao desenvolvedor um ambiente em que ele tenha autonomia para discutir e gerar código de maneira criativa;
8. Possibilitar contato direto entre analistas, desenvolvedores e usuário;
9. Promover reuniões periódicas, afim de, apresentar aos envolvidos quais funcionalidades foram realizadas;
10. Valorizar o trabalho em grupo e a troca de informações.

Com a definição de uma arquitetura adequada e a possibilidade de maior interação entre os envolvidos no projeto, teremos uma equipe melhor alinhada e a cada projeto o prazo será mais fácil de ser medido.

Sigam-me no twitter: @ric_agostinho

Não se assustem, em pleno ano de 2011 não é difícil escutar frases como estas que chegam a chocar de tão absurdas e descabidas.

Vamos aos fatos, em uma conhecida frase de Abraham Lincoln ele disse: “Se tivesse oito horas para derrubar uma árvore, passaria seis afiando meu machado.”

Ao contrário do que possa estar pensando, este exemplo adéqua-se perfeitamente com nossa realidade.

Na engenharia civil, constroem-se casas, prédios, etc. Algo palpável, tangível e real, na engenharia de software o que produzimos também é real, mas é abstrato, e principalmente, nosso software é um produto exclusivo e com particularidades, “não construímos o mesmo projeto de software várias vezes”. Isto nos traz algumas dificuldades que outras áreas de engenharia não sofrem.

A falta de importância dada ao planejamento é uma delas, como o produto é abstrato e depende dos anseios e necessidades de nosso cliente, planejar atividades é um desafio que precisa ser encarado e vencido, caso contrário, o projeto estará muito provavelmente fadado ao insucesso.

O Guia de Conhecimento em Gerenciamento de Projetos (PMBOK) 4º edição, baseia-se em nove áreas de conhecimento que contemplam a Gestão do Projeto, praticamnte todas estas precisam passar pelo Planejamento por parte da equipe, são elas: Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicação, Aquisição, Riscos e Integração.

No cotidiano vemos algumas destas áreas são completamente esquecidas em detrimento de outras erroneamente julgadas mais importantes. A falta de especialistas com poder de abstração, concentração e entendimento para planejar também vem sendo um grande problema nas equipes. Por preguiça, falta de cobrança ou até mesmo capacidade e codições, diversos projetos são produzidos sem planejamento, eles seguem o famoso “fazejamento”, esta premissa faz com que todo e qualquer controle do projeto não funcione, pois uma vez que não planejamos, não temos como acompanhar a evolução execução do projeto, tão pouco definir metas e objetivos assertivos.

Não permita que digam que planejar não é importante ou necessário.

Afiando o machado, reduzimos tempo, custo, RH e riscos. Consequentemente aumentamos a qualidade de nossos projetos, pois nos tornamos eficazes.

Vamos criar o hábito de sempre afiar o machado.

Leia também: Planejamento – Gaste minutos para ganhar horas

Ok, vamos ao que interessa.

Muitos supervalorizam o brainstorm – o que é certo. Com ele é que conseguimos chegar na qualidade desejada de um projeto, imaginar, pensar, criar, identificar dificuldades e encontrar soluções, isso é ótimo, só que muitos erram na forma em que o fazem.

Quantas vezes você se depara com brainstorms que não passam de um bate papo sem sentindo algum, ou uma disputa de egos/poderes, ou as vezes idéias ou tentativas frustradas pela falta de maturidade na situação do momento ou até mesmo pela timidez de ter sido colocado na parede de uma hora para outra quando se tem o dever de agregar algo naquele momento.

Isso tudo é frustrante, não é mesmo? Claro, que as vezes acaba surgindo uma boa idéia, e só acontece porque alguém estava criativo ou é muito profissional naquele momento, porém e o restante, porque não ajudam, por que não desenvolvem idéias tão boas, porque não encontram soluções plausíveis, porque parece ter criado algo genérico e não diferente em sua estrutura?

A falta de organização e tempo faz com que as pessoas se amedrontem, estamos tratando de sentimentos, estamos tratando de exposição de idéias e o ser humano tem a tendência de querer ser aceito e quando está em uma situação de confronto sem preparo tende a ficar tímido na maioria das vezes, tímido porque não quer errar, não quer se expor. Para solucionar isso tenho algumas regras que sigo, tenho certeza que pode ajudar você, claro se essa é a sua situação – Reuniões de Brainstorm que não rendem o esperado.

Primeiro: Brainstorm não deve ser de longa duração, no máximo duas horas é o suficiente para uma boa equipe colocar todos os pontos nos is.

Segundo: Reúna uma equipe qualificada, não estou dizendo que não é para dar espaço para aquele rapaz do canto da sala, não, estou dizendo que esse é o momento que não pode perder tempo para fazer testes de pessoas, tem que criar idéias e ainda por cima imaginar se são possíveis de aplicá-las no projeto, uma equipe grande gera muitas idéias e normalmente uma derivada da outra, quando na verdade podia-se desenvolver essa idéia com poucas cabeças, de uma forma organizada e gastando menos tempo, o resultado é sempre muito bom, só que para isso reúna quem sabe sobre o assunto, quem é criativo, quem é proativo, quem tem qualidade e vontade para isso, vontade deve ser fator relevante, conheço muitos profissionais de conhecimento incrível só que sem vontade alguma, esses são um peso morto nas empresas. As vezes ser seletivo é uma boa característica para um gestor.

Terceiro: Brainstorm não é o momento de criar idéias, é o momento de aperfeiçoá-las, aqui é o diferencial, normalmente você ouve, lê ou assiste alguém dizendo que esse é o momento de criar, não, esse é o momento de debater idéias, chegar em um consenso e amadurecer a idéia escolhida.

Porque não se deve usar brainstorm para criar idéias do zero? Simples, porque para gerar uma idéia consistente eu não posso estar ouvindo a idéia do outro, logo, se ouvir vou estar sendo influenciado, no final teremos idéias genéricas adaptadas e não opções diferenciadas para escolher a melhor alternativa. A dica aqui é reunir sua equipe por 15 ou 30 minutos, explicar o problema, desejo ou projeto inicial e deixar que esses voltem para suas mesas, pensem, criem soluções e na data e hora marcada retornem para a mesa de reunião e ai sim entra o brainstorm, ou seja, expõem-se as idéias que são únicas e assim é possível decidir o que é válido ou descartável, escolher uma excelente idéia e após isso amadurecê-la devidamente com toda a atenção merecida.

Brainstorm é algo para ser simples, só que a tendência do ser humano é complicar as coisas para que aparentem ser algo único, só que algo único, algo especial é aquilo que em sua simplicidade é eficaz. Não perca tempo com idéias genéricas, se você perceber que as idéias pouco se diferem cancele essa reunião e defina um prazo para que todos criem idéias únicas e só assim retorne para a sala de reuniões para decidir o rumo a ser tomado.

Ao gestor cabe a capacidade de analisar, a capacidade de exigir, impor e fazer com que de forma organizada o fluxo de idéias seja utilizável e logo aplicável para o projeto, você é o maestro dessa orquestra e tudo, no final, será responsabilidade sua.

Até a próxima.

Criticas e sugestões de temas – contato@alpisconsultoria.com.br