Mudar de Contratos em Cascata para Contratos de Duração e Preço (Com Tucker Sauer-Pivonka, da Crema)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa informático. Perdoe quaisquer erros tipográficos, uma vez que o robô não está correto 100% das vezes.

Ben Aston:

Bem-vindo ao podcast do DPM, onde vamos além da teoria para dar conselhos que funcionam na liderança de melhores projetos digitais. Obrigado por nos acompanhar. Sou Ben Aston, fundador do Digital Project Manager. Atualmente, os projetos raramente correm conforme o planeado e, quando os planos mudam, isso costuma gerar muito stress. É preciso fazer chamadas, marcar reuniões, atualizar planos, recalcular estimativas e, normalmente, emitir pedidos de alteração. Mas e se houvesse outra forma de gerir as mudanças nos seus projetos? Neste podcast, vamos revelar uma abordagem diferente à gestão da mudança, utilizando contratos ágeis. Continue a ouvir para perceber como fazer com que os contratos ágeis funcionem para si e compreender as vantagens e os desafios desta abordagem.

Hoje, estou acompanhado por Tucker Sauer-Pivonka, Diretor de Gestão de Produto, que ajuda os gestores de produto a crescer e a desenvolver-se. Também é responsável por fazer evoluir as boas práticas. Olá, Tucker.

Tucker Sauer-Pivonka:

Olá, Ben. É um prazer falar consigo hoje.

Ben Aston:

Igualmente. Uma das coisas que queria perguntar-lhe, para começarmos, é a seguinte: sei que parte da sua função envolve o desenvolvimento da equipa e gostava de saber se poderia partilhar algumas ideias sobre o que descobriu que funciona realmente para ajudar a sua equipa a desenvolver-se e a evoluir. Talvez no que diz respeito aos contratos com que trabalha ou que está a experimentar. Como promove o desenvolvimento da equipa e ajuda as pessoas a crescer? O que descobriu que funciona consigo?

Tucker Sauer-Pivonka:

Penso que a primeira coisa que temos de reconhecer desde cedo é que cada pessoa aprende de forma um pouco diferente e precisa de formas de orientação diferentes. Por isso, uma das primeiras coisas que faço com os membros da minha equipa é sentar-me com eles e começar a avaliar isso. Como aprendem? Como gostam de receber feedback? Como gostam de receber elogios? Registo tudo isso para poder adaptar a minha abordagem a algo a que respondam um pouco melhor. Passo bastante tempo nas nossas reuniões individuais, a abordar diferentes temas e áreas de crescimento. Na verdade, acompanho-os em tudo aquilo com que estejam a ter dificuldades no momento. As questões vão surgindo e nós lidamos com elas. Além disso, temos atualmente um grupo de leitura na Crema, em torno de um livro chamado Multiplicadores.

Esse é um aspeto importante do crescimento da nossa equipa. E depois, claro, há as conferências. Temos uma conferência marcada, penso que para o final de setembro, a que vamos assistir. Também está relacionada com a gestão de produto. Vamos participar enquanto equipa, não apenas para fortalecer os nossos laços, mas também para aprender sobre novos temas.

Ben Aston:

Muito bem. Sabe qual é o nome da conferência?

Tucker Sauer-Pivonka:

Chama-se Industry: The Product Conference e realiza-se em Cincinnati, se bem me lembro.

Ben Aston:

Uma festa em Cincinnati, se quiser juntar-se ao Tucker e à equipa. Mas queria aprofundar um pouco o assunto. Referiu que, com a equipa, talvez abordem vários temas. Gostava de saber se poderia partilhar alguns dos temas ou áreas que está a ajudar a equipa a ultrapassar. Quais são os desafios que a equipa enfrenta e que está a ajudá-los a superar?

Tucker Sauer-Pivonka:

Penso que varia um pouco para cada pessoa, porque temos diferentes níveis de competências na equipa. Mas muitos desses temas estão relacionados com a gestão de clientes. “O meu cliente disse isto, ou está a pedir que façamos aquilo, mas ainda não falámos sobre isso. Como devo lidar com a situação?” Estou a ser genérico porque não consigo lembrar-me agora do exemplo perfeito, mas é algo desse género.

As questões de gestão de clientes são normalmente as mais difíceis de ensinar, por isso acabam por ser mais uma conversa: “Senti-me estranho com isto. Não sei se foi a forma certa de lidar com a situação. Fiz bem? Ou deveria fazê-lo de maneira diferente da próxima vez?” É normalmente nessa direção que as nossas conversas seguem.

Ben Aston:

É mesmo verdade. Existem competências interpessoais relacionadas com a gestão de clientes e também com a gestão de equipas, não é? Mas nunca há uma única resposta certa. Depende sempre. Ainda assim, podemos continuar a crescer e a melhorar nessas áreas. Referiu que vão a uma conferência enquanto equipa, o que considero excelente. Gostava de perceber melhor onde procura inspiração e como se mantém atualizado relativamente a tudo o que está a acontecer. Como se mantém informado e como encontra inspiração?

Tucker Sauer-Pivonka:

Mantenho-me inspirado utilizando várias fontes. Uma delas são os livros que leio. Leio muitos artigos e, na verdade, recorro bastante ao Medium para encontrar inspiração sobre gestão de produto, especificamente, ou sobre gestão de equipas e aquilo que isso deve ou pode parecer. Tenho de me lembrar de que o Medium é um ótimo recurso, mas que devemos encarar algumas coisas com cautela, porque qualquer pessoa pode publicar um artigo. O facto de alguém poder publicar algo na internet não faz dessa pessoa um especialista. Ainda assim, se adotarmos essa perspetiva, pode pelo menos dar-nos algum contexto sobre como lidar com determinadas situações.

Uso bastante essa fonte e, depois, essas são realmente as duas principais. Também acompanho temas mais abrangentes da indústria. Gosto muito da revista Wired e costumo ler a maioria dos artigos de cada edição. Isso ajuda-me a acompanhar diferentes tendências que estão a acontecer fora do mundo da gestão de projetos, mas relacionadas com a tecnologia em geral.

Ben Aston:

Excelente. E, em termos de tecnologia, é uma pessoa que se mantém na vanguarda? Qual foi o último aparelho que comprou?

Tucker Sauer-Pivonka:

É uma boa pergunta. Gostava de ter algo muito entusiasmante para lhe contar, mas não diria que estou na vanguarda. Considero-me um utilizador pioneiro, mas não muito mais do que isso. Normalmente, tento comprar produtos novos quando são lançados, se puder. Neste momento, estou a desejar um novo iPad. Tenho um iPad Pro, que funciona bem, mas quero a nova versão e não consigo justificá-la. O meu trabalho funciona bem e essa é uma das grandes vantagens dos produtos Apple: funcionam bem, por isso não preciso realmente de os substituir.

Mais recentemente, a última versão do iOS, do iPadOS e tudo o que foi apresentado na WWDC foi muito interessante para mim. Tenho pensado bastante nisso e no impacto que essas novidades terão na indústria como um todo e talvez até em alguns dos produtos que estou a criar. Foi o principal tema que acompanhei recentemente. Além disso, sou um pouco fã de Zelda e a sequela de Breath of the Wild foi anunciada, por isso também estou muito entusiasmado com isso.

Ben Aston:

Muito bem. Eu, neste momento, estou interessado no DJI Rover. Não sei se se chama Rover ou outra coisa, mas anunciaram uma pequena câmara montada num pequeno tanque que podemos construir. Parece fantástica. Está na minha lista de compras.

Tucker Sauer-Pivonka:

Parece divertido.

Ben Aston:

É novamente uma daquelas coisas: “Será que preciso mesmo disto?” Não preciso, mas seria divertido para as crianças. Já que mencionou que gosta do seu iPad Pro, há algum outro equipamento ou programa que tenha descoberto recentemente e que esteja a tornar a sua vida melhor, algo que todos deveriam conhecer?

Tucker Sauer-Pivonka:

Ao longo dos anos, tive dificuldade em encontrar um equilíbrio entre tirar notas manuscritas, escrever notas, acompanhar tarefas e tudo o resto. Tentei encontrar um equilíbrio porque há muita informação que indica que, quando escrevemos algo, compreendemo-lo de forma diferente do que quando o escrevemos num teclado, e isso é interessante para mim. Durante algum tempo, tirei notas no iPad utilizando o Apple Pencil. Isso levou-me bastante longe. Mais recentemente, mudei para algo intermédio.

Uso o iPad ou o computador como repositório final de tudo o que está relacionado com o trabalho. No entanto, também comecei a andar com um pequeno caderno, onde tiro as notas do dia a dia e registo as tarefas à medida que surgem. No final do dia, transfiro tudo para uma aplicação chamada Todoist, para acompanhar as minhas tarefas. Também introduzo lá as minhas notas e processo-as no final do dia.

Estou a começar a adotar esse sistema agora, mas foi a maior mudança recente no meu fluxo de trabalho e tem sido muito útil. Sinto que compreendo melhor aquilo que estou a fazer e consigo acompanhar melhor as minhas tarefas, sem começar imediatamente a executá-las. Até do ponto de vista da gestão do tempo, tem sido muito útil.

Ben Aston:

Interessante. Está a utilizar um caderno físico para tirar notas. Foi aí que regressou ao analógico para as notas e os lembretes?

Tucker Sauer-Pivonka:

Sim, mas acaba por ser transferido para um espaço digital. Para mim, nada substitui abrir um caderno, clicar na caneta e começar a escrever. A minha maior dificuldade com o iPad e o Apple Pencil é que há tempo envolvido em abrir a aplicação certa, encontrar o caderno certo e garantir que o Apple Pencil está carregado. São coisas pequenas, mas acabam por ser barreiras à simples tarefa de escrever uma nota.

Comecei a reparar que andava com o iPad e um milhão de notas autocolantes, porque, quando tinha um problema, escrevia numa delas. Se precisava de começar a fazer alguma coisa, utilizava uma nota autocolante. Pensei: “Isto não é sustentável. É um pouco absurdo andar com todas estas notas.” Foi isso que me levou a mudar para um caderno.

Ben Aston:

É uma batalha com que também lido. Atualmente, utilizo o Evernote. Tenho um caderno que é a minha lista de tarefas e outro a que chamo simplesmente bloco de rascunho, que serve para despejar tudo. Assim, se começo a preocupar-me demasiado com a organização das notas e quero que a lista de tarefas esteja bonita e ordenada, deixo tudo no bloco de rascunho e depois transfiro-o para a lista de tarefas. Parece um sistema semelhante ao seu.

Também tenho um pequeno bloco de notas que me impede deliberadamente de escrever muito. É suficientemente pequeno para permitir apenas escrever lembretes, não notas. Isso obriga-me a utilizar o meu sistema. Caso contrário, começaria a criar listas diferentes em locais diferentes e acabaria tudo numa grande confusão.

Mas vamos falar sobre o artigo. Este foi um estudo de caso que escreveu para nós e é muito interessante. Trata da mudança de contratos em cascata para contratos de duração e preço. Já falámos anteriormente sobre contratos ágeis e, na escola DPM, alguém perguntou esta semana por um exemplo de contrato ágil. Enviei-lhe o link. A Alexa escreveu anteriormente um ótimo artigo sobre contratos ágeis. Para quem não está familiarizado com este tipo de contrato, pode explicar brevemente o que é um contrato de duração e preço e como funciona?

Tucker Sauer-Pivonka:

Vou explicar como funciona no contexto da Crema. Isso não significa que tenha de seguir exatamente a mesma fórmula, mas é aquilo com que estou mais familiarizado. Um contrato de duração e preço centra realmente o projeto numa equipa dedicada. Pode incluir dois programadores a tempo inteiro, um engenheiro de testes a meio tempo, um designer a um quarto ou a meio tempo e um gestor de produto. Talvez também um estratega, ambos a um quarto do tempo.

O foco está mais na própria equipa e nos objetivos que se pretendem alcançar do que numa lista exata de entregáveis e funcionalidades com estimativas exatas de horas ao lado. Descobrimos que o software é demasiado complexo para tentar estimar tudo antecipadamente e assumir que tudo correrá exatamente conforme o plano. Seria ótimo se pudéssemos planear tudo e as coisas acontecessem exatamente como pretendemos, mas isso nunca acontece.

Estes contratos permitem-nos, a nós e aos nossos clientes, mudar o foco para o trabalho de maior prioridade. Assim, no final da duração do contrato e ao longo dos ciclos iterativos, entregamos aquilo que tem maior valor para o negócio. Num contrato de preço fixo, as prioridades podem mudar ao longo do tempo. Imagine um contrato de seis meses em que, no final, entrega funcionalidades que já não são relevantes para o negócio. Este modelo permite-nos mudar de direção sempre que necessário para responder às necessidades do cliente.

Ben Aston:

Muito bem. Falou dos tipos de projetos que fazem sentido para contratos ágeis, como o desenvolvimento de software e de produtos, em que é importante ter flexibilidade para mudar de direção. Encontrou algum tipo de projeto em que tenha tentado utilizar estes contratos, mas em que o contrato ágil de duração e preço não tenha funcionado tão bem?

Tucker Sauer-Pivonka:

Há alguns casos, talvez não tanto para nós, mas para quem está a avaliar o que faz sentido. É preciso analisar o tipo de trabalho. Isto funciona para nós porque desenvolvemos produtos difíceis de detalhar completamente e que envolvem algum risco calculado. É difícil fazer isso e muitas vezes acaba por gerar custos adicionais para o fornecedor ou para o cliente.

Se for algo repetível, como criar websites padrão com um determinado número de páginas e um tipo específico de disposição, pode fazer sentido utilizar um modelo de preço fixo. É sobretudo uma questão de previsibilidade e imprevisibilidade em tudo o que se faz.

Ben Aston:

Está a surgir outro tema: o preço baseado no valor. É obviamente muito diferente do preço baseado no valor. Num projeto mais previsível, pode dizer ao cliente: “O valor deste trabalho é 50 mil”, e cobrar 50 mil. A ideia é gastar menos de 50 mil a produzi-lo, vendendo o valor em vez das horas.

Como é que esse preço baseado no valor se relaciona com contratos diretos e transparentes de duração e preço, em que o cliente paga pelas horas? Que impacto teve na rentabilidade? As coisas tornaram-se mais simples e rentáveis por existir uma margem incorporada nas horas de cada pessoa? Ou já enfrentou situações difíceis em que teve de absorver custos?

Tucker Sauer-Pivonka:

São duas coisas diferentes. Quando desenvolvemos software utilizando um modelo de duração e preço, nem sempre sabemos qual será o resultado final. Como não é previsível, é difícil atribuir-lhe um preço no início. O resultado pode mudar porque o cliente pode mudar de ideias.

O preço baseado no valor funciona muito bem quando podemos dizer: “Vamos entregar algo que proporcionará este valor ao seu negócio.” Pode ser um processo de conceção ou algo semelhante. É mais fácil de gerir. Mas, quando estamos a construir um produto grande, é mais difícil.

Quanto à rentabilidade, essa é uma das vantagens do modelo de duração e preço: está incorporada na forma como trabalhamos. O cliente compra uma alocação de uma equipa e essa alocação é aquilo que recebe. Se houver dois programadores a tempo inteiro no projeto, não estamos realmente a ultrapassar horas, porque não analisamos o trabalho dessa forma. Analisamos a alocação dessas pessoas e entregamos valor sprint após sprint. Não é necessário preocuparmo-nos tanto com a rentabilidade porque não é possível entregar menos ou mais horas do que as contratadas. O cliente não paga hora a hora.

Ben Aston:

Portanto, o cliente compra uma equipa durante determinado período. Já aconteceu o cliente dizer, no final de um sprint ou depois de vários, que não considera ter recebido valor suficiente?

Tucker Sauer-Pivonka:

Não acontece com muita frequência. Trabalhamos diligentemente para garantir o alinhamento com os clientes, não apenas no início de cada sprint, mas durante todo o sprint, mantendo-os informados sobre tudo o que muda. Uma das melhores formas de gerir isso é através de uma boa comunicação e gestão do cliente.

Dizemos com humildade: “Pensávamos que isto demoraria dois sprints, mas parece que demorará três ou quatro devido ao que descobrimos. Eis o que descobrimos e por que razão pensamos que demorará este tempo. Se preferir, podemos recuar e avançar para outra coisa.” Apresentar todos os factos ao cliente ajuda a tomar decisões e reduz o peso emocional dessas decisões.

Antes de cada sprint, alinhamos com o cliente aquilo que será incluído. Garantimos que a equipa se sente confortável com o que está a ser proposto. No final, fazemos uma demonstração do que foi concluído. Se houver trabalho transitado ou se descobrirmos algo novo, conversamos sobre isso e explicamos porquê, para que o cliente não volte mais tarde a dizer que não era aquilo que esperava.

Ben Aston:

