Índice do artigo

Por que é mais eficiente inovar em processos associando a abordagem do design ao mindset ágil?

Você provavelmente já deve ter sofrido na pele com processos pouco amigáveis, complicados e que geram perda de tempo e, muitas vezes sem perceber, já deve também ter participado da construção de processos que as pessoas não gostam de seguir.

Em uma pesquisa realizada pela Harvard Business Review, os entrevistados – colaboradores de várias organizações – afirmam dedicar 42% do tempo para resolver problemas e processos internos.

Ainda segundo a pesquisa, as empresas perdem, em média, 20% da sua capacidade produtiva, justamente por conta de processos que consomem tempo valioso e impedem que as pessoas façam atividades que agreguem valor.

Diante desse contexto, a inovação em processos não é só uma grande oportunidade, mas também uma necessidade de negócios.

Nesse artigo, compilamos os principais problemas no redesenho de processos e mostramos como as competências do design e do desenvolvimento ágil trazem um caminho inteligente e contemporâneo para a criação de processos que saem do papel e que as pessoas de fato queiram seguir.

Os problemas clássicos do redesenho de processos

Sabemos que muitos investimentos (de tempo, recursos e dinheiro) das empresas são destinados à otimização e redesenho de processos.

Seja através de times internos, seja utilizando consultorias, muitos desses projetos ficam lindos no papel, mas muitas vezes morrem no relatório final e não funcionam quando colocados em prática.

Muitos dos projetos de redesenho de processos com os quais trabalhamos aqui na weme já partiram de alguma tentativa inicial que não tinha dado certo. Em comum, identificamos as seguintes causas:

Querer resolver tudo de uma vez só: Muitos projetos de redesenho de processos buscam resolver muitos problemas de uma vez só. O problema disso é que a solução fica mais complexa que o problema: o tempo para mapear todos os problemas e para construir uma solução integrada é enorme, assim como a tentativa de colocar tudo para rodar simultaneamente. Projetos assim acabam demorando meses ou até anos para saírem do papel e acabam demorando ainda mais na manutenção e correções na implementação. Para problemas complexos, gostamos de adotar o mindset: “comece pequeno e com ganhos rápidos” – assim a chance das pessoas perceberem valor é maior.
Muito planejamento para o processo perfeito: Muitos desses projetos têm o foco de lançar o processo perfeito. Com isso, acabam dedicando muito tempo no planejamento interno, na coleta de benchmarks, no blueprint impecável e no plano de lançamento – mas pouco tempo em testes ao longo do caminho. Com isso, as grandes falhas de processo são identificadas apenas após o lançamento – e, com isso, são mais caras para reparar.
Olhar o problema com um único ponto de vista: Processos que são criados ou redesenhados apenas com um ponto de vista (e geralmente não é de quem usa) acabam não enxergando diferentes ângulos de problemas na sua aplicação. Um exemplo clássico disso é quando um processo que será utilizado por várias áreas é criado apenas por pessoas de uma área.
Processos que não mudam com o contexto: O mundo está mudando cada vez mais rápido e, com isso, o contexto muda também. Novas necessidades e novas dores surgem e a necessidade de adaptação é frequente. Processos “escritos em pedra” e que não mudam com o contexto correm o risco de ficarem defasados, de caírem em desuso ou, pior ainda, de virarem um gargalo na operação. A pandemia de Covid é um exemplo disso: a mudança rápida de contexto fez com que vários processos deixassem de funcionar.
Não olhar sob a perspectiva de quem os usa: Esse é o principal problema que vemos em comum em processos que não funcionam. Na maioria dos casos, os processos não são criados pela ótica de quem realmente os utiliza, o que acaba os tornando ineficientes. Os processos mais eficientes são aqueles que agregam valor e que as pessoas de fato querem usar – e não apenas usam por obrigação.

Esses problemas têm se tornado cada vez mais frequentes e evidentes com as mudanças rápidas de contexto (como tem sido com a pandemia de Covid-19, por exemplo).

