Da Pareidolia ao Processo: As 3 leis de construção de processos

Humanos são criaturas de padrões e repetição. Na verdade, vemos significado nos padrões mesmo quando não há nenhum. Assim, há um nome para a tendência de ver padrões em objetos ou ocorrências aleatórias: pareidolia.

Pareidolia é algo simples de entender. É o ato de ver um rosto quando olhamos para uma tomada elétrica, formas de animais em nuvens ou uma figura religiosa em uma fatia de pão. Não estamos ativamente tentando encontrar essas formas. Nosso cérebro transforma automaticamente essas formas estranhas, mas familiares, em coisas que reconhecemos.

A razão para um mecanismo tão peculiar é simplesmente que ele é mais eficiente. Vemos o padrão antes de vermos as formas ou atributos individuais. É parte do motivo pelo qual você pode reconhecer as pessoas tão rápido, embora mal consiga lembrar a cor dos olhos delas. É a mesma coisa quando lemos: um leitor proficiente verá as palavras antes das letras e até mesmo entenderá o significado de frases completas sem reconhecer palavras individuais.

O problema disso, é claro, está na perda de qualidade. Todos podem desenhar um rosto sorridente com dois pontos e uma linha curva. No entanto, são necessários anos de prática e estudo das características individuais de um rosto para que um artista desenhe um retrato realista.

Por exemplo, vamos imaginar um aspirante a artista chamado Davi.

O sonho de Davi era desenhar retratos. Para isso, ele decide começar a copiar fotos de sua família. Logo, ele atinge seu primeiro platô: ele pode fazer uma réplica quase perfeita de uma imagem, mas não pode desenhar alguém da imaginação. Sempre que ele tenta, sai errado. As peças individuais estão lá, mas parecem erradas.

Davi então decide estudar características individuais: lábios, nariz e olhos. Seus desenhos melhoraram visivelmente, mas ainda parecem estranhos, de alguma forma. Mas então, ele tem uma epifania: ele entende que desenhar não é apenas sobre as características individuais em si, mas há outra coisa que dita quão bom será o resultado final: perspectiva. Ou melhor, como as peças individuais se relacionam entre si.

É apenas quando Davi domina este último conceito que ele pode realmente criar boa arte a partir do zero.

Quando falamos em processos, algo semelhante ocorre.

Toda empresa tem processos e, a princípio, é normal que esses processos sejam equivalentes ao desenho do rosto sorridente. Eles são uma impressão de como o processo deve ser, criado por pessoas que ainda não sabem o suficiente sobre as partes individuais para criar com sucesso uma boa estrutura.

A progressão natural para a empresa é tentar melhorar esse processo inicial (que provavelmente surgiu organicamente) implementando uma estrutura genérica existente (como Agile ou Orçamento Base Zero). Isso melhora muito a eficiência do processo, mas ainda não é a solução mais eficiente para essa empresa específica. Por quê? Porque processos genéricos nunca podem levar em conta diferenças individuais.

O salto final para a eficiência total só é alcançado com um processo feito sob medida que leva em consideração cada característica / problema individual da empresa e é projetado em torno deles.

Como você pode ver, isso é muito semelhante à jornada do Davi como artista.

Essas semelhanças podem ser divididas em etapas e definem os quatro estágios para equipes autônomas e verdadeiramente capacitadas:

Aspiração → Replicação → Entendimento → Criação

Aspiração: neste estágio, temos uma compreensão bruta do que estamos tentando alcançar. Este é o estágio da pareidolia, onde entendemos e implementamos os padrões apesar das falhas nas características individuais.

Replicação: nesta etapa, reconhecemos que falta o processo, mas não sabemos como melhorar. Tentamos copiar as grandes empresas, com vários graus de sucesso.

Entendimento: neste estágio, sabemos que copiar só nos levará até certo ponto. Aqui, estudamos os porquês e como, e até conseguimos mudar as estruturas existentes de acordo com as nossas necessidades.

