Metodologias vs Competência Técnica

Eu sou um adepto incondicional das metodologias e dos processos nos projetos de engenharia de produção de software. Acho que são absolutamente essenciais para garantir que cada elemento saiba o seu papel na equipa, o que se espera dele, e qual o ponto de situação do projeto em qualquer momento. Numa empresa com o profissionalismo da Indra não podia ser de outra forma. Seja em metodologias Agile (a nossa preferida desde há alguns anos), seja em Waterfall.

Mas será que a metodologia é o mais importante neste tipo de projetos?

Não creio. Acredito mesmo que algo vai correr mal quando vejo empresas onde a competência técnica e funcional, reforço, neste tipo de projetos em que se desenvolve a partir de uma folha em branco, é relegada para 2º plano em favor da metodologia. É como se achássemos possível que um  treinador como o José Mourinho, o melhor treinador da atualidade, reconhecido pela excelência dos seus métodos, conseguisse vencer a liga dos campeões com uma equipa mediana do campeonato português. Simplesmente não é possível. Por muito bons que sejam os seus métodos.

Podem dizer que não querem ganhar a liga dos campeões. Só querem fazer um campeonato tranquilo. Eu digo: ok certo, mas se pudessem ter as duas coisas (ou quase) pelo mesmo preço? Isto é, não tinham o José Mourinho mas tinham um técnico credenciado (mas não o José Mourinho) e um  conjunto de jogadores de top ou de elevado potencial. O que preferiam?

Podem pensar que quem pensa desta forma relega a metodologia para 2º plano. Nada mais errado. Também acredito que um conjunto de excelentes técnicos mal orientados terão provavelmente resultados muito pobres. O que me diz a experiência é que temos que procurar sempre um equilíbrio.

Se é verdade que nunca conseguirei fazer um projeto de produção de software com sucesso (na qualidade, no tempo e no preço) que tenha uma complexidade mediana (entre as 5000 e as 10 000 horas de esforço) ou elevada (superior a 10000 horas) com engenheiros inexperientes e/ou com pouca capacidade, também é verdade que a probabilidade de algo correr mal, se não for muito rígido no seguimento dos processos e das metodologias, mesmo com excelentes engenheiros, é muito elevada.

A todos os Gestores de Projeto

A Gestão de Projeto é encarada pela maioria dos jovens que saem da universidades como o topo da carreira na Engenharia de Software. Exatamente antes de ser Director ou Presidente de qualquer coisa.

Não admira por isso que aqueles que não gostam muito de programar – normalmente a porta de entrada nesta indústria-  tenham frases do género: “fogo.. que aborrecido, não sei como consegues estar 10 horas a olhar para um ecrã de computador a programar“, “ahhh, eu até gostava/gosto e sei programar mas não quero levar uma vida inteira de escravidão! ….“  e ainda “eu quero evoluir rápido. Programar não tem futuro!” . Tipicamente a seguir a estas frases vêm outras: “Eu quero é evoluir para analista funcional ” (lol) ou “Quero começar rápido a fazer Gestão de Projetos, quero ter uma vida melhor” , que engano .

Desde já informo que não tenho absolutamente nada contra as pessoas que dizem estas frases e têm estas ambições. Todos nós somos livres de ambicionar aquilo que achamos ser melhor para nós. O problema é que, quando estes pensamentos se tornam instituição numa qualquer empresa de consultoria/desenvolvimento de software leva normalmente a que encontremos Gestores de Projeto que não entendem o trabalho de um programador, não têm uma noção exata de como deve ser feita e pensada uma Aplicação de Software, não estão a par nem lêem nada sobre Engenharia de Software -não gostavam, lembram-se?-  , não querem saber o que faz a aplicação -muitas vezes nem sabem entrar e trabalhar com ela- que estão a desenvolver e, mais grave do que isso,  estão numa posição de chefia! Isto tudo conjugado é a receita ideal para o desastre.

Por isso, deixo aqui algumas recomendações para estes Gestores de Projetos. Existem muitas outras, mas essas, qualquer personagem que se diz Gestor de Projeto já as leu em qualquer PMBOK. Aqui vão 4 regras fundamentais para facilitar o vosso trabalho:

1. Ver para crer. Nunca acreditar quando a equipa técnica diz que já implementou qualquer coisa e diz que está ok. Tipicamente isto implica colocar um “100%” no Microsoft Project da ordem. Mas tenham cuidado, não custa nada.  Mesmo que tenham no projeto uma equipa de QA, entrem na aplicação como se fossem um utilizador e verifiquem com os vossos olhos. Vão ver como, se repetirem este comportamento de forma sistemática tudo se vai tornar mais fácil, vão entender a aplicação que se está a fazer e  as conversas com o cliente, com os técnicos, com os funcionais vão ficar bem mais fáceis e produtivas.  Além de que, a probabilidade de terem surpresas desagradáveis mais tarde fica bem menor.
2. Entender todas as decisões técnicas. Não acreditar em tudo o que a equipa técnica diz sem perceber. Eu sei que não têm muita experiência de programação e por isso não se sentem habilitados a argumentar com os programadores. Mas acreditem em mim, qualquer decisão técnica  do tipo,  “isso não pode ser assim ou assado porque não a linguagem não dá” ou por outro constrangimento qualquer invocado pelos programadores tem que ser entendido. Normalmente vocês são pessoas inteligentes. Perguntem até entenderem, não se inibam, sejam chatos. Se não entenderem então é porque estão mesmo na profissão errada ou os programadores estão a tentar enganar-vos!
3. Ler, estudar. Eu sei que não gostam mas não custa assim tanto e vai ajudar em muito o vosso trabalho. Assinem alguns Blogs, principalmente aqueles que falam sobre as tecnologias que estão a utilizar e subscrevam uma ou duas revistas da especialidade para se manterem a par. Quando não perceberem alguma coisa perguntem a algum técnico que considerem. Não é preciso mais de 4 horas mês.
4. Não mandem Emails. Sim, pode parecer uma regra exagerada e obviamente não é para ser levada 100% à letra. Mas, por favor, não enviam emails por tudo e por nada. Levantem-se, falem com as pessoas, telefonem, comuniquem pessoalmente. Os emails muitas vezes são mal interpretados, além de que, com uma conversa pessoal, muitas da vezes, obtêm imediatamente a resposta que procuram. Poupam tempo a vocês e aos programadores. Que detestam responder a emails.  A seguinte imagem, retirada de Cockburn, A. (2001). Agile Software Development ilustra bem como a comunicação pessoal pode ser bem mais eficaz:
   

Cumprir apenas estas regras não garante que venham a ser o melhor Gestor de Projeto do mundo. Mas que vai ajudar, isso não tenho a mínima dúvida. E ainda, como bónus, vão ganhar o respeito da equipa de programadores!

O melhor local de trabalho para um Engenheiro de Software

Esta semana foi extremamente rica de acontecimentos:

1º Um amigo de longa data que trabalha comigo na Indra Portugal, anunciou-me que vai sair. Disse-me que vai à procura da felicidade total. Que adora os projetos da  Indra, que não sai por motivo nenhum especial mas apenas porque não sabe se a Indra tem ou terá exactamente aquilo que ele precisa e anseia. Acredito nele. Já o conheço há muito e sei que é um desassossegado por natureza. Foi sempre um ótimo profissional mas nunca teve a certeza de que aquilo que fazia seria exatamente aquilo que precisava,  que o faria mais feliz e ganhar mais dinheiro. Não que ele, ou eu, acreditemos que o dinheiro seja o mais relevante. Será apenas uma consequência de sermos  felizes, profissionais e muito, muito competentes. Exatamente por esta ordem.

2º O projeto onde estou neste momento, entrou numa fase decisiva. Tomamos decisões muito importantes que terão influência na verdadeira natureza do produto que estamos a construir. Estamos todos muito entusiasmados.

3º Um outro grande projeto da Indra que acompanho à distância teve a decisão de GO LIVE da versão 3 para este fim de semana.

Mas voltando ao meu amigo. A conversa com ele fez-me refletir sobre mim próprio e o meu trabalho. Serei eu feliz no trabalho que faço todos os dias? Estarei eu no local certo? Não tenho dúvidas na resposta. É claramente um Sim.

A Indra em Portugal não é uma empresa muito grande, pouco mais de 400 pessoas. Em todo o mundo somos cerca de 30 000. Mas, não tendo ainda uma dimensão grande em Portugal, ou pelo menos comparável com a casa mãe em Espanha, deve ser a consultora que mais projetos interessantes tem no seu portfolio para aqueles que, como eu,  se intitulam e que querem fazer carreira como engenheiros de software:

• Desenvolvemos e somos proprietários de um dos ERPs mais conhecidos do mercado Português. O GIAF.
• Fizemos o projeto Cartão do Cidadão (estava cá ainda há pouco tempo quando foi para produção)
• Estamos a desenvolver (a versão 3 vai para produção este fim de semana, como eu disse atrás) um dos maiores projetos a decorrer em Portugal na área de Telecomunicações. Dezenas de engenheiros, orçamento de vários milhões de euros. E como? Recorrendo às mais modernas técnicas na área de Engenharia de Software: MDA / MDD  (Model Driven Architecture / Devolopement), DSL,  Continuous Integration, Functional Test Automation e ainda com técnicas Agile/Scrum para gestão do mesmo.
• Estamos a modernizar, com uma nova versão de software, os Portos nacionais. E como é feito este software? …. pois, adivinharam.  Embora a stack tecnológica seja completamente diferente, este é ambiente JAVA o anterior é Microsoft, usamos exatamente as mesmas técnicas de desenvolvimento: MDA, MDD , DSL etc.
• Iniciamos há pouco, outro projeto com orçamente superior a 2M€ numa das áreas mais promissoras do mercado B2B atual. A área de Strategic Sourcing. Estamos a realizar uma nova plataforma de software para a empresa líder deste segmento em Portugal com ambições de vir a ser líder mundial. E voltamos a usar, cada vez de forma mais refinada, as técnicas que falei atrás.
• Assinamos a semana passada um contrato para um projeto na área da Banca de valor superior a 3M€.
• E ainda muitos mais, com orçamentos superiores a 1M€. Uns já em fase de manutenção outros ainda em desenvolvimento.

A juntar a este conjunto de projetos existe uma carreira especialmente concebida para Engenheiros de Software.

Na Indra, os Engenheiros de Sofware que adoram programar e fazer software de raiz (só os verdadeiros percebem o gozo que dá construir algo a partir do zero) não precisam deixar de o fazer para crescerem na carreira. Na Indra o topo da carreira não é ser Gestor de Projeto. Claro que também pode, mas isso é outra carreira ao lado. Na Indra, o Engenheiro de Software, será depois Arquitecto e depois Arquitecto Sénior e depois … bem, depois será aquilo que quiser e puder. Nessa fase já não contará apenas as suas qualidades técnicas.

Perguntam agora. Mas é só felicidade? Tudo corre sempre bem? Claro que não. Mas qual é a  empresa que não tem chatices e problemas? Todas têm! O segredo é escolher aquela onde os problemas não afectem o mais importante. E o mais importante é sempre a felicidade e o gozo de fazer aquilo que se gosta e para o qual se tem talento.

Boa sorte Pedro. Vou ter saudades, tenho pena que vás, mas estarei a torcer por ti.

The art of modeling

The art of modeling is to find a good trade-off between realism and manageability. Paradoxically, it is often the case that additional realism renders a model less useful because the extra detail causes complexity. A model is successful if it captures enough reality so that key features of the issue and their inter-relationships can be displayed and understood clearly

Não me lembro quem é o autor desta frase. É no entanto uma das melhores definições que conheço para arte / engenharia de modelar. Todos aqueles que andam a trabalhar em arquitecturas MDA deveriam ter sempre presente esta definição.

Stay Hungry, Stay Foolish!

Ontem, o meu amigo Pedro Campos chamou-me a atenção para o discurso de um senhor chamado Steve Jobs, efectuado na Universidade de Stanford em 2005.

Há coisas que nos inspiram e mensagens que nunca devemos esquecer.  Por isso, aqui fica o vídeo e o link para a versão em texto.

Obrigado, Pedro!

As vantagens reais do Windows Workflow Foundation (WF)

Tradicionalmente os motores de Workflow são uma caixa preta e uma grande dor de cabeça para os programadores que têm de fazer aplicações de software cujo sucesso depende do bom funcionamento de algum representante da família.

As promessas dos motores tradicionais

Normalmente estes motores disponibilizam um conjunto de funcionalidades que impressionam numa primeira análise:

1. Uma interface gráfica muito bonita e simples, para desenho rápido de Workflows;
2. Promessa de agilidade nas alterações futuras que o processo possa vir a ter;
3. API muito fácil e poderosa para comunicação síncrona de comandos do tipo start/stop/cancel/resume Workflow, close/cancel/reassign task, etc.;
4. Promessa de fiabilidade a 100% e integração simples em qualquer ambiente aplicacional. Desde que suportado, claro;

A realidade dos motores tradicionais

O que se verifica na prática raramente atinge o prometido.

Porque não se generaliza o UML ? As 5 razões

Não é por falta de divulgação que o UML não tem uma adopção generalizada. Desde há alguns anos que “UML” é uma palavra que entrou no vocabulário de todos os que trabalham na engenharia de software. Apesar disso, o certo é que em Portugal o seu uso é pouco mais que residual. Tirando alguns – poucos – projectos em que existe um cliente, um gestor de projecto ou um arquitecto de software que faz questão em fazer alguma especificação em UML, esta notação não é praticamente usada. Se me pedissem uma projecção, eu diria que 95% dos projectos de software que se realizam em Portugal não são especificados em UML. Fora de Portugal, a realidade não é muito diferente. Segundo uma pesquisa de 2006 do professor Júlio Leite, da Universidade Católica do Rio de Janeiro, as taxas de adesão variavam muito consoante as zonas do globo mas, em nenhum dos estudos encontrados, ultrapassava os 30% de adesão.  Acredito que agora o panorama seja um pouco mais animador.

Vamos então às 5 razões que, na minha opinião, explicam o relativo insucesso:

Em Portugal não são necessários Arquitectos de Software?

Fora de Portugal principalmente nos países mais info-literados, aos quais nós tanto queremos pertencer, a função é bastante conhecida e requisitada. Em Portugal nunca vi um anúncio de emprego a pedir Arquitectos de Software!

Podem dizer que não estou atento a todos os anúncios que se publicam em Portugal. Sim, é verdade, mas tive o cuidado de perguntar ao departamento de recursos humanos da empresa onde trabalho e também procurei nos site’s de emprego disponíveis, os genéricos e os de empresas de recrutamento especializadas em TI.

Formato DjVu

Há algum tempo atrás, ouvi falar pela primeira vez no formato para representação digital de documentos  DjVu  (lê-se dejá Vu).  O formato foi desenvolvido originalmente pela AT&T Labs em 1996. Em 2000 a  LizardTech  adquiriu a tecnologia à AT&T e hoje em dia é comercializado pela LizardTech em parceria com a AT&T Labs.  O formato é aberto – licença GPL-  e as implementações mais conhecidas são open-source.

Descarreguei o software necessário para efectuar a leitura de documentos com este formato e fui experimentar.

Uma lufada de ar fresco na arquitectura dos ERPs?

Hoje deparei-me com este post do Nicholas Carr. Chama a atenção para a WorkDay, nova empresa de Dave Duffield , antigo CEO da Peoplesoft.

A WorkDay promete revolucionar o mercado dos ERP’s. Diz mesmo que os ERP’s tal como nós os conhecemos têm os dias contados. Movido pela curiosidade, fui ver melhor.