A busca pelo método científico que proporcione resultados produtivos e qualitativos, e que possa ser utilizado similarmente a uma “receita de bolo” independentemente de cultura, tecnologia e tipo de negócios, é um ávido objetivo desejado nos últimos 15 anos.

Por trás desta busca existem os anseios mais íntimos e importantes das empresas: fazer projetos de software com lucro, com a plenitude da satisfação do cliente, com a fidelização do cliente e com crescimento técnico profissional.

Nas propostas existentes, os autores

Antes de colocar minha opinião sobre a existência do método, quero criar no meu leitor imaginário o método utilizado por Descartes – ou seja, duvide de tudo o que está escrito, particione o problema no menor pedaço possível e conceitue cada uma das partes.

Se existe esta “receita” escrita em algum lugar, quem a escreveu? Cerca de 95% dos textos que já encontrei sobre o assunto foram escritos por um dos tipos de autores dos explanados abaixo:

• Estudantes inexperientes que, como resultante dos seus próprios estudos, escrevem para a fixação dos conceitos adquiridos pelas pesquisas;

• Professores. Estes divididos em duas formas de finalidade de ensino:

– Para fins acadêmicos ou históricos: para constar em livros, apostilas, trabalhos escritos em geral. O problema desta linha temática é que há pouco compromisso com a realização prática;

– Para fins de consultoria (trabalhos consultivos): nesta linha de ensino percebe-se um compromisso maior com a tese, com o texto, com a proposta metodológica, comportamento consultivo que em diversas características assemelha-se à religião;

• Técnicos assalariados, que respeitando-se pouquíssimas exceções, têm como objetivo final alcançar alguma fama com seu texto. Percebe-se neste tipo de conhecimento escrito o registro de opiniões inflexíveis, com tendência a polêmicas em vão. Há pouco compromisso com o resultado como lucro, como satisfação do cliente, o objetivo do texto sempre é enaltecer a tecnologia e o conhecimento técnico como trampolim de imagem perante o mercado de oportunidades;

• Técnicos comprometidos com a tecnologia por imposição hierárquica, ou seja, se sou funcionário da empresa “Y” tenho o compromisso de defender as tecnologias desta empresa como forma de marketing.

Onde estão os ensinamentos dos empreendedores? Defino empreendedor neste contexto aqueles que fizeram clientes felizes e ganharam muito com isso. Aqueles que realizaram suas empresas como escopo econômico. Estes empreendedores não escrevem, não falam, simplesmente fazem. De fato constata-se que na maior parte das vezes estudamos teorias escritas e formuladas por inexperientes ou assalariados, quando o meio de pesquisa foi a Internet, ou por professores quando o meio de pesquisa foram os livros.

Nas propostas existentes, a metodologia formalizada

Costumo defender em oportunidades públicas que qualquer metodologia aplicada na sua empresa terá um efeito organizador. Nesta tese exemplifico com a observação do relacionamento entre uma criança e um adulto. Coloca-se uma criança, em torno de 7 anos ou menos, e um adulto com mais de 25 anos no mesmo ambiente por um tempo determinado. O resultado desta experiência é que a criança terá adquirido características comportamentais deste adulto, desde hábitos alimentares até a forma de falar, vestir e etc.

Nesta experiência podemos concluir que o organizado, o formalizado, o estruturado, tende a prevalecer sobre o desorganizado (na experiência representado pela criança). Assim funcionará qualquer metodologia minimamente séria dentro de uma empresa de software.

Quando uma metolodologia de desenvolvimento de software não traz nenhuma mudança em sua empresa, tipicamente temos as seguintes causas:

• O conjunto de pessoas que são o corpo da empresa não entende que precisa de mudanças: isso ocorre frequentemente pois não há uma comunicação transparente sobre os problemas existentes e não se compreende quais serão os benefícios com o novo método. Sem ganho, nada é substituído, apesar de parecer ser;

• Desacordo entre iniciativas comerciais e questões técnicas: os técnicos, donos do conhecimento fabril que os privilegia na relação de escopo funcional da empresa, não estão preocupados com as questões comerciais. “Isso é problema para os vendedores, meu problema é entregar os projetos com tecnologia de ponta”, costuma pensar o técnico. Com esta semântica, não aceitam propostas metodológicas que emitem certificados (CMMi, ISO e etc), pois questionam a necessidade do método e não consideram o que o certificado pode trazer de posicionamento de mercado ou vantagem competitiva comercial;

• Direção executiva: questões como visão, missão e valores da empresa, quando confusas ou desconhecidas pelo corpo da empresa, geram uma espécie de “Torre de Babel”. Sem unidade de ação, cada um segue suas próprias convicções e qualquer proposta metodológica irá falhar.

As metodologias que funcionam são as que escapam das causas de insucesso explanadas. Seja ágil, tradicional ou de certificado, funcionará quando fiel ao escopo econômico da empresa. Entende-se por funcionar, neste contexto, que irá organizar, formalizar, estruturar métodos que determinarão uma identidade de comportamento, de ação e de relação.

Nas propostas existentes, as ferramentas de automação de metodologia

