Como Criar Agilidade nos Projetos (com Dimitar Karaivanov, da Kanbanize)

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoem quaisquer erros de digitação, pois o sistema automático não está correto 100% das vezes.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Parece-lhe familiar? Bem, estes são apenas alguns dos modelos existentes para implementar métodos ágeis. Mas qual é o melhor e porquê? Continue a ouvir este podcast para compreender como pode criar agilidade nos seus projetos e conhecer os benefícios de uma abordagem e de um conjunto de ferramentas kanban.

Obrigado por nos acompanhar. Eu sou Ben Aston, fundador do Digital Project Manager. Bem-vindo ao podcast DPM. Temos como missão ajudar os gestores de projetos a ter sucesso e ajudar as pessoas que gerem projetos a obter melhores resultados. Estamos aqui para o ajudar a elevar a gestão dos seus projetos a um nível superior. Visite thedigitalprojectmanager.com para saber mais sobre a nossa formação e os recursos que disponibilizamos através da adesão. Este podcast é-lhe apresentado pela Clarizen, líder em software empresarial de gestão de projetos e portefólios. Visite clarizen.com para saber mais.

Hoje estou acompanhado por Dimitar Karaivanov. O Dimitar é um engenheiro que se tornou CEO e é cofundador da Kanbanize. É um pensador lean, praticante de kanban e tem experiência em desenvolvimento de software e melhoria de processos. Escreveu alguns livros: Desenvolvimento de software lean com Kanban e Como o Kanban de portefólio pode beneficiar o seu negócio. Creio que já percebeu. É apaixonado por Kanban. Olá, Dimitar, obrigado por se juntar a nós hoje.

Dimitar Karaivanov:

Ben, obrigado pelo convite. É um prazer falar consigo e com o seu público. Estou, por isso, ansioso por este podcast.

Ben Aston:

É ótimo tê-lo connosco. É evidente que é extremamente apaixonado por Kanban e que construiu todo um produto em torno da Kanbanize. Mas, no seu papel de CEO, tenho curiosidade em saber o que isso significa na prática. Como é um dia típico para si enquanto CEO e cofundador da Kanbanize?

Dimitar Karaivanov:

Enquanto CEO da empresa, especialmente numa empresa em fase avançada de arranque, desempenhamos muitos papéis. Normalmente, falo com muitos clientes, uma vez que frequentemente assumo responsabilidades de gestão de produto.

Ben Aston:

Certo.

Dimitar Karaivanov:

Depois, falamos com a equipa de engenharia para transmitir o feedback que recebemos dos clientes. Também participo nas vendas empresariais. E, naturalmente, dedico-me à estratégia sempre que o tempo o permite, porque é uma parte importante do trabalho dos CEO. Aliás, a estratégia também pode ser aplicada com Kanban. Talvez devêssemos reservar alguns minutos para falar sobre isso.

Ben Aston:

Sem dúvida. Mas antes de nos debruçarmos sobre isso, tenho curiosidade em conhecer melhor a sua origem. Como começou a desenvolver software de gestão de projetos?

Dimitar Karaivanov:

Normalmente, isso acontece por necessidade. Eu era o agente de mudança de uma grande empresa alemã. Estávamos a fazer a transição de processos em cascata para processos ágeis e passámos cerca de 500 pessoas da antiga forma de gerir projetos para o Scrum. O Scrum tornou-se uma norma para qualquer nova implementação ágil. Formámos toda a gente em Scrum. Tínhamos cerca de 25 equipas ágeis ou mais, mas descobrimos que, embora as equipas conseguissem entregar de forma relativamente estável, ao nível da gestão era um caos, sobretudo nas partes maiores do trabalho — no nosso caso, funcionalidades, épicos e elementos semelhantes. Percebi que nos faltavam ferramentas para gerir tanto o nível das equipas como o nível de gestão e coordenação. Foi assim que nasceu a Kanbanize, com o objetivo de expandir a agilidade por toda a organização.

Ben Aston:

Muito bem. Ao iniciar e desenvolver uma ferramenta de gestão de projetos, deve ter-se inspirado noutras ferramentas de que gostava, bem como em ferramentas de que não gostava e que o levaram a pensar que precisava de criar uma própria. De onde veio essa inspiração inicial?

Dimitar Karaivanov:

Nessa empresa utilizávamos o JIRA. É o grande Godzilla de 300 quilos que encontramos em todo o lado. Tem muitas funcionalidades interessantes. Mas a parte visual, sobretudo há oito ou nove anos, estava ausente ou era muito limitada. Embora tivesse muitos bons conceitos, a verdadeira inspiração para perceber como podíamos expandir o Kanban e a agilidade por toda a organização veio mais de um quadro kanban físico. Com a Kanbanize, tentámos reproduzir a forma como se visualiza o trabalho num quadro kanban físico, acrescentando o facto de ser digital, poder ligar várias equipas e agregar dados para que a gestão possa analisar a informação e tomar decisões fundamentadas. Na realidade, foram duas ferramentas: o JIRA e os quadros kanban físicos.

Ben Aston:

Certo. E, obviamente, a Kanbanize é a sua própria ferramenta de gestão de projetos, mas gostaria de saber com que outras ferramentas a Kanbanize se integra ou que utilizam em paralelo para gerir a empresa.

Dimitar Karaivanov:

Não dispensaria o Microsoft Teams, porque penso que é a aplicação com o crescimento mais rápido da história da Internet. É uma ferramenta extraordinária que também utilizamos com a Kanbanize. Passo muito tempo no Teams, especialmente agora que trabalhamos todos remotamente. Depois, provavelmente passo metade do dia numa ferramenta chamada Flow-e. Está disponível em flow-e.com e, curiosamente, é uma ferramenta da nossa empresa. É a Kanbanize aplicada ao email: uma camada de visualização sobre o Outlook que transforma a caixa de entrada num quadro kanban, permitindo visualizar os emails e manter as conversas numa vista semelhante ao Kanban. Para mim, é indispensável. Literalmente, não conseguiria trabalhar sem esta ferramenta, por isso recomendo-a. É gratuita, portanto qualquer pessoa pode experimentá-la.

Ben Aston:

Vou experimentá-la. Neste momento tenho 1189 emails por ler. Por isso, se ainda não respondi, já sabe. Isso iria para a minha coluna “a ler”.

Dimitar Karaivanov:

Foi precisamente assim que criámos o Flow-e: era demasiado doloroso gerir todos os fluxos de informação. Recomendo-o.

Ben Aston:

Vou experimentar. Muito bem. Falemos da Kanbanize. É o CEO da Kanbanize e esta foi a sua criação, juntamente com a equipa inicial da empresa. Já percebemos que é um quadro kanban digital que, por ser digital, melhora a previsibilidade, fornece análises e dados e permite utilizar determinadas regras. Mas qual é o mercado ideal para a Kanbanize? Quem utiliza a ferramenta da sua empresa?

Dimitar Karaivanov:

Fomos concebidos especificamente para empresas de engenharia: engenharia de software, operações de tecnologias de informação, ou engenharia não relacionada com tecnologias de informação, como fabrico, construção e áreas semelhantes. Temos muitos clientes de sucesso no setor da engenharia, mas também somos utilizados por equipas de marketing e operações, por exemplo, na banca ou nos seguros. Também somos uma excelente solução nesses casos. Existem geralmente dois tipos de utilização: a gestão de projetos, que inclui a engenharia, e a gestão de serviços, que inclui a banca e os seguros. Esses são os clientes ideais. Quando falamos de gestão de projetos, posso desenvolver mais este tema, se quiser.

Ben Aston:

Força.

Dimitar Karaivanov:

Na minha experiência, existe um desafio real: os profissionais de gestão de projetos tendem a planear e estimar os projetos e, depois, esse plano é convertido em tarefas ou itens de trabalho que normalmente ficam noutro sistema. Temos um plano perfeito num PowerPoint ou no Microsoft Project, mas o trabalho real vive no JIRA ou noutro local.

Ben Aston:

Certo.

Dimitar Karaivanov:

Como se obtém informação sobre o estado real? Não há outra forma senão perguntar pelo estado.

Ben Aston:

Sim.

Dimitar Karaivanov:

