Modelo de fábrica de software

A crítica ao modelo de fábrica de software é fortemente baseada no movimento intitulado “software craftsmanship”, que defende que o desenvolvimento de software está mais ligado a processos artesanais do que a processos industriais. Maultasch reforça argumentando que o processo de desenvolvimento de software não é fabril. Ao comparar com uma fábrica de carros, por exemplo, ele diz que esta produz milhares de unidades idênticas de um mesmo produto. O desenvolvimento de software, segundo ele, se aproxima mais ao papel do engenheiro que fez o projeto do carro, e não a fábrica que produz as unidades em série. "A única parte fabril do processo quem faz é o compilador, que é transformar o código fonte em binário. Só que isso já foi automatizado. O resto é o papel do engenheiro que criou o carro.

Nós somos aqui o laboratório de inovação de uma fábrica, e não a fábrica em si"102_.

Para contrapor o modelo de fábrica e construir algo que seria mais próximo a um “ateliê de software”, Maultasch e sua equipe tiveram que enfrentar dois principais desafios. O primeiro foi garantir que o trabalho de toda a equipe contratada fosse presencial, in loco, dentro do Ministério. Para isso bastou acrescentar essa exigência ao TR.

Já o segundo desafio foi mais complexo e partiu da reflexão de que, para o modelo proposto funcionar, era preciso garantir que a equipe contratada fosse de alta qualidade e, mais do que isso, conhecendo o perfil dos bons desenvolvedores, era preciso mantê-los motivados. Entre as ações tomadas para enfrentar este desafio, destacamos:

a) Pirâmide invertida: Conforme especificado no TR, o número de profissionais de nível pleno não pode ser superior ao número de seniores, e o número de juniores não pode ser maior do que o número de plenos. Dessa maneira, garante-se uma equipe com alto nível de experiência.

b) Pesquisa salarial e indicação de salários esperados: A partir de uma pesquisa salarial prévia, o MRE divulgou em seu TR os salários esperados para os profissionais. Isso deu um indicativo para a empresa e as obrigou a terem que justificar caso apresentassem uma tabela salarial menor. Para esses casos, o órgão também pôde fazer diligências e visitar clientes da empresa para verificar se, realmente, a empresa conseguia entregar aqueles profissionais naquele salário informado.

c) Diligência Prévia de Capacidade Técnica: cada funcionário indicado pela empresa contratada, de acordo com o TR, deve ser submetido a uma diligência para que a equipe do MRE ateste sua capacidade técnica e experiência profissional.

d) Perfil multidisciplinar: Por seguir orientação majoritariamente ágil, a metodologia do MRE não transforma funções do desenvolvimento de software (como análise de requisitos, testes etc.) em cargos. Por isso, não há cargos específicos para cada uma dessas funções (como, por exemplo, Analista de Requisitos, ou Analista de Interface). O TR explicita que toda a equipe deverá ter, de maneira conjunta, a competência necessária para executar todas as camadas incluídas no processo de desenvolvimento de software.

e) Ambiente de inovação: Preocupados com a retenção de profissionais de qualidade, o MRE também tomou algumas medidas para trabalhar a motivação da equipe. No Termo de Referência, se preocupou em colocar um cardápio de tecnologias novas dentre as que o Ministério trabalha, sabendo que os bons profissionais estão sempre interessados em aprender e trabalhar com as novidades. Além disso, durante o trabalho, Maultasch conta que os

profissionais têm bastante liberdade para sugerir e experimentar novas ferramentas e tecnologias, o que mantém profissionais de qualidade sempre motivados.

Para o processo de seleção, a equipe do MRE chegou a cogitar utilizar a licitação técnica e preço ao invés do pregão eletrônico, por temer que alguma empresa apresentasse um preço muito baixo e ganhasse o processo entregando serviço de baixa qualidade. Com a licitação técnica e preço, acreditavam que poderiam delimitar certos critérios que desencorajariam empresas a fazer isso. No entanto, em consultas aos órgãos de controle, perceberam que a modalidade do pregão, apesar de ser baseada apenas em preço, pode apresentar um termo de referência bastante detalhado, apresentando uma série de pré-requisitos objetivos, que poderiam ter efeito similar ao de uma licitação técnica e preço. Mas o principal fator de sucesso para o pregão, segundo Maultasch, foi a apresentação da pesquisa salarial. Graças a ela eles conseguiram estabelecer um patamar mínimo de qualidade dos profissionais que seriam alocados no contrato e não ficaram reféns simplesmente do menor preço.

Temos que trabalhar com a ilusão de que não estamos contratando pessoas. Estamos contratando serviços. Ou nem isso, estamos contratando Pontos de função, ou USTs. Mas, na verdade, quem entrega esses serviços são pessoas, que serão alocadas no projeto, que trabalharão presencialmente aqui conosco. E para garantir a qualidade desse serviço, temos que garantir que sejam contratados bons profissionais.103

Aqui vimos como a licitação do MRE teve grande preocupação com um aspecto da contratação normalmente deixado de lado nos processos seletivos de fábricas de software: A qualidade e a motivação dos profissionais alocados pela empresa contratada. Normalmente os gestores de TI se preocupam apenas com a quantidade de pontos de função a ser contratada, acreditando que a decisão de quais profissionais destacar para realizar as tarefas é responsabilidade unicamente da empresa e que, para ele, não faz grande diferença como ela o fará, desde que entregue o resultado previsto em contrato. Como vimos, a equipe do MRE questiona fortemente esta postura e procurou construir mecanismos formais para conseguir influenciar diretamente a seleção da equipe contratada pela empresa responsável pela realização do projeto