3P – Piores Práticas de Projeto (parte 2)

Continuamos falando sobre as piores práticas de projeto, mais uma vez com o intuito de alertar e prevenir tais práticas:

Telefone sem fio – a comunicação é essencial não apenas para a sobrevivência do ser humano, mas como também para a dos projetos. Portanto, devemos estar sempre nos perguntando se a informação está sendo gerada, coletada, documentada e passada para a pessoa certa. Segundo o PMI há quatro processos de gerenciamento das comunicações:

• Planejamento das comunicações – determinação das necessidades  de informações e comunicações das partes interessadas no projeto.
• Distribuição das informações – colocação das informações necessárias à disposição das partes interessadas no projeto no momento adequado.
• Relatório de desempenho – coleta e distribuição das informações sobre o desempenho. Isso inclui o relatório de andamento, medição do progresso e previsão.
• Gerenciar  as partes interessadas – gerenciamento das  comunicações para satisfazer os  requisitos das partes  interessadas no projeto  e resolver problemas com elas.

Eu quero eu posso – Essa é uma prática muito natural, sempre achamos que basta querer para poder realizar ou obter algo. Em projetos devemos avaliar o quanto de esforço que ele demandará e se o time está preparado, caso contrário o projeto terá grandes chances de sofrer atrasos, aumento de custo ou até fracassar. Um exemplo dessa prática foi o Pan de 2007, o maior evento poliesportivo já realizado no país, onde devido a falta de preparo dos realizadores e a problemas políticos o orçamento final ficou 1.289% a mais do que estava previsto inicialmente.

Excesso de documentação – documentação é um dos fantasmas em projetos de TI, isso porque o bom senso muitas vezes não é usado. E quando a equipe do projeto tem grande preocupação em documentar ou a metodologia usada tem como base a geração de documentos para tudo, um risco que aparece é o excesso de documentação, onde podemos ainda estar realizando a análise de risco e o prazo do projeto já ter acabado. Uma das medidas para evitar tal prática é sempre averiguar a importância que a documentação terá para o projeto e o que será documentado e o que não será. Lembrando que mais importante do que documentação gerada é software funcionando.

‘Achômetro’ – por último umas das práticas mais utilizadas não somente em projetos de TI, mas como também na nossa vida. Afinal, o ‘achômetro’ tem como base o conselho que segundo o texto de Mary Schmich, que foi transformado em um discurso musicado por Pedro Bial com o nome Filtro Solar:

Conselho é uma forma de nostalgia. Compartilhar conselhos é um jeito de pescar o passado do lixo, esfregá-lo, repintar as partes feias e reciclar tudo por mais do que vale. (“Advice, like youth, probably just wasted on the young”- Mary Schmich)

Devemos usar o ‘achômetro’ somente em momentos que realmente não teríamos como obter um histórico de dados, como por exemplo, no primeiro projeto de uma recém criada empresa. Sempre que possível, precisamos justificar as nossas ações e estratégias com base em informações e não na opinião própria ou de outras pessoas.

Aqui chego ao fim das 3P, mas com certeza há ainda muitas piores práticas de projetos que não foram citadas. Por isso, caso alguém queira colocar alguma prática que vivenciou ou conhece, por favor sinta-se à vontade. O seu comentário será bem-vindo!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK); Terceira edição, 2004. Project Management Institute, Four Compus Boulevard, Newton Square, PA 19073-3299 EUA.

http://www1.folha.uol.com.br/folha/esporte/ult92u450247.shtml

3P – Piores Práticas de Projeto (parte 1)

Melhores Práticas de Projeto é um dos temas que mais vem ganhando espaço no mundo de TI, pois percebemos que um bom gerenciamento é fundamental para o sucesso do projeto. Mas se temos as melhores práticas, quais seriam as piores práticas?

Abaixo explico algumas das piores práticas de projeto (3P) que devemos tomar cuidado para não cometemos:

Não envolvimento dos stakeholders – Por mais absurdo que possa parecer, essa é uma das práticas que mais acontecem, na qual um ou mais stakeholders (envolvidos com o projeto) não participam ativamente do projeto, ou participam apenas no início, ocasionando vários problemas, como requisitos mal especificados. Este é uns dos problemas que afetam diretamente o prazo e custo do projeto e em determinados casos, pode até representar o fim de um projeto. Um exemplo de não envolvimento dos stakeholders aconteceu com o projeto do Rodoanel, onde grupos ambientais não foram colocados como stakeholders no início do projeto, e esses acabaram gerando impasses para o governo, resultando em grandes atrasos nas obras e aumento do custo.

Contratação de funcionários, quando o projeto está atrasado –  No desespero, muitos gerentes acabam contratando novos funcionários, quando o prazo do projeto já está com seu prazo vencendo, pois acreditam na teoria de quanto mais pessoas mais produtividade. Porém, na prática a história é outra, esse novo funcionário, por mais habilidoso e experiente que seja, terá que receber um treinamento a ser dado por um funcionário, portanto o projeto perderá um funcionário ao invés de ganhar um. Para entender melhor, seria como você contratar um novo jogador de futebol faltando cinco rodadas para o término do campeonato, por mais habilidoso que ele seja, ele terá o seu tempo de adaptação e se ele for colocado em campo, o desentrosamento pode prejudicar o time.

Falta de documentação – essa é umas práticas mais adotadas pelas empresas, por parecer a curto prazo uma boa prática, pois economizará tempo. Porém, a longo prazo ela pode fazer com que o projeto seja o caos. Imagine a seguinte situação: na empresa XPTO Zé é  programador sênior e responsável por um módulo crítico da aplicação, porém não costuma documentar nada que faz, nem ao menos comenta o código. Um certo dia, Zé consegue um emprego melhor e sai da XPTO. E agora como o projeto continuará sem o Zé? Ele era o único que tinha conhecimento sobre aquele módulo e sem esse módulo o projeto não poderá ser entregue.

É pessoal, vocês podem estarem achando que tal situação apresentada não acontece nas empresas, mas por mais incrível que pareça essa é uma das que mais acontece e que faz muitos dos gerentes “arrancarem os cabelos” (quando ainda tem). Por isso o projeto tem que ser documentado e bem documentado.

Documentar no final – Não sei o que é pior, não documentar ou documentar no final do projeto. Uma documentação feita no final do projeto, por mais esforço que se faça, será fraca e imprecisa e a razão para isso é simples, as pessoas acabam esquecendo o que elas fazem. Para exemplificar uma pergunta clássica: o que você comeu ontem no almoço?

Talvez, você até se lembre do que você comeu ontem, mas e antes de ontem, e na semana passada?

Se eu fosse pedir para você me fazer uma documentação do seu almoço por um mês, ela teria que ser feita antes do almoço, onde você colocaria qual o restaurante que você vai almoçar, qual será o pedido, etc; durante o almoço, situação em que você falaria sobre a qualidade da comida escolhida; e após o término do almoço, você iria descrever como foi o atendimento e quanto custou o almoço.

Logo percebemos que a documentação é uma tarefa que tem que ser feita, durante todo o projeto e não somente durante uma determinada etapa do projeto.

Bem pessoal, por hoje é só. Em breve trarei a segunda parte do 3P. Até a próxima!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Qualidade de Software – Processo ou Projeto?

Essa é uma daquelas perguntas que muitos responderiam começando com “Veja bem” e como já diria um amigo meu, quando você inicia uma resposta com “Veja bem” você provavelmente irá enrolar, o popular “encher lingüiça”.

Antes de responder a essa pergunta precisamos, definir e diferenciar projeto de processo:

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. (PMBOK)

Um conjunto de atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados. (CMM)

Pela própria definição já conseguimos notar a diferencia principal entre projeto e processo, que é a duração de cada um. O projeto tem início, meio e fim, já o processo é contínuo. Para exemplificar essa diferença, vou usar dois exemplos:

O casamento é um projeto, ele tem início com os requisitos (igreja, tipo de comemoração, lua-de-mel, etc), meio com a elaboração do projeto (tempo, pessoas envolvidas, etc) e com a execução (convite dos convidados, aluguel do local da festa) e por fim o casamento em si.

A vida de casal seria (ou deveria ser) um processo, pois é contínua, já possui procedimentos (ex. almoço na casa da sogra no domingo) e artefatos (ex. o próprio almoço na casa da sogra) estabelecidos.

Qualidade de Software como processo

A Qualidade de Software é vista como processo, quando ela já tem um processo definido, regular e previsível, todo input (entrada) feito para a Qualidade de Software respeitará esse processo. Um exemplo seria a área de Qualidade de uma fábrica de Software, cujos softwares desenvolvidos passam pela Qualidade seguindo o processo dessa área. Ou seja, o processo será sempre reusado, o máximo que haverá será customizações e melhorias.

Qualidade de Software como projeto

Um grande projeto será desenvolvido pela empresa XPTO e será necessário o envolvimento da equipe de Qualidade atual da empresa e a contratação de novos funcionários. A equipe de Qualidade notou que o seu processo não está adequado para a magnitude do projeto, portanto ele terá que sofrer grandes modificações.

No caso citado acima, a Qualidade de Software será um “subprojeto” do projeto, portanto ele pode ser classificado como projeto de Qualidade de Software, afinal os esforços a serem dedicados serão temporários (o período do projeto). Haverá necessidades de renovação, mudança, criação e inovação, e o fluxo estabelecido poderá ser válido só para aquele projeto, e muitas vezes ele não será reusado em sua integridade em outros projetos, portanto ele se torna singular.

Conclusão

A visão de Qualidade de Software muitas vezes é confundida entre projeto e processo, ambos podem ser associados a Qualidade de Software. O diferencial para ela ser um processo ou um projeto será a maneira que ela é implantada na empresa. O importante é definir as atividades, métodos, práticas e tecnologias, pois são eles os componentes tanto de um processo quanto de um projeto.

Fique por dentro das novidades, assine o feed do QualidadeBR.

A Importância da Usabilidade

Pessoal, estou realizando o meu TCC sobre Interface Homem-Máquina (IHC), cujo foco principal é a usabilidade. Um dos motivos de ter escolhido esse tema foi há falta de preocupação das empresas e dos profissionais de TI com a usabilidade.

Um exemplo dessa despreocupação ocorre na própria faculdade, cujos trabalhos que envolvem o desenvolvimento de sistemas, muitas vezes não são avaliados tendo em vista a usabilidade do sistema e o que importa mesmo é a lógica e a utilização de conceitos aprendidos em sala de aula. Logicamente, que esses quesitos são de suma importância, principalmente em uma faculdade, porém e a usabilidade? Ela não deveria ter uma importância, ou vamos continuar com o pensamento arcaico que usabilidade é “perfumaria”?

Introdução

Há duas definições principais para usabilidade:

É a extensão na qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com efetividade, eficiência e satisfação em um contexto de uso específico. (ISO 9241-11)

Usabilidade está  relacionada ao  aprendizado,  eficiência, na  realização da  tarefa  de memorização,  minimização de erros  e  satisfação  subjetiva  do usuário. (Nielsen, J.)

A primeira definição é a mais formal feita pela International Organization for Standardization (ISO), já a segunda é feita pelo especialista em usabilidade Jakob Nielsen. Ambas tem o usuário como base, ou seja, a usabilidade está intrinsecamente ligada ao usuário, portanto todo esforço da usabilidade tem como objetivo tornar a aplicação mais usual e fazer com que o usuário tenha prazer na sua utilização.

A importância da usabilidade

Para explicar a importância da usabilidade, vamos usar o exemplo da evolução do celular: no início do milênio a maioria dos celulares, para não falar todos, tinham a navegação puramente textual e basicamente serviram para mandar mensagens, fazer/receber ligações, agenda e ainda continham alguns joguinhos. Você conseguia fazer uso dessas funcionalidades sem nenhuma dificuldade por meio dessa interface textual. Mas imagine hoje, se os novos celulares, ainda fizessem uso da interface por texto, seria impraticável fazer uso das dezenas de funcionalidades existentes nos celulares atuais, por isso a interface também teve que evoluir e hoje observamos um padrão, que basicamente é o de uso de ícones e menus.

O celular, assim como a internet, são as duas tecnologias que mais tem sofrido evoluções, quanto a usabilidade. E a razão para isso é simples, um grande número de pessoas fazem uso delas, portanto as interfaces tem que serem projetadas, tendo em mente que pessoas com diferentes graus de instruções terão que ser capazes de usar tais tecnologias.

Logo percebemos a importância da usabilidade, que é de fornecer uma interface o mais próxima do usuário e por meio dela que as barreiras entre o software e o usuário vão diminuindo.

Outro aspecto interessante, é que a usabilidade pode ser o fator decisivo pela adoção/compra de um produto. Um exemplo disso ocorreu na empresa que trabalho. Estávamos em busca de uma ferramenta de gerenciamento de testes, ficando entre dois softwares o Bugzilla e o JTester Manager (ferramenta desenvolvida pela própria empresa), o Bugzilla ganhava em número de funcionalidades, porém tinha um grande problema, a usabilidade: fluxo não era linear, continha muitos campos em uma mesma tela, etc. Enquanto o JTester Manager continha as funcionalidades essenciais e uma ótima usabilidade, devido principalmente a sua simplicidade. A decisão então foi fazer uso do JTester Manager, pois percebemos que a produtividade com o JTester Manager seria bem maior do que com o Bugzilla.

Conclusão

A usabilidade deve ser encarada com seriedade e ser focada no usuário, afinal será ele que fará o uso do software. E caso não começarmos a nos preocupar com a usabilidade, os usuários dos nossos sistema podem ter um acesso de fúria, assim como esse senhor teve no vídeo abaixo:

Aliás, quantas vezes você mesmo(a) já não se irritou por não ter conseguido realizar alguma tarefa, devido a falta de usabilidade do software?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Nielsen, J. (1993), Usability Engineering. Academic Press, Inc., San Diego.