Alow Brasil !!!

Vou tocar num assunto delicado hoje, estou trabalhando neste post há algum tempo e como estou com uma crise de insônia terrível decidi termina-lo e publicar, ok? É um post um pouco extenso, então peço sua paciência para ler até o final

A motivação para este post, nasceu de algumas conversas com amigos e com executivos de mercado, também em algumas empresas que visitei nos últimos tempos e é claro do meu dia-a-dia de trabalho. Grande parte dessa motivação veio do fato de que existem ainda muitas empresas e pessoas que vêem este formato de “fábrica” de software como a salvação dos problemas, sendo poucos os que acabam percebendo que esse modelo criado para a indústria de software somente causou desperdício de recursos financeiros desde a sua criação.

Quero deixar claro que não estou criticando as empresas chamadas de fábrica de software, certo? Até nisso existe confusão. Os atuais fornecedores de software e serviços são denominados simplesmente de “fábricas de software”, principalmente pelos próprios clientes. Claro que você já ouviu a famosa frase: “Não vamos conseguir fazer internamente este projeto, manda pra fábrica…”

Bom, posto esses parâmetros, vamos então a uma definição resumida que encontrei no wikipedia:

Fábrica de Software é um conjunto de Recursos (Humanos e Materiais), Processos e Metodologias estruturados de forma semelhante àqueles das indústrias tradicionais, utilizando as melhores práticas criadas para o processo de desenvolvimento, testes e manutenções dos softwares.

Nos anos 90, quando estávamos vivenciando o ápice do processo de downsizing nas grandes companhias, passamos por um grande problema de produção nas empresas. O mercado contava com poucos profissionais especialistas e os que tinham essa especialização estavam se tornando cada vez mais caros. Por causa de vários deste problemas, pensou-se então que a saída seria “industrializar” o setor de serviços de software.

O pensamento foi simples:

1. O maior índice de trabalho que temos está na codificação de programas;
2. então precisamos de um número altíssimo de profissionais e estes precisam ser baratos;
3. como precisam ser baratos precisamos tornar suas atividades o mais manuais possíveis e eles devem estar pouco envolvidos com questões de negócio;
4. para conseguirmos isso precisamos de modelos e processos focados em atividades e de certificações destes processos.

Ora, no século passado tivemos um problema parecido com este, como ele foi resolvido? Com a criação da linha de montagem de Ford. A idéia básica era a de que muitas pessoas, distribuídas em funções e realizando operações repetitivas conseguiriam criar um produto semi-acabado ou até mesmo acabado. Era verdade que conseguiu-se com este modelo chegar ao impressionante tempo de 98 minutos para se fabricar um carro.

Pronto, temos então a linha de raciocínio que nos levou à criação do que foi em minha humilde opinião um dos maiores erros na história do setor de serviços de TI e desenvolvimento de software: A Fábrica de Software.

Linha de montagem industrial

Imaginou-se no início que a solução então seria segregar as atividades de desenvolvimento de software em várias áreas distintas, sendo as principais:

• Análise de negócio;
• Análisa técnica / modelagem;
• Codificação dos programas;
• Testes

Pronto, com essa divisão clara de “fases” e “disciplinas” num projeto de software ficava muito mais fácil de industrializar o processo, pois poderíamos então fazer qualquer uma dessas fases com pessoas diferentes, em locais diferentes, tudo orientado por um único processo. O modelo derivado deste pensamento pode ser expresso da seguinte forma:

Processo distribuído

Para sustentar essa fantástica “linha de produção”, o mercado teve que se basear totalmente num modelo de engenharia que já era adotado na era dos mainframes, o famoso processo Waterfall, ou cascata.

Modelo tradicional baseado em cascata

O processo Waterfall foi importante para a manutenção do modelo fabril porque dá uma idéia muito parecida com uma linha de montagem e não oferece o que chamamos de retro-alimentação em seu ciclo de vida. A idéia é de cada fase seja executada de forma separada, em momentos diferentes e por profissionais diferentes, alimentando com isso a segregação dos profissionais e baseando-se exclusivamente nos processos e na documentação.

Ok! Já vimos como este modelo foi criado, certo? Agora vamos analisar um pouco como está o mercado depois de quase 2 décadas da implantação deste modelo.

Chaos Report 2009

Você já deve conhecer esse relatório, não conhece? Já falamos sobre ele em outro post. O chaos report do standish group demonstra de forma muito clara como caminha o mercado de desenvolvimento de projetos de software. O leitor pode estar se perguntando: Mas o Chaos não diz que esses resultados são causados pelo modelo de fábrica de software. Com certeza, realmente não menciona, mas menciona problemas que foram causados por este processo e principalmente pela abordagem waterfall nos projetos de software.

Outro estudo que você já deve conhecer é o de que entregamos hoje em dia apenas 20% de funcionalidades que realmente serão utilizadas pelos usuários finais dos sistemas. Podemos ver este resultado na imagem abaixo:

Uso de funcionalidades em sistemas comerciais americanos

Consigo abordar alguns pontos cruciais para afirmar que o modelo chamado de Fábrica de Software não funciona. Vamos a alguns deles:

Gera e alimenta a segregação das equipes

