24 minutos de leitura
#NoProjects é um movimento interessante, dirigido por Allan Kelly. Sigo Allan desde 2015, gosto muito de livros. Como seres humanos, tendemos apenas a acrescentar coisas e esquecemos de remover, revisitar, reciclar e repensar nossos valores e mentalidades. Aprendizado eficaz também é sobre desaprender.
O Projeto Miopia é um livro muito interessante sobre o assunto. Os projetos estão no centro do nosso universo, no entanto, nosso universo deve ser centrado no cliente, primeiro no produto e, então, orientado à inovação. Levei algum tempo para perceber como os projetos podem ser incompatíveis com os produtos digitais. Software é difícil, produtos são ainda mais. Ser ágil tem a ver com valor, no entanto, a indústria de TI e as empresas de produtos digitais geralmente têm problemas para definir, medir e entender o valor. Compreender e buscar valor é realmente essencial para oferecer melhores produtos e evitar desperdícios (Lean).
Uma das primeiras coisas que Allan aponta em seu livro (Projeto Miopia) é que há uma correlação entre downloads e alterações. Os downloads são menos críticos que o crescimento orgânico e a satisfação do cliente; porém, há uma conexão intrigante. Um software dead geralmente não possui downloads. Mas o que significa um software dead? Geralmente, significa mantenedores zero ou alterações zero. Como arquiteto, a primeira coisa que vejo em uma biblioteca de código-fonte aberto para usar em qualquer linguagem como Java, Scala, Go ou Rust, é verificar se a biblioteca/estrutura está alive. Todas essas idéias nos levam a duas questões centrais: o que significa dead or alive products?
Software dead
* Concluído: o projeto foi entregue e nenhum projeto futuro está em andamento.
* Nada de atualizações: o software para de mudar, portanto, não há melhorias nem novos recursos.
* Não há mais mantenedores: as pessoas param de trabalhar no software, pois não há projeto.
* Não há mais RPs: como as pessoas não o usam, ninguém quer contribuir.
* Não há mais investimento: como não há usuários, não há dinheiro para investir.
* Não há mais alterações: zero mudanças, é a morte do produto.
* Não há mais downloads: sem download significa que não há novos usuários.
* Nada de usuários: significa perder usuários até a morte completa do software.
Software alive
* Nunca feito: sempre em mudança. Sem interrupção.
* Sempre atualizado: nunca feito.
* Tem vários mantenedores/várias empresas/pessoas envolvidas: como o produto está alive, as pessoas querem fazer parte dele.
* Possui vários PRs por semana/mês.
* Possui investimento constante.
* Tem alterações na produção todos os dias.
* Tem downloads todos os dias.
* Possui novos usuários e mantém a base de usuários.
Eu acho que você conseguiu captar a ideia. Dead significa fim da linha, não há mais necessidade. As pessoas se relacionam com coisas vivas. Portanto, os produtos precisam estar alive e conviver o tempo todo. Em outras palavras, mesmo se você usa projetos, não deseja projetar o end; você quer um projeto que leva a outro projeto e assim por diante… Isso é verdade, mas está completamente errado na mentalidade do projeto, porque os projetos têm um end, e nós não o queremos. As estimativas têm uma relação com esse assunto. Recomendamos que você leia minha última postagem no #NoEstimates.
Poderia ser um álbum do Guns ‘n Roses.
Os projetos precisam ter um fim. Eles também exigem configuração, que é super cara. Então, precisamos realizar as seguintes atividades (não limitadas por uma visão simplista):
* Marketing: verifique se as pessoas conhecem sua marca e o que funciona para você. Marca do produto e marca da engenharia são coisas completamente diferentes.
* Contratação: a contratação não é barata nem fácil. Você precisa avaliar os candidatos no sentido de cultura fit, atitudes, habilidades, aplicação de teste prático, revisão do conhecimento em tecnologia. É um processo de, pelo menos, duas semanas por pessoa.
* Treine a equipe: não apenas nos princípios de agile, lean, devops, mas também em tecnologias como cloud, languages, frameworks, databases etc.
* Ajuste sua equipe: aprimore seu trabalho em equipe e agregue valor constantemente.
Assim que você conseguiu fazer todas essas partes funcionarem bem, o que você faz em seguida? Bem, você mata esse projeto e começa de novo. Isso faz sentido para você? Os projetos também são sinônimos de sucesso quando você entrega em escopo, tempo e orçamento. Antes de tudo, esse é um conceito PMI (organização sem fins lucrativos que tem o objetivo de disseminar as melhores práticas de gerenciamento de projetos em todo o mundo) muito antigo, baseado em ponte, que não se aplica mais ao nosso mundo atual. Eu recomendo que você também leia esse post.
Há projetos que limitam nossa busca de valor. Como estamos limitados a pensar que precisamos concluir um projeto antes de iniciar outro, e se considerarmos o backlog simples, poderíamos obter todos os itens de alta prioridade e trabalhar no primeiro? E se falharmos, mas não usarmos todo o dinheiro? Falhamos ou conseguimos? Falhamos ao considerar as definições tradicionais do projeto. Devido aos modernos conceitos de descoberta de produtos, na verdade, obtemos sucesso, porque evitamos desperdiçar muito mais dinheiro em um software que não funcionaria para os clientes.
Os projetos não aceitam falhas. Eles assumem que você entregará todo o backlog que tinha. Essa definição é concluída de forma equivocada em nossa cultura moderna de produtos desde que a Lean Startup disse, e se saiu bem: “Não conhecemos o produto, o mercado e o cliente, e precisamos descobrir”. Se precisamos aceitar que não sabemos, como podemos corrigir o backlog? Como podemos saber se precisamos desses 10 recursos exatos ou histórias de usuários?
Outro insight importante que Allan introduz no livro é a questão do termo “Tech Debt”. Eu, pessoalmente, nunca gostei do termo “dívida tecnológica”; como estamos construindo produtos digitais, prefiro o termo “dívida”, pois podemos ter dívida de produto, dívida UX, dívida BA etc.
No entanto, Allan aponta um conceito muito melhor. Responsabilidade. Ninguém quer ter responsabilidade, isso é inegociável. Eu gostaria que esse fosse o termo, e que todo gerente e profissional de produto soubesse disso. A dívida é frequentemente vista e considerada uma coisa positiva no mundo de negócios, já que toda empresa tem dívidas. No entanto, a responsabilidade é a opinião de que nada é desejado.
Responsabilidade versus dívida não é apenas uma expressão diferente. O que mais importa é mudar a sua mentalidade. Eu realmente recomendo que você leia esse post. Mudar a mentalidade significa não pensar apenas no recurso e na saída. Reconheça que os produtos de construção digital são difíceis e não que podemos, simplesmente, acumular responsabilidades.
Esse é outro grande problema que a maioria das empresas enfrenta hoje. Projetos criam expectativas falsas. No papel, você pode dizer que um projeto custa US$ 500 mil por ano, mas, na realidade, pode custar US$1 milhão. Criar gráficos Gant, projetos e estimativas longos apenas nos faz sentir melhor, mas não nos garante a adoção pelo usuário ou geração de um valor melhor. Acredito que seja o contrário. Na verdade, gera o pior desempenho e menos valor, já que estamos focados e retraídos com as coisas que não importam.
As estimativas são piores do que as expectativas. Elas são um tipo de expectativa. Depois de configurá-las, será difícil mudar. Trabalhar sem expectativas é difícil. Eu acredito, profundamente, que precisamos pensar grande e ter sonhos ousados e audaciosos. No entanto, acredito que precisamos ir devagar e com muito cuidado.
O agile não funcionará para você se você não mudar suas expectativas. O agile não funciona se você não aceitar coisas verdadeiras e difíceis. Ser agile é como um espelho: você pode não gostar do que vai ver. As expectativas precisam ser gerenciadas e focadas em causar impacto real no cliente, para não causar um impacto programado em um gráfico gigante ou em um roteiro de 3 a 5 anos.
A busca por valor é o que mais importa. Saber qual é o valor é difícil e complicado. Obsessão pelo cliente e trabalho duro de UX são a única maneira de chegarmos lá. A cultura da experiência significa: permitir que a falha aconteça; sem falha, não há inovação; sem inovação, não há impacto impressionante para o cliente. Precisamos reconhecer que a construção de produtos é DURA e não acontecerá apenas porque a construímos.
Se você não descarta nenhuma experiência de usuário que faça uma descoberta, significa que você não está fazendo a descoberta. Descoberta significa brincar com ideias e experimentar qual é a melhor e o impacto mais certo sobre os clientes. É a nossa opinião sobre o cliente dead ou alive? Como eu disse antes, o software precisa estar alive para que possamos ter um ótimo produto. Então, como o produto pode estar alive se nossa visão sobre o cliente está estática (dead)?
Se sabemos todas as respostas, por que precisamos do UX? Poderíamos, simplesmente, construir para que apareçam? Bem, a indústria de produtos e as startups enxutas já nos mostraram que as coisas não funcionam dessa maneira. Perseguir o valor significa aceitar que não sabemos todas as respostas, que vamos experimentar e descobrir. Seguir os prazos cegamente não deixa muito espaço para a descoberta.
Melhoria Contínua significa:
* Ouvir o cliente (usuário – não apenas sua equipe de negócios).
* Ouvir sua equipe de engenharia.
* Executar retrospectivas regulares do processo equipe.
* Fazer 101 sessões com todos da sua equipe.
* Fazer RCAs (Root Cause Analysis) e melhorar o que não está funcionando bem.
* Entender por que os erros acontecem e evitá-los pelo mesmo motivo.
* Entender a variação e as dependências e tentar gerenciá-las.
* Não eliminar todas as variações, ou você vai eliminar a inovação.
* Aprender a ver e eliminar desperdícios (Lean).
* Melhorar e gerenciar seu fluxo, tendo limites (Kanban).
* Dar visibilidade a todas as melhorias nas quais que você está trabalhando.
Tudo isso não funciona se você não mudar sua mentalidade. Se você ainda estiver aguardando os recursos x na data Y, com o custo Z, nenhuma melhoria funcionará para você. Porque você não está focado no valor, está focado na saída. O valor não pode ser cristalizado, ele precisa estar alive. Então, está em constante mudança.
Por que é tão difícil? Porque sua empresa é grande e tem muitas pessoas que pensam da mesma maneira. Eles se fortalecem. Então, você não está enfrentando um indivíduo apenas, está enfrentando algo muito mais forte: a cultura.
Como praticante de XP, sempre acredito em R2 Loops. O ide é antigo e envelhece mais que o XP, desde os anos 70, para ser mais preciso. Mas as empresas não aprendem. R2 Loops significa mudar sua estratégia, alterando seus modelos e valores mentais. Caso contrário, você não está realmente mudando. Dizer “sou agile” ou “eu sou lean” não faz você ser nenhum deles. Se usar práticas, sem alterar seu processo de pensamento e sem ir além de qualquer outra coisa, suas “expectativas” não vão significar nada.
Como Yoda disse uma vez:
Desaprender você deve o que aprendeu.
A única maneira é ensinar educando. A educação leva tempo, e isso não é feito apenas por meio de treinamento, mas também de trabalho árduo no dia a dia. Seus agentes de mudança (treinadores, gerentes, líderes, ágeis) estão promovendo mudanças no cotidiano?
Estamos medindo as coisas que importam? Agile é uma retrospectiva, mas quantas “Retrospectivas do Produto” você realizou? Quantas discussões sobre produtos você teve após a produção? Quantas vezes você falou com o suporte ao cliente? Uma retrospectiva de produto é diferente de uma retrospectiva de equipe. Precisamos envolver suporte ao cliente, vendas, pessoal do produto (descoberta) e ver os números em USO e entender o que está funcionando e o que não está. Caso contrário, estaremos apenas lançando recursos e esperando que nossa base de usuários cresça. Como o Google SRE, as pessoas gostam de dizer: “A esperança não é uma estratégia”.
Fonte: Blog Diego Pachego
