• Os impactos da coleta de requisitos amadora

    03 de maio de 2017

Eu sei, você provavelmente já leu a respeito e até coleta requisitos em seu trabalho ou já acompanhou o gerente de projetos (GP) da sua equipe fazer isso. Então, para coletar requisitos, basta fazer uma lista das funções que o cliente deseja que o aplicativo ou o sistema atenda e passar para a equipe programar, certo? Errado, não é tão simples assim.

Nesse artigo iremos abordar algumas peculiaridades da coleta de requisitos que são cruciais para o sucesso (ou o fracasso) de um projeto. Vamos lá!

O que é requisito?

Se você já compreende o conceito de requisito, talvez queira pular para o próximo tópico. Se você estiver chegando agora no vasto mundo da programação e ainda esteja assimilando os novos termos utilizados na área, continue lendo esse tópico.

Uma definição bastante objetiva do termo, do Project Management Institute (PMI) é a seguinte:

“Requisito é uma condição ou capacidade cuja presença em um produto, serviço ou resultado é exigida para satisfazer um contrato ou outra especificação formalmente imposta.”

Existem diversas boas definições, mas acredito que essa resume bem o que é o requisito, sem ambiguidade ou significados ocultos. Nesse artigo vamos considerar o requisito então como uma “condição exigida para satisfazer um contrato”, porque é exatamente assim que as empresas de soluções de software veem na prática.

Importante acrescentar que eu não considero correto o termo “coletar”, porque dá a ideia de que os requisitos já estão previamente definidos e que basta agrupa-los que o trabalho está feito. Na verdade, trata-se mais de descobrir requisitos. Sim, porque muitas vezes o próprio cliente não sabe ainda o que precisa e como gerente de projetos você precisa compreende-lo e compreender quem são os usuários finais para concluir essa busca.

Por que é tão importante?

Na rotina de uma empresa que presta serviços de software como é nosso caso, com enfoque no desenvolvimento mobile, é muito comum receber uma listagem com a descrição das funções que o app precisa ter – isso ocorre logo no início, na fase de orçamento do projeto. Para que a entrega aconteça com sucesso e o produto final mantenha relevância, primeiramente é importante entender quais são os problemas do negócio que o aplicativo deve ser capaz de amenizar ou, de fato, resolver. Ou, como adiantei acima, quem são os usuários finais da ferramenta e o que eles querem.

Para refletir: se um médico diagnosticar e prescrever tratamentos a um paciente sem antes examina-lo devidamente, tal ato é considerado má prática, então por que é normal ou “aceitável” começar um projeto sem ao menos entender o que o usuário final precisa? No segundo caso não há consequências diretas na saúde ou na vida de uma pessoa, porém as implicações em um projeto que começou errado são bem graves e podem até custar seu emprego, caro(a) programador(a).

Talvez em seu trabalho você já tenha presenciado ou até participado de um projeto problemático que parecia não ter fim, mas será que além de atraso no cronograma existem outras consequências graves quando a equipe não entende o que é para ser feito? É o que discutiremos a seguir.

development-team-meeting-blog-Caeno

Sinergia e comunicação entre equipe envolvida e cliente, durante todo o processo, é fundamental.

Impactos de requisitos mal coletados

Existem cases de projetos que falharam por problemas de comunicação entre fornecedores e clientes, suficientes para que o gerente de projetos seja mais cauteloso e dê a devida atenção ao escopo do projeto. No entanto, muitos profissionais continuam cometendo os mesmos erros básicos. Quer um exemplo? A Ford Motor Company, fundada por Henry Ford em 1903, estava desenvolvendo um sistema junto à Oracle e após longos quatro anos de execução encerrou o projeto e “o declarou morto” com um prejuízo de 400 milhões de dólares. Sim, você leu certo, foram 400 milhões de dólares! O motivo? Problemas de interface e UX que prejudicaram a experiência dos usuários finais e integrações que não funcionavam. Esses problemas são na verdade consequências diretas da falta de comunicação e péssimo gerenciamento do escopo do projeto.

Algumas ações básicas poderiam ter evitado esse desastre, como a combinação de técnicas de coleta de requisitos, utilização de ferramentas eficientes para registrar o escopo, documentação mais rigorosa, etc. O ponto é que o impacto financeiro não parou só nesses 400 milhões, mas também no retorno sobre o investimento (ROI) que a Ford esperava receber a longo prazo – o que deveria ser pelo menos 10 vezes maior que o valor investido.