Com isso, muitas empresas também perceberam que precisam de novos caminhos para resolver novos (e velhos) desafios em um novo contexto e uma abordagem mista entre design e desenvolvimento ágil é um dos novos caminhos que temos aplicado aqui na weme.

(Re) inventando processos com design

Assim como define Tim Brown, “o Design Thinking é uma abordagem centrada no ser humano para a inovação, que se baseia no kit de ferramentas do designer para integrar as necessidades das pessoas, as possibilidades da tecnologia e os requisitos para o sucesso dos negócios”.

Trocando em miúdos, o design thinking é um modelo mental que busca resolver problemas complexos colocando o usuário no centro da solução. O design parte sempre do entendimento profundo sobre o problema e as dores dos usuários para então projetar soluções mais criativas e assertivas a partir desse entendimento.

Essa abordagem se baseia em 3 diretrizes:

Centrado no Ser Humano: Para uma solução ser inovadora, ela precisa ser nova e relevante para alguém. Desse modo, o design sempre parte e termina no entendimento profundo e imparcial dos usuários cujos problemas queremos resolver. Entender a fundo o usuário significa encontrar a pergunta certa que queremos resolver de fora pra dentro e não simplesmente criar ideias de dentro pra fora.
Colaborativo: Do entendimento do problema às hipóteses de solução, o processo é muito mais rico quando temos diferentes perspectivas para analisar e também para cocriar. Diferentes perfis, quando trabalham juntos, contribuem com diferentes pontos de vista e se comprometem com a jornada de construção.
Iterativo: Ciclos rápidos de ideação, prototipagem e teste fazem com que a solução seja construída rápido e aprimorada aos poucos, com feedbacks constantes e melhoria contínua ao longo do seu desenvolvimento, resultando em projetos mais rápidos, assertivos e com risco reduzido.

O uso das competências do design para criar ou redesenhar processos é um ótimo caminho para sanar boa parte dos problemas relatados no primeiro tópico. Por trás de todo processo está a jornada de uma pessoa que está em busca de uma solução para um problema. Entender esse significado ajuda a entender o propósito de um processo: ajudar alguém a encontrar a solução da melhor forma possível. Entre as vantagens, estão:

Construir processos que as pessoas querem usar: ao invés de nos basearmos apenas em inferências internas ou benchmarks, o design thinking é uma abordagem que traz o usuário para o centro da construção ou redesenho de processos. Partir desse entendimento ajuda pensar em soluções a partir do mapeamento dos principais gargalos, necessidades e motivadores de quem usa – e precisa querer usar – o processo.
Redução de riscos de projeto: Ao partir do problema e do usuário e antecipar o seu contato com a ideia de solução em ciclos rápidos de teste e aprendizado, o design consegue antecipar problemas e reduzir os riscos do projeto.
Construção colaborativa reduz atritos na adesão: Criar novos processos de forma colaborativa com pessoas de diferentes áreas já ganha aliados logo no início, pois outros times fazem parte da sua construção ao invés de acatar algo que foi feito sem a sua participação.
Recorte do problema traz resultados mais rápidos: Um processo que resolve bem poucos problemas é melhor do que um que quer resolver tudo, mas não resolve nada direito. Nessa linha, o design funciona tão bem quanto melhor for o recorte do problema: ao focar em um bom recorte em um processo, colocamos foco em resolver o que é mais latente.

Redução do risco em projetos que utilizam a abordagem do Design.

‍Dessa forma, a abordagem de Design antecipa e sana vários modos de falha no redesenho de processos logo no início da jornada.

No entanto, ainda que o design seja ótimo para compreensão do problema, levantamento de hipóteses e validação de processos, muitas vezes essa lógica não segue para a implementação do processo na vida real. É aqui que o mindset ágil entra para dar continuidade aos ganhos do Design.

Implementando processos de forma ágil

