A Web em Realtime

Ontem tive a oportunidade de visitar uma empresa portuguesa e conhecer melhor os produtos e a tecnologia que eles estão a desenvolver. Falo da IBT e da tecnologia Realtime que é por eles desenvolvida e comercializada.

Fiquei verdadeiramente impressionado. Não só pela tecnologia per si, mas ainda mais pelo sentido de oportunidade e visão que eles demonstram ter. A tecnologia base onde a plataforma Realtime se apoia está disponível há relativamente pouco tempo -desde que começaram a aparecer os primeiros browsers com suporte a HTML5 e a Web Sockets- e é muito bom existir uma empresa de tecnologia portuguesa que esteja na vanguarda mundial de um processo revolucionário a que vamos assistir dentro em breve. Na forma como algumas aplicações são desenvolvidas e irão interagir connosco.

Será provavelmente um processo mais tecnológico e que não será percebido como revolucionário pelo utilizador final. Afinal, o impacto no utilizador final será “apenas” uma melhoria enorme na experiência de utilização de algumas aplicações. Quem não passou já pelas seguintes experiências:

  • Estar a seguir as incidências de um jogo de futebol num qualquer site desportivo e ter que esperar pelos menos 60 a 90 segundos para que o resultado seja atualizado? E ter que estar constantemente a fazer F5 para ver se tem os resultados mais cedo? (às vezes nem isso resulta por causa das caches que existem por todo o lado na Web)
  • Estar a comprar bilhetes para o cinema ou para o comboio e ser avisado que tem que se despachar, porque só garantem os lugares escolhidos por 5/10/15 minutos. E se eu desistir e sair do site? Os lugares ficarão indisponíveis para os outros utilizadores pelo menos por mais 10 minutos. Seria muito mais interessante perceber o que se está a passar e quais os lugares que estão a ser comprados/reservados e/ou a ficarem livres naquele exato momento.
  • Estar a seguir um site noticioso e ter que estar a fazer F5 para ver se determinado conteúdo ou noticia é atualizado.

Todas estas experiências relativamente desagradáveis vão beneficiar desta tecnologia. No fundo o que esta tecnologia permite é que de forma muito simples os utilizadores interajam em  tempo real com os produtores de conteúdos e/ou outros utilizadores com os mesmos interesses. No site do  Diário Económico está já há algum tempo um excelente exemplo da utilização da tecnologia (veja p.ex os comentários das notícias).

E para as empresas, “owners” de sites e publicitários? Ontem assiti a uma demonstração da utilização da tecnologia que me deixou tremendamente surpreendido. Tratava-se de monitorar um site real de vendas onde os utilizadores estavam a fazer compras. De uma forma extremamente simples era possível filtrar os utilizadores que estavam online naquele preciso momento e enviar um voucher de desconto. O exemplo que me foi dado a ver, foi filtrar todos os utilizadores que tinham mais que um produto no Carrinho de Compras e cuja soma fosse superior a 500 Euros.  Em seguida e com apenas 2 clicks foi escolhido um voucher de 10 Euros para  ser enviado a esses utilizadores. Menos de um segundo depois apareceu no browser desses utilizadores uma janela a informá-los que tinham ganho um desconto de 10 Euros. Não poderia haver uma forma mais directa de estimular a venda!

Estes são apenas alguns exemplos do impacto que esta tecnologia poderá ter. No site da plataforma Realtime existe um conjunto grande de exemplos que vale a pena ver e experimentar. E não falei dos impactos nas aplicações mobile …

As novidades não são só para os utilizadores finais e/ou para os vendedores ou responsáveis pelas aplicações.  Para os financeiros e donos dos sites tudo ficará bastante mais fácil e bastante mais barato. Porque requer muito menos recursos de computação -menos servidores- e é muito mais fácil de programar -menos horas de programação-.

A empresa portuguesa não está sozinha no mercado. Já existe um conjunto importante de concorrentes mas, e da análise que fiz, a plataforma Realtime está mesmo muito bem posicionada.

Em termos de arquitectura técnica utiliza uma plataforma Cloud (alojada na Amazon) que lhe garante que pode crescer rapidamente e de forma muita elástica. Isto quer dizer que as empresas que quiserem utilizar a tecnologia não precisam investir em servidores. Poderão simplesmente utilizar os servidores onde está alojada a plataforma. Claro que a plataforma pode ser instalada on premises mas a empresa recomenda que seja usada a plataforma Cloud. Com toda a razão, digo eu.

Resta-me dizer a única coisa que não gostei tanto. Eu estou habituado a que, quando quero usar uma tecnologia, poder consultar os preços e, se desejar, comprar e começar a usar sem precisar de qualquer outro contato com a empresa vendedora. No site atual da plataforma não é possível fazer isso. A tecnologia está disponível para ser experimentada sem custos :-)  mas, para saber os preços e os tarifários de utilização real, assim como para assinar algum dos tarifários terá sempre que contactar a empresa. Penso que isto poderá ser de alguma forma inibidor de uma massificação mais rápida.

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:
    Communication Modes

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), DSLContinuous 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.

Continuar a ler

Seguir

Get every new post delivered to your Inbox.