OKRs na Vida Real - Aplicação no Mundo Empresarial
Introdução
Os OKRs estão na moda. Mas tal não significa que devamos seguir essa moda se não estamos preparados para ela. Isto porque, implementar a metodologia de OKRs incorretamente vai custar mais à empresa e aos colaboradores do que se continuasse com a metodologia antiga e/ou sem metodologia. É por isso, que é uma best practice iniciar a implementação dos OKRs numa equipa considerada piloto. E, por norma, essa equipa será ou terá uma melhor performance dos que as restantes equipas e, por esse motivo, estará melhor preparada para retornar um resultado mais fidedigno daquilo da futura implementação dos OKRs.
OKRs na Vida Real
Nada melhor do que pensar naquilo que é o nosso quotidiano para perceber como funcionam os OKRs, na prática. Não obstante de podermos ler artigos e livros sobre o tema. Por exemplo, eu li o livro Measure What Mattters by John Doerr que retrata o tema dos OKRs de forma muito minuciosa.
Antes de passarmos aos exemplos, devo referir que são exemplos ilustrativos para se perceber como se devem definir OKRs. Não dei muita importância às regras para se atingir algo, porque não sou especialista nem em futebol, nem em gastronomia.
Vamos então aos exemplos e desmistificar os OKRs de forma simples, ainda que a sua implementação seja complexa e demorada.
Exemplo 1 – Clube de Futebol Profissional
No meu caso é o Sporting Clube de Portugal.
Imaginemos que após várias conversas top-down e bottom-up se definiu o seguinte objetivo (Big Hairy Audacious Goal) para o ano de 2024-2025: Ganhar a Champions League.
Definido o Objetivo, temos de pensar como vamos definir os Key results para cada uma das “sub-equipas” que compõem a equipa de futebol profissional do Sporting. Mas antes de definir esses Key Results, temos de garantir que todos que direta ou indiretamente compõem a equipa de futebol profissional do SCP estão cientes do Big Hairy Audacious Goal. É por isso que há inúmeras conversas top-down e bottom up até se atingir a definição final do Objetivo e respetivos KRs.
E podemos definir, por exemplo, como Key Results para o Objetivo de ganhar a Champions League no ano de 2024/2025 os 3 seguintes:
Objective – Ganhar a Champions League. AS MEASURED BY
Key Result 1 – Ganhar os 3 jogos em casa contra os 3 diferentes adversários do grupo
Key Result 2 – Ganhar, pelo menos 1 jogo fora, contra a equipa favorito do grupo
Key Result 3 – Ter um saldo positivo de golos marcados Ganhar à principal equipa adversário do grupo em casa e fora
Se analisarmos bem os KR, vamos reparar que os mesmos estão muito mais relacionados com a equipa que joga, os jogadores e não tanto com as restantes “sub-equipas” que compõe a “equipa global” de futebol profissional do SCP. Por exemplo, a equipa de preparação física dos jogadores do SCP, consegue perceber o Objetivo e os KR, mas por não jogarem (não são jogadores), não conseguem perceber qual será o seu Objetivo bem como os seus KR, para que a equipa profissional do SCP atinja o principal objetivo que é ganhar a Liga Europa.
Significa então que o trabalho não está terminado. Temos que definir os KR para as restantes equipas. Mas como? Simples teoricamente, porque na prática exige pensar o tema e exige tempo!
Podemos e devemos replicar (cascade) estes KR para as “sub-equipas” que constituem a equipa global de futebol profissional do SCP. Replicando os KR teríamos, por exemplo para o 1º Objetivo da equipa de futebol profissional do SCP; jogadores e treinadores, a seguinte “cascade” para a equipa de preparadores físicos.
Objective – Ganhar os 3 jogos em casa contra os 3 diferentes adversários do grupo AS MEASURED BY
Key Result 1 – Ter disponível e em forma (dentro do peso e do índice IMC) pelo menos 1 ponta de lança para cada um dos jogos em casa do Sporting na Champions
Key Result 2 – Garantir que todos os jogadores não têm uma variação da massa gorda entre jogos da Liga Europa superior a 5%
E esta “cascade” replica-se pelas restantes equipas.
Ou seja, fazendo a “cascade” dos Key Results – que não é obrigatório, mas facilita o trabalho – todos ficam a conhecer o Objetivo, todos têm KR específicos para a sua equipa e todos sabem o que devem fazer etêm as condições para fazê-lo de forma independente.
Se tivéssemos definido apenas os KR para a equipa de futebol, a equipa de preparadores físicos não sabia ao certo como atingir os KR, porque não são eles que estão dentro do campo a jogar contra as equipas. Os KR definidos não fazem sentido para a equipa de preparadores físicos.
Mas não havia problema algum se se quisesse criar só OKRs para a equipa de futebol profissional do SCP, jogadores. Não há nada que diga que todas as equipas têmque ter Objetivos e Key Results Definidos – aliás, se bem implementados, uma das fases de implementação dos OKRs é implementá-los primeiro numa equipa piloto – mas concordarão que ficará mais difícil para a equipa de futebol profissional do SCP atingir o objetivo de ganhar a Champions, se as equipas mais influentes e que trabalham mais de perto com a equipa de futebol (mas não dependem dela, têm as suas funções e responsabilidades, são multi-disciplinares e são autónomas) não tiverem os seus Objetivos e Key Results definidos.
Exemplo 2 – Cozinha de um restaurante
Para mim os restaurantes são bons, se cumprirem um determinado conjunto de critérios. Por exemplo, se o restaurante não me servir comida que não seja fresca nem saborosa, para mim são 2 razões suficientes para não voltar ao restaurante. Mas vou colocar a fasquia mais alta. Afinal é isso que é o que os OKRs se propõem.
Mais uma vez, vamos imaginar que após várias conversas top-down e bottom-up se definiu o seguinte objetivo para o triénio de 2023-2026: Ganhar a primeira Estrela Michelin para o restaurante.
O Chef do restaurante, a sua brigada, o chefe de sala e o seu staff, e o diretor do restaurante e demais membros da equipa, terão de estar alinhados enquanto equipa neste Objetivo e, com isso, definir os seus Key Results. Para esse objetivo, vamos definir então 2 Key Results.
Objective – Ganhar a primeira Estrela Michelin para o Restaurante dentro de 3 anos
MEASURED BY
Key Result 1 – Aperfeiçoar, pelo menos 2 pratos de autor, nos próximos 3 anos
Key Result 2 – Garantir que nesses 3 anos não existe nenhum reclamação grave dos clientes, seja ao nível da refeição, do serviço ou das instalações
Mais uma vez, os KR estão muito direcionados para a equipa do Chef e da sua Brigada. Será que o chef de Sala consegue cumprir o KR de aperfeiçoar pelo menos 2 pratos de autor? Não me parece.
Portanto, é preciso fazer o “cascade” dos Key Results dessa equipa, transformá-los em Objetivos de uma outra equipa e traçar novos KR.
Exemplo de um Objetivo e KR para o Chef de Sala e a sua equipa:
Objective – Garantir que nesses 3 anos não existe nenhum reclamação grave dos clientes, seja ao nível da refeição, do serviço ou das instalações
AS MEASURED BY
Key Result 1 – Promover a formação profissional da sua equipa em gestão de clientes e de sala de restaurantes
Key Result 2 – Auditar de 15 em 15 dias o comportamento e desempenho da sua equipa enquanto atende o cliente e serve os pratos.
(Muito exemplificativo)
Conclusão
- Os OKRs não são de todo uma metodologia fácil de implementar. É uma metodologia complexa que demora tempo a perceber, interiorizar, espalhar pela Organização, a implementar e a controlar. É por isso que muitas vezes opta-se, no início da sua implementação, de fazer um teste piloto junto de uma equipa que já performance bem.
- Os OKRs não se definem ao nível das pessoas, mas sim ao nível das equipas. E as equipas têm de ser 100% autónomas, responsáveis para puderem atingir o seu Objetivo medido através dos KR. E neste ponto permitam-me um exemplo muito rápido. Imaginem que o Manuel resolveu estabelecer como Objective perder 20 quilos em 1 semana. E definiu 1 KR como: percorrer 20 Km / dia de bicicleta e mais 2 KR. Só que o Manuel não têm bicicleta, mas o seu vizinho (outra equipa) tem. Ele precisa da bicicleta do seu vizinho para cumprir o seu objetivo atingindo o KR de percorrer 20 Km /dia de bicicleta. É muito pouco provável que o consiga atingir aquele KR, porque não tem autonomia e responsabilidade total sobre o KR que definiu, está 100% dependente de outra equipa.
- Os OKRs ajudam os membros de cada equipa a criarem laços mais fortes. Mas se as equipas ou algum membro da equipa não se identificar com esses OKRs, pelas razões acima descritas ou outras, o feitiço vira-se contra o feiticeiro. O que me leva ao ponto 4 da conclusão, descrito no livro de John Doerr…
- A implementação dos OKRs, tem de se ser acompanhada de CFR – Conversations, Feedback e Recognition. Com o objetivo de rever KR, adaptá-los se for o caso, e perceber as razões para a equipa não estar a conseguir atingir o Objetivo com base nesses KR.
- A réplica “cascade” dos OKR de uma equipa para outra não é obrigatória, mas pode ser uma metodologia que facilita a distribuição de OKRs pelas diferentes equipas. Mas nada impede que se crie OKRs específicos para cada equipa sem nenhuma metodologia associada. Esses OKRs têm é de ser coerentes para cada uma das equipas.
Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. E na PARTE 2 – O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum.
Vamos agora ver na PARTE 3 – se Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Ambiente Waterfall
Em ambiente waterfall significa, de forma não exaustiva, o seguinte:
- O tipo de projeto não envolve incertezas. Ou seja já se sabe o que se vai desenvolver/construir. Por exemplo, uma casa ou uma piscina.
- As as atividades desse projeto, por estar inserido num ambiente de certeza e não de incerteza, são desenvolvidas sequencialmente. Ou seja, após o términos de uma atividade, começa-se a segunda.
- Não existe um envolvimento direto do cliente e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas
- Havendo possibilidade e vontade em fazer testes, estes são feitos em grande escala no final de todas as atividades estarem concluídas
Ambiente Agile
O ambiente agile significa, o contrário do ambiente waterfall. Ou seja, e de forma não exaustiva:
- Os projetos mais adequados para serem desenvolvidos neste tipo de ambiente são projetos complexos e que envolvem algum grau de incerteza. Por exemplo, o desenvolvimento de um produto digital, enquadra-se neste tipo de projetos.
- Todas as atividades que se consideram necessárias para produzir um incremento, são realizadas no sprint correspondente. E, portanto, daqui surgem duas grandes diferenças de projetos em ambiente waterfall e ambiente agile:
- As equipas devem ser multi-disiplinares e autónomas
- Os testes, devem ser considerados uma atividade que produz um incremento e, portanto, são realizados em cada sprint e não no final do projeto. Até porque, e passamos para o ponto 3…
- Tem de existir um envolvimento direto do cliente. Isto porque não sabemos a 100% como vai ser o produto final. E o cliente também não sabe. E, portanto o cliente tem de estar envolvido no desenrolar do projeto. Por exemplo, criando atividades de UX Research na fase em que Visão do Produto está a ser desenvolvida. E com isso, valorizamos e muito o início do projeto, porque a Visão do Produto incorpora findings e insights daquilo que são as necessidades, frustrações e motivações dos cliente.
- Outra altura onde o cliente pode estar presente será nas cerimónias de review para recolha direta de feedback. e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas. Ou seja, e vamos para o ponto 4…
- Há iterações entre as equipas, clientes e stakeholders. Iterações essas que nos vão permitindo afinar o produto final. Como? Redefinindo e refinando o backlog prioridades de produto e, posteriormente, o backlog da sprint.
Conclusão
Poder-se-ia dizer que se as metodologias, ou melhor, se os ambientes ou frameworks são diferentes, então, obrigatoriamente, será diferente criar um produto digital em ambiente agile do ambiente waterfall. E dizer isto não está errado. Afinal é uma verdade de La Palice.
O problema é que não basta dizer que estamos ou adotamos uma metodologia agiela e o desenvolvimento do produto digital, per si, será diferente.
Quem faz os ambientes serem waterfall ou agile ou de outro tipo são as pessoas. E, portanto, se não houver vontade, motivação, aprendizagem e um step-up, sem medos e com compreensão 100% da hierarquia de quais são os papéis de cada um e o que isso implica, para mudar a cultura da Empresa e assim efetivamente implementar o ambiente agile, o que vai acontecer é que estaremos a desenvolver um produto digital em ambiente “pseudo-agile”; ou seja na realidade o ambiente é waterfall.
Há várias de formas de perceber isso, elenco apenas quatro:
- O cliente não é envolvido de início e ao longo do desenvolvimento
- As equipas não são multi-disciplinares nem autónomas
- A priorização das atividades ou a re-priorização das mesmas ou de algumas delas, não é feita pelo PO, mas está dependente do cargo da pessoa que faz um pedido.
- Os testes são feitos “em barda” dias antes do lançamento do produto para o mercado
Espero que tenham gostado e aprendido alguma coisa neste conjunto de 3 artigos sobre produtos digitais.