Humanized Daily Scrum

Uma das mais efetivas e cruciais ferramentas de comunicação numa equipe ágil é certamente a Daily Scrum (conhecida também como Stand Up Meeting no XP).

Esse evento é uma reunião em pé de curto espaço de tempo (pelo Scrum Guide, 15 min) com todo o time com o objetivo de compartilhar informações sobre o projeto, inspecionar o progresso do time em direção ao objetivo da Sprint (ou do objetivo do time em geral) e identificar possíveis problemas que possam comprometer esse objetivo.

Para tanto, todos os membros do time devem responder à três perguntas objetivas.

  • O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?
  • O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?
  • Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?

O objetivo e benefícios são muito delineados no Scrum Guide que diz “Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação.”.

Meu ponto é que esse evento, na sua mais pura aplicação direta do conceito, não contempla nem permite dar atenção a um componente chave para o sucesso de projetos ágeis: o ser humano ali envolvido.

Não se chega, obviamente, a um Fayolismo da prática da Iniciativa, mas ao deixar-se de lado a preocupação com o membro “ser humano” em detrimento do membro “desenvolvedor do trabalho” acabamos por negligenciar o aspecto da atenção e empatia que é favorecida, sim, pela adoção do mindset ágil mas que se não for praticada e doutrinada diariamente tende a se tornar algo efêmero, opaco, sem real importância.

Acredito que é nessa preocupação genuína e na empatia que se fazem crescer o grandes laços de confiança, essenciais para que o time ágil consiga trabalhar no seu máximo potencial de trabalho como time. Um grupo preocupado genuinamente com seus pares é capaz de atingir patamares superiores de excelência.

Laços de confiança se criam com encontros, entendimento mútuo e respeito.

Não existem obstáculos até que você tropece neles ou alguém te avise

Um ponto chave que corrobora com isso é a resposta ao esclarecimento “Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?“. Apesar de parecer certo que os membros do time vão se encontrar após da Daily Scrum para “para discussões detalhadas, ou para adaptar, ou re-planejar, o restante do trabalho da Sprint” isso nem sempre acontece de forma natural ou nem sempre de uma forma realmente efetiva.

Nem sempre natural pois as pessoas, por mais que sejam parte de um time, sem um laço real de confiança tendem a fazer esses procedimentos no automático, formalizando algo que deveria ser na verdade uma troca de preocupações com o trabalho do par praticando sua empatia. Nem sempre efetiva, pois por mais que o time esteja afim de ajudar, a pessoa pode não estar no melhor dos seus dias, prejudicando não apenas o relato/esclarecimento mas também participando da melhor forma possível na resolução do obstáculo.

Se a pessoa não confia de verdade nos pares do seu time é grande a possibilidade dele não expor verdadeiramente um problema, seja ele técnico, seja ele de relacionamento e qualquer obstáculo que não consegue se medir no código.

A Daily Scrum Humanizada

Depois de muitas Daily Scrums comecei a rodar com um dos meus times uma versão que chamei de Humanized Daily Scrum. O objetivo dela não é apenas inspecionar e adaptar o time ao goal da Sprint. O objetivo dela é também inspecionar e fazer o time adaptar-se a ele mesmo.

Olhando sob essa perspectiva, permitimos que o time entenda que os obstáculos para atingir o objetivo da Sprint não são apenas técnicos mas também humanos. O time passa então a encarar-se, do ponto de vista humano, como uma parte que deve ser levada em conta para atingir o goal.

Para atingir esse objetivo, mudei fundamentalmente os esclarecimentos com 4 perguntas.

  1. Como eu estou me sentindo hoje?
  2. O que eu estou fazendo para ajudar o Time de Desenvolvimento atender a meta da Sprint?
  3. Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?
  4. Quem eu acho que pode me ajudar?

O objetivo e benefícios dessas perguntas são os mesmos da Daily Scrum mas adicionando a inspeção ao fator humano e a tentativa de criar e fortalecer laços de confiança entre os membros do time.

Como eu estou me sentindo hoje?

A oportunidade de permitir que a pessoa diga como ela está se sentindo antes de começar dizer qualquer coisa traz efeitos importantes no momento de uma inspeção. Quando falamos pra outra pessoa como estamos nos sentindo, tendemos a criar no outro um sentimento de empatia. Esse sentimento de empatia pode ser revelador e guiador.

“Estou num dia ruim” pode traduzir em um segundo tudo que se passou no dia anterior e o que vai se passar durante o dia. Pessoas em seus dias ruins (seja de tristeza, seja de revolta) tendem a não produzir ou não se integrarem bem num time sinérgico, na programação em par e até mesmo sozinho, imerso em seus próprios problemas.

Ações, comportamentos e cobranças que normalmente seriam efetivas ou normais no dia-a-dia do time podem ser uma tempestade para uma pessoas num dia ruim.

