Workflow app: Por que é a melhor alternativa ao kanban

À medida que as empresas evoluem e estabelecem seus próprios processos internos, geralmente procuram soluções de software que lhes permitam dimensionar esses processos, mantendo a “sensação” natural dos seus fluxos de trabalho. Como os processos geralmente são assuntos cronológicos, passo a passo, a maioria das pessoas muitas vezes sentirá que os pipelines (ou kanban) são os melhores meios disponíveis para transpor seus processos em ferramentas internas.

Como resultado, a maioria das ferramentas de produtividade, como Monday, Click Up ou Trello, são orientadas ao pipeline ou, pelo menos, terão um foco pesado na construção de pipeline para gerenciamento de projetos utilizando kanban. Essa é uma mentalidade herdada que surge do uso pesado de kanban em ferramentas de negócios essenciais, como CRM ou software de gerenciamento de projetos.

O problema com essa abordagem é que, embora um pipeline seja uma ótima maneira de representar visualmente o que é o processo geral, dificilmente é a melhor maneira de operar esse processo. Isso porque os pipelines são a maneira mais lógica de um builder projetar e percorrer um processo do início ao fim, mas os processos raramente são uma tarefa de um homem só. Em vez disso, são esforços de toda a equipe que devem ser cuidadosamente orquestrados, cada pessoa sendo responsável por seu próprio microprocesso e que quase nunca se beneficia da sobrecarga de informações que um pipeline gigante e unificado acarreta.

Então o Kanban é ruim? Não! Eles são uma maneira perfeita de estruturar processos e perfeitamente úteis ao lidar com fluxos de trabalho menores e mais simples. No entanto, se você deseja construir processos escaláveis, menos propensos a erros e que aumentem ao máximo a produtividade da equipe, vale a pena dividir seu pipeline em partes menores, com visualizações dedicadas para seções específicas do processo. Vamos analisar alguns casos clássicos em que os pipelines são interrompidos e os aplicativos florescem.

Caso 1: Trabalho em equipe síncrono

Vamos dar um passo atrás e falar sobre CRM e software de gerenciamento de projetos e por que o kanban geralmente funciona para eles.

Os CRMs clássicos geralmente assumem que um vendedor será responsável por um negócio do começo ao fim. Do Novo ao Vencido, cada vendedor ditará seu próprio ritmo e executará todas as tarefas relacionadas a esse negócio, trabalhando como seu próprio “coordenador de negócios”. Mesmo que precisem de ajuda externa (por exemplo, pedindo à equipe jurídica para enviar um acordo), eles simplesmente anotam que devem entrar em contato com a equipe jurídica em um ou dois dias. Cada pedaço de informação acionável no negócio pertence a eles. O trabalho é síncrono, mas principalmente um esforço individual.

O gerenciamento de projetos é o oposto. Você terá um card para um projeto específico e atribuirá tarefas aos membros da equipe. No entanto, o card em si no kanban é irrelevante. É mais um rastreador de progresso do que qualquer outra coisa. Normalmente, os membros da equipe realizam suas tarefas em paralelo, depois se reúnem diariamente ou semanalmente para registrar seu progresso e emitir novas tarefas. O ritmo é ditado pela equipe, não pelo pipeline, que atua mais como um registro de dados do que qualquer outra coisa. O trabalho é coletivo, mas assíncrono.

Mas o que acontece quando o trabalho em equipe síncrono está envolvido?

Imagine isso: 

• A equipe de vendas deve solicitar uma estimativa de custo de um projeto da equipe de finanças. 
• Em seguida, a equipe de vendas negocia com o cliente potencial antes de fazer uma proposta. 
• Depois que o cliente em potencial concordar, a equipe de finanças deve enviar um contrato para assinatura.
• Após a assinatura, a equipe de vendas deve integrar o novo cliente e, em seguida, passar o card novamente para a equipe de finanças, que ficará de olho no primeiro faturamento.

Como você pode ver, nesse processo, o responsável é trocado muitas vezes. Em um determinado momento, um negócio pode ser responsabilidade da equipe de Vendas ou Financeira.

A maneira como a maioria das pessoas vai resolver isso é criando estágios ou colunas extras em seu kanban e atribuindo proprietários a cada estágio. Isso funciona, mas não sem seus próprios problemas: o kanban se tornará excessivamente longo e ser o proprietário de vários estágios visualmente distantes aumenta as chances de algo “escorregar” exponencialmente. Mesmo ao tentar ser o mais metódico possível, é muito fácil perder uma ou dois cards ao olhar para um pipeline como um todo – especialmente se você não conseguir realizar suas tarefas correspondentes e movê-los imediatamente.

Adicionar muitos estágios a um kanban pode tornar um processo complicado (captura de tela do Trello)

