DO DESEJO AO ARTEFATO: AVALIANDO A GESTO DE VALORES NO DESENVOLVIMENTO GIL DE SOFTWARE

por Erton Wagner Vieira da Silva Dissertao de Mestrado

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CIN - CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE, FEVEREIRO DE 2012.

ii

Erton W. Vieira

iii

UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO CIn - CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

ERTON WAGNER VIEIRA DA SILVA

DO DESEJO AO ARTEFATO: AVALIANDO A GESTO DE VALORES NO DESENVOLVIMENTO GIL DE SOFTWARE

Dissertao apresentada como requisito parcial obteno do grau de Mestre em Cincia da Computao, rea de concentrao em Mdias e Interao, do Programa de Psgraduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco.

ORIENTADOR: Alex Sandro Gomes.

RECIFE, FEVEREIRO DE 2012.

Erton W. Vieira

iv

Erton W. Vieira

Dedico este trabalho aos meus pais, e a Emerson Leandro, que mostrou que um Vieira duro na queda.

Erton W. Vieira

vi

Erton W. Vieira

vii

Agradecimentos

Meus sinceros agradecimentos minha famlia pelo suporte e confiana em minhas realizaes. Aos meus amigos, por compreenderem minha ausncia e torcerem por mim sempre. Aos meus colegas de mestrado por compartilharem da luta e das glrias alcanadas nessa jornada. Ao meu orientador Alex Sandro Gomes, por ter acreditado no projeto e em mim como pesquisador. A toda equipe do REDU que me acolheu como seu eu fosse um deles e que abriu as portas da empresa para o meu estudo.

Erton W. Vieira

viii

Stay hungry, stay foolish

Steve Jobs

Erton W. Vieira

Resumo
Com a estabilidade da economia brasileira, ela se tornou propcia a uma forma de empreendedorismo denominada de startup. Pequenos empreendimentos com um grupo de pessoas com uma ideia, procura de um modelo de negcio que possa ser replicado e que trabalham em condies de incerteza se vo ou no gerar lucros, esse a realidade de muitos startups. Para que essas incertezas diminuam o usurio do produto ou servio de um startup deve ser analisado e estudado. Este Estudo de Caso acompanha o REDU, startup pernambucano, em sua jornada de conhecer a si mesmo como empresa, o seu produto, a rede social REDU, e conhecer os seus usurios. A pesquisa focou-se nos valores que a empresa definiu para o seu produto e como esses valores esto impactando na experincia do usurio ao utilizar o sistema. Levando em considerao que a equipe utilizou metodologia gil de desenvolvimento de software, o que poderia dificultar o projeto de design da experincia. Atravs de entrevistas, questionrios e observaes dados foram coletados para avaliar se o projeto da experincia nesse ambiente gil de desenvolvimento e a prpria experincia do usurio eficiente, eficaz e satisfatria. Para isso foram utilizados definies do que experincia e como definir a qualidade de uma experincia com o usurio. A discusso dos resultados apontam caractersticas de desenvolvimento e experincia que podem ser replicadas por qualquer startup que esteja nas mesmas condies que o REDU. Adaptaes essas que podem ser na metodologia de desenvolvimento ou em um maior cuidado na integrao entre os valores da empresa e o experincia do usurio. Palavras-chave:,Startup, aprendizagem. Desenvolvimento do cliente, Tecnologia avanada de

Erton W. Vieira

10

Abstract
With the stability of the Brazilian economy, it became a way conducive to business startup called. Small enterprises with a group of people with an idea, looking for a business model that can be replicated and working in conditions of uncertainty whether or not to generate profits, this is the reality of many startups. To reduce these uncertainties the user of the product of a startup should be analyzed and studied. This case study accompanies the REDU, startup from Pernambuco, on their journey of knowing yourself as a company, your product, the social network REDU, and meets their users. The research focused on the values that the company set for your product and how these values are impacting on the issue of user experience when using the system, taking into consideration that the team used Agile software development, which could hinder the project's design experience. Through interviews, questionnaires and observations, data were collected to assess whether the project experience in agile development environment and user experience is efficient, effective and satisfactory. For this we used definitions of experience and how to define the quality of user experience. The discussion of the results showed growth characteristics and experience that can be replicated by any startup that is under the same conditions of the REDU. These adjustments can be in the development methodology or a more careful integration between the company's values and user experience.

Keywords: Start up, customer development, technology enhanced learning.

Erton W. Vieira

11

ndice
RESUMO ............................................................................................................................................................ 9 ABSTRACT ........................................................................................................................................................ 10 NDICE .............................................................................................................................................................. 11 LISTA DE FIGURAS ............................................................................................................................................ 13 LISTA DE QUADROS .......................................................................................................................................... 14 PRINCIPAIS ABREVIAES ................................................................................................................................ 15 1. INTRODUO .......................................................................................................................................... 16 1.1 1.2 1.3 1.4 1.5 1.6 2. JUSTIFICATIVA ................................................................................................................................................... 17 HIPTESE E QUESTO DE PESQUISA....................................................................................................................... 20 OBJETIVO GERAL ............................................................................................................................................... 20 OBJETIVOS ESPECFICOS ...................................................................................................................................... 20 O PESQUISADOR ................................................................................................................................................ 21 ESTRUTURA DA DISSERTAO............................................................................................................................... 22

GESTO DE VALORES NO DESENVOLVIMENTO GIL DE SOFTWARE .......................................................... 23 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 PROPOSIO DE VALOR ...................................................................................................................................... 24 DESIGN E O VALOR PERCEBIDO ............................................................................................................................. 26 EXPERIENCE DESIGN ........................................................................................................................................... 28 PROJETANDO EXPERINCIA DO USURIO ................................................................................................................ 33 DESIGN DA EXPERINCIA COM PROCESSOS GEIS DE DESENVOLVIMENTO DE SOFTWARE ................................................. 36 PROJETANDO O DESIGN DA EXPERINCIA COM PROCESSOS GEIS................................................................................ 39 QUALIDADE NA EXPERINCIA................................................................................................................................ 46 ANLISE DO REFERENCIAL TERICO ....................................................................................................................... 49

3.

MTODO DE PESQUISA ............................................................................................................................ 50 3.1 PARADIGMA DE PESQUISA ................................................................................................................................... 51 3.2 OBJETIVOS ....................................................................................................................................................... 52 3.3 ESTRATGIA DE PESQUISA: ESTUDO DE CASO .......................................................................................................... 55 3.4 CASO: REDU ..................................................................................................................................................... 56 3.5 PROCEDIMENTOS E INSTRUMENTOS DE COLETA DE DADOS.......................................................................................... 59 3.5.1 Entrevista .......................................................................................................................................... 60 3.5.2 Observao ....................................................................................................................................... 60 3.5.3 Pesquisa Documental ........................................................................................................................ 61 3.5.4 Registro de Arquivos ......................................................................................................................... 61 3.6 ANLISE DOS DADOS COLETADOS ......................................................................................................................... 62

4.

ANLISE DOS RESULTADOS ...................................................................................................................... 64 4.1 PERFIL REDU ................................................................................................................................................... 65 4.2 ANLISE DOS DADOS .......................................................................................................................................... 67 4.3 IDENTIFICAR QUAIS OS VALORES DA EMPRESA E COMO ELES FORAM DEFINIDOS............................................................... 68 4.4 DESCREVER O PROCESSO TCITO DO DESIGN EXPERIENCIAL ADOTADO NA EMPRESA ......................................................... 70 4.4.1 Desenvolvimento e os valores ........................................................................................................... 71 4.4.2 Adaptao do designer ao Scrum ..................................................................................................... 74 4.4.3 Adaptao da equipe de desenvolvimento ao designer ................................................................... 78 4.4.4 Testes com usurios .......................................................................................................................... 85 4.5 DESCREVER A EXPERINCIA DO USURIO DO REDU. ................................................................................................. 87 4.5.1 Intuitivo ............................................................................................................................................. 89 4.5.2 Fcil ................................................................................................................................................... 94

Erton W. Vieira

12
4.5.3 Na Moda ........................................................................................................................................... 98 4.5.4 Conveniente .................................................................................................................................... 100 4.5.5 Produtivo......................................................................................................................................... 104 4.5.6 Divertido ......................................................................................................................................... 110 4.6 ENCONTRAR PONTOS EM COMUM ENTRE AS VARIVEIS QUE DESCREVEM O PROCESSO TCITO ADOTADO PELA EMPRESA E O DESIGN DA EXPERINCIA. ............................................................................................................................................. 113 4.6.1 Critrios de Qualidade da Experincia segundo Alben (1996) ........................................................ 113 4.6.2 CUE Model ...................................................................................................................................... 122 5. CONSIDERAES FINAIS ........................................................................................................................ 125 5.1 DISCUSSO ..................................................................................................................................................... 126 5.1.1 A adoo e ajuste do mtodo ......................................................................................................... 126 5.1.2 Incorporao de prticas de design da experincia ........................................................................ 127 5.1.3 Separao consciente de processos internos .................................................................................. 128 5.1.4 Cooperao cientfica e transferncia de conhecimento acadmico .............................................. 130 5.2 CONCLUSO FINAL ........................................................................................................................................... 131 5.3 LIMITAES DA PESQUISA. ................................................................................................................................ 133 5.4 SUGESTES PARA TRABALHOS FUTUROS ............................................................................................................... 134 5.5 AGRADECIMENTOS ........................................................................................................................................... 134 6. REFERNCIAS ......................................................................................................................................... 135

ANEXOS E APNDICES ..................................................................................................................................... 142

Erton W. Vieira

13

Lista de Figuras
FIGURA 2.1 - WORKFLOW, REGRAS E RESPONSABILIDADES DOS TIMES DE UX TRABALHANDO EM METODOLOGIA GIL. ........................ 44 FIGURA 4.1 PLANILHA DE REVISO DE INTERFACE ................................................................................................................ 82 FIGURA 4.1 UTILIDADE DO LAYOUT. ................................................................................................................................. 90 FIGURA 4.2 SEQUNCIA DE TELAS. .................................................................................................................................... 90 FIGURA 4.3 PRXIMA TELA NA SEQUNCIA. ........................................................................................................................ 91 FIGURA 4.4 VOLTANDO PARA A TELA ANTERIOR .................................................................................................................. 92 FIGURA 4.5 PROGRESSO DO TRABALHO. .......................................................................................................................... 92 FIGURA 4.6 RESULTADO PREVISVEL NA EXECUO DAS TAREFAS ............................................................................................ 93 FIGURA 4.7 DIFCIL X FCIL. ............................................................................................................................................ 95 FIGURA 4.8 INCIO DO USO. ............................................................................................................................................ 96 FIGURA 4.9 TEMPO DE APRENDIZADO NA UTILIZAO. ......................................................................................................... 96 FIGURA 4.10 TERRVEL X ADMIRVEL. .............................................................................................................................. 98 FIGURA 4.11 INADEQUADO X ADEQUADO........................................................................................................................ 100 FIGURA 4.12 QUANTIDADE DE INFORMAES NA TELA. ...................................................................................................... 105 FIGURA 4.13 DISTRIBUIO DA INFORMAO NA TELA. ...................................................................................................... 105 FIGURA 4.14 TERMINOLOGIA RELACIONADA AO TRABALHO. ................................................................................................ 106 FIGURA 4.15 FRUSTRANTE X SATISFATRIO...................................................................................................................... 111 FIGURA 4.16 TEDIOSO X ESTIMULANTE. .......................................................................................................................... 111 FIGURA 4.17 VERSO ANTIGA DO REDU. ........................................................................................................................ 119 FIGURA 4.18 REDU MNIMO (ATUAL). ........................................................................................................................... 120

Erton W. Vieira

14

Lista de Quadros
QUADRO 2.1 - ASPECTOS PARA IMPRESCINDVEIS PARA UMA BOA EXPERINCIA (SHEDROFF, 2001) ................................................ 30 QUADRO 2.2 - COMPARAO ENTRE METODOLOGIAS GEIS E CONVENCIONAIS (ADAPTADO DE ULLAH E ZAIDI, 2009)..................... 37 QUADRO 4.1 EQUIPE REDU ........................................................................................................................................... 66 QUADRO 4.2 EQUIPE REDU EM PARALELO EQUIPE DE DESIGN DA EXPERINCIA DE YAMAZAKI E FURUTA (2007) .......................... 67

Erton W. Vieira

15

Principais Abreviaes
AL1 AVE AVEA CA CCTE CM D1 EAD GP1 IBGE ID IHC LCMS LMS LT1 LT2 P3 P4 PO PR REDU UX XP Aluno Ambiente Virtual de Aprendizagem Ambiente Virtual de Ensino e Aprendizagem Consultor Acadmico Cincias Cognitivas e Tecnologias Educacionais Consultor de Mercado Designer 1 Educao a Distncia Gerente de Projetos 1 Instituto Brasileiro de Geografia e Estatstica Interaction Design Interao Humano-Computador Learning Content Management System Learning Management System Lder de Trabalho 1 Lder de Trabalho 2 Desenvolvedor 3 Desenvolvedor 4 Product Owner Professor Rede Social para Educao User Experience Extreme Programming

Erton W. Vieira

16

Captulo

1
1. Introduo
Este captulo relata as principais motivaes realizao deste estudo, sua justificativa, questo de pesquisa, lista os objetivos de pesquisa almejados e, finalmente, mostra como est estruturado o restante da presente dissertao.

Erton W. Vieira

17

1.1 Justificativa

A economia do pas est beneficiando pessoas que com ideias inovadoras esto empreendendo. Estes empreendimentos ocorrem de diversas formas, mas uma forma de empreendimento em especial est chamando a ateno de investidores: as startups. Boris Hermanson (2011), consultor do SEBRAE, considera startups empresas de pequeno porte, recm-criadas ou ainda em fase de constituio, com atividades ligadas pesquisa e desenvolvimento de ideias inovadoras, cujos custos de manuteno sejam baixos e ofeream a possibilidade de rpida e consistente gerao de lucros. Ele ainda afirma que alm disso, o negcio desenvolvido pelo startup deve ser vivel, ou seja, que ele ser no s sustentvel, mas que apresente tambm potencial de sucesso.

Com foco em inovaes tecnolgicas, startups esto se multiplicando nos polos tecnolgicos brasileiros, com produtos e solues inovadoras. E o cenrio em que estes empreendimentos esto surgindo s impulsiona mais investimentos. Trs pontos importantes tem que ser citados: muitas pessoas esto querendo investir seu dinheiro nas solues desenvolvidas por startups. Com isso, dinheiro no falta para quem tem uma boa soluo e no tem como investir nela; o custo para montar startups baixo; e estrangeiros esto investindo muito no mercado brasileiro de startups. Esse cenrio ajuda na proliferao desse setor. Em matria recente da Revista poca Negcios de setembro de 2011, os investimentos em startups em 2009 chegaram casa dos 36 bilhes de dlares.

Contudo, para montar startups necessrio ter uma soluo inovadora e pessoas que queiram pagar por essa soluo. Steve Blank (2005) observou que os empreendimentos no davam certo, no por falta de tecnologia ou ideias inovadoras e sim por falta de clientes interessados nas ideias. Ento no existe startup sem antes ter uma viso clara de quem poder ser o consumidor.
Erton W. Vieira

18

Abordando esse tpico, Blank (2005) desenvolveu uma metodologia de desenvolvimento de clientes, que se encaixa muito bem no esprito de startups, segundo a qual ele mostra 4 passos a serem seguidos afim de garantir que a soluo desenvolvida tenha os seus consumidores: primeiro passo descobrir o cliente, as pessoas que podem se interessar por suas ideias; depois de o empreendedor validar o cliente, com uma parte da soluo j pronta ele vai junto ao cliente e testa com ele a aceitao, se a aceitao no foi favorvel, ento a ideia tem que ser melhor trabalhada ou o publico no mostra-se adequado para essa soluo, nesse caso, volta para o primeiro passo; depois de validar a ideia o empreendedor vai criar clientes, que seria a fase do lanamento da soluo completa e em larga escala; e por fim, necessrio construir uma companhia, da forma tradicional, com departamentos, contratando pessoas.

Essa metodologia desenvolvida por Blank influenciou outros estudos na rea de desenvolvimento de startups. Como o trabalho realizado por Eric Ries (2011) que uma forma de implementar a cultura de conhecimento adequado para desenvolvimento de startups, focado principalmente naquelas que trabalham com softwares. uma metodologia cclica que foca o aprendizado adquirido em cada ciclo: Partindo de ideias construdo um produto, ento medido o resultado atravs de coleta de dados e finalmente so aprendidas algumas lies sobre o processo.

Esse ciclo tem que ser validado e dificilmente o empreendedor vai acertar no primeiro ciclo. Normalmente ser necessrio fazer ajustes. Se a ideia falha ento o Ries indica o uso do PIVOT. Ries define PIVOT como uma mudana de direcionamento do produto, mantendo as caractersticas que foram aprovadas pelos consumidores e utilizando o conhecimento que adquirido durante o ciclo do processo. O PIVOT pode ser uma adaptao simples ou uma total mudana no produto. Quanto mais ciclos forem realizados, mais chances de encontrar um modelo de negcio que seja eficiente.
Erton W. Vieira

19

Contudo, as chances de falha de uma startup so ainda grandes. O prprio Eric Ries cita algumas razes:

- A primeira o fascnio que o empreendedor tem por um bom plano, uma estratgia slida e pesquisas robustas de mercado. Em pocas anteriores, essas eram indicadores de provvel sucesso. Existe a tentao de utilizar esses conceitos em startups tambm, mas no funciona, pois startups operam com muita incerteza. Startups, dificilmente comeam sabendo quem so seus clientes e o que seu produto ir se tornar. Torna-se cada vez mais difcil prever o futuro. Os velhos modelos de gesto no esto altura da tarefa. Esses conceitos de planejamento e previso s so precisos quando um ambiente relativamente esttico. O que um startup, definitivamente, no pode ser classificado como um ambiente esttico.

- O segundo problema relaciona-se com o primeiro quando o empreendedor percebe que os modelos antigos de gesto no esto funcionando ento eles adotam a escola do apenas faa de startups. Essa escola prega que se a gesto o problema, o caos a resposta. E no a resposta.

Com estes argumentos postos, percebesse que iniciar um startup requer mais que uma ideia original. Adquirir conhecimento dos mais diversos campos diferencial para o sucesso. E conhecer bem o pblico que quer atingir essencial para o xito na empreitada. E parte do trabalho de conhecer o pblico cai nas mos do designer, profissional preparado para essa tarefa. Esta pesquisa trata sobre conhecer o seu pblico e o cuidado que startups devem ter ao desenvolver as solues pensando no ator que fica na ponta do processo: o usurio. Quando a empresa emprega esse conhecimento sobre o usurio, um mtodo de produo eficiente com um esprito gil e dinmico em suas aes, o sucesso no seu empreendimento praticamente garantido.

Erton W. Vieira

20 nesse cenrio que o REDU e o seu produto (Rede Social para Educao) se enquadram. Esse startup surgiu de uma ideia inovadora e que est no caminho de construo e desenvolvimento, j iniciando seus passos comerciais no mercado brasileiro. Este caminho deveria passar por conhecer a si mesmo como empresa e conhecer o seu pblico e suas necessidades. Este processo de evoluo do produto detalhado nesta pesquisa.

1.2 Hiptese e Questo de Pesquisa

Para esta pesquisa, foi definida a seguinte hiptese: A gesto da proposio de valor no desenvolvimento gil de software impacta positivamente na qualidade da Experincia do Usurio do sistema.

Tendo isso em mente, a questo que permeia todo o estudo : Como a gesto dos valores em ambientes geis impacta na experincia do usurio?

1.3 Objetivo Geral

Analisar como a gesto de valor em ambientes de desenvolvimento gil impacta na experincia do usurio.

1.4 Objetivos Especficos

Identificar quais so os valores da empresa e como elas foram definidas; Descrever o processo tcito do design experiencial adotado na empresa; Descrever a experincia do usurio; Encontrar pontos em comum entre variveis que descrevem o processo tcito adotado pela empresa e o design da experincia.

Erton W. Vieira

21

1.5 O Pesquisador

Nesta seo, apresentaremos mais informaes sobre o pesquisador e seu envolvimento com o tema e com o campo de pesquisa. O objetivo oferecer ao leitor mais informaes sobre sua vivncia acadmica e profissional.

Graduado em Bacharelado em Design pela Universidade Federal de Pernambuco (UFPE - Caruaru) e em Sistemas de Informao pela Universidade de Pernambuco (UPE - Caruaru), comeou a desenvolver um interesse em pesquisar conceitos que facilitassem uma interao entre os dois cursos e suas metodologias, realizou pesquisas na aceitao das metodologias do design no desenvolvimento de softwares e focou seus estudos em anlises de ambientes de Educao Distncia.

Atualmente, o pesquisador professor de design da rede estadual de ensino e ministra aulas para turmas do ensino tcnico.

Aps ingressar no mestrado, o pesquisador passou a integrar o grupo de pesquisa Cincias Cognitivas e Tecnologia Educaional (CCTE) da Universidade Federal de Pernambuco (UFPE) e l participou de pesquisas que tinham como finalidade melhorar o desenvolvimento do Projeto Amadeus. O aprofundamento dos conhecimentos na rea de IHC e em Design da Experincia fez com que o pesquisador refletisse sobre a necessidade de adequao das metodologias de design com as metodologias de desenvolvimento de software, o que deu origem ao incio dessa investigao e a oportunidade de contribuir neste campo.

Erton W. Vieira

22

1.6 Estrutura da Dissertao

Este trabalho est estruturado conforme segue: Captulo 1 Introduo: Justifica e contextualiza o tema que ser investigado, apresenta a definio do problema, a questo de pesquisa, o objetivo geral e especficos, informaes sobre o pesquisador e seu interesse sobre o tema investigado. Captulo 2 Gesto de valores no desenvolvimento gil de softwares: . valor, experincia de usurio, desenvolvimento gil. Captulo 3 Mtodo de Pesquisa: Justificamos a metodologia utilizada e seus conceitos. Descrevemos o experimento e as etapas da pesquisa qualitativa utilizadas na realizao deste trabalho Captulo 4 . Anlise dos Resultados: Nesse captulo descrevemos a anlise dos dados coletados e a discusso do experimento. Captulo 5 Consideraes Finais: Neste captulo so discutidos os resultados da pesquisa e a concluso do projeto. Captulo 6 Referncias: Neste captulo so apresentadas as referncias bibliogrficas utilizadas na pesquisa

Erton W. Vieira

23

Captulo

2
2.
Gesto de valores no desenvolvimento gil de software
Este captulo aborda conceitos ligados gesto de valor, assim como definio de Design da Experincia do Usurio e Processos de Desenvolvimento gil de Software.

Erton W. Vieira

24

2.1 Proposio de Valor

O nvel de excelncia que o mercado atual esta demandando exige das empresas que elas se destaquem em pontos especficos para calcar os degraus de um caminho de sucesso. Apostar na fidelizao do cliente mais que bvio, necessrio para qualquer empresa que queira sobreviver hoje em dia (Kotler, 2006). medida que as organizaes desenvolvem, promovem, distribuem, os clientes so o foco de todas as atividades de marketing (Pride e Ferrell, 2011)

Oferecer apenas um produto ou servio de qualidade no o que vai garantir o sucesso de qualquer que seja o empreendimento. O consumidor est procurando um algo a mais para ajudar a tomar suas decises. papel da empresa apresentar para o consumidor esse algo a mais. Especificamente, papel da rea de marketing da empresa fazer com que o seu produto ou servio destaque-se dos tantos outros semelhantes que povoam o mercado. Fazer com que o consumidor relacione-se com esse produto de uma forma familiar um dos maiores desafios de qualquer empresa (Kotler e Armstrong, 2007).

E esse desafio de conquistar o consumidor est intrinsecamente ligado entrega de valor ao consumidor, a partir da empresa. Pereira (2009) afirma que nos dias de hoje as empresas criam valor oferecendo diferentes tipos de servios de que os clientes necessitam, apresentando as suas capacidades e entregando-as de uma forma agradvel e conveniente a um preo justo. Em troca, as empresas recebem valor dos seus clientes. Boone e Kurtz (2009) afirmam que esse processo de troca a base do prprio marketing, quando h uma necessidade de troca de mercadorias acontece um esforo de marketing para que a negociao seja concluda.

Frow e Payne (2011) afirmam que uma abordagem para propor valor, deve-se focar em trs processos:

Erton W. Vieira

25 Anlise de grupos de clientes pelos atributos que os clientes

consideram de valor; - Avaliao de oportunidades em cada segmento para oferecer valor superior e; - Explicitamente escolher o VP que aperfeioa essas oportunidades.

As organizaes entregam valor com seus produtos e servios atravs dos valores que so propostos pela empresa. Os valores de uma empresa so um conjunto de caractersticas que o servio oferece para atrair clientes. Trata-se de um conjunto de atributos que as organizaes oferecem atravs de seus servios, que geram satisfao, reteno, captao e participao do mercado em que ele est inserido (KAPLAN e NORTON, 2008) Porm, Kotler afirma que as empresas precisam basear suas ofertas no valor que esto entregando ao cliente, mais do que no preo ou qualquer outra varivel isolada do produto. (KOTLER e ARMSTRONG, 2007) O autor ainda expe os benefcios da aquisio de valor: Eficincia, custo x benefcios para o cliente, economia de tempo e prazos; Eficcia, conformidade, atendimento de expectativas, satisfao do cliente. Anderson (et al., 2007) afirma que as empresas que tem conhecimento sobre o que os clientes definem como valor, e o que esse valor seria, tem vantagem competitiva junto as empresas que no tm esse conhecimento.

Devido realidade de um startup, os esforos de marketing podem ser um desafio desconhecido. necessrio abordar os valores no momento certo, Grando (2011) afirma que necessrio primeiro saber se seu produto ou servio resolve o problema ao que se props, normalmente de forma inovadora, para, a partir disso ento, estabelecer metas e estratgias para a sua comercializao. Quando o produto reconhecido por sua capacidade de resolver o problema que ele se props a resolver, ento torna-se imperativo dar continuidade no processo de negcio, e consequentemente, a definio de seus valores. Isso sempre levando em considerao o seu pblico alvo.

Erton W. Vieira

26 Alm dos valores, outras caractersticas tornam-se essenciais para o sucesso de um produto, como a concepo do design do produto e a forma em que este produto ser desenvolvido.

2.2 Design e o Valor Percebido

O design uma arma poderosa, se bem utilizada, para fazer com que a empresa externe no seu produto todos os valores que so propostos por ele. Existem vrias definies para o que design, porm Lbach (2001) resumiu todos esses conceitos quando afirmou que:
O design uma ideia, um projeto ou um plano para a soluo de um problema determinado. Design consistiria ento na corporificao desta ideia para, com a ajuda dos meios correspondentes, permitir a sua transmisso aos outros. J que nossa linguagem no suficiente para tal, a confeco de croqui, projetos, amostras, modelos constitui o meio de tornar visualmente perceptvel a soluo de um problema. (Lbach, 2001)

O maior valor do design o poder de solucionar um problema. Fazer com que o consumidor perceba esse valor o grande desafio. Domingues (2000) aponta que as empresas lderes passaram a focar o valor percebido, acreditando ser ele, ao invs da satisfao dos consumidores, o impulsionador da lealdade dos clientes, conduzindo-os escolha e recompra.

Alm de Domingues, vrios outros autores como Walters (2011) e Frow e Payne (2011), discorrem sobre esse mesmo fator importante para o mercado. Um dos mais conhecidos estudiosos sobre o marketing e sobre os valores percebidos, Kotler e Keller (2006) apresentam para ns o conceito de que o valor percebido o valor atribudo pelos clientes ao produto ou servio, baseado na relao entre os benefcios que este trar, segundo a tica do consumidor, e os custos percebidos para sua aquisio, comparativamente concorrncia. Outros autores vo definindo esse valor percebido de formas diversas, como Woodruff (1997) que defende que o conceito de valor

Erton W. Vieira

27 percebido como sendo a percepo do cliente sobre as preferncias e as avaliaes dos atributos do produto, do desempenho desses atributos e das consequncias originadas pelo uso. Ferrel e Hartline (2005) continuam quando incluem valor percebido como benefcios para o consumidor que incluem qualquer coisa que ele receba em uma relao de troca com a empresa. Desde o produto em si, at questes como entrega, financiamento, entre outros.

O consumidor vai ao mercado procurando produtos que lhe apresentem vantagens. Heskett (2001) afirma e completa quando fala que:
Mercados so, portanto, a soma total de tentativas de cada indivduo para maximizar sua prpria vantagem. No entanto, se algum comprador ou vendedor pode manipular um preo bom, ou distorcer o mecanismo de mercado, ento uma condio de concorrncia imperfeita ocorre, uma condio que engloba a maior parte do trabalho de design. (Heskett, 2001)

E Teixeira et al. (2004) corroboram afirmando que design estabelece diferencial sobre as empresas concorrentes. Assim, o produto com valor agregado decorrente do design, representa uma das garantias da escolha do consumidor por determinado produto em relao ao da empresa concorrente. Hoje as organizaes pedem para os designers imaginem solues que atendam s necessidades explcitas ou latentes dos usurios, para construir a completa experincia do cliente e aperfeioar a satisfao (Serrat, 2010).

Fraser (2009) argumenta que o design pode ser o caminho para a compreenso das necessidades dos stakeholders, a ferramenta para a visualizao de novas solues e processo de traduo de ideias para estratgias eficazes.

O design pode abordar vrios aspectos de um produto, como, por exemplo, seu visual, a forma de interao com o usurio, as diferentes formas de apresentalo ao pblico. Mas iremos nos aprofundar a seguir na forma como o design pode projetar a experincia do usurio ao interagir com o produto.

Erton W. Vieira

28

2.3 Experience Design

O Experience Design, ou design da experincia, uma metodologia de desenvolvimento de produtos ou servios que ao invs de focar em um aspecto do projeto, ele tem uma viso mais holstica da experincia do usurio. O designer da experincia enfatiza que as experincias que o usurio venha a ter com o produto ou servio estejam de acordo como os valores propostos pela organizao (Patton, 2008).

A variedade de novas interfaces abriram as portas para novos estudos em como o usurio se relaciona com o produto, e principalmente, como a experincia dele com este produto. Norman (2006) afirma que a experincia do usurio com o produto comea antes do primeiro contato direto. J que existe uma serie de conhecimento prvio sobre o produto, oriunda de todo um histrico de usurios com experincias anteriores, seja com produtos similares ou com percepes do mundo de modo geral.

O designer da experincia tem que saber como conciliar as caractersticas do produto com os valores comerciais que ele entrega. Reiss (2009) afirma que a experincia representa a percepo deixada na cabea de algum seguida de uma srie de interaes entre pessoas, dispositivos e eventos.

Algumas definies de o que o design da experincia so mais detalhadas do que outras. Exemplo a citao que o Yamazaki e Furuta (2007), fazem do site American Institute of Graphic Arts que descreve a experincia como: Uma abordagem diferente de design que tem limites mais amplos do que design tradicional e que se esfora para criar experincias alm dos produtos ou servios, apenas. A viso de um produto ou servio a partir do ciclo de vida com um cliente, desde antes que eles percebem a necessidade at quando descart-lo.

Erton W. Vieira

29 Criar uma relao com os indivduos, no como alvo de um mercado de massa. Preocupados com a invocar e criar um ambiente que conecta em um nvel emocional ou de valor para o cliente. Construdo sobre ambas as disciplinas de design tradicionais na criao de produtos, servios, bem como ambientes em uma variedade de disciplinas. Os pesquisadores (op cit.) afirmam que no fcil de adotar uma abordagem de design de experincia do usurio de produtos e servios, porque o design da experincia do usurio significa que abrange uma ampla gama de aspectos, e sem a colaborao de uma equipe multidisciplinar, o projeto de experincia do usurio no ser bem sucedido.

Nielsen no Nielsen/Norman Group (2011), corrobora com a viso do Yamazaki e Furuta, quando afirma que Para atingir alta qualidade na experincia do usurio em ofertas de uma empresa, deve haver uma perfeita fuso dos servios de vrias disciplinas, incluindo engenharia, marketing, design grfico e industrial, e design de interface. Eles ainda defendem que o Design da Experincia abrange todos os aspectos da interao do usurio final com a empresa, seus servios e seus produtos. O primeiro requisito para uma experincia de usurio exemplar atender s necessidades especficas do cliente, sem barulho ou incmodo. Em seguida, vem simplicidade e elegncia de produtos que manifestam no seu usurio alegria em possui-lo, uma alegria em usa-lo. A verdadeira experincia do usurio vai muito alm de dar aos clientes o que eles dizem que querem.

Psomas (2007) e Paluch (2006) propem competncias que seriam necessrias para qualquer equipe ou profissional de design da experincia do usurio, so elas: Arquitetura da Informao, Design de Interao, Design Visual, Engenharia de Usabilidade, Engenharia de Prototipao e Ergonomia.

Contudo, alguns aspectos mais simples devem ser observados quando estamos trabalhando com a experincia do usurio. Para Shedroff (2001) a
Erton W. Vieira

30 experincia deve ter, no mnimo, uma atrao, um envolvimento e uma concluso. E ele define o que seria cada uma desses pontos: A atrao necessria para iniciar a experincia. Uma atrao pode ser cognitiva, visual, auditiva, ou pode sinalizar qualquer um dos nossos sentidos. Por exemplo, a atrao para preencher seu imposto de renda baseada na necessidade e no em uma apresentao chamativa. No entanto, ainda precisamos ter pistas sobre onde e como comear a experincia. O envolvimento a prpria experincia. Ele precisa ser

suficientemente diferente da experincia comum para prender a ateno das experincias, bem como cognitivamente o suficiente relevante para que algum continue a experincia. A concluso pode vir de muitas formas, mas deve fornecer algum tipo de resoluo, de significado, histria, contexto ou a atividade para fazer uma experincia agradvel de outra forma satisfatria. Muitas vezes uma experincia que envolvente no tem fim real, deixando os participantes insatisfeitos ou mesmo confusos sobre estas experincias, emoes ou ideias.

Para Shedroff (op cit.) necessrio entender primeiro o que faz uma boa experincia, para a partir desse conhecimento, comear a projet-la. Ele define alguns aspectos que seriam imprescindveis para uma boa experincia, como podemos ver no quadro abaixo:
Quadro 2.1 - Aspectos para imprescindveis para uma boa experincia (Shedroff, 2001)

APRESENTAO E ORGANIZAO

Um dos conceitos mais difceis de um designer entender que a apresentao (aparncia) de uma experincia est separada da sua organizao. s vezes os conceitos so to ligados que impossvel separ-los, como por exemplo, informaes geogrficas (organizao) que apresentam-se como mapas. A organizao pode ser apresentada atravs de uma variedade de formas: Dados textuais (palavras ou nmeros), escrito (descrio), visualmente (grficos), fontico, etc.
Erton W. Vieira

31

A apresentao em si pode impedir a compreenso dos dados. Acontece muito em trabalhos de designers que valorizam o estilo visual e a aparncia mais que a compreenso e preciso (tanto faz realiz-los ou no). Enquanto designers esto preocupados em trazer coisas inesperadas para seu processo de desenvolvimento, muitas vezes esses elementos inesperados podem no ser apropriado para a compreenso ou so implementados de uma forma obscura primando apenas o estilo.

VISUALIZAO E DESIGN

Visualizao de compreenso muito mais importante do que simplesmente fazer com que parea "bom". A visualizao parte integrante da comunicao, pois a organizao visvel. Muitas vezes, a organizao dos dados (e, portanto, entendimento) fica escondida quando o tipo de visualizao no corresponde organizao ou os objetivos da comunicao, ou simplesmente distorce a compreenso.

Design de interface outro aspecto da visualizao do desenho das experincias. (...) Normalmente os designers de interface tm abordado o layout das telas, os elementos de design para as telas como cones, e o fluxo entre elas.

NAVEGAO

Normalmente h mais de um caminho para chegar a lugar nenhum. O mesmo deve ser verdadeiro para muitas experincias - informar experincias, ao invs de entreter. Se possvel deve-se oferecer diversas maneiras ao seu publico para navegar a experincia. Na maioria das experincias de entretenimento, como histrias ou narrativas, tende-se a seguir uma nica mo, definida pelo narrador. Contudo na mdia digital bastante fcil dar opes para o usurio.

Erton W. Vieira

32
INTERATIVIDADE O maior problema com o termo interatividade que tem sido mal definida por muitas pessoas e empresas como significando tanto uma animao ou qualquer coisa que aparece em um computador ou na Web uma vez que estas so "mdias interativas". Interatividade engloba basicamente tudo, que se faz em um computador e principalmente fora dele. De fato as experincia mais interativas das nossas vidas no tem nada a ver com tecnologia.

Interatividade tambm composto de muitos outros atributos. Alguns desses atributos incluem: feedback, controle, criatividade, adaptabilidade, comunicaes, entre outros. Muitos desses atributos so experincias que dizem respeito a pessoas e essas experincias interativas so muito valorizadas em um bom design.

CRIATIVIDADE

Uma das coisas mais importantes para ns, e um dos principais componentes de interatividade, a capacidade de criar coisas. Enquanto pensamos que ns mesmos no somos to criativos, criamos todo tipo de coisas o tempo todo. Humanos so criaturas inerentemente criativas e quando temos a oportunidade de criar nos sentimos valiosos e satisfeitos. E os produtos de nossa criao tem um grande valor para ns, pelo menos em um nvel pessoal.

Com todos esses aspectos que devem ser levados em considerao para um design da experincia do usurio, necessrio que uma metodologia de desenvolvimento seja bem embasada e simples na sua utilizao. Yamazaki e Furuta (2007) propuseram um mtodo para projetar a experincia do usurio que consiste em:

1) Considerar a experincia do usurio do ponto de vista do ciclo de vida Do ponto de vista do ciclo de vida, o sistema inclui a conscincia inicial de um usurio, atravs de descobertas adicionais, sobre a encomenda, entrega,

Erton W. Vieira

33 instalao, uso inicial, o dia-a-dia uso do servio, suporte, atualizaes, e em fim de vida. Por exemplo, considerando uma apresentao em uma conferncia, antes da conferncia que o usurio precisa considerar o ttulo e o contedo da apresentao, preparar os slides, e viajar para a conferncia com um notebook, e aps a apresentao, o usurio recebe feedback e pode mudar a apresentao para a prxima conferncia.

2) Considerar experincias de usurio do ponto de vista do Ambiente O ponto de vista Ambiente cobrir todos os materiais que o usurio olha, toca, ou sente. Ele inclui o produto de hardware, software, aplicaes, o espao onde as coisas acontecem, e as pessoas que esto se comunicando. Por exemplo, para uma apresentao, os requisitos ambientais incluem uma secretria, um projetor, cabos adequados, a tela de projeo, entre outros materiais.

3) Considerar a experincia do usurio do ponto de vista de vrios usurios. Estes incluem vrios grupos de usurios do ponto de vista de design universal, os usurios com vrios personagens e personalidades, e sentindo vrias emoes. Por exemplo, uma apresentao deve ter um estilo de apresentao diferente dependendo do carter do usurio. Apresentadores mais jovens no podem considerar pequeno texto nos slides, designers podem tentar usar lotes de grficos nos slides, e alguns apresentadores no podem usar quaisquer slides. Muitos desses itens esto relacionados com a experincia nica do usurio.

Este mtodo de desenvolvimento um dos vrios que tem como finalidade projetar uma experincia do usurio de qualidade. Mas existem outras formas de projetar uma experincia de qualidade. o que veremos a seguir.

2.4 Projetando Experincia do Usurio

Erton W. Vieira

34 Assim como existem muitos pesquisadores que tentam definir uma teoria coesa do que seja experincia, vrios autores tentam definir uma forma eficaz de projetar essa experincia (Forlizzi e Battarbee, 2004; Hennipman, Oppelaar, Van der Veer e Bongers 2008; Ozenc, 2009). Definindo aes e passos para produzir uma experincia de qualidade. Entre estes vrios pesquisadores, Yamazaki e Furuta (2007) definiram um mtodo para projetar a experincia em sistemas informacionais, o que encaixa com o objetivo desta dissertao. Eles definem: O mtodo de projeto de design de experincia do usurio deve ser baseado na abordagem de design centrado no usurio porque o design centrado no usurio um mtodo til para resolver os problemas do ponto de vista do usurio, e tambm muito popular em muitas empresas.

O mtodo de projeto para o design de experincia do usurio precisa estenderse de design centrado no usurio para cobrir o ponto de vista do ciclo de vida, o ponto de vista do ambiente e pontos de vista de usurios diferentes. Alm disso, do ponto de vista corporativo, branding muito importante para design de experincia do usurio e para o sucesso como um negcio. O processo de projeto e da equipe de projeto para design de experincia do usurio deve ser baseado no projeto centrado no usurio com extenses do ponto de vista a experincia do usurio.

Sendo assim eles definem o processo de projetar a experincia do usurio:

- 1. Faa um plano para o design de experincia do usurio: importante ter o processo de design certo, mtodos certos e equipe certa. Para esse fim, antes de iniciar o projeto, o lder do projeto tem que fazer um plano para o design de experincia do usurio. O plano tem de incluir um esboo do processo, o cronograma, os membros da equipe, e do oramento.

- 2. Compreenda com profundidade a experincia do usurio: corresponde a entender o mercado, o negcio, os usurios as partes interessadas e o branding.

Erton W. Vieira

35 - 3. Compreenda a experincia dos usurios alvos do ciclo-de-vida, ambiente e outros usurios diferentes: Isto inclui as pessoas, os papis do usurio, os objetivos do usurio, as tarefas do usurio, e os cenrios do usurio, como pode ser visto do ponto de vista a experincia do usurio. Para entender os usurios, muito importante entrevistar usurios para obter uma opinio real para ento a equipe de projeto iniciar as atividades.

- 4. Conceber o design da experincia do usurio: Este inclui um prottipo de baixa fidelidade para a experincia do usurio e um documento para o projeto de conceito e sua avaliao.

- 5. Detalhar o design da experincia do usurio: Este inclui um prottipo de alta fidelidade para a experincia do usurio, especificaes detalhadas do projeto, e sua avaliao.

- 6. Avaliao do ponto de vista da experincia do usurio: Isso inclui o prottipo final e avaliao.

- 7. Validao da experincia do usurio no mercado: importante para validar os resultados do feedback do usurio o ponto de vista da experincia do usurio.

A equipe de projeto para design de experincia do usurio deve ser considerada com base na abordagem de design centrado no usurio. Os membros so quase os mesmos que para o design centrado no usurio, mas todos eles tm o conhecimento sobre design de experincia do usurio. (Yamazaki e Furuta, 2007). Os pesquisadores listaram membros que seriam necessrios para uma equipe de design da experincia: Lder do projeto Pesquisador do usurio Designer de experincia do usurio Designer Visual (designer industrial ou designer grfico) Especialista em testes de Usurio Planejador de marketing
Erton W. Vieira

36

O profissional de marketing encaixa-se ao grupo, pois existe uma ligao ntima entre o que se espera da experincia do usurio e os valores que foram definidos para o produto ou servio.

Porm, como seria trabalhar estes conceitos e mtodos de design da experincia em conjunto com outros conceitos e mtodos? No caso deste estudo, como os conceitos de desenvolvimento de softwares atravs de processos geis? Veremos a seguir nos prximos subcaptulos.

2.5 Design da Experincia com Processos geis de Desenvolvimento de Software

O pesquisador Boehm (2003) afirma que desde os anos 2000 estamos em uma tendncia para o desenvolvimento gil de aplicaes de software devido a um ritmo acelerado de mudanas e inovaes na tecnologia da informao e comunicao, em organizaes e no ambiente de negcios. O autor cita que no final dos anos 90 aconteceu o surgimento de vrios mtodos geis (entre eles: Crystal, Dynamic Systems Development, eXtreme Programming (XP) e SCRUM) e todos esses empregavam princpios geis, tais como ciclo iterativos, entrega rpida de software funcionando e simplicidade, como definido no Manifesto para Desenvolvimento gil publicado em 2001 (Fowler e Highsmith, 2001).

O Manifesto gil tratado como uma filosofia a ser seguida. Exemplos de princpios geis inclui valorizar o seguinte: - Indivduos e interaes sobre processos e ferramentas; - Programar sobre documentar; - Colaborao do cliente sobre negociao de contratos; - Responder a mudanas sobre seguir o plano;
Erton W. Vieira

37

A essncia do manifesto a definio de novo enfoque de desenvolvimento de software, apoiada na agilidade, na flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos produtos e servios de valor ao mercado, em curtos perodos de tempo. (Highsmith, 2004)

Quando comparamos metodologias geis com metodologias convencionais, tidas como mais pesadas, percebemos com mais segurana a existncia de caractersticas essenciais das metodologias geis. Podemos ver essa comparao abaixo:
Quadro 2.2 - Comparao entre metodologias geis e convencionais (adaptado de ULLAH e ZAIDI, 2009)

Ambiente de Projeto Categoria Varivel Estilo de Time de Desenvolvimento Comunicao Localizao Tamanho Continuidade na Aprendizagem Cultura de Gesto Participao do Time Planejamento Mecanismos de Feedback Envolvimento Disponibilidade Processos e Ferramentas

Caractersticas do Projeto gil No-gil Colaborao Somente quando regular necessrio Juntos Distribudos At 50 pessoas Mais de 50 pessoas Estimulado Desencorajado Responsivo Totalmente Desejvel Contnuo Vrios Todo o Projeto Facilmente acessvel Apenas o suficiente Pode ser alterado Flexvel Tempo e Material Comando e Controle Indesejvel Comeo No disponvel Durante a fase de anlise Difcil acesso

Gerenciamento de Projetos

Cliente

Quantidade Adaptabilidade

Contrato

Requisitos e Datas Custo

Mais do que suficiente No pode ser alterado Fixo Fixo

As metodologias geis mais utilizadas atualmente so:

Erton W. Vieira

38 Extreme Programming (XP) A mais conhecida das metodologias geis, o XP uma metodologia para equipes pequenas e mdias e que iro desenvolver software com requisitos vagos e em constante mudana. Para isso, adota a estratgia de constante acompanhamento e realizao de vrios pequenos ajustes durante o desenvolvimento de software. Seus valores fundamentais so a comunicao, simplicidade, feedback e coragem. A metodologia XP prima por seus princpios bsicos, que so: - Feedback rpido; - Presumir simplicidade; - Mudanas incrementais; - Abraar mudanas; - Trabalho de qualidade; Scrum Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis e produtos de consumo. Sua funo primria ser usada para o gerenciamento de projetos de desenvolvimento de software, mas, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessita trabalhar juntas para atingir um objetivo em comum. A caracterstica que diferencia o Scrum das outras metodologias geis a pratica de discusses dirias na qual cada membro da equipe responde s questes: O que fiz ontem?, O que estou planejando fazer at amanh? e Existe algo me impedindo de alcanar minha meta?. Dynamic System Development Methodology A DSDM foca na interao com o cliente e o usurio final, entrega de prottipos frequentes, equipes de desenvolvimento autnomas, testes massificados durante todo o processo e na definio de prioridades entre a lista de requisitos dada pelo cliente. Possui trs fases: Pr-projeto, Projeto e Ps-Projeto.

Crystal Family Methogology - Existem trs mtodos principais desenvolvidos: Crystal Clear, Crystal Orange e Crystal Orange Web (Crystal Orange acrescido de prticas especficas para web). O Crystal Clear foi desenvolvido para projetos muito pequenos, de at seis desenvolvedores de curta durao. J o
Erton W. Vieira

39 Crystal Orange desenhado para projetos de tamanho mdio, com um total de 10 a 40 desenvolvedores e com durao de 1 a 2 anos. No mtodo Crystal Orange o projeto dividido em muitos grupos com funcionalidades cruzadas.

O Manifesto gil (Fowler e Highsmith, 2001) se preocupa com

implementao do valor do cliente, apesar de definirem como sendo um princpio mais fcil de dizer do que fazer. O Manifesto defende que a volatilidade associada aos projetos de hoje exige que os valores sejam reavaliados com frequncia, e se prender aos planos originais do projeto pode comprometer o sucesso final do projeto.

2.6 Projetando o Design da Experincia com Processos geis

A realizao de um projeto de design requer que ela seja muito bem documentada. Tudo tem que ser avaliado e justificado para que possam atingir o mximo de perfeio e o problema que est sendo abordado seja resolvido de maneira eficaz e eficiente. Essa metodologia de trabalho especificada por Baxter (2000) e Lobach (2001) faz com que o processo de design seja entendido como engessada, ou seja, muito densa para ser trabalhada em ambientes de trabalho que utilizem a metodologia de desenvolvimento gil.

Em seu estudo, Fox (2010), esclarece como essa dificuldade eminente, ele afirma que em um primeiro olhar, mtodos geis e ID tm abordagens opostas em termos do trabalho que est sendo feito antes que o desenvolvimento comece. Mtodos geis de projeto de software eliminam uma grande quantidade de recursos alocados no incio do projeto. Por exemplo, um dos processos gil mais utilizados o eXtreme Programming proposta por Kent Beck e Martin Fowler, a abordagem utilizada com XP um iteraes com conjuntos menores de recursos e, portanto, menos exigncias coletadas antes do incio da implementao.

Erton W. Vieira

40 Abordagens de design comeam com uma perspectiva de como o software utilizado, passando uma quantidade considervel de tempo pesquisando os usurios, suas necessidades, as tarefas que precisam realizar e, em seguida iterativamente, testando um design de interface. Em seu livro, Alan Cooper (2007) sugere que uma boa quantidade de pesquisas iniciais devem ser realizada antes de qualquer aplicao ser concebida como uma abordagem para identificao de erro. Sua abordagem tratar os comportamentos e idiossincrasias do usurio, antes do desenvolvimento comear. Apesar de identificao e de abordagens geis so muito diferentes, ambas as metodologias tm o mesmo objetivo em mente, e que o objetivo construir um software melhor. Como resultado disto, houve um aumento no interesse dirigido como os mtodos geis e design da experincia tanto podem ser empregados em um mesmo projeto para produzir uma metodologia hbrida.

Buldwing (2009), Sy (2007) e McInerney (2005) apontam em seus estudos de caso que o grupo de Experience Design das empresas de software costuma trabalhar de forma pouco harmoniosa com os outros grupos de

desenvolvimento. O que para uma empresa que passa a utilizar processos geis pode se tornar desastroso. E ainda existe a questo levantada por McInerney (op cit.) que a grande maioria dos processos geis no identifica um papel para os designers da experincia, o que faz com que os prprios designers fiquem com o nus de procurar um espao dentro da metodologia para desenvolver seus estudos.

Contudo uma vertente de estudiosos vem trabalhando para que essas duas metodologias de trabalho sejam integradas de forma eficiente para um desenvolvimento de qualidade. Patton (2008) afirma que se a prtica do Experience Design era fraca antes do processo gil, s vai dificultar as coisas. Se a prtica do Experience Design era forte antes do processo gil, vai continuar forte e evoluir para se adaptar.

A fim de explorar como e quando as equipes podem combinar elementos do design da experincia do usurio e mtodos geis de um modo que fornece os

Erton W. Vieira

41 benefcios de ambas as abordagens. As seguintes questes de investigao so abordadas na pesquisa de Fox (op cit.):

- Como estas duas metodologias podem ser combinadas, uma vez que elas tm muitas diferenas tcnicas de alocao de recursos em incios de projeto? - Quais so as funes dos membros da equipe que esto diretamente envolvidos no processo de combinar essas duas metodologias? - Que estratgias diferentes esto sendo usados para incorporar um processo de identificao e mtodos geis para o projeto de software? - Qual o efeito que a integrao dessas duas metodologias tem em suas abordagens originais ou processos de desenvolvimento?

Essa adaptao documentada por Sy (2007) e Buldwing (2009) em seus trabalhos. Buldwing trabalhou com uma grande equipe de desenvolvedores e designers em projetos complexos que exigiam uma integrao mais apurada entre os designers e os desenvolvedores. Por essa demanda particular, as adaptaes que eles realizaram so significativas para o desenvolvimento desta interao de metodologias de trabalho.

Patton (2008) levantou 12 prticas que ajudam nessa adaptao entre o desenvolvimento do Experience Design e Mtodos geis, atravs da observao em projetos que ele participou e levando em considerao estudos de outros pesquisadores da rea. As 12 prticas so: - O Experience Designer fazer parte do time de clientes ou P.O. Isso significa que o designer tem uma participao ativa em decidir o que vai ser construdo, na estratgia global do negcio e na priorizao do trabalho ttico. - Pesquisa, Modelagem e Design antes, mas s o suficiente. A despeito do que o dogma gil pode afirmar, as empresas bem sucedidas em incorporar a equipe de design da experincia em metodologias geis de desenvolvimento, fazem uma pesquisa prvia com os usurios, o que resulta em coisas como personas, modelos de workflow, grades de anlises de
Erton W. Vieira

42 tarefas, e at mesmo modelos mentais. Porm no se deve prender-se a essa pesquisa por muito tempo. - Quebre em pedaos o trabalho de design. A construo em desenvolvimento gil realizada em pequenos pedaos, geralmente chamados de histrias. O que torna-se um problema para o designer que trabalha com uma viso geral do sistema. O que sugerido que o designer trabalhe com pequenos esboos, geralmente de uma funcionalidade, mas que tenha em mente a viso geral do produto. Dado um esboo de alto nvel do design, um pouco de prtica na segmentao, e algumas correo de curso ao longo do caminho e as coisas tendem a sair positivas. - Usar desenvolvimento de trilha paralela mover-se para trs e para frente. - O time de design trabalha em uma ou duas sprints frente. Elas podem ser: Pesquisando o trabalho a ser feito duas sprints frente (S + 2); validao de prottipos de design da prxima sprint (S + 1); estar disponvel para ajudar no desenvolvimento da Sprint atual (S); testando com o usurio para validar o trabalho feito na ultima Sprint (S - 1).

- Ganhar tempo para design com aspectos complexos de engenharia. - O ideal manter os desenvolvedores trabalhando no software enquanto a validao do design de projeto est em andamento. Para ganhar tempo, comum ter pedaos de trabalho que so tecnicamente complexos, mas triviais de uma perspectiva de design de interao. Por exemplo, a equipe de design pode trabalhar em um simples "arquivo, salvar como" opo de menu, mas na perspectiva do desenvolvimento complexo. Isso d mais tempo para a equipe de design trabalhar.

- Cultive um grupo de validao de usurios para uso de uma validao contnua. Empresas que trabalham com equipes de design tm muitas vezes um grupo de usurios que validam o design antes e depois de construdo o projeto. Esse grupo tem que ter uma quantidade razovel, para que no seja convidado toda semana e acabe se contaminando com o projeto.

Erton W. Vieira

43 - Programe a pesquisa junto ao usurio em uma trilha diferente do desenvolvimento. A pesquisa com usurio esta sendo considerado como uma trilha diferente do desenvolvimento e em constante execuo. Essa pesquisa comunicada de forma leve equipe de desenvolvimento. - Use o tempo com o usurio para mltiplas atividades Aproveite o tempo que tem com o usurio. Faa entrevistas, observaes, reveja prottipos. O truque aproveitar o tempo com o usurio para pesquisa e validao.

- Use o RITE para iterar o Experience Design antes do desenvolvimento O mtodo RITE, uma rpida e curta avaliao iterativa. Utilize os RITE para obter erros fora do software o mais rpido possvel. Entre cada teste a equipe discute os erros encontrados e como elas podem corrigilos. - Prototipao em baixa fidelidade Muitos profissionais de Equipes de Design gil, afirmam gastar muito tempo criando prottipos. Ento sugerem que trabalhem com prottipos de baixa fidelidade. Usando papel, softwares simples ou at o quadro branco.

- Tratar especificaes no prottipo - comum entregar apenas o prottipo, ou, idealmente, o prottipo mais uma discusso com a equipe de construo do software. No h necessidade de produzir documentao detalhada. Um nmero de diferentes documentos que foram abolidos em favor de discusses ao longo de um prottipo. - Torne-se um facilitador de projetos O designer tem que ser um facilitador para a obteno de informaes dos modelos mentais de grandes grupos de pessoas. Trabalhar junto com usurios e desenvolvedores para criar cenrios, e esboar o design da interface do usurio.

Budwing et al. (op cit.), um pouco mais especfico quando apresenta uma adaptao para o SCRUM. Onde as caractersticas do Experience Design so
Erton W. Vieira

44 abordadas no desenvolvimento dos softwares utilizando essa especfica metodologia gil. As adaptaes mais significativas foram:

- Agendar as equipes

de desenvolvimento da experincia do usurio para

trabalhar um ou dois sprints frente das equipes de desenvolvimento;

- Incorporar a viso de design sprints trimestrais no ciclo sprint normal;

- Organizar a equipe de desenvolvimento da experincia do usurio em um time scrum separada, com sua carteira de produtos prprios e proprietrio do produto.

Figura 2.1 - Workflow, regras e responsabilidades dos times de UX trabalhando em metodologia gil.

- Trabalha uma a duas sprints a frente das equipes de desenvolvimento Scrum resultou em menor rotatividade e o balano no trabalho melhorou para os membros da equipe de Experience Design.

Erton W. Vieira

45 Cada uma dessas adaptaes foi realizada para que o processo de desenvolvimento englobe os conceitos de Design da Experincia de forma harmoniosa, como podemos ver na figura 2.1. Budwing et al (2009) acredita que estas adaptaes ajuda a tornar o ambiente de trabalho mais eficiente e faz com que os resultados obtidos em cada ciclo de desenvolvimento respeitem cada um das definies impostas, evitando assim, retrabalho e prejuzo para a empresa.

Tantos as prticas de Patton como as adaptaes de Budwing e seus colegas, focam em caractersticas semelhantes das duas metodologias de trabalho. O que nos leva a aferir que o caminho a ser seguido j est sendo bem fundamentado por trabalhos que abordam princpios semelhantes.

Estes so algumas boas prticas que podem ser utilizadas para a interao entre o Experience Design e os Mtodos geis. E seus benefcios so altamente perceptveis no momento em que essa integrao realizada com sucesso.

Porm se a integrao desses conceitos no for realizada com o devido cuidado, o processo gil pode limitar o trabalho do design da experincia. Conciliar a agilidade do processo com as pesquisas que a metodologia de design necessita desafiador para qualquer empresa que tem como meta uma excelncia na experincia do usurio. E a dificuldade s aumenta quando os mtodos geis no identificam o papel do designer da experincia em seu escopo de desenvolvimento, deixando o projeto da experincia em segundo plano.

Evidenciar a importncia dessa integrao de conceitos leva a um produto mais satisfatrio (Sy, 2007). E essa integrao passa por adaptaes nas metodologias geis utilizadas nas empresas. Adaptaes essas que deixam o processo de desenvolvimento do produto mais eficiente e harmonizando com os vrios conceitos de projetos existentes.

Erton W. Vieira

46

2.7 Qualidade na Experincia

O termo "experincia do usurio" est associado a uma vasta gama de significados, e nenhuma teoria coesa de experincia existe para a comunidade de design (Forlizzi e Battarbee, 2004). Os autores ainda afirmam que embora ainda no tenhamos uma teoria, uma srie de modelos e abordagens est sendo desenvolvida para nos ajudar a compreender a experincia. Que incluem contribuies das reas de design, filosofia, antropologia, cincias cognitivas, cincias sociais, entre outras disciplinas.

Alben (1996), j afirmava que por "experincia" acreditamos que significa todos os aspectos de como as pessoas usam um produto interativo: o que se sente com o produto em mos, como eles compreendem o seu funcionamento, como se sentem sobre o produto enquanto eles esto a utiliz-lo, como ele serve os seus propsitos, e como ele se encaixa em todo o contexto em que os usurios esto usando. Se estas experincias so bem sucedidas e envolventes, ento elas so valiosas para os usurios. Chamamos isso de "qualidade da experincia.

A autora definiu uma srie de critrios que apontam se a experincia foi bem sucedida ou no. So questes pertinentes e que abrangem a maioria das teorias discutidas por outros pesquisadores como Norman (2006), Shedroff (2001), entre outros. Esses critrios so:

- Compreenso do usurio: Quo profundo foi a equipe de design na compreenso das necessidades, tarefas e ambientes das pessoas para quem o produto foi projetado? Como este aprendizado refletiu no produto?

- Processo de design eficaz: Um produto o resultado de um processo de design bem pensado e bem executado? Quais foram as questes principais do projeto que surgiram durante o processo e qual foi a lgica e mtodo para resolv-las? Que metodologias foram empregadas, tais como o envolvimento do usurio, ciclos iterativos de design e colaborao interdisciplinar? Como a
Erton W. Vieira

47 programao, oramentos e outras questes prticas, tais como comunicao interpessoal, conseguiram suportar os objetivos do processo de design?

- Necessidades: Que necessidade o produto satisfaz? Faz uma contribuio significativa social, econmico ou ambiental?

- Pode ser aprendida e utilizada: O produto fcil de aprender e usar? O produto comunica sua finalidade, como comear e como proceder? este o aprendizado mais fcil de manter ao longo do tempo? So caractersticas do produto ser auto-evidente e auto-reveladora? Quo bem o suporte ao produto permite que diferentes pessoas possam se aproximar e utiliz-lo, considerando seus diferentes nveis de experincia, habilidades e estratgias para resoluo de problemas?

- Apropriado: O design do produto resolve o problema certo no nvel certo? O produto atende aos usurios de forma eficiente e prtica? Como foi que considerar aspectos sociais, culturais, econmicas e tcnicas do problema contriburam para uma soluo adequada?

- Experincia esttica: Est utilizando no produto uma esttica agradvel e sensualmente satisfatria? um produto projetado de forma coesa, exibindo continuidade e excelncia no design grfico, de interao e da informao? Existe coerncia do esprito com o estilo? O design tem um bom desempenho dentro das restries tecnolgicas?

- Mutvel: Design considerou se a mutabilidade apropriada ou no? Quo bem o produto pode ser adaptado para atender as necessidades e preferncias dos indivduos e grupos? O design do produto pode evoluir para suportar novos, talvez improvveis, usurios?

- Manejvel: Leva em considerao todo caminho percorrido pelo produto? Faz a conta e produto para ajudar os usurios a gerenciar suas necessidades, tais como instalao, treinamento, manuteno, custos e suprimentos? Essas

Erton W. Vieira

48 necessidades e outras foram consideradas para um indivduo, bem como para uma organizao?

Todos os fatores que esto descritos contribuem para o entendimento dos componentes que compem a experincia do usurio com o produto. Algumas questes fazem relao direta com o usurio, como Quo profundo foi a equipe de design na compreenso das necessidades, tarefas e ambientes das pessoas para quem o produto foi projetado?. Outros relacionam-se com o processo de design do produto, o que impacta indiretamente no usurio.

J Mahlke e Thring (2007), desenvolveram um modelo de abordagem chamado CUE-Model (Components of Users Experience Model), que partem de dois pressupostos. Primeiro que a experincia do usurio um fenmeno concomitantemente relacionado interao entre o homem e a tecnologia, e influencia fortemente a avaliao feita pelo usurio do sistema. E segundo, a experincia pode ser descrita em termos de componentes distintos interagindo uns com os outros de forma particular.

Este modelo identifica trs componentes da experincia do usurio:

- Qualidade instrumental: diz respeito ao suporte que o sistema oferece e a facilidade de uso. Recursos como a controlabilidade de componentes do sistema e a eficcia de sua funcionalidade, se enquadram nessa categoria. Intimamente relacionado com a utilidade e usabilidade do sistema.

- Qualidade no instrumental: A preocupao com o look and feel do sistema. Caractersticas como esttica visual e qualidade ttil. Relacionado com o apelo e atratividade.

- Reaes emocionais: Emoes subjetivas, reaes fisiolgicas. Por exemplo, repostas lentas a uma ao pode levar a impacincia, frustrao e raiva. Um design futurista pode levar a curiosidade, surpresa ou prazer.

Erton W. Vieira

49

2.8 Anlise do Referencial Terico

Fazer com que os valores que a empresa definiu para defender sejam percebidos no seu produto um desafio. Para alcanar esse objetivo todos os processos de desenvolvimento devem estar influenciados por estes valores. Quando a empresa desenvolve softwares, muitas caractersticas apresentamse relevantes para a construo de um produto eficiente.

As caractersticas que este estudo leva em considerao so os mtodos de desenvolvimento de software, no caso deste estudo o mtodo gil Scrum, e o projeto do design da experincia do usurio. Estas duas metodologias de trabalho, em suas caractersticas primarias, so contraditrias. Os dois mtodos so conflitantes, porm, so metodologias de trabalho que se trabalhadas em conjunto podem fazer um produto ter o diferencial que o mercado necessita.

Os valores que os usurios iro perceber do produto que esto utilizando dependem de como eles se relacionam com o produto e com a experincia que eles tm com o produto final. Gerir esses valores que sero apresentados pelo produto implica em procurar uma experincia de uso mais eficiente e satisfatria. A forma de construir essa experincia apresenta-se como um passo importante no produto final e na aceitao no usurio, pois pode influenciar na sua eficcia e na satisfao do usurio.

Mas esta adaptao no fcil de realizar, como afirmaram Fox (2010) e Cooper (2007). Porm, quando utilizada com sucesso, as duas metodologias tendem a somar seus pontos positivos, deixando o processo de

desenvolvimento eficiente. Esta a realidade que o REDU est buscando. No apenas usar as duas metodologias em conjunto, mas, alm disso, no esquecer seus valores como empresa.

Erton W. Vieira

50

Captulo

3. Mtodo de Pesquisa
Neste captulo apresentaremos os procedimentos metodolgicos utilizados nesta pesquisa. Na parte inicial apresentamos e justificamos a abordagem de pesquisa utilizada. Em seguida definimos o objetivo geral e os especficos e as estratgias utilizadas para realizao dos objetivos. Logo aps explicado como foi realizada a coleta de dados. A seguir explica-se como os dados foram tratados e os instrumentos utilizados para a anlise.

Erton W. Vieira

51

3.1 Paradigma de Pesquisa

Com o intuito de avaliar a interao entre os conceitos de Design da Experincia, Valores de Marketing e Processos geis de desenvolvimento de softwares, o pesquisador teve que entender como era que se pensava experincia e valores dentro da empresa alvo. Para isso ele se apoiou na teoria de pesquisa qualitativa para seguir com o estudo. Pois necessitaramos de uma interpretao de um fenmeno que no pode ser medido atravs de nmeros. A interpretao dos fenmenos e a atribuio de significados so bsicas no processo de pesquisa qualitativa (Silva e Menezes, 2001).

Os autores Denzin e Lincon (2000), afirmam que atravs de materiais que possam dar embasamentos para interpretaes, notas, gravaes,

documentos, entrevistas - o conhecimento vai sendo construdo a partir das habilidades interpretativas do pesquisador. Minayo (1991) completa quando afirma que a pesquisa qualitativa um paradigma ideal para reunir significado e a inteno dos atos, necessitando que essas ligaes sejam interpretadas, definindo assim suas relaes.

Os mtodos qualitativos so mais adequados para estudos de fenmenos em uma comunidade delimitada, sendo assim, a viso sobre as interaes entre os membros dessa comunidade bem definida. E a partir dessa viso das interaes e das interpretaes dos mesmos, que vai sendo construdo o conhecimento baseado na experincia do pesquisador e nos dados coletados no campo (Flick, 2009; Easterbrook, 2007).

Os objetivos propostos para o estudo classificam a pesquisa como sendo de natureza descritiva. Gil (1991) afirma que uma pesquisa descritiva visa descrever as caractersticas de determinada populao ou fenmeno ou o estabelecimento entre variveis. Envolve o uso de tcnicas padronizadas de coleta de dados: questionrios e observao sistemtica.
Erton W. Vieira

52

Por ser um mtodo qualitativo o estudo de caso colabora com o entendimento do fenmeno de um ponto de vista que seja algo a mais do que nmeros e porcentagens. Contudo, ele j foi muito descriminado por ser uma metodologia (muito) usada em estudos mal construdos e que se valem da alcunha de "qualitativo", como afirmam Savenye e Robinson (1996).

Um estudo de caso pode ter como seu caso quase tudo: indivduos, personagens, grupos, organizaes, comunidades, pases. Podem ser alguma ao, uma poltica, um incidente, um acontecimento imprevisto. Brewer e Hunter (2006) propem 6 tipos de 'casos' passveis de serem estudados em uma investigao em Cincias Sociais e Humanas, so elas: Indivduos; Atributo dos Indivduos; Aes e interaes; Atos de comportamento; ambientes, incidentes e acontecimentos; e ainda coletividades. No caso deste estudo, o definimos como sendo um estudo sobre Aes e Interaes.

3.2 Objetivos
O objetivo principal do estudo analisar como a gesto de valor em ambientes de desenvolvimento gil impacta na experincia do usurio. Para alcanar esse objetivo foram definidos objetivos especficos para conseguirmos um resultado satisfatrio.

Os objetivos especficos deste projeto so:

a) Identificar quais as proposies de valor da empresa e como elas foram definidas; b) Descrever o processo tcito do design experiencial adotado na empresa; c) Descrever a experincia do usurio e d) Encontrar pontos em comum entre variveis que descrevem o processo tcito adotado pela empresa e a experincia do usurio final.

Para cada objetivo especfico foram definidas estratgias para obteno de dados que a respondessem de forma satisfatria. Estas estratgias levaram em

Erton W. Vieira

53 conta os procedimentos e os instrumentos para coleta de dados definidas para o estudo:

- Identificar quais as proposies de valor da empresa e como elas foram definidas.

Procedimentos: a) Atravs de entrevistas, obter uma sequncia de tarefas realizadas durante o dia e quem fica responsvel por destacar os valores de Marketing no projeto. b) Atravs de observaes e entrevistas, identificar qual o grau de envolvimento marketing desenvolvimento do projeto e qual a poltica da equipe.

Fonte de Dados: a)Gerente de Projetos b)Gerente de Marketing

Instrumentos: a) Entrevista semiestruturada com os participantes responsveis pelo gerenciamento do Projeto, a fim de descobrir qual a viso deles dos valores de Marketing. b) Entrevista semiestruturada com os participantes do projeto responsveis pela codificao do projeto, a fim de descobrir qual a viso deles dos valores de Marketing.

- Descrever o processo tcito do design experiencial adotado na empresa.

Procedimentos: a) Atravs de entrevistas, identificar como o processo de desenvolvimento evoluiu e se adaptou com o passar do tempo. b) Atravs de pesquisa documental, obter indcios da evoluo do processo de desenvolvimento.
Erton W. Vieira

54

Fonte de Dados: a) Gerente de Projetos b) Programadores c) Designer

Instrumentos: a) Obter uma cpia do documento de requisitos para avaliar se os valores de marketing e a experincia do usurio esto sendo abordados no documento. b) Adquirir o documento de design elaborado para o

desenvolvimento das interfaces do sistema. c) Entrevista semiestruturada, com o objetivo de captar relatos dos desenvolvedores de como foi o processo de desenvolvimento do sistema e como este processo foi evoluindo com o tempo.

- Descrever a experincia do usurio.

Procedimentos: a) Atravs de pesquisa de levantamento junto ao usurio de instituio selecionada, definir a experincia do usurio junto ao sistema pesquisado. b) Atravs de entrevistas, obter junto ao usurio as impresses sobre o sistema e sua experincia ao utiliz-lo. c) Atravs de pesquisa documental, centrar na experincia de uso do sistema em instituies colaboradas.

Fonte de Dados: a) Gerente de Projetos b) Gerente de Marketing c) Usurio

Instrumentos:
Erton W. Vieira

55 a) Entrevistas semiestruturadas, com o objetivo de identificar como os usurios do REDU definem a experincia no sistema. (anexo C). b) Questionrios respondidos pelos usurios para obteno de dados sobre a aceitao do sistema. (anexo A) c) Obter documentos que mostrem como foi descrita a experincia do usurio em testes realizados em outras instituies.

Os dados utilizados para a realizao deste objetivo especfico foram adquiridos atravs de documentaes cedidas pela equipe do REDU. Estudos realizados por outros pesquisadores foram interpretados e apresentados de forma que o objetivo especfico fosse alcanado. Apesar destas pesquisas cedidas no terem o foco na relao entre os conceitos apresentados nessa dissertao, os dados puderam ser interpretados e usados para conseguirmos essa relao e definir como foi a experincia na utilizao da ferramenta REDU.

O ltimo objetivo especfico - encontrar pontos em comum entre variveis que descrevem o processo tcito adotado pela empresa e o design da experincia fica dependente da anlise dos dados obtidos nas etapas anteriores da pesquisa, tanto da discusso terica, de onde tiramos os conceitos que tero ser utilizados, quanto dos dados colhidos em campo atravs das entrevistas e observaes.

3.3 Estratgia de Pesquisa: Estudo de Caso

O estudo de caso uma importante ferramenta cientfica que mostra como um determinado objeto se comporta diante de uma nova situao, seja ela, resoluo de problemas, busca por mais conhecimento ou construo de algum artefato. Podendo servir de exemplo para outros objetos que possuam as mesmas caractersticas do objeto doravante estudado.
Erton W. Vieira

56

O Yin (2001) afirma que "um estudo de caso uma investigao emprica que investiga um fenmeno contemporneo dentro de seu contexto da vida real, especialmente quando os limites entre o fenmeno e o contexto no esto claramente definidos". Com isto possvel concluir que um estudo de caso pode ou deve ser utilizado para entender um fenmeno no qual no esto claros seus limites com o contexto em que ele est inserido. Neste estudo podemos definir como fenmeno a insero dos valores de marketing nas interfaces e o contexto como sendo o seu desenvolvimento atravs de mtodos geis.

Para

nortear

pesquisa,

foi

elaborada

uma

questo

chave

para

estabelecermos uma estratgia relevante a ser utilizada. Nesta pesquisa em si a questo elaborada foi: "Como a gesto dos valores de marketing em ambientes de desenvolvimento gil est impactando na experincia do usurio do REDU?. As unidades de estudo desta pesquisa so os setores de Desenvolvimento, Design e Marketing do REDU, focaremos, entretanto, no desenvolvimento da experincia do usurio.

Este estudo foi definido como um Estudo de Caso nico, tambm definido como Incorporado, pois levar em considerao trs perspectivas do desenvolvimento da experincia no REDU: o desenvolvimento gil, o design da prpria experincia e o envolvimento da equipe de marketing da empresa. Aprofundando na sua definio ele pode ser classificado como sendo um Estudo de Caso Decisivo, pois testa uma teoria que especificou um conjunto claro de informaes e que pode ser a chave para o entendimento desta teoria ou para redirecionar as investigaes futuras.

3.4 Caso: Redu

O REDU um startup pernambucano que se assemelha a tantas outras no que se diz respeito equipe de desenvolvimento. formada por um nmero restrito de profissionais com caractersticas bem definidas. Conhecer a estrutura do
Erton W. Vieira

57 REDU essencial para que o estudo possa ser utilizado como referncia para outros startups, pois, com a mesma estrutura, a experincia de

desenvolvimento tende a ser semelhante, assim pode-se aprender com os acertos e erros j cometidos por equipes com caractersticas similares.

O startup REDU tem como seu produto principal a Rede Social Educacional, o REDU. Startup e ferramenta contem o mesmo nome, porm, com valores distintos, que so reflexo de suas finalidades. Para esta pesquisa, os valores que sero levados em considerao sero os valores da rede social REDU.

Numa poca em que as Redes Sociais esto obtendo uma adoo massiva de boa parte da populao, o REDU apresenta uma proposta de aproveitar esse sucesso que as redes sociais esto fazendo e focar em algo nobre: o compartilhamento do conhecimento. Melo (2010) diz que a ferramenta REDU foi concebida para que os estudantes e profissionais de ensino disponham de um ambiente de armazenamento e resoluo colaborativa de provas e visualizao do desempenho. Somadas a isso todas as caractersticas que facilitam o compartilhamento de informaes que intrnseco de qualquer rede social.

A ferramenta REDU oferece suporte colaborao, discusso e disseminao de contedo educacional (Abreu et al., 2011) por ter sido construda com base nas interaes sociais. A proposta da ferramenta REDU utilizar a tecnologia de anlise das interaes disponveis em redes sociais para permitir a criao de comunidades com diferentes nveis de acesso que potencializem a interao entre pares e ajuda mtua para criar um ambiente favorvel aprendizagem. (Abreu, 2011). No contexto apresentado, a ferramenta REDU foi projetada como um novo conceito de plataforma de ensino que expande a experincia do usurio em mdias sociais para conceitos mais especficos como redes sociais de aprendizagem. A ferramenta REDU um ambiente de ensino que procura fornecer ampla percepo do contexto da educao, utilizando de atividades, atores, recursos e metodologias que os apoiem a conseguir o seu objetivo (Abreu et al, 2011; Melo, 2010).

Erton W. Vieira

58 Uma vez conectado com a ferramenta REDU o usurio ter um acesso rpido ao contedo disponibilizado para ele. E o sistema pode acompanhar a performance do usurio e elaborar um histrico com o desempenho nas atividades desenvolvidas no ambiente ao longo do tempo. Atividades essas que compreendem comunicao, aproximao, ajudas mtuas, resoluo de problemas e participao em fruns e sees de aula pela internet. As atividades foram desenvolvidas para incentivar as interaes entre os pares. (Abreu, 2011; Claudeivan, 2011).

Algumas caractersticas da ferramenta REDU o diferenciam de outros ambientes virtuais de aprendizagem (AVA), como:

- Interface de insero de novas provas e questes - As questes podem ser inseridas das mais diversas formas de apresentao: marcao de opo; atribuio de valor numrico; marcao de uma regio fechada em grfico, figura, diagrama ou slide. Permite ainda a insero de questes discursivas, que podem ser respondidas a partir da cooperao entre os pares. - Ambiente de composio e publicao de testes - Aps construdo a banco de questes os testes podem ser gerados de forma manual ou automtica. Permitindo ainda alternar a ordem das questes e de suas alternativas, de forma a diferenciar aos usurios. - Engenho de tratamento dos dados de interao em rede social Trata os dados relativos ao comportamento dos usurios e suas interaes no sistema. As comparaes possveis tm por base tratamentos estatsticos pr-definidos pelo gerenciador do sistema. A partir das anlises realizadas possvel geras recomendaes de contedos e de pessoas com os quais os usurios deveriam interagir para melhorar seu desempenho geral na preparao dos concursos. - Apresentao de anlises de desempenho por meio de visualizaes Os resultados gerados pelos engenhos de tratamento de dados de rede social so apresentados atravs de grficos e tabelas para a visualizao na tela ou para a impresso. Essa rea pode ser configurada com opes de acesso restrito,
Erton W. Vieira

59 liberando para os usurios apenas as visualizaes dos resultados previamente liberados pelo gerenciador do sistema. - Fruns para resoluo colaborativa de problemas Ambiente para resoluo colaborativa de problemas relevantes comunidade de usurios. - Ambiente de recomendaes de pessoas e materiais O sistema apresenta recomendaes baseadas no perfil individual e nas atividades na rede social. Pessoas e materiais so sugeridos aos usurios.

Definido isto, o objetivo central do REDU conceber um conjunto de estilos de interao, formas de comunicao e colaborao que possam oportunizar o acesso a educao formal e informal, atendendo as necessidades de instituies e produtores independentes que querem construir sua prpria EaD (Abreu, 2011; REDU, 2011; Melo, 2010).

3.5 Procedimentos e instrumentos de coleta de dados

O objetivo geral do estudo analisar como a gesto de valor em ambientes geis de desenvolvimento impacta na experincia do usurio do REDU. Tambm faz parte do processo identificar como os desenvolvedores enxergam a experincia do usurio em conjunto com os mtodos geis de desenvolvimento e quais as peculiaridades eles encontraram no processo do design dessa experincia.

Estas questes esto definidas em cada objetivo especfico definido neste estudo, que podem ser vistas na sesso 3.2 deste documento. Conduzimos o estudo a fim de completar cada um destes objetivos e para cada um dos objetivos definimos um procedimento e as ferramentas para coleta dos dados.

Para obtermos os dados recorrentes a este estudo de caso, foram utilizadas vrias ferramentas de captao de dados relatadas na literatura (Yin, 2001; Coutinho e Chaves, 2002; Flick, 2009). A diante temos uma listagem das
Erton W. Vieira

60 ferramentas utilizadas no Estudo e suas implicaes com a qualidade dos dados obtidos atravs das mesmas.

3.5.1 Entrevista

Com a finalidade de conseguir esses dados foi necessrio entrar em contato com os envolvidos no desenvolvimento do REDU e com os seus usurios. Para isso foi definido procedimentos para entrar em contato com os

desenvolvedores para a coleta dos dados, para que a qualidade destes dados seja suficiente para uma interpretao verdadeira da realidade do projeto. Os seguintes passos foram respeitados:

As entrevistas e contatos devero ser efetuados preferencialmente com os gerentes de Projeto e de Marketing, por eles definirem qual o melhor horrio e ambiente para as entrevista, com o intuito de no atrapalhar no

desenvolvimento do projeto. O agendamento de entrevistas ser efetuado atravs de contato direto com os gerentes de Projeto e de Marketing, com, no mnimo, 1 (uma) semana de antecedncia para a data da entrevista.

Por haver apenas um pesquisador disponvel para a realizao do Estudo e Caso, ser utilizado, como alternativa para as entrevistas em campo, o expediente de entrevistas realizadas por chat de voz, atravs de softwares que realizam tal ao. No caso especfico deste Estudo de Caso, software escolhido foi o Skype1.

3.5.2 Observao

As

observaes

foram

realizadas

nas

reunies

que

grupo

de

desenvolvimento tinha a cada semana, o que eles definiram como o

Skype um software que permite comunicao pela internet atravs de conexes de voz sobre IP (VoIP)
Erton W. Vieira

61 Doomsday. Que onde o pesquisador poderia aferir como se dava a interao entre os membros do grupo responsvel por construir o sistema.

As observaes foram importantes para captar como se d a interao entre os responsveis por codificar o sistema e o responsvel pelo projeto da experincia do usurio. As interaes entre estes membros da equipe eram analisadas e as decises tomadas nestas reunies eram arquivadas. As reunies ocorriam geralmente com todos os participantes da equipe de desenvolvimento e cada um destes participantes tinham voz ativa nas reunies.

As reunies foram gravadas em arquivos de udio para posterior anlise.

3.5.3 Pesquisa Documental

Todos os documentos necessrios ao arquivamento e posterior consulta para este projeto estavam disponvel no espao compartilhado de arquivos na internet. No caso deste projeto, o Google Docs. Todos os integrantes do REDU tero acesso a estes documentos e podero atualiz-los a qualquer momento a partir que forem ocorrendo mudanas no projeto.

Os documentos e as imagens necessrias para a pesquisa documental ser solicitada junto ao Gerente do Projeto REDU com antecedncia para a apreciao do pesquisador. Entre estes documentos esto os planos de releases, banco de ideias e verses de melhorias. Todos os dados disponveis nestes documentos esto visveis para todos os participantes do projeto.

3.5.4 Registro de Arquivos Os documentos utilizados para a coleta de dados so oriundos de duas dissertaes de mestrado que utilizaram o ambiente REDU como cenrio de pesquisa. Atravs dos dados destes arquivos foi possvel identificar relatos de como foi a experincia na utilizao do sistema.
Erton W. Vieira

62

Alm destas dissertaes, outro arquivo solicitado ao REDU foram os dados de uma pesquisa realizada com alunos da Escola do Recife. Os alunos participaram de testes de usabilidade e aceitao e os dados brutos foram armazenados em uma planilha e compartilhados com os pesquisadores. Atravs desses dados, os pesquisadores interpretaram e apresentaram suas concluses de como seriam as relaes dos conceitos apresentados.

3.6 Anlise dos Dados Coletados

Aps a coleta de dados, dados esses obtidos atravs das estratgias definidas na seo anterior, o pesquisador ficou com um grande material documental e de udio para posterior anlise. Todos os udios foram transcritos e documentadas para apreciao, categorizao e anlise.

A anlise dos dados compreendeu a descrio dos dados e a interpretao dos diferentes aspectos do fenmeno. Para tanto, foram utilizados como base para a anlise dos dados os conceitos desenvolvidos por Yamazaki e Furuta (2007), no que se refere ao design da experincia dentro da equipe do REDU; no que se refere qualidade da experincia foi utilizado como base de anlise os conceitos definidos por Alben (1996). E foi observado todo o perodo de tempo de vida do projeto REDU, desde o seu incio (primeiro projeto da disciplina de Interao Homem Computador do Centro de Informtica da UFPE) at o lanamento de sua verso mnima em 2011.

Tanto os critrios de Alben (1996) quanto o CUE Model de Mahlke e Thring (2007), descritos no captulo 2 (dois) sero utilizados para a categorizao de como a experincia do usurio tratada no desenvolvimento do REDU.

Esta interpretao dos dados coletados no campo determinante para alcanar os objetivos propostos para a pesquisa. Um plano de pesquisa fundamental para isto, e Yin (2001) afirma que para um plano de pesquisa qualitativo, o estudo de caso ideal para a investigao de um fenmeno
Erton W. Vieira

63 dentro de um contexto de vida real. O estudo de caso foi a escolha de estratgia de pesquisa por se encaixar melhor nos objetivos do estudo. Fazendo uso de um organograma que foi definido por Yin (2001), em que ele lista variveis que possam ajudar na escolha de mtodos de pesquisa, este estudo se encaixa perfeitamente na estratgia de estudo de caso, pois a questo de pesquisa tem a forma de "como, por que", no exige controle sobre eventos comportamentais e focaliza acontecimentos contemporneos.

Erton W. Vieira

64

Captulo

4. Anlise dos Resultados

Neste captulo feita a anlise dos dados coletados durante a pesquisa com a inteno de entender como se d a utilizao dos mtodos geis e o design da experincia.

Erton W. Vieira

65 Neste estudo, para cada um dos requisitos especficos - identificar quais as proposies de valor da empresa e como elas foram definidas; descrever o processo tcito do design experiencial adotado na empresa; descrever a experincia do usurio e; encontrar pontos em comum entre variveis que descrevem o processo tcito adotado pela empresa e a experincia do usurio final. - foram associados mtodos e instrumentos para a obteno dos dados necessrios. Para que o pesquisador obtivesse uma viso ampla do sistema, do ambiente em que ele est inserido, do ambiente em que ele foi produzido e do impacto que ele causa na sociedade. A pesquisa foi realizada com o cuidado de se tornar um documento de estudo para ser usado, no s pelos interessados diretos no REDU, mas para todos que tenham empreendimentos com estrutura e objetivos semelhantes referida empresa.

Dividimos ento este projeto da seguinte forma: A primeira parte do trabalho ser a efetiva apresentao de todos os profissionais envolvidos diretamente com o REDU, todos os seus participantes e perfil de cada desenvolvedor, a segunda parte ser a anlise dos dados obtidos para cada um dos objetivos especficos, cada objetivo especfico ser abordado de forma individual e em conjunto com os demais objetivos. Logo aps a anlise de todos os dados referentes ao estudo e j com o conhecimento aprofundado sobre o caso em estudo, se dar a terceira parte do trabalho, onde ocorrer uma discusso sobre o valor do conhecimento adquirido e como ele poder e dever ser utilizado pela sociedade.

4.1 Perfil REDU

Primeiro, apontaremos um breve resumo de como se deu o desenvolvimento da rede social REDU, do incio at o ponto no qual o startup encontra-se no momento. O projeto foi concebido para um projeto de uma disciplina de graduao do Centro de Informtica da Universidade Federal de Pernambuco (CIn-UFPE). Seu objetivo inicial era estender para o ambiente virtual a continuidade do ensino na sala de aula. Atualmente a equipe do REDU formada por (no contm hierarquia):

Erton W. Vieira

66

Quadro 4.1 Equipe REDU.

Equipe REDU
Abreviao Funo Responsabilidades - Relao de pesquisa entre empresa e CA Consultor Acadmico academia. - Contato direto com o CCTE UFPE: Mestres e Doutores - Estratgia da Empresa e Captao de CM Consultor de Mercado Recursos - Relao com os parceiros - Intermedirio junto ao CNPq - Lder tcnico do redu-api P1 Desenvolvedor 1 - Decises tcnicas e pela qualidade do cdigo P2 Desenvolvedor 2 - Coordenador do projeto da API - Representante do REDU na Europa. - Lder tcnico do redu-core P3 Desenvolvedor 3 - Tratamento de erros - Contato tcnico com o usurio P4 Desenvolvedor 4 - Desenvolvimento na equipe do redu-core - Tratamento de erros - Metodologias de gerenciamento e GP1 Gerente 1 inovao - Relao com os parceiros - Gerente de projetos - Concepo de solues: pesquisas e D1 Designer 1 projeto piloto - Interao/Validao com o Consultor Acadmico e time de desenvolvimento

Tendo conhecimento das caractersticas de cada integrante da equipe que est diretamente envolvida no desenvolvimento do REDU, podemos aqui fazer uma comparao com a equipe ideal para projetar experincia do usurio definido por Yamazaki e Furuta (2007). Obviamente levando em considerao que o
Erton W. Vieira

67 estudo dos pesquisadores japoneses foi realizado levando em considerao empresas de maior porte. Contudo podemos traar aqui um paralelo entre a equipe ideal e a existente no REDU.
Quadro 4.2 Equipe REDU em paralelo equipe de design da experincia de Yamazaki e Furuta (2007).

Paralelo com a equipe de design da Equipe Redu experincia ideal segundo Yamazaki e Furuta(2007) Consultor Acadmico Consultor de Mercado Gerente Designer Desenvolvedores Pesquisador usurio; Especialista em testes com usurios; Planejador de marketing; Lder do Projeto; Designer da Experincia; Designer Visual;

Observando o quadro 4.2, constata-se que o projeto do design da experincia do usurio fica dividido entre dois integrantes do projeto: O designer, que quem vai projetar, e o Consultor Acadmico que quem vai fazer a ponte com as pesquisas que esto sendo realizadas na academia. Tendo em vista a equipe ideal de Yamazaki e Furuta, a equipe do REDU consegue efetuar uma diviso equilibrada dos papis entre seus membros. Mesmo com sobrecarga de algumas funes, devido ao nmero reduzido de componentes na equipe, membros da equipe so responsveis por tarefas que no diferem muito da equipe ideal de Yamazaki e Furuta (2007).

4.2 Anlise dos Dados

Para cada um dos requisitos especficos foi definido um conjunto de aes que deveriam ser respeitadas para a coleta dos dados da pesquisa. Esse protocolo pode ser encontrado em anexo deste projeto.

Erton W. Vieira

68 Dividiremos a anlise por cada um dos objetivos especficos definidos no projeto.

4.3 Identificar quais os valores da empresa e como eles foram definidos

Para este objetivo especfico definimos que a melhor forma de obter os dados era atravs de entrevistas com cada um dos integrantes do projeto REDU. Ouvimos de cada um destes integrantes a definio dos valores definidos pela empresa. Ao final faremos uma breve discusso de como esses valores impactam na experincia e no desenvolvimento.

As entrevistas foram realizadas da sede do REDU, que fica localizada no Bairro do Recife e faz parte do arranjo produtivo denominado Porto Digital. Foi realizada uma entrevista semiestruturada com o objetivo de adquirir de maneira espontnea esses valores de cada um dos integrantes do projeto. Os valores aqui identificados so referentes ferramenta REDU, pois o startup REDU tem valores mais condizentes s suas aes. Os valores definidos para a rede social REDU, e com os quais iremos usar como base para posterior anlise, so mostrados a seguir. Estes valores foram definidos no planejamento estratgico criado junto com a fundao da empresa.

Eles no esto apresentados por ordem de importncia, pois no foram definidos dessa forma. A apresentao dos valores se d pela ordem em que foram citados na entrevista com o Gerente de Marketing do REDU. Os valores so: a) Ser intuitivo; b) Ser fcil; c) Estar na moda; d) Ser conveniente; e) Ser produtivo; f) Ser divertido;

Erton W. Vieira

69 Definidos ento os valores para o projeto, o pesquisador foi buscar o que significa cada um desses valores para as pessoas envolvidas no projeto REDU. Nas entrevistas o pesquisador pediu para que cada integrante definisse o que significava cada um dos valores da empresa. Abaixo esto as respostas mais significativas para cada um dos valores.

- Ser intuitivo GP1 Ser intuitivo no precisar pensar muito para realizar uma tarefa. Se ele (o usurio) tem uma necessidade, a interface tem que automaticamente dar essa resposta a ele. Mesmo que seja em etapas no sendo em um clique s que eu seguindo esse caminho vou conseguir chegar onde eu quero. (...) A interface tem que guiar o usurio sem que ele tenha que pensar muito.

- Ser fcil D1 Para a gente atingir todos os objetivos propostos, o nosso sistema tem que ser fcil de ser utilizado, que seja adaptado padres mentais j recorrentes. No inserir elementos que possam atrapalhar ou dificultar a produtividade, pelo contrrio, queremos aumenta-la.

- Estar na moda P1 O Orkut no comeo era pouco usado, mas com o tempo foi ficando mais famoso e na moda. Com o Facebook foi o mesmo, pouco gente usando no comeo, mas agora o lder. O mesmo com o Tumbrl (...). O que ns queremos com o REDU dar essa caracterstica na moda, as pessoas quererem usar sem um motivo especial e que esse efeito seja prolongado.

- Ser conveniente D1 o produto em si e a necessidade que ele atinge. (...) O que faltava era uma plataforma em que de fato a educao possa fazer diferena. Em um sistema que tambm possa fazer a diferena. (...) E ainda no tem um sistema- ou um site que consiga aliar tudo que a gente que aliar no REDU.
Erton W. Vieira

70

- Ser produtivo P1 Fazer o necessrio para poder facilitar ao usurio a realizar uma determinada tarefa. No colocar uma funcionalidade a mais, caracterstica a mais no produto s porque legal, mas porque aquilo vai ter um fim.

- Ser divertido P3 Ser mais interativo (...) o aluno ou at mesmo o professor, acessar o REDU passar um tempo l e no achar chato. Porque tem coisas que s gente faz e fica olhando no relgio pra saber se j passou a hora. O ideal seria o aluno entrar l e no ver as horas passarem, interagindo com o sistema. D1 Uma caracterstica que est bem implcita nas trocas sociais do sistema, o que falta para o sistema ser mais divertido inserirmos mais elementos de interatividade para que o usurio no se sinta preso a um esteretipo acadmico.

As definies dos valores da empresa no diferem muito de integrante para integrante. Pois j passaram uma boa parte do tempo do projeto assimilando o ideal de cada um dos valores de marketing do projeto. Formando um conhecimento coletivo do que seria cada um dos valores e a melhor forma de trabalhar eles no decorrer do projeto.

4.4 Descrever o processo tcito do design experiencial adotado na empresa

Como podemos observar nas definies dos valores do REDU, pelos prprios desenvolvedores e envolvidos no sistema, esses valores foram pensados com o intuito de tornar a experincia do usurio a mais desejvel possvel. Com um nvel de qualidade de experincia que conquiste o usurio e faa com que ele retorne para o sistema e passe a utiliz-lo com frequncia. Fazer com que esta experincia seja prazerosa um dos maiores desafios do REDU, e o caminho
Erton W. Vieira

71 para conseguir este objetivo passa por trabalhar os seus valores em conjunto com o projeto da experincia no momento da construo do sistema.

Neste objetivo especfico foi analisada a interao dos membros que fazem parte do REDU. A anlise foi realizada no startup REDU e no na ferramenta.

4.4.1 Desenvolvimento e os valores No momento da construo do REDU, os valores so tratados como norteadores quando se encontram em vias de tomar uma direo no desenvolvimento que pode mudar as caractersticas antes pensadas. GP1 Quando ns temos alguma dvida, ou quando estamos no processo e surgem questes de isso tem que ser assim... no, tem que ser do outro jeito a gente sempre lembra: ser que isso fcil? Ser que isso divertido? Esses so os pilares da gente. Pra tudo que fazemos ns focamos nos valores. uma coisa que est no cotidiano da gente. Tanto da empresa quanto no produto. LP3 Na hora de conceber a ideia a gente tem que levar isso (valores) em considerao: Ser que isso vai ser cabuloso de fazer na hora? Mas isso mais na hora de pensar, que so mais variveis que temos que levar em conta. No momento de fazer isso funcionar mais tranquilo. Na hora de codificar mesmo, eu no me sinto impactado (pelos valores), no.

Como a empresa formada por pessoas recm-sadas da academia, a experincia que eles tm na utilizao de mtodos geis de desenvolvimento foi adquirida, praticamente, durante a sua formao acadmica e no no mercado real. LT3 O Scrum, eu usei em uma tarefa da faculdade, no como trabalho mesmo. Na verdade, no usvamos o Scrum de fato, utilizvamos apenas alguns elementos do mtodo. Porm, quando passamos a trabalhar com o
Erton W. Vieira

72 Scrum de fato, achei muito legal. Utilizar estimativas (...), histrias, tarefas (...) depois que nos adaptamos, ficou bacana trabalhar.

O REDU consegue envolver toda a equipe de desenvolvimento na responsabilidade de manter o seu sistema de acordo com os valores definidos por eles mesmos. Defendem e debatem esses valores para uma melhor representao deles no sistema. As reunies frequentes, devido a metodologia de desenvolvimento, ajudam nessa integrao e interao entre a equipe responsvel pelo REDU.

4.4.1.1 Banco de Ideias

A equipe de desenvolvimento do REDU trabalha com vrios tipos de requisitos para o sistema. Cada um destes requisitos fruto de observaes dos prprios desenvolvedores em ambientes com finalidades semelhantes ao REDU, de sentimentos sobre o sistema destes desenvolvedores, alm de requisitos extrados a partir de testes com os usurios, onde eles em seus testes ficavam sugerindo modificaes e fornecendo novas ideias para o sistema.

Com essas ideias em mos, a equipe de desenvolvimento do REDU construiu um banco de ideias para o REDU. Nesse banco as ideias seriam organizadas, categorizadas, ranqueadas e seriam classificadas em relao s quais valores da empresa estas ideias estariam abraando.

Este banco de ideias dividido em: Soluo/Hiptese/Ideias A ideia propriamente dita, extrada de experincia dos prprios desenvolvedores e participantes do REDU e dos usurios. Qual necessidade vai atender definida qual necessidade do usurio ou do sistema esta ideia vai atender. Passo importante para conhecer as necessidades dos usurios, observando se aquela necessidade abordada mesmo relevante junto ao usurio.

Erton W. Vieira

73

Caracterstica Killer Qual a caracterstica mais importante que a ideia ira abordar. Proponente Quem sugeriu a ideia. Ranking Qual o grau de importncia da ideia junto ao sistema. Valores Qual valor definido pela empresa esta ideia est abordando.

Com essa tabela em mos, os desenvolvedores do REDU podem ter uma ideia de qual caminho o projeto vai seguir, tanto em longo prazo, com uma ideia geral do que ser o REDU, como uma viso em curto prazo, quais so as ideias melhores ranqueadas que sero alvo do desenvolvimento nas prximas sprints. Estas ideias propostas esto definidas tanto para o Core do sistema, quanto para as APIs que sero fornecidas pelo REDU. Este banco de ideias fica disponvel para todos os participantes do projeto, e qualquer um pode ser um proponente de ideias, tornando o processo de desenvolvimento mais produtivo, j que os desenvolvedores estaro

trabalhando em suas prprias ideias para o sistema. Tornando todos os processos, de desenvolvimento ao design, mais eficazes.

4.4.1.2 Incio do Desenvolvimento da interface Boa parte da experincia no sistema definida pela interface do mesmo. onde a interao entre sistemas e usurios se d. Por isso a ateno no desenvolvimento desta interface deve ser rigorosa e, novamente, deve estar de acordo com o que foi definido como valor e como experincia ideal. No caso do desenvolvimento da interface do REDU, existiram dois momentos distintos de como se trabalhou a interface. Pois, no primeiro momento, a equipe do REDU no contava com a figura do designer no projeto. Boa parte do que era definido como interface e, consequentemente, definido como experincia era absorvido
Erton W. Vieira

74 dos estudos e definies do Consultor Acadmico do REDU, que j tinha desenvolvido estudos e projetos com foco em interao humano computador. Alm de contar com o conhecimento dos prprios desenvolvedores, adquiridos em disciplinas da graduao, na hora de projetar a interface. LT3 Antes, no tinha o papel do designer. Alis, no tnhamos um designer de fato. E a gente tentava se virar, fazendo a tela como achvamos que deveria ser. Sem muita tcnica.

No segundo momento, j com a incluso da figura do designer na equipe do projeto. A dinmica de desenvolvimento foi adaptada.

4.4.2 Adaptao do designer ao Scrum

Logo que o designer foi adicionado na equipe do REDU aconteceu uma dificuldade para ele acompanhar o ritmo que j estava imposto pela equipe. Levando em considerao algumas experincias de sucesso integrando as metodologias de design e os mtodos geis, a equipe do REDU props que o designer trabalhasse uma Sprint a frente da equipe de desenvolvimento, ou o mais adiantado quanto fosse possvel para o designer. LT2 O designer, logo quando ele entrou, ele sofreu bastante para poder ficar uma Sprint a frente da gente (codificao). Ele chegou aqui e penou. LT3 Quando ele (designer) entrou, ele teve que refazer todas as telas. O primeiro impacto foi esse. Ele tinha que criar as telas e ns (desenvolvimento) tnhamos que trocar todas as telas antigas pelas novas.

Os prprios desenvolvedores relataram que o designer teve dificuldade em adaptar-se. Os desenvolvedores j estavam acostumados com o ritmo gil que impe este tipo de metodologia de desenvolvimento. Mas para profissionais
Erton W. Vieira

75 que trabalham com metodologias que requerem um tempo maior para pesquisa e estudos, a mudana para uma metodologia gil impactante. D1 Quando cheguei, claro, tive que adaptar ao workflow. Tive que me adaptar ao Scrum. Ento precisei de um tempinho de adaptao. Mas como a energia (da equipe) era muito similar, ento acabou tornando (a adaptao) menos complicado. D1 O designer tem que estar frente porque ele precisa ser validado, ele precisa ser testado, ele precisa receber feedback. Ele precisa ser viabilizado como uma estrutura antes de ir pra l (desenvolvimento). Quando eu cheguei aqui as coisas estavam muito adiantadas. Tinha uma pilha de coisas pra fazer. A arquitetura j estava montada. Ento tive que me adaptar bastante para o que j estava sendo feito (...) e a partir da comear o meu trabalho.

comum para os designers que esto comeando em um projeto de sistemas de informao que ele desenvolva toda a arquitetura de informao fazendo com que o resto do seu trabalho seja feita em cima do que ele mesmo criou, facilitando o desenvolvimento dos artefatos. No REDU o processo de adaptao do designer mostrou-se ainda mais complicada quando ele teve que adaptar-se a uma arquitetura que j estava montada e que no tinha muito tempo para poder estudar esta arquitetura. As modificaes na arquitetura foram sendo realizadas ao longo do trabalho do designer, ao mesmo tempo em que ele desenvolvia as interfaces.

Contudo, as dificuldades de trabalhar com duas metodologias que veem o tempo de maneiras diferente, ficaram claras no decorrer desse perodo de adaptao. D1 A maior dificuldade que tive com o Scrum foi deixar todo o planejamento do trabalho bem dividido, bem separado. Tive uma dificuldade tremenda para definir algumas coisas prticas como nveis de escopo,

Erton W. Vieira

76 aprender a dividir uma tarefa no mximo de sub tarefas possveis, definir limites de esforo.

A dificuldade do designer em dividir o projeto aceitvel, pois na academia os designers trabalham em um projeto pensando nele como um todo. Projetam do incio at o fim, passando por uma srie de estudos como reviso histrica e concorrentes, aceitao, entre outras. Pensar em um projeto dividido sem ter uma ideia geral de como o todo estranho aos designers, por isso a dificuldade do designer para adaptar-se s metodologias de desenvolvimento da empresa.

Porm, aps pouco tempo, o designer conseguiu adaptar-se e alcanar a linha de desenvolvimento e passou a trabalhar a frente desta linha, ou no mximo, em paralelo com o que a equipe de desenvolvimento estava trabalhando no momento. GP1 O designer estava algumas Sprints atrasados em relao ao restante do processo de desenvolvimento do sistema. Mas chegou um momento em que a equipe de codificao comeou a desenvolver a funcionalidade do chat, que era uma funcionalidade complexa de desenvolver. E ento ele (designer) conseguiu ultrapassar a Sprint da equipe de codificao.

Contudo algumas adaptaes no processo gil foram realizadas para que os dois modos de trabalhar se combinassem para a necessidade do sistema e da equipe. LT2 Primeiro, temos uma pessoa na equipe (marketing e estratgia), que responsvel por detectar alguns problemas. Depois, pegamos elementos j estudados pelo grupo de pesquisa e tentamos resolver tais problemas. Ento temos um problema e uma soluo j solucionada na academia e logo aps passamos essas informaes para o nosso designer. E o designer faz todo o trabalho na interface. Durante o tempo que o designer est desenvolvendo a interface o grupo de pesquisa pode ir at ele e d um feedback imediato. O
Erton W. Vieira

77 designer deixa bem aberto a opo de qualquer integrante da empresa ir l e fazer alguma observao sobre a interface.

Caractersticas dominantes do processo gil ainda so dominantes e utilizadas no processo de desenvolvimento do REDU. Um exemplo claro so as reunies em final de cada Sprint. No REDU, cada Sprint tem a durao de 2 a 3 semanas. Porm, ocorre no ltimo dia til de cada semana uma reunio para compartilhar os avanos que ocorreram durante a semana em questo. um momento oportuno para o designer mostrar para os demais integrantes da equipe o seu trabalho e colher os feedbacks dos outros interessados no projeto. LT2 Ns temos uma cerimnia que ocorre dia de sexta, que chamamos de Doomsday, que quando o designer mostra o que fez durante a semana e recolhe o feedback da gente. At porque, como a gente utiliza a metodologia Scrum, ele est sempre a uma Sprint a frente da gente. E a funcionalidade que ele est desenvolvendo o layout, vai influenciar na (nossa) Sprint. E a ns damos um insumos a ele no ponto de vista mais tcnico de como aquela o que ele est desenvolvendo vai funcionar.

Todos os membros da equipe do REDU tem a definio do que so seus valores. Mostrando segurana e conhecimento do que realmente o sistema se prope. Eles definem que seus valores so os norteadores do desenvolvimento do sistema.

Isso fica claro quando o processo de desenvolvimento sofre adaptaes em busca de uma maneira de deixar este processo mais eficiente, e fazendo com qu todos os valores da empresa sejam discutidos em cada caracterstica trabalhada em cada Sprint. Esse respeito aos valores da empresa pode ser percebido quando os testes com os usurios apontam que a experincia dos mesmos com o REDU respeitava, ou buscavam respeitar, os valores da empresa.

Erton W. Vieira

78 E estes valores impactaram positivamente tambm na forma de construo do sistema. Os valores tambm influenciavam a dinmica entre os membros da equipe. O ambiente de trabalho tambm era definido por seus valores, como conveniente, produtivo, divertido. Essa busca por respeitar os valores no ambiente de trabalho influenciou para a incorporao desses valores em cada caracterstica do REDU.

4.4.3 Adaptao da equipe de desenvolvimento ao designer

Uma das maiores dificuldade encontrada no desenvolvimento das interfaces e, consequentemente, no projeto da experincia era alinhar a viso do designer, que trabalhava em um ritmo distinto dos outros membros da equipe, e a viso da prpria equipe de desenvolvimento. GP1 Uma dificuldade (do processo) estar alinhado as perspectivas do desenvolvimento e do design. Porque, antes de o designer comear a fazer (a interface) ns j temos algumas ideias, s que as vezes o que o designer conclui pode causar uma surpresa, tipo no era bem isso que estvamos pensando. Essa separao da equipe, o designer trabalhando sozinho (na interface) pode causar esse tipo de surpresa, gerando esse no alinhamento do que est sendo feito.

Para poder corrigir esse tipo de problemas os gerentes do projeto estavam definindo outras dinmicas de interao para envolver mais a equipe de desenvolvimento no processo de produo das interfaces. GP1 A gente d pouco inputs pra ele (designer). O ideal seria participar antes, e tudo que fazer, prototipar (...) para que no final tenhamos um prottipo final de alta fidelidade, pra ficar bem claro, tanto pra ns (desenvolvimento) quanto para o designer, o que vai ter de funcionalidade, o que vai acontecer em determinada experincia do usurio. Isso acontecendo fica mais fcil tanto para a equipe de desenvolvimento, quanto para o designer,

Erton W. Vieira

79 e pra mim para pode gerenciar . Quando as duas coisas no esto alinhadas, as duas partes acabam entrando em conflitos.

Mas mesmo tentando adaptar o processo de design com a metodologia gil utilizada, ainda possvel identificar algumas dificuldades de como mesclar estas duas metodologias diante de eventos que ocorrem durante o desenvolvimento. LT3 At hoje a gente fica meio em dvida se o design d pra ser feito com Scrum. Porque, (...) muda muito. Tipo, ele est fazendo uma coisa e chega um requisito maluco e que no foi planejado. E ento como a gente faz? Deixa o requisito entrar? Ou coloca ele na prxima Sprint? A gente t fazendo meio que experimental e ver qual o que pega melhor. (...) Essa uma das dificuldades que mais sinto quando trabalhamos com design no Scrum.

Os inputs que o designer do REDU recebe para o desenvolvimento do sistema so providos pelos integrantes da equipe de desenvolvimento e pela equipe de pesquisa. Essa equipe de pesquisa formada por mestrandos e doutorandos que utilizam o REDU como objeto de pesquisa. GP1 Eles (mestrandos e doutorandos) tem reunies com o designer para repassar os dados que foram coletados (nas pesquisas). Esses dados so independentes dos dados coletados pelos prprios membros do REDU (...) Eles utilizam o projeto REDU como case e acabam dando um feedback para a gente.

Tanto esses inputs fornecidos pelos pesquisadores, como os valores definidos pela empresa, servem como guia para o desenvolvimento das interfaces do sistema. D1 Os valores eles so o nosso norte. Eles apontam pra onde ns devemos ir. As reas do conhecimento de design, como por exemplo, design da experincia do usurio, design da interao, arquitetura da informao, tudo isso converge para os valores que ns adotamos para o REDU. Talvez no
Erton W. Vieira

80 todos, mas a maioria dos valores ns podemos conquista-las respeitando os conceitos deste conhecimento j explorado. Minha metodologia de trabalho era bem por a.

Depois desta adaptao, os valores, e consequentemente a experincia do usurio, so testados na interface atravs de avaliaes das verses primrias desenvolvidos pelo designer em uma reunio conjunta com toda a equipe do REDU. GP1 - Normalmente, (o designer) faz uma primeira verso e ento temos uma reunio para dar um feedback, tanto pra visualizar (...) ter uma ideia do fluxo geral, se est claro ou no, e para avaliar os valores tambm. E se a gente perceber que existem elementos que deixam a coisa chata, a a gente fala que no pode ser desse jeito. Ou se est muito complicado, tem que fazer de uma forma mais simples. Ns tentamos sempre ter essas perspectiva tendo sempre como premissas da gente os valores. LT3 Quando ele mostra a tela, a gente tem a liberdade de dizer: Isso aqui no faz sentido. (...) A gente vai bombardeando, no papel do usurio no de desenvolvedor, j pra ver se supre um pouco a parte de no ter com frequncia testes de usabilidade.

Esta liberdade que o grupo do REDU tem em apontar caractersticas que no esto agradando ou que no esto seguindo os valores propostos pela empresa, deixa o ambiente de desenvolvimento mais homogneo. O designer obtm feedbacks com os quais pode trabalhar e os desenvolvedores se aproximam mais do trabalho do designer.

Com essa aproximao entre desenvolvedores e designers, as diversas vises de como deve ser a interface do sistema convergem em uma ideia central, facilitando o trabalho do designer. Essa converso de ideias d-se atravs de conversas entres os membros do REDU, e chegam a um denominador comum e todos os membros da equipe sabem para que direo o sistema est seguindo.
Erton W. Vieira

81

4.4.3.1 Revises e Melhorias na Interface

Devido natureza da metodologia escolhida para o desenvolvimento do REDU, as interfaces do sistema passam por revises peridicas devido a um dficit de testes com os usurios. Quando usurios comeam a interagir com o sistema eles identificam problemas que at ento os desenvolvedores no tinham percebido, Jacob Nielsen (2011) definiu que at 5 (cinco) usurios podem identificar at 90% das falhas no sistema. Por isso a importncia dos testes com usurios finais.

Mas a metodologia gil necessita que o trabalho seja realizado em um tempo limitado. Restringindo o trabalho do designer em pesquisar as necessidades do usurio e seus testes, a poucas oportunidades. Devido a isso, a equipe do REDU montou uma planilha com todos os pontos que devem ser revisados no sistema e as verses com essas melhorias. Estes pontos de revises so adicionados nesta planilha principalmente aps testes com usurios, porm como estes testes so espordicos, esses pontos de reviso da interface podem ser definidos pela equipe de desenvolvimento e/ou todos os participantes do projeto, tais como colaboradores e pesquisadores.

A inteno destas revises deixar a interface mais fcil de ser compreendida e utilizada. Minimizando a sensao de frustrao que os usurios podem sentir ao no saber como interagir com o sistema.

Estas planilhas so separas em Reviso da Interface e Verses de Melhoria.

Erton W. Vieira

82

Figura 4.1 Planilha de Reviso de Interface

Na figura 4.1 podemos ver a Planilha de Reviso de Interface que est dividida da seguinte forma: Categorias Em qual parte do sistema a reviso foi efetuada. Problemas Quais os problemas encontrados em determinada parte ou rea do sistema. Solues/Ideias O que os desenvolvedores sugerem para corrigir a falha apontada.

A planilha de reviso de interface torna-se importante para que os desenvolvedores e o design entendam o legado das verses anteriores, o que no tinha funcionado e o que foi realizado a respeito disso. Com esse conhecimento em mos a evoluo do sistema se torna bem clara, e erros ocorridos no passado no so repetidos.

Na planilha de Verses de Melhorias, o modo de pensar se inverte. Aqui so definidas algumas hipteses e s a ento levantado qual problema seria resolvido a partir desta ideia inicial e quais valores do REDU esto abordando com essa ideia:

Erton W. Vieira

83

Figura 4.2 Planilha de Verses de Melhoria

Hiptese/Ideia sugerida uma ideia de interveno no sistema. Geralmente relacionadas a interface e apresentao de dados. Qual problema pode resolver Com a ideia definida antes, os desenvolvedores apontam qual o problema que ir ser contemplada com a soluo. Valores E aqui so definidos quais valores da empresa a ideia est abordando.

Estas planilhas so uma das principais fontes de requisitos para o designer do REDU. Aqui esto definidas claramente cada problema da interface identificado por pessoas com vrios tipos e nveis de experincia com tecnologia. A partir destas ideias o designer, junto com os desenvolvedores, define qual problema ser abordado no decorrer de sua prxima Sprint.

Importante ressaltar que ideias de melhoria no processo de desenvolvimento tambm so compartilhadas aqui. Os membros responsveis pelo

desenvolvimento do REDU podem apontar solues para a melhoria no processo de construo do sistema. Tornando o processo de desenvolvimento do REDU mais eficaz.

Erton W. Vieira

84 Solues aqui apresentadas vo desde a melhoria da interao entre os membros que esto construindo a ferramenta REDU, como mais reunies com o designer durante a semana, a adio de conceitos novos para a ferramenta, como o gamification. A partir dessas solues apresentadas nessa planilha os membros da equipe estaro sempre em contato com as ideias que podem melhorar a dinmica da empresa e do sistema.

4.4.3.2 Planos de Release

O Scrum, metodologia de desenvolvimento gil adotada no REDU, tem como caracterstica principal o trabalho dividido em esforos curtos, durante o tempo de uma Sprint. Onde as metas para aquele perodo de tempo so definidas e a entrega tem que ocorrer no final de cada Sprint. O tempo de cada Sprint pode ser ajustvel realidade de cada equipe ou empresa que a est empregando.

O REDU adotou o tempo mdio de cada Sprint como sendo varivel de duas a trs semanas, de acordo com a complexidade do desenvolvimento. Ento a equipe montou um Plano de Releases para entrega de cada componente do sistema. Planos estes que estavam disponveis para todos os envolvidos na construo do sistema e evidenciava em qual caracterstica do sistema os desenvolvedores estavam trabalhando.

O que fica evidenciado nestes Planos de Release a mudana na dinmica do trabalho quando a figura do designer foi incorporada a equipe de desenvolvimento. Antes de o designer entrar na equipe de desenvolvimento, os releases de questes de design e de questes de codificao eram tratados da mesma forma. Questes mais tcnicas eram abordadas nas primeiras sprints, deixando de lado questes mais subjetivas como usabilidade e arquitetura da informao.

Aps a entrada do designer na equipe ocorreram mudanas na forma como eram abordadas as caractersticas que iriam ser trabalhadas nas Sprints.

Erton W. Vieira

85 Ocorreu um perodo de adaptao do designer a metodologia gil, que durou em torno de quatro meses, onde o designer trabalhava na interface de forma dissociada do grupo de desenvolvimento. Porm, a partir do momento em que o designer alcanou as sprints da equipe de desenvolvimento a forma de trabalho modificou. Fica evidenciado nos Planos de Release que o designer conseguia trabalhar caracterstica do ambiente pelo menos duas Sprints a frente da equipe de desenvolvimento. Permitindo que o designer pudesse realizar os estudos necessrios para a construo da interface ou correo da mesma. Estas sprints a frente de trabalho que o designer tem a forma ideal de trabalhar o design em uma metodologia gil de desenvolvimento de software, segundo Patton (2008).

Porm, a equipe sentiu uma necessidade de encontros mais frequentes para discutir as interfaces que estavam sendo construdas para o ambiente. Essa necessidade se deu por algumas vezes, em entregas de releases, o trabalho do designer ter ido de encontro ao que se estava desenvolvendo. A equipe observou que reunies do designer e da equipe do desenvolvimento ocorrer apenas no final de cada Sprint no eram suficientes. Devido a isso, a equipe definiu um dia da semana onde o designer apresentava seu progresso para a equipe de desenvolvimento e as ideias que ele pretenderia desenvolver no decorrer daquela Sprint, e ento a equipe de desenvolvimento poderia ter uma viso do que estava acontecendo no processo de construo da interface. Nessas reunies vrios aspectos da caracterstica que estava sendo trabalhada naquela Sprint eram discutidos e ento aprovados ou rejeitados ao final da reunio. Esta adaptao realizada pela equipe de desenvolvimento deu mais confiana no trabalho do designer, que captava feedbacks do seu trabalho com maior frequncia.

4.4.4 Testes com usurios

Os testes do REDU com usurios acontecem em um intervalo maior que o recomendvel. Devido ao status de pequena empresa e com poucos investimentos (caractersticas de um startup) tem que balancear os gastos com
Erton W. Vieira

86 testes. O fato de estar desenvolvendo o sistema com mtodos geis, que necessita de uma rapidez na codificao, influencia tambm na escolha da equipe do REDU em realizar teste com usurios s aps uma srie de sprints e funcionalidades desenvolvidas. GP1 Na verdade, a pesquisa com o usurio no acontece nesse ciclo menor (sprint). Acontece num ciclo que tem um perodo mais prolongado. Depois de vrias criaes que a gente vai chegar junto do usurio final. Algumas pessoas do feedback, mas em uma amostra mais ampla, no tem como a cada coisa que realizamos, ns termos esse feedback das pessoas. At porque uma limitao, tambm de recursos humanos da equipe e tempo. D1 O que falta mesmo tempo, pra gente entrar nesse balano de design. Ele ser projetado, ele ser validado, ser testado, ser viabilizado, pra depois ir para o pessoal de desenvolvimento.

O que acaba acontecendo que quem avalia as interfaces desenvolvidas durante a sprint do designer a prpria equipe do REDU. E ento, aps vrias funcionalidades desenvolvidas, que parte para uma avaliao com os usurios. LT2 O que acontece que ele (designer) desenvolve a interface na sua Sprint, e o mais rpido possvel j comea a codificao. A interface vai para o ambiente de produo e l ns temos uma srie de formas de recolher o feedback deste pessoal, o que j gera novos inputs para melhorar a interface daquela funcionalidade.

Os prprios integrantes do projeto reconhecem que o correto seria realizar com mais frequncia os testes juntos aos usurios para poder validar os requisitos e tambm, a partir destes mesmos testes, avaliar como est sendo percebida a experincia de cada usurio. GP1 O ideal seria a gente ter (os testes), antes mesmo na implementao, ter outros testes, outros questionrio, j validar estes quesitos.
Erton W. Vieira

87 Este seria o cenrio ideal, porm com a limitao dos nossos recursos, esse cenrio no possvel.

A forma de obter o feedback do usurio mais utilizado pela equipe do REDU atravs de questionrio aplicados nas escolas em que o sistema utilizado. Porm foi realizado testes com o usurio alvo na sede do REDU, onde os integrantes da equipe puderam participar e absorver os feedbacks de pessoas que no estavam diretamente ligadas ao projeto. D1 Foi excelente. A gente pode ver de perto o sistema sendo utilizado. (...) Eles vieram aqui e a gente gravou. Foi a primeira vez que eu, como designer do REDU, participei de um teste com os usurios alvo. E foi muito enriquecedor. A gente pegou e viu que olha, isso aqui no bem assim, no funciona desse jeito, no tava legal. Depois que o teste terminou, ns estvamos com um checklist imenso de correes e melhorias.

Os prprios integrantes do REDU admitem que as pesquisas no ocorrem com a frequncia ideal. Os testes com usurios so realizados em espaos de tempo maiores devido a vrios fatores que impactam nesta escolha, como: a metodologia de desenvolvimento escolhida para o REDU, que requer uma agilidade maior na construo do sistema, e a pouca quantidade de pessoas na equipe de desenvolvimento, o que faz com que os recursos humanos necessrios para estes testes so escassos na empresa.

4.5 Descrever a experincia do usurio do REDU.

Durante o perodo que se deu este estudo, ocorreram duas importantes pesquisas com usurios alvo do sistema REDU, onde a equipe da empresa pode constatar algumas caractersticas da experincia desses usurios mais detalhadamente. Estes estudos se deram no segundo trimestre do ano de 2011 e foram realizados na Escola do Recife, instituio pblica localizada nas

Erton W. Vieira

88 instalaes da FCAP - UPE, onde foram aferidos a experincia no uso tantos dos alunos como dos professores, e no Instituto Federal de Cincias e Tecnologia do Cear (IFCE) Campus Crato, onde a pesquisa foi focada apenas nas experincias dos docentes. As pesquisas realizadas no IFCE foram realizadas por Abreu (2011) e Claudeivan (2011), pesquisadores residentes no Cear que se disponibilizaram a realizar a pesquisa a fim de utilizarem como material para suas dissertaes de mestrado.

Estas entrevistas e observaes com os usurios foram trabalhadas com dois grupos distintos de usurios. Nas entrevistas realizadas da Escola do Recife, o pblico alvo do estudo foram jovens entre 15 e 17 anos, do ensino mdio, que j estavam em preparao para realizar o vestibular. Esses jovens tinham mais facilidade de relacionar-se com a tecnologia, particularmente, redes sociais. Nas entrevistas realizadas no IFCE Campus Crato, o pblico alvos foram os professores e alunos dos cursos da instituio. Os alunos participantes tinham entre 16 e 21 anos, sendo 58% procedentes da zona urbana e 42% procedentes da zona rural. Todos os alunos participantes utilizam pelo menos uma rede social. Por parte dos docentes, trs professores participaram das pesquisas da ferramenta. Ambos com uma experincia limitada com a tecnologia.

Esta pesquisa tornou-se importante para os membros da equipe devido a quantidade significativa de usurios que participaram dos testes e dos seus ricos resultados que corroboraram com algumas vises dos desenvolvedores e foram opostas a algumas outras questes definidas pela equipe do REDU.

Estes resultados mostram o ponto em que a experincia do usurio estava na data da coleta de dados. E podemos observar tambm como os valores definidos pela empresa estavam sendo trabalhados. As anlises realizadas para este objetivo especfico so relacionadas a ferramenta REDU.

As pesquisas realizadas no IFCE tiveram a funo de fornecer dados para dissertaes de mestrado e contribuir com requisitos para o REDU. Tais dados, junto com os dados coletados na pesquisa na Escola do Recife, fazem com
Erton W. Vieira

89 que o grupo de desenvolvedores e interessados no REDU tenha uma gama de informaes pertinentes para o contnuo aperfeioamento da ferramenta de aprendizagem. Para melhor compreenso dos dados, as percepes e experincias obtidas atravs das pesquisas realizadas sero separadas de acordo com os valores que eles se relacionam. Assim a anlise da experincia dos usurios no REDU estar dividida a seguir em Intuitivo, Fcil, Na Moda, Conveniente, Produtivo e Divertido.

4.5.1 Intuitivo Em pesquisa realizada na Escola do Recife, questionrios foram realizados com os alunos que utilizaram o REDU, vrias caractersticas de sua experincia no sistema foram abordadas. A seguir esto organizadas as respostas relacionadas a Utilidade do Layout, Sequncia de Telas, Prxima tela na sequncia, Voltando para prxima tela, Progresso do trabalho, Resultado previsvel na execuo da tarefa. Caractersticas que impactam na intuitividade do REDU, de acordo com as definies dos prprios

desenvolvedores.

Layout da tela foi til

Erton W. Vieira

90
Figura 4.2 Utilidade do Layout.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Nunca foi til,6 a 9 como Sempre foi til e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 24% dos participantes da pesquisa definiram o layout do sistema como Nunca foi til, 69% definiram como Sempre foi til e 7% para nenhuma das opes.

Sequncia de telas

Figura 4.3 Sequncia de telas.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Confusa,6 a 9 como Clara e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 17% dos participantes da pesquisa definiram a sequncia de telas do sistema como Confusa, 79% definiram como Clara e 4% para nenhuma das opes.

Prxima tela na sequncia

Erton W. Vieira

91

Figura 4.4 Prxima tela na sequncia.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Imprevisvel,6 a 9 como Previsvel e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 7% dos participantes da pesquisa definiram que na sequncia de telas do sistema a prxima tela da sequncia como Imprevisvel, 83% definiram como Previsvel e 10% para nenhuma das opes.

Voltando para a tela anterior

Erton W. Vieira

92
Figura 4.5 Voltando para a tela anterior

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Impossvel,6 a 9 como Fcil e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 97% dos participantes da pesquisa definiram que na sequncia de telas do sistema a volta para a tela anterior como Fcil e 3% para nenhuma das opes.

Progresso do trabalho

Figura 4.6 Progresso do trabalho.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Confusa,6 a 9 como Clara e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 7% dos participantes da pesquisa definiram que na sequncia de telas do sistema a progresso do trabalho como Confusa, 90% definiram como Clara e 3% para nenhuma das opes.

Execuo de tarefas leva a um resultado previsvel

Erton W. Vieira

93

Figura 4.7 Resultado previsvel na execuo das tarefas

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Nunca,6 a 9 como Sempre e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 18% dos participantes da pesquisa definiram que o resultado previsvel na execuo de tarefas no sistema Nunca acontece, 83% definiram como Sempre acontece e 3% para nenhuma das opes.

Alm dos questionrios com os alunos, entrevistas foram realizadas com professores e alunos a fim de coletar evidncias de como a interao com o sistema, e consequentemente, sua experincia ao utiliz-la. Algumas evidncias a cerca do ser intuitivo do REDU foram coletadas.

Os professores veem com bons olhos a utilizao do REDU como auxiliar em suas aulas. Principalmente pela aceitao dos prprios alunos, que esto continuamente conectados a internet, ao utilizar o sistema: PR3 Criando o hbito de os professores estarem postando o contedo, vdeos, puxando a ateno deles espetacular. A comunicao extra sala de aula. Antigamente no tinha isso (...) quando voc queria falar com o professor tinha que esperar at a outra aula, e a j mudou o contexto, j
Erton W. Vieira

94 no tinha o que falar. E o REDU vai proporcionar essa (...) aproximao dos alunos e professores.

Os professores do IFCE, alm de receber treinamentos na utilizao de ferramentas de TI em geral, receberam treinamentos especficos para a utilizao do REDU como ferramenta de apoio s suas aulas. Vrias aes eram completadas sem maiores esforos por parte dos professores. PR8 Criou a rede de Histria e Memria. Eu devia botar uma foto minha. Isso aqui foi o que eu coloquei l no outro. O nome escravido... Oh ele a. PR6 Ento assim: eu coloco vrias questes e coloco a resposta no final? , tenho que testar. Vamos l.

Contudo, em alguns aspectos da utilizao do REDU, ainda houve dificuldade no entendimento da ferramenta. PR8 Ai o que eu fao, vou em prxima? porque eu no me acostumei com esse negcio. Seria um editor de aula? PR6 Quer que eu digite uma nova questo? Onde que eu coloco uma nova questo aqui?.

O sistema mostrou-se intuitivo para os seus usurios. Com pouco tempo de uso os participantes dos testes conseguiram se familiarizar com o sistema, que no apresentou complexidades mais contundentes. A progresso das tarefas, tanto para alunos como para o professor, foi simples e bem avaliada no sistema. 4.5.2 Fcil Em pesquisa realizada na Escola do Recife, questionrios foram realizados com os alunos que utilizaram o REDU, vrias caractersticas de sua
Erton W. Vieira

95 experincia no sistema foram abordadas. A seguir esto organizadas as respostas relacionadas a Facilidade no Uso, Incio do Uso e Tempo de aprendizado. Caractersticas que impactam na facilidade de utilizar o REDU, de acordo com as definies dos prprios desenvolvedores. Difcil versus Fcil

Figura 4.8 Difcil x Fcil.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Difcil e de 6 a 9 como Fcil. Para este quesito, 17% dos participantes da pesquisa definiram o sistema como Difcil e 83% definiram como Fcil. Incio do uso

Erton W. Vieira

96

Figura 4.9 Incio do uso.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Difcil,6 a 9 como Fcil e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 38% dos participantes da pesquisa definiram o incio do uso do sistema como Difcil, 59% definiram como Fcil e 3% para nenhuma das opes. Tempo de aprendizado na utilizao do sistema

Figura 4.10 Tempo de aprendizado na utilizao.

Erton W. Vieira

97 A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Difcil,6 a 9 como Fcil e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 20% dos participantes da pesquisa definiram o tempo de aprendizado do sistema como Difcil, 77% definiram como Fcil e 3% para nenhuma das opes.

Alm dos questionrios com os alunos, entrevistas foram realizadas com professores e alunos a fim de coletar evidncias de como a interao com o sistema, e consequentemente, sua experincia ao utiliz-la. Algumas evidncias a cerca do ser fcil do REDU foram coletadas.

Os alunos e professores entrevistados afirmaram que a interface do REDU fcil de utilizar. AL1 fcil sim (de utilizar). No comeo eu tava treinando, mas agora j t tudo certo. O legal que o REDU tem a mesma formazinha do Orkut. AL4 Pra mim foi fcil. (O REDU) foi mostrado na aula e logo depois eu acessei sem problema nenhum. AL5 O primeiro contato foi bom. Foi simples de ser usado. No apresentou grandes dificuldades.

Os alunos sentiram-se familiarizados com a ferramenta por se tratar de uma rede social, e a forma de interagir dentro de uma rede social no novidade para os alunos pesquisados. Com a incorporao de caractersticas que tornam essa rede social um ambiente de aprendizagem, a interao tornou-se mais produtiva no que se detm ao compartilhamento de conhecimento. PR2 A interface simples, simples, simples. No vejo dificuldade no uso, mesmo para pessoas que no tem um conhecimento de informtica avanado (o REDU) muito simples.

Erton W. Vieira

98 A pesquisa realizada com os professores do IFCE demonstrou que um dos valores mais apreciado pelos docentes o Ser Fcil. Todo o processo de desenvolvimento do ambiente deve partir da simplicidade do uso. Tanto simplicidade na sua interface, como simplicidade nas interaes, simplicidade na utilizao dos recursos do sistema. Sempre em vista que o usurio do sistema, principalmente os docentes, tem uma variao ampla de

personalidades, faixas etrias entre outras caractersticas.

4.5.3 Na Moda Em pesquisa realizada na Escola do Recife, questionrios foram realizados com os alunos que utilizaram o REDU, vrias caractersticas de sua experincia no sistema foram abordadas. A seguir esto organizadas as respostas relacionadas a Terrvel versus Admirvel. Caractersticas que impactam no Estar na moda do REDU, de acordo com as definies dos prprios desenvolvedores. Terrvel versus Admirvel

Figura 4.11 Terrvel x Admirvel.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Terrvel e de 6 a 9 como Admirvel. Para este quesito, 21% dos participantes da

Erton W. Vieira

99 pesquisa definiram o sistema como Terrvel e 79% definiram como Admirvel.

Alm dos questionrios com os alunos, entrevistas foram realizadas com professores e alunos a fim de coletar evidncias de como a interao com o sistema, e consequentemente, sua experincia ao utiliz-la. Algumas evidncias a cerca do estar na moda do REDU foram coletadas.

A periodicidade do acesso ao REDU variava de acordo com as tarefas que eram, ou no, disponibilizadas no ambiente. AL1 Depende, eu acessava toda noite, mas eu reparei que os professores no postaram mais. (...) A passei a acessar s quando eles (professores) tinham postado mais alguma coisa.

Mesmo utilizando o REDU a um tempo, eles no esto acostumados a utilizar o REDU. AL2 Eu ainda estou me acostumando a entrar no REDU. (...) Eu vou para a internet ver outras coisas e ento eu falo eita, no entrei no REDU a vou l e entro. Ainda no estou acostumada, mas ainda entro.

Os alunos, quando acessam o REDU, procuram primeiro confirmar se algum material foi acrescentado na sala da turma no sistema. Eles no ficam mais tempo no sistema, pois alegam que no esto acostumados ainda com o ambiente REDU como elas esto acostumadas com outras redes sociais. Outra alegao para o no uso constante do REDU a falta de pessoas com quem interagir no ambiente. Pois na poca do estudo, os alunos apenas interagiam com os seus colegas de sala e seus professores.

Mesmo com essas dificuldades os professores veem com bons olhos a utilizao do REDU como auxiliar em suas aulas. Principalmente pela

Erton W. Vieira

100 aceitao dos prprios alunos, que esto continuamente conectados a internet, ao utilizar o sistema. PR1 Essa aprendizagem em espao virtual uma coisa que os alunos gostam muito e (o REDU) vai decolar! Aqui, eu pretendo usar com certeza.

4.5.4 Conveniente Em pesquisa realizada na Escola do Recife, questionrios foram realizados com os alunos que utilizaram o REDU, vrias caractersticas de sua experincia no sistema foram abordadas. A seguir esto organizadas as respostas relacionadas a Inadequado versus Adequado. Caractersticas que impactam no ser conveniente do REDU, de acordo com as definies dos prprios desenvolvedores. Inadequado versus Adequado

Figura 4.12 Inadequado x Adequado.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Inadequada e de 6 a 9 como Adequada. Para este quesito, 10% dos

Erton W. Vieira

101 participantes da pesquisa definiram o sistema como Inadequada e 90% definiram como Adequada. . Alm dos questionrios com os alunos, entrevistas foram realizadas com professores e alunos a fim de coletar evidncias de como a interao com o sistema, e consequentemente, sua experincia ao utiliz-la. Algumas evidncias a cerca do ser conveniente do REDU foram coletadas.

Os alunos, preferencialmente, utilizavam a internet da prpria casa para acessarem o REDU. Algumas poucas vezes utilizavam a rede da escola ou o celular. O horrio de maior acesso entre os entrevistados foi no perodo da noite.

Estes alunos entrevistados afirmaram que ficam em mdia 30 minutos no ambiente REDU. Porm, dependendo do material disponibilizado para atividades dentro do ambiente, esse tempo pode aumentar. E os tamanhos dos materiais tambm influenciam na continuidade do aluno dentro do ambiente. AL3 Por exemplo, quando um vdeo dividido em trs partes de 15 minutos. Eu no vou ficar 45 minutos assistindo um vdeo, a eu digo no, o vdeo muito grande. Da no fao (a atividade). No assisto.

Estudos realizados por pesquisadores (Abreu, 2011 e Claudeivan, 2011) sobre a interao que ocorre entre os usurios do REDU apontam que a interao mais eficiente dentro do sistema do que na sala de aula. Apesar de alguns alunos entrevistados afirmarem que esta interao deve crescer e ficar melhor assim que o REDU estiver com mais usurios. Essa melhor qualidade na interao creditada a forma livre que o usurio tem em buscar conhecimento dentro do sistema. Alguns entrevistados levantam a hiptese que a falta de inibio para a interao no sistema pode ser de boa para qualidade da interao. AL1 s vezes a gente est em casa, e tem uma dvida e est sem comunicao. No tinha como a gente chegar num colega e dizer faz isso ou
Erton W. Vieira

102 no livro no tinha essa pgina indicando (a resposta). Ento, voc vai l no REDU e pergunta alguma coisa e de repente tem algum online e te responde na hora. A fica, tipo, um grupo de estudo online. AL3 A primeira coisa que a gente faz quando entra no REDU ver se tem algum online. Depois vou ver se tem alguma coisa que a galera fez, o que eles comentaram, o que tem de novo.

As interaes acontecem no momento em que o aluno entra no sistema. E assim ele j procura outro colega para compartilhar alguma informao ou tirar qualquer dvida. AL5 uma forma de interao, ou seja, ns temos uma extenso do colgio em casa. A gente pode tirar dvidas, falar com os colegas. Se tem uma pessoa que entende mais do assunto voc pode perguntar a ele, sem precisar esperar o professor pra perguntar na sala de aula. Foi o que eu achei mais interessante. AL8 (...) Quando o professor t dando uma aula em sala de aula, a tem um aluno que quer tirar uma dvida com o professor. (...) S que tem outro aluno que sabe tirar essa dvida, explicando de um jeito melhor de entender que o professor, s que fica impedido dede esclarecer mais para o colega ali. No REDU no. Tanto que quando ele (aluno) postava uma pergunta l (no sistema) quando um aluno sabia ia l diretamente (responder).

Com a utilizao da ferramenta os alunos se sentiam mais confiantes em tirar dvidas com o professor ou com outros alunos, AL7 A interao no REDU foi melhor por que a gente tinha mais acesso ao professor e colegas. E tambm pra fazer perguntas pra eles e pra o professor tambm. AL6 uma forma de a gente no se limitar s no colgio. s vezes a gente fica com vergonha de falar na sala pra todo mundo ouvir. L voc fica
Erton W. Vieira

103 mais reservado com o professor ou at mesmo com as pessoas que voc tem mais afinidade. A voc consegue quebra alguns problemas.

Apesar de alguns alunos sentirem que essa interao no funciona como deveria. AL4 Essa parte de tirar dvidas com os colegas (...) no t acontecendo. s vezes eu no tenho entrosamento com ningum, ou eu tenho que deixar mensagens pra ver se tem algum online e eu no posso ficar muito tempo na internet (...). Eu entro mais no REDU quando eu tento achar algum online para tirar alguma dvida. Mas nunca sei se algum t online. A outra pessoa tem que responder minha mensagem, se ela no responder, no vou saber se (a pessoa) est online.

Alguns alunos entrevistados alegam que mais conveniente tirar as dvidas com o professor em sala de aula do que no ambiente da turma no REDU. Pois algumas vezes os professores demoram a acessar o sistema e no respondem as dvidas na velocidade que os alunos desejam. J na sala de aula, a resposta instantnea e o professor pode utilizar de artifcios como o quadro negro e do prprio livro para auxili-lo a tirar a dvida dos alunos. AL3 Alguns professores no ficam entrando frequentemente (no REDU). Ento eu acho mais rpido tirar a dvida na sala de aula.

Os professores veem a utilizao de sistemas que apoiem o ensino como muito positivo. Qualquer que seja ele. PR5 Na realidade, eu acho que todo professor tem a obrigao de saber lidar com a internet. Porque se voc no souber lidar com isso (internet) voc fica de fora do que est acontecendo, sobretudo quem trabalha com jovens. Por exemplo, (...)a literatura muito atrelada a outras linguagens como cinema, teatro, msica. Eu no consigo ver a literatura via livro, ento eu tenho que ir por outros caminhos.

Erton W. Vieira

104 Contudo, enxergam algumas limitaes da parte dos prprios professores, como, por exemplo, a falta de tempo para acessar esses ambientes. PR1 Eu vejo como sendo muito positivo isso (utilizao de AVAs). Agora existem dificuldades do professor. O aluno no. Vejo que eles tm bastante disponibilidade de horrio pra entrar, pra pesquisar, pra estudar. Mas a minha preocupao o lado do professor, (...). PR2 O professor pra ganhar um salrio bom ele tem que trabalhar duas, trs vezes mais do que qualquer outra pessoa ganharia. Diminuindo o tempo pra ele acessar a internet. Ele acessaria quando? Final de semana? Mas o final de semana ele usa pra corrigir trabalhos, provas. Isso limita a ele o acesso a esses ambiente(...). A vida corrida do professor atrapalha muito.

Alguns professores alegaram que a falta de tempo dos profissionais de ensino podem dificultar a utilizao da ferramenta REDU por eles. A grande carga de trabalho do docente limita o tempo que ele tem para a utilizao da rede social, impedindo, muitas vezes que eles possam interagir e tirar as dvidas dos colegas.

4.5.5 Produtivo Em pesquisa realizada na Escola do Recife, questionrios foram realizados com os alunos que utilizaram o REDU, vrias caractersticas de sua experincia no sistema foram abordadas. A seguir esto organizadas as respostas relacionadas a Quantidade de informaes na tela, Distribuio das informaes na tela, Terminologias relacionadas ao trabalho. Caractersticas que impactam no ser conveniente do REDU, de acordo com as definies dos prprios desenvolvedores. Quantidade de informaes na tela

Erton W. Vieira

105

Figura 4.13 Quantidade de informaes na tela.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Inadequada,6 a 9 como Adequada e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 7% dos participantes da pesquisa definiram a quantidade de informaes na tela do sistema como Inadequada, 86% definiram como Adequada e 7% para nenhuma das opes.

Distribuio das informaes espalhadas na tela

Figura 4.14 Distribuio da informao na tela.

Erton W. Vieira

106

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Ilgica,6 a 9 como Lgica e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 3% dos participantes da pesquisa definiram a distribuio das informaes na tela do sistema como Ilgica, 90% definiram como Lgica e 7% para nenhuma das opes.

Terminologias relacionadas ao trabalho.

Figura 4.15 Terminologia relacionada ao trabalho.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Inconsistente,6 a 9 como Consistente e N/A para marcaes em Nenhuma das Alternativas. Para este quesito, 14% dos participantes da pesquisa definiram que terminologias relacionadas ao trabalho no sistema como Inconsistente, 83% definiram como Consistente e 3% para nenhuma das opes.

Alm dos questionrios com os alunos, entrevistas foram realizadas com professores e alunos a fim de coletar evidncias de como a interao com o sistema, e consequentemente, sua experincia ao utiliz-la. Algumas evidncias a cerca do ser produtivo do REDU foram coletadas.

Erton W. Vieira

107 AL3 A primeira coisa que a gente faz quando entra no REDU ver se tem algum online. Depois vou ver se tem alguma coisa que a galera fez, o que eles comentaram, o que tem de novo.

Porm alguns pontos de dificuldade na interao foram observados pelos pesquisadores. Um dos mais significativos a no possibilidade de saber quem est online. AL8 (Seria bom) Se l a gente pudesse saber que uma pessoa tava online pra gente discutir um assunto que a pessoa tem dvida ou queira discutir sobre alguma disciplina que temos na rede. (...) A pessoa ia postando as perguntas e pessoa ia respondendo quem estivesse online. E se no estivesse online, j iria conversar com outra pessoa, discutindo os assuntos da disciplina. Assim ficava quase que a pessoa em frente da outra (...) tirando dvidas.

Outro ponto levantado foi a limitao do nmero de caracteres disponveis para os textos. Que podem cercear o aluno no momento em que est tentando formular uma questo para os seus contatos ou at mesmo quando ele est tentando tirar uma dvida de algum colega. AL4 Outra coisa, o nmero de caracteres. Algum pergunta alguma coisa, a voc vai respondendo e vai digitando, digitando. Quando voc percebe, j atingiu o nmero de caracteres. E voc no conseguiu responder aquela pergunta do jeito que voc queria. AL9 Voc digitava um assunto e tinha que parar porque no tinha como digitar mais. AL8 (...) todo mundo sentiu uma dificuldade foi o total de caracteres que tem, o tanto que voc pode escrever nele, que sempre que voc quer digitar em grande quantidade e no d certo. (...) Sempre tem que t escrevendo de mensagem em mensagem.

Porm algumas reclamaes sobre a interface aconteceram.

Erton W. Vieira

108

AL3 Uma coisa complicada quando quero me comunicar. Quando voc quer mandar uma mensagem, eu nunca sei se a mensagem vai chegar pra essa pessoa ou se vai aparecer naquela pgina. E eu no consegui perceber quando uma mensagem privada ou quando ela pode ser vista por todo mundo.

Este problema apontado na interface pode comprometer uma interao de qualidade no sistema. Pois sem um retorno do sistema se as mensagens enviadas chegaram ao seu destino o sistema perde em confiabilidade. Podendo acarretar que o aluno procure outros meios de enviar a mensagem para o seu colega, enfraquecendo assim a interao dentro do sistema.

Por outro lado, os professores veem a utilizao de sistemas que apoiem o ensino como muito positivo. Qualquer que seja ele. PR2 uma ferramenta extremamente vlida, extremamente importante, que tem uma relevncia muito grande para o ensino no s da minha disciplina, matemtica, como de outras disciplinas como portugus, histria, que pode postar textos e vdeos, geografia que voc pode postar mapas. Coisas que na sala de aula fica invivel, pois temos aquele tempo limitado. Por isso, muitas vezes no podemos utilizar vdeos ou uma multimdia mais elaborada pelo tempo reduzido que ns temos em sala de aula.

Um dos aspectos bem recebidos do sistema como ele aproxima o aluno do professor. O REDU utiliza os conceitos de redes sociais para aproximar os usurios, facilitando assim a formao de conhecimento compartilhado. PR2 O que alguns alunos ainda no entenderam sobre o REDU que ali uma ponte entre ele e o professor. Ele no precisa saber o e-mail do professor e mandar o e-mail pra fazer uma pergunta, questionar sobre qualquer coisa, qualquer dvida. Ele tem l (no REDU) todos os professores de todas as disciplinas, ento se ele tiver alguma dvida sobre um assunto, pode postar essa dvida que o professor vai responder (...). Eles (os alunos) tm de
Erton W. Vieira

109 perceber que o REDU no s o professor que pode postar. O aluno pode muito bem chegar para o professor e pedir: professor, voc pode postar alguma coisas sobre determinado tema? . O REDU aquela janelinha mgica pra eles, o que eles quiserem eles podem ter ali.

Alm de aproximar aluno e professor, o REDU possibilita que os usurios utilizem vrios tipos de mdia para conseguir repassar um conhecimento para os seus pares. PR3 Criando o hbito de os professores estarem postando o contedo, vdeos, puxando a ateno deles espetacular. A comunicao extra sala de aula. Antigamente no tinha isso (...) quando voc queria falar com o professor tinha que esperar at a outra aula, e a j mudou o contexto, j no tinha o que falar. E o REDU vai proporcionar essa (...) aproximao dos alunos e professores. PR4 Eles fazem perguntas e eu tenho a necessidade de responder (...). Hoje eu acesso mais a internet pra ver se tem alguma pergunta, no devido a outras necessidades, mas mais por conta disso (perguntas). E cada vez que eu entro eu percebo que tem uma pergunta a mais pra responder. Ento acho que isso facilitou e aproximou tambm. E a medida que houve essa aproximao eu percebi que o aprendizado ficou mais slido.

A compreenso do professor como algum que est no mesmo patamar que os alunos, ajudou na livre interao entre as partes dentro do sistema. Fazendo-os sentir em um verdadeiro grupo de estudos, em que o professor estava l para auxili-los no processo de aprendizagem, assumindo o papel de facilitador neste processo. AL7 Se voc precisar tirar uma dvida com o professor o contedo j t l. Se voc precisa estudar, voc j t com o contedo l. Voc pesquisa, pergunta ao professor ou tira a dvida at com o colega mesmo.

Erton W. Vieira

110 AL5 L havia uma troca de ideias assim entre os alunos e professores e at mesmo pessoas que no faziam parte da escola. (...) Havia aquele intercmbio entre as pessoas, tirando dvidas, perguntando. Era muito interessante isso a.

Outra caracterstica importante observada pelos professores que como eles prprios esto l fornecendo material para os alunos, esses alunos podem confiar que tais materiais so confiveis. Diferente de, se eles mesmos forem pesquisar na internet e se deparar com sites que podem conter informaes errneas. Esses materiais disponibilizados pelos professores podem ser de vrias naturezas, como: vdeo, textos, sites especializados, material multimdia entre outros. PR5 O REDU, apesar de ter uma interface mais simples, tem informaes que a gente pode colocar l, como pastas de word, pdf. Eu posso colocar vdeos, posso colocar links para que alunos possam acessar, possam procurar na internet. um ambiente propcio para que os alunos possam desenvolver suas habilidades na internet. PR4 Postar uma lista de exerccios ou uma lista de teorias. Aquele material vai ser postado por um profissional que tem a instruo necessria para informar onde o aluno deve fazer a pesquisa corretamente. .

4.5.6 Divertido Em pesquisa realizada na Escola do Recife, questionrios foram realizados com os alunos que utilizaram o REDU, vrias caractersticas de sua experincia no sistema foram abordadas. A seguir esto organizadas as respostas relacionadas a Frustrante versus Satisfatrio, Tedioso versus Estimulante. Caractersticas que impactam no ser divertido do REDU, de acordo com as definies dos prprios desenvolvedores.

Erton W. Vieira

111 Frustrante versus Satisfatrio

Figura 4.16 Frustrante x Satisfatrio.

A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Frustrante e de 6 a 9 como Satisfatrio. Para este quesito, 21% dos participantes da pesquisa definiram o sistema como Frustrante e 79% definiram como Satisfatrio.

Tedioso versus Estimulante

Figura 4.17 Tedioso x Estimulante.

Erton W. Vieira

112 A escala utilizada para a avaliao desse quesito foi: de 1 a 5 como Tedioso e de 6 a 9 como Estimulante. Para este quesito, 42% dos participantes da pesquisa definiram o sistema como Tedioso e 58% definiram como Estimulante.

Alm dos questionrios com os alunos, entrevistas foram realizadas com professores e alunos a fim de coletar evidncias de como a interao com o sistema, e consequentemente, sua experincia ao utiliz-la. Algumas evidncias a cerca do ser divertido do REDU foram coletadas.

Os alunos entrevistados afirmaram que ficam em mdia 30 minutos no ambiente REDU. Porm, dependendo do material disponibilizado para atividades dentro do ambiente, esse tempo pode aumentar. E o tamanho dos materiais tambm influenciam na continuidade do aluno dentro do ambiente. AL3 Por exemplo, quando um vdeo dividido em trs partes de 15 minutos. Eu no vou ficar 45 minutos assistindo um vdeo, a eu digo no, o vdeo muito grande. Da no fao (a atividade). No assisto.

Um ponto importante levantado pelos professores impacta diretamente nos em um dos valores do REDU. Alguns professores relataram que, com frequncia, os alunos se distraiam com o computador e dispersavam sua ateno. PR6 Vocs esto entretidos no computador que no querem nem raciocinar no que eu estou falando. PR7 Eu t regulando pra vocs no ficarem atentos em outra coisa. Seno vo dispersar.

Tais

relatos

demonstra

que

em

vrios

momentos

REDU

ficou

desinteressante. Tanto que eles iam procurar distrao em outros ambientes que no o REDU. O sistema, em alguns momentos, no divertido o suficiente para prender o foco dos alunos na tarefa que esto executando.

Erton W. Vieira

113

4.6 Encontrar pontos em comum entre as variveis que descrevem o processo tcito adotado pela empresa e o design da experincia.

Para auxiliar a relacionar o processo de desenvolvimento que o REDU utiliza, levando sempre em conta os valores propostos pela empresa, e o processo de design da experincia, critrios que avaliam caractersticas da experincia foram definidos.

Os critrios para uma experincia de qualidade definida por Alben (1996) e o CUE Model apresentados por Mahlke e Thring (2007) sero abordados para classificar a relao dos conceitos.

4.6.1 Critrios de Qualidade da Experincia segundo Alben (1996)

4.6.1.1 Compreenso do Usurio

A compreenso das necessidades do usurio foi se formando com o passar do tempo. No incio do processo de desenvolvimento do REDU, os requisitos eram definidos por estudos realizados em reas como Design da Interface, Interao Homem- Computador e Arquitetura da Informao. Mas pouco eram os requisitos levantados diretamente com os usurios alvo do sistema.

Porm, como a metodologia de desenvolvimento selecionada para construir o sistema era um mtodo gil, a equipe no se preocupou de incio em fazer uma pesquisa extensiva com esses usurios alvo. Levando em considerao as necessidades que a prpria equipe tinha definido, uma verso do REDU foi sendo construda e durante muito tempo apenas os desenvolvedores e alguns poucos convidados testavam o sistema. Como alguns desenvolvedores afirmaram, eles levavam em considerao os valores da empresa no momento
Erton W. Vieira

114 de avaliar os prottipos construdos. Contudo, ainda necessitavam de uma pesquisa mais significativa com os usurios alvo, para compreender melhor suas necessidades.

E essa pesquisa foi realizada quase 1 (um) ano e meio depois de iniciado o projeto. Boa parte do sistema j estava construda. Devido utilizao de estudos prvios em reas especficas do design a aceitao do sistema foi alta. Mas, apesar dessa alta aceitao algumas necessidades dos usurios alvo, antes no identificadas pelos desenvolvedores, foram reveladas durante essa pesquisa. Eram questes simples, mas que impactavam diretamente na experincia do usurio no sistema. Algumas dessas dificuldades eram to significativas que limitavam a interao dentro do sistema, como foi o caso da no identificao de quem estava online no sistema.

Depois de realizada uma srie de pesquisa com os usurios do REDU, foi levantada uma quantidade enorme de requisitos que o sistema teria que melhorar para se tornar um eficiente ambiente de aprendizagem. Alguns desses requisitos so apresentados abaixo:

[REQ_01] Durante o processo de participao numa sesso de interao o aluno deve ser informado sobre outros alunos que estejam presentes na mesma.

[REQ_03] O usurio no necessita preocupar-se com o tamanho da rea de digitao de mensagens. Esta deve adaptar-se automaticamente ao tamanho do texto.

[REQ_04] Durante o processo de participao em uma sesso de interao o aluno deve ter como representar smbolos matemticos.

[REQ_05] O sistema deve oferecer uma opo para sincronizar a aula por meio de uma ferramenta de apresentao de slides.

Erton W. Vieira

115 [REQ_07] O docente deve ter acesso a uma ferramenta de busca de aulas editadas.

[REQ_09] O sistema deve oferecer para os usurios opes de formatao de textos.

Estes requisitos foram utilizados como referncias para aprimorar o sistema nas prximas verses do mesmo. Conhecer as necessidades do usurio importante para um sistema ser eficiente. E um sistema que est em constante evoluo, como o REDU, tem que conhecer muito bem o seu pblico. Todas as suas necessidades e anseios para que se torne uma marca forte e confivel no mercado.

4.6.1.2 Processo de Design Eficaz O processo de design foi evoluindo com o passar do tempo. No inicio do desenvolvimento desenvolvedores do sem REDU o design em do sistema era em definido sua por

experincia

interfaces,

maioria

programadores. E como os prprios integrantes do REDU explicaram o design era realizado mais em base do sentimento de cada um sobre como deveria ser a interface do que em conceitos especficos de projeto de interface, como usabilidade, acessibilidade ou arquitetura da informao. Apesar de disporem de um consultor que pesquisador na rea de Interface Homem-Computador, e a maioria ter cursado uma disciplina de Interao, a experincia do usurio era suprimido.

A escolha de utilizar o Scrum como metodologia de desenvolvimento tambm corroborou para uma dificuldade extra em trabalhar com a experincia. Pois o tempo para uma pesquisa prvia sobre a interface foi cortado, e testes com usurios eram raros.

O processo de design comeou a tomar forma quando os valores da produto foram definidos e percebeu-se que boa parte da percepo desses valores se daria na experincia do usurio com o sistema. A importncia de participantes
Erton W. Vieira

116 da equipe REDU pensando em como seria essa experincia do usurio se tornou essencial. Com a adio da figura do designer na equipe de desenvolvimento, a configurao de quem iria desenvolver a experincia ficou claro. Apesar da dificuldade inicial do designer acompanhar o ritmo da equipe de desenvolvimento, o processo de design ficou bem definido e eficaz. Algumas adaptaes foram ocorrendo durante o tempo para aperfeioar este processo.

O processo de design se d da seguinte forma:

O design trabalhar caractersticas do sistema duas Sprints a frente da equipe de desenvolvimento, com isso ele tem tempo para pesquisas e estudos mais elaborados para resolver os problemas daquela caracterstica especfica.

Como cada Sprint no REDU tem entre duas a trs semanas uma adaptao na metodologia foi aplicada. Toda semana uma reunio entre designer e equipe de desenvolvimento acontece para discutir os caminhos que o designer pretende seguir com aquela caracterstica. Esta adaptao metodolgica permitiu que os desenvolvedores se familiarizassem mais cedo com o projeto que estava sendo construdo pelo designer e tambm permitiu que os desenvolvedores tivessem a oportunidade de discutir algumas caractersticas que no estavam bem resolvidas no projeto apresentado, poupando um retrabalho do designer mais a frente.

Com isso essas caractersticas trabalhadas pelo designer eram ento construdas pela equipe de desenvolvedores, e o designer ficaria a disposio para auxiliar a equipe enquanto estavam construindo aquela caracterstica. Mas, enquanto o designer estava disposio para auxiliar o desenvolvimento, ao mesmo tempo j estava trabalhando em outras caractersticas do sistema que seriam produzidas em Sprints posteriores.

Dessa forma a comunicao entre designer e equipe era constante e evitava surpresas quanto entrega nas finais da Sprint, tornando o processo de design

Erton W. Vieira

117 bem eficaz, tendo em vista em toda reunio eram avaliados se os valores da empresa estavam sendo respeitados na interface projetada. O nico porm se refere as pesquisas com os usurios que foi discutida no item anterior.

4.6.1.3 Necessidades que o produto satisfaz

A funo do REDU, de acordo com seus desenvolvedores, facilitar e deixar mais dinmico o acesso das pessoas ao conhecimento. O dinamismo alcanado quando o sistema usa todos os conceitos de redes sociais. Por as redes sociais estarem na moda uma grande parcela das pessoas esto em contato com este conceito, principalmente os jovens.

Relatos de professores afirmam que a ferramenta ajuda a aproximar mais os alunos dos professores e do conhecimento que eles tm a oferecer. Esta interao entre alunos e professores, a construo do conhecimento em conjunto, transformar esse ambiente em uma extenso de uma sala de aula mais dinmica e integrada, esses so os pontos que o REDU trabalha para alcanar, com os resultados obtidos nas pesquisas realizadas, est alcanando com exmio xito.

Vrias outras caractersticas ainda esto sendo trabalhadas pela equipe de REDU. Principalmente aquelas relacionadas com valores mais complexos de serem trabalhados como o valor diverso e estar na moda.

4.6.1.4 Pode ser compreendida e utilizada

O sistema mostrou-se fcil de ser utilizado quando o usurio j tinha experincia com tecnologia e com o conceito de redes sociais. Porm, para

Erton W. Vieira

118 usurios com pouco contato com tecnologia o desafio de utilizao do REDU foi maior.

Os alunos, em sua maioria jovens, tiveram uma familiaridade com o REDU por este se apoiar nos conceitos de redes sociais. Por se tratar de um sistema que eles estavam usando a primeira vez, alguns tiveram uma dificuldade no incio da interao com o sistema. Porm, a velocidade de aprendizado da utilizao do sistema foi bem vista pelos usurios mais jovens. Com algumas horas de utilizao do sistema, os alunos j estavam acostumados e familiarizados com os aspectos do REDU.

Contudo, com os professores houve variao na compreenso do sistema. Os nveis de habilidades e experincia com a tecnologia influenciaram nesta compreenso. Professores mais acostumados com o uso da tecnologia se sentiram mais a vontade com o sistema e avaliaram o REDU como uma ferramenta fcil de utilizar e de interagir com os alunos. Porm, professores com o nvel de experincia com tecnologia baixo, sentiram dificuldades em entender o funcionamento do sistema e a dinmica que o sistema aplica entre professores, alunos e a formao do conhecimento.

A dificuldade na compreenso e utilizao do REDU ligada diretamente a dificuldade de compreenso e utilizao da tecnologia em si. Os usurios acostumados ao cotidiano tecnolgico atual no sentiram dificuldades na utilizao do REDU.

4.6.1.5 Apropriado

Um dos valores que o REDU prima ser conveniente. Em pesquisas realizadas com usurios do sistema, quesitos relacionados a esse valor foram avaliados como positivos. Ele se torna apropriado por usar um meio muito utilizado atualmente. A tecnologia est impregnada na sociedade e esta sendo utilizada a favor do conhecimento. E tanto professores como alunos defendem

Erton W. Vieira

119 que utilizar a tecnologia de forma eficiente pode aproxim-los de uma construo de conhecimento mais ampla e concreta.

4.6.1.6 Experincia esttica

O visual do REDU uma das caractersticas que sofreu maior impacto com a chegada da figura do design na equipe de desenvolvimento do REDU. No incio do projeto as telas eram projetadas pelos desenvolvedores, que no tinham experincia para projetar interfaces coesas, com arquiteturas de informao melhor trabalhada. O bom senso dos primeiros desenvolvedores foi o norteador das primeiras interfaces do sistema.

Figura 4.18 Verso antiga do REDU.

Erton W. Vieira

120

Devido a isso, quando o designer foi adicionado equipe, ele teve que refazer grande maioria das telas do sistema. Agora sim, respeitando conceitos de design de interao, usabilidade, alm de regras e definies de estudos na rea do design de interface. No incio do trabalho de remodelagem das telas o designer sentiu dificuldade em se acostumar com a metodologia de trabalho o que deixou mais complexo o trabalho de projetar. Porm, o processo de design foi logo absorvido por todos os envolvidos e assim, o trabalho tornou-se mais eficaz.

A confirmao da excelncia na experincia esttica veio nas pesquisas realizadas com os usurios, onde a maioria dos entrevistados afirmou que o REDU era admirvel e adequado em sua interface.

Figura 4.19 REDU mnimo (atual).

Apesar de ter sido avaliado como admirvel a interface do REDU, ela continua em evoluo para tornar a experincia esttica o mais agradvel possvel. Para isso os desenvolvedores levam em considerao os resultados das pesquisas com os usurios e estudos realizados em campos do design experiencial e de

Erton W. Vieira

121 interface. Este preocupao com a experincia esttica importante, pois uma interface bem projetada pode cativar o usurio rapidamente e fazer com que ele passe mais tempo navegando e conhecendo o sistema. Trabalhar com a experincia esttica trabalhar com o emocional do usurio, provocando a curiosidade sobre o sistema e fazendo com que ele, o usurio, procure por mais opes que o sistema oferece.

4.6.1.7 Mutvel

O REDU est em contnua evoluo. Tanto na sua interface como em seus componentes tcnicos. Com o auxlio das pesquisas que foram realizadas com os usurios e com os estudos feitos por pesquisadores que usaram o REDU como base, o sistema vem sofrendo grande evoluo no projeto de sua experincia.

As pesquisas realizadas com diversos tipos de usurio do sistema ajudaram a ter uma compreenso das necessidades destes usurios e o REDU foi se adaptando a essas necessidades de cada grupo de indivduos. E a interface do sistema trabalhada de uma forma que possa evoluir de acordo com as necessidades que ainda possam surgir.

A prpria metodologia de desenvolvimento gil prima por essa constante evoluo do software que est sendo construdo. Se uma caracterstica no foi bem avaliada pelos usurios, ela volta para ser retrabalhada em Sprints posteriores.

4.6.1.8 Manejvel

O REDU tem pessoas que cuidam da comunicao com o usurio. Dois integrantes cuidam da parte do negcio com as instituies que queiram utilizar

Erton W. Vieira

122 o REDU como ferramenta de auxlio ao ensino. Dando total suporte a questes legais e tcnicas para o incio da utilizao do sistema.

Um parceiro do REDU fica a cargo de treinamentos para os profissionais que vo utilizar o sistema e necessitam de um tempo de aprendizado do sistema. Acelerando a utilizao de todos os recursos disponibilizados pelo REDU.

E ainda o REDU oferece um canal direto de contato para questes mais tcnicas. Um email divulgado e quando um usurio sente uma dificuldade em completar determinada ao ou encontra um erro no sistema, ela pode entrar em contato com a equipe de desenvolvimento e a sua dvida ser estudada e respondida o mais rpido possvel.

4.6.2 CUE Model

Foram utilizados os dados obtidos previamente nas pesquisas com usurios, entrevistas e anlises de documentos fornecidos pela equipe do REDU. Com esses dados em mos, eles foram classificados para cada um dos componentes do CUE Model. Abaixo esto as concluses sobre: .

4.6.2.1 Qualidade Instrumental

O sistema REDU foi definido pelos usurios como sendo fcil de utilizar, como foi visto em itens anteriores deste captulo. Mas, alm desse valor alcanado atravs da interface do sistema, possvel afirmar, atravs dos dados obtidos nas pesquisas com os usurios, que no que se prope o sistema, ele eficaz. Professores e alunos relataram que a interao entre ambos ganhou uma qualidade maior com a utilizao do sistema como auxiliar para o ensino. Os alunos, principalmente, alegaram que as diversas possibilidades de interao com o sistema estimulava-os a compartilhar e buscar o conhecimento. Claro que algumas falhas de interface ainda ocorreram, comprometendo a total

Erton W. Vieira

123 aprovao desta interao. Porm, a eficcia do sistema atestada pelos seus usurios alvo.

Como instrumento de apoio a aprendizagem o REDU se mostrou til. Nas pesquisas realizadas com os usurios, questes relacionadas Produtividade e Convenincia foram bem avaliadas. At pelas diversas formas de interao que professor e aluno dispem dentro do sistema, que muitas vezes no podem utilizar na sala de aula fsica.

Com poucas interaes dentro do REDU, seus usurios j tm controle das suas aes e j conseguem prever as reaes do sistema aos seus comandos. E quando alguma ao que no esperada ocorre, um canal direto com a equipe do REDU pode ser utilizado para tentar sanar tal ao inesperada.

4.6.2.2 Qualidade No Instrumental

Por ser uma rede social o sistema j tem um apelo forte junto com os jovens. E consequentemente com os professores que tem que lidar com estes jovens conectados. A facilidade do uso do sistema tambm um diferencial que colabora com a aceitao do REDU como ferramenta de auxilio a aprendizagem. Apesar de certa dificuldade no primeiro contato com o sistema, ele se mostra mais atrativo com a frequncia na sua utilizao.

O apelo visual tambm notado pela no rejeio do design apresentado pelo sistema. Questes como a consistncia das telas, adequao da interface ao que est sendo proposto pelo sistema, qualidade das imagens e correta utilizao das cores foram apontadas como satisfatrias pelos usurios do sistema.

4.6.2.3 Reaes Emocionais

Erton W. Vieira

124 Neste componente da experincia do usurio que o REDU tem mais dificuldade em conseguir xito na abordagem. Apesar de uma aceitao geral favorvel ao sistema algumas caractersticas do mesmo causaram reaes contrrias nos seus usurios.

O sistema no mostrou-se estimulante o necessrio para prender a ateno do aluno durante muito tempo. Relatos de disperso do foco, por parte dos alunos, eram constantes. E algumas vezes, os alunos simplesmente no realizavam a tarefa por ela no ser dinmica o suficiente. Quase metade dos alunos entrevistados afirmou que o REDU tedioso. E parte desses estudantes complementou afirmando que o sistema frustrante.

Acontecia reao semelhante com os professores que ficavam frustrados com alguns erros consecutivos quando estavam preparando as aulas. Devido a essa frustrao, muitos fechavam o programa e cogitavam voltar a utilizar os meios fsicos. Porm, existe o detalhe dos professores no serem assduos usurios de tecnologia, o que pode ter influenciado na frustrao dos mesmos. Os valores Divertido e Estar na Moda impactam diretamente nessas reaes emocionais dos usurios. O valor Estar na Moda est sendo trabalhada no sentido de aproximar mais e mais o conhecimento ao conceito de redes sociais. Mahlke e Thring (2007),afirmam que a familiaridade com dinmica de interao, no caso do REDU as redes sociais, ajudam a tornar a utilizao do sistema prazerosa e at atia a curiosidade as pessoas que utilizam o produto com frequncia. J o valor Divertido ainda um desafio de ser trabalhado no REDU. As pesquisas esto acontecendo a fim de definir como seria deixar o sistema mais divertido. Porm, no existe uma estratgia definida de como abordar com eficincia este valor dentro do REDU e, consequentemente, externa-la em sua interface.

Erton W. Vieira

125

Captulo

5
5. Consideraes Finais
O ltimo captulo deste trabalho apresenta uma discusso sobre os resultados obtidos relacionados com os objetivos iniciais da pesquisa, as possibilidades para realizao de trabalhos futuros e a concluso final do trabalho.

Erton W. Vieira

126

5.1

Discusso

5.1.1 A adoo e ajuste do mtodo O REDU seguiu um ciclo de evoluo semelhante aos tantos outros empreendimentos dessa natureza. Uma ideia inovadora e uma vontade de fazer com que essa ideia seja apreciada pela sociedade. E com esforo dos seus idealizadores, comear a construir essa ideia. Com o passar do tempo na construo do REDU, profissionais de reas chaves foram sendo adicionados equipe da empresa, fazendo com que uma metodologia de trabalho e uma viso mais elaborada do que realmente queriam com o produto deles viessem tona, auxiliando os integrantes do REDU a enxergarem onde queriam chegar e como se daria este processo. A definio de seus valores como empresa, foi determinante para essa viso do futuro.

Como costume em equipes iniciais em startups, os integrantes da equipe de desenvolvimento acumulavam tarefas que, devido a sua formao acadmica e profissional, no tinham o domnio necessrio para um trabalho mais elaborado. E fica evidente quando vemos especificamente para o

desenvolvimento da interface do sistema, pois no incio do projeto no havia um designer de fato trabalhando nelas. E ao passar do tempo, a equipe do REDU percebendo este dficit de expertise, procuraram agregar ao seu time pessoas com habilidades para tornar o sistema o mais eficiente possvel.

E para tornar o REDU eficiente, era necessrio que o processo de desenvolvimento fosse eficiente da mesma maneira. A escolha de trabalhar com o Scrum foi uma escolha para tornar o desenvolvimento mais dinmico e rpido, que so preceitos de startups, porm equipes de desenvolvimento respondem de maneiras diferentes as metodologias de desenvolvimento. So pessoas com experincias diferentes e com habilidades diferentes, seguir no trilho uma metodologia pode fazer com que as pessoas no se sintam livres
Erton W. Vieira

127 para ousar. Na medida em que a equipe de desenvolvimento ia se acostumando com a metodologia, adaptaes a ela iam sendo sugeridas pelos prprios desenvolvedores a fim de deixar o processo mais dinmico. Sempre tendo como norteador os valores definidos pela empresa.

Adaptaes essas que tambm ocorriam quando novos membros com habilidades especficas eram adicionados equipe. A adaptao mais significativa ocorreu quando a figura do designer foi adicionada a equipe. Metodologias geis relegam o papel do designer a um segundo plano, focando mais na construo do sistema, porm essa integrao entre o designer e os mtodos geis est sendo sugerida por pesquisadores como Patton (2008), Sy (2007) e Budwing (2009) desde o comeo da dcada. E a equipe do REDU sentiu a necessidade de fazer essa adaptao na sua metodologia de trabalho.

5.1.2 Incorporao de prticas de design da experincia A equipe do REDU utilizou de preceitos apresentados nos trabalhos dos pesquisadores acima citados, fazendo adaptaes j testadas e comprovadas a sua eficcia. Os desenvolvedores do REDU, a fim de tornar o projeto do design da experincia o mais eficiente possvel, utilizou de adaptaes para adequar o design da experincia para trabalhar em harmonia com os mtodos geis. Muitas dessas adaptaes se assemelham ao que Jeff Patton (2008) chamou de 12 prticas que ajudam adaptao das duas metodologias de trabalho.

A primeira prtica que ele cita o de fazer com que o designer tenha voz ativa para decidir o que vai ser construdo. No grupo do REDU, por ser uma

empresa de pequeno porte, todos os participantes tem voz ativa e podem expor suas ideias para serem avaliadas, e sim, o designer faz parte deste time. Envolvendo o designer nesse ponto de surgimento de ideias, algumas que possam ser prejudiciais experincia so logo eliminadas. Um cenrio em que todos ganham por compartilhar sua experincia e expertise.

Erton W. Vieira

128 Uma segunda prtica que o Patton sugere que o design possa sim, ter um tempo para uma pesquisa prvia, para poder entender melhor o usurio e o sistema. No REDU, aconteceu de forma incomum. A pesquisa prvia aconteceu, mas sem a participao do designer. Como o REDU surgiu em uma disciplina de graduao, um estudo prvio foi realizado para avaliar a capacidade de sucesso do sistema. Foram realizadas pesquisas com usurios de sistemas com o mesmo ideal e foram recolhidos muitos requisitos. Esse documento serviu para o desenvolvimento da primeira verso do REDU. Quando o designer entrou para a equipe, o processo de desenvolvimento j estava caminhando em alta velocidade. O designer teve que adaptar-se ao estilo de desenvolvimento da empresa e aos requisitos e modelagens j realizadas por outros integrantes da equipe de desenvolvimento. Aps algum tempo, que o designer teve a liberdade de comear a trabalhar com novas modelagens de acordo com novos requisitos que iam surgindo.

A terceira prtica de quebrar em pedaos o trabalho do designer, para fazer com que ele trabalhe focado em pequenas partes do sistema, tornando o processo mais gil. O designer do REDU relatou que sentiu dificuldades, no primeiro momento, em dividir o trabalho em partes menores, pois no estava acostumado a trabalhar dessa forma. Mas o designer se adaptou a dividir o esforo para cada componente que ele estava trabalhando. Os integrantes da equipe, mais acostumados com a metodologia gil, auxiliaram o designer a se adaptar a esta nova forma de trabalho.

5.1.3 Separao consciente de processos internos Usar desenvolvimento em trilha paralela uma prtica utilizada tambm pelo designer do REDU. A ideia sempre foi deixar o designer trabalhar duas Sprints a frente da equipe de desenvolvimento, fazendo com que o designer tenha tempo de trabalhar todos os conceitos necessrios para uma interface eficiente e fazer com que a experincia do usurio ao interagir com essa interface fosse satisfatria. Aps o tempo de adaptao do designer a esta metodologia de trabalho, ele conseguiu ficar duas Sprints a frente da equipe de

desenvolvimento. Porm, nas entregas de releases, no final de cada Sprint, as

Erton W. Vieira

129 vises do designer e da equipe de desenvolvimento, s vezes, no entravam em total acordo. A equipe de desenvolvimento relatou que muitas vezes discordavam da viso do design para determinada caracterstica do sistema. A equipe do REDU constatou que essa reunio com o design apenas no fim de cada Sprint no era o suficiente. Ento determinaram que um dia na semana eles tivessem uma reunio onde seriam discutidos os rumos que a Sprint estava levando. Esta reunio semanal, chamada pela equipe de Doomsday, serve para que a equipe de desenvolvimento conhea a direo que o design est seguindo e possa dar sugestes de melhoria, o design aqui sabatinado pelos outros integrantes com o intuito de deixar claro o porqu de cada escolha que ele definiu para a interface, alm de discutir, nessa reunio, se os valores do produto esto sendo respeitados nas interfaces do sistema. Nessas reunies o design utiliza mais algumas das 12 prticas como a prototipao de baixa fidelidade, onde ele mostra seus avanos para todos os membros do REDU e ali mesmo eles tratam as especificaes para as interfaces, sem necessidade de documentao mais elaborada. Tornando assim a reunio semanal o mais produtivo possvel.

O interessante que algumas prticas foram utilizadas pela equipe do REDU por intuio. Como uma prtica que sugere ganhar tempo para o designer com aspectos complexos de engenharia. Assim que o designer entrou no grupo ele estava atrasado com suas Sprints, e tinha dificuldade para alcanar a equipe de codificao. O que ocorreu foi que a equipe de codificao se deparou com uma caracterstica complexa do sistema, que levou tempo para ser desenvolvida. Enquanto isso, o design seguia em seu ritmo consistente de trabalho em suas Sprints. Devido a este tempo extra que a equipe de

codificao tomou para desenvolver essa caracterstica mais complexa, o designer conseguiu por as suas Sprints a frente das Sprints da equipe de codificao.

Outras adaptaes metodologia Scrum foram aplicadas no desenvolvimento do REDU, sempre primando pela melhoria da interao entre todas as equipes que estavam construindo o sistema. O banco de ideias um documento onde todos os integrantes do REDU podem sugerir novas ideias para o sistema, eles
Erton W. Vieira

130 mesmos, em conjunto, ranqueiam as ideias para serem trabalhadas em futuras Sprints. O tratamento de erros tambm foi adaptado realidade da empresa, onde cada erro tambm ranqueado e sua criticidade define em qual momento ele ser tratado na Sprint.

Estas adaptaes so importantes para manter o processo do desenvolvimento mais eficiente possvel. Sempre tendo em mente a importncia dos seus valores, como empresa, em suas decises. As adaptaes realizadas no processo de desenvolvimento impactam tambm diretamente na forma em que se projeta a experincia do usurio, e consequentemente, impacta na experincia do usurio com o REDU. Projetar a experincia exige dedicao e uma equipe que tenha conhecimento do que est projetando, e esta dedicao exige tempo de estudo, caracterstica que a metodologia de desenvolvimento limita. Contudo as adaptaes do processo deram um pouco mais de tempo para o designer realizar seus estudos. Houve um suporte direto de pesquisas realizadas pela academia, onde o design aproveitaria para inserir estes estudos no projeto da interface impactando diretamente na experincia do usurio.

E estas adaptaes passam tambm pelo modo que a empresa lida com os testes com usurios. Como se trata de um startup, que tem um nmero limitado de pessoas, que trabalha com metodologia gil de desenvolvimento, onde h urgncia no trabalho, o tempo fator predominante. E os prprios membros da equipe do REDU alegam falta de tempo e de pessoal para que testes com usurios sejam realizados com mais frequncia. Porm, a equipe do REDU se adaptou a essa necessidade utilizando recursos que eles tinham em mos: a academia.

5.1.4 Cooperao cientfica e transferncia de conhecimento acadmico Com o auxlio de um consultor acadmico desde o comeo do projeto, a equipe do REDU tinha respaldo acadmico, atravs de pesquisas realizadas por estudiosos em reas como Interao Humano Computador, Design da Experincia, Auto-Regulao na aprendizagem, onde eles poderiam utilizar

Erton W. Vieira

131 este conhecimento j homologado para trabalhar com mais segurana em elementos chave do sistema, mesmo sem os testes frequentes com usurios.

Mas no quer dizer que os testes com usurio foram renegados. Testes de larga escala foram realizados junto aos usurios. A equipe do REDU, com o auxlio de pesquisadores acadmicos, realizaram testes importantes onde foi possvel identificar detalhes da interao que tinham passado despercebidos tanto pela equipe de desenvolvimento, quanto pelos pesquisadores

acadmicos. E foram importantes para definies de requisitos essenciais para a melhoria do sistema.

Nestes testes foi possvel avaliar a experincia dos usurios reais na utilizao do sistema. E como os valores do produto eram percebidos pelos seus usurios. Os valores do produto definiram a experincia do usurio. Porm, alguns valores no atingiram o sucesso em ser percebido pelos usurios e precisam ser melhor tratados e pensados para a evoluo do sistema. A lio de qual valor deve ser atacada e qual deve ser deixado para ser trabalhado no futuro foi importante para o crescimento do REDU.

5.2

Concluso Final

O REDU utilizou processos geis, pois so metodologias que se encaixam a filosofia de um startup, porm no negligenciou o projeto da experincia do usurio e se adaptou para que as duas formas de trabalhar funcionassem em harmonia. Com esse ambiente harmnico o REDU pode trabalhar a interface em conjunto com todos os seus integrantes, cada um com experincias diferentes e fornecendo feedbacks diferentes, assim, ajudando o designer a aprimorar a utilidade e usabilidade desta interface. Com o tempo maior de trabalho e reunies semanais com pessoas com diferentes estilos de vida, as caractersticas estticas e a qualidade ttil iriam sendo trabalhadas nas interfaces, deixando o REDU mais atrativo para diferentes tipos de usurios. E

Erton W. Vieira

132 esta harmonia das duas metodologias de trabalho, a quantidade de erros diminuram, e as que ainda surgem so rapidamente corrigidos evitando que os usurios se impacientem com o sistema.

As adaptaes do processo de desenvolvimento realizadas no REDU impactaram na qualidade do projeto, O que, devido s metodologias geis, os avanos e melhorias so percebidos pelos usurios rapidamente, no apenas no fim de um grande ciclo. Adaptaes essas que se assemelham ao que Sy (2007) e Buldwing (2009) demonstraram em seus trabalhos.

A pesquisa se apoiou em quatro objetivos especficos para chegar ao objetivo geral. Um dos objetivos especficos era identificar quais so os valores da empresa e como elas foram definidas, atravs de entrevistas com os integrantes da equipe do REDU estes valores foram evidenciados e a percepo de cada um dos membros da equipe sobre estes valores foram expostos, deixando claro que os valores da empresa esto sempre em evidncia e sendo discutido entre os membros do REDU.

Outro objetivo especfico era descrever o processo tcito do design experiencial adotado na empresa, o que atravs das entrevistas com os membros e a anlise de documentos de desenvolvimento ficou clara a evoluo no processo de desenvolvimento do sistema atravs do tempo, e a evoluo da forma como o design da experincia era tratado na construo do REDU. Highsmith (2004) j afirmava que as metodologias geis podem e devem se moldar a dinmica de cada empresa. E essas adaptaes tornam o mtodo de desenvolvimento mais eficiente.

Descrever a experincia do usurio era outro objetivo que, atravs de documentos fornecidos pelo prprio REDU e por outros pesquisadores, ficou evidenciado que a experincia no sistema positiva, porm existem vrios pontos que podem e devem ser trabalhados em verses futuras. Lbach (2001) afirma que o papel do design solucionar problemas, tendo isso em mente, ainda h trabalho a ser feito para corrigir erros no ambiente REDU. Devido a isso, o papel do designer continua sendo importante para o desenvolvimento.
Erton W. Vieira

133

O ltimo objetivo especfico da pesquisa era encontrar pontos em comum entre variveis que descrevem o processo tcito adotado pela empresa e o design da experincia. Aqui os dados obtidos tanto com os desenvolvedores como com usurios foram utilizados para a anlise. Tambm, como forma de organizar os conceitos, dois critrios de qualidade na experincia foram utilizados para realizar a relao entre os conceitos. A anlise deixou claro que os valores podem e devem influenciar no desenvolvimento da interface do sistema, e assim, deixando a experincia do usurio no sistema satisfatria. Os valores impactam tanto no projeto da experincia quanto na forma de produo do sistema.

Tendo alcanado os objetivos especficos o objetivo geral j estaria concludo. Objetivo este que analisar como a gesto de valor em ambientes de desenvolvimento gil impacta na experincia do usurio. E os valores do REDU impactaram e ainda impactam na forma como o sistema foi desenvolvido. Os membros do REDU tm os valores incutidos em suas aes e decises dentro da empresa. Adaptaes nos processos e evoluo da experincia do usurio so norteadas pelos valores da empresa.

5.3 Limitaes da Pesquisa.

Por se tratar de um estudo de caso nico no podemos afirmar que as concluses encontradas nesta pesquisa podem se estender a outros startups.

Detalhes e caractersticas nicas do startup aqui estudado podem ter influenciado nos resultados da pesquisa. Como o caso do REDU ter em sua equipe um consultor acadmico, que um profissional que no se encontra com frequncia em outros startups.

Para este estudo o pesquisador no pode se relacionar diretamente com o usurio da ferramenta REDU. Ento os dados utilizados foram obtidos atravs de pesquisas realizadas por outros estudiosos e ento interpretados para a

Erton W. Vieira

134 finalidade deste estudo. Ento algumas caractersticas da experincia do usurio podem ter sido tratadas com menos ateno do que realmente necessitariam.

5.4

Sugestes para Trabalhos Futuros

Definida como foi essa interao dos conceitos de desenvolvimento gil com conceitos de design, podemos citar alguns caminhos que o estudo pode seguir:

- Realizar um estudo de caso longitudinal com os mesmo objetivos em outros startups, e comparar os resultados obtidos a fim de fortalecer as definies aqui apresentadas.

- A partir das concluses do trabalha, preparar um arcabouo terico de uma metodologia de trabalho eficiente de design em mtodos gil.

- Testar este arcabouo terico com startups e avaliar seu xito.

5.5

Agradecimentos

Um agradecimento especial a toda equipe do REDU que acolheu a pesquisa de braos abertos e abriu as portas para que a pesquisa fosse realizada da melhor forma possvel.

Erton W. Vieira

135

Captulo

6
6. Referncias
ABREU, J. A. Anlise das Prticas de Aprendizagem Colaborativas em Redes Sociais Virtuais no Ensino Mdio. Dissertao (Mestrado em Cincias da Computao) Universidade Federal de Pernambuco. 2011 ABREU, J., CLAUDEIVAN, L., VELOSO, F., GOMES, A. S. Anlise das Prticas de Colaborao e Comunicao: Estudo de Caso utilizando a Rede Social Educativa Redu. XXII Simpsio Brasileiro de Informtica na Educao, 2011, Aracaju-SE. Anais do XXII Simpsio Brasileiro de Informtica na Educao. Aracaj, Sergipe. Brasil, 2011. ALBEN, L. Quality of Experience: Defining the Criteria for Effective Interaction Design, Interactions (3:3), 1996, pp. 11-15. ANDERSON, J. C.; KUMAR, N.; NARUS. J. A. Value Merchants Demonstrating and Documenting Superior Value in Business Markets. Boston, Massachusetts, USA, Harvard Business School Press. 2007. BLANK, S. The Four Steps to the Epiphany. San Mateo, CA: Cafepress.com. 2005. BOEHM, B.; TURNER, R. Balancing Agility and Discipline: A Guide for the Perplexed, AddisonWesley. 2003. BOONE, L. E.; KURTZ, D. L. Marketing Contemporneo. 12 ed. So Paulo: Cengage Learning. 2009.
Erton W. Vieira

136 BREWER, J.; HUNTER, A. Foundations of multimethod research: synthesizing styles. California: Sage Publications. 2006. BUDWING, M.; JEONG, S.; KELKAR, K. When User Experience Met Agile: A Case Study. CHI 2009. Experience with Software & System Development and Evaluation ~ Boston, MA, USA. April 4-9, 2009 CLAUDEIVAN, L. (2011). Anlise das Prticas Docentes de Planejamento e Mediao em Redes Sociais no Ensino Mdio. Dissertao (Mestrado em Cincias da Computao) Universidade Federal de Pernambuco. Recife, 2011 COOPER, A. About Face 3: The Essentials of User Interface Design. IDG Books, 2007. COUTINHO, CLARA P. ; CHAVES, JOS H. O estudo de caso na investigao em Tecnologia Educativa em Portugal. Revista Portuguesa de Educao, Volume 15, nmero 1, pp. 221-244. 2002. DENZIN, N.; LINCOLN, Y. Handbook of Qualitative Research. Thousand Oaks, CA: SAGE Publications. 1994. DOMINGUEZ, SIGRIFIED. O valor percebido como elemento estratgico para obter lealdade dos clientes. Caderno de Pesquisas em Administrao. So Paulo, v.7, n.4. p.53-64. 2000. EASTERBROOK, S.; SINGER, J.; STOREY, M.; DAMIAN, D. Selecting Empiricals Methods for Software Engineering Research. Guide to Advanced Empirical Software Engineering Research. Springer. 2007. FERREL, O. C.; E HARTLINE, MICHAEL D. Estratgia de Marketing. So Paulo: Pioneira Thomson Learning. 2005. FLICK, U. Uma introduo pesquisa qualitativa. X. ed. Porto Alegre: Bookman, 2009. FORLIZZI, J.; BATTARBEE, K. Understanding experience in interactive systems. In Proceedings of the 5th Conference on Designing Interactive Systems (pp. 261-268). New York: ACM Press, 2004. FOWLER, M.; HIGHSMITH, J. (2001) The Agile Manifesto. Agile Alliance. 2001. FOX, B. D. Agile Methods and User-Centered Design: How These Two Methodologies are Being Integrated in Industry. A Thesis Submitted To The Faculty Of Graduate Studies In Partial Fullfillment Of The Requirements For The Degree Of Master Of Science Department Of Computer Science . Calgary, Alberta. Canada. 2010. FRASER, H. Designing Business: New Models for Success. Design Management Review. Vol. 20; No. 2; pp. 5565. 2009.
Erton W. Vieira

137 GALE, B. . Gerenciando o valor do cliente: criando qualidade e servios que os clientes podem ver. So Paulo: Pioneira. 1996. GIL, A.C. Como elaborar projetos de pesquisa. 3. ed. So Paulo: Atlas. 1991. GRANDO, N. Gesto de Conhecimento e Inovao. Ncleo de Design. Centro Universitrio Belas Artes. So Paulo, Brasil. 2011. HERMANSON, B. O que uma startup? Mundo SEBRAE. 2011 HENNIPMAN, E.P.J.; OPPELAAR, E.J.R.G.; VAN DER VEER, G.C.; BONGERS, A.J. Rapid and rich prototyping: proof of concepts for experience. In Abascal, J., Fajardo, I, Oakley, I. (eds.) proceedings of the 2008 European Conference on Cognitive Ergonomics: cool interaction, Madeira, Portugal. 126-131. 2008. HESKETT, J. Creating Economic Value by Design. School of Design, The Hong Kong Polytechnic University, Hong Kong. 2008. HIGHSMITH, J.; COCKBURN, A. Agile Software Development: The Business of Innovation. IEEE Computer, November, p.120-122. 2001. KAPLAN, Robert S; NORTON, David P. A execuo premium: a obteno de vantagem competitiva atravs do vinculo da estratgia com as operaes do negcio. Rio de Janeiro: Elsevier, 2008. KOTLER, PHILIP; KELLER, K. L. Administrao de Marketing 12 Edio - So Paulo: Pearson Education. 2006. KOTLER, PHILIP; ARMSTRONG, GARY. Princpios de Marketing. Prentice Hall Brasil, 12 edio. 2007. MAHLKE, S.; THRING, M. Studying Antecedents of Emotional Experiences in Interactive Contexts. In: CHI 2007 Proceedings, 915918. New York: ACM Press. 2007. MCINERNEY, P.; MAURER, F. UCD in Agile Projects: Dream Team or Odd Couple?, interactions, 12(6), November + December 2005, 19-23. 2005. MELO, C.. Scaffolding of Self-Regulated Learning in Social Networks. Dissertao (Mestrado em Cincias da Computao) Universidade Federal de Pernambuco. Recife, 2010. MINAYO, M.C.S. Pesquisa Social: teoria, mtodo e criatividade. Rio de Janeiro, Vozes. 1994. NIELSEN NORMAN GROUP. Nielsen Norman Group. Design Review by Independent Usability Pros. Acesso em Dezembro de 2011.

Erton W. Vieira

138 NORMAN, D. A.. O design do dia a dia. Rio de Janeiro: Rocco. 2006. OZENC, F. K. Transitions Research for Experience Design, Designing Interactive Products and services for transitions. In the Proceedings of IASDR 2009, International Association of Societies of Design Research. 2009. PALUCH, K. What is User Experience Design. 2009. PATTON, J. Twelve emerging best practices for adding UX work to Agile development. 2008. http://agileproductdesign.com/blog/emerging_best_agil_e_ux_practice.html. Acesso em: 2 nov. 2011. PEREIRA, C. A criao do valor pelo marketing. Instituto Politcnico de Coimbra. Coimbra, Portugal. 2009. PRIDE, W. M.; FERRELL, O. C. Marketing. South-Western, Cengage Learning. 2011. PSOMAS, S. The Five Competencies of User Experience Design. 2009. PUNCH, KEITH. Introduction to Social Research: Quantitative & Qualitative Approaches. London: SAGE Publications. 1998. REISS, E. A definition of user experience. FatDUX Desinging valuable User eXperiences . 2009. Retrived on October 10, 2011, From the World Wide Web: http://www.fatdux.com/blog/2009/01/10/a-definition-of-user-experience/ RIES, E. Lessons learned: what is lean about the lean startup? 2011. Available at: < http://www.startuplessonslearned.com/2009/12/what-is-lean-aboutleanstartup.html>, accessed on: Feb 16. SAVENYE, W.; ROBINSON, R. Qualitative Research Issues and Methods: an Introduction for Educational Technologists. In JONASSEN, David H. (Ed) (1996) Handbook of Research for Educational Communications and Technology. New York: Macmillan USA. p. 1171-1195. 1996. SERRAT, O. Design Thinking. Knowledge Solutions. Asian Development Bank. Manila, Philippines. 2010. SHEDROFF, N. Experience design. Indianapolis, IN: New Riders, 2001. SILVA, E. L.; MENEZES, E. M. Metodologia da pesquisa e elaborao da dissertao. 3 ed., Universidade Federal de Santa Catarina, Programa de ps-graduao em engenharia de produo, laboratrio de ensino distncia, Florianpolis, 2001. SY, D. Adapting Usability Investigations for Agile User-centered Design. Journal of Usability Studies. Vol. 2, Issue 3, pp. 112-132. May 2007.

Erton W. Vieira

139 TEIXEIRA, J.; GONTIJO, L.; MARTINS, R. Marketing e Design. XXIV Encontro Nac. de Eng. De Produo. Florianpolis, SC, Brasil. 2004. WALTERS, R. Managing Your Employer Brand: Throughout The Recruitment Process. Spotlights Series. 2011 WOORDRUFF, R. Customer Value: the next source for competitive advantage. Journal of the Academy of Marketing Science, Greenvale, 1997. V.25, n.2, p. 139-153. 1997. YAMAZAKI, K; FURUTA, K . Design Tools For User Experiences Design. IASDR07 International Association of Societies of Design Research. The Hong Kong Technic University. 2007. YIN, R. Planejamento e Mtodos Estudo de Caso. Ed. Bookman. So Paulo. 2001. ZEITHAML, V. Consumer perceptions of price, quality and value: a means-end model synthesis of evidence. Journal of Marketing, New York, July. v.52, n.3, p 2-22. 1988.

Erton W. Vieira

140

Anexos e Apndices

Erton W. Vieira

141

Erton W. Vieira

142

ANEXO A QUESTIONRIO TESTE DE ACEITAO na ESCOLA DO RECIFE. 1. REAES GERAIS Nas questes abaixo circule o nmero que mais se aproxima da sua resposta. Caso no se aplique circule NA. 1.1. Reao geral em relao ao sistema: 1 1.2. 1 1.3. 1 1.4. 1 1.5. 1 1.6. 1 2 2 2 Terrvel 2 3 Frustrante 2 3 Tedioso 3 Dificil 3 4 5 6 7 Admirvel 7 8 Satisfatrio 7 8 Estimulante 7 8 Fcil 8 9 N/A

9 N/A

9 N/A

9 N/A

Inadequado 2 3 Rgido 3

Adequado 7 8 Flexvel 7 8

9 N/A

9 N/A

2. TELA

Erton W. Vieira

143

Nas questes abaixo circule o nmero que mais se aproxima da sua resposta. Caso no se aplique circule NA. 2.1. Caracteres na tela Dificil de Ler Fcil de Ler 1 2 3 4 5 6 7 8 2.2. O layout da tela foi til 1 2.2.1. Quantidade de informao exibida na tela 2.2.2. Arrumao da informao exibida na tela 2.3. Seqncia de telas 1 2.3.1. Prxima tela na seqncia 1 2.3.2. Voltando para a tela anterior 1 2.3.3. Progresso do trabalho 1 Escreva os seus comentrios sobre as telas aqui: 2 Nunca 3 4 5 6 7 Sempre 8

9 N/A

9 N/A

Inadequada 2 3 Ilgica

Adequada 7 8 Lgica 7 8 Clara

9 N/A

9 N/A

Confusa 2 3 Imprevesvel 2 3 Impossvel 2 3 Confusa 2 3

9 N/A

Prevesvel 7 8 Fcil

9 N/A

7 Clara

9 N/A

9 N/A

Erton W. Vieira

144

______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________

3. TERMINOLOGIA Nas questes abaixo circule o nmero que mais se aproxima da sua resposta. Caso no se aplique circule NA. 3.1. Terminologia relacionada ao trabalho 1 3.2. Execuo de uma tarefa leva a um resultado previsvel Inconsistente 2 3 Nunca 1 2 3 4 5 6 Consistente 7 8 Sempre 7 8

9 N/A

9 N/A

Escreva os seus comentrios sobre as terminologias utilizadas aqui: ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________

4. APRENDIZADO

Erton W. Vieira

145

Nas questes abaixo circule o nmero que mais se aproxima da sua resposta. Caso no se aplique circule NA. 4.1. Incio do uso 1 4.2. Tempo para aprender a usar o sistema 2 Dificil 1 2 3 4 5 6 7 Dificil 3 4 5 6 7 Fcil 8 9 N/A Fcil 8 9 N/A

Escreva os seus comentrios sobre o aprendizado de uso do sistema aqui: ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________

5. MULTIMDIA Nas questes abaixo circule o nmero que mais se aproxima da sua resposta. Caso no se aplique circule NA.

5.1. Qualidade das imagens 1 5.2. Cores usadas so 2

Ruim 3 4 5 6 7

Boa 8 Naturais 9 N/A

No Naturais

Erton W. Vieira

146

1 5.2.1. Quantidade de cores 1

9 N/A

Inadequada 2 3

Adequada 7 8

9 N/A

Escreva os seus comentrios sobre o multimdia aqui: ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________

Erton W. Vieira

147

Erton W. Vieira

148 APNDICE A ROTEIRO DA ENTREVISTA REALIZADA COM A EQUIPE REDU.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Como surgiu o REDU? | Como conheceu o REDU? Como desenvolvido o REDU? Quais mtodos de desenvolvimento so utilizados? Como se d a interao entre os integrantes do grupo de desenvolvimento do REDU? Quais so os valores que o REDU defende? Como foram definidos os valores? Como esses valores impactam no desenvolvimento do REDU? E na interface? Definam cada um dos valores. Como trabalhada a interface do REDU? Qual a liberdade que o design tem para trabalhar as interfaces do REDU? Como so realizadas as pesquisas com o usurio? Houve dificuldades de integrar o mtodo gil e o projeto de design da experincia? Quais so os inputs que o design recebe? De que reas? De que pessoas? Como o REDU lida com os feedbacks fornecidos pelo usurio? Quais as estratgias que o REDU tem para manter a lealdade do usurio? O REDU tem alguma ferramenta para avaliar a interface junto ao usurio? Como est o REDU agora? Na viso de desenvolvimento e mercado? Onde vocs imaginam o REDU daqui a 1 ano? E 5 anos? E 10 anos?

Erton W. Vieira

149

ANEXO B ENTREVISTA ALUNO E PROFESSOR ESCOLA DO RECIFE Entrevista 1 Aluno Perguntas iniciais: todos devem responder
1. De que local voc costuma acessar a internet? a. Casa, escola, lan house, celular, outros 2. E o REDU, de onde vocs acessaram? a. Em que horrio? 3. Quanto tempo, aproximadamente, vocs costumavam utilizar a rede social REDU por dia? 4. Que atividades vocs faziam na REDU

_____________________
1. Como voc costuma se organizar para os estudos que faz em casa? a. Voc costuma planejar seus estudos? i. Como? b. Voc costuma manter um acompanhamento do planejamento que vc fez para estudar? i. Como voc faz esse acompanhamento? ii. Voc utiliza que ferramentas? Papel, agenda, cronograma? 2. Voc costuma fazer uso de agenda? a. Como voc usa a agenda da escola? 3. Na sua opinio em que o uso da rede social REDU contribuiu para aumentar a sua motivao pelos estudos? 4. A rede social REDU contribuiu na organizao do seu estudo? Ajudou voc a ser mais disciplinado para estudar? 5. Em relao a gerenciar/organizar o seu tempo de estudo? O uso da rede social REDU auxiliou ou atrapalhou? Ou no fez diferena em relao a outras formas que voc usava para estudar? 6. O que voc acha da interface da rede social REDU? Ela fcil de usar? As ferramentas que voc precisa esto de fcil acesso? a. Foi fcil voc aprender a usar a rede social REDU? 7. Como voc avalia a sua interao com os colegas na REDU? 8. Como voc avalia a sua interao com os professores na REDU? 9. Voc acha que seu aprendizado foi melhor utilizando a rede social REDU?

Entrevista 2 Professor Perguntas iniciais: todos devem responder

1. Buscar identificar nvel de fluncia em relao ao uso de tecnologias: 2.
Erton W. Vieira

150
a. Voc costuma utilizar tecnologias em seu dia-a-dia? i. Quais? ii. Em que situaes? b. Vocs costumam utilizar tecnologias nas aulas de vocs? i. Quais? De que local voc costuma acessar a internet? a. Casa, escola, lan house, celular, outros E o REDU, de onde vocs acessaram? a. Em que horrio? Quanto tempo, aproximadamente, vocs costumavam utilizar a rede social REDU por dia? Que atividades vocs faziam na REDU?

3. 4. 5. 6.

_________________
1. Como voc avaliaria o desempenho de seus alunos na REDU? a. Voc acredita que o uso da rede levou os alunos a terem um desempenho diferenciado? b. Por qu? 2. Gostaria de ouvir um relato de sua experincia sobre o planejamento e preparo de materiais para as aulas que utilizaram a rede social REDU? a. Como foi o preparo dos materiais para postar na REDU? b. Que tipos de materiais vocs colocaram na REDU? i. Vocs tentaram postar algum material e no conseguiram? c. Com que frequncia vocs postaram contedo na rede social REDU? i. O que o motivaria para colocar contedos mais habitualmente? d. Que passos vocs seguiram para colocar contedo na rede social REDU? e. Quais as principais dificuldades que vocs tiveram para postar contedo no REDU? 3. Como foi acompanhar os alunos utilizando a rede social REDU? 4. Como voc avaliaria a interao entre os alunos na rede REDU? a. A forma de voc interagir com os alunos na REDU foi diferente do que ocorre presencialmente? b. Contribuiu para melhorar o desempenho dos alunos? 5. Em que a rede social REDU contribuiu na avaliao do aprendizado dos alunos? 6. Quais as vantagens e desvantagens do REDU quando comparados com outras ferramentas para auxiliarem o aprendizado? A REDU tem algum diferencial? 7. O que voc acha da interface da rede social REDU? Ela fcil de usar? As ferramentas que voc precisa esto de fcil acesso? 8. Quais as vantagens e desvantagens do REDU quando comparados com o sistema presencial de ensino? a. No preparo do material b. Na interao aluno c. Na interao professor aluno d. No desempenho
Erton W. Vieira

151
e. Na avaliao do aprendizado

Erton W. Vieira