O objetivo dessa pergunta não é obrigar o time à compadecer-se, sentir pena ou relevar erros na execução do trabalho da pessoa. A principal preocupação com essa pergunta é permitir que o time se adapte à pessoa para que o caos não se alastre, provocando uma série de efeitos colaterais no time que pode ser até certo ponto irreversíveis do ponto de vista do relacionamento humano.

Como o time tem que se comportar quando a pessoa está num dia ruim? Conhecer o estado emocional da pessoa é importante para permitir que o time consiga se adaptar a ela. Devo falar mais calmamente? Devo relevar excessos ou picos de raiva? Se você sabe onde pisa, sabe se pode correr ou caminhar (as vezes até parar).

Quem eu acho que pode me ajudar?

As pessoas nos times nem sempre sabem o quanto elas são importantes ou o quanto representam para as outras pessoas do time. Seja devido à presença de pessoas mais experientes, seja por não se achar capaz o suficiente para ajudar em algo além dos limites da sua auto-projetada competência ou até mesmo pelo medo de se expor tecnica ou comportamentalmente, algumas vezes as pessoas ajudam na remoção do obstáculo por formalidade.

E se ao invés de esperar ajuda, as pessoas pedissem ajuda?

Essa pergunta trabalha muitos fatores comportamentais ao mesmo tempo. Se por um lado pode transparecer humildade quando uma pessoa mais experiente pede ajuda para uma pessoa mais nova, pode também traduzir-se em reconhecimento ou respeito em ambos os casos.

Na outra ponta, o reconhecimento da capacidade de poder ajudar em algo ou alguém é recompensador. Estamos falando aqui de reconhecimento real, não aquele do tapinha nas costas. Se cria um build de confiança, amizade que pode progredir pra a descoberta de uma nova sinergia, de uma admiração mutua que pode perdurar e render frutos impensáveis se a espera pela ajuda do outro fosse uma formalidade ao invés de um pedido sincero e pessoal.

Adapte-se

Essa necessidade nasceu de muita observação e leituras sobre o mindset Ágil, a forma como ela é feita hoje e os métodos/frameworks que temos. Seja o Scrum, XP ou qualquer outra forma de gerir o time, não se deve perder de vista que o principal para qualquer time funcionar (seja ele ágil ou não) é o respeito, confiança e admiração mútua entre os membros do time.

Espero que esse formato ajude ou gere insights positivos em relação a esse evento.

Hey ho.

Porque as pessoas vem antes de qualquer metodologia

Estamos em 2016. Tudo o que achávamos que sabíamos sobre Scrum, Agilidade, Lean, Kanban e afins provavelmente se consolidou ou não tem mais aquele misticismo de 6~7 anos atrás.

Com isso na bagagem, fui chamado para bater um papo para uma turma de MBA aqui no ES num workshop de Gestão da Produtividade para a turma de Gestão estratégica de pessoas sobre como desenvolvemos software na Wine.com.br.

Sou um cara que GOSTA de slides e gifs animados … muitos deles… Depois de 130 e poucos deles falando um monte sobre, apaguei 80 deles e me senti numa oportunidade mágica de re-afirmar algo que tenho (na verdade, tinhamos junto com todos) como mantras nesses últimos 7 anos de desenvolvimento de software usando métodos ágeis e tudo mais:

Pessoas > Processos

e

Pessoas felizes fazem software de qualidade que deixa clientes felizes.

Isso pode parecer tendencioso, piegas até. Mas tem uma sacada as vezes esquecida por muitas empresas que começam a adotar metodologias que prometem turbinar a produtividade, entregar ROI mais rápido ou mesmo aquelas que já estão a algum tempo utilizando-as mas ainda com aquela sensação “Eu não sinto que isso esteja/seja certo”.

O Manifesto ágil, o cerne da esmagadora pluralidade de metodologias e frameworks, afirma entre seus princípios:

  • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  • O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Olha isso: pessoas, em conjunto, indivíduos, motivados, ambiente, suporte, confiar …

Isso é usado como insumo para que o mindset ágil possa fazer sentido. Pessoas sem medo, que tem verdadeira autonomia, que conseguem lidar com diferenças, pontos de vista, e consigam trabalhar em conjunto para fazer algo acontecer.

Agora pense rapidamente em exemplos de empresas que adotaram alguma metodologia ágil e faça uma reflexão: as pessoas passaram a ter menos medo? Elas passaram a entregar com mais qualidade? Elas estão mais felizes? A metodologia ajudou elas a serem melhores como PESSOAS?

Pô. Pq as empresas investem horas de treinamento, estudos e energia ensinando metodologias baseadas nisso e esquecem-se que para dar certo as PESSOAS devem devem ser trabalhadas para trabalharem em conjunto, diariamente, de forma motivada num ambiente e suporte necessários para que elas façam seu trabalho de forma convincente?

