Em praticamente todas as empresas que já trabalhei, existia (e imagino que ainda exista) algum tipo de dívida técnica. Em algumas, para não falar todas, presenciei o cabo-de-guerra entre a equipe técnica, desejando tratar esses itens e defendendo o porque são importantes, e os responsáveis pelo produto, promovendo a criação de novas features.

Neste post eu vou te dar pelo menos um bom motivo para pagar dívidas técnicas, deixar uma dica de quando fazê-las e uma sugestão de como priorizá-las.

Porque fazer

Facilidade de manutenção, ganho de performance, compatibilidade com novas tecnologias, diminuir o tempo que o time gasta lidando com os sintomas dessa dívida técnica (e claro, o tempo que seu time passa lidando com esses sintomas, ele está perdendo de fazer novas features, que melhorariam seu time-to-market)… Existem vários ótimos motivos pra investir esforço e resolver a causa raíz, mas eu vou falar só de um.

Quando todos argumentos se esgotarem e ainda assim ficar a impressão de que “isso é capricho de desenvolvedor”, ainda vale a pena. Por quê? Pela satisfação dos seus funcionários.

Qualquer empregador vai falar que achar mão de obra especializada é difícil. Será que não vale incluir um item no seu backlog pra manter um bom empregado?
Você ralou para achar um especialista, e agora que o encontrou, negligenciar a opinião dele pode gerar insatisfação.

Recentemente conversei com um gerente de produto de uma startup, e ele disse que uma das perguntas da entrevista que passou era: “se um desenvolvedor ameaçar sair caso um item X não seja desenvolvido, o que você faz?”
Segundo ele, várias respostas estariam certas na linha de entender esse item X, mas existe uma resposta errada: “é só um desenvolvedor, eu deixo sair”.

Talvez você não seja surpreendido com um funcionário falando isso explicitamente, mas ligue seu radar se a equipe reclamar muito de dívida técnica. Às vezes isso já é um indicativo da infelicidade desses profissionais e currículos podem já estar sendo disparados para outras empresas.

Quando fazer

Se você leu a seção acima e ficou convencido, ou já começou o texto com a intenção de lidar com dívida técnica, a partir daqui eu posso te ajudar.

Aceitar que vamos trabalhar com dívida técnica não significa que vamos parar tudo e ficar semanas focados nesses itens.

Importante: estou considerando aqui que os “juros” dessa dívida técnica estejam sob controle. Se não estamos fazendo nada da dívida e seria apenas uma melhoria para o processo, essa sugestão se aplica. Agora, se você tem um incêndio, talvez você precise de um plano de ação mais agressivo, incluindo talvez parar e trabalhar apenas na dívida técnica.

No universo do Scrum, o termo “hardening sprint” é usado para designar uma sprint inteira dedicada a consertar bugs e resolver dívidas técnicas. Deixo claro que por mais que o termo seja usado, o Scrum desaconselha totalmente essa prática, sugerindo por exemplo, considerar uma parte do esforço da sprint para tratar esses itens.

Recentemente estive com um time que tinha uma quantidade considerável de dívida técnica e, por alguns meses, até se dedicaram a trabalhar apenas nelas. Foi um período de insatisfação tanto das pessoas desenvolvedoras, quanto das pessoas de produto. Com o tempo, eles voltaram ao desenvolvimento de features, e o backlog de dívida técnica ficou parado, onerando capacity do time com pequenas demandas originadas das mesmas. Eles não trabalhavam com Scrum, nem nenhuma outra metodologia/framework. Existia, porém, um quadro tipo kanban (k minúsculo aqui).

A solução então para garantir que dívida técnica seria endereçada sem paralisar totalmente a entrega de features foi usar limites de WIP (Work in Progress).

O time não utilizava Kanban, nem limites de WIP (e nem era algo para se implantar no momento), mas chegamos num combinado:
Em qualquer dado momento, existirá um item de dívida técnica no quadro do time, sendo trabalhado.

Essa estrutura garantiu que existia um espaço para trabalhar em resolver dívida técnica, e tranquilizou stakeholders no sentido de mostrar que não iríamos “parar tudo” para trabalhar nesses itens.

Dependendo do tamanho do seu time e da sua necessidade, esse limite de WIP pode ser diferente de 1.

Essa ideia pode ser adaptada para um time com Kanban propriamente dito, com a criação de uma raia dedicada e limite de WIP considerando o tipo de demanda da “dívida técnica”.

Como priorizar

Não é só porque garantimos um espaço pra resolver itens de dívida técnica que não precisamos priorizá-las.

Se foi trazida a necessidade de fazer, é porque vamos ganhar alguma coisa, e se estamos falando de valor, podemos priorizar de alguma forma.

Dívida técnica, por natureza, não é algo que vai gerar valor para seu cliente ou usuário, pelo menos não diretamente – se gera valor, deveria estar com o resto do backlog para priorização. Como priorizar, então?

Dado esse dilema, achei na literatura referências à matriz GUT. Em resumo, avalia-se o backlog em Gravidade, Urgência e Tendência. Cada item recebe uma nota nessas três categorias, e o problema com somatória mais alta seria o mais prioritário. Porém isso não me atendia.

A maioria dos problemas não tinham gravidade mensuráveis, e urgência era só quando a bomba estourava. A tendência era uma incógnita.

Usei então a estrutura de BVP: Business Value Points. Seria a definição de critérios que faziam sentido para o time, com pesos ponderados.

Note que esses critérios só fazem sentido para a equipe que estava trabalhando comigo. Você pode usá-los como referência, mas pergunte-se se refletem totalmente a necessidade do seu time.

Existe um critério nessa lista ligado à valor monetário, mas seu peso é o menor, dado que os itens aqui não tem a natureza de impactar financeiramente a empresa, mas ainda assim pode ser relevante (até como desempate).

Daí, foi só jogar os itens e ver o resultado dado a média, considerando os pesos (dados fictícios):

O time então pegou o primeiro item da lista e começou a desenvolvê-lo.
Durante as cerimônias de planejamento, a matriz é revista e atualizada, para que assim que o item em WIP for finalizado, puxarmos o próximo.

Achou que este artigo te ajudou? Tem problemas com dívida técnica e não cobrimos aqui? Deixe nos comentários!

The post Dívida técnica: Por que fazer, quando fazer e como priorizar first appeared on Plataformatec Blog.

Qual a sua teoria favorita sobre o papel de um líder? Para mim um resumo perfeito é esta fala do Jack Welch em What is the role of a leader. Em resumo, sem a pretensão de captar a emoção de ouvi-lo:

1. Ser o “Chief Meaning Officer”! Deixar claro para todas as pessoas à sua volta: para onde você está indo, por que você está indo e, mais importante, o que haverá para elas quando elas chegarem lá com você.
2. Remover os impedimentos do caminho para que as pessoas possam agir e fazer as coisas acontecerem. Quebre os silos, se livre das burocracias.
3. Ser generoso. Vibrar com o sucesso das pessoas.
4. Ser o “Chief Fun Officer”. Dê seus pulos para tornar o trabalho divertido!

E qual o papel de um líder em uma empresa de produtos digitais? Não deve ser nada diferente disso, certo? Mas afinal, como traduzir estes conceitos para a realidade de uma empresa de produtos?

Trazendo para este contexto, quem melhor traduz o papel de um líder é o Marty Cagan em Empowered Product Teams. Na minha opinião, este conteúdo é o mais relevante que ele publicou direcionado para líderes que estão à frente de empresas de produtos digitais. E por que é tão relevante? Porque coloca de uma forma mais tangível estratégia e cultura, temas muito falados mas pouco colocados em prática.

Motivos de resistência da liderança

Um tópico bem interessante deste artigo é a explicação do por que líderes resistem tanto para empoderar seus times e continuam mantendo o estilo comando-controle.

Segundo ele, existem duas formas de gerenciar uma empresa de produto:

• O jeito errado: “Na maioria das empresas, os times de tecnologia existem para atender o negócio”. De alguma forma, líderes de outras áreas de negócios (vendas, marketing, CEO) acabam direcionando o produto, que é apenas construído pelo time de tecnologia.
• O jeito certo: “Em empresa com forte cultura de produto, times de produto existem para um propósito muito diferente. Eles existem para atender os clientes, de formas que também atendam às necessidades do negócio”. Ou seja, o foco é o cliente e não stakeholders internos. Mas obviamente o produto também tem que ser sustentável para o negócio. Gibson Biddle diz algo semelhante de uma forma mais poética “encantar clientes, de maneiras que sejam lucrativas e difíceis de copiar”.

Marty Cagan conta que conversou com CEOs de várias empresas para entender porque eles continuam trabalhando do jeito errado com desenvolvimento de produtos, mesmo conhecendo o jeito certo. A resposta foi “falta de confiança” no time. A crença é que este modelo de trabalho (o jeito certo) só funciona em empresas que podem contratar profissionais extraordinários, como os do Google, Netflix, etc.

O curioso é que já existem muitos estudos que comprovam que times de alto desempenho não são formados por estrelas, mas sim por pessoas comuns. Aliás, estrelas muitas vezes atrapalham!

“They would be surprised at how ordinary the vast majority of the members of these company’s product teams actually are, and that maybe the important difference lies elsewhere.”

Outra justificativa comum para não empoderar os times é “pessoas de tecnologia não entendem de negócios”! Quem de tecnologia já não precisou respirar bem fundo quando ouviu esta frase? Times de produto precisam do contexto de negócio, para que possam descobrir a melhor forma de resolver problemas dos clientes.

A falta de confiança certamente não é um problema fácil de resolver, já que em muitas situações os times são de fato muito inexperientes. Mas é importante caminhar nesta direção, desenvolvendo as pessoas para que elas possam atuar do jeito certo. Definitivamente, entrar em um ciclo vicioso de falta de estratégia, time inexperiente e comando-controle, não é um bom caminho!

Papel do líder no “jeito certo” de trabalhar

Trazendo para o contexto de empresas de produto, como ser o “Chief Meaning Officer”? Ou seja, como deixar claro para as pessoas para onde você está indo e por que. A Visão e Estratégia de produto são essenciais para trazer este significado e dar um direcionamento ao time, para ele possa trabalhar de forma autônoma.

Visão de Produto

A visão de produto descreve o futuro que queremos criar, em 2 a 5 anos. A importância desta visão é setar um norte inspirador e delimitar um contexto de atuação. Em startups, é muito comum o foco do produto principal ir se perdendo ou o escopo de atuação ficar muito amplo. Isto acontece principalmente quando empresas recebem investimentos e começam a diversificar o portfólio. Sem uma visão para guiar e delimitar as fronteiras, os times de produto podem ficar sem foco, não atingirem resultados e a liderança voltar a assumir o estilo comando-controle.

Estratégia de Produto

A estratégia define qual caminho precisa ser seguido para se alcançar a visão. Um erro comum na definição da estratégia é não fazer uma reflexão do momento atual e traçar uma estratégia pouco realista. Em Escaping the Building Trap, Melissa Peri apresenta um framework bem interessante para definição de estratégia.

Outro artefato, o Product Principles, também ajuda a delimitar o contexto e facilita decisões em priorização. Os princípios descrevem a natureza dos produtos que pretendemos desenvolver e reflexões sobre nossas crenças sobre o que é importante.

Exemplo de coisas que podem ser interessantes explicitar no Product Principles:

• Vamos aceitar desenvolver customizações (features específicas para alguns clientes)?
• Se o produto tem mais de um cliente (vendedores e compradores, por ex), quem vamos priorizar?
• O que é mais importante, velocidade ou qualidade?
• Queremos desenvolver tudo sozinhos ou vamos fazer parcerias?

Uma vez que a Visão e Estratégia estejam definidas, como garantir que elas sejam seguidas? Em empresas com muitos times, como desdobrar a estratégia para os diversos times e manter o alinhamento? No artigo How to Run a Quarterly Product Strategy Meeting, Gibson Biddle, apresenta um processo bem interessante para definição de estratégia de times e também um passo a passo de como estruturar uma reunião de “review” de produto.

Mais sobre o jeito certo de trabalhar

Outras fontes interessantes para entender este jeito certo de trabalhar:

• Escaping the Building Trap, Melissa Perri. Apresenta uma boa explicação da relação entre Customer, Business e o papel do Product Manager em Product-led e Sales-led organizations. As dicas para desenhar estratégia também são valiosas.
• Product team vs Feature Team, Marty Cagan. Reforça de forma bem didática e enfática os conceitos já apresentados em Empowered Product Teams. Feature team é o jeito errado de se trabalhar, no qual os times de produto existem somente para entregar features já priorizadas em um roadmap.
• Coach – Customer Centricity, Marty Cagan. Explica quem são os verdadeiros clientes de um Product Manager: as pessoas que usam o produto! Stakeholders internos (vendas, CEO, etc) não podem ser considerados clientes. Afinal, o time de produto não existe para servir ao negócio!
• Digital or Traditional, Joca Torres. Reflete sobre a diferença do escopo de atuação do Product Manager em empresas Digitais (que tem como core do negócio um software), empresas Tradicionais (que tem como core outros tipos de produto) e empresas que não vendem software, mas tem o software como parte vital do negócio, denominadas born-digital traditional company.

Resumindo

Uma das responsabilidade principais de um líder de produto é definir um norte para o produto e garantir que toda empresa esteja alinhada à ele. Para isso:

• Defina a visão e estratégia de produtos.
• Divulgue para toda a empresa, não apenas para os times de Produto e Engenharia.
• Desdobre a estratégia para todos times.
• Crie cerimônias para garantir o alinhamento entre todos os times.

Caso isso já esteja sendo feito, mas mesmo assim os times não estejam trabalhando com autonomia e alcançando resultados, vale refletir:

• Existe resistência da liderança para empoderar os times?
• Existe um entendimento sobre o papel de um time de produto?
• Se não existe confiança no time, qual é o plano para desenvolver e empoderar este time?

Como tem sido a liderança de produto na sua empresa? Deixe sua impressão nos comentários abaixo.

The post O Papel do Líder de Produto first appeared on Plataformatec Blog.

Neste blogpost vou mostrar a vocês como gerar previsibilidade para o Story Mapping a partir das métricas. Bora lá?

Recapitulando o Burnup

Primeiro, vamos falar brevemente sobre o gráfico de Burnup, a métrica que iremos utilizar como ferramenta.
O Burnup permite acompanhar o progresso e o montante de trabalho concluído versus o tamanho total de um escopo de trabalho, fazendo uma projeção linear baseada no histórico de produtividade do time. Através dele, podemos ter uma noção do quão próximo ou distante estamos de atingir um objetivo, ou seja, o popular “quanto falta para terminar o projeto”.

A leitura deste gráfico é feita da seguinte forma:

• No eixo vertical temos duas representações gráficas, sendo a primeira a quantidade de novos itens inseridos no backlog do projeto/produto, representado pela área colorida (neste caso, em amarelo), e a segunda a quantidade de itens deste backlog que foram finalizadas pelo time, representado pelas barras verticais sequenciais;
• E no eixo horizontal temos uma escala de tempo para visualizar o crescimento dos valores descritos no eixo vertical (neste caso medido em semanas).

Ou seja, conseguimos aqui acompanhar tanto o crescimento do backlog semana a semana quanto o valor de throughputs acumulados que o time vem entregando.

Dados estes valores, podemos projetar três diferentes cenários:

• O Pessimista: projetar a performance futura da equipe com base no menor Throughput histórico;
• O Mais provável: considerar que a equipe terá no futuro um comportamento semelhante ao Throughput “médio” performado;
• O Otimista: considerar que a equipe performará nas próximas semanas igual ao valor de maior Throughput histórico ja registrado pelo time.

Caso queira se aprofundar um pouco mais sobre Throughput e Burnup, recomendo a leitura deste blogpost do Raphael Albino. Agora vamos unir os assuntos!

E o que o story mapping tem a ver com isso?

Uma das etapas finais do story mapping, é fatiar o backlog levantado em objetivos menores e que em um curto prazo já podem entregar valor ao usuário final ou persona cujo problema estamos tentando resolver. Segue um exemplo onde foram definidos os três primeiros objetivos e abaixo o backlog não priorizado (imagem desfocada para preservar a confidencialidade dos dados).

Dado que nós já temos as fatias de entregas mapeadas, e se ao invés de incluirmos o backlog levantado como uma única stack dentro do nosso Burnup, utilizarmos do mesmo artifício de fatiamento e criarmos as visões de entrega de cada release?
Basicamente nós temos a seguinte visão:

Cada fatia entra individualmente como uma porção de backlog isolada. Como a leitura deste gráfico é feita de baixo para cima, logo, a primeira fatia do Story Mapping (a que está no topo e representa o primeiro objetivo de entrega), virá acima do objetivo atual do time (representado pela porção azul do Burnup), e assim sucessivamente, conforme a indicação das setas.
Podemos observar que é possível obter hipóteses de data de entrega, pessimista, provável e otimista, para cada uma das fatias do nosso Burnup, esteja o time já trabalhando nelas ou não. Com isso, torna-se possível setar ou controlar expectativas com pessoas que têm interesse no projeto ou em uma entrega, tanto de forma interna (para o próprio time) como externa (ex: Um patrocinador do projeto).

Munindo o time com estas informações, a equipe será capaz de assumir estratégias melhor direcionadas de acordo com a necessidade. Ex: Negociar escopo caso seja necessário cumprir uma data de entrega específica ou alinhar estratégias de lançamento de um produto dadas as perspectivas de finalização do trabalho que está em vista.
Porém, existem alguns pontos que devemos ter atenção quando utilizamos o burnup como ferramenta de previsibilidade, vamos ver a seguir.

Premissas que impactam diretamente as estimativas/previsibilidade

• As datas de projeção consideram o tamanho atual do backlog e a vazão do time dentro de uma linearidade. À medida que estes valores avançam, estas datas também sofrerão alteração (Ex: um crescimento no backlog ou uma mudança drástica no padrão de entregas do time);
• Mantenha os valores de throughput utilizados para a projeção sempre atualizados. É sempre importante considerar a realidade do time em relação à cadência de entregas para se ter previsibilidade. Afinal, não faz muito sentido eu projetar estimativas de entrega considerando um padrão de comportamento que não condiz mais com a realidade do time, certo?
• Se o time ainda não possuir um histórico de throughput relacionado ao projeto, o ideal seria coletar esta métrica durante algumas semanas para utilizar estes dados como insumo antes de criar-se a expectativa com datas e prazos. Caso seja de fato necessário ter esta ideia de prazo para pelo menos se ter uma perspectiva do quando a entrega seria feita, pode-se utilizar do histórico de outros projetos que o time ja trabalhou. Porém, é preciso levar em consideração diversas variáveis que impactam diretamente na assertividade em utilizar estes valores passados (tais como tamanho da equipe, se a composição do time é a mesma, tecnologias utilizadas, experiências que o time tem neste tipo de projeto, etc.
• Sinalize corretamente a qual releases cada tarefa pertence. É muito importante que cada uma das tarefas do backlog esteja enquadrada dentro do objetivo ao qual ela pertence, não só para as tarefas que foram originadas no story mapping mas também para todas as demais que podem surgir ao longo do caminho devido a processos como o Refining ou task splitting;

Como as datas de projeção/previsibilidade de entrega são extremamente sensíveis, conforme vimos nas premissas acima, minha dica final é fuja de utilizar estas datas como prazos determinantes e utilize como probabilidades de cenários (Ex: Se tudo der certo e nada diferente do habitual acontecer, temos boas chances de entregar por volta do dia DD/MM, mas é esperado que seja perto de DD/MM (de acordo com as linhas de projeção).
Desta forma, caso algo inesperado ou emergencial aconteça, o time consegue responder de forma adequada sem comprometer fortemente as expectativas geradas sobre as entregas.

Resumindo

Utilizando estas duas ferramentas em conjunto, conseguimos ter de forma mais concreta um cenário de previsibilidade que pode ajudar o time a setar expectativas com quaisquer stakeholders que estejam dependentes destas entregas ou possuem algum tipo de interesse sobre elas. Além disso, as próprias pessoas do time terão uma maior sensação de progresso em relação aos objetivos que elas mesmas mapearam e isso os ajudará a tomar melhores decisões ao longo do tempo.
Esta é apenas uma das formas de obtermos melhor previsibilidade das entregas do time. Existem diversas outras ferramentas que podem ajudar também, como o Reality Check 

O que achou desta abordagem? Deixe aqui seu comentário sobre como você trata previsibilidade de entregas dentro do seu time ou nos escreva enviando para contagil@plataformatec.com.br. Caso queira começar a utilizar o Burnup, nós disponibilizamos uma versão gratuitamente através da Planilha de métricas da Plataformatec. 

Abraços e até a próxima!

The post Extraindo previsibilidade à partir do Story Mapping first appeared on Plataformatec Blog.

Tentando me embasar melhor neste assunto para conversar com clientes e stakeholders em geral, decidi coletar dados de um projeto real e realizar uma análise sobre a relação da pontuação destes cards e o tempo que os mesmos demoram para serem desenvolvidos, contando desde o momento que eles começam na etapa de desenvolvimento até o momento em que são entregues em produção, o famoso lead time.

Disclaimers

Antes de começar, alguns disclaimers sobre o contexto do projeto:

• Logo nas primeiras semanas do projeto já tivemos o primeiro grande problema com story points: subjetividade na pontuação. Por que este card é 3? Como eu sei se este card é duas vezes maior ou três vezes maior do que o card X? O que eu considero nesta pontuação?
  • Desta forma, foi sugerido ao time que utilizasse alguns critérios para estimar com o intuito de diminuir essa subjetividade.
  • Meu amigo e colega de trabalho Henrique Oliveira sugeriu uma matriz Fibonacci-like, com base nas estimativas T-Shirt Size, para pontuar os cards que auxiliou bem ao time. Confira abaixo:

• Cards com 13 ou mais pontos eram quebrados em cards menores, pois a única vez que tentamos trabalhar com um card do tamanho 13, ele estorou o timebox da sprint, que era de 10 dias úteis.
• Os cards eram quebrados de uma forma que entregassem algo funcional em produção, de forma que backend e frontend ficassem juntos em uma mesma história.

Vamos aos dados

Primeiramente, coletei os dados do projeto como um todo e analisei o gráfico de lead time com todos os cards que já foram finalizados ou que estavam em desenvolvimento.

Após capturar estes dados, eu separei os cards por pontuação e os analisei separadamente, tendo os seguintes gráficos:

Cards com 1 story point

Cards com 2 story points

Cards com 3 story points

Cards com 5 story points

Cards com 8 story points

Cards com 13 story points

Análise dos dados

Após analisar este dados, consegui obter algumas conclusões:

• É possível verificar que cards com 3, 5 e 8 pontos têm um tempo de desenvolvimento (lead time) parecido, não sendo possível estabelecer relação entre tempo e quantidade de story points.
• Se pegarmos uma categoria com bastante amostras, como os cards com 5 story points, é possível perceber que os mesmos variam bastante, não podendo estabelecer afirmações como “um card de 5 pontos leva entre X e Y dias para ser desenvolvido”, sendo X e Y um intervalo pequeno de dias (entre 1 e 3 dias). O mesmo acontece com os cards de 3 e 8 pontos.

Observação: Os dados referentes aos cards de 1, 2 e 13 story points foram retirados da análise individual, pois haviam poucos dados para serem analizados separadamente.

Outras análises além dos story points x lead time

Houve outras conclusões sobre a utilização dos story points que eu gostaria de compartilhar com vocês:

• No começo do projeto, quando começamos a utilizar os story points, a subjetividade era muito alta. Estabelecendo alguns critérios para a pontuação, foi possível estabilizá-la, fazendo com que o tempo de desenvolvimento das histórias variasse menos e, com isso, aumentando a previsibilidade. Se você gostaria de desenvolver isso dentro do seu time, considere a leitura deste artigo do Mike Cohn.
  
• Com a adição de mais critérios à pontuação, como complexidade nos testes, dependência de outras pessoas fora do time (internas ou externas a empresa), risco relacionado a história e outros, diminuímos a variabilidade do lead time e aumentou a previsibilidade de entrega dos cards.
• Muitas vezes story points são relacionados diretamente ao esforço de desenvolvimento, o que faz com que o time foque somente no esforço e no tempo para a execução de uma tarefa. Outro ponto é que os testers/QAs e UXs/designers, geralmente, se envolvem pouco ou nada nas estimativas. Fazer o time pensar não só no desenvolvimento, mas também na duração do processo como um todo (considerando etapas de code review, testes, deploy, etc) e envolver outras pessoas na participação das estimativas para exporem suas preocupações e comentários sobre a demanda, ajuda a melhorar previsibilidade do seu time.
• O auxílio de métricas para melhoria de processos, como lead time breakdown e CFD, ajudaram muito neste processo de estabilização da pontuação, fazendo o time pensar mais no processo como um todo e mostrando em que etapa do processo eles estavam gastando mais tempo.

Conclusões

As principais conclusões que eu tive foram:

• Não foi possível relacionar tempo de desenvolvimento (lead time) com story points diretamente, conforme o propósito do estudo.
  • Vale um adendo aqui que Story Points devem ser utilizados dentro do nível de time. Se quer saber mais sobre este assunto, recomendo a leitura deste texto do Troy Magennis
• Foi possível melhorar a previsibilidade da entrega do time e atingir uma estabilização do processo de desenvolvimento utilizando story points junto com outras ferramentas.
• Existem indícios que, quando se adiciona mais critérios à pontuação, quanto menor a pontuação de um item, menor será seu risco/esforço/complexidade e, consequentemente, maior será sua previsibilidade.
• Um grande ponto aqui é que os Story Points consideram em suas estimativas somente os momentos em que uma demanda estará sendo trabalhada e não considera/não consegue prever o tempo que uma demanda vai ficar em estado de espera. Basicamente, o time considera ao estimar quanto tempo uma demanda pode levar para ser desenvolvida e testada, mas não considera nesta estimativa (por não poder prever alguns pontos no meio do desenvolvimento) quanto tempo uma demanda vai ficar aguardando para ser testada, para realizar o deploy ou para a resolução de um impedimento. Em outras palavras, a eficiência do seu fluxo vai impactar no seu lead time e, consequentemente, na relação dos story points com o tempo de desenvolvimento. Desta forma, é possível que uma user story de 1 ponto leve a mesma quantidade de dias para ser finalizada do que uma user story de 13, devido a sua eficiência de fluxo. Se quiser saber mais, consulte este texto aqui.

E se te perguntassem se você utilizaria story points para estimar um prazo para a entrega de um projeto ou card, o que você responderia?

Eu diria que story points, assim como a matriz de complexidade por incerteza (T-shirt Size), são excelentes ferramentas para instigar o seu time a quebrar melhor as histórias de usuário e ajudar a fazer melhorias de processos, porém, para dar uma estimativa de prazos, eu preferiria utilizar métricas e outras ferramentas, como simulações de Monte Carlo para prever quando um conjunto de cards vai ser entregue.

E você? Já teve alguma experiência com Story Points e estimativas de tempo? Já sofreu com algum cenário parecido? Qual a sua opinião sobre o que compartilhei neste texto? Compartilhe com a gente comentando aqui embaixo ou pelo e-mail contagil@plataformatec.com.br

The post Relação de Story Points com o Tempo de Desenvolvimento (Lead Time) first appeared on Plataformatec Blog.

Primeiro é importante fazer um adendo: nosso papel como profissionais (e principalmente o nosso como consultores na Plataformatec) é encarar a situação das equipes como elas realmente são, não como gostaríamos que fossem. As ideias desse texto se aplicam melhor em times em formação. Se você já trabalha com uma equipe auto-organizada e motivada com suas atividades, o melhor uso desse conteúdo pode ser no nível organizacional.

Existem várias teorias que falam sobre a motivação no ramo da psicologia. Se você gosta do assunto provavelmente já ouviu falar da pirâmide de Maslow ou fatores higiênicos de Herzberg. Hoje eu vou falar sobre a fórmula de Vroom e a teoria de necessidades adquiridas. Vamos partir do pressuposto que todos os fatores básicos para Maslow e higiênicos de Herzberg (remuneração, segurança, condições de trabalho, etc) estão sendo atendidos.

Inicialmente vamos ver quais os fatores se relacionam com a motivação. Abaixo está uma adaptação da fórmula de Vroom que os ilustram e adiciona o fator tempo ao conceito original.

Valor

Valor nos diz sobre a percepção de importância que as pessoas dão para algo. Isso é individual para cada membro da equipe, alguns valorizam apenas retorno financeiro, outros preferem folgas ou serem direcionados para atividades que lhes tragam mais satisfação. Para saber o que de fato uma pessoa valoriza precisamos entender seus valores, preocupações e objetivos.

Capacidade

Capacidade é a crença que a pessoa consegue fazer o que é necessário para ganhar uma recompensa. Se um membro da equipe (ou a equipe toda) não acredita que consegue fazer algo, dificilmente vai se comprometer verdadeiramente com o seu objetivo. Quando dou aula, gosto de exemplificar para os meus alunos com a seguinte proposta: “Passo com nota 10 na matéria quem conseguir ir ao departamento do outro lado do campus e voltar com essa folha assinada em 5 minutos”. Até hoje nenhum aluno se levantou da cadeira para tentar. Para aumentar a sensação de capacidade garanta treinamento e ferramentas adequadas para os trabalhos da equipe.

Esforço

Esforço é literalmente o quanto de energia uma pessoa precisa investir para receber uma recompensa. A relação é direta ao valor percebido: quanto mais difícil for fazer algo maior precisa ser a recompensa. É o conceito básico de retorno sobre investimento na esfera individual.

Tempo

O tempo para receber a recompensa é um fator interessante. Tendemos a preferir o hoje ao invés do amanhã. Quanto mais tardia for a recompensa, menos motivados vamos estar. Isso se reflete na prática em ciclos de recompensa e feedback mais curtos. Por isso algumas empresas gostam de fazer OKRs trimestrais e ciclos de avaliações de performance curtos.

Essa fórmula pode ajudar a guiar estratégias de motivação. É importante notar que se valor e capacidade forem muito baixos ou o esforço e tempo forem muito altos, a motivação tende a ser baixa.

O que tem valor para os membros da nossa equipe?

Agora que entendemos os fatores que influenciam a motivação, vamos falar um pouco sobre a variável Valor: como entender o que os membros da nossa equipe valorizam?

Uma das teorias existentes é a das necessidades adquiridas, ela diz que buscamos 3 coisas: poder (ou controle), resultados e afiliação. Como citado no início, esse é apenas um entre vários modelos para entender valoração.

Necessidade de Poder (ou controle) é a busca por influência. Pessoas com necessidade de poder gostam de controlar as situações, são ambiciosos e autoconfiantes. Para motivar pessoas assim, lhes dê autonomia sobre seu trabalho, envolva-as na gestão estratégica e na tomada de decisão. Pessoas desse grupo que apresentam traços de empatia e que conseguem dividir o poder de escolha com seus pares podem ser futuros líderes.

A necessidade de Realização é a preocupação por excelência e conquistas através do esforço individual. São pessoas enérgicas, determinadas, que trabalham duro, apreciam feedback realista e procuram maneiras para realizar um bom trabalho. Podemos manter essas pessoas motivadas com objetivos SMART, tarefas bem definidas e um ciclo rápido de feedback.

Necessidade de Afiliação é o desejo de socializar e ser aceito pelos pares. Essas pessoas gostam de desenvolver, manter e restaurar relações pessoais próximas. São sociais, com inteligência emocional e empatia. Esses membros da sua equipe vão se sentir motivados naturalmente se puderem ajudar a desenvolver pessoas, participar de onboarding e treinamento de novos membros da equipe.

Colocando na prática

Agora que você entende melhor alguns fatores de motivação, converse com as pessoas da sua equipe e descubra o que eles buscam. Ajude-os a organizar as atividades para que cada pessoa tenha responsabilidades condizentes com a seu perfil.

Também pode ser necessário ajudar a sua organização como um todo a definir políticas e recompensas que as pessoas valorizam. Isso vai ajudar não apenas a motivação, mas também e engajamento e retenção dos talentos dos times.

Quer conversar mais sobre liderança servidora e soft-skills? Está com um problema no seu time que gostaria de ver abordado? Deixe seu comentário e sugestões sobre quais tópicos gostaria de ver nos comentários ou pelo email contagil@plataformatec.com.br

The post Entendendo a motivação do seu time first appeared on Plataformatec Blog.

Inspiradas por estruturas orgânicas e multidisciplinares que vão contra as práticas que padronizam e especializam o trabalho, as empresas estão em busca de entregar novas formas de proposta de valor aos clientes, utilizando de maneira efetiva os meios digitais e mantendo sua vantagem competitiva em um mercado que exige uma reconfiguração constante das suas práticas, dos seus processos, dos recursos tecnológicos, dos papéis e das suas equipes.

Se você atua em uma empresa que já nasceu digital, é provável que alguns conceitos modernos já façam parte da sua rotina, tais como jornada de usuário, desenvolvimento de soluções centradas nas pessoas clientes, ciclos constantes de feedback, colaboração entre as diferentes especialidades do negócio para melhorar os resultados da empresa, modelos de bonificação que privilegiem o todo e entregas contínuas de software.

Contudo, existem empresas que estão inseridas em um cenário onde o sucesso é medido por projetos entregues dentro do prazo, custo e escopo. Além disso, os ciclos de entrega de software acabam sendo anuais, tamanha a complexidade na arquitetura tecnológica. Já o modelo de bonificação fica limitado aos silos criados pelos diferentes departamentos, o que pode produzir resultados locais positivos, porém, com perdas quando há uma consolidação da visão global. Por fim, a opinião das pessoas clientes torna-se algo distante do cotidiano de quem está na operação do negócio.

A seguir, gostaria de compartilhar 5 dicas de como você pode promover uma gestão por produtos digitais na sua empresa.

1) Entenda a estrutura de governança da empresa

Antes de pensar em começar um processo de transformação, tenha em mente qual é o estilo de governança que prevalece no seu ambiente. Para isso, sugiro a leitura do trabalho publicado por Grandori e Furnari (artigo original disponível aqui).

Em linhas gerais, o artigo apresenta que os negócios inovadores combinam diferentes tipos de estruturas de governança interna caracterizadas por:

• Mercado (incentivos monetários): pagamento por desempenho (individual ou coletivo);
• Burocrático (autoridade): ambientes que cultivam processos bem definidos, o uso de boas práticas, estruturas delimitadas e políticas explícitas;
• Comunitário (divisão de conhecimento, valores e cultura): espaço que valoriza o compartilhamento de informações, o trabalho em equipe e a participação das pessoas no processo de decisão/escolhas;
• Democrático (responsabilidade, decisão e direitos representados): distribuição das responsabilidades, enriquecimento das atividades das pessoas colaboradoras e empoderamento das pessoas.

Se as práticas da sua organização têm como foco o resultado (mercado), provavelmente você terá dificuldades em desenvolver uma base de colaboração.

Se há um excesso de burocracia, a eficiência das ações será prejudicada e a agilidade necessária ficará limitada.

Se não existe uma cultura de trabalho em equipe e distribuição das responsabilidades, os silos e as camadas hierárquicas serão fatores limitantes para a inovação e a construção de uma visão sistêmica da cadeia de valor.

Nem todas as organizações terão um estilo de governança propício para combinar inovação, cooperação e geração de resultado.

Agora que você conhece os diferentes estilos de governança, algumas reflexões podem ser interessantes como:

1. Como os estilos presentes na empresa que estou podem ser potencializados de forma positiva para que a mudança aconteça?
2. Dado o estilo de governança existente, faz sentido forçar a mudança?

2) Utilize a camada média como uma promotora da mudança

Provavelmente ao fazer qualquer tipo de mudança você se deparará com alguma resistência de pessoas que estão nas camadas intermediárias da organização (gestão, coordenação e afins).

Em grande parte dos casos, a diretoria e a equipe operacional estarão compradas de que mudar a mentalidade para trabalhar de forma mais digital é necessária a fim de garantir a sustentabilidade da empresa. No entanto, pessoas que se encontram no meio da cadeia hierárquica se sentirão ameaçadas e poderão não apoiar a transformação.

Ao invés de julgar e ignorar essas pessoas, identifique as que estão interessadas em favorecer a mudança, utilize os canais gerenciados por elas para promover um senso de urgência e utilize o capital social delas para reforçar as motivações da transição que acontecerá.

Há situações em que a resistência é tão grande que a pessoa realmente não consegue dar uma oportunidade à mudança e infelizmente ela pode passar a não fazer mais parte da empresa, por não conseguir se adaptar ao momento atual. Isso faz parte do processo. Mas em linhas gerais, procure embarcar a camada média no propósito da mudança e utilize-a como promotora da transformação.

3) Gerencie os domínios de uma cultura de produto digital

Tenho observado nas empresas que uma mudança para a mentalidade de produto digital depende da combinação do alinhamento e da direção construídas com a robustez da estrutura organizacional.

Para garantir o alinhamento e a construção de objetivos consistentes é importante que exista uma clareza no modelo de negócio da empresa, sua estratégia esteja clara e que haja visibilidade dos indicadores de performance utilizados para guiar a saúde do negócio. Sem um norte que combine estes elementos, a visão da empresa ficará perdida.

As pessoas e as equipes precisam entender que o trabalho delas está conectado diretamente com a sustentabilidade do negócio. Além do mais, a alta gestão precisa trazer foco e um senso de priorização para as iniciativas que são demandadas.

Sem alinhamento e direcionamento, as pessoas ficarão presas ao modelo de reconhecimento pela entrega ao invés de focar no resultado que está sendo gerado para o todo.

Para que os objetivos sejam entregues em um universo digital em constante mudança, a empresa precisa desenvolver uma capacidade de execução que é sustentada por pessoas habilitadas, processos enxutos e uma arquitetura de software flexível.

Se a empresa não cria mecanismos para formar as pessoas, não simplifica os processos de desenvolvimento de software e não enxerga a tecnologia como um ativo estratégico que precisa ser constantemente evoluído, ela dificilmente criará resultados de negócio de forma assertiva através do meio digital.

Costumo dizer que não existe entrega de produto no contexto digital sem práticas de engenharia de software e sem processos que privilegiam uma cultura de aprendizagem e resolução de problemas.

4) Construa uma visão sistêmica e promova equipes multidisciplinares

Conhecer a jornada com que as pessoas clientes interagem com os produtos e serviços da organização é a base para a construção de soluções digitais que possibilitem melhores experiências.

Captar o que é sucesso para as pessoas consumidoras e traduzir tais critérios em produtos digitais incríveis é um dos grandes desafios de um processo de mudança.

Algumas técnicas que tenho recomendado para as pessoas aplicarem quando desejam construir uma visão orientada ao resultado são:

• Construção de uma jornada de usuário para a compreensão das dores e as insatisfações ao longo do uso do produto oferecido pela empresa.
• Mapeamento de processos para a identificação de gargalos e pontos de melhoria.
• Entrevistas com as pessoas que utilizam o produto da empresa para coletar insights de aperfeiçoamentos da solução e para saber se elas valorizam critérios como tempo, qualidade dos atributos do produto ou conformidade dos requisitos.

Sem uma visão sistêmica (modo de irônia ativado) não há raio squaditizador que crie produtos que serão úteis para as pessoas.

Se você é um departamento de Tecnologia da Informação e não tem autonomia para influenciar o fluxo de aquisição do serviço que a sua empresa oferece, você não deveria ser chamado de squad. O mesmo se aplica se você é uma área de canais digitais que planeja o projeto perfeito de desenvolvimento de um aplicativo móvel, espera 12 meses para receber a solução que alguém fez e depois não tem ideia de como evoluir o artefato entregue.

Nos casos citados acima, a departamentalização gera barreiras para a criação de uma visão sistêmica e inibe a colaboração necessária para o desenvolvimento de produtos.

Desenvolver e preservar equipes que combinem todas as disciplinas necessárias para solucionar os problemas das pessoas que são clientes garantirá produtos em constante conexão com as necessidades do negócio (ex: novas receitas, aumento na satisfação das pessoas clientes, redução dos custos etc.) e com o propósito de melhorar a experiência de quem usa.

5) As três disciplinas necessárias para uma boa gestão de produto

Seguindo a sugestão do método de gestão Kanban que diz para começarmos com o que fazemos hoje e respeitarmos os papéis existentes, deixo como última dica a busca pela aplicação das três disciplinas que estão por trás da construção de produtos digitais ao invés de uma abordagem revolucionária de mudança organizacional.

A primeira disciplina é o marketing de produto que tem como foco desenvolver processos para promover e vender produtos para as pessoas clientes. Além disso, é uma função intermediária entre a criação de produtos e o aumento do reconhecimento da marca.

Pensando no movimento de criação de produtos digitais, ter um bom marketing de produto ajudará na aquisição e retenção de clientes, bem como na promoção da empresa como marca provedora de soluções.

A segunda disciplina é a gestão de produto que pode ser resumida como o processo que se concentra em criar ou promover produtos/serviços.

Conforme definido pelo Joaquim Torres – Joca, a gestão de produto é uma função que cuida da conexão entre os objetivos estratégicos e a experiência das pessoas clientes, além de relacionar as ações do produto com uma visão global da empresa.

Uma boa gestão de produtos ajudará a empresa na construção de um portfólio saudável de soluções (deixo aqui a referência de um texto que escrevi sobre como avaliar os estágios de um portfólio de produtos).

A última, mas nem por isso menos importante disciplina é a de desenvolvimento de produto, que representa a forma como construímos as soluções. Práticas ágeis de gestão de projetos são excelentes aliadas na busca de promovermos ambientes colaborativos, com alta visibilidade e com entregas que permitam feedbacks constantes.

Dado que estamos tratando de produtos digitais, não devemos ignorar práticas de engenharia de software como integração contínua, entregas automatizadas e uma base de código bem gerida. Tais mecanismos permitirão uma otimização no fluxo de entrega e garantirão um resultado final de qualidade.

Ao dominar Marketing, gestão e desenvolvimento de produto, sua empresa conceberá soluções digitais eficazes nas resoluções dos problemas, conectadas com as necessidades de quem usa e de forma eficiente.

Conclusão

Segundo uma matéria recente da Gartner, até 2020, as organizações que adotarem um modelo de gerenciamento de produtos superarão as que não o fizerem.

A transformação digital tem exigido que as empresas saibam incorporar novas tecnologias na oferta de seus produtos/serviços, mudem a forma como criam valor para os clientes através de canais digitais, revejam constantemente seu modelo de negócios para usufruírem dos artefatos digitais e repensem suas estruturas para reduzir os custos de coordenação. Diante deste cenário, uma das formas de sobreviver passa por enxergar sua empresa com a lente de produtos digitais.

Qual a sua opinião sobre o que compartilhei neste texto? Quais estão sendo os desafios neste processo de mudança para produtos no seu ambiente? Não deixe de comentar abaixo ou enviar um e-mail para contagil@plataformatec.com.br!

The post Desenvolvendo um olhar de produto na organização first appeared on Plataformatec Blog.