Liderar, delegar, multiplicar.

A grande maioria dos livros aborda estes três conceitos. Se formos analisar, eles tem total razão!

Em primeiro lugar, devemos ser líderes. Nem sempre, é claro, conseguimos ser um líder exemplar, como um "monge" de James Hunter, ou um "Bernardinho". Porém, de alguma forma temos poder de liderança, e nossos subordinados nos respeitam. Com o tempo, respeitarão mais ou menos.

O grande desafio de liderar é INFLUENCIAR as pessoas. Fazer com que elas façam as coisas que você acredita que são as certas. Vamos admitir, quase todos nós sabemos que a maioria dos nossos subordinados não fazem as coisas que pedimos porque morreriam por nós. Eles fazem porque eles se sentem na obrigação com a empresa. São poucos que conseguem realmente influenciar as pessoas.

Porém, existe uma forma bem simples e corriqueira de atingir melhores resultados nessa influência: delegar e multiplicar.

O conceito de "enpowerment" é bastante atual. Delegar tarefas e funções para seus funcionários é algo que motiva e os faz sentir mais importantes para a empresa. Você já não fez isso? Obviamente você só nota mudanças a médio e longo prazo. Ninguém fica motivado e feliz ao poder decidir alguma coisa. Mas esse "auto-gerenciamento" que eles começam a adquirir, os fazem pensar mais como empresa e menos como "vontades pessoais".

E então, por fim, vem o conceito de multiplicar. Multiplicar esse "auto-gerenciamento" para todos da equipe. Para isso, você precisará de um fio condutor! E para isso, precisará primeiro identificar os grupos de sua empresa e em seguida os lideres de cada grupo.

Influencie os líderes e eles serão seu fio condutor, seu multiplicador.

Como sempre, tudo isso parece ser tão simples enquanto eu escrevo, correto? Com certeza não é. Mas tente! Procure ao menos saber quem são os seus líderes, seus formadores de opinião, dentro do seu grupo de funcionários. Se ele não for o funcionário exemplar, busque torná-lo. Todos os demais irão seguí-lo! Não custa arriscar ou tentar!

Bom, eu pensei sobre isso enquanto assisto ao filme da Globo: "O Juri", onde um dos juris está influenciando todos os demais para ter a sentença que ele quer. E adivinhe quais foram os métodos que ele utilizou? :)

Até mais, amigos!

Tá difícil

Esse janeiro tá complicado pra mim. Batemos um dos nossos dois carros aqui em casa, na véspera do Natal. O outro carro resolveu estragar logo no início do ano.

O meu pai está sem habilitação (tá renovando). Ele vai fazer uma cirurgia agora dia 18. Então fiquei de motorista dele durante um período.

Agora, pra completar, estou com uma espécie de estiramento na perna esquerda. Amanhã irei avaliar se a dor é de uma lesão é muscular mesmo ou se é algo vascular!

Catzo! Vou me benzer! Tá difícil de trabalhar em janeiro! Isso explica algumas poucas novidades aqui no blog...

Um abraço

Repositório de arquivos

Caros visitantes,

estou disponibilizando um repositório com alguns arquivos que podem ser bem úteis pra vocês!

São podcasts do Max Geringher, o podcast do Ricardo Viana Vargas onde ele fala sobre gerenciamento de projetos em pequenas empresas, arquivos sobre SCRUM (especialmente o ebook "Scrum from the trenches" que é sensacional) e os arquivos de apoio que eu criei por aqui (a dinâmica sobre SCRUM e os indexes cards).

Ah, e claro, o podcast do meu blog (que não morreu!).

Vocês podem acessar por este link do 4shared.

Quem não escutou a primeira edição do podcast (entrevista com Andre Barcaui) o link é este:

Podcast Mudando Uma Pequena Empresa - Ed 01

Aproveitem! :)

Escopo mutante... até onde deixá-lo fixo?

Admita, caro leitor. Você já viveu o desespero de ter um projeto seu com um escopo mutante.

Sabe aquele escopo que nós fechamos na fase de requisitos/concepção/introdução ? Pois é, tenha a certeza que dentro de três meses ele já terá sofrido pelo menos umas 5 alterações, sejam mínimas, sejam máximas.

É comum encontrarmos pessoas que pregam que devemos nos cercar de garantias junto ao cliente, para que este escopo seja fixo, de forma a facilitar o trabalho do desenvolvimento. Contratos, termos de compromisso/garantia, acordos formais, informais... tudo é válido para evitar que seu cliente "viaje" demais durante um projeto.

Em um mundo perfeito, essa é a melhor das situações: saber que iremos começar e acabar o projeto da forma como ele foi concebido!

Mas eu pergunto, até onde devemos fixar o escopo como imutável?

Ora, primeiramente, vamos analisar o lado do cliente. Ele está sendo pressionado pelos seus stakeholders, mercado, concorrência direta e indireta para ter algo inovador, que supere pelo menos a maioria destes itens. Fixar o escopo para um cliente assim (que eu diria que é o cliente que atendemos em 99,9% dos casos) não seria dar um tiro no pé?

Imagine a situação: a empresa XYZ contrata a empresa ABC para criar uma máquina de escrever automatizada, para superar a concorrência que aposta nas manuais. O contrato prevê a entrega do produto em 1 ano. A empresa ABC fecha com a empresa contratante um termo que deixa o escopo imutável, de forma a garantir a entrega em tempo hábil.

Com 6 meses de projeto, os computadores se popularizam e a grande maioria das empresas começam a aderir ao mundo digital. Com 9 meses de projeto, apenas 5% das empresas ainda não substituiram maquinas de escrever por computadores. Com 11 meses de projeto, esse número cai para 2%.

Ao final do período do projeto, a máquina de escrever automatizada é entregue para a empresa XYZ no prazo, no custo previsto e com a qualidade esperada.

A empresa XYZ agradece... e joga o produto no lixo.

Outro exemplo é o meu próprio projeto. Ele teve uma característica bem incomum. Ele teve como concepção inicial um sistema que auxiliaria o motorista apenas em linhas retas, através de LEDS luminosos. Um sistema bem robusto, simples e que visivelmente seria a versão 1.0 do produto.

Com 2 meses, acrescentamos a idéia de um módulo com cartão de memória para armazenar os dados.

Com 3 meses, a idéia de prover um sistema em tempo real, com a transmissão de dados via rádio.

Com 5 meses de projeto, este escopo já havia mudado de tecnologia 3 vezes.

Com 7 meses, descobrimos que apenas andar em linhas retas não adiantaria, pois o usuário final não poderia utilizar apenas isso. Acrescentamos ao escopo as linhas curvas.

Com 8 meses, descobrimos que existem várias tipos de linhas curvas. Decidimos incorporar dois dos quatro tipos existentes.

Com 10 meses, decidimos acrescentar um painel LCD para apresentar gráficos e mapas, em tempo real.

Com 11 meses, percebemos que não cumpriríamos o escopo daquele momento. Cortamos algumas coisas críticas.

Com 14 meses, percebemos que a tecnologia que iríamos usar, não garantiria a precisão que prevíamos.

Com 15 meses, esquecemos as linhas curvas.

Atualmente, estamos prevendo entregar exatamente o que foi previsto no escopo inicial!

No nosso caso, diversas mudanças de escopo foram feitas apenas pela síndrome da JAQUE: "Já que iremos fazer isso, por que não criamos linhas curvas?"... "Já que iremos fazer linhas curvas, por que não criamos gráficos?"...

Outras mudanças foram por necessidades de mercado, como as linhas curvas.

Mas no fim das contas, o nosso escopo foi tão mutante, tão mutante, que em determinados momentos nossa moral chegou ao fim do poço, pois não sabíamos mais o que estávamos fazendo e tínhamos a certeza de que não cumpriríamos os prazos.

Um dos conceitos interessantes do SCRUM, é que trabalhamos com funcionalidades do sistema. E o cliente pode acrescentar quantas funcionalidades quiser, desde que ele saiba que estará impactando no projeto e poderá escolher substituir ou repriorizar as funcionalidades. Tudo de forma simples e bastante clara.

O que eu concluo disso é o seguinte: NUNCA fixe o seu escopo, a não ser que seja um projeto de curtíssimo prazo. Mas ao mesmo tempo, SEMPRE cuide para que as mudanças de escopo tenham fundamentos. Mudar só por mudar, é dar um tiro de espingarda no pé!

Um abração

Como não aconteceu nada de importante hoje?

Capaz, estou louco!

Hoje tivemos a apresentação da nossa primeira DEMO (prototipada) do sistema. E foi um sucesso, aparentemente (ainda não conversei com o meu chefe para ver o que ele achou).

Mas tudo o que esperávamos, no momento, do sistema, foi feito! Agora basta aparar as arestas e torná-lo um produto. E teremos finalmente uma versão 1.0 do sistema!!

Aleluia, irmãos :)

Um erro e um acerto em 2007

Vou aproveitar que o assunto anda um pouco curto (dia-a-dia sem muitas novidades) e vou fazer uma análise do meu maior erro e maior acerto em 2007.

O MAIOR ERRO: Motivar pelo $$$

Sem dúvida nenhuma, o maior erro que eu considero neste ano foi o de achar que a motivação se faz com um aumento de salário.

Lembro o dia em que demitimos um integrante da equipe, pois ele era daquelas pessoas que atrapalhava o projeto ao invés de ajudar. Com isso, a verba liberada para ele ficaria sobrando. Decidi então conversar com a equipe explicando que eles poderiam escolher: ou dividiam este valor entre eles, mensalmente, ou então contrataríamos uma nova pessoa. A opção da divisão acarretaria em mais responsabilidades, que eles, óbvio, prometeram assumir.

Então a curtíssimo prazo, vemos aquele aumento da motivação. Começam a trabalhar mais empolgados, com mais afinco, enfim. Lá por uma ou duas semanas, começamos a ver que tudo volta ao normal. E eu avisava que eles teriam mais responsabilidades... mas era uma cobrança fraca, por assim dizer.

Resultado: comprometemos uma verba com um aumento de salário e que não trouxe NENHUM benefício para o projeto. Ao contrário, evitou que pudessemos contratar outra pessoa. É aquela coisa: aumentar o salário motiva a curtíssimo prazo. Reduzir o salário desmotiva a longo prazo.

Portanto, a lição que eu aprendi, na marra, é que NUNCA UTILIZE $$$ PARA MOTIVAR SEUS FUNCIONÁRIOS. Isso não adianta... não se torna algo tangível para eles, no dia-a-dia. Tenha a certeza que esta é a pior forma de motivação.


O MAIOR ACERTO: Foco na agilidade

Quando li pela primeira vez sobre o SCRUM, na revista MundoPM, fiquei impressionado com a simplicidade das práticas e com o resultado que era "promovido" pelo artigo. Com base naquele artigo, implantei um processo (que depois descobri que era apenas similar ao SCRUM) de agilidade na empresa. Isso está descrito em alguns posts lá de agosto, setembro.

A simples publicação das atividades em um painel e as reuniões diárias, já foram excelentes para motivar o grupo. Além disso, a possibilidade de eles falarem o que estava bom e ruim na empresa, foi um fato que os deixou bem à vontade. Aquela mudança mexeu com todos nós.

Eu me senti mais motivado, na esperança de que o projeto finalmente sairia do atoleiro. E a equipe se sentiu com mais "empowerment", com capacidade de também decidir "oficialmente" nos processos e resultados.

O grande problema, é claro, é vender essa idéia para a diretoria. Foi um caminho duro, árduo, até porque eles não conviviam conosco no dia-a-dia para sentirem a mudança. Foi apenas com a nossa mudança física da empresa para o laboratório (o que causou um impacto muito negativo na produtividade) que eles puderam acompanhar o dia-a-dia do pessoal. Infelizmente, como eu disse, o impacto negativo de voltar ao clima "estudantil" de um laboratório de pesquisa acabou por exterminar com nossa mudança.

Até que eu acabei fazendo o curso de SCRUM, de fato. Então pude novamente injetar uma mudança de paradigma neles, agora da maneira correta. E o resultado foi bem animador, mas infelizmente veio tarde... teríamos apenas dois ou três sprints até o fim do projeto, então resolvi fazer apenas um para ver no que daria.

Sem dúvida nenhuma, a possibilidade de eles acompanharem da forma correta as atividades pendentes, o progresso da equipe (no sprint burndown) e a diretoria podendo ver o número de requisitos que eles queriam no sistema, contribuiram para que o projeto entrasse aos poucos nos trilhos.

Hoje, posso dizer que o próximo projeto o SCRUM estará presente. O conceito de agilidade é excelente, mas é preciso adequá-lo ao clima do laboratório e da empresa (ambas mais conservadoras). Esse será um belo desafio para mim, neste ano de 2008.

-------------

Concluindo: note como ambas as formas mexeram com a motivação da equipe. Vendo assim, vocês realmente acham que precisamos aumentar a folha de pagamento para obter comprometimento e motivação do pessoal?

Um grande abraço!

A hora certa

Caros,

este post surgiu enquanto eu pensava com meus botões no trabalho, hoje. Acredito que a grande maioria dos leitores irão se identificar com isso...

Como eu havia dito, minha equipe encontra-se num estado totalmente "'à vontade". Não tem controle de horário, acessam a internet o tempo que querem, comprometimento está afetado, o foco não é dos melhores... e o resultado, claro, é dos piores.

Pretendo mudar isso, é lógico. Minha idéia é sentar com eles, explicar as mudanças e avisar que a partir daquele dia irei esperar uma mudança de postura e atitude de todos nós (sim, eu inclusive). Então me deparo com a expressão que entitula este post: a hora certa.

Você já percebeu como que para tudo nós achamos que existe uma hora certa? A hora certa de mudar, a hora certa de conversar, a hora certa de fazer isso, a hora certa de fazer aquilo... mas afinal, por que fazemos isso?

A minha justificativa, para o meu caso, é até bem aceitável: na situação em que nos encontramos, com pouquíssimos resultados e um prazo nos pegando pelo pescoço, eu idealizei que aplicar uma mudança naquela hora não seria o ideal. Eu poderia acabar inserindo ruido demais na relação, na motivação, na comunicação... e consequentemente, o resultado seria visto no nosso objetivo final não atingido. Convenhamos, é uma justificativa plausível.

Mas e se essa "hora certa" começa a não ter hora pra acontecer? E se formos adiando ao máximo essa "hora certa"? E se chegarmos no final e percebermos que sim, sacudir o grupo naquele momento teria sido o ideal? Será que precisamos ser meticulosos ao ponto de achar que tudo tem uma "hora certa" para acontecer? Ou devemos ser mais instintivos e agir na primeira oportunidade?

A "hora certa" me parece um conceito bem comum e típico de quem tem um perfil de planejador, que gosta de ter uma previsibilidade, analisar riscos, avaliar possiveis resultados... mas notem que fazemos isso para situações físicas ou "metafísicas". Será que nós como "planejadores da hora certa" fazemos o certo ao levarmos esse conceito para o campo das relações humanas?

Existe "hora certa" para atingir um objetivo. Mas existe "hora certa" para exigir uma mudança de comportamento de uma equipe? Existe "hora certa" para mensurar resultados. Mas existe "hora certa" para dar um feedback a alguém?

Notem a diferença. Com pessoas, nós temos várias variáveis para considerar, se quisermos de fato. A outra pessoa aceitará bem a ação? Ela está num bom dia para receber esse feedback? Ela vai assimilar bem o que escutar? Se encontramos um "não" como resposta a uma dessas questões, começamos a achar que a "hora certa" pode esperar mais um pouco.

E assim, mesmo que na melhor das intenções, perdemos mais alguns dias vendo que nada mudou. Não seria melhor ser um pouco instintivo?

Este é um post "questionador" como você pode ver, caro leitor. É para refletirmos.... principalmente se você for como eu.

Um abração!