Organize, mas...

O post de ontem foi uma pequena idéia do que entendo sobre organização e terminou com uma frase que serve, não somente para organização de papéis e emails, para várias atividades, tanto profissionais quanto pessoais:

O tempo gasto em organização normalmente se reverte em produtividade, mas se você exagerar na organização, fazendo além do necessário, aí você se tornará improdutivo, talvez até mais do que os desorganizados.

Certa vez, estava conversando com uma menina que se queixava dos seus chefes. Ela não conseguia entender porque eles não gostavam do seu trabalho, já que ela sempre fazia mais do que solicitado. Ela se dizia perfeccionista e mesmo que o chefe pedisse um rascunho, ela não conseguia entregar algo sem um acabamento bem elaborado. Eu questionei quanto tempo ela levava para fazer este trabalho perfeito e ela me disse que normalmente bem mais do que os chefes gostariam. Diante desta resposta, eu tive de falar:
- Então você não está sendo perfeccionista!!!
- Como assim? – ela perguntou.
- Se esperam que você entregue um rascunho, perfeito é entregar o rascunho, ou algo um pouco melhor, desde que não ultrapasse o tempo planejado para um simples rascunho. Se definirem que um serviço deve ser feito em até uma hora, o perfeito é fazer em no máximo uma hora, e o melhor que puder ser feito neste prazo. Se você levar cinco horas, e uma qualidade melhor naquele trabalho nada valer, é só desperdício de tempo, ou de outro modo, não está sendo perfeito.
- ...
- Se você quer ser perfeccionista, faça as coisas dentro do custo e prazo estabelecido, e dentro disso, o melhor possível.
- Nunca tinha pensado nisso. – ela comentou.

Exemplos de exagero em organização ou qualidade:
- Organizar as cadeiras de uma sala de aula de forma milimétrica, com cada cadeira exatamente em linha com a da frente e com a do lado. Ninguém notará a diferença e no mesmo instante que os alunos entrarem na sala, as cadeiras ficarão desalinhadas novamente.
- Fazer um protótipo de sistema, com todas as funcionalidades e com a aparência do produto final. Isso não é protótipo, e o produto acabado. O objetivo de um protótipo é dar uma idéia de como será o sistema, e somente uma idéia, e para isso, o tempo de desenvolvimento deve ser o menor possível. Um protótipo de uma página de internet pode ser uma imagem, e não necessariamente um site funcional.

Com o exposto, eu não estou dizendo que prazo é mais importante que qualidade, e nisso discordo de alguns administradores (em outro post eu vou detalhar mais). Eu acredito que a qualidade é muito mais importante que o prazo, desde que a qualidade faça diferença para que a receba. Vamos a um exemplo:

Você solicitou um prato e ao perguntar quanto tempo levaria, o garçom respondeu 15 minutos. Ocorreu um problema na cozinha e seu prato começou a ser preparado com muito atraso. Você prefere receber seu prato frio e cru, mas no prazo; ou perfeito e com atraso? Tenho milhares de exemplos como uma oficina, que poderia entregar seu carro com defeito, mas no prazo combinado, ou um pintor que não dá a última mão de tinta.

Quando eu pergunto aos administradores o que é mais importante: o prazo ou a qualidade, estes respondem: os dois. Não, eu digo, não pode ser “os dois”, só um. E eles respondem: “então é o prazo”. Fico muito preocupado com o que os programadores vão pensar se ouvirem isso, coisas como:

- Não vai dar tempo para testar, mas tudo bem, desde que saia no prazo.
- Não vou tentar otimizar esta rotina, pois senão posso perder o prazo.

Sempre disse para os meus colaboradores que a qualidade é mais importante que o prazo, desde que a qualidade tenha um grande benefício.

Antes de você comentar (não que eu não queira que você comente, pelo contrário, comente qualquer coisa, sempre será bem vindo), existem momentos em que o prazo é muito mais importante que a qualidade, mas estas situações são menos comuns. O prazo é importante quando existe uma restrição real para ele, com o lançamento de um produto, ou a abertura de uma loja, ou uma dependência entre projetos, etc. Mas quando um prazo é algo que alguém inventou, chutou, ou pensou que poderia ser assim, este prazo para mim não tem tanto valor quanto a qualidade.

Eu penso assim: “Um projeto entregue no prazo, mas cheio de problemas, o cliente vai lembrar e reclamar durante muito tempo”, e “Um projeto entregue com atraso, mas com alta qualidade, o cliente logo esquecerá o atraso”.

Agora voltando ao assunto de organização, vale o mesmo raciocínio: organize até o ponto que você possa encontrar:
- o que utiliza diariamente de modo quase instantâneo,
- as coisas que você utiliza com freqüência de modo rápido,
- e as coisas que você raramente você utiliza, em um tempo razoável.

Se você tentar organizar de modo a encontrar tudo de modo instantâneo, mesmo o que nunca é necessário, você estará desperdiçando seu tempo, pois este ganho de velocidade nas buscas é menor do que o que você gastará organizando.

Exemplo: Abrir uma pasta para cada assunto mínimo, pois para isso será necessário buscar uma pasta nova, gerar uma identificação para a pasta, colocar a identificação na pasta, arquivar em ordem alfabética, buscando a posição em uma gaveta com mais de 1000 mini-pastas. O ideal seria manter na gaveta um número de pastas pequeno, cada uma com um “tipo de assunto”. Além de o arquivamento ser muito mais rápido, normalmente a busca também é mais rápida, porque é mais fácil saber o nome do assunto para localizar a pasta, do que o nome de uma mini-pasta dentro de uma infinidade de outras pastas.

Penso a mesma coisa para Documentação de Sistemas, mas isso fica para outro post.

O que você acha mais importante, prazo ou qualidade? Comente!

A maioria tem que ir para o lixo

Meu pai me ensinou uma das maiores lições em relação à organização, isso quando eu ainda era um “guri”, jovem demais para entender a sabedoria daquelas palavras. O que ele me disse pareceu tão simples e óbvio que não poderia imaginar que poucas pessoas soubessem fazer as coisas daquele modo. Mesmo hoje, quando eu vejo as pessoas trabalhando, eu não consigo entender porque poucos fazem o que meu pai me ensinou, já que esse é um conhecimento muito antigo (não foi meu pai que inventou). Vejo pessoas inteligentes, como administradores, gerentes, chefes de grandes equipes, desperdiçando seu tempo com algo tão simples e que se repete várias vezes ao dia.

A frase do meu pai é simples de entender, mas muitos tem dificuldade é na sua implementação. Mesmo conhecendo-a, poucos conseguem tornar isso um hábito. Veja a frase:
- Quando você recebe um papel (pode ter sido entregue por alguém, ou uma carta recebida), de logo um encaminhamento para ela, que pode ser: lixo, arquivar, para fazer depois ou fazer agora. Leia apenas uma vez e decida na hora qual o destino, caso contrário, cada vez que você pegar este papel terá de relê-lo, e isso se repetirá várias e várias vezes, sendo que a grande maioria dos papéis é lixo.

Muitos anos depois, lendo livros sobre administração do tempo, encontrei este ensinamento e fiquei feliz por meu pai já ter me ensinado muitos anos antes, e eu já estar praticando isso em quase todas as minhas tarefas, porque esta dica do meu pai serve para papéis, mas também para muitas outras coisas.

Quando eu olho o programa de email de outras pessoas, normalmente vejo a caixa de entrada com centenas, até milhares de emails, muitos dos quais ainda não lidos.

A organização nos poupa tempo, ou de outro modo, a falta de organização nos consome muito tempo. Procure uma pessoa que tem a mesa organizada, o desktop com somente os atalhos necessários, os emails em dia, provavelmente você terá encontrado uma pessoa muito produtiva. O oposto é verdadeiro.

Vez que outra nós encontramos pessoas que dizem: “Eu me acho na minha bagunça”, doce ilusão. Para confirmar, peça para ela um papel que você sabe que está no meio de uma pilha, e veja se ela não terá de verificar um por um até encontrar o que deseja. Se puder, cronometre. Eu penso que: “Bagunça na mesa, bagunça na cabeça”.

Meu email profissional tem a caixa de entrada que é apenas de passagem. Leio a mensagem e no mesmo instante decido seu destino:
- Respondo e, ou excluo ou arquivo.
- Vai para Lixo
- Vai para Pasta de acordo com o assunto
- Vai para uma pasta chamada “Para Fazer”
Com esta atitude, sempre tenho tempo para ler todos os emails (leio até o ponto de ter certeza do seu destino, algumas vezes só o assunto basta) e nada poderá passar sem eu saber, como acontece com vários colegas que dizem: “Eu não vi isso” ou “Eu não sabia”, mas quando eles verificam, encontram emails muito importantes que ainda não haviam lido (e provavelmente nunca seriam).

Eu excluo, sem pena, a maioria dos emails, e nunca precisei de nenhum. Se fosse necessário, seria só pedir um novo envio. Mas atenção, não exclua aqueles emails que podem te comprometer, estes têm que ser arquivados em local seguro.

Eu vejo pilhas e pilhas de papel na mesa das pessoas e tenho certeza que 80% é lixo, lixo puro. Isso significa 80 % do tempo perdido procurando um papel nesta pilha, ou um email em uma caixa abarrotada de bobagens. Se você olhar estas pilhas, encontrará anúncios de supermercado já vencidos, revistas ainda embaladas que nunca serão lidas, folders de fornecedores de produtos ou serviços que a empresa nunca comprará (e se precisar, é só pedir novamente), papéis de rascunho com anotações que o autor não tem mais nem idéia do que significam, etc. Lixo puro, 80% eu disse. Dos outros 20%, provavelmente 18 ou 19% podem ser arquivados, sobrando 1 ou 2% que deveriam ter a nossa atenção.

As gavetas, estas dão até medo de olhar. É tanta porcaria que nem eles lembram o que tem. Perto de 80% é lixo. Até bolachas vencidas tem.

Tive a oportunidade de ajudar na organização de uma empresa, tanto na estrutura física quanto na operacional. Quando cheguei à estante de revistas e livros, encontrei um caos, com pilhas de revistas, várias embaladas ainda. Sugeri que conservássemos apenas as 4 últimas, e cada uma que chegasse descartaríamos a mais antiga. Foi quase uma guerra:
- Não podemos colocar no lixo, pois podemos precisar de algo que está nestas revistas – eles disseram.
- Quando alguém leu uma destas revistas? – perguntei.
- Nunca, é que não tem nada que interessa aí.
- E se vocês precisarem de alguma informação, vocês procurarão nas revistas ou na internet?
- Na internet.
- Então, podemos colocar todas no lixo, não estou certo?
- É pensando assim, parece que sim.
- Então, manteremos apenas a última revista.

Agora era a vez dos livros:
- Temos muitos livros repetidos e desatualizados, com linguagens que não são mais utilizadas. Vou doar a maioria. – falei.
- Não, estão enfeitando. Quando chega um cliente, vê este monte de livros e fica impressionado. – rebateram.
- Que cliente vem aqui?
- Quase ninguém vem aqui, mas nós gostamos deles.
- Quanto tempo ninguém pega um livro?
- Faz tempo, inclusive alguns nunca foram abertos.
Finalmente convenci-os de doar os livros e abrimos espaço nas prateleiras para organizar os CDs, os arquivos, etc.

O tempo gasto em organização normalmente se reverte em produtividade, mas se você exagerar na organização, fazendo além do necessário, aí você se tornará improdutivo, talvez até mais do que os desorganizados. Vou detalhar isso em outro post.

Você se preocupa com organização? Comente!

Você é um dos melhores?

Como citei em um post anterior, 80 % das pessoas se considera dentro dos 10 % melhores (veja Oba, sou chefe! E agora?).
Quando perguntamos a um “programador” se ele tem boa lógica e se sabe programar bem, a resposta é sempre positiva. Mas quantos passariam em um teste?

Criei o desenho abaixo como brincadeira, mas “baseado” em fatos reais. Conheci alguns programadores que quando confrontados com testes bastante simples não tinham nem idéia por onde começar. Alguns, mesmo dando os passos iniciais, que para qualquer um que realmente tivesse condições de ser programador medíocre seria o bastante para desenvolver a solução, nem assim eles conseguiam. E se julgavam programadores e provavelmente até hoje estejam por aí, criando algum monstro.

Os programadores testados não percebem que a estrela de madeira não pertence ao brinquedo de plástico.

Um dos testes bem simples que aplico algumas vezes é assim:
Criar uma função que receba três strings que podem estar preenchidas ou não, independentes uma da outra, ou seja, ou todas podem estar vazias, ou apenas uma preenchida (não necessariamente a primeira) , ou duas, ou as três. Você deve retornar uma string com a soma das três strings, sendo que o texto em cada string deve ser separado do outro por uma vírgula. Mas atenção, quando a string estiver vazia, ela deverá ser desconsiderada.
Exemplos:
“”, “”, “” => “”
“”, “segunda”, “” => “segunda”
“primeira”, “”, “terceira” => “primeira, terceira”
“primeira”, “segunda”, “terceira” => “primeira, segunda , terceira”

Se você entendeu este teste e sabe exatamente como fazer, parabéns, mas alguns passaram mais de 2 horas tentando resolver e ... nada. Um chegou a passar dois dias tentando, e eu pedi para ele fazer outra coisa para mim. Este era ótimo em tarefas repetitivas, onde não era preciso pensar, e para isso ele se pagava. Pessoa extremamente prestativa, mas que, de modo algum, poderia se considerar programador.

Pare agora e tente resolver você. Depois veja algumas soluções abaixo, feitas em VB por ser uma linguagem de fácil entendimento por programadores de qualquer linguagem.

Solução 1:
Function Soma(ByVal Primeira As String, _
        ByVal Segunda As String, _
        ByVal Terceira As String) As String
  Dim Retorno As String
  Retorno = Primeira
  If Segunda <> "" Then
    If Retorno <> "" Then Retorno = Retorno + ", "
    Retorno = Retorno + Segunda
  End If
  If Terceira <> "" Then
    If Retorno <> "" Then Retorno = Retorno + ", "
    Retorno = Retorno + Terceira
  End If
  Soma = Retorno
End Function

Solução 2:
Function Soma(ByVal Primeira As String, _
        ByVal Segunda As String, _
        ByVal Terceira As String) As String
  Soma = SomaAux(SomaAux(Primeira, Segunda), Terceira)
End Function
Function SomaAux(ByVal Atual As String, ByVal Nova) As String
  If Nova <> "" Then
    If Atual <> "" Then Atual = Atual + ", "
    Atual = Atual + Nova
  End If
  SomaAux = Atual
End Function

Solução 3:
Function Soma(ByVal Primeira As String, _
        ByVal Segunda As String, _
        ByVal Terceira As String) As String
  Dim Retorno As String
  If Primeira <> "" And Segunda <> "" Then
    Retorno = Primeira + ", " + Segunda
  Else
    Retorno = Primeira + Segunda
  End If
  If Retorno <> "" And Terceira <> "" Then
    Retorno = Retorno + ", " + Terceira
  Else
    Retorno = Retorno + Terceira
  End If
  Soma = Retorno
End Function


Você tem outra solução? Comente!

Outro dia, vi um teste de empresa para programador .Net e fiquei confuso com o que eles pretendiam com aquele tipo de pergunta. Eram questionamentos muito técnicos, como a sintaxe do comando tal, o nome do arquivo da configuração tal, o tipo de tal e assim por diante, em resumo, nada sobre lógica de programação. Parecia teste para ver se a pessoa tinha boa memória e se havia estudado, mas não se seria um bom programador ou analista. Este tipo de pergunta, qualquer um poderia buscar no Google, mas lógica, isto a pessoa tem que ter, pois não tem no Google. Este mesmo teste tinha também algumas perguntas de SQL e estas sim, eram sobre conhecimento e lógica, como solicitação para montar comandos razoavelmente complexos.

Outra empresa, tem (ou tinha) um teste para programador que apresentavam um problema onde este deveria ser resolvido com um programa na linguagem Clipper. No teste, dizia que a sintaxe na importava, apenas a lógica. Teste perfeito, pois saber a sintaxe de um comando é coisa de 5 minutos (ou menos) para achar, mas lógica, nem uma vida inteira é suficiente para algumas pessoas. O que eu verifiquei neste teste é algo que até hoje tenho dúvida: Por que será que os melhores eram os que digitavam mais rápido? Será que os que digitavam lentamente não estavam conseguindo pensar direito? Tantas dúvidas, mas esta constatação: Os melhores digitavam rápida e ininterruptamente.

Essa avaliação de quantidade de toques e capacidade de lógica me parece bastante ligada, pois os melhores que conheci digitavam com grande velocidade e quase que o tempo todo. Os “Caras”, aqueles que se acham, digitam algumas letras, param, pensam (ou algo parecido), digitam mais algumas. Somente são rápidos nas teclas durante os joguinhos, neste eles são os bons. Os “Caras” digitando parecem gagos tentando discursar.

A grande maioria das empresas não testa nada, confia que se a pessoa diz que é programador, é o que basta. Pergunto-te, meu leitor, na sua empresa, quantos ficariam se hoje fosse aplicado um teste de lógica ou de conhecimento do sistema em que trabalham?

Você concorda que os melhores podem ser identificados pelo modo que digitam? Comente!

Comida ruim? Eu gosto!

Eu sou muito exigente em relação à comida e principalmente em relação aos locais onde eu almoço ou faço lanches. Cada vez que eu julgo que a comida não estava boa ou percebo alguma falta de higiene, eu não retorno mais aquele lugar. O que eu não conseguia entender era como aquela espelunca não fechava? Por que as outras pessoas continuavam indo lá? Ou será que era apenas eu que achava a comida ruim?