Isso faz sentido pra você?

Imagine um jogador de poker: você pode ensinar todas as regras do jogo e todas as jogadas possíveis à ele. Mas que tipo de sucesso terá se ele não for ensinado na parte do blefe, do jogo psicológico, de tudo que está fora das regras mas que influenciará diretamente no resultado e na performance do jogo dele.

Qual o sentido do Scrum num time com pessoas que aprendem todas as regras, todas as cerimônias, mas não foram ensinadas e/ou não tem um ambiente a não terem medo, a serem pro-ativas, a terem coragem pra mudar, a controlarem seus ímpetos numa discussão, a entenderem seus papéis e lidarem com isso bem.

Por isso, acredito na importância da criação de uma cultura ágil baseada nos valores:

  • Respeito (já existente na XP)
  • Admiração/Exemplo
  • Liberdade
  • Confiança

A XP (Extreme Programming) entre outras cita alguns valores, mas depois desse tempo percebi o quanto a admiração, liberdade e confiança impactam na forma como o time adota/utiliza as ferramentas que lhe são dadas no dia-a-dia para executar seu trabalho. E mais importante: como lidam com os problemas de forma tão natural, consciente e justa.

Esse tripé é/foi responsável por alguns momentos mágicos que tive nos últimos anos e serve de base para que outros tantos valores se apoiem. Se “(…) confiar em outro é muitas vezes considerado ato de amizade ou amor entre os humanos, que costumam dar provas dessa confiança.(…)” (Wikipedia), é muito mais fácil haver eventos de admiração e permissões da liberdades que de outra forma seriam muito artificiais ou inviáveis.

Hey ho, let’s go.

Rails Rumble: Uma lição de vida

Salve todos,

Não vou ficar falando o que sempre falo: que sumi, que não tive tempo pra postar por causa da correria da Giran e blalablablba! AHE uAHEuhaeuhAE … Estou estudando bastante e agora vou ter bastante coisa pra postar por aqui. :)

Este final de semana participei do Rails Rumble 2010. O Rails Rumble é, resumidamente, um campeonato de programação que desafia as pessoas a construirem uma aplicação em Rails em 48 horas! oO E não é qualquer aplicação, pois eles avaliam beleza, estabilidade, inovação … enfim, é como se você tivesse que fazer um Twitter (ou algo tão inovador) em 48 horas. heheheh

Participei do time Shupla Hadouken dá hadouken ryu! com os brothers recursos da Giran, Almir M3nd3s (@m3nd3s), André Gligli Tagliati (@tagliati) e nosso convidado especial (e que adestrou a gente em vários lances do Rails) Reinaldo JuniorZ (@reinaldojunior).

A Giran patrocinou nosso time e mais mais dois: o Walter Fall e o Blastoise. Provemos o espaço, comida, bebida e o que foi preciso pra deixar todo mundo a vontade.

Porque falei “resumidamente”? Porque o Rails Rumble é, no final das contas, MUITO mais que uma competição.

Preparação = motivação

O  “katá” para participar do evento foi/é uma puta motivação para quem quer entrar de vez no Rails. Durante um mês o povo da Giran estudou, discutiu, leu e codou bastante em Ruby/Rails. Ver todos se mobilizando em prol de um fim comum é algo que motiva demais até o mais preguiçoso dos programadores.

É fato e até algo psicológico isso: as pessoas se transformam quando estão em grupos e é assim que avaliamos o quanto as pessoas são realmente aquilo que elas dizem ser ou que achamos que elas são. Em todas as esferas possíveis.

Estudei muito (não tanto queria), quebrei a cara, me estressei mas foi algo decisivo para meu aprendizado Railer e do pessoal do meu time:  aprenderam bastante.

Idéia saindo do papel

A aplicação que desenvolvemos foi o Cashr, um gerenciador financeiro pessoal simples. Era uma idéia que já havia implementado no Django mas que não havia levado a frente. Preguiça, falta de tempo e entusiasmo: se já tem tantas aplicações pra quem mais uma?

Foi engraçado mas um dos meninos tinha tido A MESMA idéia. A vibe foi irada e geral. Qual não foi a satisfação e alegria em ver, depois de 48 horas de codação frenética e cansaço e muitas risadas, a aplicação rodando e fazendo MUITO MAIS do que havia imaginado fazer inicialmente.

Quem quiser dar uma sacada no projeto online: http://cashr.r10.railsrumble.com/

Tá dando uns pauzin e tem umas coisas incompletas, mas foi de coração. :)

Gestão de um projeto de 48 horas = desafio!

A largada havia sido dada, todo mundo à postos … e agora? Já tinhamos a idéia do projeto na cabeça e quase saímos meio Extreme Go Horse Development se não fosse a lucidez de fazer um mini Kanban das idéias principais. Mais que uma forma de organização foi uma puta lição de desenvolver de forma ágil, coisa que acredito ser um pre-requisito muito forte para qualquer pessoa que vá participar do Rails Rumble.

