A jornada da medição na análise de RFP
Almoçava com o diretor de serviços internacionais de uma empresa de software brasileira em um restaurante de Brasília. O prato estava muito bom e o preparo levava um dia; por isso, necessitou o agendamento prévio. Mas apesar da alta qualidade da comida, o melhor estava na troca de informações sobre as diferenças culturais entre os países e os efeitos disso nos nossos negócios; em especial, como os benefícios da medição na análise de RFP (solicitação de proposta). Obviamente isso me interessou em função de nosso Centro de Orçamentos na FATTO.
Culturas na Índia e o Brasil e a análise de RFP
A diferença entre as empresas de software na Índia e as nossas brasileiras foi um tópico de especial interesse para mim. Enquanto na Índia o escopo de atividades era mais restrito e limitava-se à codificação e o seu entorno mais próximo, aqui no Brasil o nosso escopo de atividades é mais amplo.
Em nossa cultura, é comum esperar que a empresa de software tenha um conhecimento prévio do produto e do domínio do cliente; portanto não apenas da tecnologia. Por isso, espera-se dela o desenho da melhor solução a partir do refinamento da necessidade inicial em alternativas de solução. Eu vejo isso se mantendo até hoje; principalmente o mercado privado, competitivo.
Na análise de RFP, o desconhecido é um risco; alguns à toa
Considerando se fechar um negócio antes de haver requisitos de solução bem definidos e de qualidade, há um risco desconhecido relativo à incerteza sobre quais dos possíveis conjuntos de requisitos da solução será finalmente eleito como a melhor solução.
Por exemplo, promulga-se a lei 13.853 de 08 / 07 /2019 ou a Lei geral de Proteção de Dados Pessoas (LGPD). Obviamente, a mudança promovida pela força dessa lei causa impacto no portfólio de aplicações e de projetos. No entanto, diferentes são as possíveis respostas.
É possível:
- Uma estratégia de aquisição ou desenvolvimento de uma solução de anonimização genérica e configurável;
- A adequação de cada aplicação no portfólio com um conjunto específico de requisitos próprios;
- Uma solução para uma aplicação em especial, mas genérica no âmbito daquela aplicação.
E é possível qualquer combinação dessas alternativas conforme as aplicações e serviços no portfólio!
Por um lado, incerteza tem preço; ou seja, essa incerteza promove pressão no sentido de maiores preços. Por outro lado, a concorrência promove uma pressão no sentido inverso. Como avaliar o nível de risco aceitável?
Nem sempre onde se deve investir tempo é na zona de conforto
Sem dúvida existem detalhes do desenvolvimento, que são… como posso dizer… condições normais de temperatura e pressão. Portanto, não necessitam de maior desenvolvimento prévio. A chave está em diferenciar incertezas com o potencial prejudicar o negócio e, com isso, colocar foco no que importa.
Eu vejo que se desperdiça esforço analítico em aspectos técnicos, muito antes de se decidir aspectos relacionados aos requisitos da solução. Talvez, por residir nesses aspectos técnicos a zona de conforto dos desenvolvedores.
Ao aplicar a Análise de Pontos de Função parte da suíte de métodos do IFPUG; ou melhor, simplificações da Análise de Pontos de Função como o Ponto de Função Simples (Simple Function Point) ou a contagem estimativa da NESMA, você consegue colocar ênfase no desenho da solução.
Com isso, você consegue minimizar os riscos de escopo. Isso é importante, porque os riscos de escopo podem prejudicar pontualmente a proposta técnica ou pior: O seu relacionamento com o seu cliente e a confiança que ele deposita em você!
Muito aquém da medição (o que se consegue ANTES de um número)
Ao medir ou tentar medir uma Solicitação de Proposta Técnica (RFP), você descobre o seu grau de exposição aos riscos de escopo. As regras para identificar os componentes funcionais básicos da medição, as funcionalidades, ajudam a avaliar se os requisitos estão em um nível adequado para descrever a solução. E essas regras fazem isso de uma maneira padrão.
Ao medir, algumas decisões-chave devem ser, ao menos, assumidas como premissas e; portanto, passíveis de gerenciamento uma vez conhecidas.
Por exemplo:
- Determinado conjunto de dados deve ser mantido pela solução proposta ou ele deve ser obtido a partir de dados já existentes?
- Determinado comportamento deve ser tratado como um requisito funcional ou não e; portanto, será atendido por algum elemento arquitetural?
- Ainda que eu não saiba quais, pelo menos quantos são esses “relatórios gerenciais”?
- Ainda que eu não saiba quais, pelo menos quantos são esses “todos os sistemas”
04 benefícios da medição na análise de RFP
Ou seja, ao medir ou tentar se medir, você:
- Faz uma análise crítica do quanto você sabe sobre os requisitos da solução;
- Descobre lacunas em informações críticas, permitindo sua exploração;
- Identifica a necessidade por premissas e as decide assumir de maneira consciente e com viabilizando as respostas adequadas à gestão de risco correspondente;
- Estabelece naturalmente o racional com a estrutura analítica de produto descrevendo o escopo da solução em termos não técnicos e permitindo compartilhar com o seu cliente a sua visão de melhor solução sem entrar em detalhes técnicos.
Conclusão
Observe eu em nenhum momento até aqui ter entrado no mérito do resultado numérico da medição ao quantificar o escopo. Muito antes de ter esse resultado, o processo de medição simples já produz resultados que, se não superam, equivalem ao produto fina da medição. É como diz aquela expressão já clássica dos livros de auto-ajuda: A jornada é mais importante do que o destino.
