Gestão e Liderança

by Agile.Inc Agile.Inc 2 Comentários

A Jornada do Agilista: qual o ciclo de vida desse papel dentro de um time?

Entenda melhor como é o começo, meio e o fim da atuação do especialista em Agilidade dentro de time de desenvolvimento de produtos digitais

Por Fabricio Pequeno e Ricardo Avigro
A Jornada do papel de Agilista e seu ciclo de vida dentro de um time Ágil

Considerada uma das 15 profissões emergentes de 2020 no Brasil – segundo um estudo publicado pelo LinkedIn, o Agilista, ou Agile Coach, ou Scrum Master, ou Agile Master, ou Agile Expert, entre outros nomes dados ao papel do especialista em Agilidade, é um dos trabalhos que mais cresce nos últimos tempos… Mas, você sabe como é a jornada do Agilista, seu desenvolvimento e/ou crescimento desta carreira? Ou qual o ciclo de vida desse papel dentro de um time?

Foi pensando nisso que, nós, Ricardo Avigro e Fabricio Pequeno, resolvemos escrever esse artigo! A ideia da Jornada do Agilista não surgiu para ser uma jornada definitiva, ela foi idealizada a partir do momento no qual foi perceptível um comportamento recorrente em times ágeis.

Não significa também que, seguindo essa jornada, você vai conseguir sucesso absoluto. Esse caminho defende que o Agilista tem um ciclo de vida a cumprir dentro de um time e expõe alguns marcos importantes, no qual devemos ficar atentos antes de cobrar maturidade e auto-organização das pessoas.

Pense que, por alguma vez, conversando com agilistas, você se deparou com dúvidas sobre “como é o nível de sucesso desta função?”. O papel de Agilista sempre deixou muito vago como você pode fazer as coisas e o quanto você pode fazê-las…. Não estamos aqui para limitar sua criatividade, nem o trabalho, muito menos o histórico de cada um, porém é muito importante que a gente tenha um rumo para seguir. E, com isso, nasceu a essa jornada, uma entre tantas outras que pode ser um bom caminho a ser tomado.

… Agora vamos ao que interessa, a Jornada do Agilista

Muita coisa acontecendo, correria, entregas parciais, atividades entrando no meio da sprint, desenvolve nessa sprint e na outra testa, “daily, para que isso?”, “retro só sai problemas direcionado a pessoas e não tem nada de positivo”, mas, no geral o time está bem, faz entregas e é auto-organizável para realizar suas atividades. 

Identificou alguma coincidência com algo citado? Bom, nós já passamos por algumas situações assim, e aí pensamos: “O que fazer? Por onde começo? Como agir?”. Pensando nisso, mapeamos o que chamamos de “Jornada do Agilista”, com base em nossas experiências que deram certo. 

Etapa 1 – ENTENDIMENTO

Cheguei em um time, e agora? Entendemos que é preciso fazer uma leitura do ambiente. Ok! Você já leu isso em todos os lugares, por isso, vamos lá… Como fazer essa leitura ou como chamamos, “Entendimento”, que é dividido em quatro etapas:

Fluxo para explicar a fase de entendimento de times ágeis

1 – Entenda quem é o seu time, quem são as pessoas, converse com cada um e ouça seus desafios, seu momento e suas dificuldades, sem julgamentos! Entenda o perfil técnico também, isso é muito importante. Não precisa entrar no detalhe de código, mas é bom saber minimamente;

2 – Analise o fluxo de trabalho atual. Alguns times acham que tem um fluxo de trabalho quando na verdade é um go horse disfarçado e, na loucura do dia a dia, não conseguem ver o quanto geram de retrabalho para eles mesmo. Examine também as restrições, pois muitas empresas têm processos originados do modelo tradicional e, algumas vezes, precisamos conviver com isso por um certo tempo.

3 – Entenda o backlog do produto e sua priorização. Sim, o Agilista pode ajudar o Product Owner com o backlog, questionar as priorizações e ajudar a gerar mais valor nas entregas, e isso influencia diretamente no próximo ponto.

4 – Saiba o propósito do time. Um time sem propósito vira um time tarefeiro, uma fábrica de software e isso desmotiva as pessoas.

Não existe um tempo ou uma ordem para toda essa análise, colocamos assim pois foram os pontos que achávamos mais importante e que davam base para a ação seguinte.

Etapa 2 – AÇÕES 

Depois que você tiver todo esse entendimento, chega o momento mais desafiador e pode ser contraditório com algumas literaturas, mas, é o momento de “AGIR”!

  • Identifique os problemas, monte uma proposta e apresente para a hierarquia da empresa – é muito importante estar sempre alinhado com seus superiores.
  • Apresente essa proposta para o time e busque aliados para implantação deste plano. Embora muitos falem o contrário e na agilidade pregamos que as mudanças fazem parte, as pessoas tendem a resistir à elas, por isso, quanto mais aliados você tiver, melhor para a implantação da proposta.
  • Deixe essa proposta visível para todos, compartilhe a jornada de desenvolvimento, acordos de trabalho e o que mais achar necessário.

Um dos pontos mais difíceis e cruciais desta etapa é identificar os sabotadores. Nem todos estão preparados para a mudança, seja por qual motivo for – e, sim, sabotadores existem e temos que lidar com eles. Como? Elimine-os!

Nem sempre um sabotador será uma pessoa, às vezes pode ser um processo não muito inteligente que gere desperdício, mas no geral são pessoas, e podem ser pessoas do time, de outras equipes que temos dependência ou até mesmo um gestor desconfiado e centralizador.

Essa é a parte mais complicada, pois não lemos isso (pelo menos nunca li diretamente). Mas, na prática, o sabotador se tornou um impedimento na melhora do fluxo de trabalho, implementação da proposta e/ou dia a dia do time. E falando em impedimento, nós, Agilistas, removemos como ninguém!

Para cada tipo de sabotador, temos um tipo ação a ser tomada:

  • Uma Pessoa do Time: Já li que o time deve ou não permitir uma determinada pessoa ali e, nós como Agilistas, só atuamos quando o time sinaliza. Porém, algumas vezes o time não tem maturidade para isso ou ainda não percebeu que determinada pessoa é um sabotador. Por isso, você Agilista, sim, você mesmo, deve colocar seu casaco de “general” e determinar que o sabotador seja retirado do time. (a forma de fazer isso dependerá da autonomia que terá dentro da organização, porém deve reportar o caso ao gestor direto da pessoa para que a ação seja tomada. Lembrando que deve sempre ter exemplos das situações que o levaram a tomar essa decisão e após feedbacks com esse “sabotador”.)
  • Gestor centralizador: O ideal é entender e minimizar o medo ou insegurança que ele tenha sobre o trabalho, seja falta de visibilidade, achar que o time faz muita reunião e “coda” pouco, achar que a falta de um cronograma prejudica a visão, enfim o ideal é entender e remover esse “sabotador”, pois mesmo de forma inconsciente ou indireta essas atitudes atrapalham o andamento do fluxo e consequentemente as entregas.

O que queremos dizer aqui é que, independente do que ou quem esteja atrapalhando, o andamento do fluxo e proposta estabelecida, deve ser removido.

Outro ponto importante é sempre estimular o time para ações que garantam o fluxo da jornada de desenvolvimento, uma vez estabelecido, ele deve ser cumprido. Considere sempre, os refinamentos e tenha as dependências mapeadas. Elas serão extremamente importantes para o engajamento do time em relação a Qualidade e Entrega – são coisas que não podem ser negociadas e uma não caminha sem a outra.

Nesse ponto que entraremos a seguir – que também é polêmico, pois muitos dizem que a área de Produto não faz parte do papel do Agilista, mas, na prática, como trabalhamos junto com a pessoa que energiza o papel de  Product Owner, é muito importante orientar e ajudar. E como podemos fazer isso?

  • Primeiro, é preciso garantir que o backlog esteja claro, disponível e entendido pelo time, e depois para toda a empresa. 
  • Em seguida, devemos também deixar transparente para todos as entregas do time.

Etapa 3 – DISSEMINAÇÕES 

Tendo a visibilidade do backlog e das entregas do time, começamos a entender e questionar se essas entregas estão alinhadas com o propósito do produto. E, para que isso seja possível, precisamos entender e conhecer nosso cliente, olhar pela ótica de UX e UI, para saber como é sua jornada e sua experiência usando este produto. 

Neste momento, é muito importante que você e a pessoa que atua como PO fiquem próximas de que faz o papel de Designer e do especialista da Área de Produtos. Aliás, essa parceria é essencial em todas as etapas e, levar todo esse entendimento para o time para que participem das decisões estratégicas, traz um senso de “dono do produto”, e você verá que isso fará toda a diferença. 

Por fim, pensando sempre em visibilidade, criamos um painel no qual é possível mostrar todas as entregas do produto, voltadas para as experiências do usuário, independente de times.

Literatura x Realidade

Algumas literaturas trazem modelos do que devemos seguir, eventos com sequências nas quais, independente de serem eficazes ou não, são importantes de se fazer. Não achamos que isto está errado, a questão é que poucas vezes vimos uma orientação realmente voltada ao Agilista nisso tudo…. 

Subentende-se que o Agilista deverá saber como se comportar e que a evolução do time irá acontecer perfeitamente como descrito a partir das situações propostas. O entendimento dos ciclos em muitas vezes é aplicado para produtos e para a maturidade do time, porém não é aplicado para a evolução do Agilista sobre a ótica de progresso do time como um todo. 

Nossa proposta é de conscientizar a todos que existe um ciclo de vida para a atuação do Agilista dentro de um time e que, esse ciclo, a partir de sua completude, não indica que uma deverá ter uma promoção e sim um critério de sucesso, visando o direcionamento de carreira. Assim, podemos buscar um outro time no qual nossa atuação terá resultados mais expressivos – visando a maturidade como um todo em uma empresa.

Essas foram algumas ações que adotamos e nos fizeram alcançar sucesso nos projetos que atuamos. Claro que nem sempre acertamos e aqui contamos apenas o que funcionou…

Deixe nos comentários se já passou por algo parecido e o quanto essa jornada se aplica a sua realidade. Valeu, até a próxima!

 
 
E se você precisa de bons Scrum Masters e Product Owners, nós podemos te ajudar! Clique aqui e agende uma conversa com nossos especialistas que te ajudamos a selecionar os melhores profissionais.
 
 
by Agile.Inc Agile.Inc Nenhum comentário

Você parece Ágil, mas não tem foco no Cliente? Provavelmente está perdendo o jogo!

Entenda como o foco no usuário e em sua jornada deve ser o ponto central do desenvolvimento para um produto digital de sucesso

Por Antonio Costa
Placar do jogo

Muitas empresas que estão no processo de Transformação, seja Digital ou Ágil, estão cometendo um erro muito grave em sua esteira de Desenvolvimento de Produto. Existe um grande foco no Produto e um baixo foco no Cliente. Isso faz com que a organização até tenha entregas mais organizadas e mais rápidas, mas ainda pouco eficazes. 

E sabe por que isso acontece? Às vezes a empresa tem um grande foco em ganhar dinheiro e não percebe que se dar mais atenção para a dor do cliente e atacar essas dores de forma mais organizada, o lucro vem por consequência.

Para isso, é necessário haver uma mudança de pensamento, na qual chamamos por aqui de “Foco em Produtos para Foco em Jornada e Cliente”. Vou explicar melhor no que consiste esse conceito.

Foco em Produto

É quando uma organização olha apenas seu produto, esquecendo seu cliente – o produto vem em primeiro lugar. Pode ser que ela até tenha um time ágil ou práticas ágeis, mas provavelmente o pensamento predominante venha a ser o pensamento tradicional, que faz o time buscar a eficiência operacional. Empresas com foco em eficiência demasiada, ou com grande foco no produto possui algumas características, como:

  • Começar a análise para a criação de produto ou funcionalidade, pelos sistemas internos – o sistema interno vai moldar a solução;
  • Focar em fechar requisitos, ter tudo detalhado;
  • As áreas de Negócio e TI trabalhando ainda separadas, onde não existe grande confiança entre elas;
  • Times de desenvolvimento olhando apenas sua entrega, buscando entregar mais tarefas;
  • Desalinhamento dos canais, pois como o foco é em eficiência, não precisa um canal esperar o outro;
  • Grande foco na produtividade dos times;
  • Mudanças de requisitos não são bem-vindas;
  • Foco em lançar novas funcionalidades, sem medir o que já existe;
  • Entregar o produto é mais importante que a qualidade do que já está feito.

Essa lista pode ser extensa e caberia aqui um novo texto para enumerar mais características e até detalhá-las…. Entretanto, vamos falar do que realmente importa: o modelo correto – Foco na Jornada e no Cliente.

Foco em Jornada e Cliente

Quando um time foca na jornada e no cliente, significa que o usuário final REALMENTE está no centro de todo desenvolvimento de um produto. Entenda um pouco melhor sobre as características desse time:

  • Começa pela necessidade do cliente para definir a solução viável;
  • Têm clara a jornada dos usuários e personas;
  • Áreas de Negócio e TI trabalhando diariamente em conjunto, de forma colaborativa;
  • Times orquestrando as entregas, com foco em valor;
  • Experiências iguais em todos canais (omnichannel);
  • Ciclos curtos para coletas de feedbacks com clientes;
  • Análises baseadas em dados dos clientes;
  • Abertura para mudança de escopo;
  • Foco no cliente e também em suas emoções;
  • Objetivos da empresa com foco em negócios ou cliente, e não metas para entrega de projetos;
  • Grande preocupação com a qualidade do produto (pois se você lançar algo que não funciona direito, nada agregará para o cliente;
  • preocupação em medir as features utilizadas ou não utilizadas e simplificar as funcionalidades – ao invés de lançar mais coisas novas;

Essa lista também não acaba por aqui, mas nela constam os principais pontos que vemos no mercado. A grande mudança, em termos gerais, consiste em se preocupar com a experiência do cliente, na sua jornada ao usar aquele produto digital.

Exercício

Visto os pontos acima, sugiro que você volte nessas listas e faça uma reflexão: “quantos itens acima você consegue identificar em seu time? Eles estão trabalhando com foco no cliente ou mais foco no Produto?

Sugiro também você se colocar no lugar do cliente, mas da seguinte forma, por alguns instantes: 

  1. Lembre-se de algum serviço ou produto que você consumiu recentemente, que proporcionou uma experiência muito desagradável para você… Lembre-se antes de seguir.
  2. O que você sentiu? Raiva, impotência? Pensou ou falou mal desta marca? Qual foi sua atitude?
  3. Agora se pergunte: será que o produto que você está criando, pode estar gerando esses mesmos sentimos em seu usuário? Ele pode estar reclamando da sua marca ou está desapontado com a experiência que teve ao usar esse produto?

Por fim, tenha em mente que o cliente vai consumir seu produto não por que você usa Scrum ou Kanban ou qualquer outro método ágil; não por que você possui tecnologias legadas ou disruptivas; o cliente vai comprar seu produto ou serviço, por que ele gera algum benefício para ele ou resolve uma dor do seu dia a dia.

E se você quiser tirar alguma dúvida ou falar mais sobre esse assunto, deixe seu comentário aqui ou fale conosco!

by Agile.Inc Agile.Inc Nenhum comentário

Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito

Seu time lança diversas funcionalidades, trabalha muito, mas os resultados não aparecem? Entenda agora as principais causas tudo isso

Por Filipe Machado e Thiago Fregni

Em qualquer negócio, seja ele um produto digital ou não, uma das principais preocupações é atender as necessidades dos stakeholders e isso acaba se tornando um dos grandes objetivos a serem cumpridos. Com isso, o time trabalha muito, se empenha em lançar várias funcionalidades, mas vai deixando de lado uma meta muito importante: a maximização de valor e o retorno de investimento daquela iniciativa.

Ou seja, por mais que a Agilidade tenha sido implantada e as entregas estejam acontecendo com mais velocidade, ainda há stakeholders super descontentes. “Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito.” Essa frase do Peter Drucker é uma daquelas que pode resumir de forma simples esse cenário. O time está trabalhando bem, com diversas funcionalidades em produção, mas será que estão fazendo algo realmente útil?

Isso soa comum para você? Pois realmente acontece em muitos negócios que estão iniciando uma transformação digital e por três principais motivos:

  • Maximização de valor e o retorno de investimento

Geralmente, o Product Owner fica muito preocupado em atender os stakeholders e acaba deixando de lado uma das suas principais responsabilidades que é a maximização de retorno do investimento.

  • Senso de propósito

É comum o time (Agilista, PO e Devs) não saber de forma clara qual o objetivo do produto ou não ter visão sob o motivo de estarem trabalhando em determinada demanda. Sabem o que é, como deve ser feito, mas não o por quê – não possuem senso de propósito!

  • Discovery/Ideação/Upstream 

A maximização de valor do produto, ou seja, aquilo que o cliente recebe na ponta, precisa passar por um processo de discovery e refinamento, antes de iniciar o desenvolvimento. E não é sempre que isso acontece!

Mas qual é a causa raiz desse problema?

É possível identificar alguns sinais que ocasionam essas situações descritas acima. Os principais são: 

  • Baixa autonomia do Product Owner, que depende de outras pessoas para tomar decisões e esclarecer detalhes;
  • Product Owner que não tem a competência correta;
  • PO tirador de pedido (PO Proxy/Escriba), que não tem ownership do produto. Anota os pedidos sem entender o porquê da solicitação e quais os resultados esperados;
  • Time se preocupa em encher o capacity. Ou seja, durante reuniões de Planejamento, existe uma preocupação maior em “arrumar” backlog suficiente para deixar todos ocupados, do que gerar realmente valor para o cliente;
  • PO que não sabe quanto custa cada PBI e não tem noção do custo do time, o que o impossibilita de fazer trade-offs baseados no RoI;
  • Times que não possui objetivos claros, impossibilitando-os de fazer escolhas e manter o foco no que mais gera valor;
  • Não possui Discovery (UX). Ou seja, assim que a solicitação chega, vai direto para o time desenvolver. Não existe um processo no qual o cliente é envolvido e hipóteses são tratadas como verdades;
  • Não existe uma visão Customer Centric, focada no consumidor/usuário.

Bom, se você tiver identificado alguns desses pontos acima em seu time de transformação, você está cometendo esse erro. E isso pode ser nítido em um time ágil que ainda está no paradigma tradicional de trabalho.

Resolvendo essas questões 

Quando identificamos esse cenário – que é bem comum, fazemos um trabalho bem intenso de coaching com o Product Owner, com o Scrum Master e com os stakeholders. Para isso, executamos técnicas como:

Criar um time de discovery: a fim de descobrir que funcionalidades devem ser implementadas para atender as necessidades dos usuários;

Técnicas de ordenação de backlog: o backlog deve estar ordenado e tais técnicas nos ajudam a ordená-los de acordo com os objetivos a serem alcançados;

Criar bem claramente um esteira ágil utilizando Flight Levels: esta técnica dá visibilidade de portfólio até chegar na mão do usuário final;

Organizamos os times por Value Stream ligados ao usuários, com objetivos claros, utilizando OKR´s, por exemplo;

Definição de objetivo do produto e deixar o claro qual o valor (aumentar 10% as vendas, aumentar a taxa de conversão em 5%, entre outros) esperado a ser atingido por aquele item, mais valor de itens;

Roadmap: uma visão geral dos próximos passos do produto;

Utilizar dados para tomada de decisão em itens de backlog;

Criação de conceitos de hipóteses: uma ótima forma de trabalho que ajuda a validar as hipóteses é chamada HDD (Hypothesis Driven Development). Este método auxilia na escrita do nosso backlog, orientado à validação de hipóteses.

No geral, tentamos dar o correto propósito para o time como um todo, ligado a valor para o cliente ou negócio… Por que, quando não se sabe onde quer chegar, qualquer caminho serve. E, por isso, o trabalho se torna eficiente, mas não realmente eficaz!

Mais valor entregue, com menor investimento

Solucionando essas falhas durante o processo de desenvolvimento de um produto com um time ágil, é possível ter diversos benefícios, entre eles:

  • Conseguir trabalhar no processo empírico, focando sempre no objetivo desejado;
  • Se torna mais fácil gerenciar a ansiedade dos stakeholders quanto aos resultados;
  • O stakeholder fica mais contente com a entrega, pois ela está ligada ao propósito, com foco em gerar realmente valor com a iniciativa;
  • O clima de confiança do stakeholder com o time melhora;
  • Resumindo, mais valor entregue, com menor investimento e foco na maximização de valor e o retorno de investimento da iniciativa.

Esperamos que você consiga aplicar essas sugestões em seu dia a dia. Qualquer dúvida, estamos à disposição para ajudar… É só entrar em contato conosco!

by Agile.Inc Agile.Inc Nenhum comentário

Seis dúvidas comuns ao implementar uma transformação ágil

Como esclarecemos os principais questionamentos que surgem nesse processo inicial de implementação da agilidade numa empresa

Por Eduardo Alcaraz

Iniciar uma transformação numa empresa, seja ela ágil, digital ou cultural, realmente é uma decisão muito significativa, levando em conta o impacto que causa. Mesmo que positiva e com tantos benefícios, essa jornada de mudanças ainda gera muitos questionamentos na mente de líderes. E, por isso, vamos compartilhar algumas das  dúvidas comuns ao implementar uma transformação ágil que ouvimos nos últimos tempos.

“Escopo aberto é cheque em branco?”

Essa é a primeira das seis dúvidas comuns ao implementar uma transformação ágil, principalmente partindo de gerentes de TI: “escopo aberto é cheque em branco?”. É comum que a Agilidade seja confundida com bagunça e falta de comprometimento com os objetivos da entrega. Por isso, a primeira maneira de mitigar este estigma é justamente entender o propósito do que deve ser feito

Em seguida, apresentamos uma das diferenças entre a entrega features e entrega de valor:

Uma outra característica que é muito importante no SCRUM é a entrega de incremento de valor em cada Sprint. Um projeto que, a cada 14 dias tem uma entrega de software rodando, gera muito mais transparência ao cliente.

Falando nisso, outra característica que deve ser levada em conta na hora que surgem essas dúvidas ao implementar uma transformação ágil é a transparência. Um projeto de escopo apresenta rapidamente os típicos blocks, que impedem que um software vá para a produção. Proceder nesses pontos de maneira honesta e, não personificada, faz com que os stakeholders possam agir e resolver tais blocks para que o projeto todo tenha sucesso.

Finalmente, o desenvolvimento de um projeto pode sofrer várias adaptações. Seja pela mudança de target do projeto, de algum block ou de uma mudança no mercado. O escopo aberto não se esconde atrás de um contrato pré-definido, mas engaja cliente e fornecedor em torno de um objetivo: entrega em produção.

“Mas o que vou receber?”

Falamos um pouco das diferenças entre escopo e valor. Invariavelmente, este valor significa software em produção – e rápido. Sendo assim, surge essa segunda questão, bem frequente entre as dúvidas comuns ao implementar uma transformação ágil.

A Agilidade oferece essa entrega de valor de uma maneira muito simples. Os times engajados no propósito são capazes de fazer pequenas entregas em produção, sempre. E essas pequenas entregas servem para manter o cliente e os times engajados, e dá a possibilidade de priorizar próximos passos com o “software na mão”. 

Então, as pequenas entregas em produção dão ao cliente o conforto de saber o que está sendo feito, a qualquer tempo.

“Como eu acompanho a evolução do desenvolvimento?”

Essa é uma das perguntas que mais ouvimos! Por isso, é importante ressaltar que o cliente faz parte do time, seja como Product Owner, seja como stakeholder. Logo, o acompanhamento é automático e fluido.

Sendo assim, o cliente é parte integrante do status report. Ele, como o restante do time, tem a responsabilidade de mitigar, adaptar e dar publicidade diariamente.

Vale aqui a menção do antigo PMO (Project Management Office) para projetos de escopo fechado. O PMO tradicional cobra e entrega um status report. E esse status não costuma apresentar exatamente o que está acontecendo no projeto.

“Meu chefe não me deixa fazer isso.”

Essa é outra fala que  faz parte das dúvidas comuns ao implementar uma transformação ágil. Entretanto, acreditamos que esta posição de “chefe” está lá por um ótimo motivo. Ou ele ficou muitos anos em sua empresa, galgando posições e conquistou seu espaço. Ou ele é muito competente no que faz e foi trazido para liderar e resolver problemas na sua organização.

Nesta situação, o ideal é entender as motivações dele para se manter no modelo tradicional. Geralmente há dois grandes motivos:

– Para multinacionais, pode ser uma diretriz da matriz (apesar de pouquíssimo frequente);

– A empresa está acostumada a “ter alguém para colocar a culpa”, caso o projeto dê errado.

No primeiro caso, a saída mais óbvia é começar a criar a cultura de agilidade dentro da organização. E o departamento de Recursos Humanos pode te auxiliar nisso!

Na segundo cenário, temos uma porção de argumentos reais que fazem a Agilidade ser uma boa saída para a transição do modelo tradicional para entregas com mais sentido e mais valor agregado. 

“E quais são as minhas garantias?”

A principal garantia do cliente é justamente a entrega contínua de valor. Sabemos que a Agilidade expõe os fatos rapidamente e o cliente é constantemente informado – levando em conta que o cliente faz parte do projeto, como PO.

E aí surge o questionamento: “mas se o software não ficar pronto na data?”

Deparamos a todo momento com datas fatais: dias das mães, dia dos pais, Natal, lançamento de marca, rodada de investimentos, entre outras. A principal ferramenta para mitigar a entrega é a priorização. Avaliar o que é mais importante, trabalhar em pequenos ciclos de entrega, se adaptando a todo momento, focado em entregar o melhor produto na data… Essa é a melhor técnica de sucesso para cumprirmos a tal data!

“Ainda somos muito tradicionais e Agilidade não é para nós.”

Além de todas essas questões, por fim, ainda ouvimos muito essa afirmação durante a negociação de uma transformação tão grande como essa. 

Mas, mais uma vez, é preciso entender que o mundo mudou. Não só por conta de um vírus desconhecimento que ocasiona a COVID-19, mas pela ânsia dos profissionais em serem mais felizes em seus trabalhos, em todas as escalas.

  • As organizações cartesianas (aquelas “meu chefe manda e eu executo”), está cada vez mais em decadência.
  • As entregas contínuas fazem cada vez mais sentido nesse mundo VUCA, no qual já falamos muito neste artigo aqui.
  • Então, a nossa resposta é: “SIM, a Agilidade é para todo o mundo!”

Tem mais alguma dúvida sobre esse assunto? Entre em contato conosco que vamos te ajudar.

Conheça alguns dos nossos cases de sucesso.

by Nelson Legal Nelson Legal Nenhum comentário

Experiência de Usuário: Entenda o que falta para o sucesso do seu negócio digital

Saiba quais são os benefícios de UX e como essa prática faz o cliente se tornar um fã do seu produto

Por Nelson Legal 
Mulher feliz olhando o celular

Eis que virando a esquina ele vem chegando, o mais desejado, o mais disputado, o mais querido e valioso, o cliente! Também conhecido como consumidor, usuário, público alvo e por aí vai… Todas as empresas precisam dele para existir, e manter o consumidor fiel à sua marca vem sendo uma tarefa cada vez mais difícil. 

Ficou para trás o tempo em que, para ter o coração do consumidor, bastava vender um produto bom e barato. É preciso muito mais… Hoje, grandes marcas competem para ter a chance de proporcionar a melhor experiência para o consumidor

Recebendo tanta atenção, o cliente ficou extremamente criterioso e atento a qualquer deslize e, caso isso aconteça, ele não pensa duas vezes pra mudar de marca.

A cada problema que aparece no caminho do consumidor, existem inúmeras empresas que o resolvem com uma mão nas costas. Mas uma empresa que, além de resolver o problema, ainda seja capaz de colocar um sorriso no rosto e trazer um calor no coração desse cliente, isso é bem mais difícil de se conseguir.

E é difícil porque a empresa precisa criar um vínculo especial com seu consumidor, tem que ir a fundo e ser capaz de predizer o que ele gostará ou não, e quanto esforço estará disposto a empenhar. E o mais importante, garantir que tudo o que foi feito ficará claro e será entendido intuitivamente. Complexo, né?

Pois é aí que entra a UX, User Experience ou Experiência de Usuário, traduzido do inglês. Criada por Don Norman na década de 90 enquanto trabalhava na Apple, a definição surgiu pois ele queria melhorar a experiência do usuário com seus computadores. Não só no momento em que interagiam com o computador ligado, mas no antes e depois disso. 

Um bom exemplo disso é como um restaurante que tem o melhor hambúrguer da cidade. De nada adianta um hambúrguer perfeito se não pensarem no conforto, no atendimento e no menu, entre outros detalhes tão importantes quanto. Cada um desses itens pode fazer um cliente decidir se gasta mais ou menos, se volta ou não, se indica ou fala mal do restaurante. Tudo tem que ser muito bem planejado para agradar e realmente atendê-lo!

Mas como a prática de UX vai impactar meu negócio?

Esse planejamento, focado na experiência do usuário, também pode economizar esforço e dinheiro, e aumentar os lucros de sua empresa. Segundo o livro de Robert Pressman, “Engenharia de Software: Uma Abordagem Profissional”, a cada R$ 1,00 gasto em UX para resolver um problema durante o planejamento do produto, R$10,00 seriam gastos para resolver o mesmo problema no desenvolvimento e R$ 100,00 ou mais para que o problema fosse resolvido depois que o produto fosse lançado. Ou seja, além de evitar problemas, esse planejamento também pode direcionar e facilitar o caminho entre o cliente e seu produto.

Um recente estudo realizado pela Forrester Research revelou que uma interface de usuário bem projetada pode aumentar a taxa de conversão de um site em até 200%, e uma boa experiência de usuário pode subir as taxas de conversão em 400%. 

Não é à toa que grandes empresas multinacionais são defensoras de investimentos em UX. A Amazon, por exemplo, aplica testes A/B continuamente em todos os aspectos das interfaces que atendem seus clientes, atualizando-as e redesenhando-as  constantemente com base em dados. Desde 2015, a Amazon vem sendo a maior loja de e-commerce do mundo e a mais valiosa nos Estados Unidos. 

Já aqui no Brasil temos o caso do Nubank, a principal fintech da América Latina que nasceu em 2013 e hoje já conta com mais de 5 milhões de clientes fiéis. Desde o nascimento, a fintech tem o usuário como centro de todas as suas decisões. Segundo Guilherme Neumann, ex-UX Lead do Nubank, “a solução de design ou de interface que surge é consequência não só do trabalho que o designer faz, mas da preocupação que todo mundo no Nubank tem com a experiência de quem usa o produto.”

Vemos como a UX se mostrou importante para essas empresas, e pode ainda ajudar outras a alcançar inúmeros benefícios, como:

  • Aumentar o lucro e conversão: usuários se tornam leais a produtos fáceis de usar;
  • Aumentar índices de satisfação do consumidor: usuários amam produtos bem desenhados que dão o que ele precisa e o que ele nem sabe que precisa;
  • Diminuir contatos com suporte: testes com usuários resultam em usabilidade mais fluída e intuitiva para o maior número de pessoas;
  • Evitar o retrabalho no desenvolvimento do produto: UX foca no entendimento da jornada de usuários e na aplicação de testes, o que diminui a ocorrência de erros de planejamento;
  • Reduzir o risco de produzir o produto errado: as pesquisas com usuários vão buscar produtos que agreguem real valor a eles no dia-dia.

Para começar a investir em UX, o primeiro passo pode ser agregar um Product Designer ao seu time, alguém que seja capaz de trazer a cultura de User Experience para dentro da empresa e engajar os times como um todo.

O passo seguinte é formar times com especialistas em áreas específicas da UX, como pesquisa, escrita, interface (UI), prototipagem e testes. O ideal é que todos se complementem, ao mesmo tempo que, individualmente, tenham capacidade de atuar em todas as áreas da UX.

Quer saber mais sobre esse assunto? Entre em contato com a gente para conversarmos sobre como incluir UX na prática. Várias empresas já tiveram resultados positivos depois de incluir UX no dia a dia e a sua pode ser a próxima!

Sem Parar: Entenda como uma das maiores empresas de pedágio do mundo aumentou sua base de usuários no app em 315%

by Agile.Inc Agile.Inc Nenhum comentário

As 5 disfunções de um time e como evitá-las para ter pessoas mais engajadas

Por Filipe Machado

Durante o dia a dia de trabalho, um time pode apresentar algumas disfunções, seja por brigas internas, desconfiança, falta de comprometimento ou mesmo por disputa de posição. Esses problemas são comuns, mas podem se tornar impedimentos para que a equipe atue de forma engajada e com alto desempenho.

Mas, se você está lendo esse texto, deve estar pensando: como exigir que um time composto por pessoas com diferentes experiências, personalidades e motivações reme junto para o mesmo objetivo?

Foi sob essa ótica que Patrick Lencioni escreveu o livro “As 5 Disfunções de um Time“, que traz um modelo piramidal com essas cinco disfunções: Falta de Confiança, Medo do Conflito, Falta de Comprometimento, Ausência de Responsabilidade e Falta de Resultado.

Confiança

Falta de confiança é a base da pirâmide das 5 disfunções de um time. Sem confiança entre os membros não há como sustentar as outras 4 disfunções. Quando um time está em formação, os indivíduos se protegem dentro de uma casca para não se tornarem vulneráveis. Eles são incapazes de demonstrar suas fraquezas e se abrir uns com os outros. Relutam em pedir ajuda ou a se prontificar a ajudar uns aos outros. A ausência de confiança traz uma enorme perda de energia e tempo para os membros do time.

Contudo, para se ter confiança é necessário quebrar essa casca e mostrar suas deficiências, fraquezas, necessidades… Nem todos os dias são perfeitos e os membros do time precisam confiar uns nos outros para expor e entender tais situações. Uma boa dose de empatia ajuda muito a construir uma base sólida de confiança. Além disso, o time precisa ter as habilidades necessárias e confiar que são capazes de resolver determinado problema de negócio.

Conflitos

Times sem confiança são incapazes de encarar conflitos da forma que precisam ser encarados, causando certa harmonia artificial. O medo do conflito cria intrigas e discussões veladas que não são saudáveis quando o time deveria estar comprometido e focado na direção de um único propósito. Afinal de contas, quando falamos de time, todos ganham e todos perdem. Por essa razão, os conflitos devem ser encarados de frente, com transparência e respeito.

Comprometimento

Quando os conflitos são encarados de frente, o time passa a exigir mais comprometimento interno de modo que todos consigam falar e serem ouvidos. É necessário que os membros do time tenham abertura para expor suas ideias e que todos tenham respeito uns pelos outros. Contudo, nem tudo que é falado será acatado.

É necessário encontrar um ponto em que uma decisão seja tomada de modo que todos estejam de acordo, que o propósito esteja claro para todos. Dessa forma, todos estarão engajados e comprometidos no mesmo objetivo.

Ausência de Responsabilidade

Times que não são comprometidos não têm responsabilidade. Uma vez que o time esteja comprometido é necessário que seja consciente e não se esconda de suas responsabilidades. Responsabilidade é mais sobre ação do que reação, ou seja, num time responsável, que caminha na mesma direção, não deve haver delegações.

Preferencialmente, os membros devem ser auto-organizados e pró-ativos na criação de soluções. Um time responsável não encontra culpados, pelo contrário, busca junto soluções pois sabem que estão envolvidos dentro do mesmo objetivo e que o sucesso ou fracasso depende de todos.

Falta de Resultado

Quando os indivíduos não são responsabilizados, os membros da equipe naturalmente tendem a buscar seus próprios interesses e não os interesses da equipe. Porém, quando há responsabilidade e comprometimento, os conflitos são encarados abertamente e a confiança está plena, os membros do time naturalmente focam seus esforços em prol dos resultados, pensando no bem coletivo em detrimento às realizações pessoais.

Removendo essas falhas

Para que um time atinja alta performance e entregue cada vez mais, resultados melhores, de forma eficaz e eficiente, naturalmente você precisará tratar essas 5 disfunções.

Os benefícios desse processo para o time são: 

  • Reconhecer suas fraquezas e limitações e sentir-se mais confortáveis em pedir ajuda; 
  • Compartilhar skills;
  • Focar na solução de problemas, pensando no coletivo;
  • Tomar decisões de forma mais rápida;
  • Enfrentar problemas críticos de frente;
  • Estar sempre alinhados e focados no mesmo objetivo; 
  • Aumentar o engajamento das pessoas.

Por fim, entenda que todas as disfunções estão conectadas. A chave é começar construindo uma base sólida de confiança e, em seguida, incentivar conflitos saudáveis, manter a responsabilidade e definir objetivos claros, garantindo que o time comunique-se sempre com clareza.

Precisa de ajuda sobre esse assunto? Nós temos algumas ferramentas essenciais para resolver situações como essas! Clique aqui e conheça.

https://old.agile.whit.digital/voce-parece-agil-mas-nao-tem-foco-no-cliente-provavelmente-esta-perdendo-o-jogo/


Top