É recente em nossa história a proposta de ferramentas para organizar o desenvolvimento de projetos. O termo ALM – Application Lifecycle Management – regulamenta o que uma ferramenta que se propõe a organizar uma equipe e os procedimentos para o desenvolvimento de projetos de software deve ter.

Todos os principais fornecedores do mercado de informática possuem uma ferramenta de ALM – Microsoft, IBM, Borland e Computer Associates são válidos exemplos. Alguns destes fornecedores fornecem a ferramenta com uma proposta metodológica inclusa, outros com a possibilidade de se criar sua própria proposta tecnológica. Independente das características destas ferramentas, seja ferramenta “A” ou “B”, quero comentar o meu fascínio pelo resultado que obtenho na utilização da ferramenta.

Quando estudamos estruturas organizacionais para execução de projetos, verificamos que entre várias opções existe uma denominada estrutura por método. É uma proposta fantástica, necessária aos dias atuais, porém muito difícil de funcionar na totalidade. A estrutura organizacional por métodos exige uma equipe interdisciplinar, diferente do que tipicamente encontramos nos textos técnicos que orientam a indivíduos especialistas como membros da equipe do projeto. Em outras palavras, cada participante do projeto teria que conhecer o todo, ser autônomo tecnicamente nas necessidades do projeto.

Considerando que este profissional não é encontrado com facilidade, temos que colocar os “tomadores de conta de pessoas” em nossos projetos. Certamente esta incumbência será delegada ao gerente do projeto, que além de liderar, distribuir, planejar e replanejar, deverá cuidar do resultado de cada participante do projeto (podemos chamar isso de obter feedback).

Acontece que na prática se verifica que o gestor do projeto gasta tanto tempo obtendo feedbacks, que as ações de liderar e replanejar se tornam secundárias como ato diário. O preço disso é uma gigantesca necessidade de intuição do gestor do projeto, pois os feedbacks são dispendiosos de se obter, nem sempre são realistas e tendem a aumentar a complexidade do replanejamento. Em projetos em que não há a revisão constante do planejamento constatam-se resultados terríveis.

O que a ferramenta, quando corretamente configurada, nos traz é o feedback do indivíduo, verdadeiro, em tempo real. Empresas que sabem usar este tipo de ferramenta conseguem ter gestores de projetos líderes, diferenciais ao resultado do projeto, ao invés de “tomadores de contas de pessoas”.

Se sua empresa possui profissionais interdisciplinares, certamente você não precisa de ferramentas de automação de metodologia. Caso sua empresa esteja em dúvida sobre esta afirmativa, eu recomendo uma ferramenta como facilitadora da implantação da metodologia ideal.

A metodologia ideal

Definir uma metodologia ideal seria uma hipocrisia. Há uma metodologia ideal para sua empresa quando em total conformidade ao escopo econômico e a cultura de sua empresa. Certamente as características dos clientes de sua empresa também especificam a metodologia ideal.

Podemos caracterizar elementos de uma metodologia ideal. Os que caracterizarei são baseados em generalismos observados em pouco mais de duas décadas de experiência profissional. Na composição desta visão, eu me coloco como participante de todos os tipos citados de autores. Como autor, fui estudante inexperiente, técnico assalariado, professor e técnico comprometido hierarquicamente. Nos últimos cinco anos sou empreendedor. Sou também consultor de diversas empresas, no qual destaco a USP (Universidade do Estado de São Paulo) por estar em um projeto de implantação de metodolgia para departamentos de desenvolvimento e manutenção de software.

Em pontos muito simples, os elementos são:

• Escopo econômico da empresa: de nada adianta uma metodologia tecnicamente perfeita se não é possível a rentabilidade do projeto ou a comercialização do serviço;
• Escopo de satisfação do projeto: a metodologia deve ser flexível para satisfazer o cliente e rígida para manter a rentabilidade do resultado;
• Escopo técnico social: a metodologia deve priorizar, primar, propor e proporcionar o crescimento técnico profissional e pessoal dos participantes do projeto. A metodologia deve induzir o participante a tornar-se interdisciplinar, pois fazer sempre o que já se sabe não traz crescimento;
• Escopo de serviço: a metodologia deve ser transparente em seus métodos a todos e para todos. A equipe, o cliente, os investidores, os sócios devem entender, comprar e vender estes métodos como se fossem próprios. Você participa melhor das coisas em que crê primeiro.

Este artigo não finaliza o assunto, muito pelo contrário, o introduz dentro de elementos reais, válidos para qualquer tipo de empresa. A evolução deste artigo se dará no interior de cada empresa.

Para saber mais recomendamos os livros:

Psicologia da Organização por Autores Diversos – FOIL (São Paulo, 2003)

Software Engineering with Visual Studio Team System by Sam Guckenheimer

Global Outsourcing with Visual Studio Team System by Jamil Azher

Software Project Survival Guide by Steve McConnel

Rapid Development: Taming Wild Software Schedules by Steve McConnel

Agile Estimating and Planning by Mike Cohn

Agile Software Development with SCRUM by Ken Schwaber e Mike Beedle.

Agile Management for Software Engineering by David J. Anderson.

Agile Project Management by Jim Highsmith

Treinamento SDLC – Software Development Life Cycle em http://www.fcamara.com.br

Sucesso em seus projetos!