The Standish Group e diversas outras fontes consistentemente indicam o envolvimento do usuario como um dos três mais importantes fatores que contribuem para o sucesso de um projeto de desenvolvimento de software.

O fato de que isto necessite ser dito pode parecer espantoso para os ainda não iniciados na fascinante vida corporativa. Mas a experiência tem demonstrado que as coisas não funcionam bem assim: desenvolvedores são notórios por tomar tempo da implementação das core features do produto para introduzir “interessantes” e não requeridos recursos; a área de marketing frequentemente trabalha com a filosofia “quanto mais melhor”, onde todas as features têm prioridade 100%.

Como resultado, os projetos são entregues meses (ou anos) depois do prazo inicial e o produto é uma combinação de recursos inúteis com cruciais requisitos precariamente implementados. Ou mesmo ausentes.

Além da frustação em ambos os lados, a necessidade de consertar ou refazer o produto gera uma conta salgada que alguém vai pagar. Dependendo do caso, pode ser a diferença entre continuar no mercado ou não.

Se é assim tão importante e traz tantos benefícios, por que é tão incomum envolver o usuário na criação do produto que ele está pedindo?

Existem diversas respostas. A primeira é que é um fenômeno cultural. Vinte anos de engenharia de software ainda não foram suficientes para familiarizar as corporações com o fato de que desenvolvimento de software requer intensa participação do usuário. A idéia de que requisitar software dá trabalho, muito trabalho para o usuário, ainda causa espanto na maioria dos gerentes de negócio.

Por outro lado, a idéia de que o time de desenvolvimento não é o melhor grupo para tomar decisões sobre que recursos incluir/tirar do produto, sua interface, aspectos de usabilidade, etc, ainda não é um mantra adotado de coração pelas áreas de sistema.

Mesmo quando há o reconhecimento da necessidade de envolver o usuário pode ser difícil identificá-lo. No caso de produtos de prateleira, este é um desafio significativo. Respostas frequentes são os programas de beta-teste, caríssimos laboratórios de usuabilidade ou mesmo contratação de especialistas no assunto (domain experts) de outras empresas.

Internamente à empresa, um bom projeto vai passar pela fase de identificar quais são as classes de usuários do produto. Com base neste identificação, vai categorizar as classes de usuários em termos de importância para o sucesso do projeto e definir estratégias de relacionamento com os representantes das mesmas. Algumas classes vão ser mais e outras vão ser menos favorecidas. A experiência do analista ou do gerente de projeto nesta decisão vai ser crucial para o sucesso do mesmo.

Identificados os representantes de usuários que mais vão contribuir para o projeto, há uma miríade de estratégias, tecnicas e procedimentos que podem ser aplicadas para obter o melhor retorno desta interação, mas este é um vasto assunto para outros postings.

O que não deve variar é o entendiento de que o envolvimento do usuário não é só na etapa de levantamento de requisitos mas é algo que acontece ao longo de todo ciclo de vida do projeto.

Fica claro que significativo incremento na taxa de sucesso de projetos de desenvolvimento de software pode advir da transformação cultural acima proposta.

No entanto, as condições para que isto aconteça vão variar de caso para caso e não raro vão ser muito reduzidas. Frequentemente, o contexto cultural e principalmente injunções políticas internas vão prejudicar a qualidade das decisões dos gerentes de projeto e dos grupos de desenvolvimento. Ou vão mesmo tirar-lhes a capacidade de tomar certas decisões.

O argumento de que não há tempo para montar e executar o projeto da maneira certa jeito é comum. Conheço uma empresa que está indo para a terceira versão de uma de suas aplicações mais críticas porque o desenvolvimento das duas versões anteriores enfrentou problemas os mais diversos. Em ambos os casos, pressa para colocar o produto no ar - “porque não havia tempo para esperar mais” - foi um fator preponderante no surgimento de inúmeros equívocos.

O velho adágio se repete: “não há tempo para fazer a coisa certa na primeira vez mas há sempre tempo para refazer mais tarde”.

É importante que nestes casos, mesmo se sentindo de mãos atadas, o responsável pelo projeto registre perante a área de negócios o impacto que framework em que sua equipe estará trabalhando pode acarretar em termos de prazo e custo do projeto, bem como qualidade do produto.

Algumas vezes, isto vai requerer certa coragem, mas é melhor tomar esta atitude no início do projeto que ser o alvo número 1 na hora em que a caça às bruxas começar.

[Home] [IT] [Oracle/Db] [SD] [PM] [Lendas Corporativas] [Diversas] [The Secret of Life] [About IT talks]