Entregar uma aplicação com a pressão de 48 horas, vontade de fazer o melhor e não fazer feio foi uma das lições mais legais que tive nessa esfera. E as pessoas à minha volta também pelo que vi.

Escopamos muita coisa para pouco tempo e braços, mas valew demais todo o esforço.

Extreme Happy Hour

Desde minha época de RPG, eu não tinha oportunidade de um happy hour nerd varando a madrugada tão divertido. Compramos pizzas, 2 Red Bulls pra cada um, refri, suco, biscoitos, Mendoratos … junte tudo isso com 12 nerds tarados em programação e lesados ao extremo e você tem a combinação perfeita para uma virada de madrugada de muito riso, programação e aprendizado.

Isso tudo com direito a Twittcam (você pode ver as gravações aqui), uma flood de twitadas durante a madrugada e tudo mais. O saldo foi cansaço mas aquele sentido de trabalho quase cumprido. IRADASSO.

Um por todos, todos por um

A mobilização das pessoas, até as que não estão acostumadas em trabalhar num time Scrum ou de qualquer metodologia ágil, é impressionante. As pessoas realmente entendem o quanto seu trabalho influencia o resultado não apenas do projeto mas do que o seu colega ao lado fez.

Foi como um XP atômico: pessoas codando frenéticamente, fazendo refactoring, criticando código, complementando o código alheio. Foi sem dúvida uma experiência única no que entendo ter sido uma das mais rápidas e emblemáticas que participei e vi.

Convidamos três pessoas: além do Reinaldo Júnior, chamamos o mestre railer Roberto Soares (@bt1) e o grande André Lima (@vixlima). Muito bacana como os três se integraram aos times e principalmente fizeram a gente perceber mais uma vez como as coisas trabalham bem quando as pessoas já tem um background ágil em suas mentes. Simplesmente fantástico. :)

Eu quero, eu posso

Uma palavra que ficou na minha cabeça desde horas antes de um desafio tão tenso, que expõe demais as pessoas no sentido técnico e psicológico (é a hora das pessoas verem até onde vai seu conhecimento e até onde você é humilde o bastante pra assumir isso ou ensinar as pessoas sem mesquinharias): superação.

Codar por 48 horas (não exatamente, mas pensar nisso por mais até que isso) não é apenas uma auto-superação física ou de stress mental. É superar o medo de não conseguir entregar a tempo, de saber que existem limites seus, de respeitar os limites dos outros de verdade. Superar a constante de que não sabemos tudo o que gostaríamos ou o quanto gostaríamos.

Não é papo de auto-ajuda: o Rails Rumble me fez sim uma pessoa melhor.

Extreme learning

Já falei tanto extreme nesse post que virou buzz. Não é a toa que dizem que uma das melhores formas de aprender Rails é participar do Rails Rumble. Muito aprendizado, muito problema real acontecendo em espaço de minutos e soluções para isso surgindo no vácuo.

Várias pessoas dos times não tinham muita experiência e chegaram no final da maratona falando e demonstrando o que aprenderam de uma forma muito coesa. Impressionante como as pessoas absorvem (e não apenas deixam na cabeça por um tempo) os aprendizados em situações de pressão e decisões que influenciam a vida das outras pessoas.

E no capítulo de hoje eu aprendi …

Nesse exato momento nossa aplicação está sendo avaliada pelos juízes e já recebemos até uma nota legal. :) O que fica aqui pra frente é que os estudos continuam e a coleta de idéias para o ano que vem já começou. SIM! VOU FAZER ESSA DOIDERA DENOVO NO ANO QUE VEM!

Para quem não fez, corra: é uma experiência tão singular quando a primeira balada, a primeira bebedeira (com a ressaca) e o que quer que seja tão significante.

Para quem gostou do Cashr, vamos continuar com o desenvolvimento dele e aceitamos colaboradores para o projeto, principalmente um designer pois tivemos que nos virar haehahe aueuah e.

Simbora! 😀

#AgileBrazil 2010: Eu fui … e foi foda!

Salve pessoal,

Resumir num post apenas o impacto de um evento da importância do AgileBrazil 2010 na vida de um desenvolvedor/gestor é complexo mas vou tentar dar apenas uma pequena e humilde visão do que foi isso.

Remontando alguns fatos, a Giran hoje trabalha muito fortemente com metodologias ágeis (Scrum/XP) a mais de um ano: ou seja, desde que montamos ela. heheh Mas é com o passar dos dias, projetos, pessoas, dificuldades e experimentos é que se consegue ter as reais motivações da definição dos valores do Manifesto Ágil e das técnicas usadas para se manter uma empresa ágil…

