terça-feira, 18 de junho de 2013

Traga Tuckman para a sua vida!

Gostaria de compartilhar com vocês um overview sobre os Estágios de Tuckman.

Falando um pouco sobre Tuckman, ele se chama Bruce Wayne Tuckman, nasceu 1938 e realizou uma pesquisa sobre a Teoria da Dinâmica de Grupo.
  • Em 1965, ele publicou uma de suas teorias chamada “Estágios de Tuckman”.
  • Em 1977, acrescentou um quinto estágio, Adjourning e mais tarde Transforming.

Segundo Batman Tuckman, em seu primeiro trabalho, seu chefe lhe pediu que “desse uma olhada” em alguns estudos sobre Comportamentos em GrupoApós organizá-los começou a procurar por padrões de comportamentos que se encaixassem na maioria dos estudos. Foram 4 as etapas mapeadas: Forming,Storming, Norming, Performing, as quais definem a evolução de um grupo ao longo do seu tempo de convivência.
Trazendo para uma visão mais pragmática, ao longo das iterações, o grupo vai passar por cada um desses Estágios de Tuckman.
fsnp

Forming

Quando um grupo é montado, ele entra no primeiro estágio denominado Forming. As principais características desse estágio são a hesitação e concessão, momento o qual os membros do grupo demonstram muito otimismo e orgulho por fazerem parte de uma equipe em prol de alcançar o objetivo com excelência. Sendo assim, esses membros começam a experimentar os limites de comportamento que eventualmente serão “aceitos” pelo grupo.
É comum que durante esse estágio o Facilitador do grupo seja o referencial de líder. Assim, é imprescindível a competência de mentoring do Facilitador.
Cenários:
  1. Pouca proatividade na participação do Planejamento do Produto;
    • Fator crítico para atender as expectativas do Usuário.
    • É interessante utilizar ferramentas de Product Discovery como  Product Canvas.
  2. Individualismo no desenvolvimento de tarefas;
    • Ferramentas como o Pair Programming e Code Review devem ser sugeridas com frequência.
  3. Timidez na comunicação;
    • A comunicação deve ser motivada a todo momento pelo Facilitador.

Storming

O grupo continua no processo de autoconhecimento, entrando em Storming, que se configura quando seus membros se conscientizam das complexidades referentes ao desenvolvimento do Produto.
A convivência se torna problemática e serão travados muitos embates de cunho técnico e pessoais. A concessão dá lugar as competições movidas por questionamentos, tais como, o nível de conhecimento dos demais membros do grupo e a necessidade da substituição de alguns deles.
Dessa competição, emergem as panelinhas coligações entre os membros com maior afinidade, ensaios das primeiras normas que obviamente não são realistas, sendo logo abandonadas. Haverá também uma preocupação excessiva com a forma que o trabalho está sendo feito.
A resistência à melhoria contínua e adaptação dos processos, tornam-se um obstáculo em vista da a real eficácia do grupo em entregar o Produto.
Em resumo, os membros do grupo adquirem comportamentos mimados egoístas e vaidosos.
Bem, fazer a “travessia da tempestade” requer algum gasto de energia e perseverança. Os membros do grupo devem assumir uma postura mais profissional, aceitar riscos da convivência e, principalmente, reparar os ruídos de comunicação. Toda comunicação mal interpretada deve ser esclarecida para, então somente, retomar o curso em prol da sua maturidade.

Norming

Daí as coisas começam a se acertar, então chegamos ao Norming, um dos estágio mais fáceis de se identificar, uma vez que o grupo começa se reconciliar, surge a consciência da lealdade e responsabilidade. Um por todos e todos por um!
Continuam a existir embates, contudo são construtivos. Os membros se esforçam para administrar os conflitos, criando normas de conduta e processos coerentes à realidade de seu grupo.

Performing

Depois de muita convivência e entrosamento, alcançamos o Performing. O grupo adquiriu uma visão mais coesa dos processos e códigos de conduta aceitos por seus membros. A segurança e a previsibilidade são as principais características desse estágio.
Nesse momento, os membros estão mais disciplinados e entrosados, diminuindo o risco de assuntos paralelos que consomem os esforços do grupo. A maturidade é suficiente para estimar com maior credibilidade e entregar o Produto com maior qualidade.

Adjourning e Transforming

O Adjourning somente ocorre por motivos inerentes à existência do grupo. Nesse estágio os membros vão sendo absorvido por outros grupos até a dissolução completa do anterior, porque não faz mais sentido mantê-lo. Notem que sempre que há a saída de algum membro ou a entrada de novos, o grupo tende a rever alguns desses estágios!
O Transforming somente ocorre por motivos inerentes à entrega do Produto, ou seja, quando um novo Produto é entregue para ser desenvolvido pelo mesmo grupo.

Pessoal visto o que foi descrito no post, em qual dos Estágios de Tuckman você acha que o seu Time está agora?!
[]‘s

Fontes

domingo, 2 de junho de 2013

Opressão != Pressão

Nos dias de hoje, percebo que muita gente radicaliza quando falamos de trabalhar sob alguma pressão, então resolvi escrever sobre essa linha tênue que existe entre Opressão e Pressão.

Fazendo uma analogia com a Física representamos a Pressão com a equação:


Pressão = Força Área


Força, podemos assumir como o Esforço que estamos aplicando sobre o Projeto, que seria análogo a Área.

A pressão emerge como resultado do comprometimento do time que está envolvido diretamente com o projeto.
Demostra auto-organização e auto-gerenciamento dos times ágeis.
  • Times auto-organizados têm uma DoD bem definida, evolutiva, tendem a estimar melhor suas estórias e planejar melhor seus desenvolvimentos. Garantindo o KISSDRY e SOLID das suas entregas.
  • Times auto-gerenciáveis monitoram as descrições de suas histórias, validam se os critérios de aceitação estão coerentes e se comprometem com a meta da Entrega. Justificando o significado da expressão Scrum para atender suas entregas. Literalmente :)

Esse tipo de pressão é saudável e age como uma ligação de carbono entre os integrantes do Time, mantendo-os unidos e entrosados a cada Sprint que passa. Isso se confirma na medida que o Time avança pelos estágios de Tuckman.

Estágios de Tuckman


Opressão é o vilão da história, esse cara é responsável por criar reações desagradáveis como:
"Quem esse cara pensa que é para estar nos cobrando?"
"Como ele pode cobrar sem ao menos saber a complexidade do projeto?"
"Ah entendi, será que seu cronograma feito a 3 meses atrás representa a realidade?"
Na sociedade escravocrata do Brasil, a tarefa principal do Capitão do Mato era capturar os escravos fugitivos e puni-los. Porque eles geravam um problema de produção e sua impunidade encorajaria os outros à fazerem o mesmo. Era necessário puni-los em público para servirem de exemplo para os demais.
Percebemos que pouca coisa mudou no processo de produção. Empresas ainda mantêm seus "Capitães do Mato", cujas atribuições ainda são monitorar os funcionários através de microgerenciamento e punir os menos produtivos valendo-se da meritocracia. Embora os tempos sejam outros e os métodos de comando-controle tenham melhorado muito, infelizmente o pré-conceito "funcionários não gostam de trabalhar", se manteve.

Senhores, opressão certamente é gerada por um conflito, arrisco dizer que é desconfortável para ambos os lados, embora continue sendo a forma de gestão mais popular atualmente.

Em resumo falta bom senso na Gestão, principalmente coach das Pessoas envolvidas no processo de desenvolvimento do Produto e no entendimento das previsões de entrega do Produto que seguem o modelo incremental/adaptativo sendo monitoradas periodicamente para não frustrar as expectativas dos Sponsors além de trazê-los mais próximos do desenvolvimento do Produto.

Artigo original publicado em: http://blog.lambda3.com.br/2013/01/opressao-diferente-de-pressao/


sexta-feira, 12 de abril de 2013

domingo, 24 de março de 2013

Sua empresa está preparada para jogar os seus processos pelo ralo?

Este artigo foi publicado anteriormente no Baguete, onde foi quebrado em duas partes, devido ao seu tamanho. Sugestão: reservem 5 minutos antes de entrar por esta jornada. :-)

Pois bem, defendo aqui o ponto de vista de que precisamos estar prontos para jogar nossos processos pelo ralo. Não me entendam mal: não sou contra processos e não defendo a ausência total de processos. Apenas acredito que, muitas vezes, a forma como os utilizamos inibe a nossa capacidade de aprendizado, tornando as nossas organizações mais frágeis. 

Processos e sua origem

Segundo a Wikipedia, um processo de negócio é um conjunto estruturado de atividades ou tarefas que produzem um serviço ou um produto específico.

A ideia de processo vem do final do século XIX e foi introduzida nas organizações com a finalidade de incrementar a produtividade através da divisão do trabalho. Por décadas, muitas empresas obtiveram melhores resultados econômicos através da otimização dos seus fluxos de trabalho.
 
Organizações definem os seus processos de compras, de marketing, de vendas, de recrutamento, de call center e por aí vai. Cada processo com seus indicadores, com sua missão e com os seus subprocessos.  
 
Mas onde está o problema com os processos?
 
Para falar sobre os problemas e possíveis soluções, gostaria de apresentar dois cenários hipotéticos:
 
Cenário um. Uma equipe de desenvolvimento de software é responsável por desenvolver e colocar em produção novas funcionalidades periodicamente. O produto desenvolvido está ganhando tração e novas funcionalidades são identificadas e colocadas em produção com a maior velocidade possível. As implantações em produção ocorrem a cada duas semanas. A mesma equipe faz a análise, desenvolve, testa e implanta, trabalhando da forma que considera a mais apropriada. Nas últimas implantações, vários defeitos críticos precisaram ser corrigidos em produção depois que foram encontrados diretamente pelos clientes. Esses problemas poderiam ter sido facilmente identificados se um processo de checagem mais estrito estivesse sendo utilizado pela equipe.
 
Cenário dois. Uma equipe desenvolve um sistema de roteamento de missão crítica. Novas funcionalidades são adicionadas em versões específicas. Cada versão, depois de desenvolvida, passa para o grupo de testes, que, utilizando uma sequência muito completa de testes manuais e semi-automatizados, testa durante duas semanas o novo release antes que seja liberado para produção. Defeitos críticos dificilmente chegam em produção e, quando isso ocorre, a bateria de testes é revisada e expandida. Uma gerência preocupa-se exclusivamente com a questão da qualidade e tem um grupo dedicado à isso. Uma nova funcionalidade, depois de priorizada para desenvolvimento, demora três meses para ser implantada em produção. A empresa está perdendo rapidamente mercado para uma startup capaz de implementar novas modalidades de interconexões no seu sistema muito rapidamente. A equipe de testes não está preocupada com essa startup, pois o sistema da concorrente é repleto de defeitos inadmissíveis devido a um processo muito imaturo.
Qual dos dois problemas é mais fácil de resolver? Pois bem, já vivenciei ambos. Prefiro enfrentar o primeiro e me preocupa bastante o risco do cenário um tornar-se o dois. A forma que tento evitar esse trajeto é deixando que processos, práticas e métodos possam ser jogados pelo ralo.

A visão reducionista de que o todo pode ser explicado pela soma das partes esquece de considerar os efeitos da incerteza e a complexidade do contexto corporativo. Ao desenharmos um processo, enquadramos a nossa organização através de um modelo sequencial. Entretanto, a palavra da ordem é complexidade e não podemos ignorar o impacto que o uso de modelos inadequados gera nas nossas corporações. Enrons, Worldcoms, falta de inovação, etc. estão aí para confirmar esse ponto de vista.
 
Como se isso não fosse suficiente, uma generalização da Lei de Parkinson nos diz que as estruturas criadas tendem a se manter ocupadas. Processos estabelecidos para resolver situações de negócio em um determinado contexto podem deixar de fazer sentido, mas são mantidos pois deixam de ser um meio e se tornam um fim em si mesmos!
 
E agora, o que fazer?

Sem cair na contradição de oferecer um processo para a implantação de processos, algumas práticas tem me ajudado a desenvolver a capacidade organizacional de jogar os próprios processos pelo ralo, reforçando o foco no propósito, nas pessoas e no aprendizado corporativo. 

Vamos as práticas sugeridas:
 
1) Deixar que o processo seja estabelecido por quem o executa
 
A natureza do contexto corporativo hoje demanda conhecimento multidisciplinar. Processos de negócio envolvem muitas disciplinas. Deixar que o grupo de pessoas que conhece o negócio e conhece a parte técnica possa conversar para alinhar um bom processo de trabalho ajuda a colocar o processo a serviço no negócio e a responsabilidade pelo processo na mão do próprio grupo
 
Considerando os dois cenários apresentados no início, no lugar de priorizar o detalhamento de como os testes devem ser realizados, talvez fosse mais conveniente deixar claro qual o propósito que se busca alcançar e quais os valores relevantes para a organização. Seria loucura esperar que um testador tivesse a iniciativa de avaliar se o impacto esperado está sendo alcançado por aquilo que acabou de ser implementado? 
 
2) Estabelecer restrições (e não as regras)
 
Deixar que o processo seja estabelecido por quem o executa não significa um oba-oba. Restrições podem ser colocadas e retiradas para guiar a organização na adoção de valores chave e/ou para mitigar possíveis riscos. Estabelecer que os grupos de trabalho devem ser diversificados do ponto de vista de especialidade, pode ser uma restrição estrutural alinhada com a visão da multidisciplinaridade. Estabelecer que um novo grupo de trabalho deve centralizar todas as comunicações através do gestor enquanto está em processo de formação pode evitar que o grupo inunde o resto da empresa com os seus problemas enquanto não está preparado para determinada responsabilidade.
 
Determinar que o grupo de desenvolvimento deve incluir testadores, determinar que deve existir pelo menos um cenário automatizado para cada funcionalidade ou estabelecer que entregas devem ocorrer em produção a cada duas semanas são restrições que talvez pudessem ajudar os cenários inicialmente apresentados.
 
3) Deixar claro os níveis de autoridade
 
A hierarquia é uma forma clara e direta de delegar autoridade. Entretanto, é conveniente deixar claro o grau de autoridade sendo delegado. A falta de transparência em relação a autoridade pode criar hiatos de iniciativa ou frustrações
 
Qual a autonomia em cada um dos cenários que as equipes tem em relação a garantia de qualidade? No cenário 1, uma equipe que está sendo formada, pode ter um grau de autoridade menor em relação a decisões de qualidade, enquanto no cenário 2, uma equipe mais madura, já pode ter evoluído para um estágio mais elevado de autorização. 
 
4) Oferecer espaço para o aprendizado e reflexão
 
Boas práticas fazem ou deixam de fazer sentido de acordo com cada contexto. O aprendizado não se limita a técnicas de desenvolvimento de produto, mas envolve as dimensões comportamentais, de negócio e a própria governança. Amadurecer propósitos coporativos que reforcem a importância do aprendizado pode auxiliar no alinhamento em relação a melhoria contínua.
 
Gestores apoiando o desenvolvimento de competência das equipes permitem que as dificuldades encontradas nos cenários 1 e 2 sejam resolvidas localmente, de acordo com a realidade de cada equipe. Comunidades podem ser criadas para promover a troca dentro ou entre diferentes grupos.
 
5) Incentivar a experimentação e a mudança
 
Processos não deveriam engessar o aprendizado. O aprendizado decorre da prática e da experimentação. A experimentação deve ser incentivada, mesmo que não traga benefícios de curto prazo. As pessoas se engajam naquilo que as interessa; logo, compreender o que interessa a cada pessoa e a cada time, e alinhar os processos de negócio considerando isso geralmente melhora o grau de criatividade e inovação. Correr riscos em relação a técnicas novas e abordagens novas deve fazer parte da rotina.
 
Em ambos os cenários, as equipes poderiam ter olhado para fora para buscar inspiração no que tem funcionado bem em outras equipes. Tendo espaço para a experimentação, poderiam acabar encontrando um modelo de trabalho que permita tornar o negócio mais competitivo. A adoção de novas práticas poderia ser realizada na forma de fail-safe experiments (experimentos que podem fracassar), para não comprometer o negócio e evitar tomar decisões precipitadas.
 
6) Ter cuidado com os incentivos e métricas
 
Procurar desenvolver métricas que apoiem o aprendizado e sirvam a aqueles que buscam evidências para a melhoria dos seus próprios processos. Os incentivos extrínsecos podem prejudicar a criatividade e o grau de inovação. Amarrar os incentivos a métricas pode ser um desastre para o negócio! Bons comportamentos podem ser reconhecidos, justamente para incentivar o aprendizado, mas preferencialmente com pequenas recompensas que não possam ser antecipadas.
 
7) Gerenciar a mudança de forma abrangente
 
Ao modificar processos, considerar o efeito sistêmico, o lado emocional dos indivíduos, o efeito das interações entre as pessoas e do ambiente no processo de mudança. Nossa empresa é uma rede de pessoas diversas, cada uma com suas vontades, e não um computador que pode ser programado.
 
Todo o dito até agora poderia gerar respostas imprevisíveis em ambas as situações apresentadas inicialmente. Mas experimentar e sentir como o sistema reage é a forma de conduzir o movimento de mudança. As práticas apresentadas me ajudam a colocar os processos a serviço da experimentação e do aprendizado, auxiliando a melhorar a capacidade de adaptação e, portanto, a resiliência das equipes com as quais trabalho.
 
Gostaria de deixar claro que não sou contra processos e que não devemos necessariamente jogar todos os nossos processos fora, mas acredito que devemos desenvolver uma aptidão organizacional de colocar os processos a serviço das pessoas e dos seus relacionamentos e não o contrário.

quarta-feira, 27 de fevereiro de 2013

Valve: Uma Empresa 100% Flat

Esse post foi publicado anteriormente em blog.andrefaria.com
Valve Handbook Você já ouviu falar de uma Empresa 100% Flat (ou seja, sem nenhuma hierarquia)? Pois é, ela existe! Trata-se da Valve, isso mesmo, aquela empresa que criou o Jogo Half-Life, mais conhecido aqui no Brasil, apenas, como Counter Strike.

A Valve não tem gerentes e ninguém diz ao colaborador no que ele deve trabalhar. Ele escolhe. E depois de contratado o funcionário recebe um pequeno livro que é um guia de como as coisas funcionam lá, e sobre como ele pode se situar e descobrir formas de agregar valor à empresa. "Você foi contratado para estar constantemente buscando pela coisa mais valiosa que você pode estar fazendo".

Outro aspecto importante dessa forma de organização é que "a falta de estrutura tradicional vem com uma importante responsabilidade: todos deve esforçar-se em focar no que pensam que as metas de longo prazo da organização deveriam ser".

valve-chart

A liderança é situacional e independente de cargo.

 As mesas são móveis para que o colaborador possa trocar de lugar sempre que precisar para estar próximos das pessoas com quem precisa colaborar mais no momento.

 O feedback frequente é incentivado e anualmente são realizadas revisões em par para feedback e avaliações. As pessoas são avaliadas em quatro grupos distintos: Nível de Habililidade/Técnico, Produtividade/Resultado, Contribuição com o Grupo e Contribuição com o Produto.

 A lucratividae por colaborador da Valve é bem alta (segundo o handbook, maior que da Google, Amazon e Microsoft) e os salários são mais altos do que o padrão de Mercado.

  As Pessoas são Multifuncionais: "Dentro da Valve, nós assumimos o papel necessário para o trabalho a nossa frente. Todos somos Designers. Todos podemos questionar o trabalho uns dos outros…"

 Os Profissionais são Profissionais T (Especialistas Generalistas): "As pessoas mais bem sucedidas na Valve são muito habilidosas em um conjunto de coisas e experts em uma disciplina específica". No Handbook, há vários outros aspectos bem originais e interessantes.

Quando ao modelo flat, eu, particularmente, acredito que esse modelo de gestão completamente distribuída não funcione em todos os contextos (na verdade, acredito que nada funcione em todos os contextos). Mas, sem dúvida, na Valve funciona muito bem, e pode ser uma oportunidade para que muitas outras organizações copiem ou sejam inspiradas por esse modelo de sucesso.

  Faça o Download do Handbook no Site da Valve.

 Agradecimentos Especiais ao Cassiano Coria pela Dica da Valve.