Quero aprofundar o estudo de caso e falar sobre o calendário. Disse que sabia que seriam pelo menos sete meses de trabalho. Como chegaram a essa estimativa se não tinham a certeza do que estavam a construir? Como chegaram à estimativa inicial de sete meses? Foi antes ou depois da fase de prototipagem?

Tucker Sauer-Pivonka:

Naquele caso específico, e na maioria dos nossos projetos, foi depois de realizarmos algum tipo de prototipagem ou testes. Normalmente é um trabalho de cerca de seis semanas e, neste caso, incluiu também uma auditoria técnica do sistema existente. Isso ajudou-nos a definir o prazo necessário para atingir os objetivos.

Há uma parte que vem com a experiência. À medida que realizamos mais projetos, começamos a perceber quanto tempo determinadas coisas demoram e qual é a sua complexidade. Depois existe o contributo da equipa de produção. Terminada a prototipagem e os testes, sentámo-nos e dissemos: “Não podemos definir aqui todas as histórias que vamos fazer porque isso não seria útil. As coisas vão mudar. Mas podemos analisar os objetivos, dividir o projeto nas suas diferentes partes, avaliar a complexidade de cada uma e atribuir tamanhos aproximados.”

A partir daí, recomendamos o tamanho da equipa: quantos programadores, qual a alocação necessária para um engenheiro de testes e assim por diante. Tudo depende da complexidade do que estamos a construir. A duração não está tão relacionada com entregáveis, porque o acordo não é orientado para entregáveis. Está focado nos objetivos de negócio.

Sabíamos que existia trabalho suficiente para sete meses e considerámos que, nesse período, a equipa conseguiria manter o foco e cumprir todos os objetivos. Também dependia do orçamento e da disponibilidade do cliente, porque o software nunca está realmente terminado. Há sempre coisas novas a fazer.

Ben Aston:

Imagino que parte dessa avaliação consistisse em perceber se o cliente só podia pagar sete meses ou se tinha orçamento para continuar. Na realidade, o software provavelmente iria exigir mais de sete meses.

Tucker Sauer-Pivonka:

Se o cliente quisesse apenas um contrato de três meses, isso também seria perfeitamente possível. Trabalharíamos nesses três meses naquilo que tivesse maior prioridade. No final, o trabalho prioritário estaria concluído.

É útil pensar nisto como o aluguer de uma equipa. O cliente recebe aquilo que a equipa consegue produzir em três meses, seis meses, um ano ou dois anos. Trabalhamos dentro do período escolhido e concentramo-nos sempre na prioridade.

Ben Aston:

Referiu que o primeiro passo era uma colaboração de prototipagem e validação. Era um preço fixo? Mencionou seis semanas. Basearam-se em três sprints de duas semanas? Quão bem definidos estavam os entregáveis no final dessas seis semanas?

Tucker Sauer-Pivonka:

Tecnicamente, continua a enquadrar-se no nosso modelo de duração e preço, embora seja um pouco mais próximo de um preço fixo quando comparado com o nosso contrato normal. Existem determinados entregáveis: um protótipo de alta fidelidade, os ficheiros de desenho, as entrevistas com utilizadores, as notas e a investigação correspondente.

No entanto, continua a ser baseado na duração. Se, ao fim de três semanas, percebermos que aquilo que estamos a discutir não é o que os utilizadores querem, podemos voltar à estaca zero. Não estamos limitados a entregar exatamente determinado número de ecrãs. Continua a ser um modelo de duração e preço.

Ben Aston:

Isso é importante, porque muitas vezes as coisas correm mal mesmo na fase de prototipagem. Desenvolve-se um protótipo e o cliente diz que não está certo, antes sequer de o testar com utilizadores. Se era suposto ser um processo rápido para obter feedback, não estava previsto fazer todas essas alterações. O modelo funciona também nessa fase.

Depois das seis semanas, produzem o protótipo, fazem testes com utilizadores, recolhem feedback e dizem que são necessários cerca de sete meses. Essa estimativa foi calculada de baixo para cima ou de cima para baixo? Perguntaram ao cliente quanto dinheiro tinha disponível e trabalharam a partir daí? Como avaliaram o apetite do cliente relativamente ao tamanho e ao âmbito do desenvolvimento?

Tucker Sauer-Pivonka:

Criámos tamanhos aproximados para o trabalho, avaliámos a complexidade e definimos uma ideia do plano técnico. Com isso, conseguimos construir um roteiro. Fomos claros quanto ao facto de o roteiro poder mudar ao longo do tempo, mas foi assim que chegámos aos sete meses iniciais.

