O estudo em si tem como objetivo identificar a extensão da adoção do ITIL e os benefícios colhidos com a sua utilização. Ele analisa diversos outros estudos publicados por instituições independentes, por fornecedores de ferramentas de ITSM ou por consultorias especializadas em ITIL. Naturalmente, como ocorre a qualquer estudo, ele tem suas limitações; que foram inclusive apontadas pelo autor. Mas a despeito destas, ele possui um ponto positivo em destaque que é a utilização de uma metodologia consistente para análise dos objetos estudados.

A respeito dos resultados, acho importante destacar algumas conclusões:

1. Ainda não existe um consenso entre os praticantes, consultores e fornecedores a respeito do que seria “adotar ITIL”. Cada grupo ou região interpreta a adoção da biblioteca como algo diferente;
2. Segundo o estudo, entre 30% a 80% das organizações estudadas utilizam ITIL. É uma variação muito grande que reflete  a falta de consistência entre os estudos realizados;
3. De acordo com o ranking realizado pelo estudo, os benefícios da adoção do framework são: maior satisfação dos clientes, controle de custos e melhoria no tempo de resposta;
4. Alguns estudos analisados demonstraram a relação entre os resultados obtidos e a maturidade dos processos existentes, confirmando uma opinião apresentada aqui no blog;
5. Dos 23 estudos analisados, somente 1 apresentou informações consistentes sobre a adoção do CMBD/CMS. E as informações apresentadas  dão conta de que menos de 10% das organizações os utilizam com a extensão pregada pela biblioteca.

Minha análise, que é compatível com minha percepção do dia a dia, é que o framework ITIL ainda não conseguiu atingir o platô de produtividade. Se uma das principais vantagens assessórias do uso da biblioteca é a criação de um vocabulário comum, como explicar a falta de consenso a respeito do que seria “adotar ITIL”? E o índice de utilização entre 30% e 80% encontrado nos estudos analisados? Como interpretar o limite inferior do intervalo sabendo que o tipo de estudo analisado tem, como identificado pelo autor, um viés pró-ITIL?

Eu confesso que minha visão é um pouco pessimista. Defeito de fabricação. Mas que o estudo dá voz a alguns grilos ninguém pode discordar. Ou pode?

Retomando o assunto do post, um dos principais fatores de sucesso de todas as iniciativas de TI é o apoio da alta direção. Este é um princípio defendido pela maioria dos gestores de TI e pela quase totalidade dos corpos de conhecimento e frameworks publicados. Isto até o momento em que as iniciativas começam a falhar. Nestas situações, muitas são as vezes em que a falta de apoio da alta direção é a justificativa principal para as falhas do projeto. Mas como defendido por Mintzberg em sua já referenciada obra: Se com o apoio e patrocínio da alta direção tudo correrá bem, é necessário perguntar: bem para quem?

Considerando que a alta direção é composta pelas pessoas que possuem o mandato legítimo para escolher o que é melhor para a organização, uma iniciativa de TI que não contar com o seu apoio não obterá sucesso simplesmente porque na análise comparativa entre as iniciativas que podem ser conduzidas, ela foi classificada como de menor importância. Se a equipe de gestão de TI considera de boa fé que o projeto proposto é de grande relevância e mesmo assim não encontra respaldo na alta direção, o que existe é unicamente um desalinhamento de objetivos entre as duas esferas de decisão. E neste caso, as opiniões da alta direção têm precedência sobre as opiniões da equipe de gestão de TI.

Uma das possíveis fontes deste desalinhamento pode ser a discrepância entre os conhecimentos de TI existentes entre a alta direção e a equipe de Gestão de TI. E esta discrepância é esperada, visto que a especialidade da equipe de Gestão de TI é supostamente diferente da especialidade da alta direção. Mas se é este o caso, cabem aos gestores de TI dois caminhos: educar a alta direção a respeito da TI ou traduzir os custos e benefícios da TI em termos de custos e benefícios de negócio. O caminho indicado vai depender exclusivamente das características da alta direção da organização específica. Se for uma alta direção voltada ao controle, fornecer-lhes mais conhecimentos de TI servirá para proporcionar mais segurança e visibilidade a respeito das decisões tomadas. Se por outro lado a alta direção for mais voltada a resultados, é bem possível que os detalhes a respeito da TI não sejam do seu interesse. Neste caso, traduzir da forma mais fiel possível os custos e benefícios da TI em termos de custos e benefícios de negócio é o caminho mais adequado.

Outra fonte possível para o desalinhamento de objetivos entre as duas esferas de decisão pode ser a discrepância entre as agendas. Enquanto a alta direção se orienta para determinadas vantagens estratégicas (usando o termo na forma adotada por Michael Porter nos seus livros Estratégia Competitiva e Vantagem Competitiva) as iniciativas de TI podem ser propostas com orientações distintas. Um caso clássico é a proposição da adoção de iniciativas de TI orientadas a melhorar a experiência do cliente em mercados de massa ou mesmo mercados de commodities. Se o projeto proposto pela equipe de gestão de TI está orientado a consolidar diferentes sistemas com o mesmo propósito de forma a viabilizar uma redução de custos, ele pode ter dificuldade em encontrar apoio da alta direção se a diretiva estratégica é adentrar novos mercados ou melhorar o seu posicionamento em determinado segmento. Não que uma redução de custos não seja desejada; mas um projeto com este objetivo pode ter que disputar atenção e recursos com outros projetos mais alinhados com as preocupações estratégicas atuais.

Tentando resumir o argumento: Eu acredito que a falta de apoio da alta direção não possa ser usada em nenhuma situação como justificativa para o insucesso de uma iniciativa de TI, ou de outra qualquer natureza. Se um projeto de TI não obteve o apoio da alta direção isto ocorreu por uma ou mais de três razões:

1. A alta direção não entendeu o que o projeto significava;
2. O julgamento da relação entre os custos e benefícios do projeto não foi vantajoso;
3. Os benefícios do projeto não estavam alinhados com os benefícios perseguidos pela alta direção.

Em qualquer um destes casos, a responsabilidade pelo insucesso do projeto deve ser creditada exclusivamente na equipe de gestão de TI da organização que não se preocupou em: explicar de forma clara o significado do projeto; traduzir da forma mais real possível os custos e benefícios de TI em custos e benefícios de negócio e; alinhar a agenda da TI com a agenda da alta direção em termos de vantagem competitiva.

Todas estas ações devem ser constantemente perseguidas pela equipe de gestão de TI da organização, pois elas serão suficientes para garantir que o diálogo com a alta direção seja transparente e o seu apoio seja conquistado, sempre que merecido.

Ainda bem que temos os “consultores” para nos dizer qual a nova moda e o que está errado nas nossas organizações, a despeito de elas estarem ganhando dinheiro e obtendo sucesso.

Antes de qualquer coisa, é importante esclarecermos quem compõe o grupo recorrentemente chamado de alta direção. Em empresas de capital fechado, a alta direção é composta normalmente pelas pessoas que são proprietárias do dinheiro investido na empresa. São os donos e donas da empresa ou mesmo as pessoas escolhidas por estes e que contam com a sua confiança. Em empresas de capital aberto, a alta direção é composta pelas pessoas que foram eleitas para administrá-la pelos proprietários e proprietárias da empresa, os seus acionistas. Em ambos os casos, estas pessoas são as responsáveis pela tomada das principais decisões da empresa e são também quem, em última instância, responde pelo sucesso ou pelo insucesso das organizações. A estas pessoas é dado o direito de escolher como os recursos da organização serão investidos e desinvestidos. A elas cabe escolher se um projeto é crítico, necessário ou descartável.

