Seu Bus
Resumo[editar | editar código-fonte]
Iniciando o projeto, nos familiarizamos com o tema de serviços digitais. A partir disso, uma série de técnicas foram desenvolvidas no projeto de forma que aprofundássemos cada vez mais dentro desse tema. Em seguida, a equipe foi submetida a um brainstorming para definir melhor a área em que nosso projeto seria focado. Como se tratava de um projeto no âmbito governamental, expusemos os principais serviços públicos fornecidos ao cidadão em que poderia haver aplicações relacionadas a serviços digitais.
Depois de escolher que o campo a ser trabalhado seria de transporte público, fomos às ruas a fim de nos aproximarmos ainda mais da realidade vivida pelo cidadão nesse meio e assim então descobrir as principais falhas no sistema público de transporte. Feito todo esse conhecimento das falhas, conseguimos definir nosso problema. Após tal definição, traçamos todas hipóteses de soluções possíveis e depois de escolher uma, aprimoramo-la até que conseguimos definir nosso protótipo final.
Introdução e Justificativa[editar | editar código-fonte]
Serviços digitais[editar | editar código-fonte]
A integração da tecnologia na vida das pessoas, negócios e do governo está ajudando a criar novas formas de comunicação. Com isso aumenta-se a expectativa de que o governo consiga gerar valor para a população por meio da tecnologia. É nesse contexto que entra os serviços digitais, que seria o conjunto de ações aplicadas nos meios digitais. É importante que o governo consiga disponibilizar esse tipo de serviço de forma eficiente, pois facilita o acesso da sociedade aos serviços e informações, além de aumentar a transparência do governo.
Transporte público[editar | editar código-fonte]
Após ter contato com o tema de serviços digitais, o time realizou um "brainstorming" para gerar várias ideias de possíveis áreas onde poderiam existir a necessidade da implementação/melhora de um serviço digital para os cidadãos brasileiros. Dentro das possibilidades produzidas pela equipe, a escolhida foi a de trabalhar com o transporte público. A designação dessa área foi unânime, pois todos integrantes do time já haviam tido algum problema nesse setor. Além disso, tivemos a sensação inicial de que os serviços digitais poderiam muito bem serem utilizados nesse campo.
Projeto[editar | editar código-fonte]
Gestão do Projeto[editar | editar código-fonte]
O time fez uso do WhatsApp, Google Drive, reuniões presenciais e encontro durante as aulas.
O WhatsApp era usado principalmente para marcar as reuniões presenciais. Google drive foi usado para compartilharmos arquivos de texto, planilhas e slides. Durante as reuniões e o os encontros nas aulas, o time conseguia compartilhar as ideias e tomar algumas decisões como por exemplo a maneira como faríamos as entrevistas, quando deveríamos entregar cada tarefa, etc. Também realizamos os protótipos, blueprints e fizemos a wiki durante esses encontros.
A partir do final do mês de maio começamos a utilizar o Trello para conseguirmos organizar nosso tempo e ter noção de como estava a situação de cada tarefa. Para isso criamos 3 colunas com os seguintes nomes: "Tarefas pendentes", "Tarefas em andamento", "Tarefas concluídas". Nessa plataforma foi possível designar a data de entrega de cada atividade e conseguíamos receber emails notificando a situação das mesmas e também notificando alterações feitas por todos os membros do time na plataforma.
Processo de definição do problema (Aulas e Reuniões)[editar | editar código-fonte]
Primeiro encontro do grupo (Brainstorming)[editar | editar código-fonte]
O primeiro encontro da equipe foi realizado em sala, durante a aula de PSP2, onde foi realizado um Brainstorming no qual todos os membros da equipe deveriam escrever em post-its sugestões de problemas que poderiam ser solucionados por meio de serviços digitais. Assim, foi feita uma análise dessas sugestões, onde haviam problemas relacionados com serviço militar, saúde pública e transporte público. A partir disso, foram feitas discussões onde foi definido que o setor de transporte público seria o tema mais adequado à ser trabalhado pela equipe, devido a quantidade recorrente de problemas nessa área e o fato de haver alguns membros e vários conhecidos usuários de transporte público, na equipe.
Segundo encontro (Entrevistas)[editar | editar código-fonte]
O time fez uma reunião com intuito de identificar, através de entrevistas feitas com usuários de transporte público, quais são os principais problemas enfrentados por esses. Nessa reunião foi definido que essas entrevistas seriam feitas, individualmente ou em dupla, em pontos de ônibus. Porém, entre a reunião e a aula em que deveríamos entregar as entrevistas, os membros do time acabaram por realizar entrevistas dentro dos próprios ônibus e na UnB.
As entrevistas seguiram a estrutura de, primeiramente, se apresentar, explicando que fazíamos parte de um projeto da UnB e depois questionar os usuários de transporte público acerca dos principais problemas e falhas encontrados nessa área. Esse diálogo não foi feito com uma estrutura fixa, mas sim de forma dinâmica e livre, fazendo com que os entrevistados se sentissem mais à vontade.
Terceiro encontro (point-of-view)[editar | editar código-fonte]
Esse encontro ocorreu durante a aula e os membros do time escreveram em post its as principais citações dos entrevistados, assim então foi possível obter conhecimento das principais reclamações encontradas por cada um, sendo eles:
- Superlotação;
- Preço;
- Desconforto;
- Despreparo dos funcionários;
- Informações imprecisas quanto aos horários.
Quarto encontro (definição do problema)[editar | editar código-fonte]
O time realizou uma reunião com todos os membros para definir qual seria o problema especifico a ser trabalhado. Para isso, analisamos cada problema separadamente levando em consideração a frequência que ele foi citado, a possibilidade de solução através de serviço digital e o impacto de nossas possíveis soluções.
-Preço: acreditamos que a solução do problema deveria vir de políticas governamentais, impossibilitando a intervenção através de serviços digitais;
-Desconforto: o principal passo seria dado pelas empresas fornecedoras do transporte, através de uma fiscalização efetiva em relação ao estado dos veículos;
-Despreparo dos funcionários: foi um problema pouco mencionado pelos entrevistados, sendo que sua solução cabe as empresas que contratam os funcionários, tornando papel dos mesmos fornecer um preparo ou treinamento melhor;
- Superlotação e Informações imprecisas quanto aos horários: O time ficou dividido entre esses dois problemas pois ambos foram citados com bastante frequência pelos entrevistados e também pela variedade de soluções relacionadas a serviços digitais com forte impacto. Acabamos optando por atacar o problema da desinformação pois acreditamos que esse tema seja de maior prioridade, já que, ao solucioná-lo, ajudaríamos os usuários a não perder seus ônibus, além de reduzir consideravelmente o tempo de espera na parada de ônibus.
Quinto encontro (descrição do problema)[editar | editar código-fonte]
Esse encontro foi realizado durante a aula de PSP e havíamos definido o nosso problema como falta de informações precisas quanto aos horários dos ônibus. Porém, foi levantado pela professora que o nosso problema estava muito amplo e que isso poderia resultar na ineficiência de uma possível solução. Dessa forma o time definiu o problema como tempos excessivos de espera pelos ônibus, que é causado justamente pela falta de informações precisas quantos aos horários dos ônibus.
Primeiro Protótipo[editar | editar código-fonte]
O primeiro protótipo funciona como um notificador de quando um ônibus de determinada linha irá passar por determinado ponto de ônibus, onde:
1-Primeiro, o usuário define o ponto de ônibus sobre o qual gostaria de ser notificado, a partir de um mapa de GPS que cobre toda a área do DF, podendo visualizar facilmente todos os pontos de ônibus que desejar;
2-Após isso, todas as linhas de ônibus que passam por aquele ponto, definido anteriormente, são mostradas na tela, permitindo que o usuário escolha a(s) de sua preferência;
3-E por último, o usuário define qual o período de antecedência em que deseja receber as notificações acerca daquele ponto (vinculado com a(s) linha(s) de ônibus estabelecidas), escolhendo o(s) dia(s) da semana e determinando o(s) intervalo(s) de horário definido(s) para cada dia;
4-Assim cria-se uma lista com todos os pontos personalizados que aparece na tela inicial na forma de um “lembrete”, e que pode ser ativado e desativado quando quiser (semelhante a uma configuração de despertador);
5-A partir disso, o usuário cria quantos pontos personalizados preferir e ativa ou desativa quais forem de sua escolha.
Pesquisa para elaboração do primeiro protótipo[editar | editar código-fonte]
Tomando conta do problema, foi necessário um conhecimento acerca dos possíveis métodos utilizados para que seja possível a elaboração de uma solução. A informação aos usuários acerca da localização dos ônibus e suas rotas já existem em aqui no Brasil e também no resto do mundo, porém, aqui no DF, tal serviço não se encontra em utilização, embora o GDF já tenha se manifestado acerca desse tema. Assim então, tomando exemplo de outros lugares, já existem ferramentas que possibilitam o conhecimento das informações necessárias (localização, horário, fluxo, etc). Após pesquisas feitas pelos membros, a alternativa encontrada, que é a mais utilizada no mundo todo, é a utilização de GPS.
Antigamente o monitoramento dos ônibus era feito através de laços indutivos, que eram instalados sob as vias em pontos estratégicos. Os veículos eram equipados com um dispositivo eletrônico chamado "transponder", que permitiam aos laços indutivos a identificação do ônibus. Através de linhas telefônicas, as informações eram enviadas para o órgão responsável por monitorar o trânsito da cidade.
Nos dias de hoje, o sistema de monitoramento dos ônibus é feito via GPS. A grande vantagem é o controle feito automaticamente e em tempo real. Para que isso se torne possível, é necessário que os automóveis sejam equipados com o modem GSM/GPRS. O GPS oferece ao usuário a sua localização geográfica em coordenadas. O usuário final deve também possuir um aparelho GPS para que receba as informações via satélite e permita o cálculo da posição dos ônibus. Essas informações são enviadas para uma central de controle que possui um software de gestão que processa e distribui essas informações.
Validação do primeiro protótipo[editar | editar código-fonte]
O processo de validação aconteceu nos pontos de ônibus da UnB e com uma estrutura fixa determinada pelos membros do time.
Primeiro nos apresentávamos como estudantes do curso de Engenharia de Produção da UnB e explicávamos brevemente o tema geral do projeto (serviços digitais do governo). Em seguida explicávamos o funcionamento do nosso primeiro protótipo mostrando as ilustrações para ajudar na compreensão. Optamos por não realizar perguntas fixas e deixar as entrevistas fluírem como um bate papo com viés necessário para extrair feedbacks construtivos e positivos. Todas as validações foram realizadas em duplas na qual uma das pessoas estava encarregada de anotar os pontos principais da conversa enquanto o outro conduzia.
Segundo Protótipo[editar | editar código-fonte]
Após fazer a coleta dos feedbacks, o time se reuniu para implementar novas ferramentas no protótipo e corrigir falhas apontadas pelos entrevistados. Assim então, um novo protótipo foi elaborado visando melhorar a experiência do usuário.
Um dos feedbacks construtivos que recebemos dizia respeito à lista de linhas que aparecia para o usuário após selecionar o ponto de partida. No primeiro protótipo, não era possível escolher o destino e, dessa forma, era listada todas as linhas de ônibus que passavam por aquele ponto. A lista acabaria ficando muito longa e muitas vezes os usuários não saberiam de cabeça todas as linhas que os levariam para seu destino. Dessa forma adicionamos a opção de selecionar para onde o cliente deseja ir, mostrando somente as linhas que o levariam até lá.
As validações também nos revelaram o desejo de o usuário visualizar o trajeto que o ônibus faria, para que dessa forma ele tivesse noção de por onde ele passaria. Percebemos também a importância de listar o tempo de viagem, para que assim o cliente conseguisse se programar da melhor forma.
Outro ponto alterado foi a possibilidade de recebimento de notificações sem a necessidade de salvar um trajeto como favorito. Os entrevistados apontaram que nem sempre eles faziam a mesma rota, então não faria sentido salvar nos favoritos um trajeto que seria utilizado pontualmente.
Foi criada também uma lista com o tempo restante de chegada dos ônibus nos pontos selecionados . No primeiro protótipo, em nenhuma interface era possível essa visualização. Antes era necessário salvar uma linha como favorita para receber notificações, impossibilitando aquele usuário que deseja somente saber daqui quanto tempo seu ônibus irá passar.
Abaixo estão as telas do nosso novo protótipo. Ele foi criado utilizando o site proto.io.
Validação do segundo protótipo[editar | editar código-fonte]
Para a validação do segundo protótipo, o time foi ao ponto de ônibus do ICC sul e da FT. Apresentamos o segundo protótipo no tablet e perguntamos se o usuário usaria o aplicativo e pedimos feedbacks. Abordamos um total de 9 pessoas das quais 7 afirmaram que usariam o aplicativo. Das 7 pessoas que usariam o aplicativo, apenas duas deram um feedback construtivo. Um deles disse que gostaria de ver a movimentação do ônibus em tempo real no mapa (parecido com o Uber) e o outro sugeriu uma navegação em tempo real (semelhante ao se iniciar uma viagem no Waze). Dentre as pessoas que disseram que não usariam o app, uma delas justificou dizendo que não gostava de receber notificações e a outra não tinha acesso à internet a qualquer momento.
Blueprint[editar | editar código-fonte]
Lições Aprendidas[editar | editar código-fonte]
O time aprendeu que é de extrema importância a melhor adequação de horários dos integrantes para que sejam feitas reuniões semanais e de qualidade, pois durante o projeto, foi visível a dificuldade que se tinha quando algum membro se ausentava mais, acabando sobrecarregando os demais membros empenhados no projeto. Durante as entrevistas, nos deparamos com problemas que não imaginávamos serem existente e que diariamente muitas pessoas enfrentam, assim então, percebemos que a empatia com quem faz uso do seu serviço é essencial, pois é preciso compreender o que realmente é enfrentado pelo seu cliente diariamente, e dessa forma, gerar uma solução compatível e útil a realidade dos mesmos. Outra lição tomada pela equipe é de que a validação é extremamente importante para um melhor desenvolvimento do projeto, pois é possível notar falhas que os membros do grupo não notam e assim então aprimorar o mesmo e torna-lo cada vez mais próximo da realidade e das necessidades dos usuários.
Bibliografia[editar | editar código-fonte]
http://www.planejamento.gov.br/EGD