Não sabíamos necessariamente qual era o orçamento disponível quando apresentámos a proposta. Explicámos o que tínhamos feito, o que viria a seguir e qual poderia ser o roteiro. Também indicámos o que seria incluído em cada etapa e o que considerávamos prioritário, sujeito a alterações.

A presença da equipa técnica, do gestor de produto e do estratega ajudou a definir o que seriam os sete meses. Dissemos, por exemplo, que determinada área da aplicação demoraria aproximadamente um mês e meio. Reunimos tudo no roteiro e chegámos ao número de sete meses.

Ben Aston:

Muito bem.

Tucker Sauer-Pivonka:

Durante a fase de proposta, garantimos que o cliente sabia que poderíamos ajustar o plano. Poderíamos voltar à estaca zero e conversar sobre aquilo de que precisaria num período de três meses, por exemplo. Já conhecíamos suficientemente bem o cliente para perceber o que queria no seu produto mínimo viável e criámos um roteiro adequado a isso.

Ben Aston:

Quero falar sobre a metodologia. Descreveu a abordagem como ágil, com elementos de Scrum. O que retiram do Scrum tradicional, que é bastante prescritivo, e o que deixam de fora? Como é que a vossa abordagem difere do Scrum tradicional? Estou particularmente interessado na função do proprietário do produto, em saber se é o cliente ou alguém da equipa, e em saber se têm mestres de Scrum. Referiu um estratega de produto, mas não mencionou um mestre de Scrum nem um proprietário do produto.

Tucker Sauer-Pivonka:

É comum ouvirmos aqui que colocamos as pessoas acima dos processos. Praticamos Scrum com “s” minúsculo. Isso significa que garantimos flexibilidade suficiente para que as pessoas não fiquem limitadas pelo processo. Se uma equipa precisar de o adaptar para trabalhar melhor com o cliente, tem autonomia para o fazer.

Numa agência, é mais difícil ter funções dedicadas para tudo. Numa empresa de software, a estrutura pode ser diferente. No nosso caso, o proprietário do produto costuma ser o contacto diário do cliente.

Se houver um estratega no projeto, por vezes ele funciona como uma espécie de coproprietário do produto, ajudando essa pessoa. Alguns clientes não sabem o que significa possuir software ou construí-lo. O estratega ajuda a tomar decisões sobre a estratégia e a direção geral do produto.

Por vezes, essa função cabe aos nossos gestores de produto. Pode acontecer o proprietário do produto estar do lado do cliente, mas não conseguir manter contacto diário connosco. Nesse caso, o gestor de produto assume algumas responsabilidades de proprietário do produto, comunicando sempre as decisões ao cliente.

Do lado da gestão de produto, combinamos as funções de gestor de produto e mestre de Scrum numa só. Sei que isso contraria a abordagem tradicional do Scrum, mas descobrimos que funciona para nós. Quando deixar de funcionar, ajustaremos. Organizamos as cerimónias, configuramos as reuniões diárias automáticas, verificamo-las todos os dias e removemos bloqueios. Temos o contexto necessário para tomar decisões relacionadas com o produto.

Essas são provavelmente as duas áreas em que mais nos afastamos do Scrum tradicional. O resto é bastante semelhante. Fazemos o planeamento de sprint, as estimativas, as retrospetivas e as demonstrações do produto. Normalmente reunimos tudo numa reunião chamada reunião inicial de quarta-feira.

Ben Aston:

Por vezes, o cliente é o proprietário do produto e, noutras, é o gestor de produto da vossa equipa. Quero falar sobre a gestão da mudança. No estudo de caso, mencionou prioridades contraditórias: o cliente queria criar algo novo, mas o sistema antigo, que tinha de continuar a funcionar, estava cada vez mais degradado. O processamento de pagamentos deixou de funcionar ou estava prestes a deixar de funcionar.

Nestas situações, o cliente quer as duas coisas: continuar a construir o novo e corrigir o antigo. O âmbito aumenta. Como gere esses conflitos de prioridades e como educa o cliente para gerir o backlog? No Scrum, temos um backlog e cabe ao proprietário do produto organizá-lo por ordem de prioridade. Quando um projeto se tornou essencialmente em dois, como orientou o cliente a esse nível?

Tucker Sauer-Pivonka:

A primeira coisa é compreender que, quando as prioridades mudam, devemos ter empatia relativamente à causa dessas alterações. Na maioria das vezes, o cliente nem sequer quer mudar as prioridades. Quer que continuemos focados para entregarmos aquilo que pediu inicialmente. Temos de compreender que não pediria uma mudança se não precisasse realmente dela.

É importante perceber a causa da mudança. É realmente uma prioridade elevada? É uma situação de pressão? Foi algo pedido por um interessado? Todas essas razões são válidas. Compreender a origem ajuda a definir a forma de comunicar.

Depois, é necessário explicar claramente que mudar prioridades altera todo o plano. Imagine que a equipa está a trabalhar numa grande funcionalidade e já está a meio. Surge então outra funcionalidade urgente porque um cliente final assinou um contrato de grande valor e precisa dela.

A equipa de produto tem de compreender o motivo. Depois de perceber a situação, explico-a à equipa. Isso reduz a emoção e a frustração, porque todos compreendem por que razão estamos a mudar de direção.

Em cada ponto de controlo, confirmo que o cliente percebe que, ao fazer uma coisa, a equipa está a abandonar outra. Isso significa que o segundo trabalho não ficará concluído na data inicialmente prevista. Não há problema nisso, mas o plano muda. É importante tornar a decisão completamente clara.

No estudo de caso, pensávamos saber quando o trabalho terminaria, mas não sabíamos. Foi necessária muita comunicação com o cliente para explicar que a mudança nos afastava do objetivo empresarial principal. Tudo bem, desde que o cliente compreenda as consequências, porque pode tornar-se um erro dispendioso.

Quanto às ferramentas, qualquer visualização pode ajudar. No âmbito das ferramentas, seja Jira ou outra, é útil mostrar visualmente o que está a acontecer. Por vezes, algo que dizemos não é compreendido da mesma forma que quando é apresentado visualmente.

Ben Aston:

Dão acesso dos clientes ao Jira?

Tucker Sauer-Pivonka:

Adotamos uma abordagem de transparência total. Os clientes têm acesso às ferramentas que utilizamos e são convidados para a nossa equipa do Slack. Também têm acesso ao Jira. Participam para ajudar a confirmar as prioridades, os requisitos e a direção. Isso ajuda quando chegamos ao final do sprint e o cliente pergunta por que razão determinada coisa não foi incluída.

Ben Aston:

No estudo de caso, falou sobre conquistar uma posição de confiança. A transparência ajuda. Também referiu, nas suas lições aprendidas, a importância de entregar artefactos, atualizar o roteiro e atualizar o gráfico de burndown. Como evita sobrecarregar o cliente com toda esta informação?

Tucker Sauer-Pivonka:

Parte da resposta está em admitir humildemente os erros. Isso pode criar rapidamente muita confiança, porque o cliente percebe que não estamos a tentar enganá-lo. Dizemos que cometemos um erro e explicamos como o vamos corrigir. Com o tempo, percebe que somos genuínos e que temos os mesmos interesses: o sucesso do cliente é o nosso sucesso.

Não obrigamos os clientes a utilizar as ferramentas. Garantimos apenas que têm acesso se quiserem. Criamos vídeos personalizados de captura de ecrã que explicam como utilizar uma ferramenta, onde encontrar informação e quais as áreas que provavelmente não precisam de consultar.

Quando existem muitos ecrãs para rever, o cliente pode sentir-se sobrecarregado. Uma forma de evitar isso é permitir o acesso à ferramenta e entregar o trabalho de forma iterativa e gradual, para que não receba tudo de uma vez. Nem sempre é possível, porque o trabalho pode acumular-se, mas sermos transparentes ajuda bastante.

Ben Aston:

Que nível de relatórios fornecem? O cliente paga uma equipa durante determinado período. Apresentam o tempo despendido e folhas de horas ou dizem apenas que o cliente está a comprar a equipa e deve confiar que trabalhou no projeto?

Tucker Sauer-Pivonka:

O relatório centra-se na entrega de resultados. Temos métricas que acompanhamos em cada sprint. No final, analisamos o que foi concluído, o que não foi concluído e qual foi a nossa velocidade. Se aumentou ou diminuiu, discutimos o motivo.

Não reportamos horas. O cliente compra uma equipa, mas não prometemos um número exato de horas para cada funcionalidade. Utilizamos os relatórios para confirmar que as alocações estão corretas.

