- [email protected]
- + (55) 11 945 071 133
Muitos dias parecem com o dia da marmota…
muitas funcionalidades e produtos não são aceitas pelo negocial do projeto…
só porque novas ideias vão surgindo a cada interação, e classificadas como bugs indevidamente.
Isso acaba gerando desperdícios no projeto e baixando a moral do time de desenvolvimento.
Novembro de 1993. Estreia nos cinemas um filme de Bill Murray e Andie MacDowell que poucas pessoas conseguem se recordar: Feitiço no Tempo.
Para mim este é um filme marcante, pois retrata bem a ansiedade e um mix de ódio e raiva decorrentes da sensação de estar preso no tempo.
Esse filme conta a história de um repórter chamado Phil, que é escalado a cobrir o “Dia da Marmota”. Isso mesmo!
O dia da Marmota é um evento/barra festa que acontece em uma cidade pequena do interior.
Onde uma marmota “faz uma previsão” se o inverno vai acabar mais cedo ou mais tarde.
É, até podemos dizer que a marmota é quase um gestor de projetos…
que todo dia tenta adivinhar se o projeto vai acabar antes ou depois do prazo, rs. Piadas à parte…
claro que Phil vai ao evento muito insatisfeito.
E faz o mínimo possível para fazer a cobertura do evento mais rápido possível. Para voltar ao seu tradicional trabalho o mais rápido possível.
Acontece que Phil e sua equipe ficam presos na cidade por causa de uma tempestade não prevista.
E quando amanhece, Phil fica louco para escapar da cidade. Porém, aos poucos ele percebe que voltou ao dia anterior. Ou seja, ao “dia da Marmota”.
E novamente tem que fazer a cobertura do evento.
E novamente ele e sua equipe ficam presos na cidade por causa da tempestade.
E novamente Phil acorda e percebe que ficou preso no “dia da Marmota”.
Dia após dia, todo o dia, é o “dia da Marmota” novamente.
Não vou dar spoilers 😊
E vale a dica do filme. Para um bom observador, podemos ver vários aspectos da nossa vida cotidiana e profissional.
Que poderão te ajudar no dia a dia de seus colaboradores também 😉
Mas acho que aqui, muitos de vocês já devem ter reparado algo semelhante com a realidade, não?
Quantas vezes, em um projeto, entramos em um ciclo sem fim de novas demandas.
Durante o desenvolvimento de produtos ou serviços altamente customizados, ou de inovação, é comum encontrarmos novas necessidades ou situações que nossos clientes não haviam identificado antes.
E então passamos a ouvir todo dia frases como:
“Isso agora podia ser assim ou assado…”
“Poderia fazer também….”
“Já que estamos mexendo nisso, também poderíamos…”
“E se ao invés de ….”
E então, o seu cliente, ou sua área de negócios, ou seus gestores podem chegar à conclusão de que a entrega, seja ela um produto, ou serviço, ou funcionalidade, não está funcionando como se imaginava. Ou como queriam/demandaram.
E assim, consideram como um defeito, ou melhor, um incidente. Na área de TI isso pode até ser chamado de BUG.
Quando falamos de gestão ágil de desenvolvimento de produtos e serviços, muito ainda tem dificuldades em entender que é possível começar pelo básico, mas funcional.
Ir incrementando o produto ou serviço, de modo possamos gerar valor de negócio de forma antecipada. Modelo este base para o que chamamos de MVP (Minimum Viable Product).
O termo MVP foi proposto por Frank Robinson, em 2001, para descrever a versão de um produto ou serviço…
que possui as características ou funcionalidades mínimas para ser utilizado o quanto antes.
E assim obter feedbacks antecipados, e aprimorar as próximas versões, durante o desenvolvimento do projeto.
Mas décadas de um mercado condicionando o mindset dos profissionais em um modelo de desenvolvimento tradicional, dificultam a compreensão do MVP até mesmo por gestores mais experientes.
Desta forma, ainda encontramos muitos destes profissionais acreditando que a entrega de produto ou serviço só pode ocorrer se estiver completa.
Mas o grande problema reside no fato de que ao iniciar o projeto, muitos não tem todos os critérios bem definidos. E muita coisa é descoberta durante o próprio desenvolvimento do projeto.
Logo não é incomum encontrarmos nestes projetos critérios de aceitação muito genéricos. Ou com a definição de escopo muito amplo.
Isso para não dizer extremamente abstratos.
Então, quando ocorre a primeira ou primeiras entregas, é comum que o gestor, ou o Product Owner, rejeite as entregas, alegando que elas não estão funcionais. E assim, as classificam como Incidentes (ou BUGs para o pessoal de TI).
Como lidar com isso?
Neste vídeo vamos te apresentar possíveis abordagens para lidar com isso, e demostrar o valor de negócio gerado em suas entregas ágeis.
Primeiro temos que nós mesmos termos clareza do que diferente incidente de melhorias do produto ou serviço.
Lembre que, para classificarmos algo como um incidente, ou BUG, deve acontecer algum erro ou evento que impede o atingimento do propósito daquela funcionalidade ou daquele produto.
Já uma melhoria, pode ser classificada com um complemento. Que agregam e adicionam mais ao valor que já havia sido gerado por entregas de funcionalidades ou serviços.
Dento isso bem claro em nossas mentes, assim sim podemos acionar nossos gestores e Product Owners para explicar a diferença entre incidentes e melhorias.
Sempre observando o propósito daquela funcionalidade ou daquele produto. Sempre, digo sempre, de forma amigável. Sem caçada às Bruxas.
Lembre-se que em muitos destes projetos, que estão inseridos em ambientes mais caóticos de desenvolvimento, é natural que muitos não saibam tudo o querem desde o início.
Até as primeiras versões começarem a serem utilizadas. E assim, novas necessidades ou funcionalidades podem surgir durante o desenvolvimento daqueles projetos. Podemos até dizer que isso é normal, dada a natureza de projetos assim.
Só não podemos mais é normalizar melhorias como BUGs. Além de gerar discussões e atrasar a antecipação de valor de negócio, pode também afetar o clima e a moral dos colaboradores.
Agora, de nada disso adianta, se não pudermos mostrar o valor de negócio gerado de forma antecipada.
A verdade é que muita gente possui dificuldades em apurar o valor de negócios de suas funcionalidades, produtos ou serviços.
E também não resolve muita coisa entregar algo bem-feito, mas que ninguém vai usar depois, não é verdade?
Porém, mesmo sabendo disso, ainda nos deparamos com entregas de projetos que não geram novas oportunidades de negócios.
Ou ainda que não criam maneiras de trabalho, ou otimizem o fluxo de desenvolvimento de produtos e serviços.
Que acabam não agregando nada de valor para o cliente final.
Por tudo isso, que o assunto de antecipação de valor negocial acaba sendo um assunto tão delicado.
Muitas vezes as entregas ágeis são recusadas porque o time negocial tem dificuldade em compreender o papel do MVP na geração de valor antecipado.
Porém, a empresa já poderia estar gerando frutos da nova funcionalidade/serviço se puder colocá-la em funcionamento.
Mesmo não estando perfeita aos olhos do cliente/usuário. Chamamos isso de adiantar o valor de negócio.
A grande questão é se a entrega atende ao propósito definido no projeto!
Muitas vezes isso acontece porque o time de desenvolvimento do projeto ágil não tem as ferramentas ou o conhecimento prático para demonstrar o valor gerado de suas entregas.
Muitas vezes porque tanto o time de desenvolvimento, quanto o negocial, esquecem do propósito do projeto. ☹
Então ficam discutindo vários processos ágeis, criam procedimentos.
E depois de um tempo percebem que só geraram gargalos e mais descontentamentos ☹
Por isso quero falar de um método que venho utilizando nos últimos 12 anos para demonstrar o valor de negócio de cada entrega ágil.
Agora seu posicionamento poderá ser muito mais forte quando for defender as entregas de seus projetos ágeis.
E de quebra reduzir os desperdícios de tempo e sair do ciclo do prejuízo de projetos.
Dê o próximo passo para sair dos eternos debates de que um ticket seria de Melhoria ou de Bug!
Clique no link abaixo, leia os detalhes deste método que vai te garantir uma posição mais estratégica no desenvolvimento de projetos ágeis.
Neste Workshop prático, te mostramos maneiras de qualificar e demonstrar o valor de negócios de suas entregas.
De forma antecipada, seja a cada Sprint, ou a cada Release de desenvolvimento de seus produtos e serviços.
Mostrar o valor de negócio a cada entrega pode ser difícil em projetos de natureza mutável, ou de inovação. Isso porque podem faltam métodos para apurar o valor negocial.
E somado a isso, temos que muitos profissionais possuem dificuldades em transitar, ao mesmo tempo, entre o mundo corporativo, mundo negocial e o mundo estratégico.
Convenhamos, não são muitos profissionais que tramitam por estes mundos com facilidade.
Cada um deles possuem suas próprias características, dificuldades, linguagens e abordagens.
Por isso que no Workshop True Business Value apresentamos métodos e modelos para você identificar os tipos de valor de negócios possíveis.
Além de técnicas para mensurar o valor de negócio gerado nas entregas em seus projetos, funcionalidades, produtos ou serviços.
De maneira a proporcionar melhores resultados, com maior flexibilidade no desenvolvimento de seus projetos.
Fazendo mais parte dos resultados gerados, e não dos problemas apresentados no seu projeto.
Ou seja, nele te ajudamos a sair do “dia da Marmota” (lembra do filme). E alavancar sua carreira na Agilidade.
Para mais informações, clique neste link.