Criação: nesta fase, finalmente entendemos o suficiente para criar soluções específicas para nossos problemas. É aqui que desenvolvemos nosso próprio estilo de arte, aquele que se encaixa em nossos objetivos.

A ideia da metodologia do jestor é ensinar a você como ir da mera Pareidolia ao Processo.

Dados como blocos de construção

Os processos são únicos, mas geralmente são constituídos da mesma coisa: dados.

Pense na própria realidade. Você e seu smartphone são coisas muito diferentes, mas podem ser divididos em pedaços menores até que você obtenha os mesmos blocos de construção. A matéria se transforma em moléculas, que se transformam em átomos, que se transformam em quarks. A diferente disposição e finalidade desses blocos de construção é o que os faz parecer diferentes, mas eles são fundamentalmente os mesmos. A forma como eles se relacionam é o que lhes dá significado.

Os processos são os mesmos. Não importa o propósito, tudo se resume a dados organizados. Se você achar isso estranho, vamos imaginar um pipeline de suporte ao cliente por um momento e nos aprofundar na primeira etapa: um cliente abrindo um tíquete de suporte.

À primeira vista, o cliente e seu tíquete podem parecer duas coisas muito distintas. Mas, na verdade, eles são apenas grupos de dados repetidos.

Um cliente pode ser caracterizado por um nome, endereço de e-mail e plano de assinatura.

Um ticket pode ser caracterizado por um ID, o problema e as etapas até a resolução.

Como tal, podemos escrevê-los no seguinte formato:

[clientes: nome, email, plano]

[tickets: id, problema, status]

Como você pode ver, embora eles se comportem de maneira diferente e tenham funções diferentes no processo, ambos podem ser escritos como grupos de informações. Chamamos eles de blocos de construção.

Os blocos de construção têm um formato muito específico: eles têm sempre uma etiqueta e o que chamamos de caixas. Caixas são coisas que podem ter um valor dentro. No exemplo do tíquete, o ID é uma caixa: pode ser # 0001, # 0002 e assim por diante.

Observe que não poderíamos ter algo como:

[status: novo, em curso, concluído]

Por quê? Porque novo, em curso e concluído não são caixas. Eles são os próprios valores.

O segredo para a construção de processos é reconhecer esses blocos de construção e como eles se conectam. Não se preocupe, voltaremos a isso (mas você já pode tentar adivinhar como tíquetes e clientes se relacionam).

As três leis de construção de processos

Os entusiastas da ficção científica devem estar familiarizados com o conceito das Três Leis. Para os não iniciados, elas são um conjunto de três regras criadas pelo autor Isaac Asimov e ditam o comportamento dos robôs: não importa o que um robô foi ordenado a fazer ou fez por sua própria vontade, ele não pode quebrar essas três regras.

As regras são:

Primeira Lei: um robô não pode ferir um ser humano ou, por inação, permitir que um ser humano sofra algum dano.

Segunda Lei: um robô deve obedecer às ordens dadas por seres humanos, exceto quando tais ordens entrem em conflito com a Primeira Lei.

Terceira Lei: um robô deve proteger sua própria existência, desde que tal proteção não entre em conflito com a Primeira ou a Segunda Lei.

As histórias de robôs de Asimov geralmente giravam em torno das três regras. Ou melhor, a conclusão natural de seguir essas regras em muitas situações diferentes.

Dica: Recomendamos fortemente que você leia ‘Eu, Robô’. Não será realmente necessário para este curso, mas é um livro excepcional.

Assim como as regras de Asimov não podem ser quebradas, descobrimos que existem três regras que sempre devem ser seguidas para a construção do processo, ou o caos seguirá. São leis simples, mas que geralmente são ignoradas por criadores de processos novatos. Isso é porque elas não são naturais. Você verá que elas contradizem diretamente nossos instintos quando se trata de organizar nossos pensamentos. Mas, mesmo que pareçam arbitrárias e restritivas, recomendamos que você as siga. Elas o manterão focado no caminho correto e, de muitas maneiras, você descobrirá que essas restrições são, na verdade, bastante libertadoras.