Mas ser ágil é o quê? Implementar o Scrum, seguir tudo que o manifesto ágil prediz, fazer religiosamente todas as fases antes e durante uma sprint: não quebrar as regras que agilistas e metodologias dizem? Ou seja, respeitar o processo do início ao fim? Você se mantém assim porque sua empresa é realmente ágil ou tornou sua empresa “ágil” apenas para dar um nome mais bonito ou mais hype pro seu “processo” batido do dia-a-dia com incrementos pra tentar levantar o moral da equipe e/ou vender sua empresa como uma empresa “inovadora” ou “jovem”?

É exatamente em eventos como o AgileBrazil que a percepção em relação à isso se torna EXTRAMAMENTE palpável, visível e de um bom senso tão argumentado e lapidado que chega a ser engraçado como as pessoas e as vezes nós mesmos não conseguimos enxergar algo que está na frente do nosso nariz.

A tônica do evento foi uma: você é realmente ágil? Está nessa pela fama | grana | hype ou qualquer coisa que realmente possa fomentar algo positivo pra sua empresa? Bote a mão no coração e pergunte pra si mesmo: porque você quer ser ágil ou se acha ágil?

As flexões mentais em relação à isso foram levadas a cabo por vários dias (no meu caso por dois) e horas, ensinados, desmontados, analisados e remontados por vários e principais nomes do movimento ágil do brasil e no mundo! Sim, O Martin Fowler em pessoa abriu o início das palestras e jogou luz onde geralmente ninguém vê (ou não gosta de ver).

Com uma estrutura de tirar o chapéu, feito na PUC com uma puta estrutura, uma bolsa com caneta, bloco e até caneca, a organização foi impecável em todos os sentidos possíveis. E o networking … essa parte foi um show a parte. Como disse pros brothers da Bluesoft, é muito foda ver as pessoas fora dos quadradinhos do Twitter e ver que elas são muito mais bacanas ao vivo.

Como eram muitas palestras, eu e meus companheiros na expedição (@jeveaux o @makoto_vix) nos separamos para cobrir o máximo de assuntos. Descrever tudo o que conseguimos absorver nesses dois dias ainda está cedo e talvez vire até post mas resumidamente vi:

  • Gente usando BDD/TDD pra substituir boa parte da documentação da descrição de requisitos (coisas que o cliente quer)
  • Como otimizar bastante do processo de TDD e torna-lo mais suave
  • Como ir além no uso do kanban
  • Integrar GTD + Pomodoro + Scrum + Platão (sim, rolou até platão)
  • Nomes de vários livros e sites FODARASSOS
  • Monstros da agilidade andando ali do lado
  • Porque a Giran é ágil …
  • E porque eu quero continuar com ela SEMPRE ágil :)

Se teve partes ruins? A única parte ruim é a saudade de casa, o café que acabou MUITO rápido nos coffee breaks e o cansaço nos aeroportos. Do resto, tudo muito foda. 😀

E o que senti de verdade: é MUITO bom estar entre gigantes da agilidade e reconhecer que tenho (temos) que crescer, estudar e amadurecer muito e sempre. E ainda bem que existem eventos como esse pra irmos todo ano e continuar cada vez mais humildes, felizes … e ágeis.

\\// Vida longa e próspera a todos.

Valorize pessoas, não processos

Já dizia o Manifesto Ágil (e continua dizendo) como um mantra …

Indivíduos e interação entre eles mais que processos e ferramentas

Mas até que ponto nós, não apenas como desenvolvedores mas como pessoas, levamos à cabo como agilistas ou simpatizantes de metodologias ágeis esse princípio? Mais que isso: até que ponto temos consciência de quanto esse princípio rege não apenas processos mas todo o entorno e mais dramaticamente TUDO num projeto quando pensamos que TUDO é usado, avaliado e aprovado por outras PESSOAS.

MUITO MAIS que resultantes de desempenho, produtos de qualidade e projetos mais humanamente sustentáveis, esse princípio trabalha muito intimamente com o sucesso de uma empresa, marca e seus serviços.

Dúvida?

Meu problema com travas elétricas

Quem me conhece, ouvia muito falar uma frase quando pegavam carona comigo (um carro 4 portas) e viam que as travas estava todas manuais: “Vou levar meu carro amanhã pra consertar…“.

O problema não era inteiramente meu: apesar de ser um cara enrolado, existe um processo chamado “Agendamento” da concessionária que:

  • limitava-me a levar o carro bem cedo com um dia pré-agendado
  • me fazia deixar o carro lá e conhecer, em tese, o problema real na parte da tarde e com a possibilidade de pega-lo apenas no outro dia
  • me fazia voltar pro trabalho e sair dele pra pegar o carro de busão

Apesar de tudo, o processo funcionava bem dentro de um certo contexto, pois não precisava enfrentar fila de atendimento, com sorte eles lavariam meu carro (de grátis), seria feito por profissionais (recurso ou indíviduo?) treinados pra mexer com o meu carro e existia um prazo médio (embora pouco confiável) que poderia sair com o carro consertado no mesmo dia.

Os processos são muito importantes, principalmente em empresas de maior porte onde o padrão de qualidade do produto/serviço depende bastante de um fluxo de ações e validações que certifiquem que as coisas vão funcionar bem sempre e de um modo controlado. Em pequenas empresas e pequenos grupos de trabalho, um processo pode ser substituído em partes (ou até totalmente) por indivíduos e interações.

MESMO nas grandes empresas, ainda sim, os indivíduos e interações podem fazer uma extrema diferença na qualidade: afinal, todo processo é suscetível à inconsistências e nesse ponto o indivíduo, com sua experiência e todo tipo de qualidade pessoal, vai fazer diferença.

Então qual o problema/diferencial no processo? São os indivíduos.

Indivíduo #fail: o atendente/consultor (ou quem está na frente)

Liguei para a concessionária e fui atendido por um indivíduo que atendeu-me prontamente, mas com uma certa impessoalidade incômoda, e agendara meu atendimento para as 8:30 de um dia naquela semana. O dia chegou e o alívio/sossego/esperança de não ter que sofrer mais piadas como “[tom irônico] Amanhã né Hackin?” era tão latente que o dinheiro a ser investido na resolução do problema, naquele momento, era o de menos (não, eu não sou rico … quem pode falar coisas sobre ricos é meu amigo @makoto_vix).

Cheguei para o atendimento e o indivíduo atendente me chamou pelo horário, pelo “quem chegou primeiro?” e só depois pelo nome. A contar que não era o único ali, isso passaria batido pelo meu autruísmo exagerado se não fosse pelo tratamento recheado de “Uhun”s, de “Sei”s e sem uma resposta muito convincente ou entendível ao meu “Bom dia!” recheado de dentes: aquele estava sendo um bom dia pra mim, será que pra ele não? Seja lá qual o problema, estava diante de um indivíduo totalmente guiado pelo processo.

Um indivíduo guiado pelo processo é como estar em piloto automático: não importa o que você seja, ele esta ali apenas para dar fluxo ao processo. A dispêndio de energia e atenção se limita apenas ao que é necessário para concluir o processo. Talvez quem você é po$$a significar algo e otimizar um pouco as coisas.

O indivíduo atendente então me passou o número de meu atendimento e pediu-me para que ligasse por volta das 15:00 para saber do meu problema. Será mais econômico ao processo eu ligar para saber sobre meu carro ao invés do indivíduo? Liguei e fui informado que parte do serviço tinha sido feito (tinha pedido também pra alinhar e balancear) e que o problema das travas estava sendo concluído: eu poderia pegar o carro ao final da tarde. A esperança do produto em mãos me fez deixar pra lá uma interação linear e sem contato humano com este indivíduo.

Às 18:25 chegava na concessionária e recebo a notícia de meu indivíduo atendente que o alinhamento do meu carro não tinha sido feito e que não tinham ainda descoberto o problema real das minhas travas: de acordo com indivíduo atendente, o indivíduo técnico estava com a caixa de fusiveis e tudo mais aberto lá. Como o horário de fechamento era às 18:45, apesar de muito chateado – quase puto – resolvi esperar dizendo que precisava do carro e se talvez rolasse dele descobrir algo nesses 20 min: recebi um “talvez, mas eu acho difícil…”.

5 mins depois o indivíduo atendente me informa que o problema poderia ser que as 4 travas elétricas tinham queimado simultaneamente devido a algum curto e que o valor do conserto seria de R$ 1.000,00. Questionei como 4 travas poderiam queimar ao mesmo tempo e a resposta foi um “Eu também achei bem estranho e se quiser posso conferir com o responsável pela oficina amanhã“. Amanhã? Levei o carro sem consertar as travas e voltei para fazer o alinhamento (e perder mais tempo) dois dias depois. Estranhamente uma indivíduo atendente me ligou perguntando porque não havia levado: porque não haviam me ligado assim no mesmo dia para falar sobre meu carro ao invés de me fazerem ir até lá?

