Tirar o Máximo Partido de uma Demonstração de Software

 

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe quaisquer erros ortográficos, uma vez que o sistema automático não está correcto a 100% do tempo.

Galen Low: Bem, mais uma demonstração de software de um fornecedor está a correr terrivelmente mal. O seu director de tecnologia e o responsável de DevOps parecem estar a jogar bingo de palavras-chave com todos os termos de marketing que o apresentador menciona. O seu director-geral está a perder o interesse à medida que os temas se tornam demasiado técnicos. E, apesar de a pessoa que apresenta parecer realmente dominar o assunto, ninguém parece estar a abordar o elefante na sala: o facto de essa pessoa ser, na realidade, prima do seu CEO.

Não haverá uma forma de aproveitar melhor o tempo de todos?

Se as demonstrações pouco convincentes têm sido um obstáculo à tomada de uma decisão informada sobre novo software para a sua organização, continue a ouvir.

Vamos analisar algumas das estratégias mais eficazes para tornar a fase de demonstração do processo de selecção de software muito mais relevante para as necessidades específicas da sua organização.

Olá a todos, obrigado por nos acompanharem! O meu nome é Galen Low, do Digital Project Manager. Somos uma comunidade de profissionais digitais com a missão de nos ajudarmos mutuamente a adquirir competências, confiança e ligações, para podermos elevar o valor da gestão de projectos num mundo digital. Se quiser saber mais sobre isso, visite thedigitalprojectmanager.com.

Muito bem. Hoje vamos falar sobre o processo de selecção de novo software para as suas equipas de projecto e, especificamente, sobre como ultrapassar o discurso de vendas de uma demonstração de software e garantir que a ferramenta não é apenas a melhor ferramenta, mas também a ferramenta certa para a forma como as suas equipas trabalham. Hoje tenho comigo Olivia Montgomery, Analista Principal Associada na Capterra e antiga líder do PMO de TI, que agora aconselha pequenas e médias empresas sobre a selecção de software.

Olá, Olivia!

Olivia Montgomery: Olá, Galen! Obrigada pelo convite.

Galen Low: Foi óptimo voltar a tê-la no programa. Como têm corrido as coisas em Austin?

Olivia Montgomery: As coisas estão bastante animadas. Está a decorrer o South by Southwest e voltou a realizar-se presencialmente, pela primeira vez desde 2020. Por isso, a cidade está cheia de vida e há muitos eventos, palestras e todo o tipo de actividades a decorrer. Esta semana está bastante animada.

Galen Low: Estamos de volta, estamos de volta. Estou muito entusiasmado com o South by Southwest. Está constantemente no meu feed das redes sociais e em todo o lado. Nunca fui a Austin, mas parece uma comunidade musical tão vibrante. Há tantas coisas a acontecer, tantas conferências e formas de as pessoas se reunirem e se divertirem.

Por isso, parece-me que já não tenho desculpas. Talvez este seja o ano. Talvez este seja o ano.

Olivia Montgomery: E é bastante interessante. Há definitivamente áreas dedicadas à tecnologia. Consegui assistir a palestras de líderes da cadeia de abastecimento, do CEO da Amtrak, e a John Deere está aqui a promover realmente o seu foco tecnológico. Há experiências de realidade virtual muito centradas na narração de histórias de novas formas, desde temas muito sérios e intensos até entretenimento descontraído, e sobre como podemos interagir de forma diferente com o conteúdo e uns com os outros.

Galen Low: Muito interessante. Qual foi a sua experiência favorita até agora?

Olivia Montgomery: Para além de toda a tecnologia e inovação que estamos a ver, consegui ver o novo Batmobile pessoalmente. E tenho de dizer que isso foi um dos pontos altos para mim. Sou uma grande fã de cinema. Na verdade, não vejo trailers, por isso ainda não vi nenhum. Ainda não vi o novo Batman por causa do South by Southwest, mas vi o Batmobile pessoalmente pela primeira vez. Isso foi bastante interessante.

Galen Low: Acho que isso é provavelmente melhor do que um trailer.

Olivia Montgomery: Também acho. Pensei: está bem, percebo, estou a sentir o ambiente. Agora estou mesmo entusiasmada por ver o filme.

Galen Low: É isso que espero que aconteça mais à medida que as coisas voltam a abrir, não é? Voltarmos a encontrar o inesperado, as coisas que não planeámos fazer.

Excelente. Muito bem. Vamos começar.

Vamos falar da parte mais tensa e geradora de dúvidas do processo de selecção de software, que é a demonstração. Deixe-me começar por descrever o cenário.

Imaginemos que lhe foi pedido que encontrasse uma nova ferramenta para a sua organização e que é o único decisor ou preside ao comité de selecção. Dedicou inúmeras horas a identificar casos de utilização. Recolheu requisitos junto da equipa. Definiu orçamentos com a sua liderança e fez uma grande quantidade de pesquisa online. Finalmente, chegou a um ponto em que tem uma lista restrita de ferramentas que parecem adequadas e agora quer vê-las em funcionamento.

Então, porque é que isto é tão tenso e gerador de dúvidas? Penso que é sobretudo porque esta é a concretização literal de todos os seus esforços até ao momento. Está a coordenar todas as partes interessadas. Está a tentar comunicar eficazmente todos os requisitos aos seus fornecedores de software. Está a ser-lhe pedido que absorva uma enorme quantidade de informação e reaja no momento, e tudo isto acontece no ambiente mais tenso de todos — uma reunião.

Por isso, pensei que talvez, tendo tudo isto em conta, devêssemos começar pelos argumentos dos cépticos. Uma equipa ou organização deve sequer fazer uma demonstração? Não será apenas um discurso de vendas?

Olivia Montgomery: Façam demonstrações, por favor, façam mesmo. Compreendo. Já assisti a muitas demonstrações muito centradas nas vendas. Foi a partir daí que comecei a desenvolver ideias sobre como torná-las melhores. Acredito no processo de demonstração e há muita preparação e trabalho que, especialmente o gestor de projecto, pode fazer para as tornar numa das partes mais importantes do processo de selecção.

Por isso, sim, façam demonstrações, mas elas não são tão simples como seguir a orientação do fornecedor. Penso que é aí que algumas pessoas podem cometer erros. Devem conduzir e definir essencialmente os requisitos daquilo que querem ver na demonstração.

Galen Low: Penso que isso é justo. Estas ferramentas têm muita profundidade, não é? E, em muitos casos, escolhemos uma ferramenta para fazer muitas coisas diferentes e ser muitas coisas para pessoas diferentes. Mas será sequer possível cobrir tanto terreno numa demonstração, para além de passar superficialmente pelas funcionalidades básicas de um software? Que estratégias deve uma organização considerar para garantir que obtém as respostas de que precisa?

Olivia Montgomery: Sim. Excelentes perguntas.

Em primeiro lugar, não, não é possível cobrir tudo numa demonstração de software. É aí que entra a pesquisa online anterior. E, se fizer o processo de pedido de propostas, ou quando chegar aos dois ou três fornecedores finais que está a analisar, peça-lhes que enviem toda essa informação num documento. A demonstração não é exactamente o melhor lugar para percorrer todas as funcionalidades de que precisa.

Deve concentrar-se especificamente no aspecto da interface do utilizador e em alguns casos de utilização fundamentais que a sua equipa precisa de seguir. Que processos empresariais precisam de ser suportados por esta ferramenta? E, honestamente, os utilizadores gostam do aspecto e da sensação da ferramenta? Esta pode ser a primeira vez que entram numa ferramenta e vêem a interface.

Por isso, o aspecto e a experiência de utilização serão mais importantes aqui. A lista das funcionalidades concretas deve estar escrita antes de assinar um contrato.

Galen Low: Penso que isso é muito importante. E obrigado por essa resposta, porque eu tinha apresentado isto anteriormente como uma espécie de culminar, certo? Todas as estradas conduzem à demonstração, mas, na realidade, a demonstração apenas preenche algumas lacunas.

Faz parte do processo de pesquisa. Há coisas que precisamos simplesmente de ver em funcionamento para perceber como são, como disse, a interface do utilizador e determinados casos de utilização. Não se trata de dizer: fiz toda esta pesquisa e consigo fazer todas estas coisas, vi a tabela de comparação e agora mostre-me todas as funcionalidades num período de duas horas. Isso provavelmente não correria bem.

Na realidade, é óptimo: já sabemos tudo isto, vimos tudo isto no papel e enviou-me detalhes adicionais. Agora vamos agendar uma demonstração em que possamos aprofundar algumas coisas importantes.

Olivia Montgomery: Exactamente. Na verdade, recomendo vivamente a marcação de duas demonstrações.

Gosto de uma demonstração orientada para o negócio e depois de uma demonstração técnica. Combiná-las resultaria numa reunião muito longa e complicada. Metade das partes interessadas não estaria interessada no lado técnico e a outra metade não estaria interessada no lado empresarial. Por isso, recomendo separá-las, por respeito pelo tempo das partes interessadas.

Também precisa de pessoas diferentes nessas reuniões. Não são as mesmas pessoas. Por isso, concordo plenamente que esta é uma etapa de avaliação, mas continua a ser também uma recolha de requisitos junto do fornecedor. Portanto, marque duas demonstrações — não importa se estamos a falar de uma ferramenta de gestão de projectos, de contabilidade, de um novo sistema ERP ou de qualquer outro software. Gosto de seguir mais ou menos a mesma estrutura de demonstração.

A primeira é orientada para o negócio. Tenha o responsável pelo negócio presente. Isso é provavelmente mais óbvio, mas também deve incluir o utilizador avançado. Muitas vezes é um supervisor, um responsável de equipa ou a pessoa que utiliza a ferramenta diariamente. O objectivo é garantir que está a analisar a ferramenta tanto do ponto de vista estratégico e de longo prazo como do ponto de vista prático.

O responsável pelo negócio pode decidir se a ferramenta apoiará o crescimento e o rumo da organização, mas também precisa do utilizador avançado para ver o seu caso de utilização específico. Essa pessoa precisa de saber que a função essencial que tem de desempenhar pode ser realizada e qual será o seu aspecto e funcionamento.

Por vezes, ouço gestores de projecto dizerem que nem sempre conseguem obter aprovação para incluir um utilizador avançado numa das demonstrações. Às vezes é demasiado cedo, surgem inúmeras desculpas, mas o seu utilizador avançado também vai acompanhar o resto do projecto. É provável que acabe por ser a pessoa responsável pelos testes de qualidade durante a implementação.

É a sua principal fonte de requisitos dos utilizadores. É a equipa que vai utilizar a ferramenta. Tem de ficar satisfeita com o aspecto e a experiência de utilização, que, mais uma vez, são precisamente o que a demonstração deve avaliar. Por isso, deve garantir que ambas as pessoas estão presentes nessa demonstração.

Outra forma de preparar isto é recolher casos de utilização junto da equipa, incluindo pelo menos um ou dois desse utilizador avançado, e enviá-los ao fornecedor com bastante antecedência. Idealmente, vários dias antes das demonstrações agendadas, para que o fornecedor possa configurar o sistema e apresentar exactamente esse caso de utilização. Deve conseguir dizer: enquanto contabilista, preciso de executar o relatório de fecho mensal num período de 24 horas, para poder fechar o mês contabilístico. Precisa de ver isso a acontecer na ferramenta.

Ter um caso de utilização não significa definir exactamente: quero ver esta função específica na ferramenta. Permite que talvez a ferramenta tenha encontrado uma forma inovadora de alcançar ou executar uma função que ainda não viu. Não deve limitar o fornecedor dizendo: mostre-me apenas isto. Deve manter-se aberto.

Mas, em termos gerais, o utilizador avançado precisa de conseguir ver a sua função principal. E os responsáveis pelo negócio também terão requisitos que querem ver, normalmente o painel executivo. Qual é o seu aspecto?

Como é a ferramenta quando inicio sessão como gestor, líder ou CEO? Como obtenho os meus relatórios no painel? Mais uma vez, precisa de ver o aspecto e o funcionamento dessas áreas e pedir ao fornecedor que introduza dados fictícios. Normalmente, o fornecedor irá configurar uma área de testes para a demonstração. Peça-lhe que pré-carregue alguns dados fictícios para poder avaliar a estrutura de relatórios.

Galen Low: Isso é muito interessante. Gosto muito da ideia de separar o grupo. Às vezes parece contra-intuitivo quando falamos de um processo de tomada de decisão, mas gosto da ideia de haver duas demonstrações, porque há duas conversas diferentes que precisam de acontecer sobre esta ferramenta.

Na verdade, tudo se resume a utilizar melhor o tempo das pessoas. E penso que aquilo que disse sobre, por vezes, recebermos resistência — não queremos envolver o nosso utilizador avançado da contabilidade nesta fase porque é demasiado cedo no processo — é importante. Essa pessoa faz parte da conversa para avaliar a utilização a longo prazo da ferramenta, mas também a profundidade da sua utilização.

E, francamente, trata-se de avaliar a ferramenta e transformar essa pessoa, o utilizador avançado, numa espécie de defensor do processo de selecção, porque esteve envolvida e presente. Se não estivesse, poderia ser a voz mais forte na sala a dizer que foi uma má decisão.

Gostei do que disse sobre uma área de testes. Para algumas pessoas, pelo menos nos processos de selecção de software que acompanhei, é como fazer o trabalho e depois assistir à demonstração. Ficamos sentados a observar. E depois pensamos: está bem, dêem-me um ambiente prático onde possa experimentar por mim próprio aquilo que acabou de me mostrar.

Mas haverá situações em que as pessoas experimentam a ferramenta numa área de testes durante a própria demonstração, numa demonstração prática?

Olivia Montgomery: Tenho a certeza de que os utilizadores avançados gostariam dessa oportunidade, porque uma das dificuldades é escolher a ferramenta de software adequada aos processos actuais e futuros. Por vezes, uma demonstração concentra-se apenas no estado futuro.

Às vezes, a ideia é: quando tivermos esta ferramenta, os nossos processos vão evoluir e amadurecer drasticamente, de forma automática, com toda a automatização que iremos conseguir. Mas essa não é a realidade. O utilizador avançado conseguirá perceber, desde o primeiro dia, se a ferramenta satisfaz o estado actual e também apoia o estado futuro.

Por isso, penso que entrar antecipadamente na área de testes poderia ajudar o utilizador avançado a perceber se conseguiria utilizar a ferramenta hoje e continuar a realizar o seu trabalho. Não queremos activá-la e perder todas as funcionalidades.

Não sei se as suas equipas técnicas apreciariam ou teriam tempo para fazer isso. Mais uma vez, sou uma grande defensora da transparência e da abertura. Fale com as partes interessadas e com o fornecedor sobre aquilo de que precisa e sobre as ideias que eles têm. Assim, está a ultrapassar o discurso de vendas, não permitindo que o fornecedor conduza completamente a demonstração, mas também deve reconhecer que o fornecedor conhece a solução.

Talvez tenha formas inovadoras de abordar um problema em que ainda não tinha pensado. Por isso, também deve estar aberto a isso.

Galen Low: Gosto muito disso. Vamos falar um pouco mais sobre a preparação destas demonstrações, destas duas demonstrações. Tem histórias ou exemplos sobre casos de utilização que uma equipa deva pedir para testar, de modo a garantir que o software executa aquilo de que precisa? Ou mesmo sobre o processo de recolha desses casos de utilização, como disse, sem o tornar demasiado limitador?

Não queremos dizer apenas: mostre-me esta coisa, mas permitir que, se o software abordar o caso de outra forma, a equipa possa analisar essa abordagem.

Olivia Montgomery: Sim, sem dúvida. Se tiver a sorte de contar com um analista de negócio de TI que possa recolher todos os requisitos, isso é fantástico. Mas não é comum. E, mesmo que tenha essa pessoa, o seu utilizador avançado pode nunca ter apresentado um caso de utilização ou requisitos antes e precisa de ajuda.

Uma coisa que já fiz e de que gosto é enviar um inquérito à equipa, ao utilizador avançado e aos responsáveis pelos departamentos que irão utilizar a ferramenta. Dou-lhes uma estrutura semelhante ao Mad Libs. O caso de utilização começa por: enquanto [função profissional], preciso de conseguir [acção], para poder [motivo pelo qual a acção é necessária].

É uma espécie de modelo Mad Libs e ajuda-os rapidamente a preencher os espaços. É simples e rápido para eles. Percebem o que está a acontecer. Depois, pode pegar nesse caso de utilização exacto e enviá-lo ao fornecedor, dizendo: é exactamente isto que quero ver.

Por isso, gosto desta abordagem baseada no Mad Libs.

Galen Low: Gosto muito disso. Sou um grande fã do Mad Libs e dos casos de utilização, e aqui estão os dois combinados. É uma excelente forma de olhar para a questão. Deixa a porta aberta para o fornecedor criar uma demonstração que mostre como o software irá responder ao caso, garantindo simultaneamente que a equipa consegue confirmar que a ferramenta fará aquilo de que precisa e perceber como fazê-lo. Muito interessante.

Olivia Montgomery: Ver a ferramenta e perceber que gosta do aspecto e da experiência de utilização é, mais uma vez, o principal objectivo da demonstração orientada para o negócio. Também falei de uma segunda demonstração, orientada para a área técnica. É aqui que os casos de utilização podem incluir questões como: com que frequência são executadas estas tarefas? Temos de esperar?

Podemos agendar as tarefas para a uma da manhã? Vão demorar uma hora? Isso é aceitável para o negócio? Precisamos que ocorram com maior ou menor frequência? Temos essa capacidade? É aqui que deve garantir que os responsáveis técnicos da sua equipa e do fornecedor estão presentes.

O administrador de sistemas precisa de saber como a ferramenta funciona e quem gere a arquitectura de TI precisa de saber onde os dados são armazenados. É o fornecedor que os aloja? Isso é aceitável? São alojados por si? Sabe onde? Há muitos detalhes técnicos que, se forem deixados para o momento da assinatura do contrato, podem resultar em surpresas muito desagradáveis.

Por isso, esta parte deve fazer parte do processo de avaliação. As duas equipas técnicas devem estar juntas, responder às perguntas e mostrar exactamente o aspecto da solução, discutindo as suas capacidades. Podem perguntar: isto vai exigir código personalizado? Esta funcionalidade está disponível de origem?

São perguntas que o responsável pelo negócio e o utilizador avançado provavelmente não saberão responder. E, por vezes, enquanto gestor de projecto, a menos que seja um gestor de projectos técnicos, também poderá não saber. Por isso, tem de colocar estas perguntas. Também deve perguntar sobre integrações: algum dos vossos clientes actuais tem uma integração com X e Y, as ferramentas específicas que utilizamos?

Não tenha receio de mencionar as ferramentas que utiliza e perguntar se existem integrações com elas. Para empresas maiores e mais conhecidas, isso pode parecer óbvio, mas talvez tenha de colocar perguntas mais detalhadas. No caso de empresas mais pequenas, é importante saber.

E, se não tiverem uma integração existente ou disponível de origem, isso é um factor impeditivo para si? Precisa de saber se terá de criar uma integração personalizada, se tem recursos para isso, se o fornecedor está disposto a fazê-lo e se tem tempo. Todas essas conversas podem acontecer nesta fase.

Pode parecer uma conversa demasiado extensa, mas garanto-lhe que não é, se tiver feito a preparação. As suas equipas técnicas sabem o que precisam de perguntar. Está a poupar muitos problemas futuros se não adiar esta conversa.

Galen Low: Penso que esse é um ponto fundamental. Há muito para cobrir. A conversa pode tornar-se demasiado extensa. Queremos concentrar-nos em determinados casos de utilização, mas, ainda assim, uma aplicação de software, seja um CRM, um sistema ERP ou um sistema de gestão de conteúdos, terá de fazer muitas coisas diferentes. Isso levará tempo para demonstrar e discutir.

Por isso, para evitar que a conversa se torne demasiado extensa, como selecciona e dá prioridade aos casos de utilização e às perguntas que quer que o fornecedor responda?

Olivia Montgomery: É uma pergunta muito importante. Tem de contar com os responsáveis das equipas, os líderes do negócio e o utilizador avançado. Fale com eles antes da demonstração e pergunte: quais são as suas principais preocupações? O que querem garantir que seja abordado?

Peça-lhes que indiquem o que é mais importante. Se for um gestor de projectos muito técnico, pode conduzir essas conversas, o que é óptimo, mas muitos de nós não somos. Por isso, peça-lhes ajuda: quais são as duas ou três coisas que têm mesmo de ver?

E garanta que essas questões são abordadas durante a demonstração e que se mantém no caminho certo, porque também precisa de facilitar a demonstração. Se alguém quiser aprofundar demasiado um assunto, pode dizer: queremos garantir que abordamos estes três pontos. Os fornecedores costumam ser muito bons na gestão do tempo, porque já fizeram muitas demonstrações dos seus produtos.

Mas não tenha receio de intervir e dizer: quero garantir que abordamos estes três pontos. Para que isso funcione, tem de preparar previamente as pessoas que estarão presentes e dizer-lhes quais são os três pontos. Assim, não ficam surpreendidas, não sentem que estão a ser interrompidas ou ignoradas. Sabem que esse é o caminho acordado e é mais fácil regressar ao tema sem que se sintam desconsideradas.

Galen Low: Penso que é um ponto muito importante. No papel de gestor de projecto, se está a gerir este processo, há áreas que pode controlar e pelas quais é responsável, como preparar tudo.

Mas há decisões que pertencem realmente a outras pessoas, mesmo num projecto de selecção de software. Terá um patrocinador, os decisores, a equipa de liderança, e precisamos de confiar nesse processo de decisão para que a liderança dê prioridade ao que pretende obter, especialmente numa demonstração, mantendo simultaneamente o processo de recolha de contributos das várias equipas que poderão precisar de utilizar a ferramenta.

Assim, essas pessoas preenchem o modelo Mad Libs, registam e documentam os seus casos de utilização e acabam por ter uma voz no processo.

Olivia Montgomery: Exactamente. Pode sempre lembrar às pessoas que, na demonstração, está a tentar cobrir três ou talvez quatro casos de utilização muito específicos que apresentou previamente ao fornecedor, para que este esteja preparado.

Tudo o que ultrapasse isso pode ser solicitado por escrito no pedido de propostas ou no documento equivalente. Pode dizer: precisamos de documentação sobre isto. Qual será o custo? Também deve pedir ao fornecedor, depois da demonstração, uma discriminação: isto exige código personalizado, pediu esta funcionalidade específica e este é o custo estimado. Nós construímo-la ou terá de a construir.

Actualmente, o software está a evoluir em direcção a soluções de baixo código, permitindo que um programador de front-end, um administrador de sistemas ou até a área de negócio e o utilizador avançado configurem muitos fluxos de trabalho. Mas precisa de saber quem terá de escrever o código e quem terá de executar o trabalho, tal como acontece com as integrações.

Para não se perder demasiado nos detalhes durante a demonstração, lembre todos de que os pormenores devem ficar documentados e avance com a observação do software em funcionamento.

Galen Low: Gosto muito disso. Quero voltar a uma ideia. Falámos em separar o grupo e criar duas demonstrações: uma mais orientada para o negócio, com o utilizador avançado e a interface do utilizador, e outra mais focada na área de TI, com conversas sobre infra-estrutura, integrações, tarefas agendadas e processos que precisam de ser executados em segundo plano.

Mas, em algum momento, tudo tem de voltar a juntar-se. As pessoas tiveram conversas diferentes e estão a avaliar a ferramenta com base nessas conversas. Será que todo o comité de selecção deve criar uma grelha de avaliação, para ter comparações equivalentes entre os produtos seleccionados e documentar o seu raciocínio? Dessa forma, quando voltarem a reunir-se, poderão quantificar e avaliar as suas opiniões e sentimentos sobre o software.

Ou será uma forma ultrapassada de ver a questão? Como disse, os produtos e o software são actualmente muito diferentes e alguns podem ser demasiado complexos para comparar através de uma grelha. O que pensa?

Olivia Montgomery: Gosto muito de ter mencionado as grelhas de avaliação de fornecedores. Sou uma grande defensora delas. Continuam a ter um lugar importante e não estão nada ultrapassadas. Sempre que conseguimos eliminar e reduzir reacções emocionais, que são um dos riscos das demonstrações muito focadas no discurso de vendas, devemos fazê-lo. É preciso retirar a emoção e lembrar a razão pela qual se está a adquirir software.

A grelha ajuda a recordar qual é o problema que estamos a resolver e permite comparar cada fornecedor. Podemos pensar: este fornecedor foi muito interessante. Mas, quando voltamos à grelha, encontramos perguntas como: cumpre os nossos requisitos funcionais? E os requisitos empresariais e técnicos? Se não cumprir ambos, não é uma boa opção.

Mesmo que o responsável pelo negócio adore uma determinada ferramenta por uma razão emocional, sem uma grelha ou algum tipo de modelo normalizado não existe um registo de como a decisão foi tomada. As grelhas são úteis durante as discussões de decisão. Como gestora de projectos, recomendo vivamente que as guarde sempre, porque nunca se sabe quando o projecto será auditado.

Nunca se sabe quando alguém fará perguntas ou quando a organização quererá substituir o software daqui a alguns anos. É importante saber por que razão não escolhemos determinado fornecedor: talvez tenha obtido uma pontuação de um na escala de integrações.

Quando voltar a falar com esse fornecedor, poderá perguntar se entretanto criou essas integrações. Assim, terá um processo de decisão informado. Apoio, recomendo e gosto plenamente das grelhas de avaliação de fornecedores. São uma forma de reunir informação diferente num único local, permitindo que todos vejam as pontuações uns dos outros, seja através de uma única grelha ou de grelhas individuais que depois são reunidas.

Isso dependerá da dimensão da empresa e da dimensão e complexidade do sistema. Para uma ferramenta de gestão de projectos, provavelmente terá vários responsáveis a preencher as suas próprias grelhas. Depois, enquanto gestor de projecto, reúne-as e deve guardá-las. Nunca se sabe quando serão necessárias.

Passei pessoalmente por uma situação semelhante. Trabalhava numa empresa e o nosso director de tecnologia mudou pouco depois de implementarmos um novo sistema ERP. Quando chegou, quis saber por que razão utilizávamos aquela ferramenta e como tínhamos escolhido o fornecedor. Fosse qual fosse a sua reacção emocional, consegui mostrar-lhe que tinha sido uma decisão informada e fundamentada.

Isso ajuda a criar uma relação com a nova parte interessada e também a compreender o negócio. A pessoa acabou de entrar numa nova empresa e consegue perceber o contexto da decisão.

Se trabalha numa empresa cotada em bolsa, especialmente, os auditores vão querer saber que não entregou o negócio à empresa de software do seu irmão. Precisam de confirmar que a decisão foi tomada de forma ponderada e normalizada.

Galen Low: Há três coisas que queria destacar do que acabou de dizer. Primeiro, penso que algumas pessoas vêem uma grelha de avaliação como algo muito genérico: pontuar a interface do utilizador numa escala de um a dez. Isso pode ser útil, mas o que está a dizer é que devemos incluir especificidade. O que estamos a tentar alcançar? Por que razão estamos a adquirir novo software? Essa é a grelha.

Numa escala de um a dez, até que ponto esta ferramenta nos permitirá ligar ao restante ecossistema de software e integrar processos fluidos, simplificados e automatizados? Talvez até de forma mais específica. Essa é a pergunta que deve constar da grelha.

Olivia Montgomery: Na verdade, gosto que algumas grelhas de fornecedores sejam um pouco menos específicas.

Uma escala de um a dez pode ser excessiva. Normalmente recomendo reduzi-la a uma escala de um a cinco e definir o que significa cada valor. Um pode significar que cumpre as expectativas, não cumpre as expectativas, excede as expectativas ou que a funcionalidade nem sequer existe. Nesse caso, seria zero.

Galen Low: Inexistente. Exactamente.

Olivia Montgomery: Gosto da escala de um a cinco. É mais clara e obriga as pessoas a serem mais precisas. Também simplifica os cálculos, especialmente quando atribuímos pesos individuais aos critérios.

Galen Low: Gosto muito disso. Estou a pensar nos inquéritos de recomendação que recebo: qual é a probabilidade de recomendar esta ferramenta a um amigo, de zero a dez? E fico a pensar: o que significa um sete?

Olivia Montgomery: Exactamente. Se gostar do que está a ser perguntado, escolhe sete. Se não gostar, escolhe três. É isso que toda a gente faz e não é muito útil.

Por isso, a escala de um a cinco simplifica e obriga as pessoas a escolher uma posição e a defini-la. Quer utilize uma ferramenta, uma folha de papel ou uma folha de cálculo, deve explicar exactamente o que cada valor significa. Pode mantê-lo simples: cumpre as expectativas, não cumpre as expectativas ou excede as expectativas.

Galen Low: Gosto disso. A outra coisa que estou a perceber, mas diga-me se estou certo ou errado, é que falámos em separar o grupo e criar conversas diferentes.

Muitas pessoas pensam numa grelha como uma situação de comparação directa, em que todos os envolvidos na decisão utilizam os mesmos critérios para avaliar um software.

Mas parece-me que sugeriu que nem todos têm necessariamente a mesma grelha entre si. Cada pessoa pode ter uma grelha consistente para avaliar vários softwares. É isso que quis dizer? E, de qualquer forma, acha que é uma boa ou má ideia, para que, por exemplo, a equipa técnica avalie com base em determinados critérios e a equipa de negócio com base noutros?

Desde que cada equipa aplique uma avaliação consistente a todas as ferramentas, quando voltarem a reunir-se poderão discutir os resultados sem avaliar algo que está fora da sua área de responsabilidade ou que não consideram importante.

Olivia Montgomery: Regra geral, recomendo ter um único modelo de grelha que inclua os requisitos técnicos e empresariais. Depois, deve ficar muito claro quem é responsável por cada coluna ou linha. A equipa técnica deve preencher os requisitos de integração, cibersegurança e outros aspectos técnicos, enquanto os executivos podem avaliar o painel de relatórios.

Mas quero que toda essa informação seja partilhada com todos. Pode ocultar determinadas colunas quando envia a grelha a algumas pessoas, mas elas devem saber que essas colunas existem.

Deve utilizar a mesma grelha para todos, por várias razões. Ajuda toda a gente a compreender que existem mais opiniões para além da sua. Às vezes, surgem situações interessantes: o responsável de TI pode dizer que, durante a demonstração técnica, descobriu que o fornecedor não tem clientes actuais com aquela integração. Por isso, na sua opinião, a ferramenta não cumpre as expectativas.

Entretanto, o responsável pelo negócio pode ter falado com o vendedor e ter ouvido que a integração é possível. A grelha ajuda a iniciar essa conversa: o vendedor disse que é possível, o responsável de TI concorda, mas explica que será uma integração personalizada, não disponível de origem, não testada e sem outros clientes a utilizá-la. Existem muitos riscos.

Talvez a organização não esteja disposta a assumi-los. Essa conversa precisa de acontecer e a grelha é uma boa forma de a iniciar.

Uma grelha única ajuda todos a estar na mesma página, a sentirem-se envolvidos e ouvidos, e facilita discussões fundamentais antes da assinatura do contrato.

Galen Low: É isso mesmo. É um ponto enorme que talvez seja esquecido. Quando falamos de grelhas e de valores numéricos, alguém pode pensar: colocamos os dados no computador e ele diz-nos que software escolher. Mas, na verdade, a grelha é um catalisador para uma conversa: onde existe desacordo e onde precisamos de aprofundar?

O gestor de projectos mais técnico que há em mim pensa no planeamento por pontos, em que alguém considera uma tarefa muito simples e lhe atribui três pontos, enquanto outra pessoa lhe atribui vinte e um. Precisamos de pôr essas pessoas a conversar, porque existe uma diferença enorme entre as avaliações.

Olivia Montgomery: Exactamente. É uma base para a conversa e também impede que as discussões se tornem acaloradas ou emocionais. As pessoas partilham a sua informação com base em números, em vez de se transformar numa discussão de “ele disse” e “ela disse”.

Galen Low: E, falando de questões técnicas, talvez possamos aprofundar o processo de recolha e consolidação. Referiu anteriormente que poderíamos ter pontuações ponderadas, que todos poderiam preencher a grelha e que precisaríamos de um local para guardar tudo.

Pode explicar-me o que faria se estivesse numa organização? Utilizaria uma ferramenta? Que reuniões organizaria depois de todas as demonstrações? Como apresentaria novamente essa informação às pessoas? Como faria os cálculos e identificaria as áreas que exigem discussão e quem deveria participar nessas conversas?

Olivia Montgomery: Galen, essa é uma pergunta enorme.

Galen Low: Eu sei, peço desculpa.

Olivia Montgomery: Há muita variabilidade, porque acredito sempre numa abordagem normalizada mas personalizada. Cada parte interessada é diferente. Cada empresa é diferente. A maturidade do ambiente, a maturidade dos processos empresariais, o dinheiro disponível e o tempo disponível são diferentes. Precisa de um sistema agora ou isto será uma substituição daqui a seis meses?

Enquanto gestor de projecto, precisa de ter muitas ferramentas na sua caixa para conseguir adaptar-se ao que está a acontecer. Para começar, precisa de saber quais são as expectativas. Idealmente, antes de marcar uma demonstração, quando alguém lhe diz que precisa de ser o gestor de projecto responsável pela aquisição de uma nova ferramenta de software, deve reservar algum tempo para perceber quem são os verdadeiros decisores finais.

Numa empresa maior, pode existir um comité director ou um comité director de TI ao qual terá de apresentar as suas conclusões. Numa empresa mais pequena, ou no caso de uma ferramenta menos visível, talvez baste alinhar o responsável de TI com o director da unidade de negócio. Precisa de saber tudo isso antes de agendar a demonstração e, idealmente, antes mesmo de falar com os fornecedores.

Galen Low: Penso que sim. Cada organização será diferente, mas a minha principal conclusão é a importância de preparar tudo antecipadamente, especialmente se for o gestor de projecto que lidera o processo. Deve utilizar as suas competências e capacidades interpessoais para navegar conversas políticas complexas.

Deve conseguir dizer: esta é a nossa grelha, este é o local onde vamos guardá-la, esta é a forma como estamos a preparar as sessões, estas são as informações que estamos a transmitir aos fornecedores e estas são as demonstrações que lhes pedimos com base nos casos de utilização enviados e na prioridade que definimos.

Depois das demonstrações, deve ter um plano para reunir todos os dados, apresentá-los novamente de forma a permitir uma conversa e trazer as pessoas certas para a mesa.

Quando chegar a decisão final, é importante reunir os decisores, os responsáveis pelo negócio e os responsáveis técnicos para discutir o assunto e tomar uma decisão. Deve também criar um registo auditável, seja porque poderá haver uma auditoria, seja porque poderá surgir um novo director de tecnologia que queira saber por que razão foi escolhida aquela solução.

Em vez de repetir todo o processo, terá informação que permite construir uma ponte e estabelecer uma relação com essa nova pessoa: este foi o nosso processo, este foi o raciocínio, estes são os dados. Se quiser alterar o rumo, pode fazê-lo, mas pelo menos terá a informação disponível.

Olivia Montgomery: Uma coisa: se estiver a ter dificuldade em obter apoio para uma grelha de avaliação ou se as pessoas não estiverem preparadas para preencher cada uma a sua própria grelha e depois consolidá-las, pode preencher a grelha do fornecedor em conjunto.

Pode dizer: depois das demonstrações, vamos preencher esta grelha. Vou marcar 45 minutos e, espero, será apenas isso. Vamos preenchê-la em conjunto. Assim, o verdadeiro valor da grelha enquanto ferramenta de conversa e de decisão torna-se mais activo. Muitas pessoas, especialmente os líderes empresariais, gostam de discutir as coisas em conjunto.

Quer estejam na mesma sala ou em salas diferentes, preencham-na em conjunto e digam: estamos a avaliar os fornecedores que todos vimos. Estes são os três fornecedores. No final desta reunião, teremos uma grelha completa e, esperamos, estaremos todos de acordo.

Preencher uma única grelha em conjunto pode ser uma boa solução.

Galen Low: Gosto disso. Não é um exame e não somos juízes olímpicos. Podemos fazê-lo de forma colaborativa. É uma discussão.

Quando tudo estiver concluído, algumas pessoas poderão dizer que, na selecção de software, não é possível agradar a todos. Como gere as expectativas ao longo do processo para que as pessoas da empresa que contribuíram e têm interesse na decisão final não fiquem descontentes?

Olivia Montgomery: Essa é outra razão pela qual gosto das grelhas de fornecedores, especialmente quando atribuímos pesos aos critérios. Deve ter presente por que razão precisa de uma ferramenta, não apenas qual ferramenta vai adquirir. E não dê ao projecto o nome do fornecedor, como “implementação do software X”. É outra coisa que vejo acontecer.

Não faça isso. É o seu projecto de selecção. Lembre-se da razão pela qual precisa do software, porque isso pode ser esquecido, especialmente quando as pessoas estão prontas para tomar uma decisão e dizem: queremos este software, compre-o e vamos começar a utilizá-lo na segunda-feira.

Pergunte sempre: aquilo que o fornecedor disse, a proposta, o contrato, a demonstração e toda a informação disponível resolvem o problema empresarial que estamos a tentar resolver? Utilize novamente a grelha como um modelo normalizado e não emocional para manter o foco.

Não se deixe convencer apenas porque uma ferramenta executa muito bem determinadas funções se não conseguir integrar com o sistema de correio electrónico, que é uma necessidade obrigatória. Talvez alguém tenha gostado muito do painel de relatórios, mas isso não deve superar um requisito essencial.

Volte sempre à grelha e pergunte: isto resolve o problema empresarial? Não pergunte apenas se tem funcionalidades novas e atractivas.

Galen Low: Gosto muito disso. Na minha cabeça, escrevi: grelha de avaliação é igual a transparência. Não necessariamente de forma intrínseca, mas essa é a sua utilidade.

É importante ser transparente sobre a decisão, para existir um registo de auditoria e para que as pessoas possam perceber por que razão foi tomada. Para quem participa no processo, a grelha proporciona clareza e rigor. Mostra o que estamos a tentar alcançar e partilha essa visão com todos os envolvidos.

No final, é importante comunicar a decisão a todos: tomámos esta decisão e esta é a razão; obrigado pela participação; este foi o resultado da avaliação. Ser transparente sobre o processo fará com que todos fiquem satisfeitos? Provavelmente não. Algumas pessoas continuarão a preferir outra funcionalidade, mas pelo menos haverá uma justificação e as pessoas certas terão sido envolvidas.

Olivia Montgomery: O que quer é respeito pela decisão. As pessoas não têm de ficar felizes com a decisão, mas devem respeitá-la. Só o conseguem fazer quando têm discussões honestas e transparentes e percebem que não foi escolhida uma solução apenas porque o irmão de alguém trabalha na empresa fornecedora.

Não quero ser leviana, mas esse é um problema real em muitas empresas. Acontece. A decisão tem de ser respeitada, não necessariamente adorada.

Galen Low: Gosto muito disso. Olivia, é sempre óptimo tê-la no programa. Houve muita informação útil na nossa conversa. O que mais me ficou foi a ideia de ter duas demonstrações. Intuitivamente, quero manter o grupo todo unido para tomar uma decisão conjunta, mas isso não significa que a demonstração tenha de ser a mesma para todos.

Na verdade, provavelmente não é uma boa ideia, porque há muito terreno para cobrir e as conversas são muito diferentes. Podemos voltar a unir tudo através de uma grelha de avaliação e de uma conversa colaborativa posterior, envolvendo todos sem desperdiçar o tempo das pessoas. É um excelente conselho.

Olivia Montgomery: O utilizador avançado não precisa de estar presente quando falamos sobre a frequência de execução das tarefas ou sobre o aspecto exacto da API, e vice-versa. Trata-se de respeitar o tempo de todos, sem deixar nada de lado e sem esperar demasiado tempo para que as áreas de negócio e de TI cheguem a acordo.

Isso não deve acontecer durante a implementação.

Galen Low: Última pergunta. Última pergunta. Uma pergunta com rasteira.

Olivia Montgomery: Outra?

Galen Low: Sim, outra pergunta com rasteira, para terminarmos.

Imaginemos que é gestor de projecto numa organização onde o processo de selecção de software não está a ser tratado com rigor. Talvez alguém diga: a empresa de software é do meu irmão, vamos conseguir um bom negócio.

O que pode fazer? O que pode dizer para introduzir algum rigor no processo e reduzir a subjectividade? Que conversas precisa de ter?

Olivia Montgomery: Deve garantir que tem uma relação respeitosa com a pessoa que defende essa opinião.

Confirme se essa pessoa é responsável pela decisão final. Por vezes, não é e terá de falar com quem efectivamente toma a decisão, dizendo: preciso da sua ajuda, preciso de utilizar a sua autoridade, preciso que me ajude.

Se essa pessoa for o decisor, fale com ela, ouça-a e pergunte se podem preencher uma grelha de avaliação em conjunto.

Explique que quer garantir que todos os aspectos são considerados e que está verdadeiramente interessado na ferramenta. Não seja desdenhoso e trabalhe na relação, porque poderá trabalhar com essa pessoa durante muito tempo.

Talvez preencham a grelha em conjunto e utilize uma abordagem socrática: diga-lhe para explicar o que descobriu sobre as integrações. Se não tiverem falado sobre isso, aproveite para abordar o tema.

É uma forma socrática de ajudar a pessoa a descobrir requisitos ao longo da conversa. Talvez perceba que aquela não é a melhor ferramenta, ou talvez confirme que é. Nesse caso, agradeça a informação, reconheça a ajuda e proponha avaliar pelo menos mais uma opção.

Volto sempre ao mesmo ponto: seja franco e transparente. Explique que a solução tem de funcionar para a área de TI, para a unidade de negócio, para o estado actual e para o estado futuro. Faça isso em conjunto.

Galen Low: Excelente. Gosto muito disso.

Olivia, foi um prazer tê-la connosco. Fizemos uma análise muito aprofundada do processo de selecção de software, especialmente das demonstrações e do processo de decisão posterior.

Espero que os nossos ouvintes tenham retirado muito valor desta conversa. Estou ansioso por voltar a recebê-la no programa, porque ainda há muito terreno para explorar e mais perguntas com rasteira para lhe fazer.

Olivia Montgomery: Muito obrigada pelo convite. Estou entusiasmada. Espero que as pessoas tenham aprendido alguma coisa e que estejam a pensar de forma diferente sobre o processo de selecção e as demonstrações. Talvez já não as encarem com receio nem permitam que as decisões sejam impostas. Espero sinceramente que tenha sido útil. Gosto sempre de falar consigo, Galen. É excelente. Muito obrigada.

Obrigada!

Galen Low: Na sua opinião, uma demonstração de software vale o tempo da sua equipa? Ou é apenas uma espécie de espectáculo que evita uma análise mais prática e aprofundada durante o período de avaliação? Partilhe as suas opiniões e histórias nos comentários abaixo.

E, se quiser aperfeiçoar as suas competências enquanto líder estratégico de projectos, junte-se à nossa comunidade. Visite thedigitalprojectmanager.com/membership para ter acesso a uma comunidade de apoio que partilha conhecimento, resolve desafios complexos e molda o futuro da nossa profissão — em conjunto.

Desde modelos completos e sessões mensais de formação que lhe poupam tempo e energia, até ao apoio dos seus pares no nosso fórum de discussão, eventos da comunidade e grupos de acompanhamento, ser membro da nossa comunidade significa ter mais de mil pessoas do seu lado enquanto desenvolve a sua carreira na entrega de projectos digitais.

E, se gostou do que ouviu hoje, subscreva e mantenha-se em contacto através de thedigitalprojectmanager.com.

Até à próxima. Obrigado por ouvir.