Vamos dar um exemplo ainda mais complicado. Imagine uma sequência de tarefas que pertencem ao mesmo estágio, devem ser feitas em ordem, mas são distribuídas para pessoas diferentes. Por exemplo, para um projeto de novo site, a tarefa “Testar em produção” depende do “comprar domínio”. Nesse caso, não faz sentido criar novas etapas para o pipeline geral de Projetos. Afinal, isso é muito específico para este projeto em particular. Com um pipeline regular, é muito fácil perder esse momento de “passar o bastão”.

Adicionar estágios para tarefas específicas não é sensato… (captura de tela do Trello)

…mas mantê-los escondidos apenas dentro do card facilita se perder quando as coisas pegam (captura de tela do Trello)

Podemos resolver ambas as situações facilmente com aplicativos dedicados.

No primeiro caso, podemos criar aplicativos que são filtrados para ver apenas os registros de etapas específicas do kanban. Podemos até dar um passo adiante e criar diferentes mini-tabelas que já nos mostram os registros em cada etapa, juntamente com os campos relevantes para aquela etapa específica. Usando uma combinação de fórmulas e componentes, podemos adicionar coisas como mostrar quantos registros estão “travados” sem nenhuma atualização por mais de 2 dias e outras informações importantes e acionáveis.

No Jestor, você pode criar fluxos de trabalho baseados em kanban…

… mas também criar aplicativos que permitem operá-los melhor

No segundo caso, podemos fazer uma configuração semelhante. Mas agora, podemos usar automações para nos ajudar. Por exemplo, podemos vincular duas tarefas e, em seguida, fazer com que quando a primeira tarefa for concluída (neste caso, concluindo a tarefa), ela alterará o status do campo Aguardando da tarefa seguinte de marcada para desmarcada. Isso, por sua vez, fará com que apareça no aplicativo. A parte responsável saberá imediatamente que pode começar a trabalhar nele.

Ao automatizar a progressão de tarefas…

…podemos criar um aplicativo que mostra o que temos que fazer AGORA

A ideia aqui é que os aplicativos apresentem a você uma maneira de evitar que os membros da equipe sofram sobrecarga sensorial. Olhar para um amplo pipeline cheio de cards (de dezenas a centenas por estágio) pode ser assustador e uma receita para o desastre. É confuso, e muitas vezes as coisas são esquecidas ou não vistas. Para alguns processos, como Vendas ou Faturamento, é muito dinheiro que uma empresa pode perder apenas com as coisas que passam despercebidas.

Os aplicativos, no entanto, podem reduzir a gordura desnecessária do processo, para que as pessoas saibam que cada informação na tela é útil e acionável. Isso significa não mais procurar o que fazer. Em vez disso, o software dita o ritmo: se você o vê na tela, deve agir de acordo com ele.

Caso 2: Informações centralizadas

Outra maneira pela qual os pipelines geralmente não apresentam informações da melhor maneira possível é quando você precisa de dados conectados.

Por exemplo, imagine que você tem um banco de dados de Clientes e esses clientes podem aparecer em vários processos ao mesmo tempo. Por exemplo, eles podem estar em:

• O processo de vendas, aparecendo em vários negócios ao longo de sua vida.
• O processo de Cobrança, com um novo registro para cada fatura enviada.
• O processo de Suporte ao Cliente, que contém todos os tickets que eles abriram.

E assim por diante.

O software orientado a pipeline geralmente fornece boas ferramentas para construir esses processos específicos, mas não oferece uma maneira adequada de vê-los todos ao mesmo tempo com uma visão centralizada. No máximo, eles vão te mostrar todas as conexões existentes quando você abrir o cadastro do cliente, mas ver todas as informações ao mesmo tempo, sem nenhuma forma de filtrar ou priorizar o que é relevante, é pouco útil.

Nosso ponto é: pipelines são tubos. Eles são ótimos para conectar coisas em série (por exemplo, Vendas se conecta ao Faturamento), mas não são bons para centralizar informações.

Se isso não parece relevante para a construção de processos, considere o seguinte: muitos processos vitais para uma empresa são acionados subjetivamente. Ou seja, rotinas que dependem da análise caso a caso dos dados.

Vamos a um exemplo rápido: imagine que sua equipe de Customer Experience precisa fazer uma verificação diária de seus próprios clientes atribuídos e agir com base em alguns insights possíveis:

• Talvez um cliente seja um cliente recorrente, mas já se passaram três meses desde seu último negócio em potencial. Eles encontraram outro provedor de serviços?
• Outro cliente está atrasado nas duas últimas faturas, o que é um sinal de que eles podem se desligar em breve.
• Um terceiro cliente abriu dez tickets de suporte diferentes nas últimas semanas. Como isso afetou sua experiência geral?

Se tudo o que você tem são pipelines, o processo diário será mais ou menos assim:

• Abra o pipeline de vendas e verifique todos os cardss do cliente A.
• Abra o pipeline de faturamento e verifique todos os cardss do cliente A.
• Abra o pipeline de suporte e verifique todos os cards do cliente A.

