Reflexões Pt 2 - Nova Missão
Comentário que ouvi tanto no evento de Floripa quanto em Sampa:
"Há muita novidade sim, mas pouca coisa que podemos aplicar para resolver nossos problemas de hoje!".
Quando, na metade de minha palestra em Sampa, um 'meliante' (hehe) que estava numa das primeiras filas sacou o celular e começou a resolver um de seus "problemas de hoje", preferi não me intrometer. Com certeza minhas "ferramentas" não lhe seriam úteis. Não na solução daquele "problema de hoje".
Desde que decidi virar um "articulista/graffiteiro/palestrante" tento posicionar meus estudos em temas aplicáveis HOJE. O engraçado é que as peças não se encaixam facilmente no imenso quebra-cabeças que é o dia-a-dia dos coordenadores de projetos e desenvolvedores. Sinceramente: se eles esperam encontrar saladas de panacéias em congressos e eventos de TI continuarão perdidos. Mais perdidos ainda!
Mas resolvi dar alguns passos em outra direção (não diria para trás, mas é quase isso). Iniciei há 2 semanas uma série de artigos sobre "Projetos que Falham" (título provisório). Peguei os bons estudos de Watts Humphrey (CMM papa) e Frank Winters (PM papa) e estou tentando tropicalizá-los. Usando casos reais (vividos, sofridos ou testemunhados).
Como sempre ocorre, algo cruzou meu caminho (adoro coincidências). Este artigo publicado na ProjectConnections fala d'uma empresa estadunidense que é quase perfeita em seus projetos. Entrega 90% deles exatamente dentro do prazo e sem nenhum tipo de bug. Tipo de projeto? Semi-condutores. Trata-se d'um spin-off da Intel. As coincidências residem nas práticas... Coisas que falo há muito tempo (e tenho várias testemunhas!!) e nunca consegui viabilizar. Não vou esperar a conclusão de meus artigos (vão demorar) prá comentá-las. Vamos lá:
1. O maior problema de uma empresa de "projetos" é a tentação de "abraçar o mundo". Projetos de natureza distintas exigem processos de gestão e desenvolvimento consideravelmente diferentes. Por exemplo: Uma empresa de construção civil especializada em erguer prédios residenciais conseguiria entregar com sucesso (conforme especificado, no prazo e no orçamento) um projeto de parque temático? A tríade Pessoas/Processo/Tecnologia que performa legal no desenvolvimento de aplicações transacionais será bem sucedida num projeto de BI?
2. A empresa apresentada no artigo decidiu SELECIONAR SEUS PROJETOS. "No bid" (palavrão na maior parte dos prestadores de serviços tupiniquins) é uma decisão corriqueira por lá.
3. Decisão compartilhada pela equipe de Engenharia e pela equipe Comercial.
4. Que utilizam um "check-list" com 22 itens. Não há critério subjetivo. Se o projeto não passa no "teste", diz o artigo, "we ask the prospect to go elsewhere". Ninguém decide por si quando o projeto ou cliente é "bom", estratégico e outras balelas usadas prá empurrar goela abaixo baitas abacaxis.
5. Projetos "semelhantes" são desenvolvidos e gerenciados sob um mesmíssimo processo. Desnecessário dizer que a maturação e precisão vem daí. O acompanhamento dos projetos se torna cada vez mais fácil e previsível.
6. Esta é fantástica: ao invés de engatar aquele (desgastado, velho e perigosíssimo) "o cliente tem sempre razão" (no artigo, "always be right"), a empresa faz com que o cliente assuma responsabilidade em TODAS as tomadas de decisão. Com base em informações da equipe de desenvolvimento, os clientes "decide themselves whether a change in requirements is worth the impact on cost and schedule". (Sorry pelo mix de línguas - preguiça e pressa).
Taí! Com certeza tais "práticas" resultam em projetos de sucesso. O problema (tropicalizado) é: alguém se habilita? Teremos educação e maturidade suficientes prá tanto?
"Há muita novidade sim, mas pouca coisa que podemos aplicar para resolver nossos problemas de hoje!".
Quando, na metade de minha palestra em Sampa, um 'meliante' (hehe) que estava numa das primeiras filas sacou o celular e começou a resolver um de seus "problemas de hoje", preferi não me intrometer. Com certeza minhas "ferramentas" não lhe seriam úteis. Não na solução daquele "problema de hoje".
Desde que decidi virar um "articulista/graffiteiro/palestrante" tento posicionar meus estudos em temas aplicáveis HOJE. O engraçado é que as peças não se encaixam facilmente no imenso quebra-cabeças que é o dia-a-dia dos coordenadores de projetos e desenvolvedores. Sinceramente: se eles esperam encontrar saladas de panacéias em congressos e eventos de TI continuarão perdidos. Mais perdidos ainda!
Mas resolvi dar alguns passos em outra direção (não diria para trás, mas é quase isso). Iniciei há 2 semanas uma série de artigos sobre "Projetos que Falham" (título provisório). Peguei os bons estudos de Watts Humphrey (CMM papa) e Frank Winters (PM papa) e estou tentando tropicalizá-los. Usando casos reais (vividos, sofridos ou testemunhados).
Como sempre ocorre, algo cruzou meu caminho (adoro coincidências). Este artigo publicado na ProjectConnections fala d'uma empresa estadunidense que é quase perfeita em seus projetos. Entrega 90% deles exatamente dentro do prazo e sem nenhum tipo de bug. Tipo de projeto? Semi-condutores. Trata-se d'um spin-off da Intel. As coincidências residem nas práticas... Coisas que falo há muito tempo (e tenho várias testemunhas!!) e nunca consegui viabilizar. Não vou esperar a conclusão de meus artigos (vão demorar) prá comentá-las. Vamos lá:
1. O maior problema de uma empresa de "projetos" é a tentação de "abraçar o mundo". Projetos de natureza distintas exigem processos de gestão e desenvolvimento consideravelmente diferentes. Por exemplo: Uma empresa de construção civil especializada em erguer prédios residenciais conseguiria entregar com sucesso (conforme especificado, no prazo e no orçamento) um projeto de parque temático? A tríade Pessoas/Processo/Tecnologia que performa legal no desenvolvimento de aplicações transacionais será bem sucedida num projeto de BI?
2. A empresa apresentada no artigo decidiu SELECIONAR SEUS PROJETOS. "No bid" (palavrão na maior parte dos prestadores de serviços tupiniquins) é uma decisão corriqueira por lá.
3. Decisão compartilhada pela equipe de Engenharia e pela equipe Comercial.
4. Que utilizam um "check-list" com 22 itens. Não há critério subjetivo. Se o projeto não passa no "teste", diz o artigo, "we ask the prospect to go elsewhere". Ninguém decide por si quando o projeto ou cliente é "bom", estratégico e outras balelas usadas prá empurrar goela abaixo baitas abacaxis.
5. Projetos "semelhantes" são desenvolvidos e gerenciados sob um mesmíssimo processo. Desnecessário dizer que a maturação e precisão vem daí. O acompanhamento dos projetos se torna cada vez mais fácil e previsível.
6. Esta é fantástica: ao invés de engatar aquele (desgastado, velho e perigosíssimo) "o cliente tem sempre razão" (no artigo, "always be right"), a empresa faz com que o cliente assuma responsabilidade em TODAS as tomadas de decisão. Com base em informações da equipe de desenvolvimento, os clientes "decide themselves whether a change in requirements is worth the impact on cost and schedule". (Sorry pelo mix de línguas - preguiça e pressa).
Taí! Com certeza tais "práticas" resultam em projetos de sucesso. O problema (tropicalizado) é: alguém se habilita? Teremos educação e maturidade suficientes prá tanto?
quinta-feira, 2 de dezembro de 2004 |
Assine o finito
Lista completa no del.icio.us
Paulo, acho que não temos educação (no sentido de hábito mesmo) nem cultura para isso. Por coincidência, ontem um gerente de projetos palestrou aqui na empresa. E ele falava justamente disso, alteração no escopo impacta no preço, na qualidade, no prazo (e em outros fatores, se bobear). Pode parecer simplista essa idéia, mas ela é básica! O mercado de trabalho acirrado faz a gente engolir as exigências do cliente. O jeitinho brasileiro faz a gente acomodar isso e aquilo naquele projeto já inchado. A ânsia voraz de abraçar o mundo faz a gente correr e deixar coisas pra traz! Isso não é uma justificativa. É apenas um diagnóstico. Concordo totalmente que estamos errados. Ah, não se surpreenda com a falta de visão de um ou outro participante das palestras. Vai ver a mensagem realmente não era para ele... Um abraço!
Fernando, até quando falta de "cultura" será desculpa? Olha só: se um ortopedista se meter a fazer uma operação do coração d'um paciente ele vai falhar e será punido por isso. Áreas mais "maduras" já possuem um código de conduta claro e disseminado. Quantos 'bugs' mais precisaremos cometer até a "maturidade"? Até quando será permitido que uma empresa, especializada em 'body shopping', por exemplo, se meta em projetos complexos de comércio eletrônico?
Sinceramente? Acho que tal "maturação" vai ser empurrada "goela abaixo", mais cedo do q podemos imaginar.
Realmente, por isso disse que é um diagnóstico, não considero uma justificativa a falta de cultura. Eu passo por chato, caxias e outros adjetivos quando documento, detalho, falo na cara do cliente em impacto, quando ele pede aquela alteraçãozinha a mais... aí me criticam dizendo que não sei negociar, não tenho jogo de cintura. Tudo bem, talvez tenha uma forte influência de meus antepassados europeus, mas esse tipo de pragmatismo, par mim, é resposabilidade e maturidade mesmo!
Beto,
não haveria "no bid o tempo todo" se a contratada é percebida como especialista em determinado tipo de projeto. Tal percepção não afeta em nada a "forma de comprar de uma empresa", pelo contrário: Cria um relacionamento mais rico.
Utópico? Sei lá, pelo menos em alguns lugares (como o citado no post original) a coisa funciona.
[]'s
Paulo