Um primeiro equívoco comum dos líderes de projeto, gerentes médios e consultores é o que considera que os componentes da alta direção deveriam ser pessoas com boa formação acadêmica, bem capacitadas e conhecedoras das mais modernas técnicas e metodologias. Embora estas qualidades sejam altamente desejáveis, elas não são a característica fundamental para uma pessoa da alta direção. A qualidade fundamental e que determina a escolha de quem participará da alta direção é a confiança. Entre escolher entre uma pessoa capacitada em quem não se pode confiar e uma pessoa menos capacitada de alta confiança, os donos do capital investido sempre optam pela segunda opção. Em alguns casos extremos, os donos do capital sequer conseguem confiar em qualquer pessoa de fora do seu círculo familiar, colocando então os filhos, irmãos e parentes para exercer as posições principais na empresa, não importando a sua qualificação profissional. E são estas pessoas que possuem o direito legal e estatutário de tomar as decisões a respeito de como os recursos da organização devem ou não ser investidos.

Obviamente já existem mecanismos que possibilitam aos donos do capital fiscalizar de forma eficiente as pessoas que foram escolhidas para administrar a sua empresa e o seu patrimônio. Conselhos fiscais, conselhos de administração, conselhos de remuneração, controles de governança e auditorias externas são alguns exemplos. Mas infelizmente, ainda não são todos os que acreditam na eficiência destes mecanismos. Principalmente quando as páginas das revistas de negócio e dos jornais diários trazem os escândalos que se originam em alguma falha destes mecanismos, sendo o exemplo mais recente nesta data a quebra do Banco Panamericano.

Voltando agora à nossa discussão original, é importante que gestores de projeto, consultores, analistas de processo e de formal geral todos envolvidos em iniciativas que dependem do “apoio da alta direção” entendam as características deste grupo. Os seus componentes podem não possuir o conhecimento acadêmico, o conhecimento das técnicas e ferramentas de gestão e até mesmo podem não possuir a postura adequada para a direção de uma empresa – diga-se de passagem que esta não é a maioria dos casos – mas eles contam com uma característica muito mais relevante: eles são os donos do dinheiro investido ou contam com a confiança destes. São estas as pessoas que em última instância responderão pelo sucesso ou pelo insucesso da organização. E elas tomam as suas decisões com base em um conjunto de motivações políticas, familiares, econômicas e de gestão.

Se um projeto ou iniciativa falhou e a primeira razão que vem em mente é a falta de “apoio da alta direção”, os gestores de projeto, consultores e analistas devem ter a maturidade para reconhecer que a falha na verdade foi outra. Nestes casos normalmente o que falhou foi o planejamento do projeto ou da iniciativa, que desconsiderou as características, as limitações e as motivações da alta direção. Estas restrições são condições dadas do ambiente e que devem ser analisadas, avaliadas e incorporadas ao planejamento. Afinal de contas, a “alta direção” é quem paga pelos projetos e é sempre a maior interessada em seus resultados.

Antes de chegar a estas respostas, vamos trazer algumas teorias para embasar a discussão. Segundo as modernas práticas de recursos humanos cada atividade, cargo ou papel possui um conjunto de competências associadas. A qualidade da execução de uma atividade ou do desempenho de determinado profissional no cargo está diretamente relacionada ao nível da competência associada que este profissional em específico possui. Um gerente de projetos, por exemplo, para obter sucesso em seus projetos deve contar com um conjunto de competências específicas para o cargo, como: gerenciamento de equipes, gerenciamento de riscos, gerenciamento de custos e outras relacionadas. Existem algumas linhas de estudo que falam até mesmo em competências da organização, que são compostas a partir das diversas competências das pessoas que fazem parte da organização. Um exemplo sempre citado de competência empresarial é a capacidade da GE de desenvolver líderes, competência também associada à Brasileira Ambev.

Mas o que são as competências? Ainda segundo as teorias de recursos humanos, competências são atributos dos profissionais (e empresas) que podem ser resumidas como “capacidade de realizar algo” (1). Um profissional que exerce uma função de comprador em determinada organização deve possuir a competência de negociação de contratos se o ambiente da organização suportar este tipo de atividade. Diante desta definição já nos salta um aspecto importante. Existem níveis diferentes de uma mesma competência. Dois profissionais podem possuir a mesma competência de negociação de contratos sendo que um destes profissionais é mais experiente que o outro.