O fato de dividir o projeto em fases => etapas => atividades, executadas por equipes diferentes que não se comunicam ou se comunicam pouco é nocivo para um projeto de software. As pessoas das pontas, que trabalham com o desenvolvimento do projeto não possuem contato com o cliente ou usuário final pois, uma vez que as fases de análise são terminadas a documentação funcional é enviada para a “fábrica” e só tem retorno quando o software está “pronto”.

É necessariamente baseado em documentação

O processo de fábrica tem a obrigação de se basear em documentação, já que não possui comunicação fluente entre os membros da equipe e principalmente com o cliente. Cada fase executada deve conter inúmeros documentos que descrevem como o software deve ser construído. Já trabalhei em projetos com processos em que tínhamos que entregar 32 artefatos de documentação ao longo do desenvolvimento. Esse número muitas vezes representava até 70% do esforço gasto no projeto. Sabe quanto tempo gastávamos com processos de qualidade e testes? Pois é, não sobrava tempo, muito menos dinheiro…

Outro ponto é que a empresa de fábrica precisa se basear nos documentos para se proteger do processo de contratação imposto pelo modelo de escopo fechado. Se aceitar alterações durante o projeto e elas não estiverem documentadas, o fornecedor terá que pagar a conta.

A base de nosso atual processo de software

Promove uma pseudo-previsibilidade

Como medimos o andamento de um projeto de fábrica? Com a famosa coluninha de % completo do project, certo? Se o projeto é separado em fases extensas e executado num modelo distribuído de fábrica essa prática torna-se indispensável. Agora a pergunta: Como podemos dizer que um projeto andou 50% se não temos uma unica linha de código escrita? Ainda não mostramos nada ao cliente, somente protótipos e documentos de requisitos.

Mudanças naturais decorrentes de um projeto são tratadas como alteração de escopo

Como já citei no item 2 as empresas precisam se basear no tal escopo fixo para executar o projeto. Qualquer alteração que ocorra durante seu desenvolvimento deverá ser tratada como mudança de escopo e negociada (paga), a parte. Se levarmos em consideração a cultura de punição que temos hoje para quem não consegue dimensionar um projeto de software com 100% de assertividade – tanto nos fornecedores quanto nos clientes – veremos que as mudanças ficarão engavetadas, engordando as estatísticas de funcionalidades entregues e não utilizadas.

Parte do pressuposto de que o desenvolvedor é simplesmente um operário

Ora, se todas as atividades que precisam de raciocínio já foram realizadas pelos analistas de negócio, arquitetos e analistas de sistemas nas fases de levantamento e definição do projeto então não só precisaremos do cara que escreve o código. É a atividade repetitiva de que fala o modelo fabril criado por Ford.

Este talvez seja o ponto onde a fábrica se saiu pior. Com este pensamento as empresas lotaram suas “fábricas” com estagiários e profissionais Jrs, realmente acreditando que codificar é simplesmente uma atividade braçal, e que o conhecimento especialista está nas mãos dos analistas, arquitetos, etc. Este modelo gerou, inclusive, a idéia de carreira que temos no mercado hoje (trataremos disso em outro post).

Meros codificadores braçais

Com essa atitude o mercado acabou gerando desenvolvedores de software que estão condicionados a receberem uma especificação detalhada e escrever código. A verdade é que temos um número absurdo de profissionais medíocres nas empresas. Pessoalmente acho que grande parte disso se deve ao fato de que limitamos estes profissionais com um modelo onde o programador deve ser burro e não onde unimos a solução com o desenvolvimento da aplicação.

Possui foco em processos e não em pessoas

Quando pensamos em fábrica de software somos levados a acreditar que neste modelo a dependência das pessoas é menor. A verdade é que isso não passa de marketing e é uma grande mentira! Um dos sonhos vendidos pelo modelo de fábrica é que o processo é mais importante e que ele suportará a ausência de qualquer pessoa. Afinal temos tudo muito bem documentado. Ora, sempre seremos dependentes de boas pessoas num projeto de software e para isso não importa o processo. Nunca acredite numa empresa que fale o contrário!

Não permite colaboração

Isso se inicia na contratação. O cliente não quer colaborar com o fornecedor e joga em seu colo todo o risco na contratação. Podemos analisar isso claramente nos processos de RFP que temos no mercado e até já falei isso em outro post. Como o fornecedor sabe que vai ficar com todo este risco, vai basear todo o desenvolvimento do projeto em documentos para que não tenha que assumir os problemas financeiros que certamente vão acontecer.

Neste modelo não há como se ter colaboração entre cliente e fornecedor, pois não há espaço para negociação no momento de mudanças. Sabemos que um projeto de software possui mudanças e que elas devem ser acomodadas e não negociadas. Mas para isso é preciso uma postura de colaboração, que não é compatível com o modelo de fábrica de software.

E no final…

Relacionamento cliente x fornecedor

Por todos este pontos e por diversos outros que podemos citar é que acredito que o modelo de fábrica de software está falido e que rapidamente chegará ao final. Este modelo vai amadurecer e evoluir naturalmente para outros modelos mais adequados ao desenvolvimento de projetos de software. Creio que a evolução natural será para o outsourcing baseado em processos colaborativos.

Nestes modelos, os riscos são compartilhados e as decisões tomadas em conjunto: Cliente x Fornecedor. Todos entendem que é melhor uma relação de ganha x ganha.

Podemos pensar em formas diferentes e mais efetivas para se desenvolver software e criar produtos melhores para as áreas de negócio nas empresas. Este é o nosso objetivo.

Grande abraço

André Nascimento