BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Foco no resultado: Q&A com Jeff Patton

Foco no resultado: Q&A com Jeff Patton

Favoritos

Precisamos nos concentrar nos resultados e adaptar a maneira de pensar e os processos para liberar continuamente pequenas alterações nos produtos e serviços, argumentou Jeff Patton na palestra de encerramento da Agile Greece Summit 2019.

Patton afirmou que devemos pagar para aprender, e não apenas construir um "software potencialmente entregável". Temos que reconhecer que falhamos, e muito, para criarmos humildade nos processos. Então, podemos incorporar o aprendizado ao processo:

Se não entendermos os problemas dos clientes, podemos fazer pesquisas. Se não sabemos o que realmente querem, podemos pagar para desenvolvermos protótipos. Se não sabemos se continuarão usando, podemos investir em um software, liberá-lo para um número limitado de clientes e observar o comportamento. Nenhuma dessas coisas resulta em retorno do investimento. Em vez disso, resultam em um aprendizado que nos ajuda a tomar melhores decisões sobre o que devemos construir em escala.

A mentalidade das equipes começa a se concentrar nos resultados quando começamos a torná-los visíveis.

Patton sugeriu falar mais sobre resultados. Mesmo usando a palavra "projeto" que sabota o modo que pensamos. Precisamos lembrar que queremos que os projetos terminem, mas, idealmente, queremos que os produtos sejam construídos para durar o maior tempo possível. O resultado em que nos concentramos só é mensurável depois que entregamos algo que é colocado em uso, depois que as coisas estão feitas. É por isso que é chamado de "resultado".

O InfoQ conversou com Jeff Patton, consultor de design de produtos e autor de User Story Mapping, após a palestra no Agile Greece Summit 2019.

InfoQ: Como as práticas de desenvolvimento de software do século XXI desafiam as premissas de processo mantidas por muitos na indústria de software?

Jeff Patton: Na verdade, o mundo em que vivemos mudou. E os processos, ou seja, a maneira como trabalhamos, estão mudando também.

O melhor processo e prática de desenvolvimento de software é uma resposta às demandas dos negócios e aos produtos e serviços que construímos e vendemos. Pense nos tipos de produtos e serviços que usamos todos os dias, quantos deles contam com uma experiência digital? O telefone, o relógio, o carro, a série da Netflix, o stream, os jogos. Pense em serviços como os fornecidos pelos bancos, na compra de passagens aéreas ou aluguel de quartos de hotel. Pense em como encontramos um novo restaurante ou solicitamos a entrega da comida. Agora, pense em todos esses bits de experiências digitais que usamos todos os dias e na taxa de grandes lançamentos e grandes mudanças que vemos. Meu palpite é que não vemos muitas mudanças ou lançamentos. Em vez disso, vemos uma taxa contínua de pequenas alterações.

Este é o novo normal. Tudo é digital, tudo requer um software e tecnologia. Não estamos mais tentando incluir o máximo possível em uma versão, estamos tentando lançar pequenas melhorias contínuas nos produtos e serviços.

Não importa como chamamos o processo, ele não pode mais estar enraizado no modelo de grande design do século XX, seguido da grande entrega. Esse tipo de pensamento desafia muitas das suposições em que as empresas são construídas.

Por exemplo, muitas empresas financiam o desenvolvimento de tecnologia usando projetos em que o tempo e o escopo são fixos, e o objetivo é obter o máximo possível durante esse tempo. Os projetos geralmente têm vida longa, trimestres ou anos. Por outro lado, as organizações contemporâneas centradas em produtos, financiam uma área de produtos por meses ou anos sem entender o recurso que obterão. Em vez disso, o foco está nos resultados observáveis do mercado, como aquisição e retenção de clientes. As equipes nessa área de produtos usam esse financiamento para melhorar continuamente, focando nos mesmos resultados de negócios.

InfoQ: O que devemos fazer de maneira diferente ao projetar e construir um software?

Jeff Patton: Um valor ausente em muitos processos ágeis é a humildade. O reconhecimento de que não somos perfeitos, que falhamos muito.

Falhamos em prever o quanto podemos fazer em um sprint ou release. Mas, com maior frequência, não conseguimos prever se os clientes vão gostar e usar os produtos e se um número suficiente deles irá adquiri-lo para que valha o investimento. Se isso fosse fácil, todos os fundadores de startups seriam bilionários.

Depois que construímos humildade nos processos, podemos então construir aprendizado. E precisamos aprender isso mais rápido do que costumávamos fazer a uma década atrás, porque, lembre-se, o mundo se move mais rápido hoje. É por isso que abordagens de processos como lean startup, design, pensamento, lean UX e design sprints estão prosperando. Estes são "processos pagos para se aprender". Combinar estes processos com abordagens ágeis mais tradicionais nos deixa com algo que é chamado de desenvolvimento de pista dupla, um processo com uma faixa de aprendizado contínuo trabalhando ao lado de uma faixa focada na construção em escala.

InfoQ: Projetos de sucesso focam em resultados, não em entregas. Como podemos mudar a mentalidade e prática para avançar em direção aos resultados?

Jeff Patton: Fale mais sobre resultados, muito mais. É a mentalidade e a linguagem do projeto que atrapalham.

Os projetos são definidos usando tempo, custo e escopo. Em processos ágeis como Scrum, focamos na mesma coisa. Fixamos o tempo em um sprint de duas semanas. Fixamos custos, fixando o tamanho da equipe. E como o Scrum pode ser um pouco sádico, forçamos a equipe a fixar o escopo em si mesma, a se comprometer com o que pode ser feito até o final do sprint. Em uma revisão de sprint, inspecionaremos a qualidade do que fizemos, mas não o resultado e, geralmente, não podemos falar sobre, porque a compreensão do que foi feito só pode acontecer após a entrega, normalmente, semanas ou meses após a entrega. Assim como o Project Thinking , o Scrum incentiva as equipes a se concentrarem no tempo, custo e escopo também.

Tento mudar a mentalidade das pessoas, lembrando-as dessas realidades. Vou perguntar às equipes: "Como mediremos os resultados bem-sucedidos?" A consequência disso é, infelizmente, mais trabalho, especificamente para instrumentar produtos, para que possamos saber se as pessoas realmente os usam e quais recursos são utilizados.

Também pedirei às equipes que construam uma visualização simples. O eixo da esquerda para a direita é um esforço real, o eixo de cima para baixo é o resultado real. Coloquemos cada recurso ou capacidade fornecida, neste gráfico simples. Ao colocar os recursos no eixo do esforço, solicitarei que marquem as coisas que demoraram mais que o esperado. Os colaboradores aprendem rapidamente que grandes coisas geralmente levam mais tempo do que o esperado. Para um resultado real, pedirei que usem buckets diferentes. O primeiro é "não sei", tudo começa por aí, porque até as coisas serem enviadas e os usuários começarem a usá-las, não sabemos. Mas acima disso, as coisas variam de "horrível" a "impressionante". As equipes começam a aprender quanto tempo realmente leva para ver um resultado. Pode levar semanas para que mude de "não sei" para algo entre "horrível" e "incrível". E também começarão a observar como poucas coisas acabam sendo "impressionantes". E, finalmente, como o tamanho do que estamos construindo tem tão pouco a ver com o resultado, frequentemente, as menores coisas que construímos nos dão os maiores resultados.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT