Conecte-se UnB

Fonte: Wikiversidade

Esta página possui o objetivo de reunir todo o conteúdo produzido e necessário para a realização do projeto da disciplina de PSP2, ministrada pela professora Cláudia Melo. O intuito é trazer uma solução que envolva o conceito mais amplo de Cidades Inteligentes, através de métodos e procedimentos trabalhados em sala de aula.

A equipe é composta por: Ana Luísa Nóbrega, Gabriela Franco, Juliana Solon e Vitória Penteado.

Resumo[editar | editar código-fonte]

A cidade é uma grande rede de comunicação onde a informação é extremamente valiosa pois expressa diferentes pontos de vista, linguagens, culturas de uma comunidade interligada. A informação é um bem de influência e importância enorme não somente para a tomada de decisões, mas para trazer fenômenos cada vez mais inovadores e revolucionários na construção do conhecimento. Para a viabilização de uma cidade mais inteligente, capacidades escassas de processamento de informação precisam ser mobilizados.

Um dos principais problemas entre os professores e alunos da Universidade de Brasília (UnB) é a comunicação. O Conecte-se UnB é uma plataforma que possibilita a comunicação aberta, clara e rápida entre docentes e alunos promovendo a eficiência da gestão do conhecimento em pesquisas, projetos e publicações.

A metodologia ágil foi utilizada ao longo do projeto, o que tornou a autogestão, autonomia, especificação mínima e adaptação do time fatores cruciais para o gerenciamento. Foram utilizadas diferentes ferramentas de comunicação, como Trello, Whatssap, Google Agenda, e-mail, Dropbox, Google Drive e Wikiversidade.

Através de técnicas de Design Thinking como Brainstorming e Double-diamond, o time definiu o público alvo, coletou quatro diferentes pontos de vista, fez uma análise desse público e definiu o problema específico. Além disso foram desenvolvidos dois protótipos para a solução antes da escolha do definitivo.

Introdução[editar | editar código-fonte]

Sobre o tema[editar | editar código-fonte]

Para a viabilização de uma cidade mais inteligente, capacidades escassas de processamento de informação precisam ser mobilizadas. Segundo Brian Vickery e Alina Vickery em "Information Science in Theory and Practice", em uma cidade as pessoas (prestadores de serviço, controladores, inovadores, etc) vivem em espaços (mercado, oficina, banco,s etc) e possuem problemas (comércio, segurança, logística, água, transporte, alimentação, etc) que podem ser solucionados principalmente por sistemas de comunicação, sistemas cibernéticos e especialização.

As pessoas estão se tornando cada vez mais especialistas em diferentes áreas e isso torna as cidades cada vez mais complexas, possuindo diversificados produtos e serviços. Além disso, a cidade é uma grande rede de comunicação onde cada vez mais a transmissão da informação é valiosa, pois expressa diferentes pontos de vista, linguagens, culturas de uma comunidade interligada.

Nesse contexto, foi visto que um dos principais problemas do público-alvo aluno e professor da UnB era a comunicação. Com a intenção de tornar o campus Darcy-Ribeiro da UnB mais inteligente decidiu-se focar na integração desse público alvo por meio de um canal de comunicação aberto, claro e rápido que possibilite não somente uma gestão do conhecimento mais eficiente, mas também a mobilização de capacidades escassas de processamento de informação que contribuem para tornar uma cidade mais inteligente.

Objetivo[editar | editar código-fonte]

O objetivo principal do Projeto de Sistema de Produção 2 do time em questão é desenvolver, por meio de técnicas inovadoras de resolução de problemas, tal como o Design Thinking, um plano de ação eficiente que busque a maior comunicação e, consequentemente, integração dos diversos stakeholders da Universidade de Brasília, com enfoque nos alunos e professores da instituição. Tendo sempre como foco tornar Brasília uma cidade mais inteligente e sustentável, o problema principal elencado no curso de PSP 2.

Como objetivo secundário, pode-se citar o fomento à cultura de criação de artigos por parte dos alunos, uma vez que estes, cada vez mais integrados com os professores, teriam maior acesso a certas informações e insumos que poderiam lhe proporcionar um maior conhecimento e, portanto, capacitação para redigir um documento acadêmico.

Metodologia[editar | editar código-fonte]

Gerenciamento[editar | editar código-fonte]

Diante da necessidade de se concretizar duas entregas (uma parcial e uma final) respeitando prazos e requisitos mínimos de estrutura e qualidade, um bom gerenciamento do time se torna crucial, considerando a conciliação de outras responsabilidades acadêmicas por parte dos membros e a grande incidência de choque de horários. Nesse contexto, a metodologia ágil se mostrou muito mais conveniente do que a tradicional, partindo do preceito de que foram feitos pequenos "pacotes" de entregas de maior valor que contribuíram ao fim por agregar valor ao objetivo coletivo da equipe. Juntamente a esse mindset que norteou o comportamento do time durante o trabalho, podemos citar a autogestão como um fator crucial para que cada membro se sentisse responsável pelas atividades que conduziu de maneira a viabilizar as entregas da forma mais proativa possível. A adaptação a mudanças repentinas também se mostra fundamental, pelo fato de o projeto possuir uma demanda por inúmeras sessões de validações com os possíveis usuários, o público-alvo do projeto, ressaltando a necessidade de o time possuir maior capacidade de adaptação, criando mecanismos que diminuam riscos e evitem retrabalho no projeto.

Plano de ação[editar | editar código-fonte]

Pautando-se nos métodos ágeis, ou mais especificamente no SCRUM, alguns planos de ação foram traçados para que o gerenciamento do projeto (ou a autogestão) acontecesse da melhor forma possível:

  • O time se reunia semanalmente às segundas e terças-feiras às 18 horas para discutir o que havia sido feito por cada membro, o que estava em andamento e o que ainda havia de ser feito (um report para alinhamento da equipe); além disso, a reunião servia para eventual execução de alguma parte do projeto que precisasse ser elaborada coletivamente.
  • O time trabalhava com prazos curtos, para viabilizar as entregas de valor individual; toda semana era definido o que era pra ser feito e a data final na mesma semana para que fosse entregue e validado com a equipe - os sprints.
  • O time respondia rapidamente às mudanças que ocorriam ao decorrer da execução das entregas; quando uma adversidade era identificada, algum membro sempre se prontificava a assumir a atividade e viabilizá-la dentro de determinado prazo em colaboração com os demais, de acordo com a ociosidade/sobrecarga de cada pessoa que compõe a equipe.

Riscos[editar | editar código-fonte]

O maior risco que pode ser citado, levando em consideração o contexto do projeto, diz respeito às validações do público-alvo, como mencionado anteriormente. Toda execução se vê dependente dessa validação com os possíveis usuários, tendo em vista que estes são os maiores interessados e sua satisfação quanto à usabilidade da solução apresentada define se a implementação do projeto na rotina desses usuários é realmente possível assim como seu sucesso ou fracasso perante os mesmos. Portanto, é primordial que o time esteja pronto para as adversidades e adaptações dos modelos desenvolvidos, em busca de agregar maior valor possível ao usuário final, buscando maneiras de garantir que haja uma implementação da solução apresentada respeitando os feedbacks e requisitos impostos pelo público-alvo. Além disso, deve-se considerar o risco associado ao gerenciamento do tempo, geralmente, a causa mais comum para conflitos e adversidades ao decorrer de um projeto da natureza do de PSP2. Os riscos classificados como mais alarmantes são:

  • Retrabalho com mudanças requeridas pelos usuários finais.
  • Falta de tempo para adaptações no projeto ou no protótipo do produto final.
  • Falta de tempo para validar modelos elaborados ou protótipo com usuários finais

Custos[editar | editar código-fonte]

Os custos mais significantes que podem ser destrinchados a partir da elaboração do projeto englobam majoritariamente os custos dos materiais do protótipo vinculado ao produto final:

  • Post-its
  • Papéis A4
  • Canetas esferográficas
  • Cartolinas branca
  • Papel-cartão

Comunicação[editar | editar código-fonte]

Quanto aos meios utilizados pelos membros da equipe do projeto para se comunicarem e, assim, estarem sempre alinhados com o andamento dos trabalhos, pode-se citar: Whatsapp, Google Agendas, e-mail, Dropbox, Trello, Google Drive, o Moodle da UnB e a própria plataforma da Wikiversidade. A função de cada um é explicitada a seguir:

  • Whatsapp: Embora não seja o meio de comunicação mais preferível para trabalhos profissionais, devido à totalidade de pessoas que o utilizam frequentemente é praticamente impossível não usufruir do mesmo para a troca de informações entre pessoas. Nele os informes, embora um pouco informalmente, são expostos de forma rápida e prática, por isto foi um dos meios escolhidos pela equipe.
  • Google Agenda: Utilizado para facilitar a marcação de reuniões entre os integrantes do grupo. Nele é possível comparar as agendas de todos e, com isso, cruzar os horários em que nenhum deles possui compromissos para que, dessa forma, seja possível determinar o encontro da equipe. É importante ressaltar que o Google Agendas foi utilizado, principalmente, na parte do projeto em que se foi necessário dividir os horários igualmente para a aplicação de questionários e validação dos protótipos com o público-alvo
  • E-mail: Meio pouco utilizado, mas serviu de base para que alguns documentos pudessem ser compartilhados entre a equipe.
  • Dropbox: Serviu um pouco para substituir o papel do e-mail. Por meio dele todos os integrantes puderam ter acesso a todos os documentos, bastando alocá-los nas devidas pastas e compartilhá-las. Dessa forma, foi bastante utilizado para que a equipe pudesse ter acesso a diversos documentos, principalmente referentes á capacitação, ligados ao projeto.
  • Trello: Serviu para que as atividades do projeto pudessem ser igualmente separadas entre os integrantes da equipe e para que fosse possível ter um controle de quais delas já foram feitas, quais estão em andamento e quais já foram concluídas, bem como a respectivas datas para cada um desses estágios de tarefa. Além disso, o Trello foi muito importante para guiar o time nas tomadas de decisão dos backlogs, pois cada atividade foi separada em prioridades, desde atividades urgentes até menos prioritárias, o que ajudou bastante no acompanhamento do que deve ser focado pelo time.
  • Google Drive: Serviu, majoritariamente, para a criação dos slides de apresentação parcial e final do projeto. Por ser uma plataforma “multi-uso”, foi escolhida por possibilitar a edição por mais de uma pessoa ao mesmo tempo, assim permitindo uma maior eficiência e agilidade na formulação de certos documentos.
  • Moodle da UnB: Permitiu que o time ficasse ciente dos conteúdos disponibilizados pela professora em relação ao projeto. Além de ser uma plataforma para submissão das entregas parcial e final.
  • Plataforma Wikiversidade: Utilizada ao longo de todo o projeto, foi possível a edição de textos por mais de uma pessoa ao mesmo tempo, o que permite também maior eficiência e agilidade na execução do trabalho. Serviu para reunir todo o conteúdo produzido e necessário para a realização do projeto.

Backlog[editar | editar código-fonte]

A equipe do projeto estabeleceu um backlog baseado em tarefas a serem executadas. Esse backlog foi composto por vários sprints explicitados a seguir:

  • Sprint 1 (21/03 - 27/03):

Neste primeiro sprint foi apresentado, em sala de aula, o problema do projeto em questão: “Como podemos tornar Brasília uma cidade inteligente e mais sustentável?”, para a equipe e nele foi estabelecido, pelos integrantes, que as reuniões do projeto seriam realizadas semanalmente.

