Evidence-based stakeholder identification: Managing conflict and its impact on requirements prioritisation

No complex mundo da construção de software, as pessoas que mais importam são frequentemente as mais difíceis de encontrar. Esses indivíduos, conhecidos como stakeholders (partes interessadas), são os clientes, gestores e utilizadores cujas necessidades moldam o produto final. Se uma equipa perder uma pessoa fundamental, o software poderá falhar em resolver os problemas certos ou ignorar riscos críticos. Durante décadas, encontrar estas pessoas foi uma questão de intuição humana, dependendo da experiência de gestores de projeto para adivinhar quem detinha maior influência. No entanto, à medida que os projetos se tornam maiores e mais globais, adivinhar já não é suficiente. O desafio não é apenas encontrar estas pessoas, mas compreender como ponderar as suas opiniões conflitantes. Uma pessoa pode dizer que um utilizador específico é vital, enquanto outra insiste que ele é irrelevante. Quando estas visões subjetivas colidem, os métodos tradicionais muitas vezes têm dificuldade em encontrar um caminho claro, deixando as equipas sem saber quem realmente conta.

Uma equipa de investigadores da Universidade de Almería propôs uma nova forma de resolver este enigma, afastando-se dos pressentimentos e aproximando-se de uma abordagem matemática desenhada para lidar com o desacordo. O trabalho deles foca-se num conceito chamado "saliência", que é simplesmente uma medida de quão importante ou influente uma pessoa é percebida ser dentro de um grupo. No seu estudo, trataram as opiniões de diferentes pessoas como peças de evidência, tal como um júri que pondera testemunhos. Utilizaram um quadro conhecido como teoria da evidência, um método originalmente desenvolvido para lidar com a incerteza, para combinar estas classificações subjetivas numa imagem única e clara. Os investigadores não procuraram apenas o consenso; construíram um sistema especificamente desenhado para gerir o conflito. Ao analisar o quanto os recomendadores discordavam entre si, o seu método conseguia determinar quais os stakeholders que eram genuinamente centrais para o projeto e quais eram ruído periférico.

Para testar a sua ideia, os investigadores aplicaram o seu método a um conjunto de dados do mundo real de um projeto na University College London chamado RALIC. Este projeto envolvia a fusão de sistemas de acesso à biblioteca e ao centro de fitness, e a equipa original já tinha identificado uma lista de 18 pessoas fundamentais e 28 funções. Os investigadores pegaram numa rede de recomendações onde centenas de pessoas classificaram a influência de outras numa escala de zero a dez. Eles inseriram estas classificações no seu sistema, que as converteu numa crença partilhada sobre quem mais importava. Os resultados foram impressionantes. Numa versão da rede, o seu método reduziu o conjunto inicial de potenciais stakeholders em quase 85 por cento, restringindo a lista a apenas 15 ou 19 indivíduos fundamentais, dependendo da regra matemática específica utilizada. Noutra versão, a redução foi de cerca de 70 por cento. O sistema conseguiu filtrar o ruído, identificando um grupo central que incluía pessoas que a equipa original tinha perdido, ao mesmo tempo que confirmava a importância daquelas que eles já suspeitavam.

O estudo revelou uma relação fascinante entre conflito e clareza. Os investigadores descobriram que, quando as pessoas que davam as recomendações discordavam menos, o sistema conseguia concordar com um grupo mais pequeno e preciso de stakeholders fundamentais. Inversamente, quando a rede estava repleta de alto conflito, o sistema tornava-se mais cauteloso, identificando um grupo ligeiramente maior para garantir que nada de vital fosse perdido. Este comportamento sugere que o nível de desacordo dentro de uma equipa é, em si mesmo, um sinal útil. Os investigadores também descobriram que a forma como as pessoas expressam as suas preferências importa imenso. Eles testaram três formas diferentes de recolher contributos: classificar itens por ordem, atribuir uma pontuação ou distribuir um número fixo de pontos. Descobriram que estes diferentes métodos produziam resultados significativamente distintos. Por exemplo, numa rede com alto conflito, mudar de um sistema de classificação para um sistema de pontuação alterou completamente quais os requisitos considerados mais importantes.

Talvez a descoberta mais significativa tenha sido que o grupo específico de pessoas escolhido para fornecer contributos alterou o resultado das prioridades do projeto. Quando os investigadores compararam as prioridades definidas pela totalidade da multidão de stakeholders contra aquelas definidas apenas pelos stakeholders "chave" identificados pelo seu método, os resultados foram frequentemente estatisticamente diferentes. Isto significa que confiar nas opiniões de todos pode levar a um conjunto de objetivos diferente do que confiar nas opiniões das pessoas mais influentes. Em alguns casos, a "multidão" priorizou funcionalidades que os stakeholders chave não consideravam importantes, e vice-versa. O estudo sugere que, se uma equipa não filtrar cuidadosamente a quem ouve, corre o risco de construir software que satisfaz a maioria, mas falha com os poucos que realmente impulsionam o sucesso do projeto.

Os investigadores concluíram que a sua abordagem oferece uma forma prática e automatizada de identificar as pessoas certas a ouvir, transformando um processo desordenado e subjetivo num processo estruturado e quantitativo. Eles não alegaram ter resolvido todos os problemas do desenvolvimento de software, mas demonstraram que gerir o conflito não é apenas suavizar as coisas; é usar esse conflito para refinar a lista de quem importa. Ao tratar as opiniões dos stakeholders como dados que podem ser combinados e analisados, as equipas podem ir além da intuição e tomar decisões baseadas num consenso claro. Este trabalho destaca que, na complexa teia dos projetos de software modernos, saber a quem ouvir é tão crítico quanto saber o que construir. O estudo serve como um lembrete de que o caminho para um projeto bem-sucedido começa frequentemente não com uma lista de funcionalidades, mas com uma compreensão precisa da rede humana que o sustenta.