Agora temos um CFPS Fellow no Brasil!
Em 1993, o Grupo Internacional de Usuários de Pontos de Função (IFPUG) estabeleceu a certificação de Especialista em Pontos de Função (CFPS). O exame CFPS tem sido um padrão de excelência desde então na comunidade de medição de software.
A primeira prova de certificação no Brasil foi organizada por Antônio Braga com a UNISYS Brasil e realizada em São Paulo no ano de 1996. Carlos Eduardo Vazquez, o nosso Cadu, estava entre os três profissionais aprovados naquela oportunidade.
Em 2012, o IFPUG estabeleceu que a partir de julho daquele ano os membros com mais de 20 anos de certificação contínua ganhariam a designação “CFPS Fellow“.
O objetivo da iniciativa foi o de reconhecer aquelas pessoas que demonstraram sua expertise por mais de duas décadas atuam como uma referência nas principais práticas de medição; um gesto de apreciação a sua dedicação e integridade.
Em 2015, o IFPUG concedeu a designação de IFPUG Fellow para 18 profissionais e até recentemente, havia 23 profissionais nessa lista. Isso é, até recebermos a notícia de que Cadu é o 24º profissional a fazer parte esse seleto grupo e o único IFPUG CFPS Fellow no mundo também certificado no processo de avaliação não funcional de software (SNAP).
Fizemos algumas perguntas para ele e as compartilhamos por aqui:
Entrevista
FATTO: O que levou você a se dedicar para uma certificação, que exige 90% de acerto, em uma época quando não era uma exigência no mercado?
Cadu: Eu poderia dizer que exatamente por esse motivo. Mas não foi esse o caso. Não havia exigência no mercado, porque não havia uma massa crítica de profissionais disponíveis ainda que houvesse, como hoje há, a necessidade. Três pessoas mudariam isso? Certamente, não.
Eu tive o primeiro contato com Análise de Pontos de Função em 1991. Desde então, fui gradualmente me aprofundando no assunto, porque eu não entedia a lógica por detrás das estimativas. Para mim não tinha sentido o sujeito estimar a programação de uma tela em 08 horas porque corresponde a uma Entrada Externa de 04 Pontos de Função com 02 horas / Ponto de Função.
Eu achava que era uma deficiência minha e fui me aprofundando no assunto. A certificação foi um caminho natural. No final, descobri eu estar certo e não haver ciência alguma naquela loucura.
FATTO: Mas se você descobriu que era uma loucura, porque você se manteve nessa linha ainda assim!?
Cadu: Veja, eu não disse que a Análise de Pontos de Função (APF) é uma loucura. Eu disse que a maneira como era usada naquele contexto era. Uma taxa de entrega ( HH / PF ) é uma média, uma tendência. Ela representa uma probabilidade. Algo válido para uma população pode (e geralmente é) inválido para um indivíduo dessa população. Ou seja, você usar uma métrica como a APF para estimar ou determinar metas de algo tão fino como a programação de uma tela é uma má prática. No entanto, usar a mesma lógica para planejar um portfólio, avaliar a capacidade de um departamento, estabelecer metas para um contrato ou Release é outra coisa completamente diferente.
FATTO: Cadu o que mudou da época quando você obteve o CFPS e hoje?
Cadu: Nada.
FATTO: Como assim nada!? São mais de 25 anos e a TI é extremamente dinâmica.
Cadu: Na essência as perguntas para as quais a APF provê respostas com significado são as mesmas. Eu estou desperdiçando recursos? Como esta minha produtividade e qualidade em relação ao mercado? Qual a projeção de custo ou tempo para ter uma necessidade de software atendida? Isso não mudou. Nesse âmbito do domínio do problema, o que mais mudou foi o propósito de prever o futuro para o de avaliar (preferencialmente cedo) o desempenho passado.
Na época, a mudança era a transição dos mainframes ou o desenvolvimento orientado a objetos; em seguida, o novo paradigma cliente / servidor e depois o desenvolvimento Web. A única constante na verdade é a mudança. O que varia é qual a mudança. Hoje temos os microserviços, a computação em nuvem, os assistentes com inteligência artificial, o blockchain e assim por diante.
O que permite a Análise de Pontos de Função se manter relevante há quase 50 anos é exatamente ela medir software em uma perspectiva externa dos requisitos funcionais atendidos pelo software independentemente da moda da vez.
FATTO: Há algum fator crítico de sucesso, que você queria compartilhar com a gente.
Cadu: Medir pontos de função é simples. O difícil é alinhar a medição com o propósito que a motiva. Os fundamentos da medição são os fatores críticos de sucesso. Por exemplo, dependendo de como se posiciona o escopo da medição, um mesmo desenvolvimento pode apurar 100 PF, 150 PF ou 200 PF. Qual o melhor maneira de estabelecer o escopo da medição? Depende do motivo para aquela medição; de qual comportamento você quer estimular e qual comportamento você quer evitar.
FATTO: A gente vê muita crítica ao uso de APF em contratos. Se fosse por muitos gestores públicos ela nem seria utilizada e partiriam para uma gestão de alocação. O que você pode comentar sobre isso?
Cadu: Como todo sistema, e o uso da APF em contratos é parte de algo maior, as causas de um fenômeno resultam de uma conjunção de fatores.
Primeiro, no que se refere à técnica de medição em si, eu avalio queatualmente a contagem detalhada no contexto de um contrato de preço unitário se revela um problema. Isso porque se exige um nível de informação sobre requisitos funcionais mais fino que os disponíveis e se desperdiçam recursos em discussões e resoluções de divergência, que não beneficiam o negócio e estão restritas à medição em si.
No âmbito do IFPUG, trabalha-se para a divulgação do Simple Function Point como um método de medição. Em termos práticos, É muito próximo de tirar o caráter de “contagem estimativa” para o método da contagem antecipada da NESMA e passar a considerá-la como uma medição. A simplificação da medição no sentido de não se entrar no mérito da complexidade de cada função já é uma realizada em diversas empresas públicas e privadas.
Em seguida, eu vejo um problema nos preços unitários. Em especial no âmbito da administração pública. Os preços unitários refletem uma produtividade incompatível com o ambiente no qual o desenvolvimento se insere e nas respectivas exigências. Vejo números em licitações, que só me permitem entender uma visão restrita para o escopo de atividades considerado naqueles números. Por exemplo, o cara considera, que o preço por ponto de função seja relativo a se programar e testar um desenho de solução já elaborado. E se você ler, percebe que as regras do jogo dizem diferentemente. Isso eu venho falando pelo menos desde 2011.
O que eu percebo é se culpar o termômetro, no caso a Análise de Pontos de Função, pela febre. É óbvio que em um contrato de alocação você não tem esses problemas. Afinal, em uma alocação não há uma medição de produto e a preocupação com a produtividade recai completamente no cliente; no entanto, se ninguém ver um problema, será que esse problema realmente existe?
FATTO: E para o futuro?
Cadu: Eu entendo que uma visão compartimentada de medição dissociada de outros pilares na gestão de software é algo hoje restrito demais. Eu vejo que a medição deve ser instrumental para viabilizar o nosso avanço e promover um nível de “desperdício” compatível com o que se considera razoável em termos de promover a experimentação, o feedback e o aprendizado para a entrega contínua de soluções digitais.
Por isso, a FATTO hoje se posiciona como uma plataforma de gestão de software. Para uma fábrica de software, a combinação de nossos serviços e do MESUR permite que ela se concentre no que ela chama de “desenvolvimento” e nós facilitamos a sua acomodação a um contexto com níveis mais altos de governança corporativa.
Para uma empresa usuária de serviços de desenvolvimento, fazemos o mesmo no sentido inverso. Ao invés de se ficar discutindo a rebimboca da parafuseta passamos o foco da discussão (e como consequência do progresso) para a simplificação, automação e informatização das tarefas e serviços até então exigindo o maior investimento de trabalho humano ou mesmo viabilizando novos negócios até então inviáveis ou inexistentes.
Eu coloco aqui cenários envolvendo diferentes empresas, mas nada impede que a mesma lógica se aplique a unidades de uma mesma organização.
