Todo trabalho do conhecimento pode ser mapeado em um fluxo de trabalho, também chamado de fluxo de valor ou cadeia de valor (em inglês: value stream, value flow ou value chain). Seja em uma campanha de marketing, contratos, desenvolvimento de software, aquisição, etc., um fluxo é uma sequência de etapas necessárias para que uma ideia torne-se um produto, serviço ou aperfeiçoamento de ambos. Ao final de cada etapa, espera-se que o item que estamos trabalhando esteja mais perto de ficar pronto e ser entregue para o cliente.
Ouça este artigo!
Neste Artigo
Fluxo de Trabalho x Fluxograma
É importante diferenciar um fluxo de trabalho de um fluxograma. O primeiro é composto apenas por macro etapas com entradas e saídas bem definidas. Ao final de cada etapa vemos a evolução do item de trabalho (agregação de valor). Já o fluxograma é composto por cada atividade, opção, ação e atores envolvidos no processo que está sendo mapeado. Ele possui muito mais detalhes e consequentemente é um tanto mais complexo do que o fluxo de trabalho.
Por que preciso de um fluxo de trabalho?
Se você já trabalha há algum tempo, você deve perceber que há problemas no dia a dia da sua organização. Um erro comum que cometemos é tentar resolver problemas sem compreendermos o que realmente está acontecendo. Tendemos a dar soluções para problemas inexistentes ou, como gostamos de falar, responder perguntas que não foram perguntadas.
Há um nome para essa forma de agir: Viés da Ação (Action Bias). Ele acontece quando estamos em frente a um cenário ambíguo, comum ao trabalho do conhecimento, e partimos para alguma ação sem fazermos nenhum tipo de avaliação sobre o problema. Inclusive, nesses casos, investir tempo para compreender o cenário em que estamos é visto como contraproducente. O resultado é que acabamos criando mais problemas do que tínhamos anteriormente.
Obviamente, há o extremo oposto a isso, fazer uma super análise de cada variável possível no trabalho do conhecimento e só dar uma solução quando tudo estiver devidamente verificado. Nesse caso temos a Parálise por Análise também conhecida como Big Design Up Front (BDUF). Ela acontece quando estamos com tanto medo de tomar uma ação que ficamos analisando, analisando, analisando, criando um plano "infalível" que jamais será executado.
O mapeamento do fluxo de trabalho é o primeiro passo de um bom caminho para visualizar o que estamos fazendo. Aliás, quando estudamos o método Kanban, essa deve ser uma das primeiras práticas antes de tentarmos soluções mirabolantes. Esse desenho parte da forma atual como trabalhamos.
Muita atenção à forma atual . Não comece a desenhar o fluxo como hipotéticamente seu time / empresa gostaria de trabalhar. A partir dessa visualização, podemos identificar onde estão os problemas e atuar para resolvê-los, seja algo pontual ou sistêmico.
Como mapear um Fluxo de Trabalho?
Existem diversas abordagens sobre como mapear um fluxo de trabalho. Desde os mais tradicionais como o Mapofluxograma ou, como é mais conhecido, Mapeamento do Fluxo de Valor (MFV, também muito conhecido pela sigla inglesa VSM - Value Stream Mapping), uma das disciplinas de Lean Manufacturing, até o empirismo, quando o fluxo é montado de forma desestruturada.
Particularmente, gosto muito do Systems Thinking Approach to Implementing Kanban (Statik, utilizando tradução livre, Abordagem de Pensamento Sistêmico para Implementação de Kanban). É uma forma estruturada e ágil para compreender e visualizar o fluxo de trabalho do seu time / squad e organização. Não discutirei muito esse assunto, mas deixo este, este e este links que falam bastante sobre o Statik. Tem também o nosso treinamento de Kanban System Improvement (KSI) que pode te ajudar nesse tema.
Independente da forma, imagine que você está olhando para o Rio do Fluxo de Trabalho. O fluxo começa na chuva de hipóteses (piscina de opções), vai para a nascente (upstream) é construído no leito (midstream) e sai do fluxo pela foz do rio (downstream) e produz um resultado financeiro. A alegria do seu cliente com o uso do produto ou serviço é como se fosse o sol. Ele esquenta a água (itens entregues) ela se transforma em vapor (feedback do cliente) e isso forma novas hipóteses que irão descer o rio em breve. Esse é o ciclo do True Agile (Verdadeiramente Ágil).
O seu fluxo deve mapear o rio do True agile que está contido ou contém o trabalho do seu time.
O final desse mapeamento é o desenrolar (roll out) quando o fluxo se transforma em um quadro e conseguimos torná-lo palpável tanto para o nosso time quanto para os clientes e stakeholders.
Esteja atento
Independente do método adotado para dar visibilidade ao fluxo de trabalho, é importante se atentar para alguns pontos importantes.
Como as coisas são feitas hoje.
Um erro comum é tentar definir um fluxo incompatível com o trabalho realizado. Algo que é muito desejado, porém não é conforme feita hoje. Por exemplo, Vicente acredita que antes de entregar o serviço para um cliente, seria importantíssimo ter uma etapa de avaliação da alta administração. Ele é um cara influente e consegue angariar adeptos para a sua ideia. Todos concordam que a etapa Aprovação da Alta administração deve fazer parte do fluxo.
"Você combinou com os russos?" Foi a pergunta feita pelo Garrincha, atacante da seleção brasileira na Copa de 1958, ao técnico Vicente Feola após este apresentar um esquema tático "brilhante" que funcionaria somente se a seleção da União Soviética fizesse exatamente o que estava no plano do técnico brasileiro. O Vicente do nosso exemplo tem o mesmo problema. Não combinou com a alta administração e agora o fluxo de trabalho visualiza algo que inexiste.
Se o time resolver obedecer à etapa desejada, porém inexistente, nada andará. Eles deixarão de ver sentido no quadro já que ele não é uma representação do trabalho deles.
Você pode trocar essa aprovação da alta administração por qualquer etapa imaginária do fluxo que seja apenas um desejo ao invés de um fato.
Para fugir disso, utilize um princípio básico do Kanban. Comece com o que você faz hoje. Faça mudanças evolucionárias de forma colaborativa. O seu fluxo de trabalho é um reflexo da realidade e nunca o contrário.
Nomenclatura no Fluxo
Opções
Quando um stakeholder (cliente, gestores, product owner, product manager) apresenta um desejo, não saímos correndo para fazê-lo de forma atabalhoada. Antes, essa manifestação de desejo deve ser capturada, sintetizada e analisada até chegar o Ponto de Comprometimento quando ela passa a ser chamada de item de trabalho. Antes disso, no Upstream são apenas opções.
Item de Trabalho
Uma vez que a opção foi aceita e passou pelo Ponto de Comprometimento, ela recebe o nome de item de trabalho e são eles que navegam no Midstream e no Downstream. Eles são uma parte do produto ou serviço que eu consigo disponibilizar para o cliente. Por exemplo, uma História de Usuário.
- Hospital: um paciente
- Pizzaria: Uma pizza
- Software: uma funcionalidade ou modificação em uma funcionalidade existente
- Jurídico: A petição ou o andamento do processo.
- Marketing: Campanha em uma rede social ou um item de papelaria que será enviado para a gráfica.
Tarefas
Atenção, pois o item de trabalho pode ser “quebrado” em tarefas técnicas. Tarefas não são itens de trabalho, pois isoladamente não podem ser utilizadas pelo cliente. São exemplos de tarefas:
- Hospital: aplicação de um remédio
- Pizzaria: mussarela, tomate, massa (ingredientes isolados)
- Software: criação de uma tabela no banco de dados, criação da interface (front end).
- Jurídico: As partes de um documento peticional, uma ida ao fórum.
- Marketing: Texto, imagem, wireframe (itens isolados)
Cada tarefa pode ser algo importante para compor um item de trabalho, porém eu não consigo entregar para o meu cliente essas tarefas isoladas.
Ponto de Recebimento da Demanda
Esse é um acréscimo ao artigo original, pois houve uma alteração na definição do Customer Lead Time. A partir de abril de 2023, ele passou a ser computado desde o Ponto de Recebimento da Demanda até o Ponto de Entrega. Esse primeiro é o momento em que o cliente manifesta a necessidade de ser atendido por um serviço que prestamos. Resumidamente é o momento em que ele faz o pedido e este pedido entra no nosso fluxo de trabalho.
Ponto de comprometimento
Aqui há um conceito importantíssimo. Em qual etapa do fluxo, você e seu time se comprometem a prestar o serviço para o seu consumidor (cliente, outros times ou outro stakeholder)? A partir de quando vocês dizem: "Ei, cliente, chefe, outro time, podem contar conosco para entregar este item de trabalho!"
O ponto de comprimento é uma forma de gerir expectativas do cliente ou stakeholders que consomem os serviços fornecidos pelo seu time. Pense nas seguintes situações: A) Qual é o ponto de comprometimento quando você entra em um hospital? B) Qual o momento de comprometimento quando você pede um serviço na TI da sua empresa? C) Qual é o ponto de comprimento quando você pede uma pizza por telefone?
Se você respondeu: A) Quando eu entrei no hospital; B) Quando eu abri um ticket; C) Quando a telefonista atendeu a ligação. Você errou. Essas são apenas manifestações da vontade do consumidor, são os pontos de recebimento da demanda, mas não indicam que o fornecedor do serviço se comprometeu com ele. Na verdade, os pontos seriam: A) após a triagem do paciente; B) após análise, classificação e priorização do ticket; C) após combinar o pedido, forma de pagamento e endereço de entrega.
O ponto de comprometido é algo que deve ser definido pelo time (ou squad) em conjunto com clientes e stakeholders. Da mesma forma que não há casamento solo e o noivo tem que combinar com a noiva tudo antes e ambos devem estar de acordo para assumir o compromisso. O ponto de comprometimento entre o time e quem precisa do time deve ser um acordo.
Ponto de Entrega
Quando você entrega seu serviço? Isso também precisa ser definido com clareza. Quando o produto do seu trabalho sai da sua mão e chega na mão do seu cliente? Muitas das vezes não é você que realiza a entrega, mas seu mapeamento deve visualizar as etapas necessárias para tal para que você não fique com um monte de trabalho processado, sem que ele seja entregue ao cliente. Imagine que essa é a passagem de bastão (handoff) do seu produto entre sua organização para o seu cliente.
Cuidado quando você presta serviços internos à organização. Por exemplo: infraestrutura de TI, manutenção predial, Gestão de Pessoas / Recursos Humanos etc. Nesses casos, seus clientes tendem a ser internos. Não caia na falácia dos resultados indiretos. Por exemplo, dizer que a nova fachada do prédio ajudou a aumentar o lucro da empresa em 5%. Pode até ser verdade, mas como você provaria isso? Se não tem uma relação direta, não invente.
Upstream
Uma vez que compreendemos o fluxo de trabalho, o ponto de comprometimento e o ponto de entrega, podemos ver os conceitos que facilitam o mapeamento e avaliação do fluxo.
Todas as etapas que estão antes do ponto de comprometimento compõem o Upstream (nascente do rio). Nela temos opções (ideias e pedidos) que estamos avaliando para ver se iremos ou não nos comprometer com as ideias. É comum que essas etapas compreendam as fases de captura de opções, síntese e análise. No upstream estamos preocupados em descartar as ideias ruins e detalhar as boas para que elas se tornem compromissos. As opções podem ser facilmente desconsideradas, pois ainda não há esforço e investimento de construção sobre elas.
Infelizmente ainda é comum essa parte do fluxo ser ignorada e as opções saírem de uma piscina de ideias e viajarem direto para o comprometimento. Acabamos com um monte de penduricalhos em nossos produtos e serviços que pouco ajudam a atender às necessidades dos clientes ou, até mesmo, atrapalham. Fora o refluxo (retorno do item) para esclarecimento porque é necessário mais compreensão sobre o mesmo.
Quando os times (squads) não são ponta a ponta (responsáveis pelos itens de trabalho desde o upstream até o downstream) é possível que tenhamos times diferentes no upstream fornecendo serviço para o downstream. Por exemplo: o time de experiência do consumidor define o fluxo de uma aplicação que será construída por um time de desenvolvimento. O mesmo acontece no downstream quando o time de construção não é o mesmo responsável por fazer a entrega. Esse é um caso de dependência externa que trataremos um pouco mais a frente.
Midstream
Na literatura do Kanban não há um midstream. Para esse método, tudo que vem após o ponto de comprometimento é o downstream. Entretanto, nós da K21 preferimos separar este em dois. O midstream (leito do rio) é onde acontece o trabalho de construção. O Upstream transforma a ideia (opção) em um item de trabalho. O Midstream começa no Ponto de Comprometimento e transforma primeiro o item em um item de trabalho comprometido. Ao final do midstream temos um produto, serviço ou incremento de ambos.
Para exemplificar, quando estamos desenvolvendo um software é o momento em que o item de trabalho (pode ou não estar no formato de história de usuário) se transforma em incremento do produto. No caso da pizzaria, é a pizza pronta, assada e embalada, no hospital é o paciente tratado e pronto para receber alta. Em contratos é o contrato escrito e pronto para ser assinado. Ou ainda, uma campanha de marketing é quando ela está pronta, só falta a publicação.
Downstream
Finalmente chegamos na foz do fluxo. É o momento em que o item é entregue (delivery) para o cliente. O software é disponibilizado para os consumidores, a pizza é entregue pelo motoboy ou motogirl, o paciente recebe alta e se despede na portaria do hospital, o contrato é apresentado para a assinatura do cliente e a campanha de marketing vai para o público.
Nós preferimos separar essa parte do midstream porque ela, tradicionalmente, requer conhecimentos e processos específicos que não estão relacionados à construção. Embora não seja a melhor solução, em muitas empresas, esse serviço de entrega (delivery) é feito por um time diferente do de construção (midstream).
O problema da dependência externa
O ideal de um time / squad é que ele possua pessoas com conhecimentos, acessos e autorizações necessários para navegar do upstream até o downstream. O chamado time ponta a ponta. Quando isso não acontece, temos a dependência externa. Ela se caracteriza pela necessidade do item de valor ter que ir para uma pessoa, grupo ou unidade que não está contido no time que está construindo o produto. Eles são externos ao time.
Ficamos com vontade de encerrar o fluxo quando atingimos essa dependência. Em uma pegada no estilo: "se não há nada que eu possa fazer, logo não farei nada."
Não ver o problema não resolve o problema. Enquanto o seu cliente não tiver a possibilidade de utilizar o seu produto ou serviço, ele não produziu resultado (métricas de eficácia). Um produto ou serviço sem valor é um produto ou serviço sem valor. É apenas esforço e custo sem retorno. Sendo assim, as dependências externas devem ser mapeadas para que possamos visualizar problemas, gargalos e pontos de melhoria.
E no Scrum?
Você viu esse texto e pode estar se perguntando. Isso é bem Kanban. Não aparece enxerguei no meu Scrum. Todavia, isso também faz parte do Scrum. Está lá, porém normalmente exclusivo. Mesmo que você utilize um quadro básico com: A Fazer, Fazendo e Feito. Lembrando que o Scrum não te obriga a ter um quadro com apenas essas três etapas. Você pode e deve especializar o seu fluxo.
Esse seria um exemplo de Fluxo do Trabalho do Scrum. As ideias surgem como uma piscina de opções e são armazenadas de forma despriorizada no backlog. A reunião de refinamento é justamente a etapa do fluxo em que as ideias (opções) são verificadas e avaliadas e ficam disponíveis para serem “puxadas” para dentro da Sprint durante a Sprint Planning. Se o time utilizar a Definição de Preparado (Definition of Ready - DoR), ao final do refinamento, o item de trabalho deve estar de acordo com ela.
O ponto de Comprometimento do Scrum é costumeiramente a Sprint Planning (Planejamento da Sprint). O ponto de entrega continua sendo quando o item se torna disponível para o cliente.
A pergunta que vem é: Quando posso considerar pronto? Há times que são ponta a ponta e o pronto deles é entregue para o cliente. Muitas vezes durante a execução da Sprint, assim que o item de trabalho se torna compatível com a Definição de Pronto (Definition of Done - DoD). É bom lembrar que o Scrum não diz que é necessário esperar a Sprint Review (Revisão da Sprint) para entregar um item de trabalho para o cliente. Se o item ficar pronto no primeiro dia da Sprint e não houver objeção do Product Owner (PO), o item pode ser entregue para o cliente.
Infelizmente o mais comum são times que não conseguem entregar seus itens de trabalho ao final da Sprint. O Definition of Done fica em algum lugar entre o Feito (construído) e a entrega para o cliente. A Sprint acaba, porém a entrega (downstream) continua até chegar na mão do cliente.
Curiosidade
Essa analogia do Fluxo de Valor como um rio foi criada pelo Rodrigo de Toledo, sócio fundador da K21, em 2011. A primeira versão foi feita no Power Point e ganhou o carinhoso apelido de: “Imagem do Riozinho”. Alguns a chamam de “Rio Nilo” porque as montanhas pareciam pirâmides. Tal observação agrada muito o criador da imagem 😀 #sqn.
Quer saber mais sobre Fluxo de Trabalho? Assista à palestra Porque do Scrum ao Kanban!