E depois incomodamos as pessoas: até onde chegámos? Qual é a percentagem de conclusão desta tarefa? Por isso, dissemos que podíamos resolver o problema com Kanban e, especificamente, com a Kanbanize, ligando o planeamento à execução. Na Kanbanize, temos uma camada específica onde se planeia o trabalho e outra onde o trabalho é executado. As duas estão ligadas e trocam feedback. Quando a equipa começa a trabalhar em algo, a informação é automaticamente transmitida à camada de gestão onde se encontra o plano. Se percebermos, por exemplo, que o plano vai falhar, notificamos o gestor de projetos, que fica automaticamente a saber que há um problema. Em vez de esperar uma semana, perguntar pelo estado e descobrir depois que estamos atrasados, recebe simplesmente esta notificação e pode agir. É bastante útil.

Ben Aston:

Recebe uma notificação a dizer que o seu projeto vai falhar. É um aviso educado, mas deve ser o email que todos temem: aconteceu um desastre e está atrasado. Muito bem. Penso que o cerne da questão está nas pessoas da equipa. Qualquer ferramenta só é tão boa quanto a atualização que as pessoas fazem dela. O desafio que está a resolver é que o gestor de projetos tem de perguntar a várias pessoas em que ponto estão numa tarefa, para poder atualizar os seus gráficos de Gantt. Mas isto exige que as pessoas envolvidas no projeto atualizem os próprios cartões. Presumo que também exista controlo de tempo. Na minha experiência com ferramentas como o JIRA, as pessoas esquecem-se de atualizar cartões e estados. Como é que conceberam o sistema para obter uma visão em tempo real do que as pessoas estão realmente a fazer e para as incentivar a atualizar o estado das tarefas?

Dimitar Karaivanov:

Tem razão. Esse é um problema. A forma de o resolver é recorrer ao método kanban. O método kanban é um vasto corpo de conhecimento. Não é apenas um quadro branco na parede. Existe todo um conceito chamado Modelo de Maturidade Kanban, que codifica mais de 150 práticas comuns. Se alguém tiver interesse, deve consultar o KMM, o Modelo de Maturidade Kanban, para compreender o que significa uma implementação kanban madura. Dito isto, há um elemento do método kanban chamado ciclos de feedback. São reuniões regulares, diárias, semanais, mensais ou trimestrais. Uma delas é a reunião kanban diária, ou reunião diária de acompanhamento, na qual a equipa se coloca em frente do quadro.

Se for um quadro digital, pode existir um ecrã grande com o quadro visualizado. Analisamos cada cartão que está atualmente em curso e falamos sobre o seu progresso. Não falamos sobre a pessoa e sobre o que fez ontem ou hoje. Falamos sobre o trabalho. O que aconteceu com este cartão? Foi atualizado? Precisa de ser movido? Está na posição certa? Assim, garantimos que, pelo menos uma vez por dia, os cartões são movidos para a posição correta.

Ben Aston:

É uma boa abordagem. Também é interessante o foco no trabalho, e não na pessoa. Muitos ouvintes já terão participado em reuniões diárias em que se pergunta: o que fez ontem? O que vai fazer hoje? Tem algum impedimento? Utilizamos uma ferramenta chamada Standuply, que é uma integração muito interessante para o Slack e coloca essas perguntas à equipa todos os dias. É uma boa forma de realizar uma reunião diária assíncrona. Mas existe um problema: as pessoas dizem frequentemente a mesma coisa. O que fez ontem? Trabalhei no componente. O que vai fazer hoje? Vou continuar a trabalhar no mesmo componente. Há algum impedimento? Não. E, no fim, não obtivemos informação adicional. Concentrar-se no trabalho e não na pessoa é uma sugestão útil. Obrigado. Mas, relativamente ao JIRA e ao Trello, que também é uma ferramenta kanban, gostaria de saber em que medida considera que a Kanbanize é diferente das outras ferramentas existentes.

Dimitar Karaivanov:

Voltaria a referir o KMM. O Modelo de Maturidade Kanban fala de seis níveis de maturidade. Cada nível corresponde a práticas diferentes, desde as mais simples às mais complexas. Ferramentas como o Trello conseguem levar uma equipa ao nível um ou dois, porque não têm as funcionalidades necessárias para uma implementação kanban completa. Por exemplo, o Trello não possui limites de trabalho em curso totalmente funcionais. É possível obtê-los através de complementos, mas, mesmo assim, são limitados. Numa ferramenta kanban adequada, como a Kanbanize, pode limitar-se o trabalho em curso em várias colunas, faixas horizontais, quadros, pessoas e equipas. Existe uma forte ênfase nas funcionalidades kanban.

Relativamente às métricas, também não se obtêm diretamente as métricas de fluxo necessárias, como diagramas de ciclo, diagramas de trabalho bloqueado ou simulações de Monte Carlo para fazer previsões com base na produtividade histórica. É possível obtê-las através de complementos, normalmente pagos, que acrescentam custos. E, francamente, muitas vezes não funcionam suficientemente bem. São peças retiradas de ferramentas diferentes e reunidas sem grande integração. Posso resumir dizendo que a Kanbanize se destina a cenários kanban sofisticados, sobretudo quando falamos de expansão por toda a organização e de permitir que a gestão sénior tome decisões fundamentadas. O Trello é uma ferramenta de equipa, excelente para uma equipa, mas torna-se mais difícil quando se ultrapassa esse âmbito. No JIRA é possível fazer mais, mas a abordagem depende sobretudo do Scrum e não do mecanismo de recolha de dados subjacente ao Kanban.

No JIRA, as previsões baseiam-se na velocidade histórica: os pontos acumulados obtidos em cada sprint. Mas isso depende inteiramente da previsão e da perceção da equipa. No Kanban, as previsões baseiam-se no que realmente aconteceu, ou seja, na produtividade histórica. Pode parecer uma diferença pequena, mas, quando se tenta implementar isto em 20, 30 ou 40 equipas, percebe-se rapidamente que os pontos significam coisas diferentes para cada equipa. É preciso normalizar, o que se torna um pesadelo. No mundo kanban, fazemos previsões com base no que realmente acontece. Essa é uma diferença fundamental e, na minha opinião, muito importante.

Ben Aston:

Olhando para o Kanban a um nível mais elevado, o que o Dimitar descreveu são alguns dos princípios subjacentes: o sistema kanban procura aumentar o fluxo, minimizando o número de coisas em que trabalhamos em simultâneo. Quando falamos em limitar o trabalho em curso, queremos que as pessoas se concentrem mais, em vez de tentarem fazer seis coisas diferentes. O objetivo é concluir uma tarefa e entregá-la antes de dividirmos a atenção por outras três tarefas. Quem já trabalhou numa agência com vários clientes conhece bem este cenário: vários clientes a serem tratados em simultâneo e prazos que entram em conflito. A ideia do Kanban é que, ao reduzirmos o número de coisas em que trabalhamos, podemos aumentar o fluxo e a eficiência. Fazemos isso limitando o trabalho em curso. É um princípio muito importante: concentrarmo-nos em menos coisas e, no fim, conseguirmos realizar mais.

Dimitar Karaivanov:

Tem toda a razão. Há apenas uma ressalva: se limitar demasiado o trabalho em curso, pode prejudicar o fluxo. Existe um equilíbrio entre ser suficientemente rápido e obter o melhor fluxo possível. Cada organização tem de experimentar e encontrar o nível de trabalho em curso ideal para o seu contexto. Muitas pessoas perguntam qual é o melhor limite de trabalho em curso. Respondemos sempre que não sabemos, porque não conhecemos o contexto. É preciso experimentar. Os dados estão disponíveis. Analisa-se semanalmente o fluxo e verifica-se se é satisfatório. Se for, encontrou-se o limite ideal.

Ben Aston:

É útil. Tenho curiosidade em saber para onde a Kanbanize está a caminhar. O que está no vosso roteiro? Onde vê as empresas daqui a cinco ou dez anos?

Dimitar Karaivanov:

Cinco ou dez anos é um período muito longo, mas posso dizer que estamos a avançar para retirar cada vez mais tarefas de decisão ao gestor de projetos. Em vez de uma pessoa ter de calcular, estimar e experimentar diferentes cenários, queremos responder a essas perguntas imediatamente. O gestor de projetos deve poder concentrar-se no valor efetivamente gerado, e não tanto em saber se esse valor será gerado. Queremos assumir completamente a monitorização e as notificações através da introdução de algoritmos estatísticos específicos. Quanto à inteligência artificial, sou muito cuidadoso, porque toda a gente fala atualmente de inteligência artificial e, na realidade, no nosso trabalho, algoritmos estatísticos como as simulações de Monte Carlo fornecem mais precisão do que os algoritmos existentes. Se alguém afirma fazer previsões de um sistema kanban com base em inteligência artificial, provavelmente não está a utilizar verdadeira aprendizagem automática. Mas penso que o setor irá certamente nessa direção. Precisamos de encontrar algoritmos que ofereçam uma precisão superior à dos algoritmos estatísticos. O objetivo é libertar os gestores de projetos para realizarem trabalho mais importante, em vez de apenas monitorizar e preparar relatórios de vendas.

