Avaliar uma plataforma de gestão é produzir evidência com os seus dados e a sua gente. A demo não é isso: é a apresentação. Quem escolhe o cenário, os dados e a ordem das telas é o fornecedor, e ele conhece o caminho feliz. Inverter esse roteiro tem quatro movimentos: escrever de 5 a 8 casos reais do seu negócio antes da primeira reunião, exigir que a ferramenta rode um processo do começo ao fim com as pessoas que vão operar, fazer as perguntas administrativas que a apresentação não cobre, e somar o custo total em vez do preço da licença.
O tamanho do ponto cego é mensurável. A ISO/IEC 25010:2023, norma internacional de qualidade de produto de TIC, declara no escopo que o modelo de qualidade de produto é composto por nove características. Uma demo bem conduzida demonstra bem uma delas: adequação funcional. As outras oito você só descobre na operação, quando já assinou. O trabalho do comprador é antecipar o máximo possível dessas oito antes da assinatura.
Este texto reúne o método que eu aplico, com as normas que sustentam cada etapa — e com o cuidado de dizer, em cada uma, o que ela obriga e o que ela apenas sugere. Declaro o interesse comercial: a Audatia é revenda oficial do ClickUp no Brasil e presta consultoria, treinamento e sustentação em monday.com. Ou seja, eu sou parte interessada em algumas dessas avaliações — e é justamente por isso que o método abaixo foi escrito para funcionar contra mim também.
Por que toda plataforma parece boa numa demo
Porque a demo faz exatamente o que foi feita para fazer. Ela existe para mostrar o produto no melhor cenário possível, e isso é legítimo. O problema não é o vendedor. É usar a apresentação como evidência.
Três coisas garantem o resultado bonito.
Os dados são limpos. A base de demonstração tem 40 registros, todos preenchidos, sem duplicidade, sem cliente cadastrado três vezes com grafias diferentes, sem campo obrigatório vazio há anos. A sua base não é assim.
O cenário foi escolhido. O fluxo apresentado é o que a ferramenta faz melhor. Se o seu processo tem uma etapa de aprovação dupla com alçada por valor, ela pode aparecer no fim, resumida, ou não aparecer.
Ninguém da equipe real está operando. Quem clica é quem usa o sistema todo dia há dois anos. Ele não hesita, não erra o caminho, não abre o menu errado. A velocidade que você vê na tela não é a velocidade que a sua equipe terá.
Há ainda um efeito que a norma de usabilidade descreve melhor do que qualquer argumento comercial. A ISO 9241-11:2018 define satisfação como a medida em que as respostas físicas, cognitivas e emocionais decorrentes do uso atendem às necessidades e expectativas do usuário — e registra, em nota, que a expectativa criada antes do uso contamina a satisfação com o uso real. Traduzindo: a demo fabrica satisfação antecipada, e satisfação antecipada não é evidência de usabilidade.
Some a isso o efeito da ordem. Você vê três demos em duas semanas e compara lembranças, não fatos. A última costuma parecer melhor porque está mais fresca. Sem um roteiro seu, a comparação vira preferência estética.
Avaliar uma plataforma de gestão: o que a demo prova e o que não
Vale ver a lista completa, porque ela transforma uma intuição em checklist. Estas são as nove características do modelo de qualidade de produto da ISO/IEC 25010:2023 — a tradução é minha, e por isso mantenho o termo original ao lado.
| Característica | Termo original | Uma demo prova? |
|---|---|---|
| Adequação funcional | functional suitability | Sim, é o que ela demonstra bem |
| Eficiência de desempenho | performance efficiency | Não — a base de demonstração é pequena |
| Compatibilidade | compatibility | Não — o catálogo de conectores não é teste de integração |
| Capacidade de interação | interaction capability | Não — quem opera é especialista, não a sua equipe |
| Confiabilidade | reliability | Não — indisponibilidade não acontece na hora marcada |
| Segurança da informação | security | Não — é auditoria e contrato, não tela |
| Manutenibilidade | maintainability | Não — aparece na segunda mudança, meses depois |
| Flexibilidade | flexibility | Não — inclui escalabilidade e portabilidade |
| Segurança contra danos | safety | Não — é sobre risco de operação, não sobre recurso |
Repare no padrão: das nove, oito só se manifestam com tempo, volume ou mudança — e a demo não tem nenhum dos três. É por isso que nenhuma quantidade de apresentações substitui uma semana de uso real. Três observações de rigor sobre essa tabela. A norma é conjunta ISO/IEC, não apenas ISO. A edição de 2011 tinha oito características e usava os nomes “usabilidade” e “portabilidade”; a edição vigente substituiu os dois por “capacidade de interação” e “flexibilidade”, e acrescentou safety como nona. E cuidado com o português: security e safety são características distintas na norma, e o nosso idioma colapsa as duas em “segurança”.
Uma leitura prática que quase ninguém faz: escalabilidade entrou no vocabulário da norma como subcaracterística de flexibilidade, não de desempenho. Isso muda a pergunta na reunião. Não é “a ferramenta é rápida?”, é “o que eu preciso mudar quando eu dobrar de tamanho?”.
O que preparar antes de marcar a primeira reunião
Antes de qualquer contato com fornecedor, escreva os casos que a ferramenta precisa aguentar. Entre 5 e 8 é suficiente. Menos que isso não cobre o negócio, mais que isso ninguém executa.
Um caso real tem quatro elementos: um gatilho, os dados de verdade, as pessoas envolvidas com nome e papel, e o resultado esperado. Não escreva “gestão de projetos”. Escreva: “Chega um pedido de proposta de um cliente do setor X, com sete itens de escopo; o comercial monta a proposta, o técnico valida prazo, o financeiro confere margem, o diretor aprova acima de determinado valor, e o cliente recebe o documento; hoje isso leva quatro dias e passa por três planilhas”.
Inclua de propósito pelo menos dois casos incômodos.
O caso feio. O processo que tem exceção, retrabalho ou cliente que muda de ideia no meio. Toda ferramenta lida bem com o fluxo linear. A diferença aparece na exceção.
O caso de volume. O relatório do fechamento com o número real de registros, não com 40 linhas.
Leve também uma amostra da sua base — anonimizada se necessário — e peça para importar. A qualidade da importação diz mais sobre a vida futura do que qualquer tela.
E defina antes o que é aprovação. Aqui existe um respaldo que vale conhecer: nas contratações de tecnologia do governo federal, a Instrução Normativa SGD/ME nº 94/2022 determina que, quando há verificação de amostra do objeto, os procedimentos e critérios objetivos de avaliação devem constar no termo de referência — ou seja, por escrito e antes. A regra vincula órgãos do Executivo federal e não a sua empresa, mas a lógica é transferível: se você só decide o que é aprovado depois de assistir à apresentação, quem definiu o critério foi o vendedor.
O que testar de verdade — e com quem
O teste que vale é um processo real rodado do começo ao fim, pelas pessoas que vão operar, sem o vendedor conduzindo o mouse. Ele pode estar na sala. Só não pode dirigir.
A pergunta que orienta o teste não é “a ferramenta faz?”. Quase tudo faz. É “quanto custa fazer, quem consegue fazer e o que quebra quando muda?”.
| O que testar | Como testar | Sinal de alerta |
|---|---|---|
| Importação da sua base | Subir uma amostra real, com sujeira | Precisa de serviço do fornecedor para toda carga |
| Um processo ponta a ponta | Quem opera executa, sem ajuda | Só funciona com o vendedor no comando |
| Mudança de campo ou etapa | Alguém da sua equipe altera na hora | Depende de chamado ou de horas de consultoria |
| Permissões e visibilidade | Criar um perfil restrito e testar por dentro | Tudo ou nada, sem granularidade |
| Volume real | Abrir a visão com todos os registros | Lentidão que “melhora com filtro” |
| Exportação completa | Exportar tudo e abrir o arquivo | Exporta só listas, sem anexos, histórico ou comentários |
| Integração com um sistema seu | Testar o fluxo real, não o catálogo de conectores | “Tem API” como resposta final |
| Uso por quem não gosta de sistema | Pedir a duas pessoas céticas para operar | Treinamento longo para tarefa simples |
Quem participa também importa, e há orientação normativa sobre isso. A ISO 9241-210:2019 estabelece que as pessoas envolvidas na avaliação devem ter capacidades, características e experiência que reflitam a faixa de usuários para quem o sistema é destinado — usuários representativos, não voluntários entusiasmados. E a mesma norma recomenda que a avaliação centrada no usuário aconteça também como parte da aceitação final do produto, para confirmar que os requisitos foram atendidos. Traduzindo para a sua decisão: o teste com gente real não é etapa exploratória, é etapa de aceite.
As métricas que transformam impressão em evidência
Esta é a seção que mais muda a qualidade de uma avaliação, e ela é quase sempre pulada. Anotar “todo mundo gostou” não é dado. Existem métricas objetivas, definidas em fonte primária, que qualquer empresa consegue coletar num piloto.
| Métrica | Como se mede | O que ela responde |
|---|---|---|
| Taxa de conclusão | Percentual de participantes que concluem a tarefa completa e corretamente | A equipe consegue chegar ao fim sozinha? |
| Taxa de conclusão não assistida | A mesma, contando só quem terminou sem ajuda | É a métrica que decide a compra |
| Erros de uso | Quantas vezes a pessoa não conclui ou refaz parte da tarefa | Onde o fluxo trava |
| Assistências | Número e tipo de intervenções de quem aplica o teste | Quanto de treinamento a operação vai exigir |
| Tempo de tarefa | Média e desvio-padrão por caso testado | Quanto do recurso do time é consumido |
| Participantes por perfil | Quantidade de pessoas testadas em cada papel | Se o resultado é sinal ou ruído |
A segunda linha é a mais importante do artigo inteiro, e ela vem de uma exigência formal: o relatório padronizado de teste de usabilidade do NIST determina que, quando o aplicador precisa intervir para o participante prosseguir, as métricas de eficácia e eficiência sejam reportadas separadamente para as condições assistida e não assistida, com o número e o tipo de assistências no resultado.
Numa demo, 100% das tarefas são assistidas — o vendedor está conduzindo. A métrica que decide a compra é a outra: quanta gente conclui sem ninguém do lado.
Duas âncoras a mais para dimensionar o teste. A ISO/IEC 25062:2006 recomenda oito ou mais participantes por segmento de usuário para que a análise somativa seja válida — o que desqualifica o clássico “mostramos para três pessoas e todo mundo gostou”. E, para dar noção de o quanto isso é levado a sério onde o erro custa caro, a regulação federal norte-americana de certificação de sistemas de saúde exige, para os recursos que testa, no mínimo dez participantes e a captura de métricas específicas de sucesso, falha, desvios, tempo e satisfação. Quando a escolha de software pode machucar alguém, o regulador não aceita demonstração — aceita medição.
Há ainda um detalhe de vocabulário que muda a conversa com o fornecedor. A ISO 9241-11:2018 usa deliberadamente o termo erro de uso em vez de “erro do usuário”, justamente para não atribuir a responsabilidade à pessoa — e inclui, na definição, a incapacidade do usuário de concluir a tarefa. Ou seja: se a sua equipe não consegue terminar, isso conta como erro de uso do sistema. “É questão de treinamento” deixa de ser resposta e vira hipótese a testar.
Quais perguntas o vendedor não espera
As perguntas de funcionalidade são esperadas e ensaiadas. As que revelam mais são administrativas e chatas. Faça por escrito e peça resposta por escrito.
“Se eu sair em 18 meses, como exporto tudo — incluindo anexos, histórico de alterações e comentários — e em que formato?” Exportar a lista de registros é fácil. O valor acumulado está no que veio junto: quem mudou o quê, quando, e o arquivo anexado na conversa.
“Quem, na minha equipe, consegue criar um campo ou mudar uma etapa sem abrir chamado?” A resposta separa ferramenta configurável por você de ferramenta configurável pelo fornecedor. As duas existem e as duas são legítimas. Só têm custos de vida muito diferentes.
“O que acontece exatamente quando eu ultrapasso o limite do plano — de usuários, de registros, de automações, de armazenamento?” Bloqueia? Degrada? Cobra automaticamente? Sobe de faixa? O excedente vira dívida do mês seguinte? Peça o número do limite e a regra, não a tranquilização.
“Quantos clientes do meu porte e do meu setor você tem ativos há mais de dois anos? Posso falar com dois deles?” Note que a pergunta não é sobre número de clientes. É sobre permanência. E peça referências que você escolhe, não só as três da lista pronta.
“Quem faz a implantação: você, um parceiro ou eu?” Configurar é deixar a ferramenta pronta. Implantar é deixar a empresa usando. Muita frustração nasce de contratar o primeiro achando que comprou o segundo.
“Como vocês entenderam os usuários e as tarefas desse tipo de operação?” Parece pergunta de designer e é pergunta de comprador: a ISO 9241-210:2019 lista, entre os princípios de design centrado no humano, que o projeto se baseie em entendimento explícito de usuários, tarefas e ambientes, e que usuários sejam envolvidos ao longo de todo o desenvolvimento. Fornecedor que pesquisou responde com detalhe. Fornecedor que não pesquisou responde com adjetivo.
“O que costuma dar errado nos primeiros meses com clientes parecidos comigo?” Fornecedor experiente responde com casos. A ausência de resposta também é informação.
Quanto custa de verdade
A licença costuma ser a parte visível e menor. Aqui de novo o setor público oferece um método pronto: nas contratações de tecnologia do Executivo federal, o estudo técnico preliminar precisa trazer análise comparativa de custos com o “cálculo dos custos totais de propriedade (Total Cost Ownership – TCO) por meio da obtenção dos custos inerentes ao ciclo de vida dos bens e serviços de cada solução, a exemplo dos valores de aquisição dos ativos, insumos, garantia técnica estendida, manutenção, migração e treinamento”. A regra não obriga empresa privada. O raciocínio serve igual.
| Componente | O que entra | Onde costuma escapar |
|---|---|---|
| Licença | Preço por usuário ou por faixa, anual | Reajuste, moeda, faixa que muda ao crescer |
| Módulos e add-ons | Recursos vendidos à parte | O recurso que você viu na demo pode estar em outro plano ou em outro produto |
| Implantação | Configuração, migração, desenho de processo | Cotada por escopo, cobrada por hora |
| Integração | Conexão com ERP, financeiro, e-mail, planilhas | Manutenção quando um dos lados muda |
| Treinamento | Turmas iniciais e reciclagem | Rotatividade — quem treina o próximo? |
| Tempo da sua equipe | Horas de quem participa da implantação e testa | Nunca entra na planilha e é frequentemente o maior item |
| Operação contínua | Ajustes, novos fluxos, suporte interno | Vira função informal de alguém |
| Saída | Extração, conversão, reentrada em outro sistema | Só aparece quando você decide sair |
A linha do tempo da equipe é a que mais some das planilhas, e é a que um guia do NIST sobre serviços de TI trata como parte explícita do custo total de propriedade, ao dizer que o TCO inclui não só implantação e operação, mas também custos relacionados como overhead, salários, benefícios, atualizações de tecnologia, suporte e manutenção de software. Vale a ressalva de que esse guia foi escrito para serviços de segurança da informação, não para compra de plataforma de gestão — a definição é aproveitável, o escopo original não é o seu.
Projete em três anos, não em um. E some o tempo da sua equipe em horas, mesmo que estimado. Sem esse item, a comparação entre uma ferramenta que você configura e uma que depende do fornecedor fica distorcida.
Como reconhecer sinais de aprisionamento
Aprisionamento não é má-fé. É consequência de arquitetura e de contrato. E algum grau de dependência é inevitável: qualquer sistema que guarda o seu processo cria vínculo. O que se controla é o custo de romper esse vínculo.
Aqui existe uma frase de norma internacional que resume a seção inteira melhor do que eu conseguiria. A ISO/IEC 19941:2017, que trata de interoperabilidade e portabilidade em computação em nuvem, afirma na introdução que declarar interoperabilidade ou portabilidade sem fazer uma análise detalhada do que especificamente será portado é algo sem significado, e que essa vagueza gerou confusão contínua no mercado. Ou seja: “exportamos tudo, claro” não é resposta. É a ausência de uma.
A mesma norma divide portabilidade de dados em camadas que viram três perguntas objetivas para a reunião. Ela define portabilidade de dados como a capacidade de transferir dados de um sistema a outro sem precisar redigitá-los — e registra, em nota, que imprimir os dados e redigitá-los no destino não pode ser descrito como “fácil”. Daí saem as três perguntas:
| Camada | A pergunta que ela vira | Resposta insuficiente |
|---|---|---|
| Sintática | O arquivo que sai consegue ser lido pelo destino? | “Exporta em PDF” |
| Semântica | O destino entende o que cada campo significa? | “Exporta tudo numa planilha só” |
| De política | A transferência respeita as regras legais dos dois lados? | “Isso é com você” |
| Sinal | Como se apresenta | Pergunta que confirma |
|---|---|---|
| Exportação limitada | “Exportamos os dados, claro” | Anexos e histórico saem juntos? Em que formato? |
| Customização só pelo fornecedor | “A gente configura para você, é mais rápido” | Quanto custa a próxima mudança, daqui a seis meses? |
| Preço por módulo | Plano base barato, essencial no módulo | Quais dos meus 5 a 8 casos exigem módulo pago? |
| Contrato longo sem saída | Desconto atrelado a prazo | Qual a cláusula de rescisão e o custo dela? |
| Conhecimento em uma pessoa | Um “dono do sistema” na sua empresa | Se essa pessoa sair amanhã, quem mexe? |
| Dados sem cópia sua | Tudo vive só no fornecedor | Consigo uma cópia periódica automática? |
O sinal mais subestimado é o penúltimo: a concentração interna. Não depende do fornecedor, depende de você — e é o mais fácil de corrigir, com documentação e uma segunda pessoa treinada desde o começo.
O que precisa estar no contrato, e não na promessa
Esta seção existe por causa de uma correção que eu preciso fazer com todas as letras, porque circula muita informação errada sobre ela.
A LGPD não protege a sua empresa contra aprisionamento. O direito à portabilidade previsto na lei é do titular, e a própria lei define titular como pessoa natural a quem se referem os dados pessoais. O seu acervo operacional — tarefas, projetos, anexos, histórico, automações — não é dado pessoal seu; é ativo da empresa. Não existe, no Brasil, norma que obrigue portabilidade de dados na relação entre uma empresa privada e o fornecedor de software dela. A única proteção real é contratual.
E é exatamente assim que o setor público se protege. As regras de contratação de TIC do Executivo federal determinam que os órgãos assegurem por meio de cláusulas contratuais que os serviços em nuvem permitam a portabilidade de dados e softwares, com as informações disponíveis para transferência em prazo adequado. As mesmas regras mandam, já no estudo preliminar, avaliar ações para viabilizar a possível substituição da solução, minimizando dependência tecnológica, e avaliar a diferença entre o preço de manter a solução implantada e o de substituí-la por outra semelhante, considerando licenças, serviços agregados e custos indiretos como migração de dados, novos equipamentos, implantação e treinamento.
Traduzindo em cláusulas que você pode pedir antes de assinar:
- Formato, escopo e prazo da exportação, dizendo explicitamente se anexos, histórico e comentários vão junto.
- Direito a cópia periódica dos dados durante a vigência, não só na saída.
- Prazo de assistência na transição, com entrega de documentação e transferência de conhecimento ao fim do contrato.
- Regra de reajuste e o que acontece se você mudar de faixa de usuários.
- Condições de rescisão e o custo dela.
Vale ainda separar o aceite em duas etapas, como faz a lei de licitações: um recebimento provisório, quando se verifica o cumprimento das exigências técnicas, e um definitivo, que comprova o atendimento das exigências contratuais — com previsão expressa de que o objeto pode ser rejeitado, no todo ou em parte, quando estiver em desacordo. Num contrato privado, isso vira: aceite provisório quando a ferramenta passa no seu roteiro, aceite definitivo depois de um número combinado de dias rodando com dado real.
Critério de aceite: o que faz um critério ser critério
Existe uma definição normativa útil e curta: critérios de aceitação são “parâmetros objetivos e mensuráveis utilizados para verificar se um bem ou serviço recebido está em conformidade com os requisitos especificados”. Guarde as duas palavras: objetivos e mensuráveis. “A ferramenta tem que ser intuitiva” não é critério de aceite — é opinião com aparência de requisito.
A mesma norma federal descreve o que um critério completo precisa ter: métricas, indicadores e níveis mínimos de serviço com os valores aceitáveis — e, do outro lado, o que acontece quando o mínimo não é atingido. Critério de aceite sem consequência é decoração. Num contrato privado, a consequência costuma ser desconto, prorrogação sem cobrança ou saída sem multa.
| Critério fraco | Critério de aceite |
|---|---|
| “A importação tem que funcionar” | 95% dos registros da amostra importados com os campos mapeados, sem intervenção manual registro a registro |
| “Tem que ser fácil de usar” | Taxa de conclusão não assistida de pelo menos 80% no caso 3, com 8 participantes do perfil operacional |
| “Tem que ser rápido” | A visão com o volume real do fechamento abre em até X segundos |
| “Tem que integrar com o ERP” | Um pedido criado no ERP aparece na plataforma em até X minutos, com os campos Y e Z preenchidos |
| “Tem que dar para exportar” | Exportação completa, com anexos e histórico, executada por alguém da nossa equipe, sem chamado |
Defina também o que conta como reprovação. Piloto sem critério de reprovação sempre “dá certo” — e essa é a forma mais comum de uma avaliação cara terminar exatamente onde teria terminado sem avaliação nenhuma.
Por que o piloto pago diz mais que o trial gratuito
O trial gratuito é útil e vale usar. Ele responde perguntas de superfície: a interface faz sentido, os campos existem, a navegação é tolerável. O que ele não faz é criar compromisso dos dois lados.
No trial, ninguém é responsável pelo resultado. Você testa nas brechas da semana, com dados falsos, e o fornecedor não tem obrigação de acompanhar. No piloto pago, existe escopo, existe prazo, existe alguém do outro lado com nome, e existem critérios de aceite escritos. É a diferença entre experimentar e ensaiar.
A prática tem respaldo formal. A Lei nº 14.133/2021 prevê, no art. 17, § 3º, que — desde que previsto no edital — o órgão licitante poderá realizar análise e avaliação da conformidade da proposta “mediante homologação de amostras, exame de conformidade e prova de conceito, entre outros testes de interesse da Administração, de modo a comprovar sua aderência às especificações definidas no termo de referência ou no projeto básico”. Duas ressalvas honestas: o verbo é poderá, então a prova de conceito é facultativa e precisa estar prevista antes; e a lei vincula a Administração Pública, não a sua empresa. Se um comprador que precisa justificar cada real tem previsão legal para testar antes de contratar, a empresa privada não tem por que decidir com base numa apresentação.
O guia de licitações e contratos do Tribunal de Contas da União dá a receita de como estruturar isso, e ela cabe igual num processo privado: a prova de conceito tem caráter excepcional e precisa de justificativa, é exigida apenas do fornecedor provisoriamente vencedor, e o instrumento convocatório precisa trazer data, horário e local, o roteiro detalhado da avaliação e os critérios objetivos de aceitação. Traduzindo para a sua empresa: escolha um finalista, marque, escreva o roteiro e os critérios antes, e não faça piloto com três fornecedores ao mesmo tempo.
Um piloto útil tem cinco elementos: escopo escrito, dados reais, as pessoas que vão operar, critérios de aceite definidos antes e critério de reprovação. Se você quiser fazer o reconhecimento de superfície antes disso, dá para abrir uma conta de teste em qualquer plataforma séria — no ClickUp ou no monday.com, por exemplo — e rodar um único caso. Só não confunda esse reconhecimento com o piloto: ele responde se a interface faz sentido, não se a ferramenta aguenta a sua operação.
Como envolver a equipe sem transformar a avaliação em votação
A equipe precisa participar. Sistema rejeitado por quem opera não sobrevive, por melhor que seja. Mas participação não é sufrágio, e essa confusão trava avaliações.
Separe os papéis desde o início. Quem decide é uma pessoa, com nome, e todos sabem quem é. Quem testa é quem vai operar, e o papel dessas pessoas é executar os casos e relatar fatos. Quem opina é o resto — opinião é bem-vinda como entrada, não como voto.
Peça relatos estruturados, não notas. “Concluí o caso 3 em 11 minutos, travei na etapa de aprovação porque não achei o botão” é informação. “Achei a cor feia” não é.
Cuidado com dois vieses previsíveis. O primeiro é a preferência pelo parecido: quem usa planilha há dez anos tende a aprovar o que se parece com planilha. O segundo é a resistência ao registro: ferramenta que expõe o andamento do trabalho gera desconforto legítimo, e esse desconforto às vezes se disfarça de crítica técnica. Nomear os dois em voz alta, antes do teste, reduz o ruído.
Quando não vale montar tudo isso
Este método tem custo, e há casos em que ele é maior que o risco que evita.
Quando a compra é pequena e reversível. Ferramenta de uma ou duas pessoas, contrato mensal, dados que cabem numa planilha. Assine, use um mês e cancele se não servir. Um piloto formal custa mais que o erro.
Quando o processo ainda não existe. Se você não consegue escrever cinco casos porque a operação muda conforme quem executa, o problema não é a escolha de ferramenta. Avaliar uma plataforma de gestão nesse estado é escolher onde registrar uma confusão que ainda vai mudar de forma.
Quando a decisão já foi tomada por outro motivo. Exigência de matriz, padrão corporativo, contrato global. Nesse caso o trabalho útil não é avaliar, é negociar cláusula de saída e planejar implantação.
Quando não há ninguém para conduzir. Avaliação sem dono vira reunião recorrente sem conclusão. Sem uma pessoa com nome, prazo e autoridade, o método não roda.
Quando a urgência é real. Existe. Nesse caso, corte para o mínimo: dois casos escritos, uma exportação testada e a cláusula de saída lida. Isso leva um dia e evita a maior parte do arrependimento.
O que eu não afirmo
Registro o que eu não consegui sustentar, porque em texto sobre método isso importa mais do que em qualquer outro.
Não cito taxa de fracasso de implantação. Os números que circulam sobre percentual de projetos de software que falham vêm quase sempre de consultoria, sem metodologia publicada. Eu não encontrei fonte primária confiável e por isso não uso nenhum.
Não digo que a lei brasileira proíbe aprisionamento tecnológico. A lei de licitações não usa os termos “aprisionamento”, “dependência tecnológica” nem “interoperabilidade”. O que existe é o princípio do parcelamento, que busca evitar concentração de mercado, e as regras infralegais de contratação de TIC que citei — e essas vinculam órgãos públicos federais, não empresas.
Não atribuo às normas o que elas não dizem. A ISO 9241-11:2018 define usabilidade mas declara explicitamente que não descreve processos ou métodos específicos de avaliação. Quem diz “testamos segundo a ISO 9241-11” está, na melhor das hipóteses, sendo impreciso. E a palavra “piloto”, do jeito que eu uso aqui, não tem definição normativa: é convenção minha, descrita no texto.
Perguntas frequentes
| Pergunta | Resposta curta |
|---|---|
| Como avaliar uma plataforma de gestão sem depender da demo? | Escrevendo os casos antes, testando com quem vai operar, medindo números e somando o custo total em três anos |
| A demo serve para quê? | Conhecer o produto. Das nove características de qualidade da norma internacional, ela demonstra bem uma: adequação funcional |
| Quantos casos preparar? | De 5 a 8, com dados e nomes reais, escritos antes do primeiro contato, incluindo um caso feio e um de volume |
| Qual é o teste que vale? | Um processo ponta a ponta, operado por quem vai usar, sem o vendedor no mouse |
| Qual métrica decide? | A taxa de conclusão não assistida. Numa demo ela é sempre zero, porque toda tarefa é assistida |
| Quantas pessoas devem testar? | Oito ou mais por perfil de usuário, se você quiser que o resultado seja sinal e não ruído |
| Qual pergunta revela mais? | Como exporto tudo, com anexos e histórico, se eu sair — e em que formato |
| O que somar no custo? | Licença, módulos, implantação, integração, treinamento, tempo da equipe, operação e saída — em três anos |
| A LGPD me protege contra aprisionamento? | Não. O direito de portabilidade é do titular pessoa natural. O acervo da empresa só está protegido pelo que estiver no contrato |
| Trial ou piloto? | Trial para superfície; piloto pago, com escopo, critério de aceite e critério de reprovação, para decidir |
| Como envolver a equipe? | Quem testa relata fatos; quem decide é uma pessoa. Não é votação |
| Quando não vale fazer tudo isso? | Compra pequena e reversível, processo ainda indefinido, decisão já tomada por outro motivo, ou avaliação sem dono |
Se você vai ver demos nas próximas semanas, chegue com o roteiro pronto
Nenhum método elimina o risco de escolher errado. O que ele muda é a assimetria: você para de comparar impressões e passa a comparar evidências que você mesmo produziu, com os seus dados e a sua gente.
Antes da próxima reunião marcada, faça o mínimo: escreva os seus 5 a 8 casos, defina os critérios de aprovação e de reprovação, leve uma amostra da sua base e peça a cláusula de saída por escrito. Isso já inverte o roteiro, e leva menos tempo do que a soma das apresentações que você assistiria sem ele.
Eu acompanho empresas nesse tipo de avaliação — montando os casos de teste, conduzindo pilotos, medindo taxa de conclusão não assistida e revisando cláusulas de saída — pelos serviços de consultoria e treinamento. A Audatia é revenda oficial do ClickUp no Brasil, com licença em reais e nota fiscal por cotação, e atua em consultoria, treinamento e sustentação de monday.com, sem revender a licença dele. Aplico a mesma disciplina inclusive quando a plataforma avaliada não é nenhuma das duas — e já concluí, mais de uma vez, que a ferramenta certa era a que o cliente já tinha.
Fontes
- ISO/IEC — ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model
- ISO — ISO 9241-11:2018, Usability: definitions and concepts
- ISO — ISO 9241-210:2019, Human-centred design for interactive systems
- ISO/IEC — ISO/IEC 25062:2006, Common Industry Format for usability test reports
- ISO/IEC — ISO/IEC 19941:2017, Cloud computing — Interoperability and portability
- NIST — SP 800-35, Guide to Information Technology Security Services
- NIST — NISTIR 7432, Common Industry Specification for Usability — Requirements
- Brasil — Lei nº 14.133/2021 e Lei nº 13.709/2018 (LGPD)
- Governo Digital — Instrução Normativa SGD/ME nº 94/2022
- Tribunal de Contas da União — Licitações e Contratos, item 5.4.1.2: Amostra e prova de conceito
- Estados Unidos — 45 CFR 170.315, Health IT certification criteria
*As normas ISO e ISO/IEC citadas são publicações pagas; os trechos aqui são paráfrases feitas a partir das seções de acesso público de cada uma, e as traduções para o português são de trabalho, sem correspondência oficial da ABNT. A Instrução Normativa SGD/ME nº 94/2022 vincula órgãos do Poder Executivo federal e a Lei nº 14.133/2021 vincula a Administração Pública — nenhuma das duas obriga empresas privadas, e são usadas neste texto como analogia de método. A Audatia é revenda oficial de licenças ClickUp no Brasil, segundo a regra do fabricante de mínimo de 10 usuários, e não revende licenças do monday.com.
