Definindo resultados como uma equipe de produto

(Made Tech) (23 de dezembro , 2020)

As equipes de produto devem se concentrar na entrega de resultados .

Nesta postagem, discutiremos como uma equipe de produto pode definir resultados e, em seguida, garantir que epopeias / recursos (saídas) estejam vinculados aos resultados.

As horas tomadas não são um indicador de valor

Como a entrega do projeto digital foi desenvolvida a partir de waterfall , por meio dos vários sabores de agile para o estado atual de lean , o mesmo acontece com a forma como medimos o rendimento, a qualidade e a “adequação à finalidade” geral dos produtos digitais feitos.

Em processos de fabricação tradicionais , o produto final foi um produção limitada e previsível. Isso significa que um método simples de medir a produção (reconhecidamente uma única dimensão) era o número de horas investidas na produção.

Com a engenharia digital, é muito provável que o número de horas investidas em um único aspecto de um produto que varia muito devido ao número de restrições, dependências e influências de elementos que às vezes estão fora do controle da equipe do projeto.

Portanto, sem o tempo como medida, precisamos ver os resultados do projeto usando medidas diferentes.

As saídas não têm sentido sem contexto

Com o reino livre, a maioria dos engenheiros digitais construirá o que quiserem. Faz parte da natureza humana operar em um ambiente onde nos sentimos seguros, confiantes e confortáveis. Nossa produtividade será a mais alta possível quando estivermos reproduzindo soluções conhecidas ou redefinindo um produto que é comprovado, testado e confiável.

Isso parece ótimo, os engenheiros digitais estão se esforçando para produzir muita produção, em ritmo, com poucos problemas e tudo funciona (não quebra). No entanto, essa saída não tem direção. Estaremos, no mínimo, criando um produto que será complicado, oneroso ou mesmo inutilizável para o usuário final.

Passando dos produtos aos resultados

Até agora, Postulei que leva tempo e a quantidade de coisas produzidas tem muito menos impacto no sucesso de um projeto do que se supõe. Isso não significa que eles não devam ser medidos durante um projeto, no entanto, eles precisam ser definidos em relação a uma medição muito mais importante: o valor do resultado.

“A saída é o quantidade de algo produzido, ao passo que um Resultado é a maneira como uma coisa acaba. ”

Uma mudança na terminologia nos permite mudar todo o foco e direção de uma equipe de projeto de um metáfora de fabricação do século 18 a um princípio que está alinhado com como a engenharia digital é melhor abordada.

Considere a revisão de um único componente de um projeto que acabou de ser concluído. É a saída de uma colaboração de designers, engenheiros, testadores, etc. Pensando no componente como uma saída, podemos determinar que ele demorou um certo tempo para ser produzido, é de qualidade previsível e se integrará ao o ambiente pretendido com o mínimo de problemas.

Agora, vamos considerar o mesmo trabalho como resultado. Ao produzir este componente do produto, agora é possível que uma ação seja realizada pelo usuário final, uma quantidade de esforço seja reduzida ou um problema que identificamos seja corrigido.

Por que isso distinção valiosa? Em um ambiente de engenharia onde qualquer coisa, dentro do razoável, pode ser construída, as partes interessadas terão uma visão ambiciosa do que pode ser alcançado. Simplificando, as equipes sempre terão o desafio de construir mais do que podem dentro do tempo e / ou orçamento disponível. Usar os resultados para determinar o valor permite que a equipe determine o que deve ser construído, de uma forma que os resultados (tempo e volume de produção) não podem.

Resultados são sinônimos de valor

Conforme mencionado antes, o resultado é a maneira como a coisa acaba. Portanto, a equipe precisa saber como uma coisa deve ficar antes de construí-la. Não estou pedindo que a equipe preveja as nuances dos detalhes de engenharia que usarão para produzir um resultado. Como alternativa, eu pediria que eles estivessem cientes de como o componente que construirão será usado e como isso afetará a experiência do usuário final.

Antes que alguém me acuse de apenas ser capaz de considerar usuários finais, qualquer coisa que construímos que faça interface com outro serviço (seja humano ou digital), pode ser referido como um usuário.

O valor de um resultado é geralmente medido (classificado) em relação ao valor para o negócio (a instituição do cliente) e o valor para o usuário. Isso nos leva a alguma preparação que toda a equipe do projeto deve realizar para garantir o valor dos resultados e do projeto como um todo.

O planejamento adequado impede irrite o baixo desempenho

Este é o núcleo da metodologia de engenharia enxuta / orientada para o resultado / orientada para o valor / primeiro usuário, ou como você gosta de chamá-la. O planejamento, neste contexto, não é o agrupamento complicado de informações obsoletas em documentação impenetrável. Em vez disso, concordamos como equipe em colaborar em alguns exercícios que nos permitirão construir a coisa certa rapidamente.

Estrela do Norte / Visão de negócios / Metas de negócios

Várias escolas de pensamento e os exercícios do workshop usam terminologia diferente, mas o elemento-chave para qualquer projeto é uma direção de viagem acordada. Isso pode ser descrito como uma declaração de valor, uma série de objetivos, um discurso de elevador ou uma declaração de hipótese. O formato é menos importante do que o fato de que toda a equipe sabe para onde está indo e por quê.

Com uma estrela do Norte (meu termo favorito no momento), agora temos uma ferramenta que nos permite medir o valor de qualquer coisa que a equipe se propõe a fazer com seu tempo no projeto.

Isso deve ser feito no início de qualquer compromisso. É um resultado desafiador de criar, especialmente, quando uma equipe consiste de estranhos, a confiança é baixa e muitos serão expostos a novas práticas de trabalho. Eu gostaria de ser capaz de demonstrar uma sequência de workshop prescritiva que entrega esse resultado magicamente. A realidade é que precisamos que eles sejam brutalmente francos e honestos sobre seus objetivos, e que compartilhem isso abertamente com estranhos.

Uma estrela do norte pragmática é uma medida única que podemos usar para classificar todos os esforços da equipe. Você notará que não estou mais expressando medição em abstrato, estou usando-a para classificar os elementos do projeto uns contra os outros.

Uma Estrela do Norte razoável poderia ser “o número de interações digitais por usuário. ”

O que é legal aqui é que não estamos lidando com minúcias de inscrições de usuários, tempo de permanência, jornada, taxa de falha, etc. Em vez disso, mediremos suas interações. O defensor do diabo poderia sugerir que um usuário frustrado poderia “interagir” indefinidamente com o serviço sem obter nada de valor, então não estou sugerindo que o serviço ao vivo tenha apenas uma única medida.

Os objetivos do usuário

O usuário final, seja humano ou outros serviços digitais, é a razão pela qual o produto está sendo construído. Pode estar dentro de um requisito legal ou regulamentar, mas esses são veículos para encapsular a necessidade de um usuário. A arte de descobrir e documentar as metas do usuário está além do escopo desta postagem, mas os resultados deste exercício são a principal maneira de determinar o que devemos construir.

Gostamos de descrever as metas do usuário como histórias de usuário . Essas são obras de arte lindamente elaboradas que os analistas de negócios passam décadas aperfeiçoando nos topos das montanhas enevoadas como Haikus, que se adaptam ao medidor de: negociável, valioso, estimável, pequeno e testável. projeto trabalhando sob as restrições do COVID-19, somos mais pragmáticos. Uma história de usuário se encaixa em um post-it retangular quando escrita com uma ponta afiada, de preferência em caligrafia legível.

O valor que eles têm é que eles descrevem um pedaço gerenciável de valor para o usuário. Com o suficiente desses escritos, podemos priorizá-los contra a estrela do norte usando o conhecimento da equipe, qualquer especialista em domínio que possamos persuadir a participar.

O fim do início

Nós ainda não foi escrita uma linha de código, então muitas incógnitas ainda precisam ser descobertas. Gastamos o mínimo de tempo possível fazendo isso, então podemos calcular com otimismo que perdemos 20\% ( Princípio de Pareto ) das necessidades do usuário. Também estamos cientes de que é provável que ocorram pivôs, como uma pandemia global, que afetará o projeto.

No entanto, temos uma forte direção de viagem e um acúmulo de histórias de usuários que são priorizadas.

Dada a natureza cíclica dos princípios de desenvolvimento ágil, podemos retornar às nossas premissas originais regularmente e evoluí-las para atender às necessidades emergentes. Uma crítica legítima ao desenvolvimento ágil é que ele pode perder o rumo, pois todos os objetivos são de curto prazo. No entanto, com uma estrela do Norte no lugar e uma compreensão de como usá-la, a direção é fortemente definida.

Considerações finais

Eu pulei muitos detalhes. Existem dezenas de métodos de workshop, diagramas e estruturas que fazem uma metodologia como esta funcionar, então, por favor, acredite que não há necessidade de “saltos de fé”.

Em resumo, um projeto é a expressão de um necessidade. Eles normalmente são redigidos na linguagem da organização que identificou a necessidade.Pode ser necessário muito descompactar e descobrir o mundo onde o projeto reside, no entanto, ao ajudar a equipe do projeto a descobrir, identificar, agrupar e classificar o que devem fazer de forma colaborativa, permite-lhes um desempenho eficaz e feliz.

Esperamos que você tenha gostado desta postagem e tenha achado o conteúdo informativo e envolvente. Estamos sempre tentando melhorar nosso blog e agradeceríamos qualquer feedback que você pudesse compartilhar nesta breve pesquisa de feedback .