“É só mais isso, prometo [EM HOMOLOGAÇÃO]!”

Entenda melhor o impacto do puxadinho nas demandas no seu projeto

Olá!

Este artigo tem como objetivo trazer informações importantes muitas vezes ignoradas pelos gestores ou até mesmo desconhecidas por eles. Você sabe qual o impacto que aquele puxadinho pode trazer pra sua demanda em homologação?

 

Vale destacar que tudo que será mostrado aqui, no fim das contas, resulta em perda de receita ($$), desmotivação da sua equipe e a falta de políticas explícitas[1] sobre determinadas partes do processo de trabalho de uma operação de desenvolvimento de software.

Então vamos lá!

 

A demanda

Vamos utilizar o seguinte cenário: temos um projeto que tem como objetivo aumentar a quantidade de assinantes pagantes dentro do site de notícias e colunistas. Para isso acontecer seria necessário desenvolver um mecanismo para limitar a uma quantidade X de leituras por mês e, caso o usuário queira ler mais, terá que pagar uma assinatura mensal.

 

Até aí tudo bem, kick-off[2] feito com a equipe de desenvolvimento, algumas histórias já com seus “critérios de aceite bem definidos” e liberadas para o desenvolvimento. Demandas sendo iniciadas pela equipe técnica, com a política explícita do DoD[3] (Definition of Done) bem entendida.

 

Após o trabalho da equipe de desenvolvimento, todos os critérios foram seguidos conforme o acordo.

“Toda vez que uma demanda é puxada parada ready for dev, é obrigação da gestão instruir  o cliente que, a partir daquele momento, todos os critérios ali definidos serão desenvolvidos e, no caso de novas demandas, deixar explícito o impacto financeiro no projeto.”

 

Demandas liberadas no ambiente Stage[4] para a homologação do cliente.

É cilada, Bino!

A partir desse momento, o usuário que está homologando está seguindo os passos definidos a partir de um test direction[5] criado pelo desenvolvedor. E a princípio parece estar tudo certo, MAS, vem aquela famosa frase: 

 

“Parece tudo ok mesmo… mas cadê aquela imagenzinha, selectzinho, ou informaçãozinha?”

 

A última coisa que você deve fazer é entrar em conflito com seu cliente. Retorne tão breve quanto possível informando que você irá revisar os critérios de aceite e já lhe responde.

Checados os critérios, você atesta que os pontos mencionados não tinham sido pedidos nesta determinada demanda. Você volta a falar com ele e diz que tal item não estava no critério e aí aquelas palavrinhas ressurgem e você, como um gestor “cool”, acaba acatando o pedido do seu cliente para poder ver os olhinhos dele brilharem.

É só uma coisinha…

O que você acaba de permitir é um golpe terrível para seus processos e a sua equipe. Vamos simular aqui um conjunto de processos que qualquer empresa de desenvolvimento de software madura deveria ter:

A demanda que acabou de ganhar um “puxadinho” pelo acordo entre o gestor e o cliente é a que está marcada em vermelho.

Analisando impactos

Olhando para esse Kanban, quais os  impactos que podemos visualizar por conta desse tipo de decisão? Vamos analisar olhando da direita para esquerda:

 

1. Irá atrasar a entrega dessa demanda e das demais que já estão em ready for deploy. Pela característica de ter duas demandas ali em ready for deploy podemos supor que é uma entrega de um pacote de demandas.
2. É bem provável que o desenvolvedor dessa demanda que está em homologação já esteja em outra atividade; isso é fato porque normalmente o cycle time[6] no processo de homologação leva mais do que um dia útil para ser iniciada (sendo bem otimista, rsrs).
3. O fato de estar trabalhando numa demanda em homologação ー e que esse trabalho não seja um ajuste em um determinado critério ー fará com que essa atividade tenha seu valor distorcido (financeiramente e de processo).
4. Ao fazer esse puxadinho, você enquanto gestor, estará impactando diretamente no trabalho feito da sua equipe técnica. Existem diversos passos a serem seguidos para fazer uma demanda chegar em homologação e esse tipo de questão faz com que muitos acordos firmados no meio do caminho sejam simplesmente quebrados.
5. Com essa decisão, o gestor está colocando um bloqueio artificial no seu Working In Progress (WIP). Com certeza, se ele estiver trabalhando com um time técnico maduro em processos ágeis, será um ponto a ser levantado para uma retrospectiva e ele terá que se justificar.
6. Caso esse desenvolvedor, por exemplo, estivesse na demanda XPTO-31, ele teria que bloqueá-la para voltar à XPTO-51. Então, nesse caso, você terá duas demandas bloqueadas no seu work in progress, pois a atividade que está em homologação só será desbloqueada novamente depois que o trabalho “extra” estiver pronto.

 

Os itens apontados acima são de característica de gestão. Além desses pontos, também existem os impactos técnicos dessas decisões:

 

1. É provável que a demanda XPTO-51 esteja na sua branch[7] e, para fazer esse puxadinho, o desenvolvedor terá que largar um outro branch que já estava em desenvolvimento e terá que voltar nessa. E é provável que nesse intervalo outras coisas já tenham evoluído em outras partes do sistema. Isso deixa seu processo de desenvolvimento fragilizado.
2. Se o processo da sua empresa contempla uma coluna de QA no Kanban, é provável que seu desenvolvedor tenha que acionar manualmente alguém de testes, pois como o card está em homologação, já terá passado por essa etapa e não ficará visível no Kanban. Ou seja, mais fragilidade na sua operação.
3. O atraso dessa demanda na questão do desenvolvimento terá um grande risco de tornar mais complexo o deploy dessa atividade em produção, pois travar uma demanda desta forma aumenta o risco do efeito cascata e você acabará travando outras demandas.

 

Percebendo todas essas formas de impacto, podemos chegar a números financeiros para esse tipo de caso.

Custo x Valor

Vamos supor que o valor/hora desse projeto é de R$ 150,00 e a demanda XPTO-51 teve seu cycle time em Doing de 3 dias, ou seja, 24h x 150 = R$ 3.600,00.

Após 3 dias em Ready for Homolog a atividade foi puxada para homologação pelo cliente, nesse dia foi relatado o ponto onde o homologador disse que estava faltando “uma coisinha“. Porém, esta coisinha não estava no critério de aceite, mas mesmo assim, ficou decidido que seria feito.

 

Caso o desenvolvedor já esteja na demanda XPTO-31 e, como o cliente levou três dias para iniciar o homologação, vamos supor que essa pessoa já desenvolveu por 16h (x 150 = R$ 2.400,00), supondo que já havia puxado essa demanda em outro dia.

 

Nessa “brincadeira”, temos cerca de R$ 6.000,00 reais travados (R$ 3.600,00 + R$ 2.400,00), além do Lead time[8] das duas atividades aumentando desnecessariamente.

 

Com isso entramos num problema bastante grave que será o micro gerenciamento da atividade XPTO-51, pois como ela está na coluna de homologação gerará um custo de desenvolvimento invisível. Normalmente essa etapa só existe para a aferição do cliente e fazer pequenos ajustes relacionados especificamente aos critérios de aceite. Então, neste caso, além do custo do desenvolvedor que ー deverá ser monitorado manualmente pelo gestor; o tempo que o gestor irá gastar por estar acompanhado algo tão micro se perderá e afetará provavelmente indiretamente outros projetos que ele deveria estar dando atenção.

 

Vamos supor que o tempo gasto para esse puxadinho foi de 10h, neste momento já temos os R$ 6.000,00, mais os R$ 1.500,00 das dez horas, totalizando R$ 7.500,00 e mais ainda o tempo gasto com o microgerenciamento do gestor. Coisa que, neste caso, não temos como calcular o custo, pois depende muito do contexto de cada organização, mas certamente podemos interpretar que há um impacto bastante significativo a médio e longo prazo.

 

Agora que a demanda foi liberada novamente para homologação, precisamos torcer para que o cliente não ache mais nada pois, a partir do momento que abrimos uma brecha para essa inserção abrupta de um novo critério estamos sinalizando ao cliente a possibilidade de que novos pedidos também serão aceitos, gerando atritos desnecessários no projeto e na relação.

 

Sob a visão otimista de que o cliente disse que agora está tudo certo e que pode ser enviado para produção, seu primeiro pensamento pode ser um “Que maravilha!”,  #soquenao. Temos que lembrar que o projeto não era só o mundinho da XPTO-51 e que no decorrer desses dias outras demandas também já foram para ready for deploy, e que com a entrada dessa demanda agora será necessário efetuar alguns rebases ou merges para conseguir encaixá-la corretamente no pacote que irá a produção.

 

