Quem gosta de pontos de função?

Posted on Posted in contratos, Metodologia Ágil, pontos de função, Rotéiro de Métricas SISP

Não sei se concordam comigo, mas acho que maioria dos fiscais de contratos de desenvolvimento de sistemas na administração pública não gosta de contar pontos de função (PF). Acho que nem as empresas que trabalham com o governo gostam. Muitas vezes, eu tenho que contar pontos de função aqui no TST e sempre surge uma situação estranha que me incomoda.

 

A última situação foi uma discussão sobre se um conjunto de entidades de negócio seria 1, 2 ou 3 ALIs. A resposta foi mais ou menos essa: depende da visão do usuário para essas entidades de negócio. Se elas forem muito importantes para o usuário do sistema são 3 ALIs, senão é somente 1 ALI. Ou seja, há uma boa dose de subjetividade no processo.

 

A questão é que a Análise de Pontos de Função (APF) deveria servir para termos uma relação entre funcionalidades do sistema e o esforço necessário para desenvolvê-las. Permitindo, assim, um pagamento justo à contratada pelo esforço do desenvolvimento. Entretanto, muitas vezes acontecem casos de uma rotina muito complexa, como o cálculo de uma folha de pagamento, valer poucos pontos de função – 6 PF, enquanto que um CRUD simples pode valer quase 20 PF.

 

Outro ponto que me desagrada é que a APF não agrega nenhum valor ao produto. Além disso, é uma atividade que, se feita de forma séria, tem um custo alto. Vejamos: normalmente o especialista em APF não conhece o sistema, então pelo menos duas pessoas irão participar da atividade de contagem. Outras irão validar a contagem. Teremos reuniões para negociação das diferenças até chegar ao consenso.

 

Por outro lado, no desenvolvimento ágil, usar pontos de função e pagar por iterações/sprints ou pagar por histórias de usuário pode ter um efeito contrário às práticas ágeis. Os analistas e gestores públicos podem ser levados a especificar todos os requisitos do sistema desde início para no futuro não ter que pagar pelas alterações. Se, ao invés disso, pagamos no final de releases podemos levar o contrato à uma situação financeira insustentável. Afinal, o momento de fazer um release pode variar de acordo com a necessidade do negócio.

 

Será que não existe uma forma mais barata e simples que garanta o pagamento atrelado a produtos? No II Seminário de Metodologia Ágil do SISP, a Cláudia Melo (ThoughtWorks) nos contou sobre o caso do Reino Unido onde houve um grande trabalho para refazer as formas usuais de contratações de desenvolvimento de sistemas. Será que não está na hora de revermos nossas tradicionais formas de contratar e remunerar? Ou será que o arcabouço jurídico existente e o nosso processo de remuneração atual são suficientemente bons e nós é que não estamos sabendo usá-los da melhor forma?

Vamos usar este espaço para discutir a questão? Deixe seu comentário abaixo para aprendermos juntos sobre este assunto.

9 thoughts on “Quem gosta de pontos de função?

  1. Olá Paulo,
    na verdade quando falei em releases quis dizer da entrada em produção. E normalmente quem diz que o sistema está pronto para produção é o Cliente (ou Product Owner no Scrum).
    E é isso mesmo, ciclos menores de entrega de software funcionando é um bom caminho. Tem funcionado bem no TST. A grande questão é que, neste caso, criou-se uma ideia de que pagar pelas alterações no que já está pronto é ruim.
    Abraço.

  2. Rodrigo, no encontro do SISP em 2014, propusemos uma simplificação do processo de contagem, onde seria pontuado conforme técnica estimativa da NESMA (ou FPLite – MetricViews Julho 2010). O processo consistiria em simplesmente identificar as funcionalidades e atribuir um peso que, conforme NESMA, Complexidade Baixa para Função de Dados e Média para Função de Transação. Isso diminuiria a glosagem dos validadores, aumentaria a produtividade das contagens e ainda aproximaria a Estimativa Inicial da Contagem Final.

    1. Olá Luiz Flávio,
      ainda não vi um contrato pagando pela contagem estimada. Mas isso também não quer dizer que não exista. Hoje mesmo vi uma pergunta sobre isto em uma lista de apf.
      Abraço.

  3. A questão não é gostar e sim entender. É possível fazer uma contagem de pontos de função com uma documentação bem simples, apenas para justificar o que está se pagando. O processo ágil não quer dizer que não precisa ter uma documentação, é preciso saber o que foi feito e necessita também de ter uma rastreabilidade das manutenções executadas em um software. Acho que o problema está na desorganização e falta de vontade de se fazer algo bem e que seja sustentável. O fato de pagar cada vez que o software sofre uma evolução é algo normal. É importante saber o que está pedindo para ser fabricado e não ficar mudando apenas porque não prestou atenção na hora de especificar o software. O fato de algumas funcionalidades complexas valerem pouco e outras de baixa complexidade valerem mais é devido a técnica de medição, mas no final das contas a contagem fica balanceada.

    1. Olá Antonia,
      concordo com você. Muitas vezes a mudança surge por que este é o processo natural de desenvolvimento de software. A gente constrói o software, coloca para o usuário e já surgem novas necessidades. Só temos que achar a melhor forma de remunerar o que está sendo alterado.
      Abraço.

  4. Olá Rodrigo,

    Segue meus comentários sobre alguns pontos do artigo:

    – “Ou seja, há uma boa dose de subjetividade no processo.”
    * Se os requisitos não estão maduros ou bem compreendidos, a medição é impactada sim. Porém o processo de medição não é subjetivo. A subjetividade no processo que você comenta é relativa à interpretação dos requisitos.

    – “Permitindo, assim, um pagamento justo à contratada pelo esforço do desenvolvimento. Entretanto, muitas vezes acontecem casos de uma rotina muito complexa, como o cálculo de uma folha de pagamento, valer poucos pontos de função – 6 PF, enquanto que um CRUD simples pode valer quase 20 PF.”
    * Não existe nada mais justo para o fornecedor que pagar pelas horas gastas. Este é o modelo homem-hora. Quem fiscaliza se as horas foram de fato trabalhadas? O modelo é frágil contra fraudes. Além disso é justo para o cliente pagar pela ineficiência do fornecedor? Os desvios que comenta podem ocorrer com pontos de função e com qualquer outra métrica. O modelo de negócio no qual a APF é usado tem que estar preparado para este cenário.

    – “Outro ponto que me desagrada é que a APF não agrega nenhum valor ao produto. Além disso, é uma atividade que, se feita de forma séria, tem um custo alto. Vejamos: normalmente o especialista em APF não conhece o sistema, então pelo menos duas pessoas irão participar da atividade de contagem. Outras irão validar a contagem. Teremos reuniões para negociação das diferenças até chegar ao consenso.”
    * Sim, de fato se pode trabalhar de forma muito mais simples com a APF do que muitos estão praticando por aí. O problema não é a APF, mas a complicação que se cria desnecessariamente em cima dela. Se o custo da medição extrapola 1% do custo total do desenvolvimento, há algum problema na maneira que se está trabalhando com a APF e deve-se investigar. Governos de todo mundo adoram burocracia e trabalho que não agrega valor. Se trocar APF por outra coisa, vão colocar burocracia e trabalho desnecessário em cima. Mentalidade lean é o que se deve inserir na cabeça desse povo.

    1. Olá, Guilherme,

      o pensamento Lean tem que entrar na cabeça de todos. Só temos que ganhar ao eliminar desperdícios e burocracia!

      Concordo que o homem-hora também tem seus problemas. A falta de confiança dos dois lados do contrato não permite que este modelo seja bem utilizado e causa os problemas que você relatou. Será que conseguimos um modelo melhor que APF e home-hora?

      Quando falei de subjetividade me referi mesmo em cima do software já pronto (ou parte dele pronto no final de uma sprint), que é quando faço a contagem final para pagamento. E me referi a diferenças de interpretação das normas de contagem. Não sei se você também presencia estas diferenças de interpretação.

      Abraço.

      1. Eu concordo com o Guilherme. O método é bastante objetivo, a subjetividade se dá normalmente por uma lacuna técnica no conhecimento do praticante; e a burocracia, pela minha experiência, devido principalmente ao processo falho estabelecido no TR ou pela falta de preparo dos fornecedores. Em relação à entrega de valor, separada a medida de retrabalho, é justamente o que a APF garante, visto que os recursos solicitados e entregues ao usuário são contados (ou seja, tenho blocos de software que representam novas automatizações de tarefas e serviços do usuário).

        Sobre o “pensamento enxuto”, realmente deve sempre estar presente…

  5. Gostaria de aprofundar a discussão em uma afirmação “Afinal, o momento de fazer um release pode variar de acordo com a necessidade do negócio.” … Quais são as premissas para essa afirmação? Que ao dividir os requisitos, há funcionalidades que são maiores e outras menores talvez?

    Mas se trabalhar com outra premissa? Toda quinta-feira eu vou entregar software funcionando, será que o contrato poderia ser mais flexível e poder ter entregas e retorno sustentável?

    Ou a cada 5 dias úteis vou entregar software funcionando. É trabalhar em um esquema de SLA. A equipe que eu trabalho está bem próximo de ter essa afirmação.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *