Avançar para o conteúdo principal

Não tem que ser assim

Anda por aí esta anedota:
"A namorada pede ao namorado, que é programador:
- Morzinho, vais à loja comprar pão? Se houver ovos trazes seis, OK?
O namorado vai à loja e passados uns 15 minutos volta com 6 pães.
- 6 pães? Porquê? - pergunta ela.
- Havia ovos. - responde ele."
Mas não tem que ser assim. Esta imagem absurda de um programador desligado da realidade é causada por muitas situações reais que continuam a acontecer ainda hoje, em muitas organizações.

Cabe aos profissionais das TI romperem com este estereótipo, mostrando-se empenhados em resolver problemas reais e em ter um impacto positivo na vida dos outros.

Comentários

  1. Poderia ser caso para dizer "tens umas piadas muita giras, tens tens"... Mas na verdade a conclusao a que eu chego e' a contraria da tua. Transposto para a realidade de IT, o programador fez precisamente o que devia fazer, nao tendo ele culpa que a namorada/gestora de projecto tenha especificado incorrectamente o que queria. Pode ate' ser que, na practica, o programador tenha adivinhado correctamente a intencao do PM e trazido meia-duzia de ovos e nao de paes, mas nao so' nao e' isso que lhe compete como em projectos de envergadura isso e' contra-producente. Imagina que na programacao de um Mars Rover um programador resolve interpretar o que dizem as especificacoes... ou no software que controla a alimentacao de plutonio numa central nuclear...

    Ha' tempos para tudo, para interpretar e pra seguir o que esta' especificado. Quando uma especificacao esta' fechada deixa de estar sujeita a interpretacoes.

    E' por isso que se diz que seguir especificaoes e andar sobre a agua e' facil desde que ambas estejam congeladas...

    ResponderEliminar
  2. O caso é simples e, para mim, evidente. Um programador alienado achou que vive num universo é que é normal condicionar-se a compra isolada de um número específico de pães à existência de ovos na loja. Esse programador não é parte da solução. É parte do problema.

    Os informáticos têm que aprender a antecipar os problemas, antes até de receber os requisitos. Se não compreenderem os problemas vão acabar, como tantas vezes acontece, com a solução certa para o problema errado.

    ResponderEliminar
  3. Isto dos gestores lançarem anedotas para denegrir a imagem dos programadores é alguma desculpa para justificarem pagarem tão pouco a quem exigem tanto?

    A maior parte dos erros informáticos são PIBKAC's (Problem is between keyboard and chair). Infelizmente nem todos esses PIBKAC's são originados pelos programadores. Concordo com o António que muitas vezes os mal entendidos ocorrem porque alguém teve problemas em especificar correctamente os requisitos. E não esmiúçam para não mostrar a falta de conhecimentos que têm. Depois dizem que é suposto o programador ser pro-activo. De facto, muitas vezes é, noutras, não está para ocultar tamanha ignorância de quem devia ser mais responsável.

    Não retiro da equação os utilizadores, que muitas vezes inventam coisas que ninguém imagina e que subvertem o propósito da aplicação. Alguns utilizadores são especiais, são hackers capazes de, por terem conhecimentos para tal, explorar as vulnerabilidades existentes nas aplicações.

    Que tal deixarem de empurrar com a barriga, achando que o problema é sempre do outro? Até parece que os programador e o gestor não estão no mesmo lado e que não querem atingir o mesmo objectivo. Numa equipa bem liderada este tipo de questões não aparecem.

    ResponderEliminar
  4. Eu sou informático, gestor, e às vezes ainda tenho o prazer de matar saudades a fazer umas linhas de código. Não sou um gestor a dizer mal de programadores.

    Os meus posts são em defesa de uma profissão. Se chamo a atenção para falhas de comportamento típicas é sempre com o mesmo sentido: dignificar e valorizar a nossa profissão.

    Se isso não é claro, peço desculpa, deve ter sido falha minha... ou talvez não. ;-)

    Anedotas destas existem e fazem sentido porque nós os informáticos temos frequentemente este problema de não entender os outros, por mais simples que sejam as mensagens. Ligamos o complicómetro, fazemos porcaria, e depois deitamos a culpa para a "namorada".

    ResponderEliminar
  5. Uma vez que já clarificaste inequivocamente a tua posição, já podes esclarecer a minha pergunta inicial.

    Este pretexto serve para justificar a diferença de ordenados entre programadores e gestores, sendo ambos licenciados?

    Não é claro para mim que, referindo os informáticos como seres alienados que vivem num universo desligado da realidade, seja uma boa defesa das TI's. Parece-me correcto concluir que uma pessoa que reúna estas condições, seja considerado esquizofrénico. Dificilmente me vou sentir dignificado, ou valorizado com este tipo de arquétipo. Mas posso ter entendido mal... ou talvez não ;-)

    A anedota em si, é inócua. Porque é de interpretação livre. Representa um típica situação de lógica implícita. A interpretação de que uma especificação incompleta é aceitável para concluir um projecto, apenas porque faltou um sujeito na frase. Enfim que custava à “namorada” não comer os “ovos”?

    Há várias formas de gerir projectos. Há projectos “fechados” em que não são deixadas pontas soltas para a liberdade artística. Coisa que o António chamou de “especificação congelada”, onde tudo é pensado e são atribuídas tarefas bem definidas. Onde se usa “isto” com esta configuração.
    Há os projectos dos “artistas”, em que tanto os programadores como os gestores o são. Onde há imensas pontas soltas para a liberdade artística. Quando algo corre mal, a responsabilidade é sempre do “artista” hierarquicamente inferior, programador. O artista/gestor é um infeliz que tem que lidar com estes tipos que não pensam.

    Felizmente a grande maioria dos informáticos não são assim. São pessoas inteligentes que interpretam correctamente inclusivamente aquilo que lhes é omitido. Mesmo quando muitas vezes nem é implícito na lógica. E, ou fazem perguntas para esclarecer e são considerados inconvenientes, ou tomam a liberdade artística de resolver o problema que ninguém quis “ver”. Dificilmente vão justificar o tempo utilizado numa tarefa “oculta/implícita”. Claro que o “artista/gestor” o vai responsabilizar por essa “derrapagem”. Se tudo correr bem, maravilha. Não correndo, chamam-lhes de alienados da realidade. Enfim!!! Posso estar a interpretar mal, … ou talvez não!

    ResponderEliminar
  6. Há muitas razões para um informático ganhar menos que um gestor (ou que um comercial, já agora), nem todas válidas. Como o tema é longo, deixo-o para um post futuro.

    Este é um blogue de informáticos para informáticos e utilizadores de informática. Faço aqui muitas críticas aos informáticos, mas sempre numa perspectiva positiva, para ajudar a melhorar o nosso desempenho profissional.

    Sei que nem todas as pessoas reagem bem a críticas, o que é uma pena. A médio longo prazo, a sua inabilidade para ouvir e ajustar comportamentos leva-as a perder valor e alienar os clientes. É pena, porque o sector continua a crescer e haveria muitas oportunidades que assim são perdidas.

    O informático da anedota é assim. Ouve mas não percebe. Este estereótipo é alimentado pela "surdez" de uns quantos e prejudica-nos a todos.

    Não tem que ser assim.

    ResponderEliminar
  7. Gostaria de conhecer as muitas razões que justificam um informático ser menos remunerado que um gestor. Fica o prometido.

    Quanto às críticas! Acho que ninguém está isento de críticas e concordo que imensa gente não reage bem quando é alvo das mesmas.
    Tal como disse, não posso aceitar como uma crítica positiva a acusação, não só errada, como profundamente injusta, de os informáticos de serem “alienados” que vivem num mundo à parte.

    Até aceito que haja uma boa intenção nas tuas palavras. Agora, acho esta visão demasiado redutora. Os responsáveis pelos problemas dos informáticos são quer os programadores, quer os gestores de projectos, quer os clientes e os seus requisitos nem sempre muito explícitos. Acusar única e exclusivamente o elo mais baixo da cadeia, como o causador de todos os males é errado. Digo mais, não resolve nada. Não digo que não haja informáticos com alguns handicaps, mas também os há nas outras categorias. Se apurar de forma isenta as causas do erros nos projectos, vai-se perceber que na maior parte das vezes a responsabilidade é de especificações deficientes. Quem vestir as calças do gestor que quer sacudir a água do capote, alimenta à exaustão o retrato ridículo da anedota.

    Infelizmente os computadores não se programam com intenções, mas com instruções muito concretas. Se assim fosse o Facebook teria sido,eventualmente, criação de dois remadores olímpicos e não de um “neard”. Um bom gestor sabe que nalgum ponto de projecto vai ter que transformar os requisitos em especificações e vai ter que lhes atribuir tarefas a serem executadas. Quanto mais específicas forem a descrições das tarefas, melhor poderá organizar o projecto prevendo “tempos” de forma mais realista. Numa equipa informática onde todos fazem o seu trabalho não há este tipo de problemas.

    Se as pessoas fossem computadores, fazia-mos-lhes um “upgrade” e ficava tudo a funcionar bem, com especificações completas e sem mal entendidos. Era tudo perfeito. Mas para programar as pessoas com sucesso, é necessário utilizar uma neuro-linguagem algo mais sofisticada que Java e afins. Algo que não está ao alcance de toda a gente. Há programadores que dão “marteladas” no programa para ocultar o “prego”. Só que na neuro-linguagem as coisas não funcionam bem à “martelada”.

    Não tem que ser assim!!!

    Desta discussão saliento uma frase como positiva:
    “seguir especificações e andar sobre a agua é fácil desde que ambas estejam congeladas...”

    António vais-me desculpar, mas fiquei fã desta tua frase.

    ResponderEliminar

Enviar um comentário

Mensagens populares deste blogue

[Off-topic] "Novas" tendências de gestão

Afinal as novas tendências de gestão não são de agora. E as suas consequências também já são conhecidas há muito. Vejam esta carta do Senhor Vauban , Engenheiro Militar e Marechal de França, dirigida ao Senhor Losvois, Ministro da Guerra de Luís XIV, datada de 17 de Julho de 1683. "Monsenhor: ... Há alguns trabalhos nos últimos anos que não acabaram e não acabarão nunca, e tudo isso, Monsenhor, porque a confusão que causam as frequentes baixas de preços que surgem nas suas obras só servem para atrair como empreiteiros os miseráveis, malandros ou ignorantes e afugentar aqueles que são capazes de conduzir uma empresa. Digo mais, deste modo eles só atrasam e encarecem as obras consideravelmente porque essas baixas de preços e economias tão procuradas são imaginárias, dado que um empreiteiro que perde, faz o mesmo que um náufrago que se afoga, agarra-se a tudo o que pode; e agarrar-se a tudo, no ofício de empreiteiro, é não pagar aos fornecedores, pagar baixos salários, ter os piores

Conferência Europeia da Comunidade Alfresco

Já foi há quase quinze dias, mas julgo que ainda será relevante abordar a Conferência Europeia da Comunidade Alfresco, que decorreu em Barcelona no dia 22 de Abril. Com uma audiência de mais de 200 pessoas (a sala reservada estava cheia) vindas de vários pontos da Europa, este evento serviu para que muita gente desta comunidade se encontrasse pela primeira vez face a face. A Alfresco Inc. é uma empresa recente, que apostou em criar uma solução de gestão documental de topo de gama usando o modelo open-source . Considerando que a empresa, no seu terceiro ano de actividade, já atingiu o break-even , parece ter sido uma boa aposta. No arranque da conferência esteve John Powell, CEO da empresa, que falou um bocado sobre a excelente evolução da empresa e abordou a "guerra" entre o modelo de negócios proprietário e o modelo de código aberto. Exemplificou este conflito com o Microsoft SharePoint, que ele designou como "a morte da escolha", justificando o epíteto pelo facto

O que é uma POOL ?

Tenho andado a fazer implementações de mecanismos de pooling em Java 2 Enterprise Edition. Como me parece um conceito algo lato tentei a abordagem do dicionário. Alguns mostram que de facto a palavra é usada para muita coisa. A definição mais comum é "piscina". A que mais me agradou foi o que descobri na wikipedia , onde pooling é apresentada como uma técnica para guardar qualquer coisa que já não é necessária em determinado sitio (a que se chama pool ) com o objectivo de a usar quando necessário optimizando assim a utilização de recursos disponíveis. Partindo para a computação, existem vários tipos de pools: Thread Pool - Conjunto de threads livres que se vão adicionando a um fifo quando não necessárias e retirando quando se quiserem usar. Memory Pool - Conjunto de blocos de memória, todos da mesma dimensão, que se alocam inicialmente e usam à medida que necessário garantindo que o tempo de alocação de memória é constante e a fragmentação minima. Connect