Quais são as alternativas ao Dono de Produtos (PO)? Um comitê? Não seria muito ágil. Um portão escancarado para as demandas? Aumentaria exponencialmente os riscos de desalinhamento e desperdício. Analistas de negócios? Não são diferentes dos POs sem poder. Quando entendemos o valor do recurso PO, fica difícil abrir mão dele.
Jeff Sutherland se inspirou¹ no Engenheiro-Chefe da Toyota para criar o papel do Dono de Produtos (PO). O que aproveitamos desse modelo? Um EC é visto como um “super-engenheiro e líder”. Sua formação não dura menos do que doze anos. Sua posição é a mais cobiçada entre os engenheiros daquela empresa japonesa². Quanto disso nós trouxemos para os nossos POs? Quase nada.
Terceira e última parte da série. Já conversamos sobre eficácia e eficiência, particularmente sobre a necessidade de rever nossos processos de forma a dar um pouquinho mais de atenção para o domínio do problema. Nada disso fará sentido se não considerarmos a parte mais frágil, complexa e fundamental da coisa toda. Estou falando da gente.
Hoje o problema não é nosso. Mas a gente quer que seja. Pretendemos desenhar um produto ou serviço que melhore a vida de um cliente. Por onde devemos começar? Quais ferramentas podem nos ajudar? Quais hábitos e mal entendidos colocam em risco a nossa empreitada?
Nos dois artigos anteriores tentei mostrar a necessidade de uma maior preocupação com o Domínio do Problema. Eles se concentraram no porquê. O texto de hoje ilustra como podemos nos apaixonar por problemas.
"Não morda o meu dedo, olhe para onde estou apontando." - Warren McCulloch
Não importa se é um bug ou característica programada. O fato é que os métodos e frameworks mais populares - particularmente Scrum e Kanban - tropeçam no mesmo buraco. Apesar de suas imensas diferenças, essas propostas são omissas ou relapsas no mesmo ponto.
Como nós criamos e entregamos valor? Na primeira parte deste checkup nós conversamos sobre eficácia. Agora o tema é eficiência: criar e entregar valor do jeito certo. Como trabalhamos? Nosso método realmente ajuda? Calma, não é mais uma comparação entre Scrum e Kanban. Até porque ambos tropeçam no mesmo lugar.
