indicadores de performance

Indicadores de performance, incentivos e motivação

Indicadores de performance, incentivos e motivação

Por Leonardo Müller

Venho publicando uma série de artigos sobre a "empresa ideal". O objetivo é pensar em uma empresa de desenvolvimento de software de uma forma simples e focada em gerar valor para o cliente.

Em um primeiro momento, dei uma visão global de como tal empresa deveria se organizar na minha opinião e depois falei um pouco sobre minha experiência em montar um time comercial com uma mentalidade lean. O próximo passo da cadeia produtiva da empresa é o desenvolvimento de software, mas para avançar nessa direção, primeiro vou falar de indicadores de performance, incentivos e motivação.

Entenda os indicadores de performance de forma global

Já escrevi sobre motivação em um artigo anterior, focando nos fatores motivacionais de autonomia, maestria e propósito. Além desses fatores — que eu diria estão relacionados aos objetivos pessoais de cada um — há de se atingir também os objetivos esperados pela empresa se quisermos estar em um jogo de ganha ganha. Jogo este impossível de vencer se uma empresa olhar apenas para seus objetivos sem se ater às necessidades de cada colaborador ou se este se importar apenas com seus objetivos sem estar atento às necessidades da empresa.

A melhor forma de a empresa comunicar aos seus colaboradores quais são suas necessidades é através do planejamento estratégico, que tem seu atingimento medido pelos famosos KPI´s. Logo, a forma do colaborador atender às necessidades da empresa é atingindo as metas estabelecidas por esses KPI´s. Toda essa corrente lógica funciona como um direcionamento poderoso; as pessoas realmente trabalham em função desses indicadores quando a cultura está bem implantada. E isso pode ser ótimo ou pode ser péssimo.

Imagine só um suporte que seja avaliado pela quantidade de bugs resolvidos. Quanto mais resolver, melhor a performance. Ou um desenvolvimento avaliado pela quantidade de novas funcionalidades entregues. Ou um comercial pelo valor total de vendas. Ou uma implantação avaliada pela quantidade total de usuários do sistema. Parecem todas métricas corretas não? Vamos ver mais de perto.

Se a quantidade de bugs resolvidos é a métrica principal eu posso resolver bugs de forma rápida sem analisar causa raiz. Outros iguais serão abertos. Posso também não me preocupar com qualidade no desenvolvimento. O importante é que os bugs que apareçam sejam resolvidos. Aliás, se o foco no desenvolvimento é a produção de mais telas o que importa é velocidade e não sustentabilidade. Na área comercial, eu posso vender muitos milhões sem me preocupar se estou resolvendo o problema real do cliente e se o que vendi é perfeitamente exequível. Na implantação, posso ativar milhares de usuário após um treinamento pífio, desde que eu possa considerar a implantação realizada. Eu já participei de equipes onde os resultados individuais tinham sido maravilhosos e o resultado global, péssimo!

A palavra chave aqui aqui é disfunção, causada com a melhor das intenções. Minha dica para combater essa disfunção é atrelar todas as equipes aos indicadores de resultado da empresa. Faturamento recorrente e taxa de renovação, lucratividade, NPS e felicidade das equipes são indicadores difíceis de serem burlados. Na minha opinião, todos os demais indicadores para as equipes devem ser desdobrados a partir destes. Aumento de quantidade de bugs diminuiria NPS, então não seria aceito. Vendas e implantação sem qualidade impactariam em faturamento recorrente, renovação e lucratividade. E a felicidade das pessoas é para lembrar a todos que além dos indicadores principais todo gestor tem que se preocupar com as pessoas e que resultado a qualquer custo não é uma opção.

Leia também:
Os heróis estão mortos. Sem spoilers

Logicamente estes indicadores focam em sustentabilidade a longo prazo. Existirão casos legítimos de empresas que precisam focar em vendas mesmo que isso prejudique alguma outra dimensão, por exemplo. O que defendo é que, nesses casos, os indicadores estabelecidos poderão criar disfunções em uma ou mais áreas e que esta decisão deve ser um ato consciente.

Na próxima semana, começo a falar um pouco de desenvolvimento de software. Não pretendo entrar muito na questão de como aplicar lean no desenvolvimento, já que é um assunto bem disseminado e com muita gente boa escrevendo sobre. Vou focar mais em gestão de pessoas e criação de cultura ágil. Para tanto precisava desse breve artigo sobre indicadores de performance, incentivo e motivação.

Até lá !


comercial ágil

O Comercial Ágil

O Comercial Ágil

Por Leonardo Müller

Há duas semanas, escrevi sobre o uso de ferramentas de gestão ágil além das fronteiras de desenvolvimento de software e, na semana passada, dei um zoom out para mostrar a forma que como vejo uma típica empresa de software com suas principais áreas e processos.

Fiz isso porque não vejo como uma área pode funcionar bem sem as outras e também porque a implementação do ágil fica prejudicada em áreas que se comportam como ilhas dentro da empresa.

O esquema geral que expus foi o seguinte:

                                                          A: Muito envolvimento e esforço     B: Pouco envolvimento e esforço

 

Olhando o comercial mais de perto:

Não foi fornecido texto alternativo para esta imagem

De uma forma geral, o comercial precisa fazer o funil de vendas andar, e os três passos principais para isso é prospectar, negociar e vender. Existem diversos funis para diferentes segmentos e times, cada um com uma sequência de passos, tempos e taxas de conversão.

Quando iniciei um time comercial do zero, o foco eram vendas de novos produtos e serviços para o cliente da base. Montei um time predominantemente com gente que conhecesse do negócio e agreguei profissionais com conhecimento de gestão comercial.

O modelo inicial era o tradicional: temos nossas oportunidades, cada executivo de venda tem seus clientes e sua cesta de oportunidades e cuida delas do início ao fim. Depois de 3 meses, eu não estava satisfeito com a dinâmica do time nesse modelo. Não éramos um time: éramos um conjunto de profissionais preocupados cada um com suas oportunidades.

Como mudar? Será que dava pra aplicar Scrum dentro do comercial, priorizando um backlog e atacando as tarefas prioritárias dentro de um tempo pré-definido? Tentamos e não deu certo.

Lições aprendidas

  1. Vendas dependem de resposta do cliente e ele não está nem aí se sua sprint vai acabar em uma semana. Assim, a solução do problema estava fora da equipe e isso vai contra as boas práticas do Scrum;
  2. Os executivos de vendas não estavam acostumados a trabalhar em equipe. Era MUITO difícil eles deixarem de se importar com suas oportunidades, nos seus clientes, para ajudarem em outras oportunidades em outros clientes;
  3. Existiam muitas tarefas que não geravam valor. O que é geral valor em uma equipe de vendas? É VENDER! Qualquer tarefa não relacionada a aumentar chances de venda deveria ser tarefa descartada. E tinha muita coisa a ser descartada.

Ajustes realizados

  1. As oportunidades de venda viraram nossos cards no backlog. A prioridade era simples: as oportunidades de maior valor estavam mais priorizadas em detrimento das oportunidades de menor valor. As oportunidades de menor valor não ficavam paradas, apenas não era despendido muito esforço nelas. Existiam oportunidades de baixo valor monetário e alto valor estratégico que também estavam priorizadas;
  2. Tiramos o Scrum e adotamos o Kanban. As fases do quadro Kanban eram as fases do funil de vendas um pouco mais detalhadas;
  3. Reduzimos ao máximo tarefas que não geravam valor para fazer andar as oportunidades de venda. Relatórios deveriam ser simples, ferramentas o mais automatizadas possíveis, reuniões breves e ações estruturantes tinham recursos mínimos alocados. Eram importantes a médio e longo prazo e seriam feitas, mas a prioridade era vender;
  4. Mantive um único executivo responsável por cada cliente (lição aprendida após tentar distribuir diferentes executivos atendendo um mesmo cliente, dependendo da oportunidade). A alocação desse executivo, porém, era determinada nas reuniões de planejamento da equipe;
  5. Muitas vezes o quadro tinha planejado para a próxima semana as oportunidades de somente um executivo de venda. O restante do time iria trabalhar nela e fazê-la andar, deixando as oportunidades de seus clientes em segundo plano. Como dito anteriormente, as oportunidades não eram abandonadas, apenas se fazia o esforço mínimo necessário para mantê-las vivas e caminhando. O foco era no resultado da equipe e não na performance individual;
  6. As reuniões sobre status dos trabalho eram diárias.