Primeira Lei: um construtor deve pensar linearmente, mas construir paralelamente

Os processos geralmente podem ser escritos em ordem cronológica. Dê uma olhada no exemplo abaixo:

E-mail Frio → Reunião → Proposta → Negociação → Encerramento

No que diz respeito aos processos de vendas, este é bastante direto. Claro, ele poderia ser expandido para conter uma série de etapas diferentes, mas agora, vamos nos concentrar em como é simples. Deve ser muito fácil transformar isso em um processo, certo?

Como um processo cronológico (ou seja, algo que se move em etapas), podemos decidir que a melhor visualização para isso é um kanban, e os estágios desse kanban são as etapas do processo. Seguindo esse raciocínio, podemos acabar com algo assim:

Nossa! Até parece um CRM comum. Devemos estar no caminho correto, certo?

Claro, apenas ter o nome de um cliente movendo-se em um pipeline não é particularmente bom. Precisamos de mais dados para que isso seja realmente útil para nós. Como exercício, podemos pensar em informações que seriam úteis:

• E-mail e número de telefone do cliente;
• Valor do negócio;
• Data da reunião;
• Data de acompanhamento;
• Proposta .pdf.

Nosso primeiro instinto é construir isso diretamente no cartão do kanban. Se tentássemos escrever isso como um bloco de construção, obteríamos algo como:

[negócios: id, nome do cliente, e-mail do cliente, telefone do cliente, valor, data da reunião, data de acompanhamento, proposta, status]

Por um tempo, essa estrutura pode até funcionar. Mas, à medida que utilizamos este CRM simples, veríamos alguns problemas surgirem naturalmente:

• A equipe de faturamento precisa das informações do cliente, mas não necessariamente das outras informações do negócio;
• Podemos ter várias propostas à medida que a negociação prossegue e gostaríamos de manter todas elas armazenadas em algum lugar;
• Podemos precisar de várias reuniões antes de fechar o negócio;
• A equipe de vendas perde facilmente o controle dos acompanhamentos e do histórico do cliente.

Poderíamos dar à equipe de faturamento acesso ao pipeline de vendas e criar um novo campo de dados para cada acompanhamento adicional e data de reunião. Se fizéssemos isso, nosso bloco de construção seria mais ou menos assim:

[negócios: id, nome do cliente, e-mail do cliente, telefone do cliente, valor, proposta, status, data da reunião 1, data da reunião 2, data da reunião 3. . .]

Que horror. Isso ficará bastante confuso rapidamente. É o equivalente a ter uma planilha com mais de 30 colunas quando a maioria delas não é realmente necessária. O problema aqui é que embora o processo seja linear, as partes em si não são. Vamos tentar quebrar esse mega bloco de construção em pedaços menores.

Podemos fazer isso fazendo duas perguntas:

1. Esta informação será usada em outro lugar? (ou melhor: é independente?)
2. Haverá várias linhas repetíveis para o mesmo processo?

Para tornar isso mais prático, vamos começar com o próprio negócio:

[negócios: id, nome do cliente, e-mail do cliente, telefone do cliente, valor, data da reunião, data de acompanhamento, proposta, status]

Existem três caixas que estão diretamente relacionadas às informações do cliente: nome, e-mail e telefone.

[negócios: id, nome do cliente, e-mail do cliente, telefone do cliente, valor, data da reunião, data de acompanhamento, proposta, status]

A primeira pergunta que devemos fazer é: essa informação poderia ser usada em outro lugar? E a resposta é sim. A equipe de faturamento precisará das informações do cliente, assim como a equipe de sucesso do cliente, por exemplo. Este é um grande indicador de que as informações do cliente não devem estar nas caixas de um negócio, mas sim em um bloco de construção separado, como:

[clientes: nome do cliente, e-mail do cliente, telefone do cliente]

Em seguida, temos o valor do negócio. Nesse caso, você deve ter apenas um e é um número insignificante fora do contexto do negócio em si, então isso indica que o valor nada mais é do que uma caixa do negócio.