A história é meio grande propositalmente para apontar bem os detalhes do atendimento. Podemos detectar alguns problemas propiciados não pelo processo, que possivelmente não tinha problemas salvo algumas melhorias, mas pelo indivíduo que disparou as ações do processo:

  • o tratamento impessoal causou um efeito anti “Efeito UAU! de atendimento” (sou programador, mas aprendi com grandes pessoas grandes coisas – valew Márcio Gomes! – que me fizeram uma pessoa e profissional melhores): não me surpreendeu, nem encantou e isso ajudaria bastante à experiência de uso num todo. Mesmo com um resultado abaixo do esperado ou sem nenhum resultado, minha experiência de uso teria sido boa se a empatia do indivíduo envolvido diretamente em minha interação tivesse sido melhor
  • as pessoas são guiadas muito mais pela sua experiência de uso do que as vezes pelo preço: 1k poderia ser um valor justo por um serviço “especializado” se minha experiência de uso estivesse sendo boa. A insatisfação inicial gerou enfim o questionamento sobre o valor e a vontade de “pexinxar”. Quem nunca parou e comprou algo na primeira loja apenas porque o indivíduo envolvido no processo era tão bom que lhe fez sentir-se seguro com a compra.
  • o indivíduo comprometeu a confiabilidade do processo quando
    • me relatou que meu carro tinha apenas o problema das travas para resolver quando nem o alinhamento havia sido feito
    • demorou 5 mins orçar e relatar um problema que em tese não tinha sido feito nem descoberto por todo um dia mas por “mágica” foi feito em 5 min
  • o indivíduo se aproveitou dos gatilhos e ações do processo para conclui-lo mas de forma a startar apenas mais um processo para quem é dependente dele.

Então, do que adianta investir num processo bem feito se os indivíduos envolvidos na sua execução não estão “comprometidos”?

Várias empresas da área de tecnologia e desenvolvimento ainda acreditam que investir em processos seja melhor para a empresa do que investir nos indivíduos que executam esses processos. Você como empresário ou como desenvolvedor ainda acredita nisso? Tente imaginar algumas situações como:

  • Quanto do seu processo de relacionamento é otimizado pelo indivíduo que se relaciona diretamente com seu cliente, tanto na questão de prazos e requisitos quanto em tudo o que envolve o que não é diretamente relacionado ao processo mas tem TUDO para tornar a conclusão ou qualidade dele excelentes?
  • Quantas descisões são influenciadas pela empatia dos indivíduos envolvidos no processo?
  • Quanto da qualidade final do seu produto é impactado diretamente pelo indivíduo, devido às suas idéias mais que suas certificações?
  • Qual é seu melhor quantitativo de desempenho: um processo que segue seu fluxo de forma correta ou os feedbacks positivos de seus clientes em todas as esferas possíveis?
  • Como você garante que todas as etapas/ações de seu projeto estão gerando o máximo de retorno para o seu cliente? Ligações pós-atendimento de avaliação não conseguem desfazer o pior dos estragos que é a experiência de compra abaixo do UAU! ou até mesmo abaixo do mínimo aceitável para cada cliente.

Imagine-se como um cliente e todas as situações como essas que passei e pergunte-se de forma analítica, pessoal e envolvendo o que você avalia como importante num atendimento:

Na minha empresa o que me traz diferencial são os indivíduos ou meus processos?

Indivíduo #WIN: numa oficina de 5 indivíduos funcionários

Como sou brasileiro e não desisto nunca, aproveitei o feriado para procurar uma oficina. Numa cidade ao lado encontrei uma oficina com 5 indivíduos funcionários, entre eles o indivíduo dono.

Prestativo, um indivíduo funcionário me recepcionou de forma informal mas muito pessoal, perguntando como estava o dia e como poderia me ajudar. Expliquei meu problema e ele de pronto afirmou que quando uma trava parava todas paravam e poderia ser um problema no módulo. Pediu-me 10 min para que um outro indivíduo, que “mexia melhor que ele” com travas, pudesse me atender.

Esperei por 25 mins, mas com 2 ou 3 interações dos indivíduos da oficina me dizendo que não demoraria muito. O processo até aquele momento me parecia simplista e até intuitivo, mas a interação do indivíduo me trouxe uma calma do tipo “Sem problema, vou aproveitar pra ler um livro“. Findada a espera, José me deu bom dia de uma forma humilde e pessoal, abriu o painel onde ficava o módulo, mexeu pra um lado e pro outro vários fios e em 15 min ele me disse: “Deve ter rolado um curto circuito, pois a corrente chega aqui – me apontando a porta – mas as travas não funcionam. Vamos ter que trocar as 4 travas.”.

Minha experiência de uso estava sendo muito bacana, mas lembrar dos R$ 1.000,00 me deram um amargo na boca até que ele disse “O jogo de travas e o serviço fica por R$ 280,00 e você pode pegar no final do dia“. WOW!!!!!

Pára tudo …

  • Atendimento UAU!
  • Preço UAU!!
  • Prazo UAU!!!!!!

Assenti prontamente mas às 18:00, chegando com pontualidade inglesa por sorte, meu carro ainda estava faltando a ultima trava da porta. Durante os testes, um dos indivíduos dissera que o pino da porta da esquerda estava meio enpenada e a porta não tava fechando direito mas que já tinha ACERTADO ela para mim e agora estava “filet”. 40 mins depois do horário dos indivíduos e meu carro estava pronto, com teste geral de lanternas, vidros e tudo mais. Um “Boa noite” cheio de cansaço mas sincero até a ultima vogal.

O processo estava ali escancarado no final das contas:

  • Receber o cliente
  • Verificar o problema
  • Passar orçamento e prazo
  • Executar o serviço

Algo muito próximo e parecido com o da concessionária, mas o que fez a diferença COMPLETAMENTE foram os indivíduos… o José mereceu os R$ 15,00 da gorjeta pra tomar umas na sexta a noite e a oficina minha moral eterna pela ótima experiência de uso que acabara de ter.

  • o indivíduo proporcionou qualidade a um processo que prevê ações definidas mas que cobre apenas em parte a real experiência de uso de um usuário
  • o indivíduo, mais que o processo, é quem de verdade proporcionou a validação positiva do processo
  • processos são inflexíveis, lineares e o que se poderia ter de “inteligência de decisão” são nada mais que algoritmos que não se comparam à empatia e tato que um indivíduo pode ter no momento de uma venda
  • um processo não reconhece um sorriso como um feedback válido para alteração de um fluxo
  • processos podem burlar indivíduos, indivíduos podem ser burlados pros processos, mas é bem mais difícil um indivíduo burlar outro indivíduo (as vezes hahaha)

Construindo uma marca com indivíduos

Depois de tudo isso, podemos ter uma noção melhor do quanto o indivíduo pesa muito mais numa empresa que um processo. Empresas grandes e flácidas tem um grande problema quando trabalham com zilhões de funcionários e não conseguem detectar de forma enfática e hábil quando esses indivíduos fazem perder todo o processo ou pior: não conseguem enxergar quando esses indivíduos é que fazem toda a diferença no atendimento.

Podemos citar aquele garçom que você sempre procura no bar, aquele mecânico que você conhece pelo nome e não pela oficina em que ele trabalha… os indivíduos são nossa referência nos lugares em que vamos e mantemos um link de confiança e segurança. Quando temos pontos qualitativos sob a forma de indivíduos exemplares em nossas empresas, nossa empresa se torna mais pessoal, mais próxima de quem faz nossa empresa crescer: os usuários.

Agora, se a sua empresa é ainda pequena ou seu centro de produção ainda é restrito a um grupo menor, porque você ainda valoriza mais processos do que indivíduos?

É incrível como varios empresários ainda acreditam que os indivíduos são todos substituíveis, como porcentagens num planilha ou recursos no gráticos Gantt, e que os processos da empresa são o suficiente para a empresa continuar saudável … mas será que estabilidade é sinônimo de sucesso ou apenas de “acomodação”. Empresas não quantificam de forma efetiva o quanto de capital social e humano perdem quando deixam de aumentar um salário em R$ 100,00 ou proporcionar um ambiente de trabalho bacana para um indivíduo que pode representar a qualidade que seu processo tenta emular ou manter de forma artificial e não tão efetiva.

Exemplo clássico é a Giran, empresa em que trabalho e que me serve de inspiração para muito do que sempre pensei com meu sócio Jeveaux.

A Giran é construída pelas pessoas que a compõem: idéias, confabulações, inovações, melhorias de gestão, contratações e até o café que tomamos é uma decisão tomada pelos INDIVÍDUOS que temos em nosso time. Nada escapa ao julgamento das pessoas e nossos processos é quem acabam trabalhando a favor dos indivíduos e felizmente não o contrário.

O que a empresa é hoje lá fora é o reflexo do comprometimento e profissionalismo das pessoas que estão lá dentro. A “marca” Giran não é fruto de um processo admirado por todos: as pessoas admiram uma marca pelo que ela proporciona à elas. Em nosso caso, as pessoas sempre nos elogiam pela nossa abordagem, às coisas e problemas que estão à nossa volta de forma transparente, sincera e fluída. E quem faz isso são nossos indivíduos. :)

Indivíduos, Indivíduos …

Depois dessa Bíblia, a flexão mental sobre o quão importante um indivíduo é antes do processo tomou um bom rumo, mas longe de chegar ao tremendo brainstorm que isso pode se tornar dentro de sua empresa, entre seu time ou mesmo com parceiros, sócios e quem mais seja importante.

Alguns funcionários, pessoas ou “recursos” não tem a real noção do que eles são dentro de um organismo tão complexo quanto a experiência de uso que deve ser proporcionada às pessoas que se relacionam com ela.

  • um e-mail áspero de um programador, pode gerar um sentimento nada bacana com um cliente na frente
  • o modo como seus funcionários se comunicam com seus fornecedores e cliente pode estar gerando maus sentimentos
  • um “Bom dia … tudo certo” e um  “Abraço” no final de um e-mail pode fazer a diferença (para melhor ou pior)

Agora imaginou o quanto você, do outro lado da moeda, já passou por isso e sabe (sinceramente) o quanto isso fez a diferença?

Pense nisso. :)