Ben Aston:

A maioria dos nossos ouvintes gere projetos ou são gestores de projetos, talvez também gestores de produto. Como vê a evolução de ferramentas como a Kanbanize, assumindo uma parte maior da previsão e do planeamento? Refiro-me à componente administrativa: descobrir o que está a acontecer num projeto e comunicá-lo, que pode ser um trabalho aborrecido. Falou em dar mais atenção à criação de valor. Como vê a evolução do papel do gestor de projetos? Quando fala em criação de valor, parece aproximar-se mais da gestão de produto e da responsabilidade pelo produto, com a entrega incremental de valor. Como vê a evolução dessa função?

Dimitar Karaivanov:

Penso que o gestor de projetos deve ser cada vez mais a interface que não só faz circular os dados e garante o cumprimento dos requisitos de comunicação e dos prazos, mas também enriquece esses dados e os questiona. Estamos a construir a coisa certa? Estamos a produzir o serviço certo? Para mim, o gestor de projetos deve ser a pessoa que impulsiona o sistema para uma evolução contínua, colocando as perguntas certas e as perguntas difíceis. Muitos gestores de projetos limitam-se a falar com o cliente, recolher os requisitos, introduzi-los na ferramenta de requisitos e transmiti-los à equipa de desenvolvimento. Quando o desenvolvimento termina, voltam ao cliente e dizem que o trabalho está concluído.

Isso tem valor, mas apenas parcialmente. Esses profissionais devem enriquecer o fluxo de dados, compreendendo as necessidades do cliente e não se limitando a escrever requisitos. Quando tiverem tempo para isso e não precisarem de produzir relatórios, preencher folhas de horas e tratar do orçamento, porque essas tarefas foram assumidas pelo software, poderão concentrar-se muito mais no que está realmente a ser produzido e em saber se é a melhor solução para o problema subjacente ao pedido de funcionalidade.

Ben Aston:

Falámos sobre o futuro da gestão de projetos e sobre a forma como o nosso papel muda à medida que obtemos melhores dados, compreendemos as necessidades dos utilizadores e clientes e as traduzimos com maior precisão em requisitos. Também falámos sobre inteligência artificial e a importância da precisão nas ferramentas. Como vê, em geral, a evolução do panorama das ferramentas de gestão de projetos? E como está a adaptar-se? Temos empresas como a Atlassian, que comprou o Trello, e vemos uma consolidação. Depois temos novas empresas, como a ClickUp, que tentam criar um sistema para gerir tudo. Como vê a evolução do cenário competitivo e como está a adaptar-se?

Dimitar Karaivanov:

Tem razão. Existem inúmeras ferramentas, sobretudo para gerir o trabalho de equipas pequenas. Se alguém tentar entrar nesse mercado, tem de ser muito otimista, porque é um verdadeiro desafio. Na Kanbanize, estamos a transformar o produto de uma solução de gestão de equipas numa solução de gestão ágil de portefólios. A funcionalidade já está parcialmente disponível, mas é uma tarefa enorme. No espaço da gestão ágil de portefólios, encontramos sobretudo ferramentas muito grandes que dependem do Scrum. Considero que isso é aceitável, mas não será o futuro.

O futuro será, espero, aquilo que vamos construir — não com base no que as pessoas pensam que vai acontecer, mas no que realmente acontece — criando autoestradas de informação entre as equipas e a gestão sénior, em ambas as direções. Em suma, penso que o setor das ferramentas está a consolidar-se em torno da ideia de expandir a agilidade por toda a organização. As ferramentas ao nível das equipas vão continuar a existir. Surgirão sempre novas ferramentas com experiências de utilização extraordinárias, que resolvem o problema de três pessoas mas não conseguem resolver o problema em maior escala. Essas ferramentas continuarão a aparecer e desaparecer. As que terão verdadeiro sucesso serão as que resolverem o enorme problema de introduzir agilidade numa empresa inteira.

Ben Aston:

Falemos disso. Escreveu um artigo chamado Agilidade empresarial impulsionada pelo Kanban, disponível em thedigitalprojectmanager.com, com várias sugestões para implementar uma abordagem kanban. Gostaria primeiro de abordar a agilidade empresarial. O que significa para si? O que é a agilidade empresarial?

Dimitar Karaivanov:

Para mim, agilidade empresarial é a capacidade de satisfazer os mercados através de ciclos rápidos de aprendizagem, experimentação e aplicação do conhecimento adquirido. Não é um modelo que se implementa nem uma sigla que se declara estar a utilizar. É a capacidade de experimentar rapidamente, aprender enquanto organização e utilizar esse conhecimento para criar mais valor para os clientes. É isso que significa agilidade empresarial para mim.

Ben Aston:

É um grande defensor da Kanbanize — peço desculpa, do Kanban. Chamou à empresa Kanbanize e tudo está orientado para o Kanban. Há pouco comparou Kanban e Scrum. Por que razão escolheu o Kanban e por que pensa que é mais adequado para a agilidade empresarial? Para que é bom e o que reconhece que não é bom?

Dimitar Karaivanov:

É uma excelente pergunta. A resposta está relacionada com um dos princípios do Kanban: começar onde se está e evoluir experimentalmente. Não conheço outra alternativa que diga: se quer ser ágil ou melhorar a agilidade da sua empresa, comece pelo que faz atualmente e melhore a partir daí. Normalmente, exige-se uma grande mudança: reestruturar equipas, obter certificações, criar formação ágil e assim por diante. O Kanban diz simplesmente: comece onde está, visualize o que acontece atualmente num quadro e faça perguntas sobre como pode fazer melhor. Penso que é uma abordagem humana à agilidade, porque não causa demasiado stress à organização, pelo menos inicialmente. Pode causar stress se for implementado incorretamente, mas é um processo evolutivo e as pessoas preparam-se para ele e aceitam-no.

Penso que é por isso que o Kanban é melhor do que muitas alternativas conhecidas: é uma abordagem humana. Quando é bem aplicado, reduz o stress e a sobrecarga das pessoas na organização. Também ajuda as pessoas a apreciar o trabalho que fazem. Permite-lhes concentrar-se em algumas coisas de cada vez, fazê-las melhor e não estar constantemente a apagar fogos ou a mudar de uma tarefa para outra. Quanto aos aspetos negativos, não tenho a certeza de que sejam culpa do Kanban. O maior problema é as pessoas pensarem que é apenas um quadro visual na parede. Já o disse várias vezes: o Kanban é um vasto corpo de conhecimento. Existem pelo menos uma dúzia de livros sobre o tema. Recomendo que os ouvintes pesquisem. Há muito mais do que um quadro branco.

Ben Aston:

A vantagem é que muitas pessoas sabem o que é o Kanban. Se pedir a alguém que explique Scrum ou Kanban, a versão mais simples do Kanban pode ser explicada muito mais rápida e facilmente. No Scrum, é necessário explicar o backlog, o sprint, os itens que entram no sprint, as cerimónias e todo o processo. É um modelo que, como diz, apresenta o Kanban como uma porta de entrada mais humana ou simples para o mundo ágil. Não é preciso mudar completamente a forma como se entrega o trabalho, executar sprints ou adotar todas as cerimónias. O Scrum determina muitas coisas que podem ser úteis, mas pode ser difícil assumir tudo de uma vez e exige uma grande reformulação do processo. O Kanban pode ser uma entrada mais suave para trabalhar de forma mais eficiente.

Dimitar Karaivanov:

Penso que é uma abordagem mais razoável. Se chegarmos a uma organização sem compreender o contexto e dissermos “façam isto e ficarão melhores”, isso pode ser arrogante. Se uma empresa tem um negócio bem-sucedido e conseguiu entregar um produto ou serviço valorizado pelo cliente, então sabe alguma coisa. Sabe como constrói e entrega o seu trabalho. Se eliminarmos esse conhecimento porque acreditamos que o nosso modelo é o melhor do mundo, estaremos a ser arrogantes. É muito melhor dizer: vamos perceber exatamente o que fazem e melhorar a partir daí. Penso que é uma abordagem melhor em qualquer área da vida, nos negócios ou na escola.

Ben Aston:

No seu artigo fala sobre aperfeiçoar o fluxo de trabalho, que é precisamente o que está a descrever. Encontramos um ponto de entrada simples e começamos a aperfeiçoar. Queremos reduzir o desperdício, ser lean e, potencialmente, reduzir o trabalho em curso, para podermos concentrar-nos mais e entregar valor com maior rapidez e eficiência. Como acontece, na prática, esse aperfeiçoamento do fluxo de trabalho?

Dimitar Karaivanov:

Fazemo-lo normalmente através das filas e dos limites de trabalho em curso. Quando se começa a trabalhar num quadro visual, se houver disciplina e ainda não existir muita maturidade em relação ao Kanban e ao lean, é provável que, com o tempo, se veja um conjunto de cartões a acumular-se numa zona do quadro. Esse ponto problemático do fluxo pode estar demasiado lento ou a fase anterior pode estar a avançar demasiado depressa e a inundar a fase seguinte com mais trabalho do que esta consegue processar. Numa situação assim, devemos parar e refletir. Porque está o trabalho a acumular-se aqui?

Normalmente, introduzimos novas colunas, as chamadas colunas de preparação. Podemos ter “em curso”, “em revisão” e “concluído”, e introduzir uma coluna entre “em curso” e “em revisão”, chamada “pronto para revisão”. Depois observamos se os cartões nessa coluna se acumulam. Se isso acontecer, significa que a fase de revisão é um estrangulamento e não consegue acompanhar a quantidade de trabalho produzida pela fase anterior. Podemos limitar o trabalho em curso na coluna “pronto para revisão”. Quando essa coluna estiver cheia, a coluna anterior deve deixar de produzir trabalho e ajudar os revisores. Esse é o processo de pensamento típico: vê trabalho a acumular-se, inspeciona, aperfeiçoa o fluxo se necessário, aplica limites de trabalho em curso e volta a executar para observar o resultado. Faz-se isto continuamente.

Ben Aston:

O objetivo é reduzir esses estrangulamentos, para que não tenhamos cartões a acumular-se nem trabalho por concluir. Afinal, o valor é criado quando as coisas são efetivamente concluídas, não apenas quando avançam no processo.

Dimitar Karaivanov:

Devemos fazê-lo continuamente, monitorizando o tempo de ciclo. O tempo de ciclo é o tempo que os cartões passam no quadro antes de serem concluídos. Quanto menor for, melhor. Se monitorizarmos as métricas e virmos o tempo de ciclo a aumentar, isso provavelmente significa que o trabalho se está a acumular no quadro. Devemos aperfeiçoar o fluxo, limitar algumas filas e utilizar limites de trabalho em curso para garantir que não sobrecarregamos o estrangulamento. É um processo contínuo.

Ben Aston:

Quero abordar outra das suas sugestões: transformar os HIPPO em HIPPO. É preciso ler o artigo para compreender, mas trata-se de passar da opinião da pessoa mais bem paga para a opção com maior probabilidade de sucesso, utilizando dados reais para orientar a tomada de decisões. Como é que isso funciona na sua equipa e no seu papel de CEO? É uma das pessoas mais bem pagas da empresa. O que recomenda quando a sua equipa lhe diz para reconsiderar algo? Como deve uma equipa abordar essa situação?

Dimitar Karaivanov:

É difícil, para ser honesto. Cometi muitos erros na nossa empresa até chegar a esta compreensão. Tentei fazer com que as equipas, sempre que alguém tomava uma decisão baseada apenas na intuição, sem apresentar nem analisar dados, começassem a questionar a decisão. O objetivo era levá-las a perguntar: como cheguei a esta conclusão? Posso tomar uma decisão mais fundamentada?

É natural que as pessoas queiram ter razão. Todos queremos ter razão. Apresentamos uma proposta e acreditamos imediatamente que é a melhor proposta do mundo. Sou uma pessoa particularmente opinativa e penso que a maioria dos CEO também é. Se discutir com alguém da minha equipa, normalmente ganho a discussão. Mas, quando existem dados concretos, se formos razoáveis, o argumento muda.

Tenho repetido centenas de vezes às minhas equipas: não tomemos decisões baseadas apenas na intuição. Isso são opiniões e todos temos opiniões. Se quiser comparar a sua opinião com a minha, perderá sempre. É melhor ter dados. Está a funcionar, mas é um período de transição. Estamos no segundo ou terceiro ano a tentar gravar completamente esta prática no nosso ADN enquanto empresa. É muito difícil, mas acreditamos nela. É uma prática que tem de ser repetida milhares de vezes até se tornar natural. A resposta curta é que é preciso ser extremamente persistente, exigir dados e não deixar passar as exceções.

Ben Aston:

Para terminar: o seu artigo fala de agilidade empresarial e de como o Kanban pode contribuir para a impulsionar. Para alguém que queira experimentar o Kanban, qual seria um bom ponto de partida? Disse anteriormente que o Kanban aceita o ponto onde se começa: tornamo-nos mais ágeis a partir da situação em que estamos. Não é necessário introduzir imediatamente alterações profundas no processo. Qual seria um dos primeiros passos para alcançar maior agilidade através de uma abordagem kanban?

Dimitar Karaivanov:

Diria que há duas ou três coisas muito importantes. A primeira é visualizar o trabalho. Todos podemos fazê-lo e não precisamos de ser especialistas. Basta encontrar uma forma de o fazer. Um quadro físico é a escolha mais óbvia: notas autocolantes, um quadro, alguns ímanes e algumas colunas desenhadas com um marcador. Em dois minutos temos um quadro. Não há desculpa para não visualizar o trabalho. Naturalmente, isto aplica-se quando existe alguma fonte de insatisfação. Se tudo estiver perfeito, não há razão para mudar. Mas, se existir um problema que queremos resolver, o primeiro passo é visualizar o trabalho.

O segundo passo é limitar o trabalho em curso. Comece onde está. Se visualizar tudo e tiver 100 projetos em curso, estabeleça um limite de 100. É ridiculamente elevado, mas reconhece o que está realmente a acontecer. Depois tente reduzir esse número até as coisas melhorarem. O terceiro passo — ou talvez o primeiro — é procurar formação de qualidade em Kanban. Somos parceiros da Kanban University, a entidade responsável pela certificação. É uma organização mundial com centenas de formadores. Recomendo vivamente essa formação. Pode ser dispendiosa se formar toda a empresa, mas pelo menos as pessoas-chave devem receber formação formal.

Ben Aston:

O que considero especialmente valioso é que o primeiro passo consiste em visualizar o fluxo de trabalho atual e identificar os pontos problemáticos. Pode parecer muito difícil, mas, quando se começa, é certamente gratificante mapear o processo com a equipa. Diferentes pessoas podem ter perceções diferentes sobre o processo atual e sobre a forma como o trabalho circula pela organização: estratégia, experiência do utilizador, design, desenvolvimento, garantia de qualidade e lançamento.

Também poderá descobrir que as pessoas têm opiniões diferentes sobre o processo de aprovação ou os ciclos de revisão. Por isso, visualizar o processo é uma excelente sugestão. Ajuda a identificar mais facilmente os pontos problemáticos: onde estão as falhas e onde surgem os estrangulamentos. Depois, podemos pensar em como limitar o trabalho em curso para aumentar o fluxo. Dimitar, muito obrigado. Foi extremamente útil. Para conhecer a Kanbanize, visite kanbanize.com; incluiremos a ligação nas notas do programa. Dimitar, muito obrigado por se juntar a nós. Foi ótimo tê-lo connosco.

Dimitar Karaivanov:

Obrigado, Ben. Agradeço o convite. Foi muito divertido falar consigo. Gostei da conversa. Vamos continuar.

Ben Aston:

Se quiser aprender mais e progredir no seu trabalho, junte-se à nossa comunidade através da adesão ao DPM. Visite thedigitalprojectmanager.com/ membership para ter acesso aos nossos modelos de equipa, workshops, sessões de perguntas e respostas, horários de atendimento, livros digitais e muito mais. Se gostou do que ouviu hoje, subscreva o podcast e mantenha-se em contacto através de thedigitalprojectmanager.com. Até à próxima. Muito obrigado por nos acompanhar.