The films

4.2.6.1DIFICULDADES NO PROCESSO DE LEVANTAMENTO DE REQUISITOS Uma das dimensões desta categoria foi a falta de coesão entre os stakeholders nas solicitações. Tratando de projetos inovadores, os clientes podem não saber exatamente que tipo de produto precisam ou como o processo será realizado. Assim, pode ser difícil externar para o responsável pela etapa de levantamento de requisitos exatamente o que esperam do produto que estão desenvolvendo.

Tem a própria regra de negócio do cliente, que ele acaba querendo mudar, que às vezes

nem ele define bem aquilo que ele quer. Participante da empresa A.

[...] então nós temos que fazer o papel de ir lá compreender todo processo dele, trazer pra cá e a gente faz esse interface. Tem clientes que ele tá tão perdido que nós acabamos assumindo o papel de cliente mesmo. Participante da empresa E.

Além da dimensão da inovação no processo, existe também a comunicação entre os envolvidos. Os entendimentos e significados podem ser diferentes para clientes e desenvolvedores.

[...] porque nessa área existem algumas coisas que a gente vai aprendendo com o tempo: os linguajares, os jargões, né? Então às vezes o que pra mim é uma coisa, pra ele é outra. Participante da empresa F.

Além dessas dificuldades também surgiram as indicações de que os problemas nessa etapa podem influenciar o fechamento – e possível – atraso do projeto.

Prazo de entrega fica apertado em relação a

essas questões, no processo, dessas

distorções de informação, tem muito disso, da compreensão do próprio programador, do próprio analisa, saber se é isso que ele quer. Participante da empresa A.

Eu faço o escopo inicial, eu faço o plano de projeto, começo a rodar, você começa a me demandar alterações, mudanças, eu vou te atender, eu vou fazer análise de impacto, aquele negócio todo, te apresento os cenários, tu toma a decisão, re-pacto o cronograma contigo, re-pacto o plano de projeto. Participante da empresa C.

As dificuldades apontadas nessa subcategoria são discutidas por outros autores (SOMMERVILLE, 2007; TONSIG, 2008; PRESSMAN, 2011) e poderiam ser auxiliadas por um designer. Esta situação, revelada na fala dos participantes, poderia ser revertida com o uso de métodos de design, utilizados no desenvolvimento de novos produtos. 4.2.6.2NECESSIDADES DO USUÁRIO OU DO CLIENTE?

Nem todos os participantes conseguiram explicar quem era consultado para verificar as necessidades: se o usuário do software ou o contratante. De forma geral, os participantes demonstraram ter mais contato com o cliente do que com o usuário final. Assim, era possível perceber que o usuário dificilmente expunha suas necessidades perante o sistema.

Me interessa é saber o que o cliente precisa pra melhorar o processo dele. Então é ele

que dá as coordenadas. Claro,

provavelmente ele coletou isso do usuário dele, mas eu não tenho contato com o usuário dele. O cliente é que vai me dizer. Participante da empresa A.

Eles já tem um histórico de anos de acidentes de trabalho, de o que pode ocasionar um acidente de trabalho, então quando vem o briefing, já vem muito mastigado pra gente. Então a gente não chega no nível de pegar, sentar agora com o operário lá da plataforma pra “tá trocando uma ideia com ele sobre esse tipo de...”, pra “tá pegando a percepção dele sobre o desenvolvimento desse sistema”. Participante da empresa D.

[...] essa parte de necessidades a gente consegue pegar porque é o próprio gestor com quem a gente conversa. Participante da empresa E.

Dessa forma, imagina-se quem é o usuário por meio de uma elaboração feita pelo cliente, mas não se verifica, de forma objetiva, quem irá utilizar o sistema. Mesmo que o gestor conheça as necessidades de resultado do software, o usuário não é consultado, gerando assim uma cadeia de informações que podem ser distorcidas. 4.2.6.3A RESPONSABILIDADE PELO FRACASSO

Uma das percepções interessantes deste trabalho foi a responsabilização dos clientes pelo insucesso de uma funcionalidade ou de uma implementação.

Porque já aconteceu de cliente nosso não reclamar, tava pagando e não tava usando. Tanto que chegou uma hora que ele não conseguiu aculturar o grupo de parceiros dele lá dentro da empresa, que ele abriu mão e quis encerrar o contrato. Participante da empresa A.

Porque ele domina a regra de negócio, é o nicho dele. Nós somos meros espectadores, aprendendo a regra de negócio dele. Tanto que às vezes ele se equivoca e a gente tem que refazer um trabalho. Participante da empresa A.

O que acontece é que em 90% dos casos, os projetos eles sofrem interferência externa, então tem fatores como a falta de um requisito ou a falta do cliente aprovar uma determinada funcionalidade, ele atrasa o projeto. Ou às vezes algum requisito, alguma coisa nesse sentido. Isso é que tem atrasado. Participante da empresa E.

Às vezes ele não entendeu a tela, não entendeu o processo e tá tão acostumado naquela coisa operacional “eu tenho que fazer, eu tenho que fazer aquilo, tenho que

fazer aquilo” ele não para e analisa o contexto. Participante da empresa F.

As dificuldades no relacionamento com o cliente se iniciam no levantamento de requisitos e culminam na indicação de que o cliente – ou o usuário – não compreende a ferramenta e sua funcionalidade. Assim, o cliente é responsabilizado pelo atraso ou pela falta de aceitação de um produto.

As subcategorias aqui citadas se apresentam como desafios para o design no intuito de colaborar com o desenvolvimento de software. Como é possível perceber, os desafios se encontram, basicamente, na etapa de levantamento de requisitos, em que o contato com o cliente e com o usuário são fundamentais para descobrir as necessidades e expectativas em relação ao produto que será desenvolvido.