03 riscos evitáveis com cuidados em novos contratos de pontos de função
Você é uma fábrica de software ou uma agência digital e fornece soluções de TI. Surge a necessidade de trabalhar com desenvolvimento ágil em um contrato. Adicionalmente, sua remuneração, de alguma forma, depende da medição em pontos de função ou outra métrica similar; ou seja, você precisa saber sobre os cuidados em novos contratos de pontos de função.
Como fazer isso?
Você pode ter tido sucesso até aqui com as capacidades atuais de sua empresa. Mas, será que isso é suficiente para continuar a ser bem-sucedido em um ambiente com maiores exigências de governança?
Porque trata-se disso: O ponto de função surge como um meio de melhorar a governança.
Se você continuar a trabalhar da mesma forma sem uma preocupação mínima com a análise de requisitos e a produção de especificações bem-feitas ainda que se adote um desenvolvimento Ágil você se expõe a três riscos:
Qual o nosso papel na transição para novos contratos de pontos de função
O papel da FATTO é ajudar você a superar esse gap. Além do serviço de medição em si, oferecemos suporte à análise de requisitos em dois níveis.
Um primeiro nível na verificação da documentação gerada, por exemplo na análise do Jira, e no diagnóstico e orientação de seus analistas em seu aperfeiçoamento.
O segundo nível é aquele no qual a FATTO assume a responsabilidade de ela elaborar essa especificação (ou complemento à especificação) para fins de aferição a partir da análise de impacto de seus analistas.
O serviço tende a CUSTO ZERO dado o montante de recursos que se perde em função de problemas relativos a falha em se alcançar os objetivos de informação citados. Muitas vezes problemas aparentemente de baixa produtividade em pontos de função são falsos. Eles escondem, na verdade, um problema de comunicar ao cliente o efetivo escopo da mudança.
Segue um relato levemente inspirado em um de nossos novos cientes, obviamente preservando sua identidade.
Introdução
Você desenvolve em ciclos de sprints e tem esboços da interface com o usuário em wireframes como única especificação. Não há propriamente uma especificação de requisitos do usuário, como por exemplo uma lista de requisitos ou histórias de usuário, que observem algum critério de qualidade os aproximando de requisitos funcionais ou não funcionais da solução.
Anexados aos esboços, comentários cumprem o papel de descrever vários aspectos relacionados à inclusão de uma nova interface ou a mudança em uma já entregue. São comentários relativos às regras de negócio; ao comportamento dinâmico; à informação sobre elementos da interface incluídos, alterados ou excluídos; e eventualmente, às mudanças afetando também outros processos indicados de maneira genérica por qualificadores como por exemplo, “todo”, “nenhum”, “existem”, “algum”.
A sua remuneração para o desenvolvimento ágil é pela alocação de uma equipe, ainda que com um nome mais sofisticado como Squad as a Service. Ou então, você é remunerado em orçamentos de preço global fixo.
Até que surge uma mudança…
Conformidade
Às vezes, a motivação para mudança é resumida como uma necessidade por conformidade, por exemplo à Instrução Normativa 01/2021 da Secretaria de Governo Digital, cujo apelido IN04 ainda é bastante comum; ou então, o Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação. Tanto o TCU quanto o Ministério do Planejamento, Desenvolvimento e Gestão editam um guia com o mesmo nome.
Isso só para citar fontes na administração pública; e sem contar com casos de empresas com requisitos de conformidade com a SOX ou o COBIT.
Portanto, há uma necessidade por um registro claro das mudanças; o vínculo dessas mudanças com as funções incluídas, alteradas ou excluídas por elas; e a classificação do tipo de mudança. No mínimo, com o objetivo de permitir a rastreabilidade e o atendimento de auditorias no desenvolvimento.
Eficiência operacional e transparência
Mas conformidade pela conformidade, apesar de suficiente, não tende a ser uma boa resposta ao justificar uma mudança. Isso porque você não sabe o real motivo por detrás daquela conformidade. E isso é como andar às cegas.
Em cenários de alocação, não é comum haver registros estruturados das mudanças em funcionalidades. Até pode haver registros como os que citamos antes como notas anexada a um wireframe. Contudo, isso é bem diferente de um vínculo claro e objetivo daquela mudança a uma funcionalidade.
Em termos práticos, a falta desse vínculo leva ao desequilíbrio na distribuição dos riscos associados às mudanças. Todo o risco é deslocado para o cliente, enquanto acaba sendo mais cômodo para o desenvolvedor se posicionar como um codificador, ao invés de um protagonista no desenvolvimento da melhor solução.
Afinal, a remuneração do desenvolvimento não tem nexo com o volume de mudanças. Adicionalmente, não é incomum a remuneração não entrar no mérito da manutenção ser corretiva, o que acaba levando ao seu tratamento na mesma forma que uma mudança.
Portanto, não se promove um amadurecimento da gestão do desenvolvimento em ambos os lados – desenvolvedores e usuário – e fica impossível prever e medir o esforço em mudanças em funcionalidades em um projeto com desenvolvimento ágil.
Enfim, não há motivação para o aprimoramento da maturidade e competência em gestão da equipe envolvida. Por exemplo, não há o objetivo da criação de uma base histórica no desenvolvimento ágil
Consequentemente, o modelo de remuneração não busca a eficiência do processo e a transparência dos resultados esperados.
Escopo aberto e preço global fixo
Um modelo de contratação de preço global fixo, em termos gerais, poderia ser uma solução para a problemática da eficiência operacional e da transparência. Contudo, não pode no caso do desenvolvimento ágil. Basicamente, por um motivo:
– O tempo que se perderia em discussões infinitas e negociações sobre a caracterização de uma mudança e sua remuneração em um cenário de desenvolvimento com um escopo aberto.
Unidade de produto
Duas alternativas com soluções para sua implementação incluindo algum tipo de medição da produção. Primeiro, o modelo de preço unitário; no qual a remuneração é vinculada de maneira direta à quantidade de unidades entregues. E o modelo de alocação, agora vinculado a metas de produtividade e qualidade; no qual se distingue um defeito de um refinamento de requisitos no desenvolvimento ágil.
Em ambos os casos, deve-se escolher alguma unidade de produto, estabelecer metas de preço nominal para essa unidade com em R$ / unidade. Alternativamente, estabelecer uma taxa de entrega nominal como em horas técnicas / entrega de uma unidade; afinal o valor da hora pode já estar estabelecido previamente e serve como uma referência de valor.
A unidade de produto mais usada atualmente é o Ponto de Função. Seja ele usado em todo o detalhe previsto pelo IFPUG na definição do método ou alguma simplificação como a contagem estimativa da NESMA. Recentemente, o IFPUG lançou o Ponto de Função Simples, uma excelente alternativa para nossos propósitos.
Cuidados
Um objetivo, que deve estar em perspectiva na transição para medição da produção em termos representativos para o negócio, é o de minimizar o ônus na gestão advindo da utilização do processo ágil em contratações de software, tanto para a contratante (gestor de TI) quanto para a contratada. Adicionalmente, simplificar o ônus de gestão e controle de mudanças de forma a minimizar impactos sobre a agilidade do processo de desenvolvimento.
Objetivos de informação na análise de requisitos
No mínimo, a análise de requisitos deve prover informações sobre quais funções do usuário estão sendo incluídas, alteradas ou excluídas. Observe que não se tratam de telas ou botões de ações, elementos da interface com o usuário. Mas sim, a intercessão dessas interfaces com as atividades de seus usuários no fluxo de trabalho em que a aplicação se insere.
Relativo a essas funcionalidades, a análise de requisitos deve indicar o que da mudança se refere a requisitos funcionais ou não funcionais. Mudanças em requisitos funcionais são alterações em regras de negócio ou nos campos da interface lógica da aplicação com o usuário. Já mudanças relativas aos requisitos não funcionais são mudanças na organização e desenho do formulário, na estrutura de navegação do usuário ou qualquer outra mudança relativa a usabilidade ou outros requisitos não funcionais como por exemplo, desempenho, compatibilidade e confiabilidade.
Desafios
Um desafio na transição para o desenvolvimento ágil com pontos de função é o perfil do profissional. Muitas vezes um desenvolvedor, perfeitamente adequado para o cenário de alocação, não tem o conhecimento ou a formação em requisitos e gestão para organizar a informação como os objetivos descritos.
Conclusão
Ainda que você entregue produtos de qualidade, isso não é suficiente. Você precisa demonstrar sua produção de forma que se possa de maneira simples e objetiva ter essa produção quantificada e o seu desempenho (e faturamento) compatíveis com esses resultados. Afinal:
“À mulher de César não basta ser honesta, deve parecer honesta”.