Se alguém está alocado a meio tempo e passa a trabalhar mais do que isso, podemos ter de remover trabalho da sua responsabilidade ou aumentar a alocação. Também pode acontecer o contrário, embora seja raro. As alocações costumam estar corretas.

Pode haver variações semanais. Uma pessoa pode estar alocada a um quarto do tempo e, numa determinada semana, trabalhar metade do tempo devido a questões específicas. Na semana seguinte, isso pode equilibrar-se. Acompanhamos as alocações, mas não reportamos esse nível de detalhe ao cliente. Reportamos o trabalho concluído e o trabalho pendente.

Ben Aston:

Quero terminar perguntando quando e como é que estes contratos de duração e preço não funcionam. Já alguma vez correram completamente mal? O que devem ter em atenção as pessoas que estão a pensar adotar este modelo?

Tucker Sauer-Pivonka:

As coisas podem correr mal, especialmente quando o cliente sente que o progresso é insuficiente. Quando começam a surgir sinais disso, é importante falar sobre o assunto. Se comunicarmos frequentemente, começamos a notar alguma estranheza ou algo que não está a ser dito. Devemos abordar o tema diretamente: “Sinto que não estamos alinhados relativamente a alguma coisa. Podemos falar sobre isso?” É necessário compreender o que está a causar a preocupação e fazê-lo cedo. Se esperarmos até ao fim, será mais difícil recuperar a confiança.

Nunca tive uma situação que tivesse desmoronado completamente. Tive um caso em que estávamos prestes a renovar o contrato e o cliente estava insatisfeito com o progresso. Falei com ele com empatia e analisei o trabalho realizado.

Descobrimos que tínhamos mudado para outro trabalho devido a uma alteração de prioridade. Isso atrasou o trabalho original cerca de dois meses, embora o novo trabalho fosse importante para o negócio. Quando expliquei a situação, o cliente compreendeu. As conversas anteriores sobre o impacto das alterações ajudaram-no a compreender melhor a nossa forma de trabalhar.

Cada conversa destas constrói confiança. Explicamos que as prioridades podem mudar a qualquer momento e que o cliente está no controlo. Basta indicar-nos a direção e trabalharemos para chegar lá.

Até agora, não tivemos nenhum caso de colapso total. Normalmente, trata-se de falta de alinhamento. Se o cliente não estiver disposto a alinhar-se connosco, talvez não sejamos os parceiros certos. Tentamos identificar isso cedo no processo comercial.

Ben Aston:

Para mim, uma das grandes aprendizagens da sua história é que é necessário ter o cliente certo para este modelo funcionar. É necessária alguma maturidade por parte do cliente para compreender que as coisas levam tempo, que a mudança de prioridades afeta o calendário e que isso afeta o custo.

Estas questões podem ser difíceis porque os clientes têm um orçamento limitado e um prazo. Quando se concorre com outra agência ou equipa, todos tentam ser competitivos e apresentar a melhor proposta. Porém, isso nem sempre cria as condições certas para gerir as expectativas sobre aquilo que pode ser entregue por determinado preço ou num determinado prazo.

Grande parte do trabalho está no processo comercial e na educação do cliente durante a prototipagem e a validação. O resultado é a entrega contínua de valor, de acordo com as prioridades do cliente. No final, o cliente obtém um resultado melhor, em vez de a agência tomar atalhos ou decisões de prioridade apenas para cumprir o orçamento ou o prazo.

Os contratos de duração e preço são um conceito interessante. Tucker, muito obrigado por se juntar a nós.

Tucker Sauer-Pivonka:

Foi uma excelente conversa. Obrigado pelo convite.

Ben Aston:

Gostava de saber o que pensa. Já experimentou um contrato ágil? Gostaria de saber como correu. Diga-nos o que pensa, comente esta publicação e visite TheDigitalProjectManager.com para aderir à nossa equipa do Slack. Encontrará todo o tipo de conversas interessantes sobre a entrega de projetos. Temos um canal sobre metodologias ágeis onde seria ótimo discutir este tema.

Se gostou do episódio de hoje, subscreva o podcast e reserve alguns minutos para deixar uma avaliação honesta do podcast do DPM no Apple Podcasts. As avaliações e os comentários são muito úteis e agradecemos imenso. Até à próxima, obrigado por nos ouvir.