Em seguida, faça tudo isso novamente para o cliente B e C, e assim por diante. As probabilidades são de que a exaustão fará com que o analista de experiência do cliente perca muitos insights em potencial e, na verdade, há uma chance ainda maior de que eles não tenham tempo para fazer isso com a diligência que deveriam para cada cliente. Pior, isso os deixa com ainda menos tempo para fazer seu trabalho real (de entrar em contato e construir um relacionamento com seus clientes designados). Pipelines são a pior ferramenta possível para o seu trabalho.

Abrindo cada pipeline para procurar clientes específicos… (captura de tela do Pipe)

… pode se tornar uma tarefa assustadora quando você começa a escalar (captura de tela do Pipe)

Os aplicativos, no entanto, são uma maneira maravilhosa de fornecer uma visão de águia de partes específicas da sua empresa. Com apenas uma rápida olhada, sua equipe pode verificar todos os negócios em andamento, histórico de cobrança e tickets abertos que um cliente possui. Isso pode reduzir o tempo gasto na busca de informações muitas vezes. Melhor ainda, adicionar novas informações que eles deveriam examinar quase não exige mais tempo e esforço de sua parte.

A criação de uma visualização centralizada

Enquanto o tempo gasto analisando informações de pipeline sempre é dimensionado linearmente, o tempo gasto examinando informações centralizadas sempre é dimensionado em incrementos cada vez menores.

Caso 3: Operações de campo e tarefas hiperfocadas

O último caso que apresentaremos é um caso comumente enfrentado por empresas que possuem operações físicas.

Os pipelines, assim como as planilhas, são suas principais ferramentas orientadas para o escritório. São estruturas genéricas criadas para receber dados de computadores. Você terá dificuldade em encontrar pessoas entusiasmadas com o uso de pipelines e planilhas em seus smartphones, o que pode ser um problema real ao tentar preencher a lacuna tecnológica entre o escritório e as operações de campo.

Para ser claro, isso também pode ser um problema com tarefas de escritório. Algumas equipes podem ter o que poderíamos chamar de operações hiperfocadas: tarefas tão simples que ao operar em um pipeline pode desacelerar significativamente as coisas e, na verdade, prejudicar as operações em vez de ajudar.

Vamos pensar em dois exemplos, um para operações de campo e outro para tarefas de escritório hiperfocadas.

No primeiro exemplo, vamos imaginar um armazém. Neste armazém, um oficial de expedição deve verificar os pedidos de itens específicos e despachá-los. O processo, então, é alterado para que eles tenham que atualizar as informações de estoque em uma planilha e atualizar a solicitação em um pipeline para que o escritório sempre tenha números e indicadores em tempo real. O que era uma tarefa relativamente simples com alta produtividade agora se tornou uma tarefa árdua.

A maneira como podemos fazer isso melhor é criar um aplicativo que mostre apenas solicitações acionáveis do pipeline e criar um botão que mova automaticamente o card e atualize as informações de inventário. O processo é tão rápido quanto antes, mas agora não há lacuna de dados entre o escritório e as operações de campo.

Agora vamos pensar em uma tarefa de escritório muito específica. Imagine um funcionário administrativo que precisa verificar se uma solicitação possui todas as informações necessárias e aprovar ou negar com base nessas informações. Nesse caso, poderíamos construir um aplicativo que mostre solicitações pendentes e criar botões com automação relevante. Por exemplo:

• Botão Aprovar: move o card ao longo do pipeline e envia um e-mail notificando o solicitante.
• Botão Descartar: move um card para Descartado e envia um e-mail notificando o solicitante.
• Enviar ao Supervisor: passa o card ao seu supervisor, que terá seu próprio aplicativo para avaliar e aprovar as solicitações.

Aplicativos hiper focados podem aumentar tremendamente a produtividade!

Ao criar aplicativos específicos, podemos efetivamente criar uma linha de fábrica na qual as pessoas podem ser ultra eficientes, porque informações não acionáveis ou não relevantes ficam ocultas. Tudo o que eles precisam fazer é ler e clicar em um botão, em vez de operar o pipeline, abrir cartões e assim por diante.

Devo abandonar os pipelines?

A resposta? Só se você quiser. Os pipelines não são inerentemente bons ou ruins, são ferramentas que podem ser bastante úteis se você souber como usá-los. No entanto, a mentalidade de tentar transformar cada processo e cada fluxo de trabalho em um pipeline é ruim. Por mais que o kanban seja apontado como um uso geral, recurso de aumento de produtividade, a verdade é que eles podem ser bastante prejudiciais e difíceis de operar se não forem usados ​​adequadamente.

Os apps oferecem a versatilidade para criar uma ferramenta realmente ideal para cada situação. Como eles podem trazer a você apenas as informações relevantes e ter um amplo subconjunto de ferramentas para escolher, você pode dividir os processos em microprocessos e otimizá-los de maneiras que um pipeline nunca poderia fazer adequadamente.

Na verdade, você pode até capacitar pipelines por meio de um kanban para seu aplicativo junto com outros componentes visuais, tornando os processos adequados para pipelines ainda melhores.