Empresas vs. Pessoas

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Em uma das listas que eu assino, discuti com um membro a respeito de um termo que utilizei quando falava da necessidade das empresas reterem conhecimento, e como elas se tornam "REFÉNS" dos seus funcionários. Este termo "refém" foi o motivo de um debate bem interessante.

É claro que eu não acho que realmente as pequenas empresas sejam, de fato, reféns de seus funcionários. O termo é mais figurativo do que realmente literal, neste caso. O que eu falo com propriedade de quem já viveu em duas pequenas empresas (diria até microempresas) e uma média empresa, é que é preciso de qualquer forma a empresa se tornar independente se seus funcionários.

Vou dar dois casos, um de cada empresa que trabalhei:

Na empresa do meu irmão, uma legítima microempresa, o trabalho consiste em projetos arquitetônicos pelo computador (3D e 2D). Éramos eu, meu irmão, minha cunhada e o funcionário. O funcionário era a pessoa que manjava de TUDO. Ou seja, nós três chegávamos até um certo nível (digamos, modelagem 3D) e o funcionário era o resposnável por transformar aqueles objetos brancos e 3D numa fotomontagem realística. Esse processo continua sendo uma caixa preta, até hoje... ou seja, se o funcionário sair da empresa, a empresa vai pro buraco.

Nos projetos da empresa onde estou, a situação é bem parecida. Os desenvolvedores possuem todo o conhecimento dos projetos. Se perdermos os membros do grupo, perdemos todo o conhecimento adquirido.

Vejam, falamos de situação em que micro-pequenas empresas precisam sobreviver dia-a-dia ao mercado burocrático e sufocante que o governo provê... são raríssimas as empresas que conseguem parar, respirar, organizar e seguir adiante. É tudo feito sob-demanda.

Então, a solução, é claro, é fazer as "vontades" dos funcionários. Tornar a empresa atrativa para que estes se sintam satisfeitos e reconhecidos, e assim, permaneçam na empresa.

Mas isso pode ser temporário. Pode surgir uma Dell ou uma HP ou outra empresa de porte semelhante, e pagar um salário 2 ou 3 vezes maior do que o que ele recebe. As chances de perder o funcionário são enormes. Ou ninguém aqui ficaria tentado?

Enfim... eu tentei mostrar como, de forma figurativa, as pequenas empresas são sim reféns de seus funcionários. Isso é bom para as pessoas, sem dúvida. Mas para os gestores, pode vir a se tornar uma constante dor de cabeça... e se os funcionários resolvem usar e abusar disso?

Por essas e outras que eu reafirmo que o capital maior que uma micro-pequena empresa precisa atingir é o CONHECIMENTO. Tendo isso amadurecido, ela pode se dar ao luxo de valorizar as pessoas, que são, obviamente, os motores dessa complexa engrenagem.

E você? O que acha dessa relação micro-pequena empresa x pessoas? Concorda com o meu artigo? Escreva aí! :)

Abraços

Frase da semana

Um funcionário hoje, ao ser questionado por um dos meus chefes, se estaria à tarde ali no laboratório:

- Não... eu preciso comprar ração para o meu gato. Tá desde ontem sem comer!

É difícil. Se alguém achava que eu exagerava, essa aí encerra a questão!

Abração

Especialização

Hoje pude perceber outra coisa gritante lá na empresa (e no laboratório de pesquisa). A falta de especialização de atividades.

Como eu disse no post abaixo, eu tive que ajudar um funcionário que ficou responsável pela parte do software do sistema. Esse SW será usado como uma apresentação (DEMO) para um cliente... sendo que eles ficarão testando o sistema no seu local de trabalho.

O meu chefe me falou que o sistema precisava ser melhorado e me "convidou" a auxiliar o funcionário a realizar algumas mudanças. Bem, a linguagem era PHP+HTML+MySQL. Há dois anos que não mexo com isto, então estou completamente enferrujado...

O que me deixou maluco foi perceber que o funcionário sabia MUITO POUCO sobre a tecnologia. Ele começou a me mostrar o sistema e eu gelei: ele pegou o sistema de um Trabalho de Conclusão e foi adaptando "in loco" para servir às necessidades. O código é praticamente inilegível.

Mas o pior não é isso. Quando solicitei auxilio de um outro funcionário, que estava mais familiarizado com as funções em que estávamos empacados, notei a cara de espanto do responsável pelo SW ao descobrir conceitos como formulários ("Ahh, então é isso que é o POST?") e sessão ("Por isso que haviam essas variáveis de sessão? Serve pra isso é?").

POXA! Como é que pretendemos alcançar clientes com esse tipo de especialização? Mesmo sendo um laboratório de pesquisa (esse projeto é para o laboratório, não para a empresa).

Felizmente o meu chefe falou na reunião hoje que eu tenho carta branca para montar a equipe. O funcionário este, do SW, será o responsável pelo hardware (a função real dele, a qual ele tem competência) e eu deverei encontrar outras pessoas para compôr o resto da equipe.

Mas isso me fez pensar como devem existir empresas que não especializam suas equipes.

O SCRUM afirma que o ideal é termos equipes multi-disciplinares. Por exemplo: um desenvolvedor, um DBA (responsável pelo banco de dados), um testador, um analista, um engenheiro... dessa forma, teremos especialistas (ou responsáveis) para cada conceito da produção de software e/ou hardware.

Eu aposto com qualquer um leitor deste blog: duvido que você não tenha conhecido em alguma empresa que tenha trabalhado, uma pessoa que era responsável por algo que ela não fazia a menor idéia de como gerir. Se fazem isso com cargos de gerência, o que dizer com cargos operacionais?

É outra coisa que eu levantarei na reunião que teremos, em breve...

Um abraço!

Programming...

Hoje estava eu bem tranquilo na minha baia, planejando como faria a documentação do meu projeto, quando recebo uma tarefa INGRATA!

Programar :(

Tive que auxiliar um funcionário de outro projeto a modificar um outro projeto.

Estou com dor de cabeça até agora! Acho que peguei "programafobia"!!

Argh!

Feedback

Uma das coisas que eu pretendo "implantar" na empresa, após esse período de férias, é o mecanismo de feedback. Aliás, mecanismo não seria a palavra correta... eu diria CULTURA.

Se existe uma coisa que é desistimulante em qualquer trabalho é não ter um termômetro do andamento das coisas. Se os envolvidos estão insatisfeitos com sua atuação, mas não dizem nada, nós nos tornamos inseguros. Se os envolvidos estão satisfeitos e também não dizem, nós nos tornamos insatisfeitos por não termos reconhecimento.

O meu chefe é daqueles que não costuma demonstrar nada. É difícil pescar dele se ele está satisfeito ou não com o trabalho (obviamente ele não está muito). Ao mesmo tempo, eu sei que eu mesmo deveria estar falando muitas coisas para ele (as constantes indecisões e mudanças bruscas de rumo, por exemplo). A equipe também sente essa carência de feedback, é visível.

Nossas reuniões se tornam, geralmente, uma situação chata e constrangedora. Pois sentimos que todos querem falar alguma coisa, mas não falam. Fica tudo engasgado, o que não é bom... e pode até acabar a minar as relações.

Mas feedback não é só dizer o que pensa. É saber falar também. E é aí que mora o perigo.

Existe grandes diferenças entre dizer:

"Eu não estou satisfeito."

e

"Eu não estou satisfeito!!!!!!!!"

Se você se identifica com essa situação, pense seriamente em implantar essa cultura na sua empresa. Eu diria que em curto prazo já você verá mudanças positivas.

Pretendo utilizar o método proposto pelo livro "Gerente-minuto". Se você não conhece, pesquise a respeito (aqui no blog eu já publiquei algo similar!).

Um abração!

Duas sugestões (não testadas!) para disseminar conhecimento

Olá pessoal,

primeiramente desculpem por não estar postando diariamente. Mas como o meu pai está no hospital (cirurgia padrão, sem problemas) estamos às voltas com isso aqui em casa. Logo, logo tudo volta ao normal!

-----------

Sabemos que uma empresa não vive sem conhecimento. Isso significa que todas aquelas informações que foram processadas e aprendidas durante várias horas/dias/meses/anos por sua empresa, vale mais do que qualquer equipamento que você possua. Estou exagerando? Adianta ter um super-mega-multi-hiper computador se o técnico que o opera e o conhece pedir demissão? (toc-toc-toc!)

Empresas pequenas, como a que eu trabalho, acabam se tornando totalmente dependentes dessas pessoas técnicas. Conheço uma dúzia de empresas, incluindo a minha, nessa situação terrível... literalmente de vida ou morte.

Hoje estive pensando em algumas formas mais simples e "ágeis" para realizar essa disseminação do conhecimento, mesmo que seja para todos os funcionários, de forma informal (dessa forma, reduzindo o impacto de uma saída brusca de um cérebro do time).

Imaginei duas maneiras bem informais, as quais pretendo tentar implantar como experiência para visualizar o resultado. Vou analisar os aspectos que eu considero positivos e negativos, inicialmente.

VIDEO: gravar um vídeo utilizando dois tipos de recursos. Vídeo com câmera, para o caso do sistema envolver hardware. Vídeo que captura a tela do computador, caso seja só software. A idéia é o desenvolvedor ir falando sobre o sistema, seguindo um roteiro simples. Algo como aqueles tutoriais que vemos bastante por aí. A idéia principal é responder: "Se nosso vendedor quiser levar o sistema para um lugar sem comunicação, o que ele deve fazer para instalar e apresentá-lo ao cliente?". É uma forma interessante, pois a fala é muito mais acessível para os técnicos do que a escrita. E o passo-a-passo na prática também é mais explícito do que o passo-a-passo na escrita. Isso é fato.

Lado bom:
- Se torna bastante intuitivo, mesmo que o vídeo seja longo. Você vê passo a passo o que o técnico está fazendo, sem GAPS que geralmente ocorrem (um exemplo: um dos meus funcionários foi documentar o sistema dele e identificamos vários gaps. Normalmente a justificativa é: "ah, mas isso é óbvio... o operador tem que saber!").

- Evita que os técnicos tenham que escrever. Sabemos que existem duas coisas que TODOS os técnicos odeiam: documentar um sistema e ... escrever (a não ser que seja no MSN).

Lado ruim:
- É preciso um roteiro para que o "tutorial" ou "how-to" seja coerente. Precisamos tratar isso como um mini-projeto, ou seja, precisaremos de um mínimo de planejamento para obtermos um resultado satisfatório.

- Não temos a possibilidade de "buscar" por determinados assuntos, como em um documento. Não se torna um artefato de consulta rápida.

SEMINÁRIOS/WORKSHOPS: fazer uma vez a cada mês ou dois, um seminário do time em que cada um tem 10-15 minutos para apresentar o que tem realizado. Por exemplo, o cara dos testes mostra como tem feito os testes, quais sistemas envolvidos, como codifica, como testa... e fica aberto para perguntas. O cara da interface idem. O cara do sistema principal também. Seriam seminários de curta duração (uma tarde, talvez) com o intuito de forçarem eles a exporem aos seus colegas (e, consequentemente, aos gerentes e diretores) o que tem feito. Ao mesmo tempo, se for conduzido da forma correta (com um feedback positivo), essa solução ajudará os tecnicos a melhorarem suas características de comunicação, desnibição, etc. o que seria um benefício indireto para eles.

Lado bom:
- O bate-papo, mesmo que técnico, sempre é interessante e agrega muito para todos. Todos terão a oportunidade de questionar, sugerir e criticar (de forma racional) a solução apresentada.

- Promove uma melhora nas características interpessoais dos técnicos, principalmente desnibição, comunicação, apresentação, raciocínio. Isso tende a ser um excelente extra para a empresa.

Lado ruim:
- Demanda de tempo para que os envolvidos organizem suas apresentações. Técnicos geralmente fazem PÉSSIMAS apresentações. Uma sugestão? PROÍBA O POWERPOINT! Isso mesmo. Force-os a falar com um quadro branco e uma caneta... no máximo com outros artefatos como UML e afins.

- Se os envolvidos não souberem se portar, o workshop se tornará um desastre. Pessoas entediadas, desinteressadas e desistimuladas serão uma energia negativa que além de detonar o workshop, irá tornar o seu técnico ainda mais introvertido. Chefes que não sabem escutar e dar um feedback da forma correta, serão agentes inibidores e também matarão o seu técnico.


Estas são as duas sugestões que eu imaginei. É claro que existem várias outras, mas a grande maioria das pessoas encontra-se em um período em que algumas soluções como "pair programming" não podem ser aplicadas. No meu caso, se eu aplicasse este conceito, atrasaria ainda mais o projeto (embora eu considere esta técnica BEM interessante!).

E você, caro leitor, o que achou das idéias? Possui outras? Escreva aí :)

Um grande abraço

Quando o email não substitui o telefone...

Hoje aprendi mais uma lição valiosa.

Nunca, em hipótese nenhuma, marcar uma reunião por email. NUNCA! Nem tente fazer isso.

Estou querendo agendar uma reunião com todos os stakeholders importantes da empresa para planejarmos o ano de 2008 (como fizemos anteriormente, mas que não finalizamos a reunião). Contando comigo, são 7 pessoas, sendo que uma delas é externo (precisa se deslocar até nosso local).

Ah, vocês acham que estou exagerando? Então vejam o que aconteceu:

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

SEGUNDA-FEIRA: Manhã: Envio um email para todos perguntando o dia em que eles preferem fazer a reunião... se na 4a ou na 6a. Tarde: Uma pessoa responde que na sexta é o melhor dia. Outros dois respondem que sexta não poderão. Dois falam que o email em que eles estão recebendo os emails não são os que eles gostariam para este assunto.

TERÇA-FEIRA: Envio outro email questionando se sexta-feira fica bom para os demais que podem se fazer presentes. Na mesma manhã, outro desconfirma. Outro confirma a presença (o stakeholder externo).

QUARTA-FEIRA: Prefiro dar um descanso sobre o assunto, para não encher demais.

QUINTA-FEIRA: Envio um email afirmando que a partir de agora, irei marcar as reuniões por telefone e depois apenas enviarei um email com o local/data/hora/pessoas para todos envolvidos.

SEXTA-FEIRA: O cliente externo envia um email para saber se a reunião de sexta, afinal, está ou não confirmada.

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

Vejam a confusão que foi por causa do email. A

Espero que esse fato sensibilize a todos aqueles que cometem o mesmo erro que eu cometi. NUNCA, JAMAIS marque reuniões ou compromissos por email. Você vai enloquecer.

Ah, a pouco liguei para o meu chefe para falar sobre os dias em que ele tinha disponível. Parece que só na outra sexta-feira, final de tarde, eles poderão (terão uma semana cheia). Com 2 minutos no telefone eu resolvi toda questão. Sem gerar ruído ou confusão para os demais envolvidos.

Abraços!