Mas o ponto principal e mais relevante para a nossa discussão não é a diferença de competências entre dois indivíduos. A questão mais importante se relaciona às dimensões da competência. Usando referências acadêmicas (2) podemos dizer que as competências são compostas por três elementos: conhecimentos, habilidades e atitudes. Os conhecimentos são aquelas informações, práticas ou tecnologias que um profissional deve dominar de forma a conseguir realizar determinada atividade. As habilidades representam a capacidade que um profissional possui de aplicar os conhecimentos às situações reais. E as atitudes, também conhecidas como habilidades humanas, representam os comportamentos que um profissional deve exercer quando da aplicação de seus conhecimentos e habilidades. Todos estes três elementos devem estar presentes para podermos afirmar que um profissional possui determinada competência. A existência de um único elemento não é suficiente para garantir o sucesso do profissional na realização da atividade ou ao exercer determinada função/cargo.

Outro ponto muito relevante, ainda nos escorando na definição conceitual, é que a competência está subordinada a um contexto organizacional (3). Uma competência não existe como um atributo do indivíduo. Ela existe como atributo do indivíduo diante de uma situação específica. Ao entender as dimensões da competência (conhecimento, habilidades e atitudes) fica claro que ao menos duas destas dimensões são contextuais. Embora possamos dizer que os conhecimentos apresentam características mais universais, o mesmo não é verdade para as habilidades e atitudes. A definição de quais habilidades e atitudes são necessárias para se desempenhar uma função está diretamente relacionada à indústria de atuação, à localização geográfica, aos aspectos culturais da região e da organização em particular e até mesmo ao estilo de liderança existente. Desta forma podemos dizer que cada situação específica possui suas necessidades de competências específicas.

E aqui podemos retomar o questionamento feito no início do post. Qual o valor real de uma certificação profissional em TI? As certificações profissionais, sejam emitidas por instituições acadêmicas ou profissionais, tem como objetivo único comprovar que o indivíduo possui um conjunto determinado de conhecimentos. Mas o fato de possuir este conjunto determinado de conhecimentos não faz deste indivíduo um profissional competente na execução da atividade relacionada. A competência, como vimos, depende de outros fatores que podem ou não estar presentes em quem possui determinados conhecimentos. Um profissional com uma bagagem de conhecimento comprovada em, por exemplo, gerenciamento de serviços de TI (ITIL) não necessariamente possui a capacidade de articular estes conhecimentos e aplicá-los em uma situação específica da realidade. Ele pode também não possuir o comportamento necessário para garantir que estas práticas obtenham sucesso. Se o caso é este, o profissional com a certificação em mãos não conseguirá oferecer um aumento da eficiência da organização nas suas práticas de gerenciamento de serviços de TI.

Resumindo: certificações são relevantes. Mas elas não são tudo!

(1) http://www.mundopm.com.br/download/gestao.pdf

(2) FREITAS, Isa Aparecida. BRANDÃO, Hugo Pena. Trilhas de aprendizagem como estratégia de TD&E. In: BORGES, Jairo (Org.). Treinamento, desenvolvimento e educação em organizações e trabalho. Porto Alegre: Artmed, 2006. P. 97-112.

(3) KILIMNIK, Zélia Miranda. SANT’ANNA, Anderson de Souza. Modernidade organizacional, política de gestão de pessoas e competências profissionais. In: BORGES, Jairo (Org.). Treinamento, desenvolvimento e educação em organizações e trabalho. Porto Alegre: Artmed, 2006. P. 85-96.

Entretanto, a rápida adoção dos sistemas ERP pelas empresas veio acompanhada de inúmeros casos de insucesso. Estórias de desastres empresariais que tiveram como origem principal projetos de implementação de ERP chegaram às páginas dos jornais de negócio e posteriormente às esferas judiciais. Grandes empresas perderam muito dinheiro, sofreram danos incomensuráveis às suas reputações e, em alguns casos extremos, acabaram por encerrar suas operações. Questionamentos por parte do mercado a respeito da eficiência dos sistemas ERP foram levantados; mas a existência de inúmeros casos de sucesso demonstraram que a questão é um pouco mais complexa do que parecia.

Inegavelmente o mercado de ERP hoje se encontra mais maduro. Entretanto, os riscos relacionados à adoção deste tipo de software ainda não foram totalmente eliminados. E para conhecer um pouco a respeito dos riscos ainda existentes, é importante buscarmos entender um pouco melhor o que são os sistemas de ERP.