Indo por essa linha vamos definir que o custo de efetuar um deploy padrão dentro desse projeto seja de 2 horas, ou seja, R$ 300,00. Mas dessa vez, por conta do XPTO-51, o tempo foi de 6h (R$ 600,00), logo, 200% a mais de tempo.

 

Analisando cenários

Demandas no ar! Agora vamos aos números.

 

Cenário englobando o puxadinho na homologação

• XPTO-51
  • LT = 9 dias
    • 3 dias de doing
    • 3 dias ready for homolog / primeira homologação
    • 10h de desenvolvimento em (hml) e supondo que o cliente prontamente homologou logo que ficou pronto (otimismo)
    •  6h de deploy
  • Custo total: R$ 7.500,00 (vou desconsiderar o custo do deploy para evitar complexidade desnecessária aqui no cálculo).
• XPTO-31
  • LT = ??? provavelmente mais que 9 dias
    • 2 dias de doing
    • Demanda bloqueada
    • Desenvolvedor teve que efetuar um task switch[9] desnecessário para atender uma atividade que está completamente fora do padrão dos processo de trabalho.
  • Custo total: R$ 2.400,00 até o momento, some a isso a desmotivação por parte da pessoa que desenvolveu por ter que parar uma coisa pela metade para suprir uma necessidade equivocada e que está fora do processo de trabalho.

 

Cenário que foi negado esse puxadinho e foi definido em criar uma nova história

• XPTO-51
  • LT = 6 dias
    • 3 dias de doing
    • 3 dias para ser puxada para homologação
    • 2h para deploy
    • Ficou definido que seria aberta uma nova história para atender uma nova necessidade que surgiu durante a homologação
  • Custo Total: R$ 6.000,00, processo rodando sem impedimentos, equipe técnica não sendo acionada de forma equivocada e nenhum tipo de micro gerenciamento aplicado.

 

O cliente pode ficar triste? Pode. Mas certamente se você tiver condições de simular um cenário como esse em conjunto com seu cliente, mostre o impacto financeiro com números reais que um pedido desse causará na entrega dessa demanda. Pode apostar que mesmo mostrando somente essas questões do custo total e LT fará que ele concorde contigo em criar uma nova demanda. 

 

Legendas:




políticas explícitas[1] - Documento onde é definido os acordos de trabalho dentro de um projeto. Esses acordos pode ser por exemplo, com quem falar caso tenha uma dúvida de regra de negócio, ou então um link onde está definido o processo de deploy e assim por diante.




kick-off[2] - Cerimônia que tem como objetivo apresentar o projeto para a equipe de desenvolvimento, mostrando os resultados que o cliente deseja obter com essa iniciativa e é também o momento para esclarecer dúvidas gerais.




DoD[3] - Definition of Done, é um documento que define o que é necessário para que uma demanda seja considerada pronta para o cliente, isso vai além dos critérios aceite que já fazem parte das premissas do DoD.




Stage[4] - Local que é considerado um espelho do ambiente de produção, normalmente antes de iniciar a homologação de uma atividade o desenvolvedor sincroniza o ambiente Stage com os dados vindo do ambiente de produção e então coloca a nova demanda neste cenário, onde o cliente poderá aferir a demanda num local muito próximo ao real. 




test direction[5] - São etapas que o desenvolvedor descreve para que o cliente consiga testar com maior exatidão a demanda, isso pode ser feito a partir de um tutorial escrito ou vídeo. Essa etapa é bem relevante quando se trata de demandas que possuem CRUD (Create, Read, Update and Delete) em seu contexto.




cycle time[6] - É uma fatia de tempo do seu Lead time[8]. Ou seja, quando falamos do tempo de uma determinada etapa específica, por exemplo do Doing, falamos cycle time.




branch[7] - Uma área reservada dentro do seu repositório de código-fonte, onde normalmente está o código de uma determinada demanda.




Lead time[8] - É o ciclo de tempo de uma demanda dentro de um processo de trabalho, ou seja (ready for dev até Done)


task switch[9] - É o momento onde o desenvolvedor precisa parar o que está fazendo e simplesmente atacar uma outra atividade. Ou seja, troca de atividades de maneira brusca.