O grupo buscou se conhecer e se integrar ainda nesse sprint, foi, portanto, realizado uma dinâmica em que cada um devia se apresentar, falar o semestre e o por quê escolheu cursar Engenharia de Produção. Foi bastante rendoso tal atividade pois ajudou o grupo a se formar como equipe.

Além disso, também foi estabelecido que cada um da equipe teria que pesquisar sobre projetos atuais de como tornar as cidades mais inteligentes, por meio de sites confiáveis e ricos em conteúdo, tais como: Research Gate e Academia Edo.

  • Sprint 2 (28/03 - 03/04):

Neste sprint, foi estudado o que é e como aplicar o Design Thinking em projetos atuais. Dessa forma, por meio deste método foi elaborado um questionário para aplicar no público alvo do projeto em questão.

É importante ressaltar que para a elaboração de tal questionário foram estudadas técnicas de como fazer uma “análise de mercado” sem enviesar as respostas dos mesmos. 

Também nesse sprint foram definidas datas e horários para que os integrantes do grupo pudessem aplicar os questionários.

  • Sprint 3 (04/04 - 10/04):

Neste sprint foram aplicados os questionários ao público-alvo do projeto.

O grupo buscou estipular que a aplicação dos questionários seria efetuada nos três principais horários de maior fluxo de pessoas na universidade: no horário de término das aulas do período matutino (às 12 horas), do período vespertino (às 18 horas) e do período noturno (às 22:30 horas), para que, dessa forma, fosse adquirida uma percepção totalitária do público-alvo na UnB.

  • Sprint 4 (11/04 - 17/04):

Neste sprint, a equipe se reuniu para avaliar os resultados dos questionários e discutir quais foram os principais pontos abordados pelo público-alvo. Com estes insumos, o questionário foi refeito, algumas perguntas foram acrescentadas e outras modificadas, conforme o que foi analisado na aplicação do sprint anterior.

Também nesse sprint iniciou-se a estruturação da Wikiversidade. A equipe discutiu quais pontos poderiam ser abordados em tal plataforma e como fariam para começar a editá-la. Além disso, programaram a agenda de horários que os integrantes aplicariam os próximos questionários.

  • Sprint 5 (18/04 - 24/04):

Com os questionários reformulados, esta foi o sprint para aplicação deles. O método de abordagem das pessoas e horários de aplicação foram os mesmo da outra coleta de dados.

  • Sprint 6 (25/04 - 01/05):

Neste sprint, a Wikiversidade do projeto foi atualizada. Com isto, foi realizada uma revisão da mesma em conjunto, por todos os integrantes, na reunião semanal do projeto.

Além disso, com a aplicação do questionário atualizado no sprint anterior, o resultado encontrado foi estudado e, por meio dele, realizou-se um brainstorming com o intuito de definir todos os possíveis problemas e soluções encontrados nos dados levantados.

  • Sprint 7 (02/05 - 08/05):

Com os dados elencados no brainstorming neste sprint foram definidos quais, dentre eles, seriam os principais problemas encontrados até tal momento. Assim sendo, foram feitos templates de pontos de vista.

Com os templates concluídos, na sala de aula forem recebidos feedbacks da professora sobre eles para que, assim, pudessem ser aprimorados.

  • Sprint 8 (09/05 - 15/05):

Neste sprint, todos os problemas elencados nos templates foram minuciosamente destrinchados e discutidos entre o time para que fosse possível determinar, dentre eles, quais seriam candidatos a se tornar o foco do projeto de PSP2.

Além disso, com esses insumos pode-se atualizar o conteúdo da Wikiversidade.

  • Sprint 9 (16/05 - 22/05):

Este foi um dos mais importantes sprints para a equipe pois foi nele no qual o problema específico do projeto foi definido. A partir de tal ação, a Wikiversidade também pode ser novamente atualizada.

Além disso, foi determinado que todos os integrantes se dedicariam à capacitação de prototipagem, estudando formas e práticas de como realizar um protótipo, atualmente, em projetos inovadores.

  • Sprint 10 (23/05 - 29/05):

Com a capacitação realizada no sprint anterior, neste sprint foi possível efetuar a prototipagem da solução do problema do projeto. Todos os integrantes se dispuseram a fazer um rascunho de protótipo. Dessa forma, na reunião semanal todos esses rascunhos foram discutidos e um protótipo inicial foi formulado. A partir disso, partiu-se para a validação e recolhimento de feedbacks sobre o mesmo com o público-alvo.

  • Sprint 11 (30/05 - 05/06):

Neste sprint o protótipo inicial foi validado com a professora de PSP2. Assim sendo, o protótipo foi reformulado a partir dos feedbacks recebidos e dos insumos adquiridos pela validação com o público-alvo no sprint anterior.

A Wikiversidade também foi atualizada com os pontos elencados para a entrega parcial na semana posterior, e o os slides de apresentação para tal entrega foram formulados.

  • Sprint 12 (06/06 - 12/06):

Este foi o sprint de entrega parcial do projeto. Para isto, na reunião semanal, a Wikiversidade atualizada foi revisada, conjuntamente, por todos os integrantes do time, e a apresentação em slides para tal entrega parcial foi alinhada entre eles.

Além de tais atividade foi realizada, com o público-alvo, a validação do novo protótipo.

  • Sprint 13 (13/06 - 19/06):

Neste sprint foram estudados os possíveis modelos de aplicativos ou sites, bem como foi realizado um brainstorming sobre possíveis cores para os mesmos. Com isso, decidiu-se qual seria a melhor cor, nome e design do aplicativo/site e a prototipagem do mesmo no Power Point foi iniciada.

Além disso, a Wikiversidade foi atualizada com os novos insumos.

  • Sprint 14 (20/06 - 25/06):

Neste sprint, terminou-se a prototipagem no Power Point, os slides para apresentação final foram formulados e a Wikiversidade, como semanalmente já havia sendo feito, foi atualizada.

  • Sprint 15 (26/06 - 28/07):

Este foi o último sprint do projeto no qual os slides e a apresentação final foram alinhados entre a equipe, a Wikiversidade foi revisada em conjunto e o projeto final foi apresentado.

Projeto[editar | editar código-fonte]

Definição do problema específico[editar | editar código-fonte]

Smart Cities foi o tema do projeto desenvolvido em PSP 2. O problema elencado através desse tema foi "Como podemos tornar Brasília uma cidade inteligente e mais sustentável?". Esse foi o ponto de partida para todo o projeto. A partir dele, buscou-se definir um problema específico e um público alvo. Para isso, utilizaram-se ferramentas para auxílio na tomada de decisões, como explicitado a seguir:

Smart Cities[editar | editar código-fonte]

Cada vez mais, o mundo se insere na sociedade da informação. A informação é um bem de influência e importância enorme no contexto em que se vive, não somente para tomada de decisões, mas também para demonstrar fenômenos complexos de comunicação e manipulação dessas informações. Essa era da informação traz inovações cada vez mais revolucionárias como computação na nuvem, "open data", "Internet of Things (IoT)", "crowdsourcing", "big data", etc.

As cidades são entidades dinâmicas e complexas que englobam vários setores diferentes e necessitam da manipulação e comunicação da informação para o aprimoramento do seu funcionamento. Cada vez mais está sendo introduzido o conceito de Smart Cities, que apesar de não possuir uma única definição, envolve diferentes setores da sociedade que operam em conjunto para tornar uma cidade mais inteligente. Esses setores estão expressos na imagem abaixo:


Design Thinking[editar | editar código-fonte]

O Design Thinking foi uma ferramenta que norteou o direcionamento do projeto. Através dele, pode-se idear e definir o problema específico e os pontos de vista do usuário.

Para compreender o que é o Design Thinking faz-se mister partir do próprio significado da palavra: "Design" (desenhar) e "Thinking" (pensando, pensar). Nesse sentido, é possível conceituar Design Thinking como o "desenho pensado" de algum produto inovador que seja criado em base da necessidade do consumidor, no "pensamento", no discernimento, do que realmente é preciso e útil á ele.

O Design Thinking não é denominado um método mas sim um tipo de abordagem para a resolução de um problema. Isto porque metodologia remete a algo preciso e propõe fórmulas matemáticas para sua análise, o que é justamente o contrário do Design Thinking que utiliza de um modo de pensamento "fora da caixa" ao partir do conhecimento máximo de seus stakeholders para a resolução de um determinado problema. E quando se fala em stakeholders não transparece-se apenas os clientes ou consumidores do tal produto, mas todas "partes interessadas" do mesmo, e dai é possível notar mais uma característica incomum do Design Thinking que é a interdisciplinaridade, uma vez que parte-se de diversos pontos de vistas para, posteriormente, chegar a um ponto comum, que é a provável solução do problema.

Assim sendo o processo consiste em entender a cultura, os hábitos, as necessidades e as costumes dos consumidores para, somente depois, criar e lançar no mercado um produto inovador. Por isso pode ser dita como uma abordagem totalmente "humana" e certamente subjetiva, que busca nas próprias pessoas a resolução de problemas e portanto, a criação de produtos inovadores.

Etapas do Design Thinking[editar | editar código-fonte]

Compreendido o que é, em tese, o Design Thinking a literatura tende a dividi-lo em cinco etapas:

1) Imersão: Determinada como o "entendimento do problema", é a etapa em que se identifica onde será possível encontrar oportunidades de inovação. Nela busca-se compreender de forma totalitária o desafio, estudando tanto o ponto de vista da empresa quanto do cliente (seus hábitos, costumes, necessidades e etc). Alguns exemplos de ferramentas de pesquisa utilizadas nesta fase são: entrevistas diretas, observações diretas, busca de tendências e entre outras.

A imersão pode, ainda, ser dividida em outras duas subdivisões:

  • Preliminar - Como o próprio nome transparece, é o primeiro contato com o problema.
  • Profundidade - É a subdivisão na qual, já discernido o problema, são levantadas as necessidades e oportunidades que irão nortear a soluções propostas na fase seguinte: a ideação.

2) Ideação: Pode também ser denominado como a fase de "tempestade de idéias". É quando ocorre o Brainstorming e todas as ideias são expostas, sem nenhum julgamento. É o momento de elencar todas as possíveis soluções, para isto são utilizadas ferramentas de criatividade, como Personas ou Work Shop de Co-criação, que estimulam os colaboradores a pensar "fora de caixa" de acordo, obviamente, com o conceito do tema abordado.

3) Prototipagem: Com todas as idéias possíveis geradas, esta é a fase de filtrá-las e determinar quais são as mais condizentes com a realidade do problema e necessidade do cliente. Os autores do livro "Design Thinking- Inovação em Negócios" assim determinam o significado de prototipagem: "Prototipar é tangibilizar uma ideia, é a passagem do abstrato para o físico de forma a representar a realidade - mesmo que simplificada - e propiciar validações”. Dessa forma, a Prototipagem é quando as melhores ideias são elencadas e, a partir delas, é feito um produto teste, o qual será validado posteriormente.

4) Testar o protótipo: É justamente a fase em que o protótipo será validado ou não. Normalmente utiliza-se o MVP - Mínimo Produto Viável , o qual é nada mais do que o produto simplificado, produzido por um valor menor, e testado para verificar se determinado projeto é rentável e necessário ao cliente.

5) Implementação da solução: Após todos os testes feitos e a determinação de que o produto é viável, tanto economicamente como pelo ponto de vista do consumidor, é a fase em que a solução será implementada. Lembrando que o Design Thinking tem como primórdio a satisfação do consumidor e o entendimento de todos os stakeholders do produto. Dessa forma, após a implementação do produto o processo, de incrementação do mesmo é contínuo e experimental, buscando sempre melhorar através de um processo de coparticipação entre as "partes interessadas" (clientes, colaboradores, empresa, fornecedores e etc).

Brainstorming e Double-Diamond[editar | editar código-fonte]

Essas duas técnicas do Design Thinking foram fundamentais para a definição do problema específico e público-alvo.

Inicialmente, houve a necessidade de se definir um público-alvo para direcionar todo o andamento do projeto. A equipe desenvolveu primeiramente métodos de brainstorming para identificar o público-alvo a ser trabalhado e com isso, chegou-se ao consenso de trabalhar acerca dos alunos da Universidade de Brasília que moram em regiões periféricas. O problema encontrado foi o de mobilidade urbana. Nesse contexto, foram coletados dados por meio de entrevistas e pontos de vista sobre os principais problemas enfrentados por esses alunos no dia a dia. Com os dados coletados e entrevistas realizadas, percebeu-se que esse não era o tema que a equipe gostaria de trabalhar e que o enfoque dado tinha sido falho.

Nesse ínterim, a equipe foi em busca de uma reformulação do problema específico e público-alvo para direcionar o andamento do projeto.

Através das técnicas de Brainstorming e Double-Diamond, estudadas desde a aula de Design Thinking, a equipe conseguiu convergir para um determinado público-alvo que pudesse ter algum tipo de demanda. O público-alvo foram alunos e professores da UnB. A demanda real surgiu ao longo de entrevistas posteriormente detalhadas. Esse método foi desenvolvido principalmente em sala de aula através de post-its. A imagem abaixo representa um brainstorming de ideias realizadas pela equipe:


Dados coletados[editar | editar código-fonte]

Nessa segunda fase, realizaram-se uma série de entrevistas para validação de um problema qualquer com público-alvo pré-determinado. Considerando que este se resume a alunos e professores da UnB, a pesquisa foi feita no campus Darcy Ribeiro, com 10 alunos de graduação, 1 de mestrado e 3 professores.

Diante das várias possibilidades de atuação, as entrevistas tinham enfoque para o aspecto da comunicação no ambiente acadêmico. A partir disso, pôde-se convergir para uma demanda mais específica do público-alvo, relacionado a um canal de comunicação mais aberto, claro e rápido no âmbito da pesquisa. Ou seja, as demandas giravam muito em torno de integrar a relação aluno-professor, aluno-aluno e professor-professor quando se realiza quaisquer pesquisas ou projetos dentro da universidade, de modo que haja uma gestão do conhecimento mais eficiente e que, portanto, ofereça mais suporte a todos os interessados.


.

.

Pontos de vista[editar | editar código-fonte]

Os dados obtidos nas entrevistas podem ser traduzidos em pontos de vista. Dessa maneira, a equipe consegue visualizar melhor as perspectivas e diferentes focos que o problema pode ter, considerando a heterogeneidade que existe dentro de um mesmo público-alvo.

Alunos do início do curso - Foi visto que os alunos do início do curso (primeiro ou segundo ano do curso) tinham muitos problemas para encontrar professores pesquisadores na UnB. Muitas vezes esses alunos se concentram nas matérias previstas da grade mas se interessam pouco no âmbito da pesquisa. Os interesses variam, vão desde encontrar áreas que possuem afinidades para iniciar pesquisas até encontrar professores que estejam interessados em um assunto também de interesse do aluno. O alunos ficam sabendo de alguma pesquisa, PIBIT, PIBIC ou projetos de extensão geralmente porque ouviram falar de algum outro aluno que faz (ou seja, a informação é passada boca a boca).

Alunos do meio do curso - Os alunos do meio do curso (terceiro ano do curso) possuem um perfil bem parecido com os alunos do início do curso porém estes possuem um pouco menos de dificuldades para encontrar pesquisadores na UnB. A maioria dos alunos entrevistados já sabia mais ou menos alguma referência na área do seu curso para realizar pesquisas, PIBIT, PIBIC ou projetos de extensão mas ainda assim a informação é passada boca a boca e esses alunos muitas vezes desconhecem plataformas de pesquisa de artigos. Esses alunos possuem mais interesse em realizar pesquisas mas encontram muita dificuldades em encontrar materiais de fontes confiáveis e ainda não sabem muito bem qual a área de interesse das pesquisas que querem trabalhar.

Alunos do final do curso - Os alunos do final do curso (quarto ano em diante) já possuem mais claro quais suas áreas de interesse no âmbito da pesquisa. Além disso, conhecem plataformas de pesquisa de artigos e alguns professores que trabalham na área de interesse do aluno. Apesar de possuírem referências sólidas a respeito de alguns temas, muitas vezes se sentem inseguros pois gostariam de conhecer mais materiais e professores de referência. Foi relatado também que esses alunos não possuem fontes suficientes para a realização de projetos de graduação e trabalhos de conclusão de curso e foi sugerido que uma plataforma que contivesse os trabalhos acadêmicos dos semestres passados facilitaria na conclusão dos trabalhos finais do curso.

Alunos de mestrado - Os alunos de mestrado conhecem referências bem mais sólidas de professores, materiais e interesses. Esses alunos possuem um vasto conhecimento a respeito de realização de pesquisas, plataforma de artigos, revistas de publicação e outros temas. Muitos deles trabalham enquanto fazem o mestrado e muitos também terminaram a graduação à mais de 5 anos. A visão desses alunos é bem diferente dos alunos de graduação pois visam a especificação em uma determinada área. Porém esses alunos ainda encontram dificuldades de achar professores de referência na sua área de pesquisa e pesquisas de outras universidades que tratam da área de interesse.

Professores - Os professores encontram muitas vezes dificuldade em achar bons alunos que tenham interesses nas suas áreas de pesquisa. Estes possuem um vasto conhecimento a respeito de pesquisas e projetos porém muitas vezes desconhecem projetos que outros professores de outros cursos da UnB estão realizando.

Análise[editar | editar código-fonte]

Por meio da análise dos pontos de vista foi possível identificar que o público-alvo do projeto de interesse não são os professores, e nem os alunos de mestrado, pois estes já possuem um conhecimento vasto a respeito da realização de pesquisas e projetos e podem ser contribuintes no sentido divulgar o conhecimento que possuem para os alunos de graduação. Assim, a análise dos dados coletados pode ser representada no gráfico abaixo:

Nesse contexto, foi visto que a facilidade dos alunos de graduação em encontrar professores, encontrar materiais, interesse em pesquisa, conhecimento em pesquisa e na comunicação progredia com o tempo desse aluno no curso. Ou seja, os alunos de final de curso possuem mais facilidade nesses âmbitos dos que os alunos do meio do curso, que por sua vez possuem mais do que os do início.

Além disso foi visto que quase todos alunos de graduação se sentem inseguros com relação a encontrar materiais e professores de referência na UnB e a grande maioria das informações a respeito da pesquisa é passada boca a boca, o que prejudica fortemente a transmissão da informação de maneira íntegra, aberta e formalizada.

Assim, foi visto ainda, que os alunos de graduação possuem diferentes indagações e interesses com o passar do tempo na universidade. Essa análise pode ser representada no gráfico abaixo:

De acordo com o gráfico acima, é possível observar que os alunos no geral possuem diferentes indagações e interesses durante o curso. Os alunos do início do curso estão mais em uma fase de conhecimentos e descobertas, o que influencia nos seus interesses e percepções à respeito da procura por pesquisas e projetos. Os alunos do meio do curso procuram por atividades complementares variadas como estágios, intercâmbios, pesquisas, projetos e começam a se indagar a respeito da área que querem seguir e como querem trabalhar no futuro. Os alunos de final de curso tem dúvidas a respeito da continuação do estudo, se vão trabalhar, onde vão trabalhar, se vão se especializar, realizar mestrado, morar fora do país etc.

Problema específico[editar | editar código-fonte]

Acerca das análises feitas, o time definiu, então, um problema específico. Ele foi identificado como sendo a dificuldade em promover a conexão de alunos a docentes ou alunos de referência em determinada área do conhecimento, no ambiente da Universidade de Brasília, com viés acadêmico e científico.

Público-alvo[editar | editar código-fonte]

O projeto em questão tem como público-alvo os alunos da Universidade de Brasília interessados em participar da comunidade científica da universidade e em se conectar com docentes ou alunos referência em determinadas áreas do conhecimento.

Solução[editar | editar código-fonte]

A solução para o problema específico identificado foi discutida pelo time tendo em vista dos pontos de vista coletados - e, por conseguinte, problema específico e público-alvo.

A solução, para tanto, é uma plataforma que conecta os alunos aos docentes, visando o compartilhamento de informação com viés acadêmico: o Conecte UnB.

Hipóteses[editar | editar código-fonte]

  • A plataforma será bem aceita pelo público-alvo por ser bastante interativa e visual;
  • A plataforma facilitará pesquisas dentro da universidade;
  • A plataforma fomentará e estabelecerá, no curto e longo prazo, uma cultura voltada à pesquisa na universidade;
  • A plataforma terá uma vasta base de dados extraída da plataforma Lattes.

Protótipo[editar | editar código-fonte]

Hipóteses[editar | editar código-fonte]

As hipóteses para iniciação do processo de prototipagem foram obtidas através de sessões de brainstorming que a equipe teve de maneira coletiva.

  • Partindo do princípio que a plataforma deveria ter amplo acesso por parte de alunos e professores da UnB, pensou-se na elaboração de um site e de um aplicativo compatível com vários smartphones e na instalação de totens ao redor dos campus da universidade. Portanto, o site, o aplicativo e o toten seriam inicialmente as plataformas que se utilizaria para oferecer o serviço desejado.
  • Observou-se a necessidade de um feed de notícias, em um primeiro momento, contendo as várias demandas por pesquisas acadêmicas, ou simplesmente notícias sobre projetos e pesquisas que estariam sendo tocados dentro da universidade, tanto no sentido de divulgar quanto de recrutar e engajar pessoas a fazerem parte de qualquer envolvimento desse âmbito mais acadêmico.
  • Um cadastro seria necessário para obtenção de informações e histórico das contribuições acadêmicas dos alunos e professores que utilizariam a plataforma; pensou-se que através do registro com um e-mail Gmail, LinkedIn ou currículo Lattes, os dados poderiam ser puxados automaticamente, reduzindo ainda mais o tempo e o esforço requerido no processo de cadastro pelo usuário.
  • Quando tratamos do mecanismo principal que compõe a plataforma, e que permite a conexão das pessoas através de suas realizações na UnB, observa-se que o uso de filtros (ex.: assuntos de interesse, curso, departamento, etc) promoveria essa interconexão; o resultado das buscas foi definido desde o primeiro momento como PESSOAS, e através delas se obtém acesso a dados mais específicos do que ela produziu e da área de especialização da mesma.
Primeiro protótipo[editar | editar código-fonte]

O primeiro protótipo foi feito de forma manual, sabendo que seria um modelo altamente passível a modificações e adaptações. Pensou-se, inicialmente, no cadastro dos usuários, considerando que fosse o mais interativo e empático possível, criando conexão com o usuário desde o primeiro momento do uso da plataforma.

