Álvaro Ferro
Desculpem-me os entusiastas dos wearables, mas pessoalmente não quero mais um device para me preocupar em carregar todos os dias. Prefiro o Pebble. É em e-paper e por isso a bateria dura cerca de 5 dias.
E já agora… Não uso relógio. O meu iPhone também já dá as horas.
A Canonical vai lançar em breve o Ubuntu para smartphones. Enquanto utilizador de iPhone e Apple OSX, preferia um ambiente mais livre e integrado sem o excesso de controlo da Apple, Windows ou Google (Android), pelo que para mim pessoalmente este novo player é uma excelente noticia.
Pessoalmente considero o Ubuntu como sistema operativo (OS) para utilizador final no seu conjunto muito apelativo, mesmo para o utilizador menos experiente. A minha opinião é suportada na facilidade de instalação do OS e gestão do sistema após instalação.
Os fóruns de utilizador e blogs para acompanhar as mudanças, tal como a sua loja de aplicações pré-instalada, permitem a quem nunca viu este OS adaptar-se rapidamente sem ter de aprender instruções de linha de comandos.
O Ubuntu é suportado grandemente pela sua comunidade de utilizadores, mas também pela Canonical, empresa que presta serviços pagos e gere a distribuição. A distribuição deste sistema operativo é gratuita (oferecida) para utilizador final e tem versões para posto de trabalho e servidor. A distribuição é baseada em GNU/Linux e nos utilitários e aplicações que foram construidos para este conjunto.
Esperemos que o Ubuntu para smartphones se apresente com a mesma abertura e vivacidade que a versão para computador tem demonstrado até agora.
O mentor deste estudo José Tribolet afirmava em Abril 2011: “faço votos que o próximo Governo – qualquer que ele seja – se compenetre que a maioria das melhores práticas de organização, de gestão e de controlo operacional e estratégico, testados e adoptados no mundo empresarial se aplicam com todo o propósito à ‘empresa’ administração pública portuguesa, central e local, instrumentos fundamental de navegação rumo ao futuro do Portugal INC, do século XXI“.
Não vi o estudo do governo, mas tenho já aqui os pontos que irei verificar se ele aparecer em público:
A temática da nuvem já não é nova para quem anda nesta coisa dos sistemas de informação à tantos anos. Já lhe chamaram Software as a Service (SaaS) ou Infrastructure as a Service (IaaS) ou só Cloud, mas redunda sempre numa transferência de poder do utilizador para o prestador desequilibrando a balança para o lado de quem ainda hoje presta mau serviço com a desculpa que as regras de quem compra são muito complexas.
Ao defender os meios que conhecem como necessários, os técnicos envolvidos em aquisições ou desenvolvimento de sistemas de informação estarão a demonstrar também a sua competência.
Dizem algumas boas práticas que devemos tentar verificar nos vários momentos do projeto de desenvolvimento de sistemas de informação que quem tem a necessidade indicou como se verifica que se está a adquirir ou desenvolver corresponde a essa necessidade.
Ao verbalizar as formas de verificar o objetivo do requisito, quem o verbaliza revê o requisito e pode assim melhorar o detalhe sobre o mesmo. Está também a comprometer-se com o resultado construído ou adquirido e a reduzir com isso a possibilidade de gerar desconformidades com a sua expectativa.
O comprometimento de quem compra com a forma de verificar a conformidade do que se pretende comprar é um passo essencial no processo de alinhamento de quem tem a necessidade aos meios necessários garantir para verificar a conformidade dos produtos resultantes.
Para a sequência, quer o projeto seja em cascata ou em organizações mais recentes de projeto de desenvolvimento, a análise deverá conter pelo menos:
Retirados os critérios de verificação e validação a quem constrói, não existirá o que verificar objetivamente. Os requisitos estarão ligados aos produtos por hiatos intransponíveis por falta de análise.
Porque o mais provável é a derrapagem nos prazos durante a análise quando os requisitos do produto forem descritos sem a preocupação com a forma de os verificar, também é bastante provável que quando confrontado quem tem a necessidade com o aumento do período de análise coloquemos em causa a competência da equipa técnica pela imprevisibilidade da sua atividade.
A minha recomendação é assim que defendam sempre os meios de confirmar por vocês próprios os produtos sem dependerem da intervenção do vosso cliente.
A minha experiência pessoal indica-me que, embora muitas vezes o pedido e orientações para o desenvolvimento dos sistemas de informação chegue até quem implementa a solução vindo da camada de gestão, a gestão sucumbe quando pressionada pelos seus operacionais face aos objectivos que lhes determinou.
A minha experiência indica-me que, mesmo que seja dada carta branca ao implementador para propor uma solução com que os utilizadores se comprometam, é o próprio implementador que falha na determinação das medidas de sucesso. Poderíamos especular as razões por de trás desta falha, mas a realidade é que são irrelevantes para o resultado final.
Quem implementa soluções em sistemas de informação deve assegurar o comprometimento dos utilizadores finais da solução com os resultados esperados. Este comprometimento só pode ser obtido mediante comunicação eficaz, eficiente e directamente desenvolvida para os utilizadores finais. À camada de gestão só deverá preocupar o custo da sua implementação e utilização: tempo e dinheiro.
O comprometimento dos utilizadores não é mais do que a indicação que estes concordam com o resultado esperado. O resultado esperado é medido em 3 partes:
O utilizador a quem o sistema se destina não se vai comprometer com soluções que:
Os resultados esperados pelo utilizador são sempre os necessários para cumprir objectivos da sua função em menor tempo e com maior eficácia que antes do sistema entrar em produção. A satisfação que ele próprio obtém da utilização acaba por ser resultante dos anteriores.
Na implementação de sistemas de informação a equipa que os implementa ultrapassa muitas dificuldades, nomeadamente as suas próprias incapacidades, os impedimentos técnicos, mas também a incapacidade do solicitante de se comprometer com a solução esperada.
Numa situação de resistência à adopção da solução, a implementação entregue têm tanto ou mais sucesso quanto a capacidade de determinar critérios de validação mensuráveis por outros que não os próprios implementadores.
Se os critérios de aceitação não estão definidos antes da aceitação do sistema, já é tarde para obter o comprometimento do utilizador. O implementador estará numa situação que ele próprio criou ao não acordar com o utilizar as medidas de sucesso.