Esta semana eu fui almoçar com a minha esposa e ela me deu uma dica para entender porque alguns lugares com atendimento ruim ou péssimo continuam abertos e com clientes freqüentes. A frase foi mais ou menos esta (referindo-se a um restaurante que venda comida a quilo):
- Algumas vezes eu almoço no restaurante tal, porque lá a comida não é muito boa, então eu não coloco muita comida no prato, e normalmente acaba sobrando comida. Com isso, eu economizo e também faço regime.


Puxa, pensei comigo, se minha esposa pensa assim, uma pessoa tão inteligente e que cozinha tão bem, quantos não devem pensar do mesmo modo? Se ela tem este raciocínio que eu nunca havia imaginado existir, quantas mais razões devem existir para as pessoas comerem constantemente em lugares ruins? Sei que as maiores razões devem ser: o custo, a distância, algum(a) atendente bonito(a), ou masoquismo mesmo.


Meus amigos, eu citei tudo isso para dizer o que eu pensei logo em seguida: Será que alguns clientes aceitam fornecedores ruins por alguma razão do tipo? Será que as empresas aceitam funcionários incompetentes por alguma razão que eu desconheço? Em relação a fornecedores e funcionários, eu tenho a atitude que em relação a restaurantes, isto é, nunca aceitei atendimento ruim. Os funcionários, eu chamava para conversar uma vez, se não demonstrasse melhoras, sinto muito, não queria que este estragasse os bons.

Converso normalmente com a minha esposa, que trabalha em uma empresa com vários funcionários e não conseguimos entender como os chefes mantêm funcionários tão incompetentes, e a incompetência pode ser por diversas razões, mas a maioria é aparentemente a falta de vontade de fazer o trabalho bem feito, simplesmente vontade. Nós nos perguntamos por que será que os chefes não têm uma atitude para resolver o problema? Será que eles não vêm o mal que este funcionário está trazendo para empresa? Será que eles têm medo ou vergonha ou sei lá o que para falar com o funcionário e tentar fazê-lo entender que tem que melhorar?

Uma das razões dos chefes não demitirem funcionários incompetentes é que se eles demitem alguém que eles contrataram, os incompetentes foram eles de haverem contratado alguém assim.

Mas nas conversas com a minha esposa e com outros colegas, não conseguimos entender por que os chefes demitem normalmente quem é bom e mantém outro bem pior? A única é triste razão que eu consigo imaginar é que o chefe tem medo que o bom tome o seu lugar. Isso porque eu não acredito que alguém possa ser tão bobo de não ver o que todos estão vendo, não perceber que a escolha tem efeitos muito piores do que a simples perda de um bom funcionário, mas que esta atitude é um recado aos bons como: “Não sejam tão bons”, e aos ruins: “Podem ficar tranqüilos”. A tendência destas decisões é que a equipe se tornará cada vez mais medíocre e aí, terão que torcer para que os clientes tenham alguma razão ilógica para mantê-los como fornecedores.

Você já foi demitido e sentiu-se injustiçado? Comente!

Que bagunça, vou certificar CMMI

Muito se tem discutido sobre as razões as conseqüências das certificações de Maturidade em Desenvolvimento de Sistemas, ou aquelas letrinhas que você deve estar cansado de ver como: CMM, CMMI, MPS.Br, etc.

Se você perguntar para um empresário ou para o setor comercial de uma empresa a razão da Certificação, certamente eles dirão que é para qualificar ainda mais sua equipe e seus processos, mas o que a grande maioria aponta como sendo a verdadeira razão é apenas para participação de concorrências e/ou para vender mais.

As conseqüências são desencontradas, alguns apontam uma grande melhoria nas estimativas e na qualidade geral (normalmente os empresários ou o setor de vendas), outros dizem que não serviu para nada, pois logo após a certificação tudo voltou ao normal, outros ainda dizem que só piorou, sendo tão ruim quanto antes, só que com mais burocracia.

Eu participei de um processo de certificação e o que eu vi parece coincidir com as críticas feitas. A idéia de certificar era para tentar melhorar o processo interno, ter mais controle e visibilidade, ter maior acertividade, ter maior qualidade no sistema (menos erros nos sistemas produzidos).

Eu sei que teria uma maneira bem mais rápida, barata e eficiente para resolver isso, mas a diretoria não conseguia ver, mesmo eu tendo mostrado isso durante alguns meses (vou comentar em outro post o que eu fiz para aumentar a qualidade e controle da equipe utilizando conceitos Agile). A solução que estou falando era colocar no cargo de Líder de Projeto pessoas capazes de serem Líderes de Verdade, ou seja, pessoas comprometidas com o resultado e sem melindres para cobrar o que tem que ser feito. A empresa aceitava conversas intermináveis sobre vários assuntos não relacionados ao trabalho, onde se formavam grupinhos cada vez maiores, internet, MSN, ligações particulares a todo instante, até joguinhos rolavam. Os líderes, nada faziam. Se alguém demorava uma semana para fazer algo e a mesma tarefa era feita em duas horas por outra pessoa, tudo bem, cada um tem sua velocidade... diziam (em outro post comentarei mais sobre isso).

A diretoria acreditava que uma certificação faria tudo funcionar corretamente, mas nem ela sabia cobrar o que deveria ser cobrado. Ela acreditava que um sistema de lançamento de horas trabalhadas resolveria o problema, só que ninguém utilizava este sistema, e os que utilizavam, lançavam qualquer coisa.

Foi então contratada uma consultoria que de consultoria não fez nada. Apresentou o livro do MPS e disse para nós definirmos o nosso processo, do zero. Quanta perda de tempo, quanta discussão desnecessária, pois se o consultor tivesse entregado um modelo, poderíamos apenas adaptar. Eles diziam que assim era melhor, pois faríamos um modelo perfeito para a nossa empresa. Mentira, não fizemos modelo bom, nem na versão 1, nem na 2, nem na última. Eram muitos controles desnecessários, muitos documentos gerados de forma repetida, pois nós acreditávamos que eram importantes para certificação. O nosso processo nasceu gigante, e após muitas alterações e reduções, ainda estava enorme. Muita dúvida e é claro, muita consultoria paga, bem paga para ajudar-nos nas definições. No final, tive a certeza que o objetivo de não entregar um modelo inicial era só esse: Faturar.

Então o Processo foi definido e documentado e utilizado por poucos grupos. Os outros grupos diziam: “Ainda bem que nós não temos que usar!”. Era muito trabalho extra e muita enganação também, pois os grupos não conseguiam fazer tudo que era obrigatório, então mentiam, burlavam os documentos, as atas, etc. Quando havia uma alteração na definição, o processo pedia uma infinidade de passos, independente do tamanho da alteração, coisa de no mínimo duas semanas de vai e volta de documentos e reuniões. Era evidente que ninguém seguia o processo e fazia “por baixo dos panos”. Nem o diretor, que era o maior interessado, seguia o processo que ele havia ajudado a definir, pois deixava de assinar as atas, não encaminhava os documentos, etc.

Veio a certificação e fomos aprovados. Foi o último dia que alguém usou o processo definido. Vez que outra alguém se lembra dele, mas para esta solicitação não teremos tempo para utilizar o processo, é muito demorado... dizem.

Tudo voltou ao normal, a mesma bagunça, a mesma falta de qualidade, a mesma falta de controle. Quem ganhou com isso? O setor de vendas que agora pode dizer que é certificado, os consultores e os avaliadores.

Qual a sua experiência? Comente!

Isso é chato, antes eu vou...

Hoje vou falar um pouco mais sobre Prioridades. Este assunto é tão complexo para a maioria das pessoas, pois se não fosse assim, não haveria a quantidade de livros sobre isso. Quando falo em livros sobre prioridade, penso inicialmente no livro “Primeiro o mais importante”, mas temos também livros sobre administração do tempo, decisões rápidas, organização, etc. A existência destes livros e a quantidade comprada me faz ter certeza que as pessoas não sabem como administrar sua vida e seu tempo, ou de outra maneira, não sabem priorizar.

São tantas coisas que temos, tanto profissionalmente quanto pessoais, e que nos dias atuais, poucas pessoas parecem saber diferenciar (mas isso é assunto para outro post). E daquela centena de atividades que temos ou que gostaríamos de fazer, qual a mais importante? O que percebo na maioria das pessoas é a dificuldade de parar para avaliar, isso se dá por preguiça, desinteresse, busca do prazer, fuga da dor, ... Você deve estar se perguntando: Busca do Prazer(?), Fuga da Dor (?). Logo abaixo explicarei.


Um funcionário desmotivado, com uma lista de 10 tarefas, qual a probabilidade de ele priorizar as suas atividades? Diria que quase nula. A primeira da lista será a primeira a ser feita, depois a segunda. E se você pensa que o chefe vai dar as tarefas sempre ordenadas, só posso dizer, “Bem vindo ao mundo real”. Se você perguntar para alguém, o que é prioritário em uma lista, provavelmente a resposta seja:
- Tudo é prioritário (ou Tudo é urgente).
Você já deve ter escutado isso algumas vezes, principalmente quando está junto ao cliente definindo as funcionalidades de um sistema.

Outro grave problema que eu vejo na maioria da empresas é a falta de preocupação em descobrir a causa dos problemas, e buscar apenas a correção dos erros. Eu penso que é mais importante evitar futuros erros do que passar a vida corrigindo as suas conseqüências, até porque normalmente a correção do erro é mais rápida do que reparar os problemas gerados por ele. Pode parecer para alguns sem muita experiência que isso acontece raramente, mas afirmo que não, e que depende de atitude.
Dois exemplos simples:
- Um sistema gerava um log de erros, que posteriormente eram utilizados para corrigir os dados do sistema, através de ajustes manuais. Tarefa tediosa e repetitiva. Um funcionário passou anos fazendo isso. Quando outro funcionário assumiu, ele criou um programa para ajudá-lo a analisar e corrigir os erros, mas, além disso, começou a cobrar a correção das causas dos erros mais freqüentes.
- Os bancos de dados SQL Server dos clientes constantemente chegavam corrompidos. Um funcionário buscou informações sobre o que poderia resolver o problema e descobriu que deveríamos desabilitar o Cachê de Gravação do HD, conforme recomendação da Microsoft. Testes foram feitos e confirmados. Muitos meses se passaram, e muitos outros bancos chegaram corrompidos, custando em média 3 dias para correção de cada um, alguns com perda de dados. Finalmente definiram que os Cachês deveriam ser desabilitados.

- O mais importante primeiro - eu dizia no meu prédio, quando o Síndico insistia em consertar o Portão antes de consertar o Porteiro Eletrônico. Com o portão consertado, o visitante tocava o Porteiro, e como este não funcionava, forçava o portão até que este quebrava novamente.

Quando vejo os programadores, principalmente os novinhos (eu disse principalmente), montando telas ou relatórios, normalmente eu percebo a falta de avaliação do que é importante. O que vários programadores fazem inicialmente? Deixam a tela bonita, alinham bem os campos, procuram ícones bonitos, acertam as bordas, e assim vão. Quando acreditam que está bem bonito é que começam a preocupar-se com as funcionalidades do sistema. Quase sempre, o que acontece é que uma funcionalidade obriga a reestruturação da tela, e eles param tudo para ajustar a tela novamente. E outra funcionalidade, outra reestruturação.


Mas deixe-me explicar o que quis dizer com: busca do prazer e fuga da dor. Estes dois conceitos eu vi em um livro de auto-ajuda: “Desperte o gigante interior”. Gostei muito deste livro, pois não é do tipo “Pense positivo”. Nele o autor explica como pensamos e diz que basicamente: Buscamos o prazer ou Fugimos da dor. Só que fazemos isso no curto prazo, e se pensarmos no longo prazo, mudaremos nossos hábitos. Exemplos:
- Comer muito é bom, hoje, mas me fará ficar gordo amanhã.
- Ginástica é chata, mas me ajudará a viver mais e melhor.

Razões porque os funcionários não fazem o mais importante primeiro:
- Busca do Prazer: O que é mais agradável fazer agora, como: conversar com a menina da área de testes sobre um probleminha bobo, desenvolver uma funcionalidade só para ver como ficaria, enfeitar uma tela, atender aquele cliente bacana, mas principalmente, deixam sempre para depois os problemas reais, aquelas coisas chatas de fazer, mas que tem urgência.
- Fuga da Dor: O cliente chato vai me ligar novamente para me cobrar isso, que eu sei que é bobagem, e depois eu resolvo o problema grave daquele cliente que não reclama.

E você, sabe priorizar? Estudar é sempre uma prioridade, ler outras idéias, pensar se estão corretas e avaliar se nós somos assim é muito importante para o nosso crescimento pessoal e profissional.

Você tem exemplos de falta de prioridade? Comente!

O que é prioritário?

Talvez a maior dificuldade das pessoas seja definir prioridades, tanto no emprego quanto em qualquer outra área da vida. Normalmente nós temos 10.000 coisas para fazer, e só temos condições de executar uma por vez. E agora, qual deveria ser a primeira, e a segunda, ..., e a milésima (brincadeira, veja abaixo), ...

Minha primeira sugestão é que você não deve criar uma lista com mais de 10 tarefas ordenadas por prioridade, ou um dia de trabalho, o que for menor. Você não deve perder muito tempo organizando isso, pois a cada instante aparecem novas tarefas, e você terá de rever toda a sua lista. Tendo uma lista pequena das próximas coisas a fazer, encaixar uma nova é fácil, basta ver se ela é mais importante que algum dos itens. Se não for, coloque do bolo “Ver depois”.

Agora vejamos como decidir o que é mais importante:
Se você tem duas tarefas, uma urgente e outra não urgente, qual você deverá priorizar? Provavelmente você respondeu a tarefa urgente, mas a resposta certa seria: “Depende!”.

Algumas vezes, uma tarefa é urgente, mas não é importante, como: Colocar uma firula no sistema antes do fechamento da versão, participar de uma reunião que não agregará nada, responder a um MSN de um amigo que não seja assunto profissional, entre outros. Para saber se algo é Importante, avalie-a a frase seguinte: As tarefas são importantes se você tivesse tranqüilidade de colocá-la em uma lista de atividades feitas no dia, para entregar ao seu chefe.
Bem este é um modo de avaliar a importância de uma tarefa, mas o que conta mais é qual o impacto para o futuro terá a sua execução. Uma nova funcionalidade que fará o cliente economizar tempo ou reduzir o número de erros é muito importante, mas um ícone diferente na tela de abertura não tem tanta importância, assim como otimizar uma consulta que provavelmente ninguém utiliza.

Você deve priorizar as tarefas Urgentes e Importantes, mas não deverá ficar apenas nestas, pois tarefas assim são como apagar incêndio, enquanto tarefas Importantes e Não Urgentes são construção de futuro. Tentando exemplificar, se você tem constantes reclamações de erro do cliente, e passa todo seu tempo corrigindo a conseqüência deste erro, este erro persistirá (provavelmente até os clientes abandonarem o sistema). Você deverá executar uma tarefa aparentemente “Não Urgente, mas Importante” que é descobrir a causa do erro e corrigi-la.

E aquelas tarefas que são “Não Urgentes e Não Importantes”? Essas são as preferidas pelas pessoas que não estão preocupadas com o seu trabalho, aquele tipo que acha que o importante é cumprir horário. Estas são as atividades mais prazerosas, com menos compromisso com resultados e mais simples de fazer, por isso as eleitas por vários “profissionais” de todas as áreas.

Você poderá ver mais sobre isso pesquisando no Google por "urgente mas não importante" (coloque todas as palavras entre aspas).

Independente de quantas tarefas você tem, faça cada uma de modo que não precise voltar para acertá-la logo depois. Se você fizer mal feito, sua lista nunca diminuirá. Isso lembra uma frase que li em algum lugar: “Se você não tem tempo de fazer bem feito agora, quando terá?”.

Você sabe priorizar? E o seu chefe? Comente!

Oba, sou Chefe! E agora?

Quem não tem cargo de chefia não tem idéia do que é coordenar pessoas, muito menos liderar. Conheço profissionais que dizem abertamente que não desejam o cargo de coordenador, pois sabem que não desempenharão bem este papel, mas a grande maioria deseja ser “promovido”, sem saber o que os espera.

Em uma empresa que trabalhei, acompanhava o pessoal de produção, que eram adolescentes em início de carreira. Cada vez que o líder do grupo era promovido para outro setor, um dos membros tornava-se o novo líder, e entrava um novo colaborador no grupo (normalmente o office-boy). Os coordenados sempre reclamavam do chefe, dizendo que não ajudava nas tarefas e que só queria mandar. O legal era ver que, quando este que reclamava era promovido a líder, ele passava a ter a mesma atitude que tanto criticara. Neste ponto, o círculo fechava-se, pois os novos membros passavam a criticá-lo também.

Os profissionais em geral almejam um cargo de chefia, mas dificilmente preparam-se para isso, através do estudo de assuntos ligados a: pessoas e suas personalidades, conflitos, negociação, organização, delegação, etc.

Como o livro “O monge e o executivo” apresenta, a grande maioria das pessoas acredita estar entre os 10% melhores em algumas categorias, como inteligência, capacidade, etc. Se você ainda não leu este livro, procure no capítulo “O ambiente” para verificar como as pessoas se auto-valorizam. Até algum tempo atrás, eu acreditava que as pessoas tinham a real noção de quanto despreparadas ou pouco habilidosas eram, agora eu tenho certeza que não, que todas as pessoas acham-se muito melhores do que são.

Em outro estudo, fizeram um teste com um grupo de pessoas, onde cada um respondia a determinadas perguntas. Ao final, cada um descrevia como acreditava ter se saído no teste. O resultado da pesquisa foi surpreendente para alguns (não para mim): Quem mais errou havia dito que acreditava ter acertado a maioria, e o que tinham dúvida sobre seu desempenho foram os que mais acertaram. Quanto mais seguras, menos competentes (minha interpretação).

As pessoas não se preparam para os cargos de chefia e independente disso são promovidas. Com isso, a empresa perde um bom técnico (algumas vezes, nem tanto) e ganha um péssimo chefe (normalmente).

O novo chefe (sem preparo para isso):
- Quer controlar “tudo”. É ele quem define quem vai fazer o que. Quando ele não está ou está ocupado, os funcionários que já terminaram suas tarefas ficam aguardando (e aguardando...) até ele ter tempo de encontrar uma nova tarefa. Os coordenadores com pouca prática acreditam que este controle é o que faz deles bons coordenadores.
Conseqüência: A empresa perde, pois os funcionários ficam ociosos em grande parte do seu tempo e o chefe desperdiça seu tempo em tarefas que pouco valor agrega.
Solução: Ter uma lista de tarefas onde cada funcionário, ao terminar o que estava fazendo, pudesse selecionar uma nova tarefa. O chefe deve ter como controlar quem está fazendo o que, e quanto tempo previsto para o término, mas tudo de modo mais simples possível, e somente quando necessário.

- Não sabe delegar. Os novos chefes acreditam que eles são os responsáveis por todas as decisões importantes e todas as tarefas especiais. Eles costumam não perguntar e muito menos avaliar as idéias dos seus coordenados, independente de quanto conhecimento eles tenham.
Conseqüência: decisões equivocadas e falta de foco no que é importante.
Solução: Solicitar ajuda para tomada de decisões e delegar as tarefas que não sejam sua obrigação pessoal. Controlar e apoiar a execução destas tarefas, mas sem pressão. Algumas atividades devem ser realizadas pelos coordenados, pois é isso que aumenta a motivação da equipe.

- Reclama em público e elogia em particular. Quando um colaborador faz algo errado, grita para todos ouvirem que ele é incompetente. Quando quer elogiar alguém por algo que fez, chama em sua mesa. Normalmente não elogia ninguém, pelo motivo logo abaixo.
Conseqüência: Baixa motivação da equipe.
Solução: Chamadas de atenção devem ser dadas, pois não podemos ser tolerantes com alguns erros. Elogios em público, mas somente quando realmente merecidos, senão perdem o poder de motivar.

- Tem medo de que um colaborador apareça mais que ele. Este medo faz com que os funcionários que mais se destacam sejam boicotados e algumas vezes até demitidos.
Conseqüência: O nível da equipe cai consideravelmente, pois os funcionários são forçados a trabalhar abaixo da sua capacidade.
Solução: O chefe tem que saber que o sucesso da equipe é o que importa, e se a equipe tiver sucesso, seu nome vai aparecer mais ainda. Não sou eu quem diz isso, mas grandes nomes como Jack Welch.

- Ser tolerante demais. Este é um grave problema que a maioria dos chefes não sabe lidar. Eles aceitam que seus coordenados errem constantemente, atendam mal os clientes, criem conflitos entre si, etc. Os chefes não sabem como agir, por medo ou preguiça, e esperam que um dia, por milagre, tudo se resolva;
Conseqüência: Um nível descendente de qualidade e motivação.
Solução: Ser intolerante, mas com respeito. Não deixar para amanhã o que deve ser dito ou feito hoje, e ter uma postura de não aceitar que o problema se repita. Deve tentar entender a razão e apoiar o colaborador quando necessário.

- Não aceita que o fracasso do projeto seja culpa sua. Quando um projeto é um sucesso, o chefe quer todos os louros para si, mas quando fracassa, a culpa foi do fulano ou do beltrano.
Conseqüência: Ninguém terá muito empenho em buscar o sucesso.
Solução: O que qualquer livro de administração apresenta: O sucesso é do grupo, o fracasso, sinto muito, do chefe.

- Não sabe motivar, nem dá importância para isso. Muitas vezes, nem ele mesmo está motivado. Como dito anteriormente, ele aguarda que um dia as coisas melhorem, e aí os colaboradores ficarão mais motivados...
Conseqüência: Cada colaborador faz só o que tem que ser feito para se manter no emprego, ou até sai em busca de outras oportunidades mais motivadoras.
Solução: Pesquisar (em livros, cursos, com colegas, com os próprios colaboradores) o que poderá motivar seus subordinados, e a motivação gerará uma curva ascendente de desempenho, que gerará maior motivação.

Muito antes de ser promovido a chefe, comece a estudar. Comece a prestar atenção no que você não gosta no seu chefe, mas também no que você gosta. Avalie o que você terá de aprender para não cometer os mesmos erros que ele e o que terá de estudar para conseguir ser melhor ainda nos pontos positivos dele.

Quais suas experiências? Comente!

O dono é o culpado!!!

Comentário que recebi de um amigo, que é Doutor em Informática:

Sobre teu blog, acho muito legal. Um pouco "ácido", mas infelizmente realista. É um relato cruel da realidade do mercado...
É interessante porque pelo menos os novos profissionais podem parar e pensar antes de cometer as (piii)...
Mas acho que seria interessante intercalar críticas e soluções, ou seja, criticar sim (é a função primordial do blog), mas seria importante apresentar propostas de solução.
Acho que assim ele fica mais interessante ainda.

Duas coisas sobre o comentário muito bem vindo e aceito:
- Ele citou “novos profissionais” (porque ele é professor), mas eu diria “novos e velhos”.
- Também nunca gostei apenas de críticas sem sugestão, porque criticar é muito fácil. Quando recebi o comentário, já estava preparando alguns posts com este objetivo, e acho que tenho muito para compartilhar sobre as coisas que funcionam em empresas de informática.

Quero começar recomendando o programa "Kitchen Nightmares". Após ver este programa, fica fácil perceber que pequenas alterações em alguns detalhes e atitudes fazem uma grande diferença, grande não, enorme diferença. A grande lição deste programa é que as coisas que os donos dos restaurantes têm como verdade absoluta e imutável normalmente está totalmente errada. Eles acreditam que fazem tudo certo, mas não conseguem entender porque não está funcionando. Eles acham que o menu, a decoração, o atendimento, tudo está bom, diriam até perfeito (alguns poucos tem consciência de que algo está errado, só não sabem o que). O Gordon Ramsay (que não é um cara muito delicado, e também não poderia ser, pois para conseguir fazer o que tem que ser feito, tem que ser duro e direto) chega mudando tudo, o menu, a decoração, o nome do lugar, o tipo de clientela, a estrutura do pessoal, etc. É interessante ver a briga do dono em tentar manter as coisas do jeito que ele criou, mas o Gordon não perdoa, e no final, o dono acaba concordando que era a coisa certa a fazer. A conclusão do dono vem após verificar que os clientes estão mais satisfeitos, os funcionários também e o caixa: quanta diferença.

O que podemos aprender com isso é que:
- É fácil mudar, difícil é saber o que e como.
- As pessoas não aceitam a mudança.
- As pessoas acham que sabem das coisas e não aceita a opinião de quem incontestavelmente sabe mais que elas.
- A maioria dos funcionários são mal treinados ou desmotivados e ninguém parece se preocupar.
- Não devemos ser tolerantes com os erros e problemas.
- O dono é sempre o culpado de tudo, de tudo mesmo.
Além de outras.



Uma observação aqui se faz necessária: O Gordon é intolerante com o que está errado, seja em relação à higiene, a motivação, o comprometimento, etc. Mesmo assim, não desrespeita as pessoas, apenas dá uma chamada de atenção (de um modo meio drástico algumas vezes), e após um tempo, esta pessoa se dá conta de que estava errada e pede desculpas, além de agradecer o conselho.

O programa apresenta um restaurante, mas poderia bem ser uma empresa de informática, pois estas também costumam ter uma infinidade de problemas que muitos vêem, mas ninguém faz nada. A grande diferença é que a concorrência na área de alimentação é muito grande, enquanto na área de informática ainda não. Outra diferença é que os clientes ainda não conseguem saber o que é bom e o que não é em informática. Isso faz com que o cliente acabe aceitando um software: requentado, mal feito ou até cru.

Nos próximos posts vou detalhar mais estes pontos, mas principalmente sobre a “intolerância com erros” e porque o dono é o culpado de tudo.

Você é tolerante? Comente!

Quem vamos demitir?

Vez que outra surge a necessidade de cortes na equipe. Imagine-se como chefe de 10 pessoas e tendo de cortar dois funcionários. O que você faria? Que critérios você usaria?
- Os menos capazes?
- Os de menor comprometimento?
- Os mais jovens, já que tem maior facilidade de nova colocação?
- Os de menor crescimento profissional?
- Os com menor conhecimento da linguagem que trabalham?
- Os menos enturmados?
Bom, teria uma série de parâmetros que poderiam e DEVERIAM ser utilizadas como pontuação para definir quem deve sair e quem deve ficar.

Você deve estar pensando: “Lá vem ele novamente, criticando os Caras de TI”, mas fazer o que? Tem muito programador, analista, coordenador, chefe e diretor que se acha o “Cara”, mas que raramente estuda para desempenhar bem a sua função, e não é só estudo não, e esforço, e tentar acertar todo dia, e ao final do dia perceber onde errou e pensar uma maneira de nunca mais cometer o mesmo erro. (Você faz isso? Se está lendo este texto deve fazer, pois quem é o “Cara” não lê nada de interessante!)

Hoje vou criticar os chefes, incapazes de perceber o desempenho dos seus coordenados, incapazes de avaliar quem tem potencial e quem não tem, quem tem vontade de crescer e quem não está nem aí para a empresa...

Novamente pergunto qual o critério para o corte de funcionários? O primeiro critério é aquela frase bíblica:
- Os últimos serão os primeiros!

É meu caro leitor, o critério é apenas de tempo de empresa, onde os mais novinhos são dispensados independente da sua capacidade, ou de outro modo, ficam os mais antigos, independente da sua incapacidade. Para contraria a regra, vez que outra vai um mais antigo, mas é porque deve estar merecendo há muito tempo.

Outro critério também muito utilizado é o salário, onde os mais altos são os selecionados, independente de quanto produzem. Preferem deixar dois bananas que não fazem nada e ganham X cada um e demitem um funcionário exemplar que ganha 1,5 X. Se avaliassem, perceberiam que este funcionário trabalha (e rende) muito mais que os dois bananas.

Isso só faz mal à empresa, pois dá uma mensagem de que não precisa (nem adianta) ser bom, esforçado e comprometido, pois se tiver cortes, você pode ser um dos escolhidos.


Você já foi cortado injustamente? Comente!

Não adianta ser o melhor

Logo que comecei a trabalhar, pensava que bastaria ser o melhor em alguma coisa para me destacar. Com o tempo, percebi que os melhores em alguma coisa não têm vantagem nenhuma, apenas os que vendem melhor se destacam. Falo isso em relação pessoal e empresarial.

Comecemos pela avaliação Empresarial (a pessoal fica para outro post):
Na minha ingenuidade, acreditava que um bom atendimento, um bom sistema, deixaria o cliente satisfeito, e como todos dizem, um cliente satisfeito indica. MENTIRA, um cliente satisfeito nunca indica, no máximo responde quando alguém pergunta: “Tem uma empresa que me atende bem, mas ...”. Levei tempo para entender o porquê disso, mas é algo tão obvio que até sinto vergonha de confessar:
O cliente quer você só para ele, pois se você tiver vários clientes, passará a não atendê-lo da mesma forma. E se você conseguir um cliente melhor e lhe abandonar?
É algo como uma menina, ela até pode falar que gosta do namorado para as outras, mas sempre cita inúmeros defeitos para nenhuma amiga ficar de olho.

Um amigo (grande empresário de Marketing) me disse: “Não espere por ‘A verdade surgirá’, pois ela nunca surgirá, isto é, mesmo sendo o melhor do mundo, não vai haver uma fila de clientes na tua porta se você não for ao mercado, se não anunciar e vender.” Sábias palavras...

Vi várias e várias amostras deste fato: “Não adianta ser o Melhor, tem que Vender”. Muitas empresas com produtos medíocres, com clientes insatisfeitos, com equipes incapazes de atender bem as necessidades do cliente, cobrando valores absurdos, e crescendo. Outras, com bons produtos e ótimo atendimento, remando e remando (e fechando).

Hoje tenho convicção disso, o setor de vendas é o mais importante de uma empresa de Informática. Eles podem tudo, podem dizer que a funcionalidade X estará pronta em um mês, mesmo sabendo que é impossível ser feita em menos de um ano. O cliente precisa acreditar que aquela é a solução para os seus problemas, e ele quer acreditar, como a amante acredita que um dia o seu amado deixará a esposa para ficar com ela. Depois de assinado o contrato, aí a gente pensa como vai fazer para ir empurrando o cliente com a barriga.

Meus leitores, eu não concordo com isso, acho desonesto prometer sabendo que não iremos cumprir, mas são fatos. E o cliente, sem saber o que fazer, após tentar pela enésima vez encontrar uma empresa de informática boa, aceita algumas coisas absurdas como: prazos exagerados, entregas adiadas, qualidade baixa, erros, atendimento ruim, falta de retorno, etc.

E as empresas continuam vendendo, e colocando estes clientes insatisfeitos no seu rol. Agora veja só o que acontece quando um prospect liga para um cliente deste rol:
- Bom dia, é o Sr. Fulano da empresa XYZ?
- Sim.
- É que eu tenho uma proposta do sistema “Supimpa”. Vocês utilizam este sistema?
- Sim.
- Como ele funciona? É bom?
- Sim.
- Obrigado

Como é que o Sr. Fulano dirá que não? Ele nunca assumirá que usa um sistema ruim, com atendimento péssimo, etc, muito menos em uma conversa tão rápida e superficial.

Algumas vezes precisei ligar para um prospect que utilizava um sistema concorrente. Veja o que eu fazia:
- O sistema é bom?
- Sim.
- E quando vocês precisam de alguma alteração, como fazem?
- Não, nós não pedimos alteração, é muito cara (ou leva muito tempo).
- E como vocês controlam xyz?
- Com planilhas.
- O sistema não tem?
- Tem, mas é tudo furado.

O que você pensa sobre isso? Comente!

Padrão muito louco

Em desenvolvimento de sistema, qual o tipo de tela mais comum? São aquelas telas de edição de Tabelinhas Básicas, como Status, Tipos, Grupos, etc. Estas tabelas normalmente não possuem chaves estrangeiras, somente um campo chave e mais alguns campos descrição (normalmente apenas um). Sendo assim tão simples e tão comum, deve existir uma rotina que gere estas telas, ou melhor, não deve nem ser necessária a criação destas telas, pois deve existir uma “Tela Genérica de Cadastramento de Tabelas Simples”.

Meu amigo, eu sinto te desapontar (isso se você não trabalha em empresa de desenvolvimento, pois se trabalha já sabe), mas a grande maioria das empresas leva um tempo estúpido para configurar o sistema quando precisa incluir uma nova “Tabelinha”. Este estúpido serve para descrever o tempo e o padrão de desenvolvimento.

“Entrou um novo comandante no quartel e reparou que sempre existia um soldado parado ao lado de um banco específico que ficava no meio do pátio. Após perguntar para todos no quartel o porquê, e ficar sem resposta, encontrou um velho sargento, que disse: Ah, quando pintaram aquele banco, há 15 anos, o comandante mandou colocarem um soldado de guarda para ninguém sentar nele, mas acho que era para ser somente até a tinta secar.”

Os padrões de programação de algumas empresas são assim, os “Caras” que definiram o padrão até já saíram, mas ninguém tem coragem de contestar alguns absurdos. Nem sei também se é coragem ou falta de vontade, mas acredito que tem muito “Cara” atual que nem percebem que isso não deveria ser assim.

Eu fico sem entender quando conheço uma empresa de informática que diz levar mais de 1 hora para montar uma tela de cadastro básica (normalmente este tempo ultrapassa 8 horas). Não entendo como conseguiram montar um padrão tão complexo e demorado, já que nos sistemas que desenvolvi, sempre construí bibliotecas para montagem das telas de Cadastro, e com estas bibliotecas, não levava mais de 15 minutos (normalmente menos de 2 minutos, com Inclusão, Alteração, Exclusão, Consulta, Impressão e uma tela de Pesquisa utilizada por outras telas). E quando alguém me diz que leva 8 horas e fala isso “com uma tranqüilidade”, eu fico pensando que experiência tem este “Cara” para achar isso normal?

E se você está pensando que é exceção, na minha amostragem de empresas e de programadores e outros que se dizem analistas, a maioria é assim:
- Não tem padrão para nada importante,
- Mas tem um padrão de fezes para complicar as coisas que deveriam ser simples.

Neste ponto, você deve estar pensando, se para uma coisa tão simples e comum é assim, então, como é para o resto? Nem queira saber...

Abaixo apresento o padrão de programação para ir do número 1000 ao 2000 da Av. Paulista.

Logo, novo post sobre Padrões.

E você, questiona coisas assim? Comente!

É claro que eu sou produ...(oba, chegou email)...tivo

O título deste post é uma brincadeira em relação à falsa produtividade dos “Caras” de TI. Acredito que nem eles nem o chefe deles saibam o que é produtividade ou como medi-la, e mesmo que o chefe soubesse, ficaria com medo de melindrar o colaborador se o resultado apontasse uma baixa produtividade.

- E se eu medir todos os meus coordenados e todos forem mal avaliados, como é que eu fico? Vou deixar assim mesmo e torcer para que ninguém repare...

Acredito que a principal razão da improdutividade é a falta de cobrança, e aí não estou falando em ameaças, mas o simples fato de alguém saber que está sendo avaliado o faz trabalhar com mais empenho. Mas também não adianta avaliar se isso não tiver resultado nenhum, então, vez que outra, um profissional fraco deveria ser dispensado, para manter a saúde da equipe. (Por que isso não é feito? Isso fica para outro post!)

Outra grande razão é a falta de conhecimento e capacidade dos programadores. Muitos que conheci não tinham conhecimento da linguagem que trabalhavam (e não faziam questão, já que não ganhariam mais por isso) e nem capacidade lógica de programação (e não fazia diferença, pois ganhavam tanto quanto quem tinha). (Por que isso é assim? Outro post!)

O ambiente empresarial atual fica em dúvida em como tratar os “atrapalhadores” de produtividade, que são a Web, Mensagens Instantâneas, o Celular e as Músicas (os jogos nem vou falar). Já vi muita empresa bloquear o acesso de todos porque não sabia cobrar dos “Caras” a correta utilização. Para mim, isso é tratar os programadores como crianças, ou melhor, bebês, que temos que deixar as coisas no alto do armário. Com adultos, seria apenas dizer que não pode... (Se os "Caras" fossem como adultos, não seriam os "Caras"!)

Se pensarmos em pessoas com conhecimento, capacidade e comprometidas, quais as razões para improdutividade?

A principal é a dificuldade de estabelecer prioridades. Temos diariamente uma infinidade de coisas para fazer e nunca temos tempo para todas. O que fazer primeiro? Só este pensamento, para quem não tem experiência já é um grande consumidor de tempo... (Detalharei isso em outro post.)

Uma segunda razão é a dificuldade de achar uma maneira rápida de resolver o problema, ou seja, de modo mais simples possível (veja Quanto mais complexo, melhor!).

A terceira é a falta de organização, e isso se apresenta de várias formas, basta olhar o computador da maioria das pessoas:

- Desktop lotado de ícones que não tem utilidade nenhuma ou raramente são utilizados

- Falta de atalho para os programas mais utilizados (Tarefas repetitivas, repetitivas, repetitivas...)

- Menu “Iniciar / Todos os Programas” com dezenas de entradas e fora de ordem alfabética. (Eu crio grupos como “Aplicativos”, “Desenvolvimento”, “Menos usados”, etc. Levamos um tempinho organizando, mas saiba que vale a pena, se você trabalha o dia todo no micro.)

- Mesa com centenas de papéis que não tem mais nenhuma utilidade, misturados com os que são necessários no dia-a-dia. Cada vez que precisamos de um, é uma “briga” para achar.

A quarta (e vou parar por aqui, para não me alongar) são os padrões de programação e documentação. Sobre Padrões vou falar no próximo post, mas para adiantar, existem padrões tão mal definidos, sem preocupação com a simplicidade que é impossível ser produtivo.

Você conhece outras razões para improdutividade? Comente!

Faço, mas não sei porque...

Você já deve ter visto a cena ou até participado dela (o problema é de qual lado da história você estava):
- Fulano, por que você fez isso deste modo?
- Isso, me deixa ver!... Putz, não sei!
- Mas você não tinha entendido o problema?
- Não tão bem...
- E por que você não me perguntou?
- Não sei...

Isso é o que um amigo chama de “macaquinhos”, sem nenhum sentido racista, apenas aquela simbologia do bicho que imita as atitudes humanas, mesmo sem saber para que servem. Gostei da referência, pois já encontrei muito “macaquinho” que se achava o “Cara”, mas não tinha nem idéia do que estava fazendo. Podia até ser o bom no vídeo-game, mas como programador... Fazer o que, pois como eu digo, estava empregado, bem pago, o chefe gostava dele, era bom de papo... e continuava fazendo “macaquices”.
Teste para ver se você não é um “macaquinho” (bicho que imita as atitudes humanas, mesmo sem saber para que):
- Você planeja antes de começar a escrever? (Você sabe o que é planejar, né?)
- Você documenta o que você escreveu? (Mas se nem você sabe o que está escrevendo, como poderia documentar?)
- Quando você encontra um erro, você corrige? (Não é possível que você seja do tipo que coloca um “IF x = valorerrado THEN x = valorcorreto”?)
- Você constantemente lê livros sobre a linguagem que desenvolve? (Ou Livro é aquela coisa que você usa para levantar o monitor?)
- Você conhece todos os comandos da linguagem que você utiliza? (Ou apenas aqueles 10 mais usados?)
- Quando você tem uma dúvida, você pergunta para quem sabe? (Ou pergunta para outro “Cara”, que além de saber menos que você, está pouco se importando com o seu problema, e pior, ainda aceita a opinião dele?)
- Você consegue entender (e explicar) o programa que você escreveu no mês passado? (Bom, veja bem, daí o programa pega o ...)
- Você consegue entender (e explicar) o programa que outros escrevem? (Agora complicou...)

Se você entendeu o teste, já é um bom começo...

Dizem que o macaco é um animal que aprende com facilidade, mas por que é que o ser humano não é assim também?
Você ficou gostou? (Ou ficou brabinho?) Comente!

Isso aqui não é para qualquer um

Meus amigos, o que vou dizer pode não agradar alguns, então, peço aos melindrosos que não continuem a leitura.

Se você aceitar ler, o assunto é: “Desenvolvimento de Sistemas não é para qualquer um” e você pode ser um dos excluídos (sinto muito). Quando iniciei na informática, não tinha a noção de quanto era vasta e complexa esta área, e também, não imaginava que os profissionais desta atividade deveriam ter certos pré-requisitos. Um tempo depois fui dar aula, e lá encontrei pessoas de várias idades, formações e interesses. Em certo momento, me dei conta de que, para ser um bom programador (só bom, ainda não cheguei ao ótimo), precisaria ter: vontade que move montanha (não apenas querer), gostar de resolver problemas, ser persistente (quem já montou um quebra-cabeças de 3.000 peças?), e mais algumas coisinhas. Para um ótimo desenvolvedor precisa também inteligência, ou melhor, vários tipos de inteligência.

Acho que com os requisitos acima, já reduzi a população dos desenvolvedores a 9% para bons e 1% para ótimos.

Se você pensa que eu estou errado, e que é só estudar para ser um bom desenvolvedor ou analista, acompanhe o meu raciocínio:

Quantas pessoas são capazes de correr 100 metros abaixo de 10 segundos? Você seria capaz? Duvido. Mesmo que você treinasse toda a sua vida, nunca chegaria lá. É questão de conformação física, ossos e músculos, e não apenas de vontade.

Se você não concorda comigo, pode pular para outro texto, porque daqui para diante, só vai piorar...

Como acredito que nem todos nascem com aptidão para algumas atividades físicas de alto nível, penso o mesmo para desenvolvedores e analistas, ou seja, tem que ter condições físicas também, mas não são ossos e músculos, mas neurônios.

Isso mesmo, eu acredito que alguns nascem com condições de desempenhar bem as atividades de raciocínio e outros não. E não adianta estudar e estudar, nunca vão chegar lá. Infelizmente, não temos testes para medir esta capacidade, como temos as pistas de atletismo, então, todo mundo se acha um campeão...

E você, é um profissional de alto nível? Comente!

Interface do Boobol

Uma característica marcante nos “Caras” é falta de preocupação com o usuário. O problema é dele (do usuário) se tiver que redigitar, clicar em intermináveis menus, selecionar o item quando existe apenas um, etc. Valores Default nos campos? Pra que? Ordem de tabulação eles já ouviram falar, mas não lembram o que é...

Quantas vezes já sugeri uma melhoria que levaria uns 15 ou 30 minutos para ser feita, mas que economizaria 30 segundos em cada operação. Multiplique isso por vários usuários, várias vezes ao dia, e você percebe a economia para empresa. E os “Caras” sempre perguntam, prá que? É só clicar aqui e ali e acolá, é simples – eles dizem. Falar o que?

E a área de testes, e o chefe, e o comercial, ou o próprio usuário, por que ninguém fala nada? É bem provável que um dia, alguém tenha dito alguma coisa, mas o “Cara” disse que não era possível fazer de outro jeito... Quem iria discordar? O usuário, coitado, talvez nem perceba o trabalho que está tendo porque um programadorzinho acha que não é importante se preocupar com Interface, Ergonomia, Agilidade, Simplicidade. E o Cliente segue pagando, acreditando que o produto que ele comprou é bom, feito por gente boa, e não por qualquer Zé Mané que se acha “O Cara”.

E este mesmo Enrolão, quando utiliza outro programa, provavelmente acha que está ruim, que poderia ser mais simples. Ou não, porque os “Caras” não gostam de perder tempo pensando...

Fato real: Uma rotina de gravação levava 25 minutos para concluir. O usuário reclamou e foram feitas alterações. Novos testes e o programador disse:
- Agora melhorou muito, está levando apenas 12 minutos.
E eu, quase sem acreditar:
- Como assim, você acha que 12 minutos está bom?
- Sim, é a metade do tempo.
- Não, não está bom! 2 minutos já seria muito tempo...
- Mas tem muita informação para ser salva – ele disse.
Após várias tentativas e aceitando algumas sugestões minhas (felizmente, porque os “Caras” não aceitam sugestão), reduziram para perto de um minuto.

Esta é a versão da tela do Google se fosse desenvolvida por alguns colegas que conheci ao longo da minha carreira:
E você, já viu muita bobagem? Comente!

Quanto mais complexo, melhor!

Normalmente, qualquer tarefa tem inúmeras formas de ser executada, assim como qualquer problema tem inúmeras soluções. Dentro desta gama de opções, algumas são mais simples e outras mais complexas. Não sendo você um dos “Caras” de TI, certamente você preferiria sempre as mais simples, e se não fosse assim, mesmo sem aceitar, você seria um dos “Caras”.

Já participei de várias reuniões de definição e é incrível o número de programadores e de analistas que não consegue parar para pensar um pouco antes de dar uma idéia estúpida, digo, estupidamente complexa (o que é a mesma coisa que estúpida). Pergunto-me: Será que é preguiça de pensar, falta de capacidade ou tentativa de mostrar que é inteligente? E ao ouvir uma dessa idéias dos “Bonitinhos da mamãe”, falar o que?
- Veja bem, e se a gente pegasse esta tua idéia, que é boa (cof, cof, cof), e retirasse isso, isso, isso, isso, isso e isso, não ficaria mais fácil?
Resposta normal, não sempre verbalizada:
- Ah, mas aí não vai ter graça de fazer, em meia-hora estaria pronto. Com a minha solução, levaremos no mínimo uma semana,... somente para definir.

Amigos, para tudo, eu não estou brincando, eu já vivi situações assim em grandes empresas de informática. Mas fazer o que, quando o chefe valoriza estas pessoas que estão rasgando o dinheiro da empresa?

Tenho certeza que alguns dos “Caras” que só tem idéia complexa, quando uma mais simples resolveria, têm a intenção de parecerem “Inteligentes”, e acredito que para os outros “Caras”, realmente eles sejam considerados os “Cabeças”. Mas quem sabe do assunto, na primeira olhada, percebe quanta bobagem desnecessária. Um solução complexa é difícil de definir, de implementar e principalmente de manter (bah, coisa mais óbvia,... mas não para os “Caras”).

É interessante ouvir dois “Caras” tentando achar uma solução. Como a primeira idéia já é meio complexa, ela carrega uma séria de problemas, e para resolver cada um dos problemas, mais complexa se torna a solução, e conseqüentemente com mais problemas. E olha lá o chefe aplaudindo tanto empenho.


E você, conhece “Gênios” assim? Comente!

Mamãe, eu já sei programar...

Esses “Caras” de TI são incríveis, pois aprendem a escrever um “Hello World” e acham que já sabem tudo de programação. E se já sabem tudo, estudar para que?

Já conheci muito programador, ou pelo menos, era assim que se apresentavam. Bastava olhar algum código escrito por eles que dava pra entender porque o cliente estava reclamando tanto. 

Felizmente este problema de “Sabe-Tudo” diminui ou até acaba com o aprendizado, pois como disse o filósofo Sócrates: “Só sei que nada sei”. Quanto mais sabemos, mais percebemos as nossas faltas e as nossas falhas. 

Infelizmente para alguns, como não percebem que são muito fracos e não estudam, nunca irão progredir. 

Outra grande frase de Sócrates: "Eu não posso ensinar nada a ninguém, eu só posso fazê-lo pensar.". Grande Sócrates. Mas os “Caras” não querem pensar, menos ainda pensar que não sabem tanto quanto acham e tudo o que teriam de aprender, já dá uma canseira...

 

Desculpem-me a brincadeira, mas é até engraçado ouvir um grupo de “Caras” conversando, é algo como um cego puxando o outro. Sai cada coisa que é melhor sair de perto para não criar inimizade. É bacana ver quando discordam, é cada um defendendo uma bobagem maior que o outro. 

Se um tem dúvida, pergunta para outro (normalmente que sabe menos que ele, se isso for possível), e aí ficam mirabolando soluções idiotas para problemas tão simples. E eu me pergunto: “Por que não perguntam para quem sabe?”, e eu mesmo respondo: “Porque eles acham que sabem.”. 

Mas dizer o que para estes “Caras”, se alguém os contratou e os mantém no cargo, apesar de toda meleca que fazem? Como podemos dizer para estudarem, para tentar uma solução mais simples, para tentar fazer assim ou assado? Se eu pergunto por que não usam uma rotina recursiva, eles normalmente respondem que não gostam de usar rotina exclusiva. 

Bom, deixa pra lá... 

Você conhece gente assim? Comente!

Tarefas repetitivas, repetitivas, repetitivas...

Analise o dia-a-dia de um trabalhador de TI e perceba quanta “Tarefa Repetitiva BURRA” é feita.

Nós passamos o tempo todo fazendo Tarefas Repetitivas, como escovar os dentes, mas deve ser difícil encontrar alguém vá até a casa dos pais, pois ainda “não teve tempo” de levar a escova de dente para sua casa. Certo, tudo bem, é um exemplo muito idiota, ninguém faria isso... Então, por que muitos desenvolvedores e analistas fazem coisas deste tipo?

Já vi demais o que considero TRB (Tarefa Repetitiva Burra), para achar que é exceção, mas independente da quantidade absurda, nunca vou considerar como algo normal.

TRB é uma tarefa executada rotineiramente e que envolve uma série de passos, mesmo que estes passos sejam simples. Um exemplo é aquele arquivo que você abre diariamente, e diariamente você executa o Explorer, navega em um mar de diretórios, rola a tela para cima e para baixo até encontrar o arquivo desejado e executa um duplo-clique nele para abrir (alguns ainda preferem clicar no botão direito e selecionar Abrir). E o usuário, nesta tarefa simples de abrir um arquivo, gastou 30 segundos ou muito mais. São aproximadamente 15 minutos por mês somente para abertura deste arquivo. Por que este usuário não cria um atalho no desktop para este arquivo? A resposta dos “Caras” é normalmente:
- Porque não precisa.
Bela resposta, pois quem está pagando esta improdutividade é o “coitado” do Cliente. Tenho certeza que se saísse do bolso deste profissional (?), algumas coisas seriam muito diferentes.

O exemplo acima é de uma TRB simples, mas existem outras mais complexas, que envolvem uma série de passos, alguns com potenciais grandes de problema, além de grandes consumidoras de tempo. Estes TRBs normalmente requerem uma ordem específica para serem executados e são feitos por apenas uma pessoa (o Especialista na TRB), que nunca descreveu a tarefa por não ter tempo ou vontade. Muitos, ou melhor, praticamente todas as TRBs que eu vi poderiam ser rapidamente automatizadas através de programas muito simples, a maioria somente utilizando Scripts do Sistema Operacional (os antigos arquivos .Bat ou os modernos ShellScript).

Se você me perguntasse, a queima-roupa, por que os profissionais de TI fazem essas TRBs, e responderia:
- Porque eles não sabem como automatizar, já que nunca se preocuparam com isso.

Outro exemplo que eu vejo bastante são usuários organizando uma planilha Excel “manualmente”. Eles não conhecem o recurso “Classificar”. E provavelmente acreditam que não exista, pois do contrário, iriam procurá-lo... ou não???

Mais sobre isso, em breve.

E você, tem muita TRB? Comente!

Em Casa de Ferreiro ... na Informática

Você conhece este ditado: “Em casa de ferreiro, o espeto é de madeira”? Certamente, e você já deve ter dito ou pelo menos pensado nisso em várias situações e com um grande número de profissionais. Eu pensava que esse problema era apenas com pessoas, mas quando comecei a trabalhar, descobri que vale para muita empresa também.

Isto me lembra uma piadinha que ouvi há muito tempo, que tentei reproduzir no desenho abaixo.



Conheci muita empresa de Informática como a do desenho acima, isto é, que não utilizavam os sistemas que vendiam para fazer o seu próprio faturamento, o controle de pagamentos, a contabilidade, etc. Algumas não tinham nada informatizado, era tudo no papel mesmo, outras poucas utilizavam planilhas para os controles, e muito poucas utilizavam alguns arremedos de sistema. Apesar disso, na maioria, as Notas Fiscais eram feitas a mão ou na velha máquina de escrever. E não estou falando apenas das pequenas empresas de informática.

Não sei responder porque isso é assim, nem porque os sistemas internos normalmente são muito fracos em termos tecnológicos e com poucas facilidades operacionais. Tenho algumas idéias, mas fica para uma próxima vez...

A sua empresa é assim? Comente!