Em 2001, com o objetivo de dar voz e escala a uma nova forma de desenvolvimento de soluções digitais, um grupo de desenvolvedores de software de grandes empresas escreveu o manifesto ágil.

Ele trouxe na sua essência um mindset mais contemporâneo para desenvolver novas soluções no novo contexto de mundo. Esse novo jeito se baseia em 4 valores:

Indivíduos e interações mais que processos e ferramentas
Software (ou solução) em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Mesmo havendo valor nos itens à direita, o mindset ágil dá mais valor aos itens à esquerda. Veja que nenhum deles prioriza especificamente a rapidez, pois a velocidade de resposta é uma consequência do mindset ágil.

Esse novo modelo mental viabiliza uma organização mais adaptável e, com isso, aumenta a assertividade e reduz o risco da operação.

Por mais que tenha sido originado no desenvolvimento de software, os valores do manifesto ágil também se aplicam ao desenvolvimento de outros tipos de soluções, como processos.

Igual a um software que está em constante aprimoramento, um processo pode ser lançado com o que é mais latente e ir se aprimorando aos poucos.

Trazer as competências do mindset ágil para o desenvolvimento de processos ajuda na antecipação de entregas e na adaptação às mudanças de contexto.

Os 4 valores do manifesto ágil explicados acima falam muito da essência de um modelo mental.

Esse modelo, por sua vez, pode ser colocado em prática em vários contextos e de várias formas.

Existem centenas de métodos ágeis para as mais diversas aplicações e você pode estudar e testar vários deles em uma mesma operação.

O método específico de execução pouco importa: importa mais é a aplicação prática do modelo mental (que é base para todos os métodos existentes e muitos que ainda virão).

Nesse sentido, como muitos sabem, o design é uma abordagem alinhada com o manifesto ágil. No entanto, como já dito, é mais utilizada no momento de compreensão do problema e validação da solução, preparando o terreno para a implementação.

Seguir a lógica do mindset ágil na implementação de processos, por sua vez, significa colocar um processo para rodar da mesma forma que um software:

Formação de um time com diferentes competências: Para garantir o sucesso das entregas em diferentes aspectos da implementação de processos, assim como no design, é importante que o time de projeto tenha todas as competências necessárias para tirá-lo do chão (ou de acionar quem for necessário). Logo no início, são definidos e alinhados os papéis e responsabilidades de todos os membros.
Rotinas e rituais ágeis para dar ritmo e consistência: Engana-se quem pensa que rotinas e métodos ágeis são só para desenvolvimento de software. Dividir projetos em pequenas entregas constantes distribuídas em ciclos contínuos (sprints) com rotinas disciplinadas não exaustivas trazem ritmo, alinhamento e consistência na operação. Cada sprint (que varia entre 1 e 2 semanas) começa com um alinhamento de objetivos e entregas por responsável, o caráter padronizado dos rituais oferece previsibilidade e diminui a ansiedade dos membros (que já sabem o que esperar de cada rotina), os touchpoints diários trazem um canal frequente para tirar dúvidas e remover barreiras e, ao final, cada revisão de sprint traz melhorias para o próximo, o que ajuda a melhorar a performance do time.
Quebra do projeto em pequenas entregas: Ao invés de esperar meses (ou até anos) pelo processo perfeito para o famoso “go live” (lançar o processo na vida real), o desenvolvimento ágil quebra o processo em ciclos de entregas menores (sprints), lançando um MVP (Mínimo produto viável) do processo apenas com suas funcionalidades mínimas logo no primeiro sprint. Desse modo, assim como um software que lança sua versão beta mais simples, o processo já começa a entregar valor para o usuário desde o início e aprende com ele os pontos de melhoria (e já corrige nos próximos ciclos).
Adaptação de rota e redução de risco na implementação: A quebra do projeto em pequenas entregas também segue a mesma lógica de redução de risco do design. O lançamento “perfeito” que dá errado depois de meses de planejamento custa muito mais caro do que o lançamento mais modesto de um MVP que vai sendo aprimorado aos poucos, sempre aprendendo com cada ciclo de testes (agora na vida real) e ajustando a rota de desenvolvimento conforme se caminha. Com isso, a probabilidade de ter um processo implementado que seja, ao mesmo tempo, eficiente e que as pessoas querem usar é bem maior.
Acompanhamento de KPIs como fonte de informação para ajustes de rota: Todo processo possui uma (ou algumas) métricas de sucesso e um baseline de comparação. O processo que dá certo é aquele que move um ponteiro importante em relação a um momento anterior à sua existência. Nesse sentido, medir e analisar essas métricas ao longo do desenvolvimento ágil é fundamental para encontrar oportunidades de melhoria ou para escalar alguma funcionalidade que deu muito certo. Os KPIs de processo são fundamentais para orientar a direção do seu desenvolvimento.
Priorização de backlog a cada sprint: Diferentemente de um desenvolvimento em modelo cascata que depende de muitas variáveis para mudar a rota de um projeto, em um desenvolvimento ágil para implementação de processos a priorização do backlog de tarefas a serem realizadas ou funcionalidades a serem lançadas é revisada a cada sprint. Os dados e resultados de uma sprint podem fornecer insights que gerem novas ideias ou que alterem a urgência entre as atividades do backlog. Essa possibilidade de revisão mais fluida dá ainda mais agilidade e adaptabilidade à jornada de implementação.