Então chegamos à “data da reunião”. É um tipo de informação que provavelmente não será usada isoladamente, mas como já dissemos, provavelmente poderíamos ter muitas reuniões para um único negócio. Esta é uma boa indicação de que as reuniões devem ser um bloco de construção. Podemos até expandi-lo para conter mais de uma data:

[reuniões: data, tipo, notas]

Da mesma forma, podemos ter muitos acompanhamentos vinculados ao mesmo negócio. Não apenas acompanhamentos: talvez haja outras tarefas importantes, como enviar propostas ou elaborar orçamentos. Vamos fazer um bloco de construção genérico para isso:

[tarefas: prazo, tipo, proprietário, status]

As propostas devem seguir uma estrutura semelhante:

[propostas: valor, anexo]

Por fim, a transação deve ter apenas um status atual e, como são informações que não fazem sentido por si só, deve ser apenas uma caixa do bloco de construção “transações”.

O produto final será mais ou menos assim:

Agora, você pode estar se perguntando onde estão as informações do cliente. Bem, decidimos que “clientes” devem ser blocos de construção por si próprios, certo? E, na verdade, um cliente pode ter mais de um negócio durante sua vida. Portanto, toda a estrutura deve ser semelhante a esta:

Com essa estrutura, basicamente estamos avaliando que:

1. Um cliente pode ter mais de um negócio;
2. Um negócio pode ter mais de uma reunião, tarefa ou proposta.

Isso garante que os dados sejam organizados da maneira mais escalável possível. Não importa se uma transação tem uma tarefa e a outra mil: a estrutura sempre será a mesma e não haverá necessidade de alterá-la.

Tudo bem, então como transformamos a imagem acima em um sistema escalável? Você pode ver que cada bloco de construção aponta para outro bloco, exceto para “cliente”. Portanto, ao construir um bloco de dados, você deve manter esta relação em mente: aponta para, ou se conecta a. Vamos indicar isso com uma seta para cima (↑).

Então nós temos:

[clientes: nome do cliente, e-mail do cliente, telefone do cliente]

E depois:

[negócios: id, valor, status, ↑ cliente]

E a última linha é:

[reuniões: data, tipo, notas, ↑ negócio]

[tarefas: prazo, tipo, proprietário, status, ↑ negócio]

[propostas: valor, anexo, ↑ negócio]

Esta não é uma maneira natural de pensar sobre os processos. Estamos acostumados com a construção linear, ou o que gostamos de chamar de lógica de workspace.

A lógica de workspace determina que tudo relacionado a um processo deve ser construído dentro do mesmo local e conter todas as informações. Parece sensato, mas não é a melhor maneira de construir processos escaláveis. Os processos modulares, baseados em blocos de construção, ajudam a organizar as informações, em camadas de acordo com a relevância e torná-las acessíveis em qualquer lugar, sem que os processos interfiram uns nos outros.

Se eu quiser ver as informações do cliente, realmente não preciso ver negócios específicos, mas devo ter acesso a elas.

Se eu quiser ver um acordo específico, eu realmente não preciso ver todas as reuniões, tarefas e propostas, mas devo ter acesso a elas.

Portanto, a conclusão natural para a lógica de workspace levará você a algo assim:>

Que é… útil na melhor das hipóteses. Pode até fazer o trabalho, mas é muito confuso. Há muitas informações desnecessárias visíveis ao mesmo tempo, e se eu tiver que obter alguma informação individual (como o número de telefone do cliente), ela estará sempre anexada a um negócio específico, mesmo que possa existir por conta própria.

A construção paralela, no entanto, lhe dará algo assim:

Você notará que todas as informações são facilmente acessíveis, mas priorizadas e organizadas. Na verdade, temos muito mais campos de dados no segundo exemplo, mas o processo em si é menos confuso. Se eu quiser ver todas as propostas, elas estão bem organizadas em uma tabela dedicada que posso filtrar e pesquisar facilmente para encontrar o que preciso.

Segunda lei: um construtor deve usar um design direcionado para os resultados

A segunda lei parece óbvia à primeira vista, mas é algo em que os criadores novatos de processos inconscientemente falharão: um bom processo não deve coletar dados supérfluos, nem sair de seu caminho para preservar hábitos ruins.

Existe um ditado famoso que incentiva os autores a “matar seus queridinhos”. Não é tão dramático quanto parece: simplesmente afirma que não importa o quanto você ame um personagem, cena ou parte do enredo, você nunca deve permitir que isso atrapalhe a história.

Os processos funcionam de maneira semelhante.

Não é incomum que os processos tenham partes “legadas”, partes que existem não porque são úteis, mas porque de alguma forma conseguiram entrar na primeira iteração do processo e ninguém realmente se preocupou em retirá-los.

O problema aqui é que os processos orgânicos pareidólicos têm uma tendência a acumular. A maneira natural de resolver problemas é manter o que funciona e adicionar novas peças. Como resultado, os processos tendem a crescer de estruturas brandas para complexos gigantescos e, de repente, você se depara com um carro que tem três motores, sete rodas, onze espelhos retrovisores e ninguém sabe ao certo por quê. Essas partes legadas continuam se acumulando, atrapalhando o processo.

Normalmente, essas peças existem por um dos seguintes motivos:

1. Alguém realmente gostou da ideia, apesar de não haver necessidade real dela. Todos nós já passamos por isso. Por algum motivo, a equipe de vendas realmente precisa saber o signo astrológico do cliente em potencial, apesar de nunca ter usado essa informação para nada.
2. Essas partes já foram necessárias, mas não são mais. Um exemplo clássico é imprimir um documento e pedir a assinatura de um gerente, apesar de todas as outras partes do processo serem estritamente digitais, ou mesmo importunar um cliente por um segundo número de telefone porque o ERP anterior o exigia para o registro.
3. Eles fazem parte de uma estrutura genérica. Isso é o equivalente ao falso senso comum. Quer dizer, todo CRM deve ter “temperatura do lead”, certo? Na verdade, não, a menos que você planeje agir sobre isso.

Agora, o problema com as peças legadas é que é realmente difícil justificar o descarte. Quer dizer, sempre esteve lá, então deve ter um propósito, certo? Ao construir processos, temos a tendência de olhar para todas as informações de entrada que temos / coletamos e tentar obter o melhor resultado possível com elas.

Essa mentalidade, é claro, prepara você para construir processos de má qualidade. É o equivalente a olhar para cada coisa em sua geladeira e se perguntar como encaixá-las numa salada de frutas, mesmo que tudo o que você tenha seja bife. Bons processos, no entanto, começam ao contrário: você deve primeiro definir os resultados desejados e só então descobrir as entradas e etapas necessárias.

Como exercício, vamos imaginar um processo de compra simplificado. Vamos passar pelo processo de legado e, em seguida, passar pela Segunda Lei para ver como podemos melhorá-lo.

O curioso caso de Butterscotch Bottles

Butterscotch Bottles são garrafas comestíveis com sabor de caramelo. Como parte de seu rigoroso processo de fabricação, eles compram apenas os melhores ingredientes dos fornecedores mais confiáveis. Ainda assim, cerca de 5% dos ingredientes que compram ainda não estão de acordo com seus padrões, então eles decidiram implementar um processo de Controle de Qualidade para suas compras.

Eventualmente, um processo surge organicamente:

1. O comprador emite um pedido de ingredientes;
2. Os ingredientes chegam ao armazém;
3. O inspetor imprime o formulário com cada item pedido;
4. O inspetor examina cada item, procurando defeitos;
5. Inspetor preenche formulário com itens defeituosos;
6. Os itens restantes são armazenados para uso futuro. Os itens defeituosos são jogados fora e o fornecedor é contatado para substituição.

O formulário na etapa (5) pode ser parecido com este:

Formulário de Inspeção

Pedido: #0376

1. Açúcar – 100 kg – OK
2. Manteiga – 20 kg – Parcialmente OK
3. Sal – 50kg – Parcialmente OK

Notas:

• 1kg de manteiga NÃO ESTÁ OK;
• 3kg de sal NÃO ESTÁ OK.

Bom, isso pode funcionar por enquanto, mas com o passar do tempo a empresa pode decidir que esse processo deve ser digital, pois o método atual de impressão de formulários está gerando muito lixo e é difícil de organizar.

Nossa primeira versão do processo digitalizado será uma solução com foco no legado: isto é, manter o processo como está.

Solução Legada

Se pensarmos neste processo em blocos de construção, obteremos algo assim:

• Você tem um fornecedor que tem um pedido (ou mais).
• Você tem um pedido que:
  • Aponta para um fornecedor;
  • Pode ter muitos itens;
  • Pode ter um formulário de inspeção.
• Você tem itens que:
  • Apontam para um pedido.
• Você tem um formulário de inspeção que:
  • Aponta para um pedido;
  • Pode ter muitos itens com defeito.
• Você tem itens com defeito que:
  • Apontam para um formulário.

Ao pensar sobre os rótulos e caixas, você deve obter algo como:

[fornecedores: nome, endereço, e-mail, número de telefone]

[pedidos: id, quantidade, status, ↑ fornecedor]

[itens: nome, quantidade, ↑ pedido]

[formulário: ↑ pedido]

[itens com defeito: nome, quantidade, ↑ formulário]

A solução será mais ou menos assim:

Faz sentido, certo? No entanto, ainda há partes legadas no processo que não precisam estar lá. Você consegue identificá-las?

Solução Direcionada aos Resultados

Se pensarmos sobre o resultado desejado do processo, podemos expressar o problema da seguinte forma:

“Quero que meu fornecedor substitua os itens com defeito.”

Portanto, como o resultado do meu processo é o número de itens com defeito, preciso de alguém para inspecionar os itens. Para que alguém inspecione os itens, a empresa deve ter feito um pedido de um fornecedor. Linearmente, será mais ou menos assim:

Fazer pedido → Esperar pela chegada → Inspecionar itens

Nessas etapas, eu sei que:

• “Número de itens com defeito” é uma parte necessária do processo, porque é isso que o fornecedor precisará substituir.
• “Fornecedor”, “Pedido” e “Itens” são partes necessárias do processo porque são inerentes à própria compra.

O formulário, no entanto, é uma parte do legado. A única razão para isso é porque o processo era anteriormente feito à mão em uma folha de papel impressa. É um artefato que só é realmente necessário por conta das limitações impostas pelo software / recursos.

Além disso, quando você pensa sobre o formulário, não é apenas um bloco legado em si, ele também cria outros dados legados: por que os “itens com defeito” deveriam ser blocos de construção, se eles apenas refletem os itens comprados com uma quantidade diferente?

Poderíamos cortar totalmente o formulário e alterar os itens comprados de:

[itens: nome, quantidade, ↑ pedido]

Para algo como:

[itens: nome, quantidade comprada, quantidade com defeito, ↑ pedido]

Ao mesclar “itens com defeito” nos “itens” do pedido e cortar o formulário, nosso processo ficará mais ou menos assim:

Agora, quando o pedido chega, o inspetor só precisa preencher a Quantidade Defeituosa de um item, quando necessário e, em seguida, alterar o status do pedido para Inspecionado.

Esse processo é mais enxuto, tem menos etapas e é mais fácil de organizar. Ao abrir o pedido, o número de itens com defeito é apenas uma camada de dados abaixo, em vez de duas, e a relação entre itens comprados e itens com defeito é muito mais clara.

Usando o Design Direcionado aos Resultados, você pode entender quais partes do processo são realmente necessárias e quais partes legadas podem ser cortadas.

Terceira Lei: um construtor deve se concentrar no processo mínimo viável

O que acontece com as empresas é que elas são entidades complexas, com muitos objetivos e necessidades. Como resultado, eles terão muitos processos em andamento ao mesmo tempo.

Às vezes, esses processos se alinham e parecem uma única entidade.