Além da adoção do Kanban uma outra boa prática melhorou bastante a qualidade de nossas vendas: trouxemos as outras áreas para cada vez mais perto do comercial e isso melhorou muito a qualidade de nossas vendas e o comprometimento das equipes de entrega com o sucesso delas. Nenhuma proposta saía sem o OK da área executora.

Leia também:
Os heróis estão mortos. Sem spoilers

Muitas vezes, a construção de um projeto se dava em conjunto com a área executora (eram vendas relacionais de grandes projetos). O desenvolvimento, a implantação e a sustentação tinham que dar o seu aval e, sempre que possível, eram envolvidos nas fases mais preliminares da venda.

Kanban com mindset ágil e envolvimento das demais áreas. Com esses ajustes a equipe engrenou. Paulatinamente, a visão começou a ser em cima de qual era o resultado da equipe e não mais em torno dos resultados individuais. Batemos uma meta bastante ousada de vendas naquele primeiro ano de funcionamento.


A empresa ideal

A empresa ideal

Por Leonardo Müller

Semana passada, escrevi sobre a aplicação dos conceitos de Agile e Lean além das fronteiras de desenvolvimento de software. Cheguei à conclusão de que tinha mais para falar sobre o assunto e, então, terminei o artigo prometendo uma retomada hoje. Entretanto, senti a necessidade de dar uns passos pra trás e olhar o funcionamento do sistema como um todo, antes de falar sobre Agile e Lean dentro de cada área. Serei breve.

Antigamente, as empresas eram vistas como departamentos, cada um no seu quadrado fazendo seu trabalho. A forma de representá-la era esta aí de baixo:

empresa ideal

As setas mostram que cada departamento está dentro de sua caixinha e todo seu trabalho começa e se encerra nele mesmo. O outro departamento pega um pacote e tem que dar continuidade, muitas vezes sem saber do que se trata o pacote.

Aos poucos, porém, fomos percebendo que existia vida nos departamentos próximos e começamos a implementar rituais de passagem. O departamento anterior passou a apresentar o pacote para o próximo departamento. Às vezes, era um repasse mais estruturado; outras, apenas para tirar o peso da consciência mesmo. O trabalho continuava restrito ao departamento de direito, porém era repassado formalmente para o próximo quando encerrado.

empresa ideal

Várias tentativas foram — e são feitas — tentando colocar uma visão mais processual nas empresas, organizando-as por grupos de atividades que atravessam todas estas áreas e recebem um pouco de trabalho de cada uma. Vi, repetidas vezes, estas tentativas fracassarem por motivos diversos, geralmente ligados a engessamento de atividades, egos e mexidas em queijos alheios.

Minha proposta aqui é muito parecida com a visão voltada a processos, porém sem as caixinhas indicando quais atividades devem ser feitas em quais sequências.

A: Muito envolvimento e esforço
B: Pouco envolvimento e esforço
O processo acima desenhado é pensando em uma empresa de desenvolvimento de software. Já gerenciei todas essas 4 áreas, então conheço bem os processos de cada uma delas. Também sei o quanto é importante o envolvimento em cada fase para não termos surpresas mais adiante e, por isso, a sugestão aqui é o envolvimento em maior ou menor grau de todas as áreas em diferentes fases do processo, sendo que:
  • 1. Cada área vai ter seu momento de alto grau de esforço e envolvimento nos processos nas quais ela será líder;
  • 2. Cada área terá seu envolvimento em cada fase do processo para poder contribuir no andamento dos trabalhos de modo que as entregas cheguem de forma redonda onde têm que chegar.

Para o modelo funcionar é necessário que todas as lideranças adotem uma atitude de cooperação e estejam abertas a mudanças. Esse tipo de atitude — assim como as atitudes ruins — acabam transbordando para os liderados e faz com que eles as adotem também. Estando as barreiras interdepartamentais quebradas, nós podemos pensar em adotar o Agile e o Lean de forma estratégica na empresa.

Antes disso, ainda vou me aprofundar um pouco mais nesse modelo de organização colaborativa. Até lá!


Agile e Lean além do Desenvolvimento de Software

Agile e Lean além do Desenvolvimento de Software

Por Leonardo Müller

Me lembro que há uns 12 anos a pós em gerenciamento de projetos era dominada por gente de Tecnologia. Depois começaram a chegar os engenheiros e, por fim, pessoas de profissões mais variadas. Esse movimento foi ótimo, afinal GP é uma área que pode ser aplicada em qualquer profissão.

Agile e LEANCom o SCRUM, e demais disciplinas que sustentam o conceito AGILE, aconteceu o mesmo: primeiro nasceu e cresceu na tecnologia, mais especificamente em times de desenvolvimento. O KANBAN é mais antigo que o SCRUM e sua adoção nos escritórios é mais recente junto com a "descoberta" do LEAN. O próprio LEAN ficou bastante tempo restrito às linhas de produção da Toyota antes de se espalhar para outras linhas de produção e finalmente chegar aos escritórios.

A TEORIA DAS RESTRIÇÕES — cujo embrião de restringir o trabalho em andamento já estava há muito tempo no KANBAN — ainda hoje tem um uso não tão difundido, talvez aparecendo mais nas fábricas que adotam o LEAN com mais afinco e aos poucos mostrando-se timidamente nos escritórios.

Fiz toda essa linha do tempo para mostrar que as técnicas, processos, disciplinas, filosofias, ou seja lá como queiram chamar as letras grandes do texto, vão se expandindo no mercado. E passou da hora delas serem adotadas na empresa toda.

Eu já trabalhei gerindo equipe comercial, de customer success, de desenvolvimento, de entrega e de sustentação de sistemas. Posso dizer que tenho conhecimento de como funciona a operação de uma empresa de software como um todo. Em cada uma destas áreas adotei uma combinação de SCRUM, LEAN e KANBAN.

Como eu já disse em artigos anteriores, considero uma caixa de ferramentas que usei e uso conforme as necessidades da empresa:

SCRUM

Ótimo para ter previsibilidade de quantidade de entrega — note que eu não falei em previsibilidade de escopo — quando se conhece a velocidade do time e consegue protegê-lo de trabalho não planejado. O SCRUM foi concebido para priorizar e entregar primeiro o que gera mais valor para o cliente. Quem quiser saber mais sobre suas raízes sugiro o ótimo livro A Arte de Fazer o Dobro do Trabalho na Metade do Tempo, de Jeff Sutherland.

O problema é que no mundo real o desenvolvimento não define sozinho o que é vendido, como é vendido, como é entregue e como são cobrados os produtos e serviços da empresa onde ele está inserido. Normalmente esta é uma atribuição do comercial. Se ambos não estiverem na mesma sintonia sobre como trabalhar o desenvolvimento e entregas dos produtos para os clientes, o objetivo primário do SCRUM não será plenamente atingido. Estou usando o desenvolvimento como exemplo, mas o mesmo vale para o alinhamento de implantação, treinamento e sustentação com a área comercial e entre elas mesmas.

LEAN

Enquanto o foco do SCRUM é gerar valor rápido, o foco do LEAN é eliminar desperdício. Juntos eles são imbatíveis. O LEAN eu vejo mais como uma filosofia com algumas atitudes anti desperdício do que como um processo com rituais bem delimitados. Considero o livro Implementing Lean Software Development: From Concept to Cash de Mary Poppendieck e Tom Poppendieck uma referência para conhecer a aprofundar o uso da filosofia LEAN no desenvolvimento de software. O livro traz algumas indicações contraintuitivas para quem pensa em termos de gestão financeira, como por exemplo não deixar a equipe totalmente alocada, tendo sempre à mão equipe ociosa para reduzir o desperdício! Traz também muitas provocações e provas de que o funcionamento de todas as áreas estão interligadas, afinal fazemos parte de um sistema em que o todo é — ou deveria ser — maior que a soma das partes.

Então, do LEAN eu sempre uso:

  • foque no resultado final;
  • não faça nada que atrapalhe seu resultado final;
  • procure e elimine desperdício (melhoria contínua!).

Importante: foco no resultado final não é resultado a qualquer custo. É fazer da melhor forma o que precisa ser feito. Por exemplo: uma equipe bem treinada e integrada faz melhor o que precisa ser feito e normalmente obtemos isso através de custos indiretos ou despesas. Custos indiretos e despesas que melhoram o que deve ser feito também são parte do LEAN.

KANBAN e TEORIA DAS RESTRIÇÕES (TOC):

Trabalhei com KANBAN e TOC em todas equipes que não estavam trabalhando para projetos. As equipes de Comercial, Customer Success, Suporte e alguns projetos que tinham fases repetitivas geri com o KANBAN e TOC. Foi uma experiência muito interessante colocar esse modo de trabalho — normalmente restrito à fábricas e equipes de desenvolvimento de software — para funcionar além destas fronteiras e os resultados foram ótimos!

Começar com objetivos estratégicos, desdobrar em OKR´s e indicadores e, a partir daí, puxar o trabalho que precisa ser feito realmente organiza uma operação (claro que essa fórmula, aparentemente simples, eu descobri depois de algumas tentativas e erros).

Leia também:
Segurança Psicológica não é frescura

Bem, por hoje descrevi um pouco da minha experiência aplicando essas ferramentas do AGILE e do LEAN nos times por que passei. Na próxima semana, pretendo escrever um pouco mais sobre como é possível aplicá-las para fazer o trabalho fluir melhor entre as equipes e não somente dentro delas.

Um abraço e até lá!


Segurança Psicológica não é frescura

Segurança Psicológica não é frescura

Por Leonardo Müller

Esta semana compartilhei o vídeo abaixo, do Simon Sinek em uma TED, sobre como os grandes líderes inspiram ação:

https://youtu.be/qp0HIF3SfI4

Eu não tinha ciência sobre o conteúdo, apenas sabia que gostava das ideias do autor. No vídeo ele citou, entre outras características, a questão da segurança psicológica que um líder deve prover para seu time. Esse insight em especial me chamou a atenção porque não é usual quando aparece o tema liderança e desenvolvimento de times. Mesmo assim, não era a primeira vez que eu ouvia sobre ele.

Me recordei, então, de uma palestra em que fui apresentado ao “Project Aristotle” do Google, que se baseou em centenas de entrevistas com funcionários e na análise de dados de mais de 100 equipes de trabalho na empresa. O Google esperava achar como fatores de melhor desempenho nas equipes:segurança psicológica

  • Engenheiros com melhor formação;
  • Engenheiros com mais experiência;
  • Liderança focada em resultado;
  • Baixo índice de conflitos (harmonia).

Cada uma destas hipóteses, no entanto, estava errada. O Google efetivamente encontrou como fatores para uma equipe de alto desempenho:

  • Segurança psicológica: podemos assumir riscos sem nos sentirmos inseguros ou envergonhados?
  • Confiabilidade: podemos contar com os outros para fazer um trabalho de alta qualidade em tempo?
  • Estrutura e clareza: São claros os objetivos, funções e planos?
  • Significado do trabalho: Será que estamos trabalhando em algo que é pessoalmente importante para cada um de nós?
  • Impacto do trabalho: Será que acreditamos no trabalho que estamos fazendo?

A segurança psicológica não por acaso foi colocada como ponto central nos resultados. Ela permite que os membros da equipe discordem abertamente, debatam e errem sem medo de represálias de colegas e das lideranças. Por outro lado, exige que as pessoas estejam pré dispostas a abandonar suas ideias — ou no mínimo ouvir de verdade as outras pessoas — em prol de algo que possa ser melhor ou mais produtivo. Todo mundo que já teve que mudar de posicionamento sabe que isso demanda uma tremenda maturidade, tanto pra quem fala quanto pra quem ouve.

Você também vai querer ler:
Contratar sênior nem sempre é melhor que contratar júnior

Minha experiência na montagem de diversos times mostrou que quanto mais conflitos saudáveis existiam na equipe, melhor eram os resultados entregues. Quanto menos conflito em torno de decisões, maior era o sinal de que algo estrutural estava errado. Se não havia conflito é porque alguém tinha desistido de debater com o dono da verdade ou porque a estrutura da empresa ou da equipe não absorvia ideias fora de um círculo restrito. E aí é hora do líder agir.

