Carmen DeArdo, ex-diretor de tecnologia DevOps na Nationwide Insurance, e Nicole Bryan, vice-presidente de gerenciamento de produtos da Tasktop, falaram recentemente no DevOps Enterprise Summit London sobre a importância de mudar uma organização baseada em projeto para uma organização baseada em produto [PDF dos slides]. O planejamento e financiamento baseados em projetos levam a uma desconexão entre a TI e a visão de negócios (onde a TI é vista como um centro de custos e uma caixa preta), rastreando atividades em vez de resultados e orçamentos rígidos de projeto que não acomodam a velocidade atual de mudança estratégica e direção.
A orientação a produto é um desafio, pois exige novas abordagens em todos os setores, na forma como são gerenciados orçamentos, planejamentos, equipes, prioridades, visibilidade e risco. O InfoQ entrou em contato com DeArdo para refletir sobre esses desafios.
InfoQ: Por que você recomenda mudar de projetos para produtos? Pode dar exemplos concretos de "projetos que deram errado"?
Carmen DeArdo: No início da nossa palestra mencionamos os cinco desafios, muitos dos quais vêm de uma visão da TI como um "centro de custo", em vez de uma capacidade fundamental para gerar lucro. Uma razão para isso é que a TI parece desconectada da visão e estratégia dos negócios. Embora as empresas mapeiem (interminavelmente) os relacionamentos entre os objetivos dos negócios e da TI, o sócio normal de cada lado muitas vezes não sente essa conexão. Por ter equipes de produtos compostas por ambas perspectivas, negócios e TI, e trabalhando em conjunto diretamente, não apenas na funcionalidade do negócio, mas também dando insights de negócios sobre o que mais precisa ser priorizado em termos de riscos, defeitos e dívidas, ajudam a fornecer esse alinhamento direto.
Quanto a projetos que deram errado, acho que é mais sobre o fato de que itens importantes, como mitigação de riscos, muitas vezes não são vistos e priorizados, mesmo que possam ter um impacto significativo no negócio (por exemplo, Equifax). Ter silos em Dev e Ops causam problemas e o mesmo vale para Negócios e Dev. E uma estrutura de projeto tende a criar o mesmo tipo de silos entre os diferentes tipos de trabalho e as prioridades que realmente precisam ser abordadas de forma holística.
InfoQ: Isso significa que não devemos mais usar projetos para planejar nosso trabalho?
DeArdo: Não. Acho que Jon Smart fez um ótimo trabalho em sua palestra com a declaração "O PMO está morto. Viva o PMO". Enquanto estive no Bell Labs usávamos projetos para criar novos produtos. Então, nunca diria que não há necessidade de ter um projeto. Mas o trabalho necessário para melhorar e dar suporte aos produtos é melhor feito em uma estrutura de produto.
InfoQ: Em sua experiência, quais são os três principais obstáculos para fazer essa mudança na abordagem da gestão de trabalho?
DeArdo: Em nossa palestra, tivemos sete áreas que precisavam ser abordadas ao passar de projeto para produto. As três primeiras vão mudar conforme as situações atuais e a cultura de uma dada empresa. Para mim, vejo o orçamento, o sucesso (ver a TI como centro de custo cujos custos precisam ser reduzidos) e a abordagem às equipes (levando o trabalho para as equipes em vez de formar equipes de projeto) como as três primeiras. Mas o primeiro desafio é definir os produtos a partir de uma perspectiva de negócio para a qual se possa criar equipes para suporte.
InfoQ: Você poderia apontar abordagens específicas e benefícios da orientação ao produto em termos de orçamento?
DeArdo: Há uma percepção de que ter orçamentos anuais pode ser necessário para algumas organizações, mas em vez de financiar centenas de iniciativas - às vezes com 18 meses de antecedência - a empresa pode financiar o investimento em produtos e permitir que os gerentes priorizem o trabalho. Na Bell Labs, isso era revisado a cada três meses para determinar se o financiamento do produto precisava ser alterado.
Jon Smart falou sobre ter uma abordagem ágil no gerenciamento de portfólio. Não podemos dizer que somos ágeis se apenas uma pequena parte do nosso fluxo de valor tiver realmente alguma agilidade. Para ser ágil realmente, é necessário começar com os processos de orçamento e gerenciamento de portfólio.
InfoQ: Qual a sua definição de produto?
DeArdo: Existem produtos de negócios e produtos de TI. Um produto é simplesmente algo que tem uma base de clientes que agrega valor. Acho que no passado criamos problemas ao não tratar produtos de TI (por exemplo, nosso pipeline de implantação) da mesma maneira que tratamos os produtos de negócios.
InfoQ: Você falou sobre as desvantagens de considerar as pessoas como um "conjunto de recursos" de onde se monta uma equipe para fazer um projeto. Qual a melhor alternativa e como a orientação a produtos pode ajudar?
DeArdo: Uma vez determinado o que será investido em um produto, pode-se financiar a primeira equipe que suporta este produto. Note, no entanto, que também falamos sobre o fato de que é um "conto de fadas" acreditar que uma única equipe dentro da "regra das duas pizzas" pode fazer todo o trabalho para um determinado produto. Mas é necessário ter recursos inter-qualificados associados a produtos. Então, quando o financiamento muda, se formos verdadeiramente ágeis, podemos mover as pessoas de acordo. Percebo que isso é mais fácil dizer do que fazer, mas precisa ser um objetivo.
Os processos que exigem visualizações de 30, 60 e 90 dias de "demanda" e também processos de atendimento com SLAs longos não são ágeis em nenhum sentido e não suportam a necessidade crescente de responder rapidamente às necessidades de negócios.
InfoQ: Qual é a sua definição de um fluxo de valor e por que é importante alinhar o trabalho e as equipes com isso?
DeArdo: Um fluxo de valor é o conjunto de atividades e tempo gasto focados em entregar "valor" a um determinado cliente. Os fluxos de valor começam e terminam com o cliente.
A razão pela qual é importante é porque o foco de qualquer negócio é entregar valor aos seus clientes. Fluxos de valor são o mecanismo no qual isso pode ser realizado.
InfoQ: Quais são os possíveis relacionamentos entre fluxos de valor e áreas de negócios?
DeArdo: É importante, como dito antes, alinhar produtos de negócios com equipes de produtos. Uma complexidade com a qual muitas áreas lidam é que isso não é claramente visto hoje, o que leva a otimizações locais que, na verdade, não melhoram o fluxo de valor para esses clientes.
InfoQ: Como a orientação a produtos ajuda a melhorar o gerenciamento e a mitigação de riscos? Não há mais riscos de se "esquecer" os riscos quando não são mapeados para um projeto específico?
DeArdo: Os riscos são inerentemente associados a um produto. Por exemplo, há o risco de que, se eu não trocar o óleo ou fizer uma manutenção nos carros da minha família, ocorram falhas. Como os riscos para cada carro são diferentes em termos de tipos e prazos, tê-los como parte de um projeto "Transporte" seria mais trabalhoso do que simplesmente ter cada produto usado para Transporte com seu próprio conjunto de atividades que inclui os riscos (por exemplo, recalls) e a atividade de manutenção (dívida) e também, talvez, "recursos", como a adição de Sirus XM.
O PO (product owner) é mais capaz de fornecer o "pensamento sistêmico" em torno do que é melhor para esse produto. Há visibilidade entre os diferentes tipos de trabalho que estão sendo continuamente priorizados e rastreados.
Por fim, muitas vezes os gerentes de projetos são recompensados por fornecer recursos de negócios a um custo mínimo. Pagar por uma correção de segurança em um sistema que está sendo alterado na versão não é algo que se alinha a essa meta. Ter uma orientação de produto concede esse controle ao PO para gerenciar sem incentivos conflitantes.