Diferença entre jornada ágil e jornada tradicional.

Diferença entre jornada ágil e jornada tradicional.‍

Design&Ágil para inovar de verdade em processos.

De forma geral, grandes empresas já investem muito tempo, recursos e dinheiro na otimização e redesenho de processos.

Sejam projetos internos ou mesmo projetos externos com consultorias, muitos deles ficam lindos no papel, mas morrem em um relatório final ou não funcionam na vida real. E tudo isso, ironicamente, gera mais demanda por processos melhores.

Na weme, unimos as competências do design e do desenvolvimento ágil para quebrar esse ciclo vicioso e inovar nesse tema tão tradicional através da criação e redesenho de processos que agregam valor e que importam para as pessoas.

Para cada desafio de processos, criamos e lideramos um time multidisciplinar de até 6 pessoas, formado por wemers e membros do time da empresa, focado trabalhar em ciclos ágeis desde a exploração do problema até a implementação da solução.

Ciclo agil de projeto - Blog Na Garage — Ciclo ágil de projeto

‍Essa união se desdobra nas seguintes diretrizes que, por sua vez,trazem novos ares ao redesenho de processo:

Começamos pelo óbvio: entendemos quem vai usar o processo, ao invés de nos basearmos apenas em benchmarks e inferências internas.
Envolvemos diferentes áreas desde o início do projeto, para trazer diferentes perspectivas e aliados que podem colaborar com a construção e implementação.
Recortamos bem o problema que o processo deve resolver, ao invés de querer resolver todos os problemas eu um processo só.
Pensamos não só nas etapas, mas também nas conexões, mapeando informações necessárias, pontos de contato, as pessoas envolvidas e as barreiras interação.
Testamos o processo no “papel de pão” antes de colocá-lo em prática, ao invés de esperar por meses até ter o “processo” perfeito em mãos para testar com o usuário.
Tratamos a melhoria de processos como algo contínuo, e não como um projeto pontual que não se adapta às mudanças.

Além dos benefícios primários de otimização de etapas redundantes ou desnecessárias para o usuário, processos criados com e para as pessoas geram um aumento do engajamento das pessoas que o utilizam, além da melhoria da interação e da eficiência entre times.

O problema de redesenho de processos pode ser um velho conhecido das organizações, mas o jeito de resolvê-lo pode ser novo. Na pior das hipóteses, essa é uma abordagem que vale testar, não acha?