Por exemplo, podemos ter a equipe de marketing criando anúncios para atrair leads ao site da empresa. Uma visão simplificada desse processo será mais ou menos assim:

A entrada desse processo é a definição de uma estratégia (desconto para assinaturas anuais, por exemplo) e a saída desse processo são os novos leads que chegam ao site. Eles podem ajustar a estratégia para resultados diferentes, como mais leads ou melhores leads, mas se essa equipe de marketing existisse no vácuo, os blocos acima são as únicas coisas que importariam para suas rotinas diárias.

Depois, temos a equipe de vendas: seu trabalho é contatar os leads e convertê-los em clientes pagantes. Uma visão simplificada desse processo seria mais ou menos assim:

Você deve ter notado que o resultado do processo de Marketing é a entrada para o processo de Vendas. Então, ao esboçar o processo que está tentando construir, você pode estar inclinado a fazer algo assim:

Mas você se lembra que “clientes pagantes” é a entrada necessária para a equipe de faturamento e a equipe de experiência do cliente, então você esboça as próximas etapas:

E em algum momento você percebe que há um processo para entrar em contato com negócios perdidos depois de um tempo e tentar convertê-los em clientes pagantes também. A entrada é “Negócios perdidos”, que vem direto do meio do processo de vendas…

Como você pode ver, as coisas estão começando a ficar bem complicadas.

Se tentarmos transformar o esboço acima em um processo, há uma série de coisas que podem dar errado:

• Transbordar: conectando processos em um megaprocesso antes de construí-los individualmente, você aumenta as chances de criar blocos de construção errados. Por exemplo, você pode construir um único kanban complexo que contém as informações do cliente, bem como os estágios de Vendas e Experiência do cliente, tornando mais difícil / confuso para ambas as equipes operar o kanban, não importa a dor de cabeça que causaria para o Departamento de faturamento (a melhor solução, é claro, seria ter dois kanbans diferentes que apontassem para o cliente potencial / cliente).
• Projeto direcionado às entradas: conforme o processo cresce, torna-se cada vez mais difícil pensar nos resultados necessários e trabalhar de trás para frente para encontrar as entradas necessárias. Afinal, a relação entre “Estratégia de Marketing” e “Enviar fatura” não é imediatamente clara, pelo menos não tão clara quanto “Cliente pagador” e “Enviar fatura”. Portanto, como resultado, tendemos a descartar o Design Direcionado aos Resultados e a construir com base nas entradas possíveis.

Você pode notar que o Transbordar é uma consequência da não aplicação da Primeira Lei. Na verdade, é exatamente o oposto disso: Transbordar nada mais é do que pensar paralelo e construir linearmente. Da mesma forma, o Design Direcionado às Entradas é o oposto da Segunda Lei.

De certa forma, a Terceira Lei é uma forma de garantir que você não infrinja as duas primeiras leis. Contanto que você se concentre nos processos mínimos viáveis, não terá dificuldade em criar os melhores blocos de construção e deixar que os resultados desejados guiem seu projeto.

Então, se em vez de pensar em um megaprocesso, eu dividir o esboço em muitos processos mínimos viáveis, eu obteria algo como:

• Marketing;
• Vendas;
• Cobrança;
• Experiência do cliente;
• Reengajamento de transações perdidas.

Esses são processos muito mais gerenciáveis ​​de construir. Eles são mais curtos e autoexplicativos. E a questão é: contanto que eu me lembre de construir em paralelo e criar os blocos de construção certos, posso começar a construir o processo na ordem que quiser.

Eu poderia, por exemplo, começar com o faturamento se for urgente e só então construir o processo de vendas. Isso ocorre porque o faturamento pode ser um processo autônomo que começa com uma lista manual de “clientes pagantes” e, desde que tenha essa entrada, deve funcionar sem problemas. Então, quando eu construir o processo de vendas, eu poderia alimentar seu resultado para a equipe de faturamento apenas conectando os blocos de construção corretos.

Claro, há também um efeito colateral maravilhoso de se concentrar em processos viáveis ​​mínimos: adaptabilidade. Esses processos modulares podem ser expandidos, trocados, desligados ou reescritos sem afetar os outros processos. Ao almejar escalabilidade, a Terceira Lei garante que uma empresa pode se mover rapidamente sem quebrar mais coisas do que o necessário.

Processo como narrativa

Para encerrar este guia, recomendamos que você se considere não apenas um criador de processos, mas também um contador de histórias. Seu trabalho não é apenas criar a melhor estrutura possível, mas ajudar os atores a navegar por ela sem problemas.

Na escrita, há um conselho comum ao criar personagens: um personagem deve sempre querer algo, não importa o quão pequeno seja. Pode ser a derrubada de um governo corrupto, mas também pode ser algo tão simples quanto comprar uma bicicleta nova. Não importa: o que importa é que, quando um personagem deseja algo, todas as ações que realizam geralmente visam atingir seu objetivo.

Quando você apresenta a alguém um processo, eles seguem o mesmo raciocínio: se o trabalho do Executivo de Contas é fechar negócios, cada ação que eles tomarem será algo que eles sentem que os aproxima de fechar um negócio. Isso significa:

1. Sempre deve ficar claro o que eles têm que fazer para avançar para o próximo passo, ou então seu instinto será ficar parado em vez de agir;
2. Coisas que não são necessárias para esse objetivo geralmente serão ignoradas. Isso significa que se você quiser que o Executivo de Conta colete o site do lead, mas isso não é necessário para fechar o negócio, é provável que ele nunca se importe com isso.

É por isso que tudo é importante: rótulos, caixas, a ordem das informações, quais informações são necessárias para avançar para a próxima etapa. Tudo deve ser construído com intenção. Em qualquer ponto do processo, deve estar claro como seguir em frente:

• Você quer fechar negócio? Envie a proposta;
• Você quer criar uma postagem no blog? Envie o primeiro rascunho;
• Você quer comprar um item? Obtenha orçamentos de fornecedores.

É por isso que as Três Leis são importantes:

1. Ao construir o paralelo, você garante que os dados estejam sempre organizados e fáceis de acessar, caso alguém precise deles em uma etapa;
2. Usando design direcionado aos resultados, suas etapas serão otimizadas para atingir uma meta, ajudando o usuário final a entender o caminho a seguir;
3. Ao focar no processo mínimo viável, a estrutura é projetada para a jornada individual de cada usuário, e não mais que isso.

E então, quando a estrutura em si é finalmente construída, você pode pensar nela como o equivalente a um primeiro rascunho: ela estabelece os personagens e deixa claro qual é o propósito da história, mas deve ser editada e melhorada até que você obtenha uma bom romance. Em um primeiro rascunho, os romances geralmente têm muitos pontos de atrito: blocos pesados ​​de exposição, diálogos desnecessários, diálogos travados. Eles atrapalham a jornada do leitor para ver o personagem alcançando seus objetivos e são cortados durante a fase de edição.

Em processos, o atrito geralmente surge na forma de etapas desnecessárias e tarefas repetitivas. Se você tem seguido as Três Leis, você já se livrou dessas etapas desnecessárias, mas as tarefas repetitivas também podem ser eliminadas por meio de automações.

As automações agilizam o processo e permitem que as pessoas se concentrem em seguir em frente, em vez de se prenderem à repetição e ao trabalho manual. É a etapa final em direção a um processo totalmente eficiente, em que os atores não estão gastando seu tempo na burocracia, mas sim tomando decisões.

Lembre-se que as automações devem servir ao processo, e não o contrário. Um processo que dispensa as Três Leis por uma automação geralmente fará a equipe perder toda a eficiência que ganhou por ter algo automatizado. Em alguns casos, novos processos irão surgir organicamente para contornar a automação, porque mesmo os processos pareidólicos são melhores do que processos burocráticos sem sentido.

Como construtor de processos e contador de histórias, lembre-se sempre de que, se as pessoas não entenderem sua história, elas criarão suas próprias.