Risco de desconformidade dos meios de verificação de produtos de desenvolvimento e aquisição de sistemas de informação

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:

  1. Objetivo – O que se pretende atingir;
  2. Requisito – Detalhes considerados essenciais para atingir o objetivo;
  3. Critérios de verificação – A forma de verificar que os requisitos foram cumpridos; e
  4. Critérios de validação – A forma de dar como válida a verificação dos requisitos e objetivos atingidos.

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.

Consultores: as 3 respostas possíveis

No meu trabalho tenho conhecido muitos Consultores, Analistas, Programadores e Gestores de Projeto.

Tenho também ouvido muitas perguntas em reuniões feitas pelo cliente, mas para qualquer pergunta, só conheço 3 respostas que funcionam:

  1. “Vamos analisar.”
  2. “Os factos são […]”
  3. “Os impactos são […]

Qualquer outra resposta levará a cenários que o Consultor não foi capaz de prever.

À espera do Ubuntu 11.10


Unie200x113Daily

Quem me conhece pessoalmente sabe que recentemente perdi o meu MacBook Pro para uma falha catastrófica na sua Logic Board.

A resolução do problema dependia de um valor tão elevado que por menos disso comprei um Core i7 com características semelhantes, mas com um Sistema Operativo Windows 7.

A tentativa do Windows 7 de melhorar a sua Usabilidade ficou longe do alvo porque não é entendido por quem gere o produto que o utilizador por querer mais controlo não implica estar a ser incomodado a cada 2 minutos com janelas de confirmação.

O meu portátil corre atualmente o Ubuntu 11.04, uma distribuição Gnu/Linux que entendeu a simplicidade e necessidade de ter um computador pessoal controlado. Estou muito satisfeito com esse escolha, pelo que partilho aqui a expectativa com que aguardo a próxima versão.

Dizer o que faz e fazer o que diz

Os fornecedores de projetos de desenvolvimento de sistemas de informação em Out-sourcing devem:

  1. Dizer o que vão fazer; e
  2. Fazer o que disseram que faziam.

Este par é a minha mnemónica para rapidamente verificar um processo de  gestão de projeto.

Uso-a também para avaliar os meus representantes políticos.

Quando o teste de qualidade de software é invalidado pelas ineficácias da comunicação

No blog de James Bach’s encontra-se ilustrado o exemplo de como duas formas de comunicação diferentes podem ser a diferença entre o sucesso e insucesso de uma validação da qualidade do produto.
Ambos os exemplos se referem aos mesmos factos e apresentam as mesmas conclusões, mas um deles perdeu a credibilidade para futuras contratações, não porque dissesse alguma coisa diferente do outro, mas porque se entreteve a insultar os desenvolvedores.

Pior:

Melhor: