Sensemaking pode ser definido como “fazer entender, criar sentido ou dar significado” para algo. Ele é uma das ferramentas de análise de contexto, que ampliam o entendimento das necessidades de um determinado contexto. Isso porque, no dia a dia dos projetos é muito comum se deparar com situações complexas, que precisam ser “desvendadas” e explicadas para outras pessoas.
O sensemaking pode ser utilizado, por exemplo, para garantir que as melhores escolhas sejam feitas, para atingir o objetivo de geração de valor do negócio. Isso porque, apesar da grande popularização da metodologia ágil e seus frameworks no mundo do desenvolvimento de software, há momentos em que a estrutura adotada não funciona como o esperado, comprometendo essa geração de valor.
A mudança para o ágil, ainda mais atualmente, vem acompanhada de uma série de expectativas, especialmente de aumento da lucratividade. Entretanto, elas podem ir por água baixo, caso a adoção do modelo tenha problemas na definição de papeis, que podem afetar a escalabilidade, de acordo com o crescimento da organização.
Um exemplo que podemos dar nesse sentido é o famoso “modelo Spotify”, que popularizou as squads no mundo da tecnologia, se tornando um queridinho de muitos. Entretanto, de uns anos para cá, os próprios autores do “modelo Spotify” deram entrevistas e escreveram artigos afirmando que a intenção nunca foi criar um modelo que pudesse ser simplesmente copiado por qualquer tipo de organização, afinal há uma série de problemas nele e nas replicações fora de contexto.
Isso deixa claro que a ideia do “one size fits all” passa bem longe dos princípios do manifesto ágil, criado em 2001. Além disso, copiar padrões, papéis e identidades sem a realização prévia do sensemaking pode tornar o sonho de uma organização ágil, um verdadeiro pesadelo.
Por isso, nesse post vamos falar sobre os principais problemas do ágil desestruturado e porque os idealizadores do “modelo Spotify” cada vez mais apresentam indícios contra o uso ao pé da letra dessa ideia.
Além disso, se você já adotou o modelo ágil, ou mesmo os squads sem se atentar a essas questões, não se preocupe, vamos falar também sobre as definições de papeis e identidades e como análises de contexto, como o sensemaking, por exemplo, são fundamentais nesse momento, evitando que você tenha equipes cada vez mais infladas, que não produzem o esperado e custam muito mais. Confira:
Desenvolvimento ágil: por que meu projeto deu errado?
O manifesto ágil completou 20 anos de publicação em 2021 e de lá para cá tem derivado uma série de metodologias e frameworks, utilizados para melhorar o desenvolvimento de software nas empresas. O grande número de projetos ágeis de sucesso, contribuiu para a popularização desses frameworks.
Então, por que existem projetos ágeis que dão errado? O que pode ter acontecido nesse caminho se você seguiu todas as regras? Se você aumentou o investimento, por que não recebeu o retorno? Se na sua equipe há todos os papeis e cargos necessários, por que o esperado não foi atingido?
Veja que dar errado nesse contexto, pode ser entendido como não atender às expectativas de produtividade, entrega, organização e lucratividade.
É claro que existe uma série de fatores que podem impactar o andamento dos processos ágeis. Entretanto, existem alguns pontos que se destacam nas análises desses erros.
De acordo com artigo da Harvard Business Review, os processos ágeis costumam dar errado, porque as empresas, ao buscar uma alta performance, acabam se tornando muito táticas (focando muito nos processos e caindo na microgestão) ou muito adaptáveis (evitando comprometimentos de longo prazo e colaborações multidisciplinares). Na realidade, o ideal seria equilibrar esses dois posicionamentos.
Além disso, alguns mitos criados ao redor do mundo ágil acabam fazendo com que muitos se sintam desmotivados e, por consequência, menos produtivos. Por exemplo, no geral, as práticas, processos e ferramentais se tornaram o condutor do trabalho e não os indivíduos e as interações. De acordo com o artigo da HBR, o Head de produtos digitais de uma empresa da Fortune 100, chegou a relatar que não era permitido que eles questionassem os próprios processos.
O manifesto ágil indica que, em intervalos regulares, a equipe precisa refletir sobre como se tornar mais eficaz e, em seguida, sintonizar e ajustar seu comportamento de acordo. Isso raramente é feito porque o backlog sempre precisa de manutenção.
Em uma outra organização da Fortune 500, Product Managers e engenheiros se comunicam exclusivamente por meio de ferramentas, com o objetivo de apenas dar e receber ordens. Isso faz com que muitos desses processos acabem, na realidade, assumindo características do Waterfall, já que o trabalho é apenas passado de área para área. Não à toa, o CTO dessa empresa relatou que seu time se sente desmotivado, apenas recebendo ordens de execução.
Quando falamos do valor “responder a mudanças mais que seguir um plano”, muitos entendem como “não tenha um plano”. Assim, alguns times acabam, não tendo contato com a estratégia da organização, o que resulta em entregas com baixo valor. Sem um planejamento, os times não sabem quais ações devem ser priorizadas e como investir nessas ações com responsabilidade.
“Todos os modelos estão errados, mas alguns são úteis”, disse George Edward Pelham Box, famoso estatístico britânico. Essa frase expressa bem a ideia de que não existe um único modelo ou framework que vai se adaptar perfeitamente às necessidades de todas as organizações ou até mesmo dos projetos.
Muitos acabam se inspirado nos conceitos apresentados por grandes big techs e empresas do Vale do Silício, com o objetivo de conquistar o mesmo sucesso e acabam criando ambientes de trabalho pouco colaborativos e inflados, nos quais não há papeis e responsabilidades definidos, revisão de processos e implementação de melhorias.
Além disso, o rápido escalonamento de empresas passa por temas que acabam causando pequenas confusões no dia a dia. Aqui, podemos citar 3 exemplos:
– autonomia não é deixar que cada time faça o que quiser;
– muitos gestores para poucos times resulta em bases que apenas são suporte e não se responsabilizam pelas entregas dos projetos;
– para aumentar o número de entregas, basta aumentar o número de desenvolvedores.
Em relação a esses dois últimos pontos, há o que alguns chamam de “culto ao cargo”. Esse termo pode até ser considerado pejorativo, entretanto, ele atrapalha de forma considerável o andamento dos projetos, porque existe uma percepção de que basta apenas replicar papéis e cargos que funcionaram em outros momentos, utilizando como referência para a tomada de decisões, versões simplificadas, de outros contextos.
Descrições técnicas não absorvem as responsabilidades de um bom trabalho. Seguir qualquer processo “cegamente” já não funcionava no Waterfall e também não vai funcionar no ágil.
Isso acaba fazendo com que muitas operações fiquem infladas. Ou seja, quando os investimentos são destinados para contratações, sem a atribuição correta das responsabilidades e sem considerar o contexto específico de cada projeto, é muito provável que o projeto não alcance os resultados esperados. Um exemplo disso, são as empresas que não conquistaram o sucesso desejado, aplicando o Modelo Spotify, por falta de análise de contexto, como o sensemaking.
>>Leitura recomendada: Transformação digital: Como o ágil facilita esse processo nas empresas
Modelo Spotify: porque os próprios criadores não defendem seu uso
O Modelo Spotify se popularizou de forma considerável nos últimos anos, sendo um dos principais responsáveis por colocar na rotina de muitos projetos de desenvolvimento de software a estrutura da squad ágil. Nossa ideia aqui nesse post não é abordar essa estrutura em detalhes, mas sim apresentar o lado dos próprios autores desse modelo, assim como o de ex-funcionários do Spotify.
Além disso, é importante deixar claro que isso não significa que os squads não vão funcionar em absolutamente nenhum caso, tudo vai depender do contexto e das escolhas feitas no decorrer do projeto. Justamente por isso, as ferramentas de análise de contexto, como o sensemaking, são muito importantes.
Jeremiah Lee, que atuou como PO no Spotify, compilou em seu blog uma série de depoimentos e indícios que mostram porque “o próprio Spotify não utiliza o modelo Spotify e você também não deveria”. Isso porque, até hoje os autores afirmam que quando o modelo foi escrito, essas ideias não estavam sendo colocadas em prática. “Era parte ambição, parte aproximação. As pessoas estavam se esforçando para copiar algo que, na realidade, não existia”, afirmou Joakim Sundén, que atuou como Agile Coach no Spotify entre 2011 e 2017.
“Me preocupa que as pessoas pensam o Modelo Spotify como um framework que pode ser simplesmente copiado e implementado… Agora, a gente está tentando deixar claro que temos problemas também. Nem tudo é incrível e funciona bem, os squads nem sempre são bons”, conta Anders Ivarsson, co-autor do Modelo Spotifty.
Alguns dos principais problemas destacados por Lee, foram:
Responsabilidades: a falta de definição dos papeis de responsáveis pelas entregas do time de engenharia, por exemplo, fazia com que um Product Manager, não conseguisse negociar prioridades com um equivalente.
Comunicação: se um problema não fosse resolvido com os pares, havia sempre a necessidade de escalar para cada vez mais níveis, de modo que, por vezes, todo um departamento estava envolvido na resolução de problemas simples.
Colaboração: não havia um processo definido para colaboração entre times, cada um ficava livre para usar o que quisesse, o que acabava afetando a produtividade, justamente porque não havia uma linguagem em comum para que eles pudessem discutir sobre processos, problemas, estratégias e aprimoramento de performance.
“Se você tem modelos inconsistentes de trabalho, é mais difícil que as pessoas se movam. Se é mais difícil que as pessoas se movam, é provável que o seu modelo de trabalho seja inconsistente. É apenas um reforço, até que, de repente, você não está mais realmente trabalhando para a mesma empresa. Você está trabalhando nessas ‘subculturas’ estranhas”, explicou Jason Yip, Agile Coach no Spotify.
Além disso, é importante ter em mente que o modelo Spotify foi documentando na época em que o Spotify era uma empresa menor do que é atualmente. A ideia inicial, era de que esse modelo seria apresentado de forma seriada, tendo, por exemplo, a autonomia como foco da primeira parte (ou o documento que conhecemos hoje por “Modelo Spotify”). Entretanto, itens como alinhamento e responsabilidades nunca chegaram a ser apresentados de maneira complementar ao modelo apresentado incialmente.
>> Leitura recomendada: Cultura ágil: todas as empresas precisam de business agility?
Como definir papeis e identidades corretamente com sensemaking?
Como vimos com os problemas do modelo Spotify, a ideia de que existe um único padrão que não pode ser alterado pode impactar negativamente a sua infraestrutura. Isso porque, a definição dos papeis ou cargos deve ser feita pensando na geração de valor, grande objetivo do negócio.
Pensando nessa lógica, a materialização da geração de valor acontece por meio do trabalho, que por sua vez, é realizado por pessoas, que ocupam um determinado papel dentro da estrutura do projeto, assumindo uma identidade específica, com responsabilidades pré-determinadas, de acordo com os acontecimentos e situações.
As consequências de papeis inflados é justamente o aumento nos conflitos de interesse, gerando barreiras e rivalidades entre os integrantes do time. O aumento desses conflitos leva ao consequente aumento da burocracia, que por sua vez torna o projeto menos ágil. Ou seja, se o seu objetivo com a criação dos papéis era conquistar um ideal de agilidade, o resultado será justamente o inverso.
A pergunta que não quer calar então é: como definir os papeis, identidades e responsabilidades para o meu projeto corretamente? A realidade, é que não existe uma única resposta correta, porque cada projeto possui um alto nível de complexidade de mercado, que requer uma análise de contexto específica.
Portanto, é importante ter em mente que os papeis podem variar de acordo com o contexto do seu projeto e dos profissionais que você tem no seu time, pensando no desenvolvimento de produtos/serviços ágeis. Ou seja, nem todos eles são necessários em um único projeto.
>>Leitura recomendada: O papel e os impactos da tecnologia na cultura organizacional
Sensemaking: evitando erros no modelo ágil
Um estudo do MIT (Massachusetts Institute of Technology) definiu como fundamental para uma liderança eficiente o desenvolvimento de 4 competências principais:
- Visioning;
- Relating;
- Inventing;
- Sensemaking.
O termo sensemaking foi introduzido no mundo organizacional pelo teórico americano Karl E. Weick, autor de diversos livros sobre o tema. Ele é uma ferramenta muito útil, que auxilia as empresas a compreenderem melhor o contexto de um determinado cenário, modelo de negócio, escalonamento do planejamento estratégico e, claro, a definição dos papeis e identidades.
Isso porque, é possível aumentar o entendimento de assuntos complexos de forma mais simples. A definição dos papeis e responsabilidades de um projeto é uma tarefa que demanda uma análise de contexto, como o sensemaking, para que seja possível deixar claro o objetivo de geração de valor da empresa, assim como o contexto do projeto que será desenvolvido.
Simplificando, o sensemaking pode ser divido em 3 fases:
- Exploração do ambiente;
- Contextualização do sistema;
- Aprendizado e atuação sobre o sistema.
Compreendendo a importância de ferramentas de análise de contexto, como o sensemaking, para o desenvolvimento dos projetos de software e tecnologia, a OPUS Software inclui os princípios da análise de contexto com seus clientes, para atender com precisão às necessidades de cada projeto, e, a partir daí, identificar todos os papeis e responsabilidades necessários para o desenvolvimento do projeto, considerando a capacidade do time interno ao alocar as equipes de maneira estratégica.
O modelo de trabalho da OPUS foi criado pensando em Business Agility, ou seja, na utilização dos conceitos ágeis que possibilitem o entendimento de contexto e das necessidades para, com base nisso, tomar a melhor decisão, para evitar problemas, como esses que apresentamos nesse post. Por isso, todo o projeto é desenhado levando em consideração o contexto e os desejos específicos de cada cliente.
Para saber mais sobre nossa metodologia de trabalho, é só entrar em contato com a gente!