Protótipo inicial.jpg
Protótipo inicial, feed.jpg
Protótipo inicial, resultados de pesquisa.jpg

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Nesse primeiro protótipo, definiu-se que a plataforma iria operar online por meio de um site. Teve-se também a ideia de montar totens por toda a universidade.

Validações[editar | editar código-fonte]

Alguns questionamentos foram feitos através de validações com possíveis usuários, que permitiram um maior direcionamento na elaboração do protótipo.

  1. O cadastro não é muito longo e cansativo? Os usuários não vão desistir no meio do registro?
  2. O foco não acabou se perdendo por a plataforma ter tantas outras facilidades e funcionalidades?
  3. Será que os totens seriam realmente usados pelas pessoas? Os aplicativos ou sites não são mais simples?
Planos de ação[editar | editar código-fonte]

Os respectivos planos de ação foram traçados para cada validação exposta anteriormente:

  1. O cadastro será objetivo, somente com as informações necessárias.
  2. A plataforma será focada apenas na solução do problema específico citado anteriormente. Não haverá o feed de notícias.
  3. A plataforma será operada através de sites e aplicativos. Os totens não são viáveis e utilizáveis por parte do público-alvo.
Segundo protótipo[editar | editar código-fonte]

O segundo protótipo foi elaborado pautando-se nos feedbacks durante as aulas de PSP 2 e, principalmente, das validações realizadas com os usuários finais. Tendo como base o primeiro protótipo, a grande diferença entre os dois refere-se à facilidade do uso, adaptação ao propósito final do plataforma e atratividade do ponto de vista do novo usuário (cuja segunda prototipagem possui vantagem em todos os aspectos citados).

Abandonou-se a ideia dos totens, pois estes não trariam tanta adesão à plataforma do ponto de vista da atratividade, voltando-se a um protótipo de um site que pudesse ser adaptado para smartphones. Focou-se apenas no mecanismo principal que conectaria os usuários, prevalecendo agregar mais valor através de maior simplicidade e facilidade no uso. Para iniciar, realizou-se um breve rascunho que foi previamente digitalizado e exposto visualmente de maneira mais harmônica e realista.

O protótipo desenhado manualmente foi o seguinte:

Rascunho final do protótipo .jpg
Rascunho final 2 do protótipo .jpg

Além dele, duas outras versões virtuais do protótipo foram criadas, cuja única diferença reside no fundo de tela que aparecerá no computador ou aplicativo dos usuários:

  • Protótipo digital 1: versão com fundo azul
Tela 1 protótipo 1.png
Tela 2 protótipo 1.png
Tela 3 protótipo 1.png
Tela 4 protótipo 1.png
  • Protótipo digital 2: versão com fundo colorido
Tela 1 protótipo 2.png
Tela 2 protótipo 2.png
Tela 3 protótipo 2.png
Tela 4 protótipo 2.png
Validações[editar | editar código-fonte]

Para a etapa da entrega final, se tornou necessário validar o protótipo novamente com o público alvo a fim de identificar de forma ágil os requisitos que não foram aplicados até então. Esse refinamento da prototipação considerou muito mais os aspectos de acessibilidade do usuário final, aspectos visuais e a funcionalidade da plataforma. Uma série de validações foram realizadas através de entrevistas no Campus da UnB, com alunos de graduação majoritariamente, sendo que as que mais agregaram valor do ponto de vista do usuário final são descritas abaixo:

  1. Não terá nenhuma forma de avaliação dos professores?
  2. Existe algum filtro mais específico para refinar a busca?
  3. Terá como acessar os arquivos e projetos do resultado da busca?
  4. Quais serão as informações de contato do resultado da pesquisa?
  5. Só as pessoas que tem Linkedin ou Lattes podem ter perfil público nessa plataforma?
  6. Como será restringido o público só para Universidade de Brasília?
Planos de ação[editar | editar código-fonte]

Os respectivos planos de ação foram traçados para cada validação exposta anteriormente:

  1. Será criado um critério de avaliação de 1 a 5 que aparecerá no perfil do professor; A pessoa avaliará no momento que tiver acesso ao perfil.
  2. Haverá possibilidade de realizar uma pesquisa através de um filtro de busca que permitirá selecionar o curso que o usuário procura. Além disso, o usuário também poderá procurar através de palavras-chaves que farão referência ao tema de interesse. A união do filtro de busca com a inserção da palavra-chave gerará resultados mais precisos e específicos.
  3. O resultado da busca fornecerá um link que redirecionará para o Lattes e/ou Linkedin;
  4. O perfil da pessoa terá as seguintes informações: projetos, pesquisas e publicações realizadas e informações de contato (e-mail, link do currículo Lattes, link do perfil do Linkedin, resumo (opcional) do usuário, posição/cargo do usuário na UnB).
  5. Atualmente, essas são as únicas plataformas que possuem as informações necessárias com grau de confiabilidade desejado. Por isso, somente as pessoas com cadastro nessas plataformas que poderão ter perfil público.
  6. Para os alunos, o cadastro solicitará a matrícula e validará com o MatriculaWeb. Para os professores, o banco de dados da plataforma terá somente perfis de professores da Universidade de Brasília – através da plataforma Lattes.
Terceiro protótipo[editar | editar código-fonte]

A partir dos questionamentos feitos desde o primeiro protótipo levantado, o terceiro protótipo pôde ser elaborado com maior confiança de que o usuário final se adaptaria de maneira mais fácil, criando mais empatia e engajamento pelo uso da plataforma. Apesar das mudanças entre o protótipo 2 e 3 serem pontuais, se mostraram efetivamente relevantes do ponto de vista do público alvo. A ideia dessa terceira prototipação era moldá-la totalmente de acordo com os requisitos dos usuários finais:

Captura de tela 2017-06-27 11.35.06.png
Captura de tela 2017-06-27 11.32.03.png
Captura de tela 2017-06-27 11.32.11.png
Captura de tela 2017-06-27 11.32.36.png
Captura de tela 2017-06-27 11.32.43.png
Captura de tela 2017-06-27 11.33.05.png

Metodologia de Prototipação[editar | editar código-fonte]

Os protótipos foram inicialmente elaborados à mão em cartolina branca e folha A4, diante da grande possibilidade de ter que realizar adaptações com o surgimento de eventuais validações e pontos passíveis a aperfeiçoamento. O protótipo 1 foi usado como base para as posteriores prototipações no computador, que foram realizadas no PowerPoint e permitiram uma melhor visualização do propósito da plataforma e da função central que ela exerce.

Service Blueprint e BPMN[editar | editar código-fonte]

Para refinar ainda mais e compreender, de forma totalitária, a experiência do usuário final ao usufruir da plataforma projetada, foi utilizada a ferramenta do Service Blueprint adaptado a formatação do Business Process Modeling Notation (BPMN).

Este tipo de mapeamento permite analisar e descrever os elementos críticos de um serviço, tais como: o tempo, as sequências lógicas de ações e as atividades que ocorrem, direta e indiretamente, para que o produto final seja entregue. Ele especifica todos eventos que acontecem no espaço-tempo da interação e as ações que estão fora da linha de visibilidade dos usuários, mas que são fundamentais para o bom desempenho do serviço.

Como explicitado, no Service Blueprint as funções são destrinchadas acima e abaixo da linha de visibilidade de quem usufrui da plataforma. Dessa forma, os pontos de intersecção (customer e onstage) e as ações que estão fora da percepção do cliente (back-stage) são documentados e alinhados, cronologicamente, com a experiência do usuário planejada.

Assim sendo, é por meio desta compreensão da jornada do cliente que foram elencadas quais seriam as dúvidas dos mesmos, os pontos de desconexão entre as atividades do processo e como seria o comportamento do cliente, como um todo, ao utilizar a plataforma. Com tais insumos o produto em questão pode ser ainda mais refinado, de acordo com a experiencia com que cada cliente, no caso o usuário, tem ao usufruí-lo.

A imagem a seguir explicita o mapeamento do serviço executado pela equipe do projeto:

Service blueprint.png

Entregas[editar | editar código-fonte]

Apresentação parcial[editar | editar código-fonte]

A montagem da apresentação parcial foi realizada através de um documento PowerPoint compartilhado no Google Drive onde cada membro do time adicionou aos slides as partes que acharam necessárias, seguindo a metodologia ágil de grupos autônomos. Além disso, na reunião do dia 06/06 os membros passaram a apresentação em conjunto, para tirar as últimas dúvidas para o fechamento dessa primeira etapa.

Além disso, a Wikiversidade foi toda atualizada com o relatório escrito sobre o projeto do time.

Apresentação final[editar | editar código-fonte]

Seguiu a mesma linha da apresentação parcial: a apresentação em documento PowerPoint foi elaborada através do Google Drive. Cada membro contribuiu adicionando tópicos pertinentes ao projeto. A equipe alinhou tudo para a apresentação final do dia 26/06 em sala de aula.

A Wikiversidade foi refinada e adicionaram-se alguns outros tópicos essenciais à conclusão do projeto.

Resumo impresso[editar | editar código-fonte]

Nas entregas, apresentou-se a estrutura geral do resumo impresso, que foi a compilação dos pontos mais importantes da projeto até o momento, da Wikiversidade, das referências e documentos compartilhados ao longo do projeto.

.

Considerações finais[editar | editar código-fonte]

Aprendizados[editar | editar código-fonte]

A constante busca por soluções de problemas flexíveis e inovadoras, traz o cotidiano de realização de projetos um grande desafio pessoal e do time. Em meio aos problemas, surge o aprendizado que é um processo de alinhamento e desenvolvimento da capacidade da equipe de criar os resultados que seus próprios membros desejam (Aprendizagem em Equipe: Uma revisão bibliográfica dos principais pilares para a implementação das técnicas de aprendizagem organizacional.)

O time obteve alguns aprendizados importantes a serem relatados como:

  • Mudança do foco do problema: Após a definição do tema, que anteriormente era mobilidade urbana dos alunos da UnB que moravam no entorno, foram realizadas entrevistas e questionários nesse assunto. Devido a inconsistências, o time resolveu mudar o foco para comunicação dos alunos da UnB, o que tornou a pesquisa realizada anteriormente um enorme aprendizado.
  • Mudança no primeiro protótipo: Com a realização do primeiro protótipo, foi visto que este não atendia aos objetivos e foco inicial do projeto, então o time teve que prototipar algumas outras vezes sempre validar com o foco no público-alvo.
  • Comunicação interna: Foi visto ao longo do projeto que o time não possuía ferramentas suficientes para gestão de documentos, então foi necessária a criação de um Google Drive e Dropbox para gestão de documentos da equipe.
  • Reuniões: Foi necessário modificar o local usual das reuniões (Faculdade de Tecnologia, em frente ao aquário) visto que esse local estava muito cheio no horário das reuniões previstas.

Bibliografia[editar | editar código-fonte]

http://dextra.com.br/blog/prototipacao-e-sua-importancia-no-desenvolvimento-de-software/

http://blog.mjv.com.br/ideias/3-fases-do-design-thinking-prototipagem

http://www.slideshare.net/ypigneur/service-blueprint-presentation 

http://www.polaine.com/playpen/media/uxaus/apolaine_UXAustralia_workshop_handouts.pdf

www.slideshare.net/apolaine/blueprint-developing-a-tool-for-service-design

http://www.servicedesigntools.org/tools/35

http://www.pixelkated.com/wp-content/uploads/2011/02/passport-Overview-Service-Blueprint.pdf