Além do prejuízo financeiro e do tempo despendido para não obter o produto final, uma grande consequência é que a Ford está defasada com relação aos concorrentes que já conseguiram criar um sistema capaz de facilitar o dia a dia de seus funcionários, seja para acessar informações de negócio com a ferramenta ou evitando custos de impressões em papel (objetivos iniciais da empresa ao solicitar os serviços para a Oracle).

Aqui utilizamos um exemplo de grande escala para que fique claro que requisitos não são parte apenas da rotina de startups ou empresas de pequeno e médio porte, mas também de multinacionais e mesmo elas cometem erros! No caso de um projeto mobile, os prejuízos são proporcionais ao tamanho e duração do mesmo. Outras consequências são:

  • Perda de confiança do cliente na empresa;
  • Pressão sobre os desenvolvedores (retrabalho, horas extras, etc);
  • Pressa na concepção do sistema (escopo aberto ou ambíguo é igual a projeto problemático);
  • Perda de oportunidades de fechar novos negócios, quando a equipe não é suficiente para assumir novos projetos. 

Um estudo da NASA revelou que para cada etapa do desenvolvimento de um produto em que ocorre mudança de requisitos, o custo aumenta em dez vezes. Essa é a prova de que quanto mais tempo as empresas levam para compreender as reais necessidades do usuário e documentar essas descobertas apropriadamente, mais furado fica o escopo e maior o custo final. Agora imagine uma empresa de desenvolvimento com equipe pequena, que fechou um contrato com um cliente e possui alguns projetos ocorrendo em paralelo (portanto tem pouco ou nenhum pessoal disponível para o trabalho): o prejuízo maior vai ser da empresa que já cobrou do cliente e de sua equipe que se comprometeu com a entrega. Se seguir dessa forma essa empresa não vai durar muito tempo no mercado ou, se durar, pode acabar com baixa lucratividade e com uma equipe desmotivada pela pressão e má remuneração. 

O sucesso de um projeto significa ganho para o cliente e para a equipe envolvida, por conta disso é que na Caeno temos um processo estratégico, bastante claro, para realizar a coleta e documentação de requisitos e também buscamos combinar diversas técnicas de coleta para evitar esses erros amadores (comente abaixo se tem interesse em ler um artigo sobre isso).

Esperamos que essa discussão tenha sido relevante para você e que tenha proporcionado uma reflexão sobre por que não podemos pular essa etapa tão importante – ou simplesmente faze-la de qualquer jeito.

—–

E você, o que você pensa a respeito do processo de coletar requisitos? Já trabalhou em algum projeto complicado em que o escopo incorreto prejudicou a entrega? Compartilhe sua opinião, abaixo nos comentários, e ajude a enriquecer essa discussão. 🙂

Share

Adoro estar envolvida no processo de criação de aplicativos e tudo o mais que envolve mobile. Apesar de ser Relações Públicas por formação, sempre tive um pé na área de tecnologia: possuo conhecimentos no co-gerenciamento de projetos, suporte à área de Design para mobile e social media. Procuro sempre estar por dentro do universo mobile e pretendo compartilhar todas as novidades com os leitores no blog da Caeno.

Leia também

7 erros que podem acabar com seu aplicativo
Design
18 de julho de 2016

7 erros que podem acabar com seu aplicativo

Já aconteceu com você a seguinte situação: em busca por determinado conteúdo ou serviço, você instalou um aplicativo e percebeu que alguma coisa não estava legal ou como o esperado? Qual sua reação nessa situação? Talvez não seja o seu caso, mas muitos usuários se sentem frustrados pelo tempo perdido instalando o app e acabam o […]

LEIA MAIS
Parem de dizer que aprender a programar é fácil
Programação
22 de junho de 2016

Parem de dizer que aprender a programar é fácil

Atenção: essa á uma tradução livre do texto Stop saying learning to code is easy, de autoria de Scott Hanselman, publicado originalmente em seu blog em 17/06/2016. Para conhecer mais a respeito de seu trabalho acessem hanselman.com. Eu vi esse tweet após o Keynote do WWDC da Apple e pensei a mesma coisa. Perdi, programar […]

LEIA MAIS
.NET Core é lançado (e porque isso é importante!)
.NET
10 de julho de 2016

.NET Core é lançado (e porque isso é importante!)

O dia 27 de junho marcou o lançamento oficial do Microsoft .NET Core 1.0. Mas por que você deveria me preocupar com isso? Alias, que diabos é esse tal de .NET Core? Vamos explorar um pouco desse universo e entender porque esse é um marco significativo não só para as comunidades de desenvolvedores Microsoft mas […]

LEIA MAIS

Comentários