Vendidos como uma plataforma que integra todas as informações das organizações, os sistemas ERP são muito mais do que isto. Em verdade, a integração das informações é apenas o resultado da adoção de um conjunto estruturado de processos que é o núcleo dos sistemas ERP. Falando de forma simples, a aquisição de um sistema ERP é na verdade a aquisição de um conjunto padronizado de processos empresariais. E os projetos de implementação de sistemas ERP, se quiserem obter sucesso, devem ser planejados com esta ótica: um projeto de implementação de novos processos.

Entendendo a implementação de ERP como a implementação de novos processos conseguimos então compreender as questões adjacentes. A primeira delas é relacionada à qualidade e adequação dos processos que estão sendo adquiridos. Ao escolher uma dentre as várias opções de ERP, em última instância uma organização faz uma opção por um modelo de trabalho. A ferramenta escolhida irá determinar o funcionamento das operações da organização e, na maioria dos casos, irá determinar quais devem ser os indicadores de desempenho e as estratégias relacionadas. As empresas fabricantes de ERP naturalmente desenvolvem modelos de processos, indicadores de desempenho e direcionamentos estratégicos genéricos o suficiente para serem aplicados por quaisquer clientes potenciais. Cabe então à organização compradora determinar se este conjunto de modelos genéricos é adequado ou não à sua realidade.

Neste contexto, se uma organização possui um nível de maturidade de processos muito baixo, a aquisição de um conjunto de processos já existentes pode significar um benefício na medida em que provê um conjunto consistente de práticas gerenciais. O desafio para este tipo de organização, nestes casos, se resume então a garantir a correta utilização da ferramenta, o que representa verdadeiramente a adoção de uma visão de processos da organização. Tarefa nem um pouco simples, diga-se de passagem.

Por outro lado, se uma organização possui um nível de maturidade de processos um pouco mais elevado, a aquisição de um conjunto de processos padrão pode significar um prejuízo. Como já citado, o conjunto de processos componentes de uma solução ERP é genérico o suficiente para ser utilizado por diversos tipos de organização. Um nível mínimo de maturidade em processos significa que as partes principais da operação da organização já estão sendo controladas por meio desta abordagem. E neste caso, temos processos criados e planejados considerando-se todas as especificidades da organização. Neste contexto, trocar processos específicos para a organização por processos genéricos representaria um retrocesso.

Mas processos padrão em organizações com alta maturidade em processos nem sempre significam prejuízos. Projetos para padronização de processos entre diferentes unidades ou localidades geográficas de uma organização são a prova disto. Grandes multinacionais, por exemplo, adotam a “Estratégia ERP” para conseguir padronizar seus processos e geralmente obtém um alto grau de sucesso em termos de redução de custos nestas iniciativas. Importante dizer que: para obter sucesso, estas iniciativas devem se concentrar em padronizar processos que não sejam relevantes para diferenciação competitiva destas organizações. Do contrário, voltamos à situação onde se troca um processo com boa eficácia e menor eficiência por um processo eficiente, mas com baixa eficácia. O que no final das contas acaba sendo um desperdício de recursos e oportunidades.

Para preencher este vácuo surgiu recentemente uma obra de muita utilidade. Susan Cramm, professora da Harvard Business School e editora do blog Having IT in Your Way, publicou no primeiro semestre de 2010 um livro com o título de 8 Things We Hate About IT (8 coisas que nós odiamos na TI) onde ela discute o relacionamento entre as áreas de negócio e a TI e auxilia no seu desenvolvimento. Escrito tendo como audiência principal líderes de negócio, o livro busca explicar aos que a professora Susan Cramm denominou de IT Smart Business Leaders quais as responsabilidades e restrições da área de TI e como estes líderes podem trabalhar para auxiliar a TI atingir seus objetivos e respeitar as suas restrições, isto ao mesmo tempo em que atende às necessidades das áreas de negócio.

O livro debate oito “ódios” que são comumente explicitados pelas áreas de negócio e que, em resumo, existem por conta de objetivos conflitantes. Ao direcionar a discussão para estes conflitos de objetivos, a professora consegue explorar de forma neutra a origem destes conflitos e esclarecer em uma linguagem clara as motivações de cada área. E os méritos do livro não param por aí. Além de diagnosticar a existência destas disfunções no relacionamento entre a TI e as áreas de negócio ele também provê sugestões de como solucionar estes conflitos em direção ao que o livro denominou de Great IT.

Embora a audiência principal do livro sejam os líderes de negócio, ele também é de grande utilidade para os líderes de TI, chamados pela professora Susan Cramm de Business Smart IT Leaders. Estes líderes podem utilizar o livro como mecanismo de auxílio na compreensão das motivações dos líderes de negócio e quais as expectativas que estes possuem com relação a uma área de TI voltada ao crescimento e à inovação.

Em resumo: altamente recomendado para  líderes de negócio e para líderes de TI.

Segundo o autor, as metodologias ágeis permitem o aprendizado que é negado quando da utilização da metodologia de desenvolvimento em cascata. Durante as interações da metodologia ágil os clientes, usuários e desenvolvedores conseguem reavaliar e amadurecer os seus conhecimentos e as suas expectativas, obtendo ao final deste processo um software mais alinhado com as necessidades dos envolvidos. É difícil discordar deste argumento. Para quem já trabalhou com métodos ágeis e com o método em cascata então é impossível. Tendo então obtido tal sucesso no uso do seu argumento, repito aqui a pergunta do autor do post: “Porque é difícil convencer as pessoas a abandonarem a metodologia em cascata e abraçar uma metodologia incremental?”

Não pretendo responder esta pergunta diretamente. Principalmente porque ao me deparar com este tipo de discussão percebo que ela sempre é realizada a partir do ponto de vista errado: diferentes profissionais de desenvolvimento debatendo qual a melhor maneira de criar um software. É um debate válido, mas que desconsidera o contexto em que o processo de desenvolvimento está inserido. Considerando que o desenvolvimento de um software é apenas uma parte de um investimento da organização, o foco da discussão nas metodologias nos remete a lembrança de ambientes de chão elevado e com refrigeração no máximo, os antigos CPD’s, onde a TI se considerava independente e autônoma. Se parássemos por aí não existiria problema. Mas esta discussão, quando realizada considerando o contexto mais amplo da organização, destaca uma das maiores deficiências das metodologias ágeis.

Em uma organização madura, o desenvolvimento de um software é uma parte da resposta a um plano de negócio. E um plano de negócio é um instrumento utilizado pela alta administração, não pela área de TI; o que torna a metodologia escolhida para o desenvolvimento de software irrelevante. Quem quiser um excelente resumo sobre planos de negócio e decisões de investimento relacionadas ao desenvolvimento de software, sugiro este ótimo artigo do José Papo que também foi recomendado pelo Paulo Vasconcelos.

O plano de negócio é um guia para uma decisão de investimento. E uma decisão de investimento – qualquer tipo de investimento – avalia os recursos que serão necessários, os resultados que podem ser obtidos e analisa se a relação entre estes dois elementos é vantajosa. Outro aspecto do plano de negócio é que, para guiar as decisões de investimento, os fatores são considerados principalmente na sua dimensão financeira. A escolha da metodologia de desenvolvimento em um investimento de software, por exemplo, só é relevante no seu aspecto de custos.

E é neste ponto que as metodologias ágeis são menos vantajosas do que a metodologia em cascata. A metodologia em cascata fornece dados mais consistentes para análise de investimentos. Ela estabelece um custo esperado para desenvolvimento de todas as funcionalidades que irão suprir uma necessidade. Enquanto isto, as metodologias ágeis não se preocupam em oferecer estimativas de custo para atender um conjunto definido de necessidades. Os agilistas, arrogando-se uma posição de conhecedores das verdades, se recusam a fornecer quaisquer estimativas e adotam uma postura de “não pergunte, apenas me dê os recursos e confie”, semelhante a dos antigos chefes de CPD.

O processo de investimento de organizações maduras não suporta este tipo de abordagem. Para fins de exemplificação, imagine uma organização industrial que opte por desenvolver uma nova planta fabril. Antes de tomar esta decisão ela avaliou a sua atual capacidade de produção, a demanda futura e chegou à conclusão que um investimento para dobrar a sua produção se justificaria pelos retornos esperados. A partir desta decisão ela contrata uma empresa de engenharia e estipula o local, o tamanho, a capacidade de produção e a data de entrada em operação da nova planta. Em resposta, ela é informada que a planta será construída, mas não será possível prever a sua capacidade de produção ou mesmo o tempo em que a obra levará para ficar pronta. Ao invés disto, a empresa de engenharia vai entregar, de tempos em tempos, um pedaço da planta até que a fábrica completa esteja pronta em uma data que não pode ser prevista de antemão.

Podemos afirmar que este tipo de contratação vai garantir uma grande flexibilidade na construção da planta fabril. A organização contratante vai possuir uma capacidade quase total de alterar o projeto para atender suas necessidades ainda não identificadas. Entretanto, o objetivo da organização de ter uma planta totalmente operacional em uma data estabelecida possui grandes chances de não ser atingido. E neste caso, existe também uma grande chance da organização perder a oportunidade de mercado se um concorrente conseguir aumentar sua produção antes que todas as interações tenham sido finalizadas. Embora a organização tenha ao final uma fábrica totalmente aderente às suas mais diversas necessidades, ela falhou redondamente em obter os resultados esperados quando tomou a decisão de realizar o investimento.

Embora as metodologias ágeis tenham seu valor, um gestor de TI deve evitar fazer apostas pré-maturas na mais nova moda e abandonar práticas consolidadas apenas pelo fato de estas terem mais de dez anos. Professores e evangelizadores podem até adotar esta postura. Eles não têm responsabilidade nos resultados ou na manutenção da saúde dos relacionamentos da organização. Mas o gestor de TI deve se preocupar com a satisfação dos seus clientes e usuários e também com a capacidade da TI em responder às necessidades de investimento da alta direção de maneira profissional. E o profissionalismo da TI é julgado a partir da sua habilidade em realizar os investimentos dentro dos custos e prazos planejados, mantendo a transparência das suas decisões. Enquanto a TI não se posicionar de forma responsável e assumir compromissos com a alta direção, ela não conseguirá fazer parte das decisões mais importantes da organização.

Ps 1: Embora a redação deste post possa passar a mensagem de que eu condeno as metodologias ágeis, isto não é verdade. Eu acredito que as metodologias ágeis possuem o seu valor. Só não acredito que a sua adoção deva acontecer por meio da eliminação de outras metodologias já maduras e ainda muito úteis.

Ps 2: A minha defesa da metodologia em cascata também não significa que esta metodologia não apresenta problemas. Como bem exemplificado pelo Paulo em diversas discussões, a metodologia em cascata exige que os requisitos de um investimento sejam todos descobertos no início do processo. E esta exigência é uma fragilidade relevante porque, no caso de softwares, os requisitos estão sujeitos a alterações naturais ou mesmo a erros de interpretação por conta de sermos humanos. Mas esta deficiência não torna inválida a metodologia em cascata como o Paulo prega. Ela na verdade desperta a necessidade de criar melhores controles sobre as incertezas do investimento, controles que normalmente já estão presentes nos planos de negócio mais maduros. E aqui entra outro ponto que parte dos agilistas, do alto do seu pedestal de “quebradores de paradigmas”, ainda não conseguiram entender. O melhor controle sobre as incertezas do investimento é o verdadeiro papel de um gerente de projetos formado a partir da filosofia do PMBoK.

Ps 3: O artigo do José Papo referenciado neste post traz uma ótima abordagem de investimentos em desenvolvimento de software com ênfase na ótica econômica. Ele busca usar esta lógica para justificar a adoção de metodologias ágeis. No meu ponto de vista o argumento dele é perfeito, mas acredito que as premissas que ele utilizou para desenvolver o argumento não sejam válidas em 100% das situações. Pretendo discutir esta questão em um post futuro.