Em um famosa cadeia de lanchonetes conhecida mundo afora, dezenas de milhares de pedidos são feitos ao longo de um dia.

No início da sua operação, algumas décadas atrás, as pessoas faziam pedidos sem qualquer formalização. Os pedidos eram automaticamente enviados para a cozinha. O ponto de compromisso era imediato, assim que o cliente falava algo. “Um X-bacon e uma coca-cola”, e o pedido era comandado.

Inicialmente isso funcionou, mas com o crescimento da rede e novos funcionários sem experiência vários pedidos vinham errados e o retrabalho passou a operar acima de níveis aceitáveis. Tudo isso afetava a satisfação dos clientes, além de gerar prejuízos financeiros para a essa rede de lanchonetes.

Depois de algum tempo, o sistema para aceitar pedidos mudou. Quando um cliente chegava ele entrava na fila, um atendente o recebia e começava a organizar o pedido. Ele perguntava agora o sanduíche desejado, acompanhamentos como batatinhas fritas ou saladas com molhos, refrigerantes, sucos e sobremesas. Mas a cozinha não estava trabalhando para o cliente. Não ainda. Não existia formalmente nenhum compromisso. O ponto de compromisso não havia sido estabelecido. Apenas depois do pagamento realizado o pedido era comandado.

A Apólice de Seguros da Lanchonete

Veja as duas figuras do sistema de trabalho dessa lanchonete, modeladas como quadros Kanban.

Observe o papel do ponto de compromisso nas figuras. Ele separa as opções que chegam mais acima (Upstream Kanban) dos compromissos que devem ser honrados (Delivery Kanban). Se você quer saber mais sobre Upstream Kanban, a arma destruição em massa de POs e SMs, fiz um post sobre essa importante técnica aqui

Na primeira figura o ponto de compromisso (momento no tempo onde o pedido é formalizado pela cozinha) está muito mais acima.

Na segunda figura o ponto de compromisso desceu. Existe agora um processo de preparação do pedido. Existe um atendente que está ajudando os clientes a preparar o pedido. Observe que isso é custo, mas ele se justifica para evitar que pedidos errados entrem na cozinha, o retrabalho aumente e clientes fiquem insatisfeitos.

Formalmente, o ponto de compromisso é assim definido no método Kanban.

“O ponto do processo em que ocorre a transição entre as etapas de trabalho descomprometido e comprometido”, Portal KMM

Quando descemos o ponto de compromisso, estamos dizendo que iremos “investir” tempo e profissionais na qualificação da demanda. Isso é custo, que pode ser pensando como um equivalente a uma apólice de seguros.

Um Caso Real em um Equipe de Produtos

Quando desenvolvemos produtos, o trabalho que chega pode ser empurrado para o time. Se assim ocorre não existe ainda um ponto de compromisso e isso pode provocar os seguintes problemas:

• desequilíbrio entre a demanda e capacidade.
• pedidos mal qualificados
• pedidos que estão alinhados com a estratégia da organização
• retrabalhos diversos

Nesse time de produtos, cuja empresa vou chamar de ACME, todos esses problemas eram observados.

A liderança do time, após compreender o conceito de um ponto de compromisso derivado de seus estudos Kanban, orientou o time na introdução dessa técnica.

Em um sistema Kanban, para dizer que um item de trabalho está comprometido, ele deve atender a duas condições:

• (1) o cliente tem uma forte expectativa de que o trabalho em sua solicitação deve agora prosseguir para a entrega e está comprometido em receber (e pagar) pelo resultado;
• (2) a equipe de serviço tem capacidade disponível para realizar o trabalho e se compromete a começar a trabalhar e entregá-lo. O trabalho é puxado e não mais empurrado

Foi importante que o time definisse um critério para a preparação do trabalho. Inicialmente, apenas os requisitos eram previamente preparados. O retrabalho foi reduzido e o alinhamento com os OKRs da organização melhorou, mas ainda haviam problemas técnicos e de usabilidade. A apólice de seguros ainda não estava alta o suficiente para lidar com o risco.

Posteriormente, o ponto de compromisso desceu para depois da etapa de UX e arquitetura. Isso indicou que o time precisava “pagar” por um seguro maior antes que o compromisso com o cliente pudesse ser realizado. O efeito foi que em algumas semanas os problemas de natureza arquitetural e de usabilidade foram minimizados. O seguro se mostrou apropriado para mitigar o risco.

As figuras abaixo mostram a jornada nesse time de um trabalho empurrado para um sistema com pontos de compromisso bem delimitados.

• Momento 1

• Momento 2

• Momento 3

Tornar o ponto de compromisso explícito traz clareza e transparência ao processo de tomada de decisão. Remover a ambigüidade sobre o ponto de solicitação e o ponto de compromisso e esclarecer o significado de do “compromisso” torna o tempo de entrega do sistema e o tempo de entrega do sistema similares.

De volta ao time ACME, depois de alguns meses, a arquitetura de produto se tornou estável o o time subiu o ponto de compromisso novamente. Agora eventuais trabalhos de arquitetura eram realizados depois do ponto de compromisso. Havia maior confiança técnica compartilhada e o ponto de compromisso se moveu apropriadamente. Esse momento é mostrado abaixo.

• Momento 4
  

Ponto de Compromisso Como Apólice de Seguros

Um time ágil pode decidir que precisar investir 10% do seu tempo para qualificar demandas antes que ela sejam comprometidas.

Esse mesmo time pode resolver pagar ou menos nessa “apólice”, usando como fator decisor os problemas observados no seu fluxo de entrega.

Alguns sintomas comuns que já observei nos quadros de entrega e que podem orientar você em investir na sua apólice de seguros incluem:

• Muito retrabalho nas demandas
• Trabalho empurrado
• WIP sem controle
• Trabalho comprometido abortado com frequência
• Usabilidade pobre
• Impacto técnico subestimado

Em um sistema Kanban, então, se você quer aumentar a apólice de seguro você desce o ponto de compromisso. Mas se existe baixo risco você sobe o ponto de compromisso.

Resumo: Pense como o ponto de compromisso como um nivelador de risco. Riscos maiores exigem preparações maiores. Riscos menores sinalizam preparações menores.