Pessoalmente eu busco estimular o conflito e mostrar para as pessoas que elas podem tentar coisas novas e errar porque não serão consideradas menos capazes por isso. É um trabalho essencial da liderança prover esse ambiente de segurança psicológica. O Google já havia provado e o Simon Sinek seguiu uma linha de raciocínio ótima para abordar o tema mais uma vez.

Não é frescura. É gestão além da vitrine. Você se sente seguro em sua empreitada atual?


Contratar sênior nem sempre é melhor que contratar júnior

Contratar sênior nem sempre é melhor que contratar júnior

Por Leonardo Müller

Nas últimas semanas, muita gente tem usado o vídeo abaixo como prova de que três seniores valem mais que cem juniores:

https://youtu.be/73bAld3ZydQ

Como todo vídeo da moda, os profissionais assistem-no, transferem para o mundo dos negócios sem filtro e generalizam as conclusões. No vídeo, de fato, três seniores valem mais que cem juniores. No futebol.

Mas nas empresas a avaliação tem que ser diferente. Ela deve levar em conta os desafios do cargo e a capacidade do profissional. Quando esses dois fatores estão equilibrados, o resultado atingido é o que chamamos de flow, ou realização pessoal, situação em que o profissional sente-se desafiado, porém preparado para vencer o desafio.

Se a capacidade do profissional for muito superior ao desafio ou vice-versa, o resultado são os comportamentos mostrados no gráfico a seguir:

Dito isso, sempre que vou contratar alguém me recordo do exercício abaixo, em que o quadrado representa o tamanho do desafio e a pessoa representa a capacidade do profissional.

Alguém com capacidade menor que os desafios do cargo

 

Prós: é um profissional que ficará motivado para melhorar durante bastante tempo. Terá espaço para crescer e desenvolver suas habilidades.

Contras: profissional pode se desmotivar se não tiver apoio e se a demanda por resultados for de curtíssimo prazo. O tempo para que o profissional performe de forma razoável é maior.

Quando usar: quando a empresa confiar na capacidade de crescimento do profissional e tiver tempo para esperar o atingimento da melhor performance e resultados. Também é indicado que exista estrutura para apoiar e acompanhar de perto o desenvolvimento desse profissional. A autonomia dele, nesse caso, não é fator crítico porque ele já espera um acompanhamento mais próximo.

Alguém com capacidade do tamanho dos desafios do cargo

Prós: é um profissional que entrará no cargo para entregar o resultado desejado em curto espaço de tempo. Quando questionado sobre como está o trabalho, dirá que "tudo sob controle".

Contras: rapidamente este candidato pedirá por mais autonomia e desafios. Se a empresa não prover esta demanda, poderá perder o profissional.

Quando usar: quando a empresa precisa de resultado de curto prazo e já tem uma previsão de lançar novos desafios ao profissional em um curto horizonte de tempo. Como o profissional já domina o que e como fazer, um bom grau de autonomia é necessário.

Alguém com capacidade maior que os desafios do cargo

Prós: é um profissional que entrará no cargo e dará a certeza de um bom trabalho e resultado. Pode conter momentos de crises em ambientes que domina.

Contras: este profissional já assume os desafios esperando pelo próximo. Vê-se como uma solução provisória e que assumirá algo maior em breve. Se a empresa não prover esta demanda, poderá perder o profissional.

Quando usar: quando a empresa precisa de resultado de curtíssimo prazo e precisa conter uma crise ou quando não consegue um profissional mais adequado. Deve ter um horizonte de desafios maiores em curto prazo. Autonomia é essencial.

Em minha experiência, eu gosto muito de trabalhar com o primeiro caso, porém nem sempre é possível. Às vezes, o prazo ou a criticidade de um desafio demandam o segundo exemplo. Raríssimas vezes recorri ao terceiro caso, sempre como uma solução pontual para algum problema crítico.

Então, da próxima vez que alguém falar para contratar sempre seniores ao invés de juniores devido a um vídeo de futebol no Youtube, pense bem na criticidade e no prazo da missão. Além de entregar os resultados esperados nas empresas, também é missão nossa, enquanto líderes, fazer os profissionais crescerem dentro de suas capacidades.