WEBVTT 00:00:00.000 --> 00:00:03.920 Olá, boas-vindas ao nosso episódio 6, que é o último dessa nossa série 00:00:03.920 --> 00:00:06.160 sobre literacia, técnica e governança. 00:00:06.160 --> 00:00:10.840 Hoje a gente vai fechar a nossa jornada focando no momento exato em que a demanda nasce. 00:00:10.840 --> 00:00:14.400 Pra começar a imagina uma cena, a gente tá inventando agora só pra didática, tá? 00:00:14.400 --> 00:00:18.680 Alguém do marketing para na mesa do time técnico numa terça-feira e pede, digamos, 00:00:18.680 --> 00:00:21.200 faz uma integração aí do formulário com o CRM. 00:00:21.200 --> 00:00:24.800 E, por exemplo, três semanas depois recebe uma entrega que funciona, 00:00:24.800 --> 00:00:26.800 que foi supertestada e tá no ar. 00:00:26.800 --> 00:00:28.800 Só que é outra coisa. 00:00:28.800 --> 00:00:32.800 A entrega sincroniza os contatos uma vez por dia, lá de madrugada, 00:00:32.800 --> 00:00:38.120 quando o que se precisava, na verdade, era do contato caindo no CRM no instante exato do envio, 00:00:38.120 --> 00:00:41.520 porque a campanha dependia de alguém ligar em poucos minutos. 00:00:41.520 --> 00:00:42.520 Sabe o que é pior? 00:00:42.520 --> 00:00:46.560 Ninguém trabalhou mal aí, mas o tempo se perdeu completamente. 00:00:46.560 --> 00:00:50.320 O que nos leva a grande pergunta central da nossa análise de hoje. 00:00:50.320 --> 00:00:53.320 Como formular um pedido ao time técnico com contexto, 00:00:53.320 --> 00:00:55.840 critério de aceite e um prazo realista? 00:00:55.840 --> 00:01:01.360 A boa notícia é que a estrutura completinha para evitar aquele atraso inventado de três semanas 00:01:01.360 --> 00:01:06.560 vai ser revelada para você agora mesmo, ainda nestes primeiros 60 segundos na nossa conversa. 00:01:06.560 --> 00:01:10.560 Olha só, na nossa leitura, montada sobre a aula escrita do portal, 00:01:10.560 --> 00:01:14.440 um pedido que realmente vira entrega tem esses três elementos aqui. 00:01:14.440 --> 00:01:19.080 Primeiro, um contexto que descreve o problema e o porquê, e não a solução pronta. 00:01:19.080 --> 00:01:22.480 Segundo, um critério de aceite numa frase que começa com 00:01:22.480 --> 00:01:26.160 está pronto quando e termina em algo que se confere no sistema. 00:01:26.160 --> 00:01:29.760 E terceiro, um prazo cuja troca está nomeada por escrito. 00:01:29.760 --> 00:01:34.240 Por baixo desses três, a gente precisa de uma linha de base medida antes da mudança 00:01:34.240 --> 00:01:36.320 e de uma resposta registrada por escrito, 00:01:36.320 --> 00:01:39.320 que é o que transforma a promessa num compromisso de verdade. 00:01:39.320 --> 00:01:42.880 Mas por que será que um pedido vago sempre vira uma entrega errada? 00:01:42.880 --> 00:01:47.040 A aula do portal observa sobre pedidos agentes de A, com estas palavras, 00:01:47.040 --> 00:01:50.680 a qualidade de um pedido depende de três partes observáveis. 00:01:50.680 --> 00:01:54.760 Objetivo claro, contexto suficiente e critério de revisão. 00:01:54.760 --> 00:01:58.880 Se uma delas falta, o agente preenche a lacuna com uma suposição plausível. 00:01:58.880 --> 00:02:02.640 Voltando à nossa leitura, com gente ocupada acontece exatamente o mesmo. 00:02:02.640 --> 00:02:06.400 E por isso, a culpa da entrega errada mora no espaço em branco do pedido. 00:02:06.400 --> 00:02:10.520 Lá no nosso exemplo inventado de corredor, o pedido nunca disse o que precisava dizer 00:02:10.520 --> 00:02:13.840 e a entrega simplesmente respondeu ao pedido que existiu. 00:02:13.840 --> 00:02:17.920 Um time técnico com fila não tem como devolver a pergunta que faltou. 00:02:17.960 --> 00:02:21.000 Então ele preenche a lacuna com a suposição plausível dele. 00:02:21.000 --> 00:02:22.720 Não é questão de competência de ninguém. 00:02:22.720 --> 00:02:23.760 A regra é clara. 00:02:23.760 --> 00:02:26.840 O pedido vago entrega a suposição de quem construiu. 00:02:26.840 --> 00:02:30.160 O pedido com contexto entrega a solução que o problema pedia. 00:02:30.160 --> 00:02:32.440 Vamos detalhar esse primeiro elemento. 00:02:32.440 --> 00:02:36.840 Na nossa leitura da produção, o pedido descreve o problema e o porquê 00:02:36.840 --> 00:02:39.200 e deixa a solução para quem vai construir. 00:02:39.200 --> 00:02:42.320 Voltando, por exemplo, à nossa cena inventada de corredor, 00:02:42.320 --> 00:02:45.520 o faz uma integração aí já era uma solução pronta. 00:02:45.520 --> 00:02:49.640 O problema real era que a equipe precisava ligar em poucos minutos para o contato 00:02:49.640 --> 00:02:51.360 e o dado demorava aparecer. 00:02:51.360 --> 00:02:56.400 Quem entende-se porquê consegue decidir detalhes técnicos que o pedido inicial nem previu. 00:02:56.400 --> 00:03:00.680 Por outro lado, quem recebe só solução pronta, executa o texto e devolva o texto. 00:03:00.680 --> 00:03:04.920 E tem mais, esse contexto ganha muita força com um detalhe prático. 00:03:04.920 --> 00:03:09.680 A aula ensina uma pergunta muito boa para fechamento de avaliação de ferramentas. 00:03:09.680 --> 00:03:13.600 E a gente aqui da casa aplica essa mesma pergunta ao próprio pedido, 00:03:13.600 --> 00:03:15.760 de onde vem cada informação. 00:03:15.760 --> 00:03:21.200 O número de volume que você citou veio de um sistema auditável ou da memória de alguém na reunião. 00:03:21.200 --> 00:03:26.320 Um pedido onde os números apontam a fonte de onde vieram poupa o time de construir em cima de dados 00:03:26.320 --> 00:03:31.200 não verificados e salva todo mundo de descobrir erros só na hora de entregar a chave. 00:03:31.200 --> 00:03:34.520 E o que garante que entrega resolve o problema de fato. 00:03:34.520 --> 00:03:38.840 Aí a gente entra no segundo elemento, o critério de aceite. 00:03:38.840 --> 00:03:43.800 É muito interessante usar a régua rigorosa da aula sobre o que define uma unidade aceita. 00:03:43.800 --> 00:03:50.360 Segundo a aula, uma unidade aceita precisa de contrato, critério verificável e janelas sem correção posterior. 00:03:50.360 --> 00:03:56.400 Isso fica muito visual no cenário didático da aula com números que a própria aula declara como suposições. 00:03:56.400 --> 00:04:02.360 Nesse cenário de avaliação, a unidade de aceite era a reunião que aconteceu com o registro no CRM. 00:04:02.360 --> 00:04:06.760 E faz todo sentido, porque o agendamento criado contabiliza o passo inicial. 00:04:06.760 --> 00:04:11.400 A reunião realizada com o registro no CRM contabiliza o ganho prometido. 00:04:11.400 --> 00:04:16.000 Como as duas contas são diferentes e essa diferença é a maior parte do ganho lá no exemplo, 00:04:16.000 --> 00:04:20.360 um aceite sem um lugar de verificação no sistema verá só uma opinião. 00:04:20.360 --> 00:04:24.280 A tradução da nossa casa para essa regra é bem direta na rotina de quem pede. 00:04:24.280 --> 00:04:30.240 Toda frase de aceite começa com está pronto quando e termina num sistema não numa impressão. 00:04:30.240 --> 00:04:36.880 Pensa no exemplo assim, está pronto quando o envio de teste aparece no CRM com os campos preenchidos. 00:04:36.880 --> 00:04:40.840 Essa estrutura simples que corta os debates subjetivos durante entrega. 00:04:40.840 --> 00:04:44.240 Agora, o terceiro elemento, o famoso prazo. 00:04:44.240 --> 00:04:47.320 Sobre prazo, a aula diz com estas palavras. 00:04:47.320 --> 00:04:51.120 Prazo, escopo e qualidade formam uma tríade. 00:04:51.120 --> 00:04:56.680 Ao pedir uma automação de captura de leads, pronta, até sexta, a pergunta seguinte deveria ser 00:04:56.680 --> 00:05:01.560 o que sai do escopo ou qual nível de teste será pulado para caber no prazo. 00:05:01.560 --> 00:05:06.840 E os casos de borda, como o mesmo contato enviar o formulário duas vezes, não desaparecem com a pressa, 00:05:06.840 --> 00:05:09.160 voltam como retrabalho em produção. 00:05:09.160 --> 00:05:16.240 Voltando à nossa leitura, essa pergunta é o pedaço do pedido que quase nunca se escreve e é o mais barato de acrescentar. 00:05:16.240 --> 00:05:20.840 Lá no cenário didático da aula, a pergunta sobre a troca arranca resposta honesta. 00:05:20.840 --> 00:05:25.600 Até cabe no prazo de sexta, mas sem passar por staging e sem o registro de operações. 00:05:25.640 --> 00:05:28.040 E não tem problema ter urgência, viu? 00:05:28.040 --> 00:05:30.880 Sobre a pressa, a aula diz com estas palavras. 00:05:30.880 --> 00:05:36.200 Prazo apertado tem lugar legítimo na operação, campanha sazonal exige velocidade 00:05:36.200 --> 00:05:39.800 e o marketing tem o direito de pedir isso sem pedir desculpa. 00:05:39.800 --> 00:05:44.680 O que muda a qualidade da decisão é nomear o que foi trocado por aquela velocidade, 00:05:44.680 --> 00:05:50.720 registrar a troca junto ao pedido e combinar quando o que ficou de fora volta para a fila. 00:05:50.720 --> 00:05:54.760 Voltando à nossa leitura, pressa com troca nomeada é gestão, 00:05:54.760 --> 00:05:57.760 pressa com troca muda é surpresa contratada. 00:05:57.760 --> 00:06:00.120 Só que qualquer mudança levanta uma dúvida. 00:06:00.120 --> 00:06:02.520 A gente está melhorando em relação ao quê? 00:06:02.520 --> 00:06:05.960 Sobre medir antes de mudar a aula diz com estas palavras. 00:06:05.960 --> 00:06:11.200 Sem linha de base medida antes da intervenção, todo resultado de IA vira depoimento 00:06:11.200 --> 00:06:14.120 e depoimento perde para a primeira pergunta cética. 00:06:14.120 --> 00:06:17.080 O mínimo viável é uma tarefa e cinco dias úteis. 00:06:17.080 --> 00:06:20.400 Com tempo de execução, tempo de espera medido em separado, 00:06:20.400 --> 00:06:25.400 volume, erro, com motivo e responsável registrados por quem executa no momento em que termina 00:06:25.400 --> 00:06:28.080 e a ferramenta em avaliação fica fora do período. 00:06:28.080 --> 00:06:32.680 Voltando à nossa leitura, a linha de base é o pedaço do pedido que protege quem pede 00:06:32.680 --> 00:06:36.120 porque define o número que o critério de aceite vai cobrar depois. 00:06:36.120 --> 00:06:38.280 E olha como é factível. 00:06:38.280 --> 00:06:41.080 O mínimo viável tem cinco dimensões. 00:06:41.080 --> 00:06:44.800 O tempo de execução, o tempo de espera medido em separado, 00:06:44.800 --> 00:06:49.440 o volume, o erro, com motivo e o responsável pelo registro. 00:06:49.480 --> 00:06:52.520 Você não precisa parar a empresa por um mês para medir isso. 00:06:52.520 --> 00:06:57.000 O mínimo viável da aula pede só uma tarefa e cinco dias úteis. 00:06:57.000 --> 00:06:59.560 Trazendo de novo aquele cenário didático da aula, 00:06:59.560 --> 00:07:04.440 onde os números são declarados como suposições, tem uma ficha de exemplo superlegal. 00:07:04.440 --> 00:07:08.840 Foram justamente cinco dias medindo que mostraram que a maior parcela do tempo de atraso 00:07:08.840 --> 00:07:12.000 estava concentrada na espera pelo primeiro atendimento humano 00:07:12.000 --> 00:07:14.360 e não no tempo de execução da digitação. 00:07:14.360 --> 00:07:16.120 É isso que o medir primeiro faz. 00:07:16.120 --> 00:07:18.600 Evita que você mire no problema errado. 00:07:18.640 --> 00:07:22.760 E para fechar o circuito do pedido, a gente precisa falar da resposta. 00:07:22.760 --> 00:07:28.080 O modelo de mensagem da aula pede as expostas em um documento com data e nome de quem respondeu 00:07:28.080 --> 00:07:31.720 e traz por escrito a preferência por registrar sem estimativa 00:07:31.720 --> 00:07:34.120 em vez de receber um número aproximado. 00:07:34.120 --> 00:07:35.960 Na nossa leitura aqui da produção, 00:07:35.960 --> 00:07:39.480 o sem estimativa escrito traz uma informação valiosa. 00:07:39.480 --> 00:07:42.280 O número aproximado verbal traz um fato falso. 00:07:42.280 --> 00:07:45.280 Saber que ninguém sabe o prazo é uma informação que muda de verdade 00:07:45.280 --> 00:07:47.560 e como você vai decidir lidar com aquilo. 00:07:47.600 --> 00:07:50.360 E a gente não está falando de burocracia pesada, tá? 00:07:50.360 --> 00:07:54.160 Na nossa leitura, a prática é rastro não-ata. 00:07:54.160 --> 00:07:56.320 Duas mensagens bem escritas, 00:07:56.320 --> 00:08:01.040 onde o pedido termina num lugar fácil de achar, bastam para ancorar o trabalho. 00:08:01.040 --> 00:08:05.480 É isso que transforma uma promessa falada num compromisso real. 00:08:05.480 --> 00:08:09.240 Quando a gente amarra tudo isso, a dinâmica inteira muda. 00:08:09.240 --> 00:08:13.200 As respostas passam a ser preenchidas no próprio encontro. 00:08:13.200 --> 00:08:17.400 E qualquer lacuna vira pendência com dono e prazo. 00:08:17.400 --> 00:08:20.160 Não uma suposição silenciosa. 00:08:20.160 --> 00:08:24.120 Na nossa leitura, a reunião para de disputar urgência 00:08:24.120 --> 00:08:27.680 e passa a decidir sobre trocas visíveis. 00:08:27.680 --> 00:08:30.480 E assim, a jornada destas seis conversas 00:08:30.480 --> 00:08:35.320 nos levou de entender a integração que se pede com contrato lá no episódio 1, 00:08:35.320 --> 00:08:37.560 a enxergar o custo total no 2, 00:08:37.560 --> 00:08:41.760 respeitar o dado pessoal no 3, cuidar do acesso no 4, 00:08:41.760 --> 00:08:43.680 passar pelo número que vai acomitê 00:08:43.680 --> 00:08:46.200 e passa pelo verificador no episódio 5 00:08:46.200 --> 00:08:51.120 e, por fim, chegar hoje na capacidade de transformar tudo isso em pedidos diários 00:08:51.120 --> 00:08:53.120 que virão entregas sólidas. 00:08:53.120 --> 00:08:55.920 Então, pra gente encerrar, fica a provocação. 00:08:55.920 --> 00:08:58.240 A sua próxima promessa de corredor 00:08:58.240 --> 00:09:01.160 já tá pronta pra verar um compromisso verificável por escrito? 00:09:01.160 --> 00:09:04.640 Pra ajudar nisso, ao terminar a leitura do material lá do portal, 00:09:04.640 --> 00:09:07.880 a pessoa consegue exigir a prova que transforma uma promessa verbal 00:09:07.880 --> 00:09:09.440 em um compromisso verificável. 00:09:09.440 --> 00:09:12.680 Eu convido todo mundo a voltar a aula escrita pra pegar as tabelas, 00:09:12.680 --> 00:09:15.080 os modelos de mensagem e o check list. 00:09:15.080 --> 00:09:17.480 Muito obrigado por acompanhar essa série com a gente 00:09:17.480 --> 00:09:19.080 e até a próxima análise.