FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Peer to Peer Health Insurance
Armindo Barbosa de Carvalho
Mestrado Integrado em Engenharia Informática e Computação
Orientador: António Lucas Soares
21 de Julho de 2016
Peer to Peer Health Insurance
Armindo Barbosa de Carvalho
Mestrado Integrado em Engenharia Informática e Computação
21 de Julho de 2016
Resumo
Nos últimos anos, a tecnologia tem vindo a mudar a forma como vivemos. O acesso cadavez mais generalizado à internet faz com que a informação seja partilhada de forma exponenciale permite que as pessoas estejam conectadas como nunca, o que potencia a criação de economiasde partilha e a formação de redes sociais. Isto leva a que os comportamentos dos clientes mudem,fazendo com que os intervenientes mais tradicionais, enfrentem cada vez mais a competição denovos concorrentes que exploram novas formas de negócio.
No caso do setor segurador uma dessas novas formas de negócio que tem sido apontada comouma grande tendência nesta indústria é o “Peer to Peer Insurance”, que visam a aproveitar aspotencialidades de construção de comunidades na internet de modo a fornecer um serviço segu-rador mais personalizado, transparente e mais facilmente acessível. Desta forma, o “Peer to PeerInsurance” promove a criação de apólices em grupo, sendo o risco das mesmas partilhado pelosmembros desse grupo, permitindo, caso a taxa de sinistralidade seja baixa, a devolução de partedo prémio pago.
O grande objetivo desta dissertação foi a análise deste tema para o caso dos seguros do ramosaúde, utilizando metodologias ágeis de desenvolvimento que privilegiam a vontade do clientefinal, nomeadamente “Design Thinking” e a framework de projetos de inovação da Deloitte, “Di-gital Agility”, sendo que esta análise culminaria na criação de um protótipo funcional de umaaplicação web, capaz de simular esta nova modalidade de vender seguros.
Ao longo deste projeto, foram realizados entrevistas e workshops de Design Thinking compotenciais futuros utilizadores de uma plataforma de P2P Health Insurance, de forma a construiruma visão geral de quais as funcionalidades pertinentes para uma aplicação deste tipo. Após estaetapa, foi desenvolvido um protótipo utilizando tecnologias de desenvolvimento web, finalizandoassim o trabalho desta dissertação.
i
ii
Abstract
The technology has been changing the way we live and the global access to the internet hasfacilitated the information sharing and allowed people to be more connected than ever, enhancingthe creation of sharing economies and social networks. Thus, the behavior of the customers arechanging, threatening traditional market players with the competition of new entrants exploringdisruptive technologies.
In the Insurance industry, one disruptive idea that has been indicated as a trend is the Peerto Peer Insurance. This new way to sell insurance tries to leverage the advantages of internetcommunities to provide a better service, more customized, transparent and accessible. With thisgoal, "Peer to Peer insurance", allows the creation of groups of people to share the risk of insuranceproducts and in case of low number of claims, part of the premium is returned to the customer orused to pay the insurance in the next year.
The main goal for this dissertation was to study this topic to the health insurance field, usingagile methodologies like Design Thinking and Deloitte’s framework for innovation projects, “Di-gital Agility”. This analysis would end up with the development of one prototype of of one possi-ble solution for this new model to sell insurance.
During this project, in one first phase there were interviews and Design Thinking workshopsto gather the main functionalities of the solution, and in the second phase, the solution prototypewas developed by the student.
iii
iv
Agradecimentos
Deixar os agradecimentos para o final da escrita da dissertação tem a vantagem de permitir quenenhuma pessoa que tenha colaborado, seja colocada de parte, no entanto, a grande desvantagemé que devido à pressão para entregar o documento, não podemos dar asas à nossa veia poética deforma a construir um texto que emocione aqueles que nele são referenciados, porém darei o meumelhor.
Em primeiro lugar gostaria de agradecer, na pessoa do Eng. Nuno Cordeiro, à Deloitte pelaoportunidade que me facultaram de desenvolver esta dissertação sobre um tema tão atual e per-tinente, num ambiente muito estimulante e rodeado de pessoas fascinantes. Em segundo lugargostaria de agradecer ao Eng. Miguel Mendes, pessoa que me acompanhou de perto e que tornoutoda esta experiência muito mais estimulante e enriquecedora. Para terminar os agradecimentosrelacionados com a Deloitte, resta-me agradecer àqueles que me acompanharam todos os dias, no-meadamente aos elementos do grupo da Deloitte Digital do Porto: André Silva, António Moura,Carlos Piedade, Filipe Perdigão, Lara Marinha e Ricardo Pedroso, agradecendo ainda na pessoado Eng. Fernando Pinto, a todas as pessoas do Oporto Digital Studio.
Quero também agradecer a todas as pessoas que foram entrevistadas ao longo desta disserta-ção, bem como, a todos os meus amigos e colegas que participaram nos workshops que realizei. Omeu muito obrigado a todos vocês: Adriana Rocha, Joana Sousa, Cláudio S. João, Diogo Freixo,Ana Rita Ferreira, Tiago Torre, Pedro Almeida, Sara Freixo, Gonçalo Moreira, Vasco Félix, Mar-garida Correia, Rúben Peixoto.
Ao Professor Doutor António Lucas Soares, quero agradecer toda a disponibilidade e empenhodemonstrados desde o primeiro contato feito desde Zagreb para o Porto.
Por fim, resta-me agradecer àqueles que sempre tornaram tudo mais fácil e que sempre fizeramtudo para que eu cumprisse esta etapa com sucesso. Nenhuma palavra é suficientemente forte paradescrever o meu profundo obrigado a todos vós. À minha namorada, Jéssica Ferraz, obrigado portudo! Aos meus irmãos, Ana Sofia e José, bem como, aos meus novos irmão Pedro e Teresa, muitoobrigado também! Ao meu pai e à minha mãe, obrigado por me possibilitarem tudo aquilo querepresentaram os últimos 5 anos.
Armindo B. Carvalho
v
vi
“Se não fosse inseguro, não conseguia um nível de qualidade mínimo nos meus textos.(...)
O receio de falhar parece-me muito produtivo.”
Ricardo Araújo Pereira
vii
viii
Conteúdo
1 Introdução 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Oportunidade e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Indústria Seguradora e a Inovação 52.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Desafios da Indústria Seguradora . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Novas tecnologias e novas formas de negócio . . . . . . . . . . . . . . . 72.2.2 Nova geração de utilizadores . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Aumento da Concorrência e necessidade de inovação . . . . . . . . . . . 9
2.3 Seguros (d)e Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Os desafios dos Seguros de Saúde . . . . . . . . . . . . . . . . . . . . . 112.3.2 Ter um seguro de Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Inovação nos Seguros de Saúde . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Peer to Peer - A comunidade em ação . . . . . . . . . . . . . . . . . . . . . . . 152.4.1 Peer to Peer na Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Peer to Peer Insurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.1 Atuar como um intermediário . . . . . . . . . . . . . . . . . . . . . . . 182.5.2 Comunidade e Seguradoras . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.3 Baseado na Comunidade . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Estado da Arte - Desenvolvimento Web e Prototipagem 233.1 Frameworks de desenvolvimento web . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Backend frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Frontend Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Sistemas de Gestão de Conteúdo - CMS . . . . . . . . . . . . . . . . . . . . . . 323.2.1 Joomla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.2 WordPess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.3 Drupal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Ferramentas de Desenvolvimento Rápido de Aplicações - RAD . . . . . . . . . 353.3.1 OutSystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.2 Mendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.3 SalesForce - plataforma de desenvolvimento rápido de aplicações . . . . 38
3.4 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
ix
CONTEÚDO
4 Metodologia e Objetivos 414.1 Novas tendências na Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . 414.2 Uma metodologia para a criatividade: Design Thinking . . . . . . . . . . . . . . 43
4.2.1 Imersão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.2 Ideação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.3 Prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Metodologias Ágeis na Deloitte . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1 Design thinking na Deloitte . . . . . . . . . . . . . . . . . . . . . . . . 474.3.2 Abordagem ao problema da dissertação . . . . . . . . . . . . . . . . . . 47
5 Imersão, Ideação e Prototipagem 495.1 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Entrevistas a clientes de seguros e potenciais clientes . . . . . . . . . . . 505.1.2 Entrevistas a Prestadores de Serviços de Saúde . . . . . . . . . . . . . . 525.1.3 Entrevistas a mediadores de seguros saúde . . . . . . . . . . . . . . . . . 52
5.2 Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2.1 Workshop 1: Seguros, Seguros e Seguros de Saúde . . . . . . . . . . . . 545.2.2 Workshop 2: Comunidade e Saúde . . . . . . . . . . . . . . . . . . . . 595.2.3 Workshop 3: Seguros e Saúde . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.1 Workshops e Entrevistas: Lições para o Futuro . . . . . . . . . . . . . . 655.3.2 Oportunidade e Problemas . . . . . . . . . . . . . . . . . . . . . . . . . 66
6 Visão da Geral da Plataforma 696.1 Atores da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2 Descrição dos Problemas e Oportunidades . . . . . . . . . . . . . . . . . . . . . 696.3 Visão da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.4 Objetivos da plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.5 Visão geral das Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.5.1 Funcionalidades para o Cliente . . . . . . . . . . . . . . . . . . . . . . . 736.5.2 Funcionalidades para os Profissionais de Seguros . . . . . . . . . . . . . 786.5.3 Funcionalidades para os Prestadores de Serviços de Saúde . . . . . . . . 80
6.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7 Implementação do Protótipo 837.1 Arquitetura de Prototipagem Deloitte Digital . . . . . . . . . . . . . . . . . . . . 83
7.1.1 Camada de Backend e Camada de Dados . . . . . . . . . . . . . . . . . 847.1.2 Camada de Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . 857.1.3 Camada de Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2 Funcionalidades Implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3.1 Iteração 0 - Protótipo Estático . . . . . . . . . . . . . . . . . . . . . . . 897.3.2 Protótipo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.3.3 Iteração 2 - Protótipo Final . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.4 Validação do Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
x
CONTEÚDO
8 Conclusão 978.1 Design thinking e as suas potencialidades . . . . . . . . . . . . . . . . . . . . . 978.2 Avaliação das tecnologias escolhidas . . . . . . . . . . . . . . . . . . . . . . . . 988.3 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998.4 Avaliação do trabalho desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . 100
Referências 103
A Processo de Prototipagem 109A.1 Iteração 0 - Protótipo Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . 109A.2 Iteração 1 - Protótipo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.3 Iteração 2 - Protótipo Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
xi
CONTEÚDO
xii
Lista de Figuras
2.1 Simulação de apólice no website da Lusitania seguros . . . . . . . . . . . . . . . 132.2 Exemplos de ecrãs da aplicação para dispositivos móveis da Médis . . . . . . . . 142.3 Comparação entre a vista geral do plano de saúde das companhias Oscar e Médis 15
3.1 Método de funcionamento não-bloqueante do NodeJS[dS15] . . . . . . . . . . . 29
5.1 Fotografia recolhida no primeiro workshop . . . . . . . . . . . . . . . . . . . . 555.2 Esquema representativo do protótipo do primeiro grupo do workshop 1 . . . . . . 575.3 Esquema representativo do protótipo do segundo grupo do workshop 1 . . . . . . 585.4 Esquema representativo do protótipo do primeiro grupo do workshop 2 . . . . . . 605.5 Esquema representativo do protótipo do segundo grupo do workshop 2 . . . . . . 615.6 Esquema representativo do protótipo do terceiro grupo do workshop 2 . . . . . . 615.7 Fotografia dos participantes no workshop 3 a realizarem os seus protótipos . . . . 635.8 Esquema representativo do protótipo do primeiro grupo do workshop 3 . . . . . . 645.9 Esquema representativo do protótipo do segundo grupo do workshop 3 . . . . . . 65
6.1 Diagrama de Casos de Uso do Cliente para a gestão do seu seguro . . . . . . . . 746.2 Diagrama de Casos de Uso do Cliente para a gestão dos seus cuidados médicos . 766.3 Diagrama de Casos de Uso do Cliente alavancando o fator comunidade . . . . . . 776.4 Diagrama de Casos de Uso para os profissionais de Seguros . . . . . . . . . . . . 796.5 Diagrama de Casos de Uso para os Prestadores de Serviços de Saúde . . . . . . . 80
7.1 Esquema da arquitetura de prototipagem da Deloitte Digital . . . . . . . . . . . . 847.2 Esquema do modo de funcionamento do Falcor retirada de [FAL] . . . . . . . . . 867.3 Rascunhos relativos à estrutura de alguns ecrãs . . . . . . . . . . . . . . . . . . 907.4 Estrutura da página dedicada à procura de porfissionais de saúde com exemplos
aleatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.5 Estrutura do ecrã que possibilita a criação e adesão a comunidades . . . . . . . . 917.6 Página principal da plataforma - possibilidade de simulação da apólice . . . . . . 917.7 Página de Controlo da plataforma . . . . . . . . . . . . . . . . . . . . . . . . . 927.8 Página de criação e adesão a comunidades . . . . . . . . . . . . . . . . . . . . . 927.9 Página de procura por profissionais de saúde . . . . . . . . . . . . . . . . . . . . 927.10 Página de consulta das atividades da comunidade . . . . . . . . . . . . . . . . . 937.11 Página principal da plataforma, fornecendo a possibilidade de simulação . . . . . 937.12 Página de registo na plataforma e subscrição da apólice . . . . . . . . . . . . . . 947.13 Página de criação e adesão a comunidade na nova plataforma . . . . . . . . . . . 947.14 Página de consulta das atividades da comunidade e interação com os outros membros 94
A.1 Esquema representativo da página de perfil e de controlo . . . . . . . . . . . . . 109
xiii
LISTA DE FIGURAS
A.2 Esquemas representativos da página de comunidade e da página de controlo . . . 109A.3 Esquemas representativos da página de marcação de consultas e do motor de pes-
quisa de profisssionais de saúde . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.4 Esquema representativo da apresentação do detalhe do sinistro . . . . . . . . . . 110A.5 Primeira estrutura pensada para a partilha de atividades entre os membros da co-
munidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.6 Primeira estrutura pensada para a criação de comunidades . . . . . . . . . . . . . 111A.7 Estrutura para as página de procura por profissionais de saúde . . . . . . . . . . 111A.8 Estrutura da página de consulta do histótico de sinistros . . . . . . . . . . . . . . 111A.9 Estrutura inicial da página de perfil pessoal . . . . . . . . . . . . . . . . . . . . 112A.10 Página de revisão do serviço prestado pelos profissionais de saúde . . . . . . . . 112A.11 Estrutura inicial da página de marcação de consultas . . . . . . . . . . . . . . . 112A.12 Estrutura inicial da página de controlo . . . . . . . . . . . . . . . . . . . . . . . 113A.13 Página Inicial do protótipo funcional - possibilidade de simular a apólice . . . . . 113A.14 Página de escolha do plano de saúde oferecido . . . . . . . . . . . . . . . . . . . 113A.15 Página de subscrição e registo na plataforma . . . . . . . . . . . . . . . . . . . . 114A.16 Página de controlo do primeiro protótipo . . . . . . . . . . . . . . . . . . . . . . 114A.17 Página de criação e adesão a comunidades . . . . . . . . . . . . . . . . . . . . . 114A.18 Página de procura de profissionais de saúde . . . . . . . . . . . . . . . . . . . . 115A.19 Página das atividades da comunidade . . . . . . . . . . . . . . . . . . . . . . . . 115A.20 Página de perfil pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.21 Página de consulta da cobertura do seguro . . . . . . . . . . . . . . . . . . . . . 116A.22 Página de marcação de consulta - escolha do tipo de visita . . . . . . . . . . . . 116A.23 Página de marcação de consulta - escolha do tipo de especialidade . . . . . . . . 116A.24 Página de marcação de consulta - escolha do profissional de saúde e data . . . . . 117A.25 Página de revisão do serviço prestado pelos profissionais de saúde . . . . . . . . 117A.26 Página do histótico de informação clínica . . . . . . . . . . . . . . . . . . . . . 117A.27 Página de consulta do histórico dos sinistros . . . . . . . . . . . . . . . . . . . . 118A.28 Página inicial e de simulação da apólice . . . . . . . . . . . . . . . . . . . . . . 118A.29 Página de exibição dos vários planos de saúde disponíveis . . . . . . . . . . . . 119A.30 Página de registo e subscrição da solução final . . . . . . . . . . . . . . . . . . . 119A.31 Página de criação e adesão a comunidades do protótipo final . . . . . . . . . . . 119A.32 Página de partilha de atividades entre membros da comunidade . . . . . . . . . . 120
xiv
Lista de Tabelas
2.1 Análise comparativa das várias seguradoras . . . . . . . . . . . . . . . . . . . . 142.2 Análise comparativa das várias seguradoras . . . . . . . . . . . . . . . . . . . . 21
3.1 Análise comparativa das várias abordagens possíveis . . . . . . . . . . . . . . . 393.2 Análise comparativa das Frameworks de Backend . . . . . . . . . . . . . . . . . 393.3 Análise comparativa das Frameworks de Backend . . . . . . . . . . . . . . . . . 403.4 Análise comparativa das Frameworks de Backend . . . . . . . . . . . . . . . . . 40
6.1 Tabela com os problemas e oportunidades recolhidas . . . . . . . . . . . . . . . 706.2 Tabela com os problemas e oportunidades recolhidas para os clientes no âmbito . 716.3 Tabela com os problemas e oportunidades recolhidas no âmbito da gestão dos
cuidados médicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.4 Tabela com os problemas e oportunidades recolhidas no âmbito da criação de co-
munidades online de P2P Health Insurance . . . . . . . . . . . . . . . . . . . . . 726.5 Tabela com os problemas e oportunidades recolhidas no âmbito da criação de co-
munidades online de P2P Health Insurance . . . . . . . . . . . . . . . . . . . . 756.6 Tabela com as funcionalidades para o cliente no âmbito da gestão dos cuidados
médicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.7 Tabela com as funcionalidades disponíveis a nível da comunidade . . . . . . . . 786.8 Tabela com as funcionalidades possíveis para profissionais de seguros . . . . . . 796.9 Tabela com as funcionalidades possíveis para Prestadores de Serviços de Saúde . 81
7.1 Tabela com as funcionalidades disponíveis a nível da comunidade - parte I . . . . 887.2 Tabela com as funcionalidades disponíveis a nível da comunidade - parte II . . . 89
xv
LISTA DE TABELAS
xvi
Abreviaturas e Símbolos
P2P Peer to PeerPPI Modelo Peer to Peer InsuranceMVC Model-View-ControlerCMS Sistema de Gestão de ConteúdosREST Protocolo de Comunicação Representational State TransferAPI Application Programming InterfaceORM Object Relational MapperNPM NodeJs Package ManagerPIP Gestor de pacotes de software de PythonCRM Customer Relationship Management
xvii
Capítulo 1
Introdução
1.1 Contexto
No final dos anos 90, a Kodak liderava o mercado da venda de produtos fotográficos, assim
como, a Nokia se começava a afirmar como um dos grandes intervenientes na indústria dos tele-
móveis. Nesta altura, estas duas empresas pareciam ter pela sua frente muito sucesso e provavel-
mente poucas pessoas arriscariam dizer que estes dois gigantes da economia mundial acabariam
por fechar atividade nos sectores de atividade que lideravam. No entanto, a dificuldade da Kodak
se adaptar às novas exigências da fotografia digital e a entrada tardia da Nokia no mercado dos
smartphones, levaram a que estas duas empresas perdessem o estatuto de líderes, passando a ser
apontados como exemplos da importância estratégica da inovação. A Kodak encerrou, em 2012,
a sua atividade no sector dos produtos de fotografia de consumo e a Nokia optou por vender, em
2014, o seu negócio relativo aos dispositivos de comunicação móvel à Microsoft[DiS11].
Aos exemplos das duas empresas anteriores, poder-se-ia juntar o exemplo da queda do volume
de negócios no sector da produção de música após a proliferação de plataformas de distribuição
de música pela internet, tais como, a Napster e o Itunes[KKP]. E avançando até aos tempos atuais,
podemos ver empresas como a Uber, a AirBnB e a Netflix, a ameaçarem, respectivamente, os
intervenientes mais tradicionais no sector dos transportes, alojamento e meios de comunicação.
Todos estes casos, mostram-nos que a inovação chegará, mais tarde ou mais cedo, a todos os
sectores de atividade sem exceção, colocando em risco, todas as organizações que optarem por
resistir a inovar.
A Indústria financeira, na qual se incluem os bancos e as empresas seguradoras, não é diferente
das demais[BOA16]. Plataformas como o KickStarter, que permitem que empresários reúnam o
investimento necessário para o lançamento de certos produtos, são apenas um exemplo de como
as comunidades online podem vir a afetar a indústria financeira, pois desta forma os empresários
evitam o risco de pedir um empréstimo a uma instituição financeira e simultaneamente garantindo
antecipadamente a viabilidade financeira do produto que estão a lançar. Portanto, a indústria
1
Introdução
financeira deverá estar atenta às várias ideias de negócio que vão surgindo no seu sector, assim
como, apostar em projetos de inovação que melhorem os índices de satisfação dos seus clientes e
aproveitem as novas tecnologias para introduzir novos produtos e serviços.
Mais especificamente no sector segurador, a introdução das novas tecnologias, nomeadamente,
aquelas relacionadas com a criação de novos canais venda, poderá trazer muitas vantagens tanto
para os clientes como para as seguradoras, garantindo assim um melhor índice de satisfação entre
e uma maior taxa de retorno, respetivamente. Estas novas tecnologias poderão, entre outras coisas,
ajudar as companhias de seguro a melhor calcular o risco associado a cada apólice e assim fornecer
um preço mais justo a cada cliente. Por outro lado, as novas tecnologias podem ajudar as empresas
seguradoras a fornecerem uma melhor experiência de utilização dos seus serviços, ajudando os
clientes a ter maior facilidade em gerir todos os assuntos relacionados com o seguro e levar a que
o cliente fique encantado com a qualidade do serviço prestado [BER16b]. Além disto, as novas
tecnologias poderão ajudar as seguradoras a implementar outras formas de negócio mais atrativas
para determinados segmentos de clientes, personalizando ainda mais o tipo de serviço prestado
[KKP].
A necessidade de estudar formas de negócio inovadoras, bem como, potenciar o uso de novas
tecnologias de forma a providenciar um melhor serviço ao cliente, pelos motivos anteriormente
referidos, levaram a que muitas empresas apostassem na criação de projetos de investigação que
visassem aproveitar as novas potencialidades que a tecnologia fornece, com o objetivo de tentar
acompanhar de perto as várias criações que vão surgindo e estudar novas formas de estar presente
no mercado. Neste sentido, a Deloitte, empresa de referência na prestação de serviços em Portu-
gal, funda em 2015 um novo grupo de competências dentro do seu departamento de consultoria
em serviços financeiros, a Deloitte Digital. Este novo grupo de competências é criado com o ob-
jetivo de estudar soluções disruptivas para os seus clientes, ajudando estes a se reinventarem de
modo a responderem às novas exigências do mercado. Com este novo grupo de competências,
a Deloitte também se reinventa, incorporando nos seus recursos quadros de diferentes áreas, tais
como, designers, de forma a conseguir providenciar aos seus clientes uma nova abordagem, muito
focada nos meios digitais e na criação de novos produtos e serviços, com o objetivo de otimizar a
experiência de utilização fornecida por estes.
A Deloitte tem vindo nos últimos tempos a identificar alguns temas que podem vir a causar
impacto na área da indústria financeira, noemadamente, a aplicação de Internet Of Things a esta
área, sendo que outra dessas temáticas é o modelo "Peer to Peer Health Insurance"[Del15]. Dado o
interesse de investigar sobre este tema e de criar um protótipo que prove o conceito subjacente, leva
a que este tema apresente relevância necessária para a realização de uma dissertação de mestrado
na área da engenharia informática e computação.
1.2 Oportunidade e Objetivos
A indústria seguradora, bem como os seus parceiros, pelos motivos que foram referidos no
ponto anterior, tem procurado acompanhar de perto as inovações que vão surgindo no seu setor e,
2
Introdução
por outro lado, apresentar soluções novas. Estas soluções têm como objetivo o maior aproveita-
mento dos canais digitais para a venda e gestão dos seguros, a necessidade de diferenciação entre
as várias empresas concorrentes e a conquista de uma nova geração de clientes que está a crescer.
O modelo de Peer to Peer Insurance é criado para endereçar estes objetivos. Este conceito
novo de vender seguros, consiste na construção e gestão de comunidades virtuais através de uma
plataforma feita para este propósito. Estas comunidades, partilham o risco de apólices de seguros
entre os membros da comunidade e caso o volume de sinistros seja baixo, no final de cada ano o
dinheiro do prémio inicialmente pago, ou parte dele, é devolvido aos membros da comunidade.
Esta forma de negócio tem suscitado interesse entre as várias seguradoras, pois para além de for-
necer um preço mais baixo para os clientes, as seguradoras também têm menos despesa pois os
clientes tem menor taxa de sinistralidade e tendencialmente existem menos sinistros fraudulentos,
para além de conseguirem fornecer o serviço através de canais digitais (computadores e dispositi-
vos móveis), poupando gastos com mediadores, balcões de atendimento ao público e oferecendo
uma experiência de utilização de maior qualidade.
O objetivo desta dissertação foi desenvolver uma prova de conceito de uma plataforma para
gestão de comunidades virtuais aplicada ao modelo PPI. Para isso, foram analisadas implementa-
ções atuais deste modelo de negócio, bem como, explorado o estado-da-arte das plataformas para
gestão de comunidades. A análise e especificação de requisitos recorreu à metodologia Design
Thinking, uma vez que a empresa também tinha interesse em estudar a eficácia desta ferramenta
nestas tarefas.
1.3 Estrutura da Dissertação
Esta dissertação é composta por 8 capítulos, além da presente introdução, sendo que o se-
gundo capítulo é dedicado à realização do estudo do estado da arte relativamente ao negócio das
seguradoras, sendo feito uma análise dos seus principais desafios, seguida de uma secção mais
especializada em seguros de saúde, onde são explicadas algumas especificidades deste tipo de
seguros, bem como alguns exemplos de inovação nesta área. Este capítulo encerra com a apresen-
tação do estudo sobre a temática do P2P Insurance, sendo apresentadas as várias variantes deste
tipo de seguros e as empresas a explorar esta ideia disruptiva na área dos seguros.
No terceiro capítulo é realizado um estudo sobre o estado da arte sobre as tecnologias exis-
tentes para o desenvolvimento, dando especial relevo a ferramentas que ajudem o programador a
acelerar o seu trabalho, sendo analisadas 3 conjuntos de tecnologias, as frameworks de desenvol-
vimento web, os sistemas de gestão de conteúdos ou CMS e as plataformas de desenvolvimento
rápido de aplicações ou ferramentas RAD.
O capítulo quatro é dedicado à apresentação da metodologia do Design Thinking, bem como,
à introdução das metodologias ágeis usadas nos projetos de inovação na Deloitte. Este capítulo
inicia com uma breve revisão bibliográfica, relativa à importância da utilização de métodos mais
criativos nos processos de engenharia de requisitos.
3
Introdução
O capítulo número 5 é dedicado á demonstração dos resultados obtidos com a aplicação das
ferramentas do Design Thinking e das respetivas conclusões recolhidas tanto a nível das funcio-
nalidades esperadas para a protótipo de P2P Health Insurance, como a nível da próprias técnicas
utilizadas.
No capítulo 6, é apresentada a visão do sistema que será refletido no protótipo, incluindo a
descriminação dos problemas e oportunidades descobertos, objetivos do sistema e as funcionali-
dades a implementar. Ao longo do sétimo capítulo, é apresentado o processo de construção do
protótipo, desde a arquitetura utilizada até ao produto final.
Esta dissertação termina no capítulo 8, sendo que este capítulo é utilizado para apresentação
das várias conclusões retiradas deste projeto, bem como, a apresentação das futuras etapas.
4
Capítulo 2
Indústria Seguradora e a Inovação
2.1 Introdução
Quando na antiga civilização chinesa, há sensivelmente 6 ou 7 mil anos atrás, os comerciantes
se uniram e começaram a distribuir as suas mercadorias pelos vários barcos, em vez de usarem
um único barco para transportar toda a sua mercadoria, garantindo assim, que sempre que um
barco naufragava havia uma perda reduzida para cada um dos comerciantes[Nas98], estes, com
certeza, que não imaginariam que a sua ideia se transformaria numa das maiores indústrias da
atualidade, sendo que no ano de 2013, segundo, esta indústria subscreveu prémios no valor de
cerca de 4,640,941 Milhões de Dólares [Hara].
O negócio das seguradoras, consiste na oferta de proteção sobre certos acontecimentos que de-
sejavelmente não irão ocorrer, previamente enumerados ou que são descobertos dentro do período
de cobertura, sendo que estas empresas geram lucro quando os valores dos sinistros existentes,
juntamente com os custos operacionais, são menores que o valor total dos prémios pagos pelos
clientes. Os prémios são calculados recorrendo a modelos estatísticos e probabilísticos, de forma
a garantir que este valor consegue cobrir os gastos com sinistros. As seguradoras dividem o seu
negócio em dois ramos de atividade, o ramo vida, que trata os seguros relacionados com os ris-
cos associados à perda da vida humana, e o ramo não-vida, que está associado com os restantes
infortúnios, que contempla os seguros de responsabilidade civil, automóvel, bens pessoais, entre
outros. No que respeita aos seguros de saúde, área sobre a qual esta dissertação se irá debruçar
mais, por norma pertencem ao ramo não-vida das seguradoras, porém em alguns países, como por
exemplo os Estados Unidos da América, pertencem ao ramo dos seguros vida, pois os seguros de
saúde e de vida estão intrinsecamente ligados.
Esta indústria, apesar de ser de enorme dimensão e de a tendência apontar para o crescimento
das empresas deste sector[LKSR16], não pode deixar de estar atenta às novas evoluções verifica-
das no campo tecnológico e consequentes mudanças comportamentais nos clientes. Nos últimos
anos, a tecnologia tem ajudado muitas empresas a mudar o paradigma das suas áreas de negócio.
5
Indústria Seguradora e a Inovação
Empresas como a Uber, AirBnB, ebay ou KickStarter, tem vindo, a mudar, respectivamente, a
forma como nos deslocamos, viajamos, compramos ou até procuramos investimento. Isto, leva a
que muitas organizações tenham, nos últimos anos, procurado formas de inovar nas suas indús-
trias, criando produtos que melhor servem as expectativas dos seus clientes, bem como melhoram
a sua eficácia operacional. Sendo assim, o sector segurador, não foge à regra e também tem vindo
a procurar novas formas de inovar, acompanhando assim, a enorme proliferação das novas tecno-
logias. Entre as várias ideias de negócio que tem vindo a surgir encontra-se a ideia que serve de
mote a esta dissertação, o “Peer to Peer Insurance” [BECC14].
Ao longo do presente capítulo, irá ser realizada uma análise sobre a importância da inovação
nesta indústria, seguindo-se de uma explicação mais detalhada sobre o que é o “Peer to Peer
Insurance” e de alguns exemplos de empresas que já operam seguindo este conceito de negócio.
2.2 Desafios da Indústria Seguradora
Ao contrário de muitas outras indústrias, os maiores desafios que a indústria seguradora tem,
não estão diretamente relacionados com a crise económica, apesar de desde 2008 ter-se verificado
a queda do volume de negócio principalmente nas seguradoras que operam nos países desenvol-
vidos [Hara]. Os grandes desafios da indústria seguradora estão relacionados com o risco que as
empresas mais tradicionais podem ter em relação ao surgimento de novos intervenientes nesta in-
dústria, ameaçando assim a sua quota de mercado, correndo assim o risco de se tornarem obsoletas
aos olhos dos clientes[BOA16].
O facto de muitos clientes terem ultrapassado algumas más experiências com as seguradoras,
tais como a não cobertura de um determinado sinistro, bem como, o facto de as expectativas dos
clientes estarem sempre além daquilo que é oferecido pelas empresas seguradoras [Boe11], levam
a um grau de insatisfação muito grande, abrindo assim, espaço para que novas ideias de negócio
surjam, de forma a fornecer um melhor serviço ao cliente. Estas novas formas de negócio, apro-
veitam as potencialidades fornecidas pela tecnologia, e conseguem providenciar um serviço mais
personalizado, rápido e, quase sempre, sem que o cliente tenha de se dirigir a qualquer lado, rea-
lizando as operações necessárias a partir do seu computador, telemóvel ou tablet, evitando assim
longas filas de espera, deslocações e consequentemente melhorando a experiência de utilização
deste.
Ao longo deste estudo identificados três grandes desafios que a indústria seguradora tem na
atualidade. O primeiro desses desafios é o surgimento de novas tecnologias e novas formas de
negócio, o segundo o surgimento de uma nova geração de clientes e, por último, o aumento da
concorrência entre as empresas seguradoras e a necessidade de diferenciação entre estas. Na
próxima secção, cada um desses desafios será analisado com maior detalhe, sendo apresentados
alguns exemplos de como as seguradoras tem respondido a estes desafios.
6
Indústria Seguradora e a Inovação
2.2.1 Novas tecnologias e novas formas de negócio
Os novos dispositivos que surgiram nos últimos anos, deixaram de fornecer apenas uma ex-
periência divertida, para se tornarem um elemento crucial para a perceção de qualidade do cliente
[Car15b]. Hoje em dia, os utilizadores utilizam o seu telemóvel para realizar variadas funções
para além das tradicionais chamadas e mensagens de texto, fazendo com que as empresas tenham
de apresentar soluções que aproveitem as potencialidades deste tipo de dispositivos. Segundo
[Car15b], em 2014, cerca de 24% dos adultos que utilizam a internet nos Estados Unidos da Amé-
rica, já geriam os seus seguros através do seu telemóvel. Portanto, para corresponder à crescente
exigência dos utilizadores, muitas empresas já estão a aumentar os seus orçamentos disponíveis
para investir em soluções novas para dispositivos móveis, cimentando a ideia que o negócio dos
seguros através de aplicações para smartphones, está a deixar de ser um investimento experimental
para começar ser uma opção necessária para as empresas [Car15b].
As empresas seguradoras procuram com estas soluções inovadoras, conseguir estabelecer uma
melhor relação com o cliente, fornecendo um serviço melhor e mais eficaz, mas também ajudando-
o a reduzir o risco das suas apólices. Por exemplo, a subsidiária francesa da seguradora AXA lan-
çou uma aplicação que tenta reduzir o risco de acidentes rodoviários lembrando o utilizador para
fazer pausas a cada duas horas, fornecendo um calculador de taxa alcoólica e também fornecendo
um localizador de hotéis e de táxis. Por outro lado, estas soluções também permitem às empre-
sas perspetivar a redução de alguns custos relacionados com o serviço ao cliente, permitindo às
empresas um contacto mais próximo com o cliente e simultaneamente mais barato [Car15b], dimi-
nuindo assim a rede de intermediários, que por um lado cobra grandes comissões e, por outro, tem
uma abordagem ao cliente não adaptada aos tempos modernos. De facto, as novas tecnologias,
poderão ajudar as seguradoras a revolucionar completamente o seu modelo de operar no mercado,
possibilitando que estas estejam muito mais próximas dos clientes e oferecer produtos melhores.
Outro ponto no qual as novas poderão ser utilizadas, é na venda dos produtos, uma vez que,
a quantidade de informação que é possível obter recorrendo aos dispositivos móveis e os dados
partilhados pelas pessoas nas redes sociais, permitem que seja possível oferecer um produto muito
mais personalizado, que cobre os riscos necessários, retirando coberturas desnecessárias, dimi-
nuindo o preço da apólice e, consequentemente, aumentado a satisfação do cliente. Por exemplo,
em Portugal, a companhia de seguros Ok! Teleseguros[Dcd15], lançou uma aplicação, que acon-
selha o condutor para uma condução mais segura e confortável, calculando através dos vários
sensores do smartphone, a velocidade, o modo de aceleração e a forma de travagem. Deste modo,
a empresa não está só a possibilitar ao condutor uma ferramenta útil, que o ajudará a mudar o seu
perfil de condução, mas também está a recolher importantes dados, que poderão no futuro ser usa-
dos para o cálculo de uma nova simulação do seguro, agravando ou atenuando o prémio consoante
o comportamento do condutor.
Tendo isto em vista, nos próximos anos a indústria seguradora terá de colocar especial atenção
no desenvolvimento de aplicações/soluções para esta nova gama de dispositivos, aplicações estas
que deverão para além de permitir ao cliente realizar as operações básicas inerentes a uma apólice,
7
Indústria Seguradora e a Inovação
como por exemplo consulta de dados ou registro de um sinistro, ter outras funcionalidades extra
que permitam ao cliente ter uma melhor experiência com a seguradora e simultaneamente diminuir
o risco inerente às suas apólices.
2.2.2 Nova geração de utilizadores
Outro desafio, que poderá colocar em risco os intervenientes mais tradicionais da indústria
seguradora, é o facto de estar a surgir uma nova geração de utilizadores, que esta poderá não estar
compreender bem. As gerações mais novas, pessoas com menos de 36 anos, são a primeira geração
que cresceu com os computadores à sua volta e por isso merecem uma especial atenção, pois os
seus comportamentos e expectativas são diferentes em relação às gerações anteriores. Estas novas
gerações são normalmente apelidadas de millennials pois toda a sua vida profissional/adulta se
realizou após o virar do milénio.
Esta nova geração de clientes está a fazer com que as empresas se tenham de adaptar às suas
exigências e expectativas, pois esta geração no futuro representará uma fatia muito considerável
entre os clientes totais da empresa. Aliás, a questão com a geração dos millennials, já não está
apenas relacionada com o futuro, já é parte do presente, pois em 2015 nos Estados Unidos da
América, a população ativa desta geração ultrapassou pela primeira vez as outras duas gerações
mais velhas[GVJ+16]. Mas porque é que a indústria seguradora deverá ter especial atenção a esta
geração em detrimento das anteriores?
O motivo pelo qual as empresas em geral e o sector segurador em particular deverão estar
atentos a esta nova geração de utilizadores, prende-se com o facto de esta geração ser diferente
das anteriores e acima de tudo esperar produtos e soluções diferentes que as gerações mais velhas.
Esta nova geração tem muito mais afinidade pelas novas tecnologias e espera sempre soluções
novas que facilitem a sua experiência de utilização com um determinado produto. De facto, esta
nova geração é muito mais recetiva a novas tecnologias comparando com as gerações anteriores.
Segundo Gownder [GVJ+16], cerca 64% dos indivíduos desta geração responderam que gostam
de tecnologia, o que comparado com as gerações mais velhas (entre 36% e 27%), é um número
consideravelmente maior. Para além desta geração ter uma maior afinidade pela tecnologia, esta
geração é muito mais aberta a novas formas de negócio, nomeadamente ao uso de economias de
partilha e à utilização das redes sociais, o que podem ser um novo lugar para a concretização de
novos negócios e novas oportunidades para as empresas. Por exemplo, modelos de negócio como
o Uber, AirBnB ou o ebay, tem uma taxa muito maior de utilização entre as gerações mais novas
do que entre as mais velhas[KKP]. Outro ponto curioso em relação a esta geração e na maneira
como se relacionam com a indústria financeira, é o facto desta geração ter pouca confiança nas
instituções tradicionais, confiando mais em empresas como a Amazon ou a Google [Coc16], tendo
portanto uma relação de pouca fidelização com os intervenientes mais tradicionais, o que pode
representar uma oportunidade e uma ameaça para estes.
Esta geração, normalmente, procura produtos mais baratos, talvez por terem uma condição
económica mais débil que os seus antepassados[GVJ+16] ou por esta geração ter maior consci-
ência financeira e maior conhecimento sobre esta área, uma vez que muitos viram os seus pais a
8
Indústria Seguradora e a Inovação
ter dificuldades durante a crise que iniciou em 2008, tendo retirado lições para não repetir os seus
erros [Car15a]. Tendo isto em conta, esta geração procura por soluções simples, que sejam efica-
zes e que não os obriguem a perder tempo com procedimentos complexos, longas listas de regras
e condições ou longos tempos de espera para obter um determinado produto, procurando também
soluções que sejam imediatas e que forneçam uma rápida resposta às suas solicitações[Car15a].
Outras duas condições que os millennials buscam quando adquirem um produto, é o facto de
estes permitirem que eles sejam independentes no seu uso, isto é, que não tenham que recorrer a
nenhum serviço externo para conseguir realizar a transação e que a possam realizar por si, quando
bem entenderem, procurando por ajuda quando assim necessitam. A outra condição, relacionada
com a anterior, prende-se com o facto de esta geração também pretender realizar essas transações
em qualquer ponto e com qualquer dispositivo[Car15a], nomeadamente através dos seus disposi-
tivos móveis ou computadores.
No caso do sector financeiro, no qual se incluem as seguradora, é ainda ter atenção o facto desta
geração valorizar muito a transparência dos serviços e preços que lhe são fornecidos[GVJ+16],
algo que o sector segurador não tem conseguido alcançar. Isto leva a que esta geração seja relutante
a confiar em instituições financeiras, criando assim uma maior distância entre este sector e as novas
gerações de utilizadores. Logo, se as empresas deste sector pretendem se aproximar deste grupo
de utilizadores, deverão ter especial atenção à forma como explicam os seus produtos e como
criam uma relação de confiança com o cliente.
Portanto, esta nova geração procura novas soluções que contenham estes quatro aspetos. Pro-
curam soluções que sejam simples e imediatas, que lhes permitam ser independentes, que permi-
tam o acesso em qualquer parte e acima de tudo que lhes forneça uma relação de transparência.
Tendo isto em conta, as seguradoras devem procurar incorporar estes aspetos nas soluções que
desenvolverem no futuro.
2.2.3 Aumento da Concorrência e necessidade de inovação
O mercado das seguradoras é altamente competitivo, existindo inúmeras empresas a tentar
aumentar o seu volume de negócios de ano para ano. Isto leva a que seja crítico para as empresas
que inovem nos produtos que fornecem aos seus clientes, para que consigam captar mais clientes,
continuando a manter os clientes antigos. Com este objetivo, têm vindo a surgir produtos no
sector segurador que tentam aproveitar inovar na forma como se gere a relação com o cliente, bem
como, na forma como o seguro é comercializado. Assim, as empresas deste sector têm tentado
através das novas tecnologias aumentar a sua quota de mercado entre as gerações mais novas,
aproveitando os últimos avanços nas áreas de Big Data e Internet Of Things[Cap15], e também
a crescente popularidade das redes sociais que possibilitam a criação de economias de partilha.
Contudo, o sector segurador é um dos que historicamente tem evoluído mais lentamente, muito
devido ao facto do seu negócio estar intrinsecamente construído sobre princípios de estabilidade e
aversão ao risco[KKP].
Um dos exemplos desta diferenciação são os seguros automóveis que permitem ao utilizador
pagar somente pelos quilómetros que anda, tendo um preço mais baixo caso a quilometragem seja
9
Indústria Seguradora e a Inovação
baixa e mais alto no caso oposto [Cap15]. Outro exemplo, é o uso de Internet Of Things para
reduzir o risco sobre apólices de seguros sobre imóveis, monitorizando os dados sobre os sensores
instalados no imóvel, permitindo, que caso exista algum sinistro, que este seja detetado com muito
maior rapidez [BC14], podendo, possivelmente minimizar os danos causados. No caso dos seguros
de saúde, têm surgido aplicações que incentivam o utilizador a ter comportamentos mais saudáveis,
tais como, praticar exercício físico com moderação e a ter uma alimentação saudável, fornecendo
um preço mais baixo quando os dados de saúde são melhores[Boe11].
Outro conceito que tem surgido também, é a gamification, que tenta levar os clientes de um se-
guro a terem comportamentos de menor risco, através da criação de uma dinâmica de competição
entre os vários membros dessa comunidade de clientes, atribuindo prémios aos vencedores. Por
exemplo, no caso de um seguro automóvel, as seguradoras, através de uma aplicação para dispo-
sitivos móveis, podem recolher dados sobre o perfil de condução dos seus clientes, atribuindo um
prémio ao condutor com o perfil de condução que apresentar menos riscos. O resultado esperado
desta ideia, é que um grande número de clientes dessa seguradora, melhorem os seus hábitos de
condução, reduzindo, consequentemente, os riscos associados às apólices de um grande grupo de
clientes.
O tema que serve de mote a esta dissertação, o Peer to Peer Insurance, é também uma destas
novas abordagens que tem vindo a ser explorada pelas seguradoras, existindo alguns operadores
que já exploram esta ideia de seguro baseado na comunidade. No entanto, este tema será abordado
numa secção um pouco mais à frente nesta dissertação.
Visto isto, podemos concluir que existem muitas ideias que estão a inovar no mercado segura-
dor e apesar de estas tecnologias e novas formas de negócio ainda estarem numa fase muito inicial
e da sua taxa de penetração ser ainda muito baixa [Cap15], é necessário que as empresas do sector
segurador tenham especial atenção a estes novos intervenientes e simultaneamente consigam in-
troduzir algumas destas ideias disruptivas nos seus processos de venda de forma a cativarem novos
clientes.
2.3 Seguros (d)e Saúde
Os cuidados de saúde tem vindo a evoluir ao longo do tempo, contudo, por vezes, os cuidados
de saúde apresentam custos para o doente, que muitas vezes, este não consegue suportar. No en-
tanto, as pessoas não querem deixar de ter acesso aos mais avançados tratamentos, medicamentos
e especialistas, sempre que necessitam. Isto levou a que surgisse uma oportunidade para as segu-
radoras, uma vez que um grande número de pessoas estaria disposta a desembolsar uma quantia
mensal ou anualmente, de forma a proteger-se contra eventuais problemas relacionados com a
sua saúde. Assim, surge a área dos negócios dos seguros de saúde, garantindo àqueles que a eles
recorrem, proteção sobre um conjunto de riscos relacionados com a saúde.
Ao longo desta secção, irão ser analisadas algumas particularidades deste tipo de seguros e
quais os processos tradicionais inerentes a este tipo de produtos, bem como, algumas inovações
10
Indústria Seguradora e a Inovação
que têm vindo a ser introduzidas nos últimos anos, tanto na área dos seguros de saúde como nos
serviços de saúde em geral.
2.3.1 Os desafios dos Seguros de Saúde
O primeiro grande desafio que as seguradoras de saúde têm, é o facto de cobrirem despesas
relacionadas com saúde, tornando todos assuntos muito sensíveis, tanto para o lado da seguradora
como para o lado do cliente. Isto é, caso ocorra um determinado sinistro não que esteja contem-
plado na apólice do cliente, a saúde do cliente pode ser colocada em causa, criando uma situação
de desconforto tanto para o cliente, como para a seguradora que passa a ter um cliente insatisfeito,
podendo inclusivamente colocar em causa a reputação e imagem da mesma. Sendo assim, um dos
grandes desafios dos seguros de saúde é conseguir garantir ao cliente que todos os possíveis even-
tos inesperados que lhe possam acontecer, são cobertos pela apólice, pelo menor preço possível,
para que o cliente consiga suportar esse custo mensal ou anual.
Para além do desafio apresentado no parágrafo anterior, outro ponto onde os seguros de saúde
se destacam dos demais, tem a ver com o facto de, por norma, serem produtos onde existe uma
maior taxa de sinistralidade. Enquanto nos seguros automóvel e de propriedade, por exemplo,
os sinistros são esporádicos no caso dos seguros de saúde isso não acontece. Segundo um artigo
da revista Forbes[McC14], em média cada cidadão americano e alemão, recorre a um médico,
respetivamente, 4.1 e 9.7 vezes ao ano. Por outro lado, em média, cada pessoa só preencherá
um requerimento devido a um acidente de carro a cada 17.9 anos[Des11]. Este facto leva a que
o acompanhamento dos clientes de seguros de saúde tenha de ser muito maior, do que quando
comparado a um seguro automóvel, uma vez que os clientes de um seguro de saúde irão precisar de
entrar muitas mais vezes em contacto com a sua seguradora de saúde, do que com a sua seguradora
automóvel. Assim, as seguradoras de saúde deverão ter muito mais atenção ao serviço que é
prestado aos seus clientes, otimizando a experiência de utilização do mesmo, de forma a garantir
a máxima satisfação possível, uma vez que ele terá, inevitavelmente, de recorrer aos seus serviços
variadas vezes.
À alta taxa de sinistralidade junta-se ainda um problema gerado pela falta de ética profissi-
onal e alavancado pela sensibilidade especial deste tipo de seguros, como vimos anteriormente.
Sempre que um paciente entra num prestador de cuidados médicos com determinados sintomas,
o prestador de cuidados médicos poderá levar o paciente a realizar mais tratamentos/exames de
diagnóstico do que realmente são necessários. Estas situações de fraude são muito difíceis de pro-
var, uma vez que, o doente quer recuperar da situação em que se encontra e, por outro lado, é um
assunto muito sensível colocar em causa a ética de um profissional de saúde. A fraude nos seguros
de saúde é combatida, sobretudo, recorrendo a profissionais de saúde independentes que realizam
esporadicamente algumas visitas para verificar se os serviços que estão a ser declarados às segu-
radoras, são realmente aqueles que estão a ser prestados e, simultaneamente, são os serviços que
os pacientes estão a necessitar. Outro mecanismo que também é usado para combater este tipo de
fraude, são as parcerias que as seguradoras estabelecem com os prestadores de serviços de saúde,
criando uma situação de ganho para as duas partes, através de uma relação de confiança, pois a
11
Indústria Seguradora e a Inovação
seguradora combate o excesso de despesa desnecessária e o prestador ganha a possibilidade de ter
mais pacientes.
Por último, outra característica dos seguros de saúde está relacionada com o facto de muitas
pessoas só terem um seguro de saúde, devido a este ser providenciado pela entidade patronal, o
que leva, muitas vezes, as pessoas a não terem grande escolha no seu seguro saúde, tendo que ficar
com as condições que foram negociadas pela empresa aquando da contratação da apólice coletiva
de seguro de saúde. Isto poderá levar a uma insatisfação dos clientes e também limita a capacidade
de escolha destes, mesmo havendo produtos melhores e mais adequados no mercado a que ele não
pode recorrer [Boe11].
2.3.2 Ter um seguro de Saúde
Como vimos na secção anterior, os seguros de saúde tem uma série de especificidades que os
tornam únicos e, por isso, ao longo desta secção, irão ser analisados os vários momentos da jornada
de utilização de uma cliente com um seguro de saúde tradicional, bem como alguns conceitos
chave da gíria dos seguradores.
Quando um cliente decide que quer recorrer a um seguro de saúde, o primeiro passo a dar
é pedir uma simulação a um agente de seguros ou então dirigir-se aos websites disponíveis de
algumas seguradoras, usando por vezes motores de busca ou agregadores para encontrar as segu-
radoras com melhores condições. Após fornecer alguns dados, o cliente recebe uma proposta, ou
várias, de um possível seguro de saúde, escolhendo aquele que melhor se adequa às suas neces-
sidades, expectativas e possibilidades. Depois de escolher, é necessário acrescentar mais alguns
dados e posteriormente pagar, sendo que o seguro passará a ser válido após o pagamento do pré-
mio. Aquando do pagamento, o cliente já terá em sua posse as condições gerais e específicas do
seu seguro, que indicam quais as coberturas que a apólice tem.
Após o seguro ser ativado, o segurado poderá recorrer a cuidados médicos, contudo caso nas
condições da apólice estiver contemplado um período de carência, o cliente terá de esperar até ao
fim desse período para poder usufruir das vantagens do seguro de saúde. Este período é criado
para evitar que clientes criem seguros de saúde para cobrir um determinado sinistro que é anterior
à contratação do seguro. Sempre que o cliente quiser aceder a serviços de saúde, pode optar
por recorrer a prestadores dentro da rede de prestadores de serviços parceiros da sua companhia
de seguros ou pode optar por um prestador fora da rede, contudo a maior parte das seguradoras
tende a beneficiar quando os clientes utilizam prestadores da rede parceira. Por exemplo, na
Medis, sempre que o paciente necessita de hospitalização, se for dentro da rede de prestadores
paceiros o seguro cobre 100% das despesas e se for fora da rede cobre apenas 30%. É importante
ainda referir que, sempre que o cliente recorre a serviços fora da rede de serviços, obriga a que
este tenha de submeter as faturas do serviço prestado para que a seguradora lhe possa devolver o
dinheiro correspondente à comparticipação do seguro, no entanto, este processo costuma ser muito
burocrático e demorar muito tempo, desencorajando, ainda mais, os clientes a recorrer a serviços
fora da rede. Sendo assim, o cliente sempre que precisar de um certo cuidado médico, deverá
procurar ajuda junto da sua seguradora de forma a encontrar um prestador.
12
Indústria Seguradora e a Inovação
Figura 2.1: Simulação de apólice no website da Lusitania seguros
Portanto, os processos inerentes a um seguro de saúde são basicamente a simulação da apó-
lice, contratualização e pagamento da mesma, e após estes dois, são a procura por prestadores de
serviços de saúde e reclamação de despesas, caso o prestador em questão não tenha acordo com a
seguradora.
2.3.3 Inovação nos Seguros de Saúde
Apesar de a indústria seguradora ter alguma dificuldade em evoluir com a velocidade que seria
desejável, tal como vimos na primeira secção deste capítulo, existem alguns exemplos de segu-
radoras que têm evoluído, de forma a acompanhar as expectativas dos seus clientes ou potenciais
clientes. Ao longo deste capítulo, iremos analisar 3 seguradoras e a adaptação de cada uma às
novas tecnologias, sendo que as primeiras duas operam no mercado de Portugal e a última, opera
no mercado Norte-Americano. O objetivo de realizar esta análise é demonstrar de que forma as
empresas seguradoras tem vindo a integrar as novas tecnologias nos vários processos inerentes ao
seu serviço.
A primeira companhia de seguros analisada, será a Lusitânia Seguros [LUS], empresa per-
tencente ao Grupo Montepio, que se encontra no mercado segurador há mais de 25 anos. Após
navegar um pouco no website desta empresa, conseguimos facilmente chegar ao simulador de se-
guros de saúde. Após a introdução do nome, do número de telefone e idade, é possível aceder a
uma simulação de prémio de seguro, contudo, caso o cliente queira prosseguir com a subscrição do
13
Indústria Seguradora e a Inovação
Figura 2.2: Exemplos de ecrãs da aplicação para dispositivos móveis da Médis
seguro, o site tenta encaminhar o cliente para a duas situações: fornecer alguns dados e aguardar
ser contactado por um operador da seguradora, ou consultar a rede mediadores desta companhia e
ter acesso aos mais próximos.
A gestão dos sinistros e procura de profissionais de saúde dentro da rede da seguradora, é feita
através de um portal de gestão deste tipo de seguros de saúde a AdvanceCare [ADV], empresa
especializada na criação de portais de gestão de sinistros, que fornece um portal, onde os clientes
das seguradoras podem realizar as várias atividades relacionadas com o seu seguro de saúde. Tal
como a Lusitania, outras seguradoras usam este sistema, tais como, a Açoreana, a LOGO e a
ENSA.
A segunda empresa analisada foi a Médis [MED], uma companhia de seguros que opera no
mercado português desde 1996 e que dá especial relevo à sua presença nos vários meios digitais.
Tal como a maioria das empresas a atuar no sector dos seguros de saúde, a Médis, também fornece
a possibilidade de simulação online. O motivo pelo qual a Médis destaca entre as várias segurado-
ras em Portugal, é pelo facto de permitir que o processo de subscrição poder ser feito, praticamente
todo, através do computador, tendo o cliente apenas que imprimir alguma documentação e digitali-
zar posteriormente. Esta companhia destaca-se ainda pela sua aplicação para dispositivos móveis,
onde o cliente pode gerir seu seguro, desde consultar anteriores sinistros, até pesquisar por mem-
bros de prestadores de serviços dentro da rede Médis, oferecendo uma funcionalidade que procura
Tabela 2.1: Análise comparativa das várias seguradoras
Seguradora SimulaçãoOnline
SubscriçãoOnline
Gestão deSinistrosOnline
AplicaçãoMobile
Consultasmédicasremotas
Lusitania Sim Não Sim Não NãoMédis Sim Sim* Sim Sim Não*Oscar Sim Sim Sim Sim Sim
14
Indústria Seguradora e a Inovação
Figura 2.3: Comparação entre a vista geral do plano de saúde das companhias Oscar e Médis
os prestadores de serviço mais próximos da área onde o cliente se encontra. Recentemente, a Mé-
dias apresentou uma linha de apoio ao cliente, na qual profissionais de enfermagem encaminham
o cliente para o serviço de saúde adequado.
Por último apresento, o Oscar [OSC], empresa fundada em 2013 e que opera no mercado
dos Estados Unidos da América. Esta start-up visa a aproveitar ao máximo as potencialidades
que a tecnologia fornece de forma a providenciar um serviço mais cómodo, mais barato e muito
focado na nova geração de utilizadores. Esta seguradora tem toda a sua actividade focada nos
meios digitais, não tendo qualquer balcão tradicional aberto, possuindo apenas uma linha de apoio
ao cliente. As funcionalidades que mais se destacam é o facto de permitir atendimento médico
remotamente 24 sobre 24 horas e a integração com wearables, permitindo ao cliente rastrear a sua
atividade física.
Esta companhia de seguros é dada como exemplo a seguir no campo das seguradoras digitais
[BC14] e de sucesso entre a geração dos millenials. Esta seguradora para além de fornecer uma
solução focada nos meios digitais, também se preocupa com a forma como a informação é trans-
mitida ao cliente, tentado criar o máximo de transparência possível, usando infografias e tabelas de
simples leitura. Esta seguradora preocupa-se também em simplificar ao máximo todo o processo
de subscrição e reduzir os custos para o cliente final.
A tabela anterior, sumariza a informação recolhida ao longo deste estudo sobre o grau de pre-
sença nos meios digitais das três seguradoras analisadas e a figura 2.3 mostra algumas diferenças
entre a apresentação do plano de saúde oferecido pela Médis e pelo Oscar.
2.4 Peer to Peer - A comunidade em ação
A Internet evoluiu e deixou de ser apenas um lugar onde podíamos consultar informação, para
um lugar onde podemos partilhar informação e criarmos o nosso próprio conteúdo [AL08]. Os
utilizadores deixaram de ser apenas espectadores e passaram a poder ser criar conteúdos, parti-
lhar informações ou juntarem-se em comunidades colaborando uns com os outros. Assim surgiu
a possibilidade de desenvolvermos projetos em conjunto, utilizando por exemplo o Github, ou
15
Indústria Seguradora e a Inovação
partilharmos conhecimento através de Wikis, como por exemplo na Wikipedia[HU15]. As comu-
nidades foram evoluindo e muitas plataformas foram surgindo com o passar do tempo, até que
passaram a fazer parte do cotidiano das pessoas. Plataformas como o Facebook, Google, Twitter
ou AirBnB, passaram a fazer parte dos nossos dias a dias, levando a que as empresas tenham que
estar especialmente atentas ao desenvolver destas.
Em 2013, a revista Forbes estimou que a receita originária de plataformas de economia par-
tilhada (apenas no que diz respeito a plataformas de consumo colaborativo, tais como AirBnB ou
BlaBlaCar), se fixa em cerca de 3.5 milhares de milhão de dólares americanos, levando a que
muitos investidores estejam a aplicar centenas de milhões de euros em empresas que exploram
este modelo de negócio, tornando assim a economia partilhada numa das maiores tendências dos
próximos anos [HU15]. Alguns autores afirmam que o sucesso deste tipo de plataformas se deve
ao facto de todas se preocuparem pela direta beneficiação do cliente, bem como, a promoção de
comportamentos mais sustentáveis e consequentemente mais amigos do ambiente. Claro, que o
sucesso destas plataformas, também está diretamente ligado ao facto de levarem o cliente a con-
seguir economizar algum dinheiro e facilitarem o acesso a certos recursos [HU15].
Hoje em dia, as comunidades da internet vão cada vez mais longe e começam a formar concei-
tos de negócio que vão muito para além daquilo que estamos habituados, possibilitando à comu-
nidade a hipótese de investimentos coletivos (crowdfunding) e outras soluções de P2P Lending,
tais como o Kiva, que possibilita a comunidade de se unir para fornecer micro-crédito a outros
membros.
De facto, as plataformas que têm surgido na internet têm modificado, cada vez mais, a forma
como realizamos as mais variadas tarefas na nossa vida e para a indústria seguradora é importante
analisar como é que estas tecnologias poderão ser utilizadas como alavanca para a inovação num
dos setores mais tradicionais do mercado. Uma das ideias que tem sido discutida, que visa a
aproveitar o sentido de comunidade estabelecido pelo Peer to Peer, de forma a inovar no setor
segurador é o P2P Insurance, que aproveita a criação de comunidades online, para partilhar o
risco das apólices de seguros e simultaneamente promover algumas poupanças entre os membros.
2.4.1 Peer to Peer na Saúde
O P2P na área de saúde, corresponde a grupos de pessoas que se juntam, utilizando os meios
de comunicação para formar comunidades virtuais, com o desejo de realizarem atividades relaci-
onadas com a saúde ou com a educação para a saúde [DD16]. De entre as atividades que podem
ser realizadas, incluem-se o fornecimento de cuidados de saúde, nomeadamente a realização de
consultas utilizando videoconferência, partilha de informação e documentos, assim como, a sensi-
bilização/educação dos pacientes para comportamentos mais saudáveis. Recorrendo a estas novas
tecnologias, os pacientes conseguem obter um serviço mais adequado por parte dos prestadores de
cuidados de saúde, pois a partilha de informação é muito mais frequente, o que permite uma me-
lhor monotorização dos dados de saúde, e, ao mesmo tempo, mais rápido, uma vez que, o contacto
16
Indústria Seguradora e a Inovação
com o médico poderá estar à distância de um clique. É ainda também possível obter mais infor-
mação sobre os comportamentos corretos que devem adotar de forma a evitar certos problemas de
saúde.
Alguns exemplos de comunidades online na área de saúde são expostos em [DD16], entre os
quais, o apoio a pacientes com asma, através da monitorização de sinais do utilizador, que permite
a deteção precoce e a intervenção adequada, bem como a criação de alertas especializados para
prestadores de cuidados de saúde sempre que seja necessária uma intervenção mais célere. Outro
caso de uso de comunidades online para a ajuda de pacientes, é o da utilização de uma aplicação
web que permite aos pacientes de cancro que estão a realizar quimioterapia, reportarem os seus
sintomas que vão tendo, levando assim os médicos a criarem planos de mais personalizados e,
consequentemente, uma melhoria nos cuidados médicos prestados.
Outro ponto interessante, também referido em [DD16], é o facto de em Maio de 2005, existi-
rem cerca de 68000 grupos relacionados com saúde e bem-estar na plataforma "YaHoo!Groups",
o que nos leva a concluir que as pessoas recorrem à internet quando querem recolher informações
sobre saúde e assim optarem por comportamentos mais saudáveis. Portanto, é pertinente analisar
de que maneira, um futuro sistema de P2P Insurance dedicado à área de saúde, poderá incluir
certas funcionalidades que explorem estas potencialidades que as comunidades virtuais fornecem
no campo da saúde.
2.5 Peer to Peer Insurance
Por norma, os seguros funcionam de uma forma muito tradicional, com os canais de venda
também eles muito tradicionais. Se quisermos adquirir um seguro, podemos recorrer a um inter-
mediário de um grupo segurador, ou então podemos adquirir contactando diretamente a segura-
dora, através de websites, linhas telefónicas de venda ou ainda, mais raramente, através de uma
aplicação para dispositivos móveis. O Peer to Peer Insurance, inova pois introduz um novo con-
ceito de venda de seguros diferente do tradicional e ao mesmo tempo aproveita as potencialidades
que as redes sociais e das economias de partilha fornecem. Apesar de ainda ser considerada uma
ideia disruptiva e da sua quota de mercado ser muito residual, o Peer to Peer Insurance é uma
das ideias que é apontada em diversas publicações [Del15, Cap15, BC14], como sendo uma das
grandes tendências no setor segurador para os próximos anos.
O modelo P2P Insurance é uma forma inovadora de comercializar seguros que permite que
as pessoas se unam em comunidade e consigam partilhar o risco de uma determinada apólice de
seguros. Caso não exista nenhum sinistro, os membros dessa comunidade recebem o montante,
ou parte dele, que inicialmente pagaram. Se ocorrer algum sinistro, o dinheiro que foi pago pelos
membros no início, cobre o valor do sinistro [Del15]. Contudo, podem haver algumas variações
e, mais à frente, iremos analisar as várias formas como se pode implementar este conceito.
As grandes vantagens desta nova forma de seguros são: a fácil gestão de sinistros de pequena
dimensão, uma vez que as plataformas automatizam este processo, diminuindo também a taxa
de sinistralidade, visto que os clientes são motivados a reduzir esta para seu benefício, e ainda
17
Indústria Seguradora e a Inovação
fornecimento de um serviço mais transparente ao cliente, sobre o qual este tem mais controlo.
Outras vantagens, neste caso para as seguradoras, prendem-se com o facto do estabelecimento de
um sentido de comunidade, possa levar a que existam menos situações de fraude, pois, as pessoas
tendem a enganar menos os seus colegas/amigos do que as grandes empresas, e, por outro lado,
o facto de os clientes servirem como meio de divulgação dos produtos da seguradora, atraindo
pessoas para a plataforma, reduzindo assim os custos com mediação, marketing e angariação de
clientes. Por fim, referir que a grande vantagem subjacente a estas plataformas, é o facto de tanto
o cliente como a seguradora conseguirem obter e prestar, respetivamente, um serviço mais barato,
pois para o cliente existe a possibilidade de reaver algum do dinheiro investido no início da apólice
e, para as seguradoras, como a taxa de sinistralidade tende a ser menor, assim como, o número de
intermediários e gastos de operação tenderem também a ser menores, estas terão também menor
despesa com os clientes [Ber16a].
Em termos de desvantagens, o modelo P2PI pode sofrer devido à inércia dos clientes em
mudarem, principalmente numa área onde as mudanças podem acarretar muitos problemas. Por
outro lado, o facto de as pessoas terem um seguro em conjunto, leva a que tenham que partilhar
informação com a comunidade, o que poderá levar muitos clientes a se sentirem desconfortáveis
com esta situação. As questões regulatórias são outro ponto no qual o modelo de P2PI, pode
levantar algumas questões, pois as empresas que exploram esta ideia de negócio terão de provar
que não existem quaisquer riscos de haver um determinado sinistro e de não haver capacidade de
o cobrir. Por último, o facto de este modelo de negócio ser algo complexo pode levar a que muitos
clientes desistam dele, pois os clientes não estarão interessados em colocar o risco de determinados
sinistros num modelo que eles não compreendem [BECC14].
Atualmente, já existem alguns intervenientes que exploram esta ideia de negócio, nomeada-
mente, o InsPeer, o Guevara, o P2P Cover, o FriendSurance, Lemonade, contudo existem algu-
mas variantes de explorar este modelo de negócio [Ber16a]. Ao longo das próximas secções, serão
apresentadas as variantes que existentes do modelo de P2PI e as empresas que implementam essas
mesmas variantes.
2.5.1 Atuar como um intermediário
A Friendsurance [FRI] é uma empresa alemã, lançada em 2010 e é considerada um dos pio-
neiros no que diz respeito ao P2P Insurance. A sua forma de atuação é parecida com a forma de
vender seguros de um intermediário ou mediador. Esta empresa fornece a possibilidade aos utiliza-
dores de se unirem em grupo e comprarem seguros em conjunto. Quando a empresa vende um se-
guro a uma comunidade, esta compra um seguro a uma empresa seguradora, contudo uma pequena
parte do prémio de cada membro do grupo é colocado de parte para cobrir os sinistros de pequena
dimensão. Se, no final do ano, ainda houver dinheiro no fundo coletivo, este é dividido pelos
membros do grupo, ou pode ser usado para o pagamento de uma nova apólice[BECC14, Ber16a].
Este modelo de operar, tem sido reconhecido como o mais estável e que acarreta menos riscos
para o cliente, pois apenas os sinistros mais pequenos são assumidos pelo fundo coletivo e caso o
18
Indústria Seguradora e a Inovação
fundo coletivo esteja esgotado, a empresa seguradora à qual foi feita a apólice é chamada a cobrir
o risco desse mesmo sinistro.
Esta forma de seguro permite uma pequena poupança aos clientes, caso o número de sinistros
seja pequeno, e simultaneamente promove uma relação de confiança entre os membros da comu-
nidade, pois os membros não vão reclamar falsos sinistros pois querem usufruir do desconto e, por
outro lado, tendencialmente as pessoas não enganam os amigos tão gravemente como enganam as
seguradoras. Por isto, a Friendsurance é de entre as empresas que exploram o P2P Insurance é
a que tem o modelo mais estável [BECC14] e que tendencialmente terá menos problemas relaci-
onados com as instituições regulatórias, contudo a poupança que permite aos seus clientes não é
muito grande.
2.5.2 Comunidade e Seguradoras
A empresa inglesa Guevara [GUE], anteriormente chamada de jFloat, ao contrário da Friend-
surance, aplica mais a fundo o conceito de Peer to Peer Insurance. Segundo o modelo de negócios
desta empresa, os utilizadores unem-se em grupos de grande dimensão (cerca de 100 pessoas)
e o prémio pago por cada cliente é dividido entre o fundo da comunidade e uma percentagem
que é fornecida a empresas seguradoras para cobrir sinistros com valores maiores. A Guevara
reserva cerca de 80% do valor pago pelo cliente para os sinistros mais regulares e com os restantes
20% contrata apólices para cobrir os sinistros com valores mais elevados e probabilidades mais
pequenas[BECC14, Ber16a].
Depois, tudo se desenrola de uma forma muito semelhante ao Friendsurance, sendo que no
caso desta empresa, o fundo comunitário é utilizado com maior frequência pois este é de maior
dimensão. Assim é possível a esta empresa fornecer um maior desconto aos seus clientes. No
entanto, esta empresa está atualmente a tentar demonstrar às entidades reguladoras que o seu
modelo de gestão dos riscos é eficiente e que não existe o possibilidade de um cliente ficar sem
cobertura de seguro caso os fundos se esgotem.
2.5.3 Baseado na Comunidade
Até agora foram analisados dois modelos que envolviam empresas seguradoras de forma a
serem estas a assumirem os sinistros quando os fundos não eram suficientes. Contudo existem
empresas que exploram muito mais o conceito de Peer to Peer. É o caso da empresa da Nova
Zelândia, a PeerCover[PEE], que tem um modelo de negócio completamente inovador e que rasga
com todos os conceitos que temos sobre seguros, levantando consequentemente muitos mais pro-
blemas com as instituições regulatórias[BECC14].
No modelo praticado por esta empresa, os utilizadores não pagam nenhum valor ao início e,
sempre que é registrado um sinistro, os membros do grupo votam para saber se o grupo irá cobrir
esse sinistro. Caso o grupo vote positivamente, a despesa desse sinistro é dividida pelos membros
dessa comunidade, e se for negativa, o sinistrado terá de assumir o valor do sinistro sozinho.
19
Indústria Seguradora e a Inovação
Este modelo acarreta grandes riscos para o utilizador e assenta numa base de confiança entre
os membros da comunidade, contudo levanta muitas questões relativamente à regulação, daí ser de
muito difícil aplicação em países fortemente regulados, como os pertencentes à União Europeia,
nomeadamente Portugal.
2.6 Conclusões
A indústria seguradora, embora seja muitas vezes rotulada como sendo muito tradicional e
conservadora, tem feito um grande investimento de forma a se expandir para os meios digitais e
aumentar a sua presença e visibilidade entre as gerações mais novas, existindo muitas empresas
que oferecem serviços dentro dos seus produtos, claramente criados para atrair uma geração nova
de utilizadores, como é o caso do Oscar ou até da seguradora portuguesa Médis. No entanto,
existem ainda muitas capacidades tecnológicas por explorar, de maneira a que as seguradoras
consigam oferecer melhores condições aos seus clientes, tanto a nível de preço final mas também
a nível do serviço que é prestado.
O modelo P2PI, decerto que é uma forma de vender seguros que muda completamente a forma
como os clientes estão habituados a comprar seguros, porém, as vantagens que poderá trazer,
tanto aos clientes, como às seguradora, podem levar a um grande crescimento deste conceito nos
próximos anos. O Peer to Peer aplicado ao sector dos seguros de saúde poderá trazer muitas
vantagens, uma vez que algumas vantagens do modelo P2P Insurance coincidem com alguns dos
desafios dos seguros de saúde, nomeadamente, a grande taxa de sinistros, a grande taxa de sinistros
fraudulentos e ainda a necessidade de os seguros de saúde terem de fornecer maior atenção ao
cliente pois o número de contactos deste com a seguradora é maior.
Visto isto, o P2P Health Insurance, poderá concentrar numa plataforma todas as atividades
relacionadas com a gestão de um seguro e respetivos sinistros, bem como, oferecer ao cliente
serviços relacionados com a pesquisa de profissionais de saúde, consultas à distância, marcação
de atividades de promoção de saúde entre a comunidade e ainda fóruns de discussão sobre tópicos
relacionados com a saúde.
Na tabela de cima, encontra-se uma sistematização da informação recolhida sobre as três for-
mas de P2P Insurance existentes, mais precisamente das 3 empresas que foram analisadas para
cada caso, sendo que a última coluna é referente à participação do fundo da comunidade na cober-
tura dos sinistros.
20
Indústria Seguradora e a Inovação
Tabela 2.2: Análise comparativa das várias seguradoras
Seguradora Fundação Tipo de Seguros Responsabilidadeda Comunidade
Friendsurance 2011 Dispositivos eletrónicos,recheio de casas,despesas legais e
responsabilidade civil
40%
Guevara 2013 Automóvel 80%PeerCover 2015 Qualquer tipo de seguro,
desde que haja umacomunidade interessada
100%
21
Indústria Seguradora e a Inovação
22
Capítulo 3
Estado da Arte - Desenvolvimento Web ePrototipagem
Depois de no capítulo anterior ter sido apresentado um enquadramento relativo à indústria
seguradora, é tempo agora para apresentar uma revisão bibliográfica focada nas tecnologias que
poderão ser utilizadas no desenvolvimento de plataformas web, semelhantes aquela que foi desen-
volvida ao longo desta dissertação. De acordo com aquilo que foi anteriormente referido, o grande
objetivo desta dissertação, consiste no desenvolvimento de um protótipo que possa ser utilizado
como prova de conceito de uma plataforma de P2P Health Insurance, portanto ao longo da pes-
quisa elaborada, foi atribuída especial importância a ferramentas que consigam ajudar os progra-
madores a diminuir o tempo de entrega de soluções, assegurando o máximo de qualidade possível.
Deste modo, a pesquisa realizada concentrou-se em três conjuntos de tecnologias que ajudam os
programadores web a entregarem soluções mais celeremente. Estes três conjuntos são: as fra-
meworks de desenvolvimentos web, os Sistemas de Gestão de Conteúdos (Content Management
Systems) - CMS, e as ferramentas de desenvolvimento rápido de aplicações (Rapid Application
Development) - RAD. Ao longo das próximas secções, serão analisados estes três grupos de tec-
nologias, sendo apresentados as suas desvantagens e desvantagens, bem como, alguns exemplos
de tecnologias para cada um destes conjuntos.
3.1 Frameworks de desenvolvimento web
Nos anos 90, quando a World Wide Web foi criada, as páginas a que os utilizadores tinham
acesso eram estáticas, não existindo praticamente nenhuma interação entre o utilizador e os con-
teúdos partilhados na página web. Contudo, as tecnologias web continuaram a evoluir a um ritmo
impressionante, sendo que em 1993, o National Center for Supercomputing Applications apre-
sentou uma tecnologia - Comon Gateway Interface - que permitiu a interação do utilizador com
as páginas web, através da capacitação dos servidores que geram o pedido HTTP de executarem
23
Estado da Arte - Desenvolvimento Web e Prototipagem
certas aplicações no lado do servidor, permitindo a criação de páginas dinâmicas. Todavia, nos
primeiros tempos desta tecnologia, cada pedido que era feito ao servidor, gerava um processo, o
que resultava numa grande sobrecarga dos servidores e, consequentemente, problemas de eficiên-
cia, resultando numa grande procura por tecnologias mais eficientes. Deste modo, surgiram, neste
período, as primeiras linguagens de programação de scripting, como o ASP.NET e o PHP[Bjö10].
Com o crescimento exponencial da web, as aplicações foram-se tornando cada vez mais com-
plexas e para responder a este facto, começaram a surgir bibliotecas que juntavam código previ-
amente escrito sobre um determinado âmbito. Mais tarde, começam a surgir as frameworks de
desenvolvimento, que para além de juntarem um leque de bibliotecas de âmbitos diferentes, forne-
cem ao programador uma estrutura base, sobre a qual a aplicação será construída. Desta forma, os
programadores deixaram de ter de criar de raiz a estrutura da sua aplicação, bem como, deixaram
de ter de repetir o código das funcionalidades que são recorrentes em todas as aplicações web.
As frameworks são habitualmente construídas utilizando uma determinada linguagem de progra-
mação, sendo que, atualmente, existem frameworks de desenvolvimento web num leque muito
abrangente de linguagens de programação, começando no C++, passando no Java e acabando no
Javascript ou PHP, havendo também frameworks mais focadas no lado do cliente e outras focadas
no lado do servidor.
Tal como foi anteriormente dito, a grande vantagem em utilizar uma framework é, sem dúvida,
a diminuição do tempo de desenvolvimento, porém existem outras vantagens, entre as quais, o uso
de código que já foi utilizado e testado por vários programadores, aumentando a confiança na
aplicação; o facto de as frameworks serem utilizadas por grupos de programadores, o que permite
a partilha de experiências entre os vários membros, promovendo o sentimento de comunidade e de
ajuda mútua; o recurso a uma framework facilita a adoção de padrões de desenho, nomeadamente
do Model-View-Controller, ajudando assim o programador na organização do seu código; as fra-
meworks ajudam os programadores mais inexperientes a adotarem práticas de desenvolvimento
mais correta, assim como, conseguem reduzir o tempo de aprendizagem de uma determinada lin-
guagem de programação [Bjö10].
Porém, existem alguns pontos menos positivos, como por exemplo o facto de por vezes as
frameworks serem muito mais complexas do que aquilo que realmente é necessário, exigindo
por vezes uma longa curva de aprendizagem para realizar tarefas simples e também prejudicar
a performance, sem que seja necessário; no caso de ser detetada algum erro ou debilidade na
framework, todas as aplicações construídas recorrendo a esta, estão em risco; por vezes o recurso
a uma framework pode não fornecer a flexibilidade desejada para o desenvolvimento de certas
soluções.
Posto isto, podemos concluir que a utilização de frameworks poderá trazer inúmeras vanta-
gens ao processo de desenvolvimento de uma determinada aplicação web, contudo, sempre que é
necessário construir uma determinada plataforma, deverão ser analisados todos os prós e contras
de adotar uma framework em detrimento de outra, ou adotar uma framework ao invés de construir
a aplicação de raíz. Nas próximas secções, serão apresentadas algumas frameworks com diferen-
tes potencialidades e que utilizam diferentes linguagens de programação, sendo que ao longo da
24
Estado da Arte - Desenvolvimento Web e Prototipagem
próxima secção foram destacadas tecnologias que sejam 100% open-source.
3.1.1 Backend frameworks
3.1.1.1 Ruby on Rails
Ruby é uma linguagem de programação, desenvolvida pelo japonês Yukihiro “Matz” Matsu-
moto, lançada no ano de 1995. Esta linguagem caracteriza-se por ser uma linguagem de uso global,
tal como C ou Java, contudo a sua popularidade está muito ligada ao desenvolvimento web, muito
devido à criação da framework de desenvolvimento web Rails. Rails [RUB] é uma framework,
desenvolvida em Ruby, que foi lançada em 2004, com o objetivo de auxiliar os programadores no
desenvolvimento de aplicações web dinâmicas. Desde da sua criação, esta tecnologia tem angari-
ado inúmeros utilizadores, destacando-se algumas startups de nível mundial, tais como, GitHub,
Twitter ou a Groupon. Combinando a linguagem de programação Ruby com as tecnologias de
desenvolvimento de web, HTML, JavaScript e CSS, o Rails, permite a construção de aplicações
dinâmicas, sendo que as várias páginas são geradas do lado do servidor web, daí esta framework
ser considerada como uma tecnologia de backend. Além da geração dinâmica de páginas web, o
Rails, também permite a criação de modelos de dados e a adaptação a uma arquitetura que utilize
o REST como forma de estruturação da aplicação[Keh13].
Aquando do seu lançamento, uma das características que mais fez com o esta framework se
destacase das demais, foi o facto de esta se basear no padrão de desenho de sistemas de software,
Model-View-Controller - MVC. Desta forma, os programadores conseguem de uma forma mais
simples, estruturar o seu código, facilitando simultaneamente, a colaboração de outros programa-
dores, uma vez que este padrão de desenho é vastamente conhecido entre os programadores mais
experientes. Para isto, existem três tipos de classes em Ruby on Rails: ActionController, que
diz respeito ao controller; ActionView, que diz respeito às views; e por último o ActionModel,
relacionado com o Model.
Um dos pontos mais relevantes quando se fala de Ruby on Rails, é o facto de esta tecnologia
ser totalmente gratuita e open-source, contando também, com uma comunidade muito extensa,
ativa e disponível para ajudar os programadores nos problemas decorrentes do desenvolvimento.
Para além da disponibilidade e da informação disponível, existe ainda outra vantagem bastante
determinante, o RubyGems, um gestor de instalação de pacotes de software, que facilita muito
a tarefa de criação, partilha e instalação de bibliotecas, facilitando e acelerando o processo de
desenvolvimento. Outro aspeto que também é apontado como uma das vantagens em utilizar
esta framework é a qualidade do código produzido, isto é, o código desenvolvido em Ruby é
considerado, por alguns programadores, como sendo mais organizado e de mais alto nível, quando
em comparação com outras linguagens como o PHP ou NodeJS[Mac15, Harb].
No entanto, existem algumas desvantagens inerentes à utilização desta tecnologia, entre as
quais a performance média, o tempo de compilação e o multithreading. Em relação à perfor-
mance, o Ruby on Rails é considerado mais lento que outras tecnologias como por exemplo o
NodeJS, contudo, por norma, os problemas de performance de uma aplicação não se prendem
25
Estado da Arte - Desenvolvimento Web e Prototipagem
com o framework que é utilizado, mas sim com os acessos às bases de dados, arquitetura do sis-
tema, entre outros. No que toca ao tempo de compilação, esta sim é considerada como uma das
maiores frustrações dos programadores de Ruby on Rails, principalmente quando um projeto tem
um grande número de dependências e ficheiros, podendo assim interferir na produtividade das
equipas de desenvolvimento. Por último, o multithreading é um dos assuntos no qual o Ruby on
Rails pode introduzir mais problemas de performance, sendo que os programadores têm de ter
particular atenção quando lidam com este tema no processo de desenvolvimento. Existem ainda
outras desvantagens mencionadas em relação a esta tecnologia, porém não consensuais, nomea-
damente o facto desta ter uma grande curva de aprendizagem, pois a aprendizagem do paradigma
de programação do Ruby pode ser algo complicado para programadores mais habituados a outras
tecnologias, e o facto desta tecnologia por vezes fornecer funcionalidades que realizam uma de-
terminada tarefa mas que simultaneamente “escondem” a forma como a fizeram, não dando ao
programador controlo sobre a operação que está a ser realizada[Mac15].
Visto isto, o Ruby on Rails, é sem dúvida uma das frameworks que precisa de ser tida em
conta quando se analisa as principais tecnologias deste tipo existentes. Apesar da sua penetração
no mercado estar a abrandar e de ser menor daquilo que outrora foi esperado, esta tecnologia tem
todo o potencial para ser utilizada como base para construção de aplicações web, contudo é preciso
ter atenção que, para além das desvantagens acima enumeradas, o facto de haver ainda poucos
profissionais proficientes com esta framework, poderá levantar alguns problemas em projetos de
maior dimensão.
3.1.1.2 Laravel - PHP
Sempre que se estudam possíveis tecnologias de implementação de aplicações web, não se
pode deixar de considerar o PHP e as frameworks que o utilizam, uma vez que esta linguagem de
programação é uma das mais usadas em termos de desenvolvimento web, muito devido ao facto
desta ter sido uma das primeiras linguagens de scripting e da sua sintaxe ser muito semelhante a
outras linguagens amplamente utilizadas como o C e o Java. Esta tecnologia é executada do lado
do servidor e apesar de permitir aos programadores o desenvolvimento do projeto de raiz de forma
totalmente personalizada, a maioria dos programadores prefere não reinventar a roda e decide
optar por uma das várias frameworks disponíveis [Vo]. Entre as várias frameworks, destacam-
se o CakePHP, Zend Framework, CodeIgnite, Symfony e o Laravel, porém devido ao facto de o
principal objetivo desta dissertação ser a construção de um protótipo, será feita apenas a análise
de uma única framework, o Laravel, uma vez que as funcionalidades oferecidas por estas são
semelhantes.
O Laravel[LAR], atualmente na sua versão 5.5.9, foi criado em 2011 por Taylor Otwell e em
apenas dois anos conquistou muitos programadores nas várias partes do mundo. Entre as princi-
pais funcionalidades que o Laravel fornece, estão a capacidade de gerir sessões, gestão de base
de dados (oferecendo um sistema capaz de abstrair e automatizar toda a parte relacionada com o
acesso aos dados), motor de geração de páginas web, entre outras. Tal como outras frameworks
apresentadas nesta dissertação, o Laravel também contém um sistema que ajuda os programadores
26
Estado da Arte - Desenvolvimento Web e Prototipagem
a instalar pacotes de software disponibilizados pela comunidade, parecido com o RubyGems visto
anteriormente para o Ruby on Rails. O Laravel, à semelhança de outras frameworks, também é es-
truturado seguindo o padrão de desenho Model-View-Controller, e como tal acarreta as vantagens
inerentes à implementação deste modelo.
Esta framework, para além de reunir as vantagens da utilização deste tipo de tecnologias an-
teriormente referidas, também fornece uma sintaxe muito organizada e de fácil aprendizagem,
possibilitando ao programador a definição de regras para uma maior adaptação à sua forma de
desenvolver, fornecendo grande liberdade ao programador. Outra vantagem são algumas funcio-
nalidades que o Laravel providencia, entre as quais o Artisan e o Eloquoent ORM, que ajudam e
aceleram a produtividade dos programadores. Por outro lado, apesar do Laravel dar muita liber-
dade de implementação aos programadores, isto leva a que as equipas de desenvolvimento sejam
menos produtivas a utilizar esta framework, comparando com outras como o Ruby on Rails e o
Django, devido à existência de regras específicas para certos projetos e à necessidade de as definir.
A outra grande desvantagem em escolher o Laravel está relacionada com o facto desta framework
ser muito recente, sendo que a sua resposta para certos problemas é ainda limitada e o seu gestor de
pacotes de software ainda não está tão forte como o de outras frameworks, tais como, RubyGems
(Ruby), NPM (NodeJS) ou PIP(Python)[Vo].
Posto isto, podemos considerar que o Laravel é uma framework que poderá ser considerada
para fins de prototipagem, uma vez que o PHP é uma linguagem de programação amplamente
conhecida, de fácil aprendizagem e que em conjunto com o Laravel poderá constituir uma boa
opção para a rápida construção de soluções. Todavia, é necessário estar alerta para o facto de
o tempo de desenvolvimento poder ser maior e de haver a possibilidade de ser difícil encontrar
suporte e ferramentas ou bibliotecas.
3.1.1.3 Django - Python
O Python, tal como o Java, o C ou o Ruby (visto anteriormente), é uma linguagem de progra-
mação que foi lançada no início dos anos noventa pelo holandês Guido van Rossum e que pode ser
usada numa gama variada aplicações, entre as quais, aplicações web. Esta linguagem é conhecida,
não só pela sua sintaxe estruturada, mas também pelo grande número de bibliotecas que auxiliam
os programadores nas variadas tarefas. O Python é ainda reconhecido pelo seu ambiente de exe-
cução de grande performance e estabilidade, sendo capaz de ser executado nos principais sistemas
operativos: Unix/Linux, Windows e MacOx. Em termos de desenvolvimento web, o Python ofe-
rece algumas opções de frameworks que aplicam o padrão de desenho MVC, nomeadamente o
TurboGears, Zope e aquele que será analisado neste capítulo, o Django[Hou].
O Django[DJA] é uma das frameworks disponíveis em Python, que conquista mais seguidores
dentro da comunidade de programadores desta linguagem de programação desde a sua criação
em 2003, sendo uma tecnologia open-source. As funcionalidades que fornecidas que mais se
destacam nesta framework são o seu poderoso componente de base de dados (Object-Relational
Mapper) que facilita muito os acessos a dados, a sua interface de administração automática que
permite fazer a gestão de toda a aplicação, podendo ser personalizável e flexível, o seu ambiente
27
Estado da Arte - Desenvolvimento Web e Prototipagem
de desenvolvimento extremamente poderoso e leve, capacitando o programador com uma série
de ferramentas muito úteis no desenvolvimento, e por último, o sistema de gestão de URLs que
permite que o programador defina URLs seguindo padrões, criando URLs compreensíveis para o
utilizador e para os motores de busca.
Entre as várias vantagens de utilizar o Django, encontram-se a facilidade instalação e de utili-
zação da framework para programadores experientes, a possibilidade de lidar com tarefas concor-
rentes (multithreading), a fácil integração com código de python já existente e outras tecnologias,
a boa performance fornecida e, por último, o facto de ser uma tecnologia que é utilizada por gran-
des gigantes da tecnologia como a Google, fazem com que esta tecnologia esteja em constante
desenvolvimento, assegurando por outro lado a qualidade da mesma. Em relação às desvantagens,
é normalmente apontado ao Django uma certa complexidade relacionada com a própria framework
e também com a linguagem de programação(quando comparando com outra linguagens, como o
JavaScript ou o PHP), o facto das aplicações tenderem a ter um tamanho grande e também uma
grande complexidade e ainda o facto de esta framework não ser tão poderosa como, por exemplo,
o Ruby on Rails, levando o programador a despender mais tempo para desenvolver a mesma tarefa
em Django[Hou].
Em suma, o Django e Python poderão ser uma boa opção pois a sua utilização capacita os
programadores com uma ferramenta com muitas potencialidades, que poderá providenciar um de-
senvolvimento célere e que simultaneamente oferece uma boa performance. Contudo, é preciso
ter em atenção alguma complexidade que poderá advir da utilização desta linguagem e desta fra-
mework e também o facto desta framework já estar no mercado à bastantes anos, levando a que
a evolução desta framework seja mais lenta daquilo que é desejado, de modo a garantir que com
a introdução de novas funcionalidades não são criados conflitos naquelas desenvolvidas anterior-
mente.
3.1.1.4 NodeJS
O NodeJS[NOD] é uma tecnologia utilizada para correr do lado do servidor, implementada em
C/C++ baseada na implementação runtime da Google, chamada motor “V8”[CHR+]. Esta tecno-
logia utiliza a linguagem de scripting javascript e possibilita a criação de servidores, utilizando
uma abordagem orientada a eventos e um modelo assíncrono, tornando esta aplicação eficiente
e pouco exigente em termos computacionais. Lançada em 2009, esta tecnologia foi totalmente
desenvolvida em Open Source e encontra-se atualmente na versão 5.7. Um facto interessante so-
bre o NodeJS, é o tamanho da sua comunidade, levando esta organização a considerar que o seu
ecossistema de bibliotecas e pacotes de instalação (NodeJS Package Manager, NPM) é o maior em
todo mundo. As qualidades desta tecnologia tem vindo a ser reconhecidas por diversas empresa
entre as quais: Microsoft, SAP, LinkedIn, Netflix e PayPal.
O NodeJS, para além de inovar no facto de colocar a linguagem javascript no lado do servi-
dor, também inova pelo abandono da abordagem multithreading, criando a oportunidade de criar
aplicações com grande potencial de escalabilidade, sem o lado negativo da grande complexidade
inerente aos sistemas de multithreading. Deste modo, o NodeJS, funciona através de um sistema
28
Estado da Arte - Desenvolvimento Web e Prototipagem
de single-threading com uma abordagem baseada em eventos e inputs/outputs não bloqueantes,
recorrendo a funções de callback que são invocadas sempre que um processo termina, evitando
que a aplicação fique bloqueada[TV10].
Figura 3.1: Método de funcionamento não-bloqueante do NodeJS[dS15]
Uma das frameworks disponíveis em NodeJS é o Express, uma ferramenta muito simples
que auxilia os programadores na construção APIs REST, bem como na geração de páginas web e
gestão das várias rotas da aplicação. Esta framework destaca-se por ser de utilização muito simples
e por permitir aos programadores a construção de uma aplicação em poucos passos. Existem
ainda outras frameworks/bibliotecas que poderão ser usadas em NodeJs, permitindo acelerar muito
todo o processo de desenvolvimento, nomeadamente módulos de acesso à camada de dados, com
módulos existentes para uma vasta gama de tecnologias de bases de dados, acesso a ficheiros ou,
ainda, módulos de acesso a outras APIs, permitindo, por exemplo, o acesso a APIs como o Google,
Facebook, entre outras, muito facilmente. O NodeJS ainda se destaca dos demais concorrentes,
pela sua simplicidade e facilidade, pois o Javascript é uma linguagem pouco complexa e de fácil
aprendizagem. Para além deste facto, o NodeJS também é reconhecido pela sua rapidez, tanto
no tempo de compilação como na sua execução, muito devido ao facto de esta tecnologia usar o
motor “V8” desenvolvido pela Google[dS15]. É ainda importante notar, que o NodeJS é de fácil
instalação, tornando o processo de colocar código em produção muito mais fácil do que noutras
plataformas.
Todavia, existem alguns pontos negativos apontados ao NodeJS, entre os quais, o facto de
este ser single-threaded, característica que apesar de trazer muitas vantagens poderá também ge-
rar alguns problemas. Como nesta tecnologia, por defeito, não existe concorrência, é o próprio
programador a decidir como gerir estas situações, o que pode levar programadores mais inexperi-
entes a cometer erros e a criarem bloqueios ou quebras de sistema. Outro ponto menos positivo do
29
Estado da Arte - Desenvolvimento Web e Prototipagem
NodeJS, é o facto deste ainda não possuir frameworks tão poderosas como o Ruby, o Python ou o
PHP, no entanto, devido à grande comunidade que esta tecnologia tem, existem muitos pacotes de
software que poderão ser utilizados pelos programadores, acelerando muito o desenvolvimento.
Em alguns fóruns, é ainda reportada uma outra desvantagem: a falta de maturidade, contudo, após
sete do seu lançamento é decerto injusto, continuar a apontar este ponto negativo a esta tecnologia.
De facto, o NodeJS é tido como uma das tecnologias de desenvolvimento que estão em voga
no momento, com muitas empresas e startups a apostarem nesta tecnologia para os seus produtos,
tendo verificado uma grande taxa de crescimento nos últimos anos[Ols14]. No entanto, é neces-
sário enfatizar que esta tecnologia ainda não tem uma grande framework disponível, o que poderá
levar as equipas de desenvolvimento a dispenderem muito tempo a desenvolverem a aplicação de
raiz, ou por outro lado a pesquisar pelos melhores módulos para a sua aplicação.
3.1.2 Frontend Frameworks
3.1.2.1 AngularJS
AngularJS[ANG] é uma framework de desenvolvimento de web baseada no padrão de desenho
MVC, desenvolvida pela Google e que se encontra actualmente na sua versão 2.0, sendo que,
ao contrário das frameworks anteriormente analisadas, corre do lado do cliente. Esta aplicação
surge para combater a complexidade que as aplicações baseadas apenas em JQuery e Javascript
apresentam, exigindo ao programador conhecimentos profundos para a construção de aplicações
mais elaboradas com a estrutura mais adequada, que garanta eficiência e a sustentabilidade das
mesmas [SG]. Assim, o objetivo principal do AngularJS é, fornecer uma framework com uma
estrutura previamente definida, permitindo assim um desenvolvimento de aplicações web mais
fiável e rápido.
O AngularJS apresenta inúmeras vantagens, entre as quais, o facto de ser uma framework que
permite a separação do estilo da página principal da lógica de negócio, permitindo que a lógica
de negócio seja alterada sem afetar a visualização e vice-versa. Uma outra grande vantagem que
o esta framework apresenta, é a sua simplicidade de codificação, tornando muito mais simples o
papel do programador na criação de aplicações estáveis por um longo período de tempo [SG].
A estrutura desta framework é relativamente simples e está dividida por módulos que por sua
vez estão todos ligados por um módulo raiz. Cada módulo tem um conjunto de componentes,
nomeadamente, um componente responsável pelas configurações gerais a todo módulo, outro res-
ponsável pelas rotas inerentes a este módulo e depois cada rota, tem um conjunto de controladores
e vistas, que comunicam entre si através de uma variável chamada “scope”. Existem também dois
componentes que podem ser usados pelos controladores, as fabricas (factories) e os serviços (ser-
vices), que são utilizados por um lado para comunicação entre os vários controladores da aplicação
e por outro pela comunicação com API externas[Cho].
Apesar das suas potencialidades, a utilização do AngularJS ainda não evita a utilização de
uma tecnologia do lado de servidor, contudo quando se recorre a esta framework, nem sempre
30
Estado da Arte - Desenvolvimento Web e Prototipagem
é necessário a utilização de uma framework tão complexa do lado do servidor. Este facto, jun-
tamente com aqueles referenciados nos capítulos superiores, podem contribuir para uma melhor
organização dos vários módulos da aplicação, bem como podem ajudar os gestores de equipas a
distribuírem os seus recursos, visto que desta forma a equipa terá de ter elementos de diferentes
áreas de conhecimento.
3.1.2.2 EmberJS
Lançada no ano de 2011, o EmberJS[EMB] é uma framework de desenvolvimento web, muito
semelhante àquela apresentada anteriormente. Usando também o padrão de desenho MVC, esta
tecnologia permite a estruturação do código através de três estâncias: o route que é responsável
pelo Model, o handlebar template que gere as views e o controller que é a entidade que manipula
os dados. Esta framework é escrita em JavaScript e está assente no princípio de página web
rápida, que consiste em não recarregar a página toda sempre que é necessário atualizar alguma
informação, aumentando assim a performance da mesma.
Quando comparada com outras frameworks semelhantes, o EmberJS destaca-se por ser mais
pequena que os seus concorrentes, fator que pode ser determinante aquando da escolha de uma
framework que funcionará do lado do cliente. Outro ponto importante de referir, é que esta fra-
mework é baseada em convenções e não em configurações, motivo pelo qual os programadores
deverão procurar aprender estas convenções de forma a melhorarem a sua produtividade, contudo
a aprendizagem destas diretrizes poderá levar a que o tempo de aprendizagem seja um pouco maior
do que nas outras frameworks, no entanto, assim que o programador interioriza o seu processo de
desenvolvimento é mais célere do que em outras frameworks. Em termos de comunidade, esta
framework, apesar de não ser tão popular como outras, já tem uma comunidade de programadores
que a utilizam, porém poderão surgir dificuldades em arranjar informações mais específicas[Cho].
Posto isto, o EmberJS poderá ser uma opção viável para a construção de uma aplicação web,
uma vez que apresenta bons níveis de performance e funcionalidades que permitem o desenvolvi-
mento rápido, contudo, o facto de esta possuir uma curva de aprendizagem mais acentuada que as
suas concorrentes, poderá levantar alguns entraves à sua utilização.
3.1.2.3 BackboneJS
BackboneJS[BAC] é uma framework que corre do lado do cliente, desenvolvida em JavaScript
que foi lançada em Outubro de 2010. Esta framework, tal como as anteriormente apresentadas,
tem como objetivo o desenvolvimento de aplicações web de página única (single-page web appli-
cations) e também se baseia no padrão de desenho MVC, apesar de aplicar uma variação chamada
Model-View-Presenter. Esta framework inova a retirar o acesso a dados do DOM, introduzindo
uma série de elementos que ajudam o programador a realizar esses processos, nomeadamente,
o Model, as Collections e os objetos View. Atualmente, esta tecnologia é utilizada por muitas
empresas, entre as quais, a AirBnB, a Hulu, SoundCloud e Pinterest.
31
Estado da Arte - Desenvolvimento Web e Prototipagem
Neste framework existem três tipos de objetos: os Model, que gerem o acesso aos dados e a
lógica de negócio, carregam e guardam a informação no servidor e disparam eventos quando exis-
tem mudanças nos dados; as Views, que registra mudanças e constrói a interface com o utilizador,
gere os inputs do utilizador e interação da aplicação com ele e ainda é responsável por informar o
model dos inputs do utilizador; e as Collections, que ajudam o programador a gerir grupos de Mo-
dels relacionados entre si, fornecendo algumas funções que poderão ajudar a lidar com agregações
de dados.
As grandes vantagens de utilizar esta framework, prendem-se com o facto de as comunicações
serem geradas por eventos, tal como acontece com o JQuery, contudo sem os problemas de es-
calabilidade normalmente associados a esta tecnologia. Outra vantagem é a sincronização com o
lado do servidor, pois no BackboneJS, os Models podem ser facilmente ligados aobackend, uma
vez que esta framework fornece um bom sistema de acesso a APIs REST, tendo já implementado
as funcionalidades necessárias à leitura, escrita e remoção, respectivamente, GET, POST e DE-
LETE. Outro ponto de destaque desta aplicação é o facto de as suas convenções poderem ajudar
os programadores a reduzir a quantidade de código necessário, aumentando, consequentemente, a
produtividade do desenvolvimento. Referir ainda que a comunidade do BackboneJS, tal como a de
EmberJS, ainda é de tamanho reduzido, o que poderá acarretar alguns problemas, principalmente
a programadores mais inexperientes[Cho].
Em suma, tal como as duas frameworks apresentadas anteriormente, o BackboneJS é uma boa
opção para estruturar o código do lado do cliente, apresentando também algumas funcionalidades
que podem melhorar tanto a performance como o desenvolvimento da aplicação.
3.2 Sistemas de Gestão de Conteúdo - CMS
Os Sistemas de Gestão de Conteúdo, ou em Inglês, Content Management Systems, surgem no
final dos anos 90, para responder a uma outra necessidade existente no mundo do desenvolvimento
web. Se por um lado começam a surgir as primeiras frameworks de desenvolvimento web, com
o objetivo de ajudar os programadores a estruturar e acelerar o processo de desenvolvimento de
uma aplicação web, por outro lado, a proliferação das tecnologias web leva a que o mercado
comece a procurar soluções para ajudar as pessoas na criação e gestão dos conteúdos colocados
nas suas páginas web. Desta forma e baseado no princípio que todas as aplicações web têm muitas
funcionalidades em comum, começam a surgir tecnologias com o objetivo de facilitar a criação
de aplicações web, diminuindo os conhecimentos técnicos necessários para conseguir construir
e gerir uma aplicação. Dentro dessas tecnologias, destacam-se os CMS, que permitem que as
pessoas criem e disponibilizem conteúdos, utilizando interfaces de fácil interpretação, sem que
seja necessário que o criador dos conteúdos tenha conhecimentos de programação[PB].
Desde a criação dos primeiros CMS, a comunidade de desenvolvimento em torno destas tec-
nologias foi crescendo, e hoje é possível encontrar muitos tipos de CMS, bem como, muito tipo
de aplicações previamente criadas em cada um desses CMS. Por exemplo, se visitarmos a página
web de um dos CMS mais usados, o Joomla, conseguimos constatar que existe um leque muito
32
Estado da Arte - Desenvolvimento Web e Prototipagem
alargado de soluções padrão que podemos escolher para desenvolver uma aplicação para as mais
variadas áreas de negócio, sendo apenas necessário personalizar para a entidade em questão, ha-
vendo disponíveis para criar um simples Blog até à criação de um complexo sistema de gestão de
informação de uma empresa[CdMA+11].
Por norma, os CMS estão estruturados em dois blocos, o frontend, que corresponde à parte que
é visualizada pelo utilizador da aplicação web, e o backend, parte que é apenas acedida pelos admi-
nistradores da aplicação e que diz respeito à gestão dos conteúdos expostos e acesso a informação
fornecida pelos utilizadores. O processo de desenvolvimento de uma aplicação, recorrendo a esta
abordagem, pode passar por escolher um determinado modelo e depois personalizá-lo, ou cons-
truir uma aplicação de raiz com os vários módulos e componentes disponíveis entre a comunidade
de desenvolvimento.
As grandes vantagens em recorrer a um sistema destes são: a grande facilidade de criar
uma aplicação, a grande velocidade de desenvolvimento, pois existem imensos componentes e
módulos que poderão ser utilizados e caso não existam, podem ser criados utilizando a lingua-
gem/framework sobre a qual o CMS foi construído, e por fim, o facto de serem tecnologias matu-
ras, estáveis e que têm uma grande comunidade de desenvolvimento, fazendo com que seja muito
fácil encontrar informação e muitos pacotes de software previamente desenvolvidos. No entanto,
existem alguns pontos negativos, nomeadamente a dificuldade de criar um produto muito persona-
lizado e específico, o facto de muitas vezes o programador ter que lidar com uma estrutura muito
complexa para realizar uma aplicação simples e, por último, com a utilização destas tecnologias
poderão surgir alguns problemas de performance.
Visto isto, é percetível a pertinência do estudo desta gama de tecnologias para fins de prototi-
pagem, pois conseguem acelerar muito o processo de desenvolvimento de software. No entanto,
existem dezenas de CMS, por exemplo, Moodle, gestão de conteúdos para fins educativos, Sha-
rePoint, gestão de documentos para empresas, Magento, criação de plataformas de e-commerce,
MediaWiki, criação de enciclopédias colaborativas, entre outros, sendo que ao longo da próxima
secção, serão analisados 3 dos mais populares CMS de momento e simultaneamente mais versá-
teis: o Wordpress, o Joomla e o Drupal.
3.2.1 Joomla
O Joomla[JOO], segundo o sítio da própria organização, é um sistema de gestão de conteú-
dos(CMS) que conquistou prémios e que fornece a qualquer pessoa a possibilidade de construir
aplicações web com muito potencial, destacando-se pela facilidade de utilização e pela escalabi-
lidade. Este CMS, pode ser usado para uma gama alargada de tipos de plataformas web, sendo
que se evidenciam os seguintes: portais de empresas e organizações, aplicações de e-commerce
e reservas online, redes sociais e jornais,revistas e publicações online. Entre os vários ilustres
utilizadores deste CMS, encontram-se a Universidade de Havard, o banco americano Citybank e a
revista de fotografia Outdoor Photographer.
Comparando o Joomla com os seus mais diretos concorrentes, o WordPress e o Drupal, pode-
mos afirmar que este acaba por ser um meio-termo entre os CMS concorrentes, pois fornece uma
33
Estado da Arte - Desenvolvimento Web e Prototipagem
variedade de funcionalidades que não podemos encontrar no WordPress, sem exigir ao programa-
dor um grande nível de conhecimento técnico, como acontece com o Drupal. No Joomla, tal como
acontece com os seus concorrentes, existem muitos componentes e modelos que o programador
poderá usar, contudo é de salientar a facilidade que o Joomla fornece para a criação de redes so-
ciais, permitindo ao programador criar uma de plataforma deste género de forma rápida e fácil.
Este CMS, destaca-se ainda pela oferta que dispõe para soluções de e-commerce, providenciando
soluções de grande qualidade[Men15].
Os principais pontos positivos de utilizar o Joomla são a simplicidade de instalação, o grande
número de plug-ins disponíveis e ainda o seu poderoso painel de administração que permite reali-
zar muitas tarefas relacionadas com a criação e gestão da aplicação. Quanto aos pontos negativos,
é normalmente apontado ao Joomla uma certa dificuldade em criar soluções muito específicas,
pois apesar de existirem diversos componentes disponíveis, existe sempre alguma funcionalidade
necessária que não é suportada ainda. É também apontado como ponto negativo o facto de muitos
dos componentes disponíveis exigirem um pagamento para serem utilizados. É importante referir
também que, o Joomla poderá apresentar problemas de performance, principalmente relacionados
com a escalabilidade da plataforma, contudo, na construção de aplicações pequenas, este problema
não se deverá verificar. Por fim, ressalvar que a utilização deste CMS, implica que o programa-
dor tenha conhecimentos gerais sobre desenvolvimento web, contudo não exige conhecimentos
técnicos muito profundos para que seja possível criar uma simples aplicação[CdMA+11].
Em suma, o Joomla é uma poderosa tecnologia que poderá acelerar muito o processo de de-
senvolvimento, contudo as equipas de desenvolvimento devem estar conscientes que apesar de
todas as potencialidades deste CMS, poderão surgir sempre problemas derivados da dificuldade
de personalização.
3.2.2 WordPess
Quando se fala em sistemas de gestão de conteúdos, é muito difícil não referenciar o Word-
Press [WOR], uma vez que mais de 40% das aplicações web construídas recorrendo a CMS, foram
construídas recorrendo a esta tecnologia, totalizando cerca de 60 milhões de websites[Col12]. Este
facto faz com que este CMS, possua a maior comunidade entre os existentes, o que resulta num
grande número de modelos e componentes disponíveis para a construção de novas aplicações web,
existindo mais de 2000 modelos e 27000 componentes. Além disso, esta tecnologia popularizou-
se pelo facto de ter reunido alguns utilizadores célebres, tais com, a revista Forbes, o canal de
televisão CNN e a empresa de tecnologia Sony[Jul].
A utilizar este CMS, os programadores ficam capacitados com uma ferramenta que lhes per-
mite o desenvolvimento de um website ou de uma aplicação web com conhecimentos técnicos
muito reduzidos, realizando toda a construção através de através de interfaces gráficas. Esta ca-
racterística, juntamente com a grande facilidade de instalação, fazem com que esta tecnologia
seja uma ótima opção para programadores pouco experientes e com conhecimentos reduzidos de
desenvolvimento web, pois os plug-ins e os modelos existentes, tornam o trabalho dos progra-
madores mais simples. Todavia, tal como acontece no Jooomla, sempre que é necessário realizar
34
Estado da Arte - Desenvolvimento Web e Prototipagem
alguma funcionalidade mais específica, este CMS exige que o programador tenha conhecimentos
na linguagem de programação PHP e na biblioteca sobre a qual foi construído o CMS. O Word-
Press acarreta ainda inconvenientes relativos à eficiência, relacionado com a grande quantidade de
componentes que muitas vezes se têm de instalar, e à segurança[Men15].
Posto isto, podemos concluir que, apesar de o WordPress ser amplamente utilizado na constru-
ção de websites, este CMS não é totalmente vocacionado para a construção de aplicações comple-
xas, sendo mais orientado para o desenvolvimento de plataformas mais simples. No entanto, seria
possível utilizar esta tecnologia para o desenvolvimento de um protótipo, contudo, a equipa de de-
senvolvimento teria de estar consciente que muitas das funcionalidades iram ter de ser construídas
de raiz utilizando a linguagem de programação PHP.
3.2.3 Drupal
No ano de 2001, Dries Buyteart e Hans Snijder disponibilizaram a primeira versão, daquele
que viria a ser um dos mais usados CMS do momento. Atualmente, o Drupal[DRU] é utilizado
por centenas de milhares de organizações em todo o mundo, ocupando o segundo lugar dos CMS
mais usados, apenas atrás do WordPress, tendo, consequentemente, uma grande comunidade em
seu redor. Esta tecnologia pode ser usada na construção de todo tipo de aplicações web, sendo
que o Drupal se destaca pela versatilidade que providencia, disponibilizando muitos plug-ins,
modelos e opções de configuração, que podem ser adaptados facilmente às necessidades das apli-
cações em construção. De forma a conseguir esta versatilidade, o Drupal acaba por exigir aos seus
utilizadores maiores conhecimentos técnicos de tecnologias web, nomeadamente, PHP, HTML e
CSS[BB12].
De facto, o Drupal traz consigo uma série de benefícios, nomeadamente, um grande número de
funcionalidades como a possibilidade de criar tipos de conteúdo adaptados à aplicação, personali-
zação do frontend, autorização de acesso a conteúdos baseada nas permissões de cada utilizador,
ferramentas de interação e colaboração e ainda um sistema de otimização para motores de busca.
No entanto, este CMS poderá apresentar alguns problemas para o programador, entre os quais,
a instalação e a adaptação a este sistema podem ser difíceis, as versões mais atuais poderão ter
problemas a utilizar plug-ins mais antigos e as aplicações de maior dimensão tendem a gerar uma
grande sobre carga nos servidores, criando alguns problemas de eficiência[Men15].
Resumidamente, o Drupal pode representar uma grande vantagem caso a equipa de desenvol-
vimento tenha conhecimentos de tecnologias web e caso a aplicação em questão não vista não
venha a sofrer um grande crescimento, questão que não se coloca aquando da construção de uma
prova de conceito ou de um protótipo, mas que pode ser determinante na construção de uma solu-
ção real.
3.3 Ferramentas de Desenvolvimento Rápido de Aplicações - RAD
Na indústria de software a produtividade das equipas de desenvolvimento é um fator deter-
minante, porque para além de influenciar diretamente os custos dos projetos, também pode levar
35
Estado da Arte - Desenvolvimento Web e Prototipagem
a que certos produtos cheguem ao mercado já sem características diferenciadoras em relação aos
seus concorrentes. Consequentemente, os líderes desta indústria têm procurado encontrar solu-
ções para aumentar a velocidade com que os produtos de software chegam ao mercado. Desta
forma, tem surgido uma vasta gama de tecnologias, das quais fazem parte os dois tipos anterior-
mente apresentados. Contudo, nos últimos anos têm surgido o interesse sobre uma nova espécie
de tecnologias: as ferramentas de Desenvolvimento Rápido de Aplicações ou as plataformas de
desenvolvimento com pouco código. Estas tecnologias, consistem em complexas aplicações que
permitem a criação de plataformas de grande envergadura de forma altamente personalizada e com
potencial de escalabilidade. As RAD diferenciam-se por serem muito mais poderosas que os CMS
e das frameworks, permitindo que as equipas de desenvolvimento consigam construir aplicações
poderosas sem praticamente escrever uma linha de código, focando-se apenas na construção da
lógica e nos processos de negócio[RA16].
Tal como foi referido anteriormente, o crescente interesse por estas tecnologias deve-se essen-
cialmente à diminuição do tempo de desenvolvimento e consequente aumento de produtividade
das equipas de software. Segundo relatório lançado em agosto de 2015[Pra15], a utilização deste
tipo de tecnologias pode diminuir em 10 vezes o tempo necessário para a construção de uma apli-
cação, sendo dado dois exemplos. O primeiro de uma seguradora espanhola que implementou um
novo portal de internet em apernas 13 semanas, sendo que a estimativa recorrendo ao processo
normal de desenvolvimento era de 2.7 anos. O segundo de um ministério da saúde que desenvol-
veu um sistema de administração de pacientes em 5 semanas, enquanto a estimativa usando outras
tecnologias era de 3 anos. Existem ainda outros factores que fazem aumentar o interesse em torno
destas tecnologias, como por exemplo, a possibilidade de expandir e diversificar as áreas de for-
mação dos programadores e o facto de grandes investimentos terem sido feitos em empresas que
detêm plataformas deste género, provando que esta área de negócio está em franco crescimento e
que é rentável. Estas tecnologias podem ser utilizadas na construção de aplicações de raiz, bem
como, a camada de frontend que contata com o cliente e integra a informação com outros sistemas
mais complexos.
De entre os produtos existentes nesta gama de tecnologia, destacam-se 3 empresas, a Outsys-
tems, a SalesForce, empresa conhecida pelo seu sistema de CRM que possuí também um software
específico para este fim, e o Mendix. Normalmente, este tipo de produtos incluem 4 grupos de
funcionalidades: possibilidade de configurar modelos de dados e integração com outros sistemas,
ferramentas de implementação de lógica de negócio e de processos recorrendo a desenho de di-
agramas, desenho de interfaces responsivas com drag-and-drop de componentes e ferramentas
de gestão de projetos e desenvolvimento colaborativo. É importante referir que existem muitos
softwares que se incluem neste grupo, cerca de 42 segundo [RA16], contudo nem todos fornecem
tantas funcionalidades como os três apresentados anteriormente.
Todavia, existem algumas dúvidas sobre a capacidade que estas plataformas irão ter para su-
portar sistemas de maior dimensão e complexidade, sendo aplicados aos mais diversos cenários
de aplicação e sobre a capacidade que as empresas que as desenvolvem vão ter para responder ao
seu crescente uso de forma a gerir todos os problemas que vão surgindo. Estas dúvidas poderão
36
Estado da Arte - Desenvolvimento Web e Prototipagem
levar as empresas a não investir nestas plataformas ou pelo menos a investirem de forma mais
cautelosa, pois enquanto não houverem provas reais das verdadeiras capacidades destas tecnolo-
gias crescerem e de se manterem estáveis, pois as empresas que recorrem a estas plataformas, não
querem estar a colocar o futuro das suas aplicações em risco, apenas para conseguirem um desen-
volvimento mais rápido no presente. Outro problema apontado a estas tecnologias, é o facto de
todas as tecnologias nesta área serem pagas e normalmente com preços que podem ser demasiados
altos, caso o propósito seja apenas a experimentação de um determinado conceito ou a construção
de um protótipo de uma aplicação. O atual modelo de negócio seguido por muitos intervenien-
tes neste mercado, passa por aplicar um custo inicial semelhante a outros softwares proprietários,
aumentando gradualmente consoante o grau de uso[RA16, Pra15].
Concluindo, estas plataformas apresentam-se como sendo o futuro do desenvolvimento de
software, no entanto ainda é necessário comprovar que a sua utilização não irá acarretar proble-
mas no futuro. As vantagens da sua utilização são imensas, sem dúvida, porém as empresas não
poderão arriscar hipotecar o seu futuro apenas para garantir algumas vantagens no tempo corrente.
Ao longo da próxima secção apresentarei brevemente as plataformas das três empresas acima
referidas, a OutSystems, a SalesForce e o Mendix.
3.3.1 OutSystems
Com cerca de 16 anos, a Outsystems[Out] foi, em abril de 2016, considerada como sendo a lí-
der entre as plataformas de desenvolvimento aplicações com pouco código pela Forrester [RA16],
contudo o motivo pelo o qual esta organização mais se destacou na imprensa, foi a angariação de
um investimento de 55 milhões de dólares no início do ano de 2016. Esta empresa foi fundada em
Portugal, mas em que em 2014 moveu os seus altos quadros para os Estados Unidos da América,
sendo que entre os principais clientes se destacam a seguradora Fidelidade, a TAP e a Vodafone.
Esta plataforma pode ser usada na construção de aplicações complexas, possibilitando a integra-
ção com sistemas de informação como o SAP, Oracle ou SalesForce, sem que seja necessário
ao programador escrever código. Entre os grandes projetos em que esta tecnologia foi utilizada,
encontra-se a construção de um sistema completo de gestão de sinistros para uma grande empresa
de seguros em Portugal.
As funcionalidades oferecidas que mais se destacam são o leque alargado de ferramentas que
providencia par gerir modelos de base de dados e integrações com diferentes sistemas, o desenho
de interfaces responsivas com boa experiência de utilização, a possibilidade de construir platafor-
mas recorrendo ao desenho de diagramas de processos e ainda o suporte para desenvolvimento
colaborativo. No entanto, apesar de a OutSystems assumir um forte compromisso de forma a não
levar os seus clientes a terem que programar nas várias fases do processo de desenvolvimento de
software, desenvolvimento, entrega e manutenção, existem ainda algumas situações, em casos ex-
cecionais, que poderão levar os utilizadores desta plataforma a terem que escrever algum código.
Em relação à eficiência das aplicações construídas com esta tecnologia, ainda não existem muita
informação, sendo que na verdade esta é uma das grandes questões que se coloca a esta gama
37
Estado da Arte - Desenvolvimento Web e Prototipagem
de tecnologias, se vão conseguir ser capazes de construir grandes aplicações com bons níveis de
eficiência, sem se transformarem em tecnologias obsoletas[RA16].
Posto isto, podemos concluir que uma determinada empresa estiver a pensar em adotar uma
tecnologia de desenvolvimento rápido de aplicações, a OutSystems é uma boa opção, contudo
é necessário ter em atenção que estas tecnologias ainda estão a provar as suas potencialidades,
portanto a sua utilização em projetos mais crítico deverá ser ponderada com muito cuidado.
3.3.2 Mendix
Criada em 2005 em Roterdão, a Mendix[MEN] é a par da OutSystems e da SalesForce, um dos
líderes no mercado das tecnologias de desenvolvimento rápido de aplicações, contudo, segundo o
relatório da Forrester publica do em abril de 2016, apresenta algumas fraquezas que a OutSystems
não apresenta, nomeadamente o facto de não possuir qualquer certificação de segurança, o que
juntamente com o diminuto tamanho da empresa, leva a que muitos clientes de nível global fiquem
reticentes em adotar esta tecnologia.
A principal vantagem de utilizar o Mendix, prende-se com o facto de esta tecnologia incorporar
métodos ágeis de desenvolvimento, sendo que também apresenta funcionalidades de desenvolvi-
mento semelhantes à OutSystems, porém não tão poderosas. Resumindo, o Mendix pode ser uma
ferramenta muito poderosa, contudo tal como o que foi falado anteriormente para o seu concor-
rente, é necessário refletir muito sobre a sua utilização em certos projetos de grande importância,
quer estratégica quer funcional[RA16].
3.3.3 SalesForce - plataforma de desenvolvimento rápido de aplicações
A empresa SalesForce[Sal], criada é 1999, é uma empresa que se tornou num gigante do
mundo tecnologia com o seu sistema de gestão de relação com o cliente - CRM, lançando posteri-
ormente alguns produtos complementares, entre os quais algumas tecnologias de desenvolvimento
rápido de software. Plataformas como o Force.com, Community Cloud e o Lightning, são os pro-
dutos que esta empresa disponibiliza nesta área e que fazem de si o maior vendedor de plataformas
deste tipo, com uma receita estimada na entre os 600 e os 700 milhões de dólares americanos.
As grandes vantagens em recorrer a esta plataforma estão relacionadas com o facto de os
programadores poderem adaptar as aplicações conforme as suas necessidades e o facto de pos-
suir diferentes certificações de segurança. Por outro lado, um ponto negativo que é apontado ao
SalesForce é o facto de esta aplicação ainda estar totalmente focada em diminuir ao máximo a
necessidade de programar, bem como, o facto de não dar ao programador poder para controlar a
forma como a plataforma é estruturada[RA16].
3.4 Conclusões
Encerrando este capítulo, podemos concluir que a indústria de tecnologias de desenvolvimento
de aplicações tem apresentado muitas soluções que visam a facilitar e potenciar as tarefas dos pro-
38
Estado da Arte - Desenvolvimento Web e Prototipagem
gramadores, existindo tecnologias muito poderosas, existindo uma vasta gama de tecnologias que
poderão ser utilizadas nos mais variados contextos. Sendo assim, a escolha de tecnologias para a
construção dum protótipo duma aplicação web, depende de vários fatores, entre os quais: a equipa
de desenvolvimento, sendo que a tecnologia encontrada deve ir de encontro às capacidades e/ou
conhecimentos desta, as especificidades da aplicação em questão e ainda de questões estratégicas,
que podem levar a optar por uma tecnologia ao invés de outra por se acreditar que esta trará van-
tagens não só relacionadas com a parte técnica mas também com aspetos comerciais. Portanto,
sempre que uma equipa tem a difícil tarefa de escolher uma determinada tecnologia ou conjunto de
tecnologias para desenvolver uma solução, esta deverá avaliar os vários aspetos acima referidos,
de forma a conseguir encontrar as melhores tecnologias para o projeto em questão, pois não existe
nenhuma tecnologia que seja a chave-mestra para todos os problemas.
Concluindo, apresento agora algumas tabelas comparando as três abordagens ao desenvolvi-
mento web, apresentando de seguida tabelas de comparação para as tecnologias dentro de cada
uma das abordagens citadas.
Tabela 3.1: Análise comparativa das várias abordagens possíveis
Abordagem SoluçõesOpen-Source
Capacidades técnicasexigidas
Time-to-Market Nível dePersonalização
Frameworks Sim Alto Elevado AltoCMS Sim Moderado Médio Médio/Baixo
PlataformasRAD
Não Baixo Baixo Alto
Tabela 3.2: Análise comparativa das Frameworks de Backend
Framework Complexidade Instalador deBibliotecas
Performance Sistema deBase de Dados
Ruby onRails
Alta RubyGems Satisfatória Sim
Laravel -PHP
Média/Baixa - Satisfatória Sim
Django -Python
Média/Alta PIP Muito Boa Sim
NodeJS Baixa NPM Muito boa Não*
39
Estado da Arte - Desenvolvimento Web e Prototipagem
Tabela 3.3: Análise comparativa das Frameworks de Backend
Framework Suporte deAPIs Rest
Complexidade Performance Convenções deDesenvolvi-
mentoAngularJS Sim Baixa Muito Boa NãoEmberJS Sim Alta Muito Boa Sim
BackboneJS Sim Média Muito Boa Sim
Tabela 3.4: Análise comparativa das Frameworks de Backend
CMS Performance Painel deAdministração
Plug-ins deRedes Sociais
Facilidade dePersonalização
JOOMLA Satisfatória Sim Sim MédiaWordPress Satisfatória Sim Não Baixa
Drupal Satisfatória Sim Sim Alta
40
Capítulo 4
Metodologia e Objetivos
O objetivo desta dissertação é construir e avaliar uma prova de conceito de plataforma de ges-
tão de comunidades virtuais para suportar o modelo P2PI. Com esse objetivo, foi determinado
que seriam utilizadas metodologias ágeis de desenvolvimento, nomeadamente recorrendo ao pa-
radigma de resolução de problemas “Design Thinking", de forma a desenvolver um protótipo que
permita a prova de conceito desta novo modelo de vender. Esta metodologia tem vindo a ser ado-
tada pela firma Deloitte, de maneira a conseguir melhor endereçar as expectativas e necessidades
dos seus clientes.
Ao longo deste capítulo irá ser apresentada uma revisão bibliográfica sobre esta metodologia,
indicando quais as suas etapas e os objetivos de cada uma dessas etapas, bem como as técnicas
que existem para se atingirem esses mesmos objetivos. Por último, explicarei de que forma é que
esta metodologia será aplicada à resolução deste problema e quais os objetivos de cada uma das
fases para esta dissertação.
Em termos de tecnologias a usar no protótipo, serão utilizadas tecnologias de desenvolvimento
web, sendo que também será pertinente estudar quais as ferramentas disponíveis no mercado e
que podem contribuir para um processo de desenvolvimento o mais rápido possível, tal como
é necessário em projetos de prototipagem. Outro objetivo, passa também por tentar otimizar o
produto final através da realização de sessões de trabalho com alguns profissionais experientes em
interfaces com o utilizador, criando assim u produto mais poderoso em termos de usabilidade.
4.1 Novas tendências na Engenharia de Requisitos
Das várias fases que compõem o desenvolvimento de software, a engenharia de requisito é
uma das primeiras. Ao longo desta fase, a equipa do projeto procura recolher as necessidades dos
utilizadores, analisando e documentando os requisitos de um futuro sistema, tornando-se assim
uma fase muito importante e com impacto direto na qualidade da solução entre ao cliente [CNT03].
Apesar de esta prática ter sido durante muito tempo não ter sido considerada como uma atividade
41
Metodologia e Objetivos
criativa, nos últimos anos, o desenvolvimento de novos produtos e plataformas completamente
inovadores, levou a que o interesse de em práticas mais criativas aumentasse, fazendo com que
os processors de engenharia de requisitos fossem reconhecidos como práticas criativas [MR05,
MGR04].
Ainda em 2002, James Robertson, num artigo publicado na revista IEEE Software [Rob02],
indicou a importância de introduzir práticas que incentivem à criatividade. Ao longo do seu artigo,
Robertson indicava que sempre que se realizava um processo tradicional de elicitação de requisitos
pouca inovação era introduzida, argumentando também que dentro da prática de engenharia de
requisitos deveria ser introduzida algum passo que inventasse algo melhor do que aquilo que já
existia. O autor vai mais longe e cita a seguinte frase de Dewys Lasdon (designer): “O nosso
trabalho é dar ao cliente, dentro do tempo e custo, não aquilo que ele quer, mas sim aquilo que ele
nunca sonhou que queria; e assim que ele o recebe, reconhece que aquilo era algo que ele sempre
quis”.
Assim é reconhecida a importância de introduzir criatividade nos processos da engenharia de
requisitos, pois é necessário a produção de conteúdos que sejam simultaneamente originais e que
respondam às necessidades e expectativas dos utilizadores finais [MR05].
Em [MR05], é descrito um protocolo de realização de workshops no âmbito da engenharia de
requisitos, utilizando métodos que estimulam a criatividade. Os workshops são divididos em 4 fa-
ses, a preparação, a incubação, a iluminação e a verificação. No início do workshop um convidado
falava sobre um tema, que poderia estar ou não relacionado com a temática, fase de preparação.
Depois era pedido aos convidados para utilizarem os conhecimentos que tinham aprendido na fase
de preparação e os trabalhassem de modo a conseguirem criar novas associações ou combinações,
fase de incubação. Após esta fase de incubação começavam a surgir ideias, fase de iluminação.
Quando já existiam ideias, os orientadores do workshop levavam os participantes a verificarem as
ideias criadas com as limitações e/ou fronteiras do sistema, fase de verificação. Este protocolo
foi usado pela mesma equipa no âmbito da criação de um sistema de gestão de tráfego aéreo, o
CORA-2. Após a realização de 3 workshops, foram criadas cerca de 210 novas ideias para imple-
mentar neste sistema, sendo que 20 foram criadas no primeiro, 115 no segundo, 18 no 3o e outras
46 foram criadas posteriormente à realização dos mesmos.
Por outro lado, a engenharia de requisitos tem vindo a optar por técnicas que priviligiam a
vontade do utilizador final, tal como é referido em[HBL07, HHD16]. No artigo, "Requirements
in the 21st Century: Current Practice & Emerging Trends"[HBL07], os autores enunciam algu-
mas técnicas que são atualmente utilizadas de forma a melhor recolher as necessidades de um
sistema, entre as quais, métodos etnográficos, a prototipagem, entrevistas e "focus group", sendo
que esta última é mais usada entre as equipas analisadas ao longo deste estudo. Algumas das van-
tagens de utilizar técnicas centradas nos utilizadores finais são: a recolha de grandes quantidades
de informação sobre o campo em que se está a trabalhar, que permitem que as equipas discutam
sobre as principais funcionalidades do sistema, a descoberta de informação que poderia passar
despercebida usando técnicas menos centradas no utilizador final e a possibilidade de que os en-
genheiros de requisitos não tenham que ser especializados na área sobre a qual o sistema atua. Da
42
Metodologia e Objetivos
mesma forma, em [HHD16], os autores, após entrevistarem 9 especialistas na área da elicitação
de requisitos, afirmam que técnicas como as entrevistas, sessões colaborativas, sessões de "team-
building", observação, bem como, a criação de modelos representativos, podem representar um
grande aumento no nível de qualidade dos requisitos recolhidos.
Assim podemos concluir que, atualmente no campo da engenharia de requisitos a vontade e
os desejos do utilizador final têm grande importância, assim como, mais do que nunca é neces-
sário introduzir um lado mais criativo na maneira como o processo de elicitação de requisitos
ocorre, potenciando assim a criação de ideias originais e simultaneamente que correspondem às
necessidades dos utilizadores, criando assim soluções inovadoras. Como irá ser descrito na secção
seguinte, o Design Thinking é uma metodologia que tem vindo a ser utilizada de forma a ir ao
encontro desta tendência de crescente preocupação com o cliente final.
4.2 Uma metodologia para a criatividade: Design Thinking
A inovação é um fator determinante na sobrevivência das empresas e organizações, bem como
uma grande capacidade que estas têm para enfrentar os problemas que podem surgir no futuro
[Hsu13]. Antigamente a inovação era resumida à procura de novas soluções de cariz tecnológico,
contudo o conceito tem vindo a sofrer alterações e a passar a incluir também a criação de novas
formas de contacto com o cliente e de novas maneiras de ir ao encontro das suas necessidades e
expectativas [VVA+11].
Na busca pela inovação e de processos/metodologias que melhor captem as necessidades dos
clientes, surge o Design Thinking [VVA+11], uma metodologia baseada no ser humano e que pri-
vilegia um conhecimento mais profundo sobre os clientes ou utilizadores, trabalhando diretamente
com estes de forma a recolher informações relevantes e de cariz mais qualitativo [CBGL14], com
o objetivo de descobrir quais as reais expectativas ou necessidades do cliente e assim criar uma
solução que angariará maior sucesso. Em suma, o Design Thinking é uma metodologia que agrega
uma série de etapas que tem o objetivo de “observar, perceber e identificar o que um cliente quer
de um produto, serviço ou experiência. [CBGL14].
O Design Thinking tem como objetivo a busca por soluções que sejam viáveis em termos de
negócio, exequeíveis em termos tecnológicos e ao mesmo tempo sejam desejadas pelos clientes
[GH15, CBGL14]. Para isto, são introduzidos na fase inicial do projeto novas abordagens que es-
timulam por um lado a participação ativa dos clientes e utilizadores finais, bem como, a utilização
de processos que fomentem mais a criatividade.
No que diz respeito à criação de novas soluções de software, o problema de conseguir construir
sistemas que realmente enderecem as necessidades dos clientes ou utilizadores, é recorrente, sendo
que esta é considerada umas das maiores razões pela qual os projetos de software falham [Ree99,
Hum05]. Portanto, é necessário aplicar novos métodos no processo de elicitação requisitos de
modo a que seja possível criar soluções capazes de criar valor para o cliente ou utilizador final.
O Design Thinking é apontado diversas vezes como uma metodologia eficaz no que diz respeito à
satisfação das necessidades dos clientes [Bro08]).
43
Metodologia e Objetivos
No livro “Design Thinking” [VVA+11], são descritas as várias etapas desta metodologia, sendo
que estas são: imersão, fase em que a equipa responsável pela resolução do problema se inteira do
assunto do problema; ideação, fase em que a equipa começa a idealizar o produto final; e por fim,
a prototipagem, que consiste em criar modelos de baixa/média fidelidade, capazes de demonstrar
o produto a funcionar, possibilitando assim mais uma oportunidade para alguns melhoramentos
e/ou a validação do produto antes de uma fase de implementação.
Ao longo dos próximos tópicos serão apresentadas mais aprofundadamente estas fase, assim
como algumas técnicas que poderão ser utilizadas em cada uma dessas fases.
4.2.1 Imersão
Segundo [VVA+11], a primeira fase da metodologia de Design Thinking é dividida em duas
fases sequenciais. A primeira é a fase de imersão preliminar e a segunda é a fase de imersão
aprofundada.
Durante a imersão preliminar a equipa responsável por resolver o problema tem que perceber
quais são os problemas que o cliente tem de resolver e explorar estes problemas de vários pontos
de vista. Em [VVA+11], os autores consideram que ao longo a imersão preliminar a equipa
deverá realizar 3 tarefas: a reformulação do problema, uma pesquisa teórica sobre o tema e uma
pesquisa exploratória. Na reformulação do problema, o principal objetivo da equipa é analisar
o problema, tentando olhá-lo de diferentes perspetivas, colocando em causa todas as verdades
assumidas, fazendo assim que seja possível a mudança de paradigmas, possibilitando assim a
criação de soluções criativas. A pesquisa teórica diz respeito à procura de informação sobre o
tema do projeto nas várias fontes disponíveis, tais como, websites, blogs, revistas, jornais ou livros,
tendo como principal objetivo obter informação relativa a tendências na área na qual se desenvolve
o projeto, bem como ajudar a equipa a ter uma prespetiva sem ser aquela que é dada pelas partes
diretamente envolvidas no projeto. A última das 3 tarefas é a pesquisa exploratória, que consiste
em colocar os membros do projeto a observar e interagir dentro do contexto do problema, ajudando
a equipa a perceber melhor o ambiente em que o problema se desenrola.
Na fase de imersão aprofundada, o objetivo principal passa por perceber o que é que as pessoas
dizem e pensam sobre o tema do problema, como elas atuam em relação àquele problema e como
elas se sentem em relação a isso. Por outras palavras, esta fase tenta perceber mais aprofundada-
mente quais os sentimentos das pessoas envolvidas no projeto, previligiando consequentemente
o lado humano do problema. Ao longo desta fase são realizadas entrevistas e sessões de grupo,
nas quais se tenta obter informações sobre o dia-a-dia dos utilizadores, de que forma é que eles
vêm o problema e de que forma se sentem em relação a este. Outro tipo de técnicas que podem
ser utilizadas são técnicas que envolvem o acompanhamento do cliente ao longo de um dia ou du-
rante o período em que este está em contacto com o serviço em questão, conseguindo desta forma
observar quais os comportamentos deste e ao mesmo tempo analisando de forma mais eficaz os
sentimentos do utilizador sempre que está em contacto com o problema que está a ser resolvido.
44
Metodologia e Objetivos
4.2.2 Ideação
A fase de Ideação surge após a equipa ter recolhido a informação necessária para começar a
analizar o problema e a criar materiais que possibilitem a geração de ideias de uma futura solução.
Esta fase começa com a análise dos materiais obtidos no decorrer da fase anterior e finaliza com a
criação e organização das ideias originadas.
Para analisar as informações recolhidas durante a fase de imersão existem algumas técnicas
que podem ser usadas de modo a facilitar este processo, tais como, a utilização de “Insight cards”
onde vão sendo registradas as opiniões/sentimentos/desejos dos clientes finais, que podem depois
ser agregados conforme a sua temática, ajudando a ter uma visão mais geral sobre o sistema. Ou-
tra técnica que poderá ser usada são os mapas conceptuais, onde a informação é organizada em
esquemas, de forma a fornecer uma visão mais ampla dos dados recolhidos. A criação de Per-
sonas, que consiste na concepção de perfis de clientes com comportamentos extremos de modo
a que seja possível a melhor análise dos seu desejos e sentimentos, assim como, a previsão de
comportamentos futuros. Outra ferramenta que também poderá ser usada para uma melhor aná-
lise e sistematização da informação, é a jornada do utilizador, que consiste na análise dos vários
pontos de contacto que o cliente tem ao longo da sua relação com o produto/serviço que está a ser
estudado.
Após a informação recolhida juntos das várias fontes ao longo da fase de imersão ser anali-
sada e sintetizada, pode-se então recorrer uma série de ferramentas que ajudam à criação de novas
ideias e novos conceitos, entre as quais, o brainstorming e as sessões de co-criação. A primeira
consiste na elaboração de sessões onde a informação obtida na primeira fase, e posteriormente or-
ganizada, possa ser utilizada em sessões centradas no princípio de que “quanto maior for o número
de ideias gerado pela equipa, maior será a chanse de produzir uma solução inovadora e funcional”
[VVA+11]. Por outro lado, as sessões de co-criação, consistem em reuniões estruturadas de uma
maneira que promovem a criatividade bem como a colaboração entre pessoas de várias áreas de
conhecimento.
No fim destas sessões, a equipa já deve ter conseguido recolher um número considerável de
ideias, das quais apenas algumas poderão ser aplicadas, portanto poderão ser utilizadas algumas
técnicas que ajudam as equipas a filtrar as ideias que obtiveram. Uma dessas técnicas é a matriz
de decisão, onde nas colunas e nas linhas da matriz se encontram alguns critérios definidos pela
equipa, escolhendo-se depois as que melhor se adequam aos objetivos do projeto. Outra técnica
também mencionada em [VVA+11], é o menu de ideias, que consiste na criação de uma lista de
ideias, permitindo depois à equipa escolher quais é que querem implementar.
O principal objetivo no final desta fase, é conseguir ter um conjunto de ideias funcionais que
possam ser reproduzidos posteriormente num protótipo.
4.2.3 Prototipagem
A última fase da metodologia, prototipagem, tem como principal objetivo a validação das
ideias criadas na fase de ideação através da materialização das mesmas. Por outras palavras, a
45
Metodologia e Objetivos
prototipagem consiste no “acto de tornar uma ideia mais tangível” [VVA+11]. Esta técnica já é
utilizada na engenharia de requisitos e é uma das tendências nesta prática [HBL07], pois permite
aos intervenientes no projeto ter uma melhor visão sobre as ideias concebidas para o sistema. Ao
longo desta fase, as ideias do sistema poderão ser aprovadas ou rejeitadas, e simultaneamente
permite a criação de novas ideias que melhor se adquem ao problema.
Os protótipos poderão ser construídos com diferentes níveis de fidelidade, sendo que o ní-
vel mais baixo consiste em esquemas representativos da futura solução, e o nível mais alto é a
concepção de um modelo que permita a visualização da solução quase por completo.
Entre as várias técnicas de prototipagem enunciadas em [VVA+11], destacam-se a prototipa-
gem em papel, na qual se criam modelos de uma futura solução utilizando papel, de maneira a levar
o cliente final ou o utilizador a perceber melhor as ideias concebidas. A outra técnica, denominada
“storyboard”, baseia-se na criação de cenário onde são explicados os vários momentos nos quais
o utilizador recorre à solução criada. Para isso são criadas ilustrações desses vários momentos
e posteriormente colodadas de ordem cronológica de modo a permitir uma melhor visualização
da solução. No âmbito da engenharia de software poderão ser criadas aplicações estáticas que
materializem as ideias obtidas.
4.3 Metodologias Ágeis na Deloitte
A necessidade de inovação que se tem verificado nos últimos anos, levou a que a Deloitte
introduzisse novas práticas de maneira a agilizar os seus processos internos. Tendo isso em conta,
foi criada uma framework de desenvolvimento de projetos denominada “Digital Agility” e que
se divide em 3 fases distintas: Imagine, Deliver e Run. Esta foi desenvolvida recorrendo a uma
abordagem ágil que permite a incorporação nos projetos das melhores práticas de pensamento
criativo, desde os colaboradores da Deloitte até aos membros dos seus clientes. Esta metodologia
é utilizada de forma iterativa, sendo realizados vários sprints, melhorando de iteração em iteração.
Os objetivos desta framework passam por aproveitar os clientes atuais das empresas com quem
a Deloitte colabora e fornecer-lhes a possibilidade de explorarem novos mercados, ajudar os cli-
entes da Deloitte a melhor gerirem a inovação e aumentar a capacidade de resposta destes às
mudanças que vão ocorrendo nas várias indústrias.
Segundo o manual que explicita esta framework, a primeira fase, Imagine, consiste na pesquisa
e descoberta das necessidades dos utilizadores, identificando os pontos-chave da relação do cliente
com a organização.
Ao longo desta fase são estudadas as actuais tendências dos mercados, bem como as expecta-
tivas dos clientes para que seja possível recolher pontos de melhoramento. Esta fase é dividida em
duas etapas, a fase de Sense e Frame. A primeira etapa, tem como principal objetivo a exploração
mais profunda sobre o problema, colocando o cliente no centro das preocupações da equipa, fa-
zendo com que seja possível a identificação das suas principais necessidades e expectativas. Por
outro lado, a segunda etapa desta fase tem como objetivo a estruturação do conhecimento obtido
46
Metodologia e Objetivos
na fase anterior, percebendo de que forma as oportunidades existentes poderão ser aproveitadas
num contexto de negócio.
A segunda fase desta framework é a fase de Deliver, na qual a equipa começa a conceber o
produto, testando os conceitos obtidos anteriormente. Ao longo desta fase, as fronteiras do sistema
são definidas, a sua implementação planeada, protótipos são desenvolvidos. Esta fase, tal como a
primeira, é dividida em 2 etapas: Validate e Define. Durante a primeira etapa, as ideias obtidas na
fase Imagine são validadas de maneira a ser assegurado o sucesso final. Na etapa seguinte desta
fase, são definidos os requisitos para o desenvolvimento de um produto de sucesso.
A última fase desta framework, a fase Run, consiste na implementação e lançamento da apli-
cação/solução idealizada e planeada nas fases anteriores. Tal como as outras fases, esta também
é dividida em 2 etapas, sendo que a primeira a etapa Scale, tem como objetivo a construção do
sistema e entrega da solução que vai criar valor na organização. A outra etapa desta fase, a etapa
Operate, focasse na entrega de uma solução de excelência, otimizando os processos operacionais
de maneira a melhorar efetivamente a experiência do cliente.
4.3.1 Design thinking na Deloitte
A metodologia “Digital Agility” baseia-se nos princípios do design thinking pelo facto de dar
muita importância às necessidades do cliente final, contudo esta vai um pouco mais além, forne-
cendo também aos profissionais da Deloitte algumas ferramentas, materiais e linhas orientadoras
para a implementação do produto final, enquanto a metodologia Design Thinking centra-se na
construção da visão do sistema, estabelecimento das fronteiras do sistema e dos requisitos gerais
da solução.
As práticas do Design Thinking são introduzidas na metodologia da Deloitte através de workshops
durante a fase Imagine, sendo realizadas as três fases do Design thinking num mesmo workshop.
Para além disso, a equipa também idealiza o sistema com base nas três etapas do design thinking,
sendo que os workshops são realizados durante a fase de imersão de forma a percecionar as ex-
pectativas do utilizador final. Contudo, a abordagem da Deloitte à resolução criativa de problemas
contempla a definição de requisitos, desenho da arquitetura, entre outras atividades necessárias à
construção e entrega de uma solução, que vão muito para além do âmbito do design thinking.
4.3.2 Abordagem ao problema da dissertação
Ao longo desta dissertação, de forma a se construir a melhor solução possível para uma pla-
taforma de criação gestão de comunidades seguindo o modelo de P2PI para um seguro de saúde,
foi seguida a metodologia da Deloitte, “Digital Agility”, sendo que só foram realizadas as fases
Imagine e Deliver. Durante a fase Imagine, foram realizadas entrevistas e workshops de Design
Thinking de forma a conseguir detetar as várias entidades interessadas numa plataforma como esta,
funcionalidades esperadas e outros aspetos relacionados com a partilha de informação e privaci-
dade, sendo que numa fase posterior foi desenhada a jornada do utilizador e os primeiro protótipo
47
Metodologia e Objetivos
não funcional da solução. Ao longo da fase Deliver, foi desenvolvido um protótipo com as várias
funcionalidades escolhidas.
No capítulo que se segue, irá ser descrita a informação que foi obtida ao longo das várias ati-
vidades de elicitação de requisitos para uma plataforma de P2P Health Insurance. Posteriormente
nesta dissertação, irá ser apresentada a visão final do sistema e de que forma foi implementado o
protótipo funcional da solução.
48
Capítulo 5
Imersão, Ideação e Prototipagem
Tal como foi referido no capítulo anterior, ao longo desta dissertação foi seguido a metodo-
logia "Digital Agility”, usando entrevistas e workshops de Design Thinking de forma a conseguir
percecionar melhor quais os sentimentos e expectativas dos clientes finais em relação a um po-
tencial produto de P2P Health Insurance. Tanto os workshops, como as entrevistas realizadas,
tiveram a presença das várias partes interessadas na criação de uma plataforma deste género. Ao
longo deste projeto, foram entrevistadas 11 pessoas e realizados 3 workshops de Design Thinking,
envolvendo cerca de 17 pessoas, sendo criadas muitas ideias, funcionalidades e insights.
5.1 Entrevistas
O principal objetivo na realização das entrevistas exploratórias era tentar percecionar como as
pessoas interagem com o seu seguro de saúde, verificando a sua opinião em relação ao serviço
prestado, bem como, identificar expectativas não alcançadas e possíveis pontos de interação que
provocassem desconforto aos clientes. Por outro lado, também foram realizadas entrevistas com
pessoas sem seguro de saúde, de forma a analisar quais as razões que levam essas pessoas a
não aderirem a um seguro de saúde e tentar perceber de que forma é que as seguradoras podem
corresponder às expectativas desses potenciais clientes. Os clientes de seguros de saúde, assim
como, os potenciais clientes, que foram entrevistados ao longo desta dissertação, tinham idades
compreendidas entre os 23 e os 32 anos de idade, de forma a garantir que as suas opiniões serão
correspondentes à nova geração de utilizadores, os millenials.
Foram ainda entrevistadas duas outras partes interessadas, os prestadores de serviços de saúde
e os mediadores de seguros, de forma a entender como é que a gestão dos sinistros é feita atual-
mente, identificar pontos de melhoria nos processos relacionados com os seguros de saúde e ainda
quais os motivos que levam os clientes finais a ficarem descontentes com o serviço prestado pela
seguradora.
49
Imersão, Ideação e Prototipagem
5.1.1 Entrevistas a clientes de seguros e potenciais clientes
As entrevistas entre clientes jovens de seguros de saúde e potenciais clientes de seguros de
saúde, foram desenroladas seguindo uma estrutura semelhante, mudando apenas o ponto de vista
em que eram feitas as questões. Por exemplo, enquanto numa entrevista com um cliente de um
seguro de saúde, era perguntado quais os pontos de contacto com a sua seguradora que lhe provo-
cam mais desconfronto e quais as melhorias que sugeria para a sua seguradora, com um potencial
cliente seria perguntado, de que forma é que ele gostaria de contactar com a seguradora e quais os
serviços que o levariam a escolher uma seguradora em detrimento de outra.
Apesar de ter sido construída uma estrutura para entrevista, com alguns pontos que teriam
de ser abordados, o objetivo passava por construir uma conversa exploratória sobre a experiência
ou expectativa de experiência, onde o entrevistado falaria à vontade sobre a sua história com o
seguro de saúde, contando boas e más experiências suas e de pessoas próximas. A estrutura da
entrevista consistia em 3 partes, uma primeira dedicada a falar das novas tecnologias e novas
formas de negócio, onde a pessoa entrevistada era levada a falar sobre a sua experiência com a
utilização de dispositivos móveis e de plataformas P2P, tais como, o AirBnB, o CouchSurfing ou
o BlaBlaCar. Após esta parte, era pedido ao entrevistado que falasse sobre a sua experiência com
seguros de saúde. Caso o entrevistado tivesse um seguro de saúde, era perguntado quais os pontos
positivos de ter um seguro de saúde e quais os pontos em que a experiência de utilização poderia
ser melhorada, enumerando os vários processos inerentes a um seguro de saúde, tais como, a
simulação, a gestão de sinistros e a pesquisa por profissionais de saúde.
No caso de o entrevistado não possuir um seguro de saúde, o objetivo passaria por tentar
perceber porque é que não recorria a este tipo de serviço e quais as mudanças no serviço que o
poderiam levar a equacionar comprar um seguro de saúde. Na última fase da entrevista, o conceito
de P2P Insurance era apresentado ao participante da entrevista e de seguida era feita uma análise
exploratória sobre o tema, sendo o entrevistado convidado a refletir um pouco sobre as vantagens
e desvantagens de um produto desta categoria ligado à saúde.
Em relação aos entrevistados que possuíam seguro de saúde, é importante referir que das 4
pessoas entrevistas todas tinham seguro de saúde contratado pela entidade patronal ou pelo facto
do seguro do cônjuge cobrir os dois, e a idade dos entrevistados situava-se entre os 28 e os 32 anos.
De uma maneira geral os entrevistados usavam de forma frequente os seus dispositivos móveis,
possuindo telemóveis e também dispositivos de móveis de média dimensão. Quanto ao uso de
plataformas P2P, alguns referenciaram que conheciam todos os conceitos, contudo nunca tinham
utilizado nenhuma das anteriormente descritas, sendo que os motivos enunciados se prendiam com
a falta de oportunidade, no caso do AirBnB, e com algum receio nos casos do BlaBlaCar e Cou-
chSurfing. Quanto à opinião sobre o seguro de saúde, alguns dos entrevistados demonstraram que
não gostavam do facto de ser algo confuso a gestão dos vários orçamentos disponíveis e que apesar
das aplicações fornecidas estes acabavam por não controlar muito o estado do seguro. Outro ponto
negativo enumerado, foi a cobrança de despesas que eram feitas fora da rede de parceiros da segu-
radora, um processo que todos consideraram muito burocrático e que este excesso de burocracia
50
Imersão, Ideação e Prototipagem
levava a que muitas vezes as pessoas não declarassem se quer a despesa ao seguro. Quanto à pes-
quisa de prestadores de serviço de saúde, os entrevistados também referiram que apesar das suas
seguradoras, fornecerem uma aplicação, estes acabavam por recorrer aos prestadores de serviço
que eram aconselhados por amigos e familiares, principalmente quando se tratava de especialistas,
não se preocupando se estes tinham acordo ou não com a sua seguradora. Um dos entrevistados
referiu ainda que sentia que por ter um bom plano de saúde, que por vezes era sujeito a um excesso
de exames e tratamentos desnecessários. De uma forma geral, as pessoas entrevistadas sentiam
que o seguro de saúde correspondia ao serviço contratado, contudo o sentimento de falta de con-
trolo sobre as quantias que eram gastas foi unanime. Estes entrevistados, após a apresentação do
conceito de P2P Insurance, levantaram algumas reticências em relação à privacidade da informa-
ção do âmbito da saúde e aos membros que compunham a comunidade, no entanto, valorizaram o
facto de este conceito beneficiar os clientes com baixa taxa de sinistralidade e de poder haver uma
poupança.
No caso das duas pessoas entrevistadas sem seguro de saúde, a sua idade estava entre os 23
e os 24, sendo que em ambos os casos a pessoa se encontrava a iniciar uma carreira profissional.
As duas pessoas demonstraram que utilizavam os dispositivos móveis com muita frequência, reali-
zando no telemóvel um grande leque de operações, tais como, consulta do saldo da conta, consulta
de dados fiscais, chamada de meios de transporte e marcação de serviços. No entanto, estas duas
pessoas entrevistadas não possuíam um seguro, pois na sua opinião os seus gastos com saúde são
muito baixos e de momento a sua condição física não exige especial atenção, contudo consideram
que, no futuro, provavelmente recorrerão a um produto de seguro de saúde. Na opinião dos dois
entrevistados, o preço do seguro seria um factor importante na sua decisão, mas uma cobertura
alargada seria igualmente importante. Estes referiram, que o ideal seria gerir todo o seu seguro
através do computador ou do telemóvel, porém deveria existir algum ponto de contacto mais pes-
soal, como por exemplo um chat de apoio em tempo real ou uma linha de telefone de apoio. Sobre
o P2P, os dois entrevistados demonstraram grande abertura para a ideia contudo deveria também
levantaram questões relacionadas com a composição da comunidade e da privacidade, sendo que
valorizaram o facto de os utilizadores com menos ocorrências terem desconto, mas por outro lado,
referiram que viam como principal vantagem de um seguro de saúde o facto de estarem completa-
mente à vontade para usufruir, o que é colocado em causa quando recorrendo ao modelo do P2P
Insurance.
Em suma, com estas entrevistas, foi possível recolher uma série de informações importantes,
destacando-se as enumeradas a seguir:
• Muita burocracia relacionada com o processo de reclamação de despesas fora da rede de
parceiros da seguradora;
• Dificuldade em gerir os orçamentos disponíveis bem como a cobertura da apólice;
• A partilha de informação de saúde entre membros da comunidade deverá ser feita com
especial cuidado;
51
Imersão, Ideação e Prototipagem
• Os membros da comunidade terão de ter uma relação muito próxima entre si;
• A criação de um seguro de saúde subentende que o utilizador já está a pensar em ter alguns
encargos médicos.
5.1.2 Entrevistas a Prestadores de Serviços de Saúde
Ao longo desta investigação, foram também entrevistados 3 prestadores de serviços de saúde,
com o objetivo de perceber como é que era o processo de gestão de sinistros do lado do prestador
de serviço. Estas entrevistas foram realizadas através de telefone, para 3 clínicas de pequena/média
dimensão, sendo que as pessoas entrevistadas pertenciam ao departamento administrativo. Devido
à entrevista ser feita via telefone e ao tempo disponível ser pouco, a entrevista consistia em 3
simples perguntas: descrição do processo de reclamação da despesa junto da seguradora, quais os
pontos negativos na experiência com a seguradora, quais as melhorias que sugeriria.
As três pessoas entrevistadas referiram o mesmo processo de reclamação do sinistro, consis-
tindo no preenchimento de um formulário num portal online, sendo que o preço calculado para
o cliente final é calculado através da plataforma, após a inserção do tipo de ato médico que foi
praticado e do número do cliente em questão. Quanto aos pontos negativos, foi referido a perfor-
mance do portal, sendo que muitas vezes era impossível reportar despesas devido ao website estar
em baixo. Outro ponto negativo, foi o facto de muitas vezes as comissões pagas pelas seguradoras
para certos serviços serem muito baixas, o que pode levar à prestação de um serviço pior e à insa-
tisfação do cliente. Em relação às melhorias, as pessoas entrevistadas referiram que se os pontos
negativos fossem melhoradas já seria uma grande ajuda.
Concluindo, recorrendo a estas entrevistas, foi possível identificar os seguintes problemas,
relativos à relação das companhias de seguro com os prestadores de serviços de saúde:
• Plataforma que suporta a reclamação das despesas, tem pouca performance;
• Baixas comissões pagas em certos atos médicos.
5.1.3 Entrevistas a mediadores de seguros saúde
No decurso deste projeto de dissertação, foram entrevistados dois mediadores de seguros pre-
sencialmente, sendo que a entrevista também foi de curta duração, apenas de modo a perceber
de que forma os mediadores contactam o cliente e gerem a relação com ele após a subscrição de
um determinado seguro. As perguntas colocadas aos mediadores foram as seguintes: qual a sua
motivação em vender seguros de saúde, como costuma contactar os seus clientes antes e após a
subscrição do seguro, os seus clientes costumam apresentar alguns pontos negativos aos seguros
de saúde.
Ambos os mediadores foram concordantes na grande vantagem de vender os seguros de saúde
se prendia com o facto de eles ganharem uma comissão por cada subscrição, sendo que depois
disto, não tinham mais nenhuma preocupação com o seguro, visto que a taxa de sinistralidade do
cliente, nos seguros de saúde não os prejudica enquanto mediadores, ao contrário do que acontece
52
Imersão, Ideação e Prototipagem
com o seguro automóvel. Quanto à forma de contacto dos clientes, os dois mediadores dizem que
a angariação dos clientes é feita na base da sua rede de contactos, através dos balcões ou ainda
através de email, no entanto não existe nenhum processo pré-definido. Em relação ao contacto
após a subscrição da apólice, os mediadores confessaram que raramente contactam com o cliente
após o momento da subscrição e o momento da renovação da mesma, falando com ele apenas
esporadicamente para o esclarecimento de uma dúvida ou pedido de uma informação. No que
toca a pontos negativos evidenciados pelos clientes dos mediadores, estão por vezes reclamações
pela falta de prestadores de serviços médicos com parceria sem ser nos grandes centros urbanos e
por vezes alguns mal entendidos devido à falta de informação em relação à cobertura da apólice.
5.2 Workshops
Com o objetivo de aplicar a metodologia Design Thinking, foi estruturados 3 workshops de
forma a explorar criativamente o tema desta dissertação, criando conhecimento para uma com-
preensão mais profunda para a construção do protótipo. Após uma pesquisa bibliográfica sobre
o tema e ter entrevistado os vários possíveis intervenientes numa plataforma deste género, era
importante conseguir perceber que funcionalidades o público-alvo desta aplicação gostaria de ter
disponíveis numa plataforma deste género. Sendo assim, os participantes nestas sessões de traba-
lho, realizariam toda a jornada do Design Thinking, passando pelas suas 3 fases, Imersão, Ideação
e Prototipagem. Embora os temas sobre os workshops fossem sensivelmente diferentes, o tema
dos seguros de saúde foi recorrente nos três workshops, assim como, o facto de todos passarem pe-
las diferentes fases do Design Thinking. No entanto, cada workshop evoluiu de uma forma única,
levando a que muitas vezes o tempo dispensado em cada uma das fases fosse substancialmente
diferente.
A primeira parte dos workshops, tinha como objetivo levar os participantes a entrarem no con-
texto pretendido, os seguros de saúde, de forma a realizar a fase de Imersão do Design Thinking.
Ao longo desta primeira fase os moderadores da sessão, deveriam fomentar a discussão, fazendo
perguntas relacionadas com o tema da sessão, levando os participantes a falar sobre as suas ex-
periências e opiniões. Durante esta fase, de forma a reunir o máximo de informação possível,
os convidados faziam também um levantamento dos pontos negativos e positivos sobre o tema
em questão, usando post-it de forma a criar um visão global para todos os participantes. Fina-
lizada esta atividade, os participantes apresentavam os pontos positivos e negativos que tinham
referido, com o objetivo de gerar discussão entre os vários membros da sessão, corroborando ou
discordando dos pontos apresentados.
Depois dos elementos se terem debatido sobre o tema do workshop, era pedido para que, tendo
em conta os pontos positivos e negativos anteriormente indicados, que pensassem em soluções
para melhorar a experiência de utilização em relação ao tema da sessão ou que criassem ideias
originais para lidar com o problema em questão. A esta parte do workshop corresponde a parte
da Ideação do Design Thinking. Após uma breve discussão, os participantes eram convidados a
escreverem as suas ideias e a colocá-las na parede através de post-it, para que ficassem registadas
53
Imersão, Ideação e Prototipagem
para toda a gente ver nas fases posteriores. Em alguns casos, os convidados podiam ser levados a
idear sobre um problema que tinha sido previamente identificado nas entrevistas. Nesta fase, de
maneira a conseguir ideias realmente inovadoras e fora do comum, era pedido aos participantes
que criassem algumas ideias que, apesar de eles acharem impossíveis ou descabidas, pudessem
ajudar o cliente no seu dia-a-dia.
Depois da Ideação, seguia-se a fase de Prototipagem, onde os vários participantes eram convi-
dados a escolher dois ou três cenários de utilização de uma plataforma de P2P Health Insurance,
e aplicarem algumas das ideias criadas ou resolverem um problema que tinha sido apontado an-
teriormente, através da realização de um protótipo em papel. Aos convidados eram fornecidos
vários materiais, tais como, folhas de papel A4 e A3, marcadores e canetas de várias cores, cola,
entre outros, e o objetivo passava por criar um esquema que representasse uma determinada funci-
onalidade de um portal online. Após a construção do protótipo em papel, seguia-se uma pequena
apresentação da solução criada, bem como, um momento de perguntas e respostas, no qual os
vários participantes colocavam questões sobre as funcionalidades apresentadas.
Após a apresentação dos esquemas ou protótipos de baixa fidelidade e, seguia-se um momento
de explicação sobre o workshop, isto é, era explicado aos participantes quais tinham sido as fases
por que se tinha passado ao longo da sessão e era apresentado o método Design Thinking. O motivo
pelo qual foi decido fazer isto no fim, prende-se com o facto de não se querer condicionar os
participantes do workshop de nenhuma maneira, levando os convidados a pensar que não existem
muitas regras, de forma a criar descontração e um ambiente favorável à criação de ideias. O
workshop termina com os elementos participantes a fazerem uma revisão à sessão que foi realizada
e a fornecerem sugestões para otimizar futuras sessões.
5.2.1 Workshop 1: Seguros, Seguros e Seguros de Saúde
O primeiro workshop foi realizado com seis participantes, com idades compreendidas entre os
21 e os 31 anos e o tema sobre o qual se debruçou mais, foi a indústria seguradora e como o modelo
P2PI pode resolver os problemas que este sector ainda cria aos seus clientes. É relevante ressalvar
que os participantes nesta sessão, eram todos colaboradores da Deloitte na área da indústria finan-
ceira, daí terem elevado conhecimento sobre o setor segurador. A sessão começou com algumas
perguntas com o objetivo de motivar os convidados a falaram sobre a sua experiência com seguros,
nomeadamente seguros de saúde. A discussão iniciou-se e as opiniões foram-se sucedendo, com
todos os elementos a apresentarem pontos positivos e negativos sobre as suas experiência com as
seguradoras. Após um momento de debate, os participantes foram convidados a registar em post-
its os pontos negativos e positivos sobre a sua relação com as seguradoras, seguindo-se um breve
momento de discussão sobre os pontos apresentados.
Entre os pontos positivos apresentados, sendo que entre estes se encontram também alguns
desejos de melhoria dos participantes, destacam-se os seguintes:
• A vontade de angariar o melhor preço possível com a cobertura necessária;
• O desejo de querer realizar simulações sem ter que fornecer nenhum contacto;
54
Imersão, Ideação e Prototipagem
• A ambição por uma melhor experiência de utilização, nomeadamente, com o recurso a apli-
cações mobile e web;
• O facto do tempo entre a simulação e a subscrição ser baixo.
Figura 5.1: Fotografia recolhida no primeiro workshop
Entre os pontos pontos negativos registrados ao longo desta sessão destacam-se os seguintes:
• A demora na resolução dos sinistros;
• O excesso de burocracia para a entrega de faturas em prestadores sem acordos;
• Pouca personalização dos produtos oferecidos;
• Pouca comunicação entre as seguradoras e os segurados após o momento da subscrição;
• Condições pouco claras ou confusas para o cliente final;
• Excesso de informação necessário para conseguir realizar uma simulação
• Pouca confiança entre os segurados e as seguradoras
• Venda de seguros ainda estar muito focada nos Pontos de Venda tradicionais, o que implica
a deslocação ao local.
Após este momento, foi apresentado o conceito de P2P Insurance e os convidados foram leva-
dos a debater o tema. Depois disto a imersão no tema pretendido estava concluída e os convidados
realizaram um momento de ideação sobre como estas plataformas podiam resolver os vários pro-
blemas que as seguradoras têm. No entanto, este momento de ideação foi orientado a 3 áreas
importantes do P2P Health Insurance, que tinham sido identificas previamente, nas entrevistas e
na pesquisa previamente realizada: a gestão da apólice, a sensibilidade da informação partilhada
e criação de confiança entre os membros da comunidade.
55
Imersão, Ideação e Prototipagem
No que toca à gestão da apólice foram identificadas as seguintes ideias ou funcionalidades que
o cliente final poderia valorizar:
• Simulação e subscrição da apólice online;
• Simplificação dos formulários e brochuras que explicam as coberturas dos seguros
• Infografias com o atual estado da apólice, contendo gráficos com os gastos e orçamentos
ainda disponíveis;
• Possibilidade de contacto mais pessoal com o cliente, quer por email, telefone ou mensagens
instantâneas;
• Simplificação do processo de submissão de despesas através do website;
• Incentivar a comunidade a realizar atividades de saúde, beneficiando aquelas que apresen-
tem maior grau de esforço.
Em termos de ideias geradas no âmbito da sensibilidade da informação partilhada destacam-se
aquelas enumeradas em baixo:
• Possibilidade de partilha de atividades de saúde, integrando com redes sociais, como o Twit-
ter, Instagram e Facebook;
• Simplificação dos formulários e brochuras que explicam as coberturas dos seguros
• Partilha das despesas dos vários membros da comunidade;
• Possibilidade de cada comunidade escolher o grau de privacidade que pretende;
• Partilha do valor e do tipo geral de cuidado médico realizado, isto é se foi uma consulta ou
um exame, contudo não partilhar informação muito específica sobre o serviço prestado;
• Possibilidade de fornecer e consultar informação relativa a profissionais de saúde.
Em relação às ideias geradas para a criação de confiança e espírito de comunidade entre os
vários membros da comunidade, foram apontadas as seguintes ideias:
• Criação de dinâmicas de competição entre os vários membros da comunidade e as comuni-
dades, tanto a nível de gastos como a nível de atividades de saúde.
• Possibilidade de partilha dos feitos conseguidos entre os vários membros da comunidade;
• Restrição do número de pessoas por comunidade;
• Permitir apenas que sejam os membros da comunidade a definir quem faz parte da comuni-
dade;
56
Imersão, Ideação e Prototipagem
Posteriormente a esta sessão de ideação sobre estas três áreas específicas, os elementos es-
colheram alguns cenários de utilização e desenvolveram um protótipo de baixa fidelidade, com
as algumas funcionalidades capazes de resolverem alguns problemas. Para isso, os convidados
foram divididos em dois grupos, escolhendo entre si os cenários/problemas sobre os quais iriam
criar funcionalidades.
O protótipo do primeiro grupo focou-se em três cenários distintos, a procura por prestadores
de saúde, a consulta do atual estado do seguros e a submissão de despesas realizadas em prestado-
res fora da rede. No primeiro cenário, representado à esquerda, o grupo sugeriu criar um motor de
busca inspirado em sites como Tripadvisor, no qual as pessoas têm acesso a informação dos pres-
tadores de serviços de saúde, assim como, comentários de pacientes anteriores e uma pontuação
associada. Para o segundo cenário referido, representado no centro, o grupo sugere um o acesso às
despesas e orçamentos da comunidade através de um gráfico, mostrando visualmente quais foram
as despesas e quais os valores ainda disponíveis. Para o ultimo cenário, o grupo sugeriu que o
processo de submissão de despesas fosse feito totalmente na plataforma, através da submissão das
faturas digitalizadas.
Figura 5.2: Esquema representativo do protótipo do primeiro grupo do workshop 1
O segundo grupo apresentou um esquema de uma possível solução também para três cenários,
contudo dois dos três cenários diferentes do grupo apresentado anteriormente. Este grupo escolheu
o cenário da adesão, recolha de sugestões do prestador e, tal como o grupo anterior, o controlo do
estado atual do seguro. No primeiro cenário, o grupo sugeriu que a adesão deveria usar as redes
sociais para ser o mais rápida possível, sugerindo imediatamente alguns possíveis membros para a
comunidade ou algumas comunidades. No segundo cenário, o grupo sugeriu que fosse criado um
portal que os prestadores de serviços de saúde poderiam utilizar no qual podiam reportar as des-
pesas à seguradora, contudo estas despesas tinham de ser posteriormente aprovadas pelo paciente.
No controlo das despesas de saúde da comunidade, o grupo sugeriu uma solução semelhante ao
protótipo anterior, contudo com uma nova funcionalidade, um mural onde apareceriam as várias
despesas conforme eram efetuadas e informações que eram partilhadas entre os vários membros
57
Imersão, Ideação e Prototipagem
da comunidade.
Figura 5.3: Esquema representativo do protótipo do segundo grupo do workshop 1
O workshop terminou com a apresentação dos protótipos anteriormente mostrados, seguida de
uma breve explicação sobre alguns conceitos do Design Thinking e recolha de algumas sugestões
para futuras sessões semelhantes. De uma forma geral, todos os participantes apreciaram muito
esta nova forma de percecionar as reais necessidades e expectativas dos clientes, sendo que apenas
sugeriram que a parte da ideação fosse não fosse focada em áreas, uma vez que existem ideias que
podem ser transversais às várias áreas.
Após a conclusão do workshop e análise das várias informações, foi possível retirar algumas
ilações sobre a temática dos seguros e do P2P Insurance, destacando-se as seguintes:
• As pessoas vêm um seguro de saúde como um seguro de consumo, não vendo como possível
forma a garantir suporte numa situação de maior dificuldade;
• A burocracia existente continua a proporcionar uma má experiência de utilização aos clien-
tes;
• P2P Insurance, fará mais sentido em comunidades de tamanho pequeno e no qual as pessoas
tenham relações estreitas umas com as outras, por exemplo, família ou amigos;
• As comunidades criadas podem também ser criadas tendo em vista as áreas de interesse dos
membros ou a necessidade de cuidados médicos semelhantes;
• O facto de existirem membro com diferentes graus de risco tem de ser tido em atenção
aquando da construção da plataforma;
• A informação a ser partilhada sobre os cuidados de sáude entre os membros da comunidade,
deverá ser sempre geral e nunca muito específica;
• A procura de profissionais de saúde de qualidade é um problema para as pessoas, principal-
mente quando se encontram numa cidade que desconhecem.
58
Imersão, Ideação e Prototipagem
5.2.2 Workshop 2: Comunidade e Saúde
O segundo workshop realizou-se sobre o tema Comunidade e Saúde e o grande objetivo deste
workshop era saber de que forma é que uma possível plataforma P2P de um seguro de saúde, po-
deria ser construída de forma a aproveitar ao máximo as potencialidades da comunidade e ajudar
as pessoas na gestão da sua saúde. Nesta sessão participaram seis pessoas, com idades compreen-
didas entre os 21 e os 26 anos, sendo que três tinham formação superior na área de saúde.
A primeira parte do workshop, correspondente à imersão, foi um pouco diferente nesta sessão,
uma vez que não fazia sentido fazer um levantamento de pontos positivos em relação à indústria
seguradora, pois os participantes ainda não tinham muita experiência nessa área. Portanto, optou-
se por começar o workshop, pela apresentação do conceito do P2P Insurance, apresentando as
vantagens, desvantagens e alguns exemplos. De seguida, os elementos da sessão iniciaram uma
discussão sobre o tema, tentando perceber o conceito, levantado simultaneamente alguns pontos
positivos e alguns receios em relação a este conceito. O principal ponto positivo foi o facto de ser
possível ter um seguro de saúde para um eventual imprevisto a um preço reduzido, enquanto os
pontos negativos estavam relacionados com a privacidade e com a geração de confiança entre os
membros da comunidade.
Após um debate sobre os prós e contras do P2P Insurance, os participantes foram convidados
a gerarem ideias de forma a combaterem os receios anteriormente referidos e, ao mesmo tempo,
aproveitarem as potencialidades de uma plataforma online para resolverem alguns problemas que
são comuns quando lidamos com aspetos de saúde. Posto isto, e após alguns momentos de reflexão
os participantes foram surgindo ideias, realizando um brainstorming sobre este tema. As principais
ideias resultantes desta atividade foram as seguintes:
• Conseguir aceder a informação dos restantes membros da comunidade, mesmo sendo refe-
rentes ao período anterior à criação da comunidade;
• Criar sistemas de classificação sa comunidade e os membros da mesma, de forma a sabermos
mais sobre a comunidade e os seus membros e em que posição estão em relação às restantes,
sendo mais baixa consoante os gastos que realiza
• Requerer um relatório médico no inicio da apólice, para garantir que a pessoa está saudável;
• Fornecer um sistema que procura prestadores de serviços de saúde, bem como, os organiza
por especialidade e qualidade do serviço prestado;
• Estabelecer meios de comunicação entre os membros da comunidade, os prestadores de
cuidados de saúde e as seguradoras;
• Atribuir vantagens aos elementos da comunidade e às comunidades que se esforcem mais
para ter um estilo de vida saudável.
Após o momento de ideação, os participantes desta sessão foram convidados a realizar um
protótipo em papel de uma possível solução, escolhendo alguns cenários no qual o utilizador final
59
Imersão, Ideação e Prototipagem
pudesse utilizar a aplicação. Os seis elementos, foram divididos em três grupos sendo criados 3
esquemas de uma possível solução. O primeiro protótipo criado centrava-se nos dois seguintes
cenários: o controlo das despesas da comunidade e um sistema de classificação para criação de
confiança entre os membros da comunidade.
Este grupo sugeriu que deveria haver uma página onde existiriam gráficos e infografias com
as despesas da comunidade, tal como os grupos já tinham indicado no anterior workshop. A
parte mais inovadora introduzida por este grupo, foi o seu sistema de avaliação/classificação dos
membros e das comunidades. Estes dois participantes, sugeriram que se um elemento estivesse a
gastar acima da média, a sua classificação iria diminuindo conforme o afastamento para da média,
sendo que este teria de justificar os gastos quando o estes correspondiam a cerca do dobro da média
da comunidade. Assim as pessoas poderiam ver qual o nível de gasto dos seus pares sem terem
que ter acesso a informação delicada, havendo apenas uma justificação sempre que os gastos eram
realmente grandes.
Figura 5.4: Esquema representativo do protótipo do primeiro grupo do workshop 2
O segundo grupo criou um protótipo que contempla dois cenários distintos: o controlo das
atividades do grupo e o registro e criação das comunidades. No que toca ao registo, este grupo
propõe que seja colocado um breve questionário médico de forma a avaliar o risco do cliente,
sendo que de seguida seriam sugeridas comunidades baseadas no risco desse cliente. Em relação à
gestão e consulta das atividades da comunidade, este grupo sugere que a comunidade deverá poder
gerir as regras de privacidade, comunicar problemas com a seguradora e deveria existir ainda um
espaço par compra e venda de medicamentos e outros equipamentos de saúde. Os elementos do
grupo referiram também que deveria existir um mecanismo de classificação dos elementos e da
comunidade, contudo não forneceram um modelo a adotar.
O último grupo, apresentou um protótipo focado na gestão das despesas da comunidade e na
procura de prestadores de serviços de saúde. No que toca à gestão das despesas a comunidade e
cada membro tinha um histórico de atividades, no qual se poderia consultar as várias ativações do
60
Imersão, Ideação e Prototipagem
Figura 5.5: Esquema representativo do protótipo do segundo grupo do workshop 2
seguro, contudo o membro em questão tinha a opção se queria ver revelados detalhes ou não. Em
relação à procura de prestadores de serviços de saúde, este grupo, tal como já tinha sugerido outro
grupo no workshop anterior, propõe a criação de um motor de busca semelhante a plataformas
como o TripAdvisor, providenciando a hipótese de ler comentários de utilizadores anteriores e
avaliação do serviço prestado. Para criar confiança em relação aos membros da comunidade, este
grupo sugere a criação de um campo de comentários e de avaliação, para que seja possível avaliar
os membros.
Figura 5.6: Esquema representativo do protótipo do terceiro grupo do workshop 2
No final da apresentação dos protótipos dos vários grupos, foi explicado aos elementos par-
ticipantes quais os objetivos da sessão, qual era a metodologia que estava a ser utilizada e foram
ainda pedidas sugestões para eventuais futuras sessões, no entanto, os participantes não fornece-
ram nenhuma sugestão. Após a conclusão da sessão e análise dos resultados obtidos, retiraram-se
os seguintes insights em relação à construção da plataforma e experiência de utilização do seguro:
• A informação partilhada é de sensibilidade especial, sendo que é importante fornecer às
pessoas opções de configuração neste campo;
61
Imersão, Ideação e Prototipagem
• Os utilizadores não deverão ser incomodados com preenchimentos desnecessários;
• É necessário incluir vantagens que sejam palpáveis para todas as pessoas da cadeia de va-
lor de um seguro de saúde, desde as seguradoras de saúde, passando pelos prestadores de
serviços de saúde, até aos clientes;
• A criação de confiança entre membros da comunidade terá de respeitar a privacidade dos
membros, contudo obrigará à divulgação de informações.
5.2.3 Workshop 3: Seguros e Saúde
O terceiro e último workshop, teve como tema central a saúde e de que forma os seguros aju-
dam a termos uma melhor experiência nesta área. Nesta sessão participaram 5 pessoas, com idades
compreendidas entro os 22 e os 28 anos, participando inclusivamente dois profissionais do ramo
da saúde. Durante a fase imersão deste workshop, foi em primeiro lugar abordado o tema da saúde
e só depois o P2P Insurance, tendo o workshop começado com os participantes a contarem as suas
experiências no campo da saúde. Posteriormente, foi pedido aos convidados para registrarem em
post-its alguns pontos que consideravam positivos e negativos na sua experiência de utilização dos
prestadores de serviços de saúde, sendo que os pontos positivos foram os seguintes:
• O facto de em alguns hospitais haver um grande histórico do paciente, principalmente no
sector público, o que permite um melhor tratamento e diagnóstico do paciente;
• O estabelecimento de uma relação de confiança com o prestador do serviço de saúde, leva
a que problemas urgentes possam ser facilmente resolvidos e a um maior sentimento de
segurança.
• O facto de conseguir aceder a profissionais de saúde de excelência quando se tem um bom
seguro de saúde.
Contudo, foram também enumerados muitos pontos negativos na experiência de utilização dos
serviços de saúde:
• Muita dificuldade na marcação de consultas, tanto na ótica do paciente como do prestador
de serviço de saúde;
• Tempos de espera por vezes elevados;
• Adiamento das consultas, tanto na ótica do paciente como do prestador de serviço de saúde
• Falta de atenção e cuidado no serviço prestado, bem como, falta de disponibilidade dos
funcionários na resolução dos problemas dos pacientes;
• Falta de ética profissional, leva muitas vezes os clientes a receberem mais tratamentos do
que aqueles que deveriam;
62
Imersão, Ideação e Prototipagem
• O facto de muitas vezes os profissionais de saúde, não terem o tempo suficiente para ava-
liar um determinado paciente, levando a que muitas decisões sejam tomadas seguindo uma
atitude “One size fits all”, criando muitas vezes problemas aos pacientes evitáveis.
Figura 5.7: Fotografia dos participantes no workshop 3 a realizarem os seus protótipos
Depois da discussão sobre saúde, seguiu-se a apresentação do conceito de P2P Insurance,
esclarecendo os participantes sobre as vantagens e desvantagens desta nova forma de vender se-
guros. Após este momento, os participantes foram levados a criar ideias que combatessem os seus
problemas relacionados com a saúde, através da utilização de uma plataforma online. As cinco
pessoas participantes na sessão, foram divididas em dois grupos, realizando entre si um momento
de brainstorming, de forma a construírem um protótipo.
O primeiro grupo desenvolveu um protótipo, que contemplava as seguintes funcionalidades
para ajudar as pessoas na gestão dos seus cuidados médicos e ajudar na gestão do seguro de saúde:
• Possibilidade de marcação de consulta, conseguindo consultar comentários de pacientes
anteriores e informações relativas às especializações do profissional de saúde;
• Conseguir ver a informação relativa à apólice, conseguindo consultar as despesas anteriores
e ver quais os orçamentos ainda disponíveis;
• Possibilidade de aceder ao histórico clínico e informações relativas a análises e exames,
eliminando a necessidade impressão dos mesmos, fazendo com que a informação flua entre
os prestadores de serviços de saúde usando apenas a plataforma;
• Nas comunidades, os membros poderiam ter um orçamento disponível para gatar sem que
os seus pares saibam que ele gastou e como gastou, sendo a comunidade informada apenas
para despesas maiores;
• Possibilitar o agendamento de consultas diretamente com o profissional de saúde;
63
Imersão, Ideação e Prototipagem
• Criação de fóruns de perguntas e respostas, onde os profissionais de saúde poderiam escla-
recer pequenas dúvidas ou colocar pequenos artigos com matérias de saúde;
• Incorporar algum sistema que possibilite que os pacientes consigam avisar mais rapidamente
as clínicas caso surja algum imprevisto que os impossibilite de ir às sessões agendadas,
otimizando assim a gestão dos recursos disponíveis.
Figura 5.8: Esquema representativo do protótipo do primeiro grupo do workshop 3
O segundo grupo, dividiu o protótipo construído em quatro grupos de funcionalidades: marca-
ção de consultas, gestão do histórico clínico, sistema de avaliações e gestão da informação relativa
aos participantes. No caso da marcação duma consulta, o paciente poderia escolher se queria mar-
car o mais rapidamente possível se quer marcar numa data específica, encontrando logo qual o
prestador de serviço mais próximo. Em relação ao histórico, o utilizador teria acesso a todas as
consultas realizadas por si, desde que ingressou na plataforma, assim como, exames e medicações
prescritos. Para a partilha de informação entre os membros da comunidade, este grupo sugeriu
que, se criasse um mural com todos os eventos que iam sendo reportados pelos vários membros.
O sistema de avaliação proposto por estes participantes, consistiria na possibilidade dos utiliza-
dores da plataforma conseguirem avaliar os vários prestadores de serviços de saúde, presentes na
plataforma. Por fim, estes participantes no workshop, referiram que seria interessante incluir al-
guma funcionalidade que permitisse o contacto com o profissional de saúde via videoconferência
e envio de fotos para monitorização de uma certa lesão.
À semelhança dos workshps anteriores, após a apresentação dos protótipos pelos dois grupos,
seguiu-se um momento de explicação da metodologia Design Thinking e recolha de sugestões
para sessões futuras. As principais conclusões retiradas deste workshop foram as seguintes:
• O histórico clinico, assim como, a baixa rotatividade dos profissionais de saúde são de
importância estratégica para um bom serviço de saúde;
64
Imersão, Ideação e Prototipagem
Figura 5.9: Esquema representativo do protótipo do segundo grupo do workshop 3
• A insatisfação das pessoas relativamente a alguns profissionais de saúde é notória, com os
participantes a revelarem a enorme falta de atenção ao detalhe no serviço que é prestado e
até alguma arrogância por parte de alguns profissionais;
• Os sistemas de recolha de feedback e de avaliação de profissionais de saúde, são sem dúvida
necessários, principalmente para pessoas que se encontram a viver fora da sua área de resi-
dência, precisando muitas vezes de recorrer a serviços de saúde e não têm ninguém capaz
de lhes fornecer referências de profissionais de saúde;
• O agendamento de consultas é um problema que existe, com muitos clientes a terem que
esperar muito tempo para marcarem uma consulta e a não conseguirem agendar para o
profissional desejado dentro de um prazo razoável;
• Na plataforma P2P deverá ser muito subtil a forma como os pares se controlam uns aos
outros, não gerando desconforto aos membros pelo conteúdo da informação partilhada.
5.3 Conclusões
5.3.1 Workshops e Entrevistas: Lições para o Futuro
O recurso destas duas ferramentas para a identificação de problemas e oportunidades para a
construção de uma aplicação web de P2P Health Insurance, demonstrou-se bastante útil e eficaz,
produzindo um alargado número de ilações que serão muito importantes para a construção de uma
plataforma que visa a resolver os problemas dos clientes e a otimizar as experiências de utilização
dos mesmos. Recorrendo a este método, os analistas de negócio podem criar, definitivamente,
maior empatia com os utilizadores, quando comparando com outras técnicas, como questionários.
65
Imersão, Ideação e Prototipagem
Usando esta técnica, os analistas podem sentir quais as verdadeiras ambições e expectativas dos
clientes e assim construir sistemas que realmente criem valor na vida destes.
Do ponto de vista dos resultados obtidos, os workshops são um método mais poderoso que as
entrevistas, fornecendo mais materiais que podem ser analisados e um maior número de insights,
muito devido ao confronto de ideias entre os vários participantes e ao facto destes serem levados
a usar o seu lado mais criativo. Contudo, reunir um conjunto de 5 ou mais pessoas na mesma sala
por um tempo alargado, é mais difícil do que conseguir realizar entrevistas, mas sem dúvida que
os resultados obtidos compensam o esforço.
Para maximizar os resultados obtidos nas entrevistas e nos workshops é importante tentar criar
um ambiente de alguma descontração, fazendo com que os participantes estejam confortáveis e
à vontade para darem as suas opiniões, sendo também importante não permitir que elementos
julguem a opinião de outros participantes e que não haja um participante que pela sua excessiva
participação, condicione a dos restantes. É importante também criar uma estrutura para estas
atividades, bem como, recolher alguns factos e histórias interessantes que possam fomentar a
discussão entre os vários participantes, no entanto, o moderador do workshop, ou entrevistador,
tem de conseguir ter alguma flexibilidade para deixar que o workshop ou entrevista flua de forma
natural, embora não permitindo que os participantes se afastem do tema central da discussão.
Por último, referir que é muito importante registar toda a informação e insights que são re-
feridos, pois caso contrário, muitos dos resultados do workshop e da entrevista irão ser perdidos.
O moderador destas atividades pode optar por gravar quer em vídeo quer em áudio, contudo ao
longo desta pesquisa foi notado que as pessoas tendem a ficar um pouco condicionadas quando isso
acontece, motivo pelo qual os workshops e as últimas entrevistas não foram registadas recorrendo
a meios audiovisuais.
5.3.2 Oportunidade e Problemas
Depois da realização de 11 entrevistas e 3 workshops é possível identificar uma série de proble-
máticas nas quais uma plataforma de P2P Health Insurance poderá ter um papel muito importante
na sua mitigação. Estes problemas afetam tanto profissionais de saúde, profissionais da indús-
tria seguradora, como clientes/pacientes, sendo que estes problemas podem ser agrupados em três
áreas de atuação sobre as quais uma aplicação P2P de seguros de saúde terá de intervir. Essas
três áreas são: a gestão da apólice do seguro, que diz respeito à realização dos processos relativos
aos seguros de saúde; a gestão dos cuidados médicos, relacionada com a coordenação de ativi-
dades relacionadas com a saúde dos utilizadores; e, por último, a motivação da comunidade para
bons comportamentos, tanto a nível gastos realizados, como a nível de atividades de promoção da
saúde.
Relativamente à gestão da apólice do seguro saúde, é possível concluir que os problemas
encontrados estão relacionados com os processos de simulação, subscrição, controlo de despesas
e o reportamento de despesas fora das redes de prestadores de serviços de saúde. Ao longo dos
workshops e das entrevistas, foi possível identificar que estes problemas poderiam ser resolvidos
recorrendo a um portal online que permitisse a realização destes processos, bem como, fornecesse
66
Imersão, Ideação e Prototipagem
gráficos, infografias e esquemas que tornassem mais fácil a compreensão dos gastos realizados,
dos orçamentos disponíveis e da cobertura do sistema.
Quanto à gestão dos cuidados de saúde, foram apontados os seguintes problemas: dificuldade
na procura de profissionais de saúde de referência, demora na marcação de consultas, falta de cui-
dado e atenção no serviço prestado, falta de histórico clínico (principalmente no sector privado da
saúde) e a falta de ética profissional, que leva por vezes os pacientes a recorrerem a tratamentos
que muitas vezes não necessitam. Para estes problemas foram sugeridas as seguintes funcionalida-
des: um motor de busca que permita a procura de profissionais de saúde, a possibilidade de avaliar
o prestador de serviço, a criação de um repositório com as várias informações relativas à saúde
do utilizador, a criação de um portal para marcação de consultas e tratamentos online e ainda a
possibilidade de reportar casos de abuso por parte dos profissionais de saúde.
Em relação à motivação da comunidade para bons comportamentos, foram identificadas várias
oportunidades, contudo, também foram apontadas assuntos sobre os quais se tem de ter especial
atenção. Entre os pontos que requerem mais atenção está a sensibilidade da informação respei-
tante a um seguro de saúde, pois facilmente se pode colocar a privacidade dos utilizadores em
risco. Por outro lado, também é preciso atribuir especial atenção ao facto de terem que existir
mecanismos para a criação de confiança entre os vários membros, oferecendo a opção de banir
membros tóxicos, partilha de informação entre os membros e consulta do histórico anterior à for-
mação da comunidade para atestar o bom comportamento. Entre as oportunidades, destaca-se a
possibilidade de criar dinâmicas de competição entre os vários membros da comunidade, tanto
para diminuir os gastos totais com o seguro de saúde, fornecendo a possibilidade de poupança no
final do ano, quer a nível de bons hábito de saúde, fornecendo vantagens aos membros mais ativos
e ao mesmo tempo motivando os mais sedentários.
Estas oportunidades e problemas que foram identificados ao longo deste trabalho de campo,
poderão agora ser utilizadas para a construção da visão de uma plataforma P2P Health Insurance.
Posto isto, no próximo capítulo será apresentada a visão do sistema, fazendo uma sumarização
dos problemas e oportunidades, apresentando posteriormente uma gama de funcionalidades que
poderão resolver os problemas e potencias as oportunidades encontradas ao longo dos workshops
e entrevistas.
67
Imersão, Ideação e Prototipagem
68
Capítulo 6
Visão da Geral da Plataforma
No presente capítulo, irá ser exposto um resumo de todos os problemas e oportunidades des-
cobertas durante a execução da pesquisa bibliográfica e da aplicação dos métodos do Design Thin-
king. Irá também ser apresentada a visão da plataformas, assim como, as principais funcionalida-
des.
6.1 Atores da Plataforma
Ao longo do estudo realizado, tanto a nível da aplicação das ferramentas do Design Thinking,
como a nível da revisão bibliográfica, foi possível identificar os atores ou intervenientes nesta
eventual plataforma para venda de seguros seguindo o modelo P2P Health Insurance:
• O ator que terá mais destaque será o cliente de seguradoras de saúde, uma vez que a plata-
forma será construída a ter em conta as suas principais necessidades e expectativas;
• As seguradoras com produtos de saúde, assim como, os seus parceiros de negócio;
• Os prestadores de serviço de saúde, havendo intervenção de profissionais de áreas mais
administrativas e também de profissionais de cuidados médicos.
6.2 Descrição dos Problemas e Oportunidades
Aproveitando as conclusões do capítulo anterior e tendo em conta a pesquisa realizada, é
possível agrupar as várias oportunidades e problemas em três classes. A primeira dessas classes,
agrupa todos os problemas e oportunidades relacionados com a gestão do seguro saúde e qualidade
do serviço prestado pelas seguradoras. A segunda classe, diz respeito aos problemas e oportuni-
dades relacionados com a prestação dos cuidados de saúde. O último grupo, compila as várias
possibilidades e pontos negativos respeitantes à criação de comunidades online. Ao longo dos
próximos parágrafos, irá ser feito um resumo de todas os problemas encontrados, apresentando
69
Visão da Geral da Plataforma
também como uma plataforma P2P Health Insurance pode ser uma oportunidade para a resolução
dos mesmos.
Nas tabelas que se seguem, apresentam-se o problemas registados no âmbito da gestão do
seguro de saúde e de todos os processos inerentes, assim como, as oportunidades que poderão ser
geradas por uma plataforma de P2P Health Insurance. Seguidamente, exibem-se mais 2 tabelas
apresentando, respectivamente, os problemas e oportunidades registados na gestão dos cuidados
médicos e na criação de comunidades online.
Tabela 6.1: Tabela com os problemas e oportunidades recolhidas
Stackeholders Problema OportunidadeSeguradoras Grande taxa de ocorrência de
gastos verificada nos seguros desaúde
Com esta solução, os clientessão levados a reduzir a sua taxade gastos, para conseguirem re-ceber as poupanças da sua co-munidade
Seguradoras Existência de sinistros fraudu-lentos, originando gastos exces-sivos
Com o P2P Insurance, as pes-soas tendem a enganar menos asseguradoras pois não querem en-ganar os seus pares
Seguradoras Falta de mecanismos de acom-panhamento do cliente
Com a plataforma, poderão sercriados mecanismos para acom-panhar o cliente
Seguradoras Inexistência de produtos orienta-dos a uma nova geração de utili-zadores
O P2P Insurance por ser umaideia inovadora, que utilizameios digitais e com outrasvantagens, terá adesão por partedas novas gerações
Seguradoras Modelo de venda antiquado, re-correndo a lojas e mediadores,com grandes custos para as se-guradoras
A plataforma permite a venda deseguros de online, sem grandescustos e comissões.
Seguradoras e Cli-entes
Pouca personalização dos pro-dutos oferecidos, levando a umexcesso de cobertura ou a umacobertura deficitária
O P2P Health Insurance au-menta a personalização dos pro-dutos de seguros, uma vez queos clientes tendem a pagar con-soante o real risco
Seguradoras, Cli-entes e Prestado-res de serviços desaúde
Muita burocracia ligada aos pro-cessos de subscrição e reclama-ção de despesas de sinistros
As plataformas online poderãofornecer funcionalidades paraagilizar tanto o processo desubscrição, como o processo dereclamação de despesas
70
Visão da Geral da Plataforma
Tabela 6.2: Tabela com os problemas e oportunidades recolhidas para os clientes no âmbito
Stackeholders Problema OportunidadeClientes Pouca valorização das segura-
doras pelo bom comportamentodos clientes
O P2P Insurnace fornece a opor-tunidade de os clientes menos si-nistrados serem ressarcidos comparte do valor pago ao início
Clientes Procura por melhores preços,sem perder os benefícios de umacobertura alargada
O P2P Insurance oferece umacobertura ampla e ainda a pos-sibilidade de reaver parte do di-nheiro inicialmente pago
Clientes Dificuldade de compreensão dosprodutos de seguros e da respe-tiva cobertura
As plataformas online fornecema hipótese de criar esquemas einfografias que auxiliam o cli-ente
Clientes Sensação de falta de transparên-cia dos seguros e falta de confi-ança nas companhias segurado-ras
O P2P Insurance aumenta a rela-ção de confiança entre os segu-rados e as seguradoras, havendouma relação mais transparente
Clientes Dificuldade na gestão do estadoatual da apólice e dos orçamen-tos disponíveis
As plataformas online permitema criação de gráficos com infor-mação em tempo real sobre o es-tado da apólice
Tabela 6.3: Tabela com os problemas e oportunidades recolhidas no âmbito da gestão dos cuidadosmédicos
Stackeholders Problema OportunidadePrestador de ser-viço de saúde e Cli-entes
Falta de histórico clínico, nãohavendo um repositório globalpara a agregação das várias in-formações dos pacientes
Uma plataforma online tem apossibilidade de se agregar numsó repositório, várias informa-ções relativas à saúde dos paci-entes
Prestador de ser-viço de saúde e Cli-entes
Dificuldade na marcação de con-sultas, sendo um processo demo-rado e que não otimiza os recur-sos disponíveis
Este processo poderá ser otimi-zado com a criação de uma apli-cação web que realize estas fun-ções
Clientes e presta-dores de serviçosde saúde
Falta de atenção à qualidade doserviço que é prestado
Uma plataforma online poderáagregar comentários dos váriospacientes, levando os prestado-res de serviços de saúde a me-lhorarem o seu serviço
Clientes Dificuldade na procura de profis-sionais de saúde referenciados
Poderão ser criados mecanismosnuma aplicação web que permi-tam facilitar esta tarefa
71
Visão da Geral da Plataforma
Tabela 6.4: Tabela com os problemas e oportunidades recolhidas no âmbito da criação de comu-nidades online de P2P Health Insurance
Stackeholders Problema OportunidadeClientes Dificuldade de planeamento de
atividades de saúde em grupoUma aplicação web para criaçãoe gestão de comunidades poderáfacilitar esta função
Clientes Dificuldade de partilha e aglo-meração de informação relativaa saúde
Poderão mais uma vez ser apro-veitadas as plataformas e comu-nidades online
Clientes Desmotivação para a práticade atividades de promoção desaúde, como exercício físico
As comunidades online poderãoter mecanismos que levem unsmembros a motivar os outrospara comportamentos mais sau-dáveis
Clientes Monotorização dos dados de es-forço do exercício físico
Poderão ser criadas funcionali-dades para monitorizar esses da-dos e partilhar com a comuni-dade
Seguradoras Grande dificuldade de atraçãode clientes e grandes gastos emmarketing
Os membros da plataforma po-derão ter interesse em chamarpara a sua comunidade maiselementos, atraindo assim no-vos clientes, sem qualquer custopara a seguradora
6.3 Visão da Aplicação
Uma aplicação web que permite que os clientes simulem, subscrevam e giram os seus seguros
usando os meios digitais, mas que simultaneamente fornece uma nova forma de vender seguros.
Assim esta aplicação possibilita a criação de comunidades online, que permitem que os mem-
bros dessas comunidades dividam os riscos das apólices entre eles e caso a taxa de sinistros seja
baixa, os membros dessa comunidade receberão o excedente resultante. Esta aplicação por ser
vocacionada para a área da saúde, também permitirá que os utilizadores giram as suas atividades
relacionadas com a saúde, podendo marcar consultas e armazenar informações relativas ao seu
histórico clínico, contendo simultaneamente mecanismos que motivem as várias comunidades à
prática de exercício físico e à educação para a saúde.
6.4 Objetivos da plataforma
O grande objetivo da criação desta aplicação web será então fornecer aos clientes de seguros
de saúde uma melhor experiência de utilização, contemplando melhorias quer a nível daquilo que
envolve diretamente o seguro de saúde, quer a nível da forma como recorremos aos profissionais de
saúde, aproveitando ainda a criação das comunidades para gerar benefícios para os seus membros.
72
Visão da Geral da Plataforma
Nos parágrafos em baixo, será feita uma enumeração dos vários objetivos de uma plataforma de
P2P Health Insurance, segundo aquilo que foi concluído ao longo desta dissertação.
Os objetivos de uma plataforma de P2P Health Insurance são os seguintes:
• Fornecer mais informação ao cliente e de forma mais clara sobre a cobertura da sua apólice;
• Conseguir prestar um melhor acompanhamento aos clientes, providenciando uma melhoria
no serviço;
• Fornecer mais informação e mais estruturada sobre o atual estado da apólice do seguro;
• Melhorar a presença das seguradoras nos meios digitais, atraindo as novas gerações de uti-
lizadores;
• Melhorar a eficiência operacional das seguradoras, baixando os gastos com atração de cli-
entes, diminuindo as taxas de sinistralidade e atenuando os sinistros fraudulentos;
• Diminuir a burocracia inerente aos processos dos seguros de saúde, nomeadamente da si-
mulação, subscrição e da reclamação de despesas;
• Tirar vantagem das potencialidades das novas tecnologias para conseguir fornecer produtos
mais personalizados e adequados aos seus clientes;
• Aproveitar as comunidades online para melhorar a saúde dos clientes, promovendo ativida-
des e aumentando a quantidade de informação disponível;
• Aumentar a confiança das pessoas nas empresas de seguros de saúde.
6.5 Visão geral das Funcionalidades
Para fornecer uma visão geral das funcionalidades da aplicação, irão ser apresentados, durante
a presente secção, os vários pontos em que a aplicação irá entrar em contacto com os vários
utilizadores. Para este efeito, as várias funcionalidades serão divididas em vários cenários de
uso possíveis, sendo apresentados diagramas de casos de uso para cada um desses cenários. Os
diagramas de casos de uso, serão complementados com uma tabela, explicando de forma mais
concretamente as funcionalidades que foram idealizadas para cada um desses casos.
6.5.1 Funcionalidades para o Cliente
Ao longo de todo este processo, houve grande preocupação em descobrir as reais necessida-
des do cliente, para que a aplicação que seja criada forneça uma experiência de utilização que o
encante. De facto, o grande objetivo desta aplicação é providenciar serviços e funcionalidades que
enderecem os problemas dos clientes dos seguros de saúde. Nesta secção serão apresentadas as
funcionalidades que visam a corrigir os problemas identificados ao longo do estudo desta maté-
ria. De forma a conseguir estruturar melhor esta sumarização das funcionalidades, foi seguido a
73
Visão da Geral da Plataforma
mesma linha de pensamento das secções anteriores, dividindo as funcionalidades em três campos:
gestão da apólice de seguro, gestão dos cuidados médicos e aproveitamento do factor comunidade.
Estes três grupos de funcionalidades irão ser apresentados na ordem anteriormente referida, sendo
apresentado em primeiro lugar um diagrama de casos de uso, seguido de uma tabela que expões
as funcionalidades com mais detalhe. O primeiro grupo de funcionalidades exibido diz respeito à
gestão da apólice do seguro.
Figura 6.1: Diagrama de Casos de Uso do Cliente para a gestão do seu seguro
74
Visão da Geral da Plataforma
Tabela 6.5: Tabela com os problemas e oportunidades recolhidas no âmbito da criação de comu-nidades online de P2P Health Insurance
Processo FuncionalidadesSimulação do valor daapólice
- Fornecer uma forma intuitiva de realizar a simulação de umaapólice de seguro, seguindo as tendências atuais- Apresentar de seguida os vários planos disponíveis, com umresumo da cobertura disponível
Subscrição do Segurode Saúde
- Possibilitar a subscrição online, sem recurso a burocracia eformulários em papel- Conseguir acelerar o processo de subscrição, recorrendo ainformação presente nas redes sociais
Consultar gastos - Consultar gastos os vários gastos efetuados, relacionadoscomo seguro de saúde, estruturando a informação em gráficose infografias
Consultar orçamentos - Consultar os orçamentos que o cliente ainda tem disponíveispara usufruir, dentro de seguro de saúde- Consultar o orçamento disponível, sem que as poupançasanuais sejam prejudicadas
Consultar a cobertura - Ter acesso às várias condições da apólice, recorrendo a es-quemas e infografias, evitando as longas tabelas normalmenteapresentadas
Consultar estado dossinistros
- Ter acesso aos vários sinistros realizados até então- Conseguir consultar qual o estado de processamento dos si-nistros
Submeter despesas - Possibilitar a submissão de despesas através da aplicação- Envio de recibos via online, evitando o uso do correio tradi-cional
Reportar situações defraude
- Conceder a possibilidade de os clientes poderem reportar si-tuações em que pensem que estão a ser alvos de um compor-tamento pouco ético por parte dos profissionais de saúdel
Formar comunidadesde partilha de risco
- Formar uma nova comunidade na aplicação- Convidar membros para se juntarem à comunidade, quer es-tejam na aplicação ou utilizando email ou as redes sociais- Permitir que um membro se junte a uma determinada comu-nidade já existente na plataforma
75
Visão da Geral da Plataforma
Figura 6.2: Diagrama de Casos de Uso do Cliente para a gestão dos seus cuidados médicos
Tabela 6.6: Tabela com as funcionalidades para o cliente no âmbito da gestão dos cuidados médi-cos
Processo FuncionalidadesMarcação de consultasou outros tratamentos
- Conseguir marcar consultas, escolhendo o hospital, o profis-sional de saúde e a data-Encontrar os prestadores de serviços de saúde por ordem deavaliação dos anteriores pacientes
Otimizar o processo demarcações
- Conseguir gerir melhor o processo de adiamento ou desmar-cação de consultas, de modo, a prejudicar o menos possível,os prestadores de serviços de saúde e os pacientes
Pesquisa de profissio-nais de saúde
- Permitir a pesquisa de prestadores de serviço de saúde,ordenando-os por ordem decrescente das avaliações forneci-das por utilizadores anteriores
Avaliar o serviço pres-tado
- Criar mecanismos que permitam que o utilizador avalie edeixe comentários, sobre um determinado prestador de servi-ços de saúde
Repositório de examese prescrições
- Aglomerar numa só plataforma os vários exames dos utiliza-dores, evitando que este tenha que ir aos vários locais levantaros exames e prescrições e, simultaneamente, preserve a infor-mação de forma organizada
Repositório de infor-mação médica
- Guardar num só local os relatórios médicos feitos pelos vá-rios médicos, para que os médicos no futuro tenham maiorquantidade de informação disponível sobre o paciente
76
Visão da Geral da Plataforma
Figura 6.3: Diagrama de Casos de Uso do Cliente alavancando o fator comunidade
77
Visão da Geral da Plataforma
Tabela 6.7: Tabela com as funcionalidades disponíveis a nível da comunidade
Processo FuncionalidadesPartilha da informaçãodos gastos em saúde
- Permitir que os membros da comunidade definam qual o tipode informação que querem ver partilhada em relação aos seusgastos em saúde- Permitir que os membros da comunidade definam qual o tipode informação que querem ver partilhada em relação aos seusgastos em saúde
Partilha de atividadesde exercício físico
- Possibilitar que os membros da comunidade partilhem entresi as várias atividades de exercício físico que realizam- Calcular uma taxa de esforço, consoante o número e a inten-sidade dessas mesmas atividades- Permitir que aplicação interatue com dispositivos wearables,que permitam uma melhor monitorização dos dados relativosà prática do exercício físico
Partilha de vídeos e ar-tigos
- Permitir que os membros da comunidade partilhem entre siinformação de carácter variado, nomeadamente, vídeos e ar-tigos que estejam relacionados com área da saúde e do bem-estar
Consultar o total pou-pado em tempo real
-Conseguir consultar, em tempo real, o montante que a comu-nidade irá poupar no final do ano- Conseguir consultar o montante que o membro em questãovai poupar no final do ano.
Consultar gastos dacomunidade
- Conseguir obter informação relativa aos gastos dos outrosmembros da comunidade, recorrendo a gráficos- Obter os gastos dos vários membros, comparando com a mé-dia da comunidade e com a média global das comunidades daaplicação
Notificar os membrosmenos ativos
- Ter mecanismos na aplicação que permitam notificar osmembros com menor atividade física- Motivar os membros mais ativos a convidarem os menos ati-vos
Classificações porbom comportamento
- Ordenar os membros de uma de uma determinada comuni-dade pela ordem de esforço- Atribuir um nível de bom comportamento, ponderando paraisso a quantidade de atividade física e a taxa de despesas emsaúde.
6.5.2 Funcionalidades para os Profissionais de Seguros
Como já foi dito anteriormente, os profissionais dos seguros de saúde terão um papel impor-
tante numa plataforma de P2P Health Insurance, uma vez que os utilizadores terão um seguro de
saúde e será necessário acompanhar estes clientes ao longo da sua jornada de utilização. O papel
deste ator estará muito mais ligado à administração da plataforma e dos vários utilizadores, bem
como, gerir os vários processos relativos aos vários clientes. De seguida é apresentado um dia-
grama de casos de uso das funcionalidades que um profissional de seguros poderá realizar numa
78
Visão da Geral da Plataforma
plataforma destas e uma tabela com a especificação detalhada dessas funcionalidades.
Figura 6.4: Diagrama de Casos de Uso para os profissionais de Seguros
Tabela 6.8: Tabela com as funcionalidades possíveis para profissionais de seguros
Processo FuncionalidadesGestão de sinistros - Consulta do estado atual do sinistro e acompanhamento do
seu processo, utilizando gráficos e infografiasAnálise de situaçõesfraude
- Aceder e analisar eventuais situações indicadas pelos utiliza-dores da plataforma
Gerir clientes - Possibilitar o acompanhamento mais próximo dos clientes,conseguindo analisar índices de satisfação e percecionar seainda existem pontos de melhoria- Levar o cliente a usufruir ao máximo da plataforma, indi-cando comunidades no caso de este não estar em nenhuma oumotivando-o a participar mais na sua comunidade
Oferta de novos produ-tos
- Notificar via aplicação da existência de novas apólices/co-berturas, aproximando mais o cliente e as seguradoras
Administrar aplicação - Fornecer os mecanismos necessários para que seja possívelgerir os utilizadores, comunidades e todos os aspetos relativosà aplicação- Gerir eventuais situações que se poderão originar nas comu-nidades de utilizadores
79
Visão da Geral da Plataforma
6.5.3 Funcionalidades para os Prestadores de Serviços de Saúde
Os prestadores de serviços de saúde têm um papel muito importante nesta aplicação, uma vez
que, estarão envolvidos nos gastos associados ao seguro, tendo que posteriormente declarar à se-
guradora as respetivas despesas. De seguida, é exibido um diagrama de casos de uso relativo aos
prestadores de serviços de saúde e a respetiva tabela de explicação das funcionalidades mais deta-
lhadamente. É, no entanto, importante referir que, ao longo desta explicação um prestador de um
serviço de saúde, poderá ser relativo à parte administrativa que trata da reclamação das despesas
junto das seguradoras, mas também poderá ser relativo aos profissionais de saúde, nomeadamente
médicos, farmacêuticos ou outros técnicos de saúde.
Figura 6.5: Diagrama de Casos de Uso para os Prestadores de Serviços de Saúde
80
Visão da Geral da Plataforma
Tabela 6.9: Tabela com as funcionalidades possíveis para Prestadores de Serviços de Saúde
Processo FuncionalidadesGerir marcaçõess - Disponibilizar as datas consoante a disponibilidade dos pro-
fissionais de saúde ou capacidade dos recursos- Consultar a agenda de consultas/marcações
Otimizar adiamentos edesmarcações
- Criar mecanismos para otimizar as desmarcações, tentandoevitar ao máximo que se prejudique quer o cliente quer o pro-fissional de saúde
Submissão das despe-sas
- Disponibilização de um portal que permita a submissão dasdespesas dos clientes
Consultar o estado dasdespesas
- Consultar qual o estado atual das despesas anteriormente re-clamadas
Armazenar exames eprescrições
- Fornecer mecanismos que possibilitem que os vários examese prescrições de um paciente, fiquem guardados num únicolugar
Guardar informaçãosobre os pacientes
- Permitir que os profissionais de saúde armazenem informa-ção sobre os seus pacientes e possam aceder a informação an-tiga dos mesmos.
6.6 Conclusões
No decurso do presente capítulo, foram apresentados os vários problemas recolhidos e de
que forma é que a aplicação idealizada os vai mitigar, tendo sido enumerado um leque de pos-
síveis funcionalidades a implementar num protótipo de P2P Health Insurance. Contudo, devido
aos constrangimentos de tempo de uma dissertação de mestrado, apenas será possível realizar um
protótipo com algumas das funcionalidades anteriormente referidas. No próximo capítulo, serão
listadas as funcionalidades implementadas na prova de conceito construída ao longo desta disser-
tação e apresentados outros aspetos relativos à fase de prototipagem/implementação da prova de
conceito.
81
Visão da Geral da Plataforma
82
Capítulo 7
Implementação do Protótipo
Este capítulo será focado no processo que esteve subjacente ao desenvolvimento do protótipo
da ideia de negócio que foi estudada ao longo desta dissertação. Assim, durante as próximas sec-
ções serão apresentadas informações relativas à arquitetura utilizada para desenvolver o protótipo
e às várias iterações que foram realizadas até se atingir o protótipo final apresentado.
7.1 Arquitetura de Prototipagem Deloitte Digital
A Deloitte Digital é uma área de competência, inserida dentro da Deloitte, que se dedica
a apresentar soluções inovadoras, tirando proveito de novas tendências tecnológicas, de forma
a criar novas abordagens para o negócio dos seus clientes. Por este motivo, a Deloitte Digital
criou uma arquitetura para ser utilizada sempre que seja necessário desenvolver um protótipo para
apresentar aos seus clientes uma nova solução de negócio. Uma vez que esta dissertação se centra
no estudo de uma determinada ideia de negócio e consequente desenvolvimento de um protótipo,
torna-se pertinente o uso desta arquitetura para acelerar o processo de desenvolvimento. Tendo
isto em conta, o facto de esta dissertação ser desenvolvida em ambiente empresarial e a empresa
em questão ter interesse em analisar qual a eficiência e rapidez de desenvolvimento recorrendo a
esta arquitetura, este processo de prototipagem foi desenvolvido tendo como base esta arquitetura.
Esta arquitetura foi desenvolvida com o propósito de ser uma solução genérica para a constru-
ção de qualquer tipo de projeto de desenvolvimento de aplicações, quer de web, quer de dispositi-
vos móveis. Ao recorrer a esta arquitetura, o programador, pode-se concentrar no desenvolvimento
da lógica de negócio e na personalização das vistas apresentadas ao utilizador. A arquitetura está
organizada recorrendo ao padrão de desenvolvimento MVC (Model - View - Controller) e foi cons-
truída de forma modular, para permitir que módulos e possam ser retirados ou acrescentados sem
prejudicar a fiabilidade da solução. Cada módulo funciona como uma aplicação independente,
comunicando com os restantes módulos através de APIs. Para além disso, os vários módulos exis-
tentes nesta estrutura, estão divididos em quatro camadas, respetivamente, a camada de Frontend,
83
Implementação do Protótipo
aquela que é apresentada ao utilizador final; a camada de Middleware, que é responsável pela
intermediação dos acessos ao Backend; a camada de Backend, a qual incorpora os sistemas de
acesso à camada de dados e parte da lógica de negócio; e por fim, a camada de dados, que inclui as
base de dados que suportam toda a arquitetura. As várias camadas que compõem esta arquitetura,
são analisadas ao longo das próximas secções, bem como, as tecnologias e frameworks que as
suportam.
Figura 7.1: Esquema da arquitetura de prototipagem da Deloitte Digital
7.1.1 Camada de Backend e Camada de Dados
O módulo de Backend é responsável por gerir todos os acessos a dados, pela lógica de negócio
da aplicação e por estruturar os dados para serem lidos nas camadas superiores. Esta camada é
ainda responsável por ser o ponto de contacto com dois importantes módulos desta arquitetura:
o sistema de gestão de utilizadores e o sistema central de mensagens. O primeiro consiste num
sistema que ajuda os programadores a gerirem os utilizadores das suas aplicações, facilitando a
autenticação com as redes sociais, registo de utilizadores e gestão de grupos de utilizadores. O
segundo sistema, é construído com o propósito de gerar mensagens à medida que o código é exe-
cutado, para permitir ao programador o controle sobre as funções que estão a ser executadas. Entre
outras coisas, este sistema permite detetar em que momento é que a aplicação deixou de respon-
der, gravando todas as mensagens de erro numa base de dados, para que mais tarde possam ser
consultadas. Estes dois sistemas foram construídos pelas equipas de desenvolvimento da Deloitte
Digital utilizando tecnologias como o NodeJS, para criar os servidores, o RabbitMQ, para gerir as
filas de espera das mensagens e MongoDB, para as bases de dados.
O módulo de Backend, é construído recorrendo ao NodeJS e HapiJS, uma biblioteca que
ajuda a construir APIs REST, sendo que as bases de dados também são construídas recorrendo
ao MongoDB. O módulo de Midleware consegue aceder aos dados presentes nas bases de dados,
84
Implementação do Protótipo
através de chamadas à API do módulo de Backend, sendo que as chamadas desta API poderão ser
personalizadas conforme as necessidades do projeto.
7.1.1.1 MongoDB
Em busca de maior eficiência e confiança dos sistemas de base de dados e adotando o pa-
radigma de NoSQL, surge em 2009 o Mongo DB[MON]. O principal objetivo desta tecnologia
passa por fornecer um sistema de base de dados que tenha um enorme capacidade de escalamento
e simultaneamente, com grande flexibilidade, eficiência, facilidade de uso e aprendizagem. O
MongoDB, ao contrário de tecnologias de base de dados SQL, aborda a construção de bases de
dados sem recorrer ao modelo relacional, abdicando também da pré definição do esquema da base
de dados, criando assim uma maior flexibilidade na manipulação dos dados. Outra característica
importante do MongoDB, é o facto deste ser mais vocacionado para criar estruturas de dados mais
simples ou mais próximas do modelo de programação orientada a objetos e menos semelhantes
dos tradicionais sistemas de gestão de base de dados tradicionais[Str].
Todas as vantagens enumeradas nos parágrafos acima, levaram a que um grande número de
organizações a escolher o MongoDB como o seu sistema de gestão de base de dados, entre as
quais, a Source-Forge, o GitHub e o The New York Times[dS11, BRA16].
7.1.2 Camada de Middleware
A camada de Midleware é responsável por controlar os acessos à camada de backend, bem
como, o controlar o acesso a outros serviços, encapsulando os dados, de forma a abstrair a camada
de frontend do tratamento e acesso a dados. Nesta arquitetura, a camada midleware é composta
por um módulo principal e por um sistema de gestão de dados em cache. O módulo principal é
composto por um servidor de NodeJS, utilizando a biblioteca Falcor para ajudar na orquestração
dos dados provenientes de vários serviços. O módulo de gestão dos dados em cache é baseado na
tecnologia Redis, sendo utilizada uma biblioteca do NodeJS para facilitar o acesso do módulo de
midleware aos dados em cache, chamada IORedis. Nas próximas duas secções serão apresentadas
mais em pormenor as duas tecnologias que compõe a camada de midleware desta arquitectura.
7.1.2.1 Falcor
O Falcor[FAL] é uma biblioteca open-source, criada pela Netflix utilizando Javascript, que
permite um acesso mais eficiente aos dados provenientes de várias fontes de informação. Esta
eficiência é alcançada através da criação de uma camada intermédia entre os servidores e o lado
do cliente. A camada intermédia que é criada pelo Falcor, junta os dados provenientes das várias
aplicações utilizadas, criando uma única interface para o frontend utilizar. Deste modo, o lado do
cliente pode abstrair-se da forma como os dados são obtidos, existindo apenas um ponto no qual os
vários dados podem ser recolhidos. Os dados de origem remota, são apresentados com o recurso
85
Implementação do Protótipo
a um objeto JSON, o qual contém a informação agrupada das várias fontes, permitindo ao Front-
end aceder a um único objeto, sempre que seja necessário obter dados, como se este estivesse em
memória.
Esta framework está dividida em duas camadas, o “Model” e o “Router”, sendo que o “Model”
é a camada responsável pela comunicação com o frontend e com o “Router”, enquanto o “Router”
é o local onde a aplicação de middleware corre e como tal, o local onde os dados originários
de várias fontes, são agrupados e enviados para o Frontend. Em suma, o “Model” é a parte da
framework que está colocada do lado do cliente e o “Router” é a parte do Falcor, que se situa entre
a camada de Backend e Frontend. Na figura seguinte, é apresentada a estrutura do Falcor, na qual
o logótipo deste projeto representa as duas partes desta ferramenta, sendo que o logótipo na parte
superior representa o “Router” e o da parte inferior representa o “Model”.
Figura 7.2: Esquema do modo de funcionamento do Falcor retirada de [FAL]
A utilização desta tecnologia é especialmente aconselhada, sempre que uma determinada apli-
cação necessita de aceder a diversas fontes de informação, pois esta ferramenta consegue de uma
forma eficiente e simples, fundir dados originados de sítios diferentes, fornecendo ao lado do cli-
ente um objeto que poderá ser facilmente acedido. Para além disto, o Falcor também providencia
vantagens a nível da escalabilidade, pois permite que o Frontend se abstraia da forma como os
dados são guardados. Contudo, devido ao facto desta tecnologia ser muito recente, ainda não
existem muitos estudos e informação disponível sobre esta, porém o facto de esta ser usada pela
Netflix, empresa de grande sucesso, cujo negócio implica uma grande manipulação de dados, está
a aumentar o interesse em redor desta tecnologia, motivo pelo qual a Deloitte Digital o decidiu
incorporar na sua arquitetura.
86
Implementação do Protótipo
7.1.2.2 Redis
Um ponto crucial na usabilidade e na experiência do utilizador com a aplicação, é a eficiência
da mesma. Uma das formas de acelerar o acesso aos dados necessários para a aplicação é a
utilização de sistemas de chaching, que armazenar a informação que vai sendo utilizada pela a
aplicação, de modo a evitar acessos repetidos a outros componentes da arquitetura. Entre as várias
vantagens de recorrer a um sistema de cache estão, a redução das necessidades de largura de banda,
o melhoramento da disponibilidade dos servidores e ainda a redução das latências do servidor.
O Redis[RED] é uma biblioteca open-source, criada em 2009 pela empresa Salvatore San-
filippo, que suporta estruturas de dados que podem ser usadas em memória de trabalho. Esta
tecnologia, suporta um leque variado de estruturas de dados, tais como, strings, hash sets, list sets,
sets, sorted sets e bitmaps. As principais vantagens em utilizar o Redis, prendem-se com a varia-
dade de estruturas de dados disponíveis, a possibilidade de criar listas de comandos, a inserção de
múltiplos dados aquando da instalação e a possibilidade de realizar back-ups para disco. Contudo,
esta tecnologia apresenta ainda alguma complexidade na configuração.
7.1.3 Camada de Frontend
A camada de frontend da arquitetura de prototipagem da Deloitte Digital, é composta por vá-
rios vários módulos: o módulo de dispositivos móveis Android, o módulo de dispositivos móveis
IOS e o módulo de aplicações web, contudo ao longo desta dissertação, apenas se usou o módulo
de aplicações web. Este módulo é composto por um servidor construído com base em NodeJS e
Express, uma biblioteca que auxilia na criação de APIs REST, sendo que o servidor é responsável
pelo acesso aos dados presentes na camada de midleware. Este servidor é conectado com a apli-
cação que corre totalmente do lado do cliente, construída recorrendo à framework anteriormente
analisada, o AngularJS. Do lado do cliente, encontra-se parte da lógica dos processos de negó-
cio, assim como, a construção das vistas que são apresentadas ao utilizador final. Na construção
das vistas apresentadas aos utilizadores finais é ainda utilizado a tecnologia Bootstrap, que será
apresentada na subsecção seguinte.
7.1.3.1 Bootstrap - Construção de websites responsivos
Em Agosto de 2011, Mark Otto e Jacob Thornton, ambos funcionários do Twitter, conscientes
da necessidade da sua empresa de padronizar as ferramentas e frameworks utilizados no desenvol-
vimento de frontend, criaram o Bootstrap[BOO]. Esta ferramenta encontra-se atualmente na sua
versão número 3.3.6 e fornece aos programadores que a utilizam, uma série de ferramentas muitos
úteis no design do frontend de uma aplicação, que auxiliam desde a criação de um design respon-
sivo para os vários tipos de dispositivos, até à inclusão de botões e formas de input. O Bootstrap
inclui ainda, um leque de plug-ins construídos com recurso a Javascript, bem como um conjunto
de imagens e ícones de uso livre.
A grande vantagem em recorrer a esta framework, prende-se com a facilidade de tornar o de-
sign de uma determinada página web adequado para todos os dispositivos, o que se tem vindo a
87
Implementação do Protótipo
demonstrar como um aspeto particularmente importante, devido à grande proliferação dos dispo-
sitivos móveis verificada nos últimos anos.
7.2 Funcionalidades Implementadas
No capítulo anterior foi apresentado um grande número de funcionalidades que seriam inte-
ressantes de implementar numa plataforma de P2P Health Insurance, no entanto, devido ao curto
período de tempo no qual se realiza uma dissertação, torna-se necessário priorizar as funcionali-
dades consoante a seu grau de importância para a prova de conceito.Sendo assim, foi deliberado
que apenas seria apresentado o lado do cliente final no protótipo, deixando de parte para já as fun-
cionalidades respeitantes aos prestadores de serviços de saúde e seguradores. Na próxima tabela,
são apresentadas as funcionalidades implementadas, organizadas pelos respectivos ecrãs que irão
compor o protótipo desenvolvido.
Tabela 7.1: Tabela com as funcionalidades disponíveis a nível da comunidade - parte I
Ecrã FuncionalidadesPágina inicial - Possibilidade de fazer uma simulação de forma simples e
intuitiva- Possibilidade de autenticar o utilizador na plataforma
Página de Registro - Apresentação dos vários planos disponíveis para o cliente-Possibilidade de registro do cliente e subscrição do plano quemelhor corresponde às suas necessidades
Criação ou Adesão àComunidade
-Apresentação de comunidades já existentes- Apresentação de pessoas sugeridas para a criação de umanova comunidade- Possibilidade de convite de novas pessoas para utilizar estaplataforma
Página de controlo -Acesso aos orçamentos disponíveis nas várias áreas de cuida-dos médicos- Apresentação de informação dos gastos de outros membrosda sua comunidade- Acesso ao atual montante poupado e atual taxa de dedicaçãoaos comportamentos saudáveis da comunidade
Página Pessoal - Acesso à informação relativa às várias atividades de exercí-cio físico- Acesso aos gastos pessoais
Página da comunidade - Visualização das atividades e informações partilhadas pelospares da comunidade- Acesso à taxa de esforço dos restantes membros- Possibilidade de convidar os membros para atividades
88
Implementação do Protótipo
Tabela 7.2: Tabela com as funcionalidades disponíveis a nível da comunidade - parte II
Ecrã FuncionalidadesVisão geral da Cober-tura
- Visão global das condições específicas da sua apólice,usando esquemas e explicitando de forma clara a cobertura
Marcação de Consulta - Escolha do tipo de consulta que pretende realizar e da respe-tiva especialidade- Escolha da clínica/laboratório e do respetivo profissional desaúde- Escolha da data mais adequada para o utilizador
Página de revisão doserviço prestado
- Avaliar o serviço prestado recorrendo a uma escala- Comentar os pontos negativos e positivos
Procura de Profissio-nais de Saúde
- Pesquisa de prestadores de cuidados médicos- Classificação dos prestadores de serviços de saúde tendo emconta os anteriores pacientes
Repositório de infor-mação médica
- Repositório da informação relativa a exames e prescriçõesmédicas- Repositório de informação relativa a avaliações feitas porprofissionais de saúde no passado do paciente
Página de gestão de si-nistros
- Consulta do estado do processamento do sinistro- Consulta do histórico de sinistros- Possibilidade de reportar um determinado sinistro, no casode suspeitas de comportamento abusivo
7.3 Desenvolvimento
Desde a construção da visão das funcionalidades da aplicação, até à construção do protótipo
final, foram realizadas 3 iterações de forma a ir melhorando o protótipo de iteração em iteração.
A primeira iteração consistiu na colocação das funcionalidades nos respetivos ecrãs, tendo sido
realizado ecrãs estáticos, daí ser chamada iteração 0 uma vez que não foi desenvolvido código,
sendo apenas desenvolvida a estrutura das várias páginas. Na segunda iteração, foram desenvolvi-
dos os vários ecrãs e as funcionalidades correspondentes, constituindo assim a primeira versão do
protótipo funcional da aplicação web de P2P Health Insurance. Na terceira iteração, o protótipo
construído sofreu alguns ajustes em termos de design e usabilidade, de forma a tornar a experi-
ência de utilização do mesmo mais agradável. Nas próximas subsecções serão apresentados em
pormenor as três iterações realizadas. Os protótipos cotêm texto em Inglês, uma vez que este é o
idioma base da empresa proponente desta dissertação.
7.3.1 Iteração 0 - Protótipo Estático
Após as funcionalidades principais de uma futura plataforma de P2P Health Insurance, terem
sido levantadas, recorrendo a entrevistas, workshops de design thinking e a uma pesquisa sobre o
tema, é necessário perceber de que forma é que as várias funcionalidades irão ser apresentadas ao
utilizador da plataforma. Para isso, foram testadas várias estruturas para as páginas que compõe a
89
Implementação do Protótipo
aplicação, primeiro recorrendo a rascunhos e, numa fase posterior, recorrendo a esquemas. Estes
esquemas, sofreram posteriormente algumas alterações, de forma a melhor contemplarem questões
de usabilidade e agregarem novas funcionalidades. A duração desta iteração foi de 2 semanas.
De seguida, são apresentados alguns exemplos dos esquemas construídos para servirem como
base ao futuro desenvolvimento do protótipo funcional, sendo que em primeiro lugar aparecem os
rascunhos e depois, esquemas mais precisos.
Figura 7.3: Rascunhos relativos à estrutura de alguns ecrãs
Figura 7.4: Estrutura da página dedicada à procura de porfissionais de saúde com exemplos alea-tórios
90
Implementação do Protótipo
Figura 7.5: Estrutura do ecrã que possibilita a criação e adesão a comunidades
7.3.2 Protótipo Funcional
Conforme o que tem sido referido, desde o primeiro capítulo, o grande objetivo de todo o
processo realizado ao longo desta dissertação, prendia-se com a construção de um protótipo de
uma plataforma de P2P Health Insurance. Depois de ter conseguido estruturar as funcionalidades
nos vários ecrãs, seguiu-se a fase de desenvolvimento do código da solução da plataforma de
P2P Health Insurance. O protótipo foi desenvolvido recorrendo à arquitetura de prototipagem
da Deloitte Digital, o que permitiu desenvolver rapidamente um conjunto de funcionalidades em
pouco tempo. Esta iteração durou, cerca de 4 semanas e caso não fosse possível recorrer a esta
arquitetura, poderia ter demorado consideravelmente mais.
De seguida, são apresentados alguns dos ecrãs que foram construídos nesta iteração, sendo
que a totalidade dos ecrãs poderá ser consultada nos anexos desta dissertação.
Figura 7.6: Página principal da plataforma - possibilidade de simulação da apólice
91
Implementação do Protótipo
Figura 7.7: Página de Controlo da plataforma
Figura 7.8: Página de criação e adesão a comunidades
Figura 7.9: Página de procura por profissionais de saúde
92
Implementação do Protótipo
Figura 7.10: Página de consulta das atividades da comunidade
7.3.3 Iteração 2 - Protótipo Final
Hoje em dia, as funcionalidades que uma plataforma oferece, podem não ser suficientes para
cativar os clientes, daí ser muito importante a atenção ao design da aplicação e à forma como as
páginas são apresentadas. Deste modo, torna-se pertinente a inclusão de especialistas na área de
design e desenho de interfaces com o utilizador, para conseguir fornecer a melhor solução possível.
Visto isto, a Deloitte Digital para conseguir entregar soluções com o máximo de qualidade a todos
os níveis, incorpora nos seus quadros alguns especialistas destas áreas.
Dado o interesse desta empresa no protótipo desenvolvido ao longo desta dissertação, foram
realizadas algumas sessões de trabalho em que membros da equipa de design, foram sugerindo
alterações de forma a tornar a solução mais apelativa para o utilizador. As alterações realizadas,
apesar de pequenas, fizeram com que o aspeto geral da aplicação melhorasse consideravelmente.
As próximas três imagens, são relativas a esta iteração, podendo ser registadas as alterações
realizadas. Esta iteração teve a duração também de 4 semanas, focando-se no design da interface
com o utilizador.
Figura 7.11: Página principal da plataforma, fornecendo a possibilidade de simulação
93
Implementação do Protótipo
Figura 7.12: Página de registo na plataforma e subscrição da apólice
Figura 7.13: Página de criação e adesão a comunidade na nova plataforma
Figura 7.14: Página de consulta das atividades da comunidade e interação com os outros membros
94
Implementação do Protótipo
7.4 Validação do Protótipo
De forma a validar o protótipo desenvolvido durante esta dissertação, bem como, garantir que
este realmente vai de encontro às necessidades e expetativas dos utilizadores finais, foram reali-
zadas algumas sessões de validação com potenciais utilizadores. Nestas sessões, as várias funcio-
nalidades do protótipo foram apresentadas, seguindo-se um momento de preguntas aos potenciais
utilizadores. Entre as perguntas realizadas destacam-se: quais os pontos positivos da aplicação,
quais as funcionalidades que o deixam desconfortável ou que não o entusiasmam, e por fim, quais
as melhorias sugeridas. Ao todo foram entrevistadas 7 pessoas, todas pertencentes ao grupo de
pessoas que anteriormente já tinham participado nos workshops, de forma a garantir que estas já
estavam enquadradas com a temática em questão.
Em relação aos pontos positivos enumerados destacam-se os seguintes:
• A maneira intuitiva e direta de gerar uma simulação;
• A página de controlo fornece uma visão clara sobre os vários orçamentos disponíveis e
despesas realizadas;
• A página de consulta da cobertura da apólice providência de forma clara a informação ne-
cessária para compreender as condições do seguro;
• Os mecanismos de marcação de consultas, procura de profissionais de saúde e de arquivação
do histórico de saúde;
• O facto de haver um mecanismo que leva os membros a se motivarem mutuamente para a
prática de exercício físico.
No que toca às funcionalidades que menos entusiasmaram os potenciais utilizadores é impor-
tante referir os seguintes tópicos:
• A partilha de informação relativa ao exercício físico, não entusiasmou alguns dos potenciais
utilizadores, uns pelo facto de não se sentirem confortáveis com a partilha dessa informação,
e outros pelo facto de não quererem ter a pressão de não se esquecerem de partilhar esta
informação;
• A partilha de informações relativas a saúde e bem-estar, também foi referida como um
potencial problema, uma vez que os potenciais utilizadores afirmaram que prefeririam fazer
esta partilha através das suas redes sociais habituais;
• Os utilizadores voltaram a referir que a informação relativa a consultas, deveria ser parti-
lhada com muito cuidado entre os membros da comunidade.
Relativamente aos pontos de melhorias, os potenciais utilizadores entrevistados enumeraram
os seguintes pontos:
95
Implementação do Protótipo
• Deveria existir maior integração com as redes sociais para levar o utilizador a ter que in-
troduzir o mínimo de informação possível, tanto na criação da apólice, como na partilha de
dados relativos ao exercício físico;
• Na marcação da consulta deveria ser possível procurar por proximidade, funcionalidade que
não está ainda disponível no protótipo realizado;
• Deveria existir alguma forma para o potencial utilizador conseguir perceber o conceito sub-
jacente à plataforma, devido à sua elevada complexidade.
• Na criação de comunidades deveria existir alguma forma de chamar diretamente os ami-
gos/conhecidos através de redes sociais ou listas de correio eletrónico.
7.5 Conclusões
Durante o terceiro capítulo foram apresentadas bastantes tecnologias existentes que ajudam os
programadores de aplicações web a acelerarem o seu processo de desenvolvimento. No decurso
desta dissertação, o desenvolvimento teve como base duas frameworks que foram analisadas nesse
capítulo o NodeJS e o AngularJS, contudo foram utilizados recorrendo à arquitetura de prototi-
pagem da Deloitte Digital, uma arquitetura que incluí muitas potencialidades não oferecidas pela
generalidade das frameworks analisadas. Recorrendo a esta arquitetura, foi possível o desenvolvi-
mento mais célere, uma vez que já existia uma estrutura de base para o desenvolvimento, levando o
programador a se concentrar logo no desenvolvimento da aplicação em si, em vez de estar preocu-
pado em realizar a instalação dos vários componentes. Esta também permitiu que, o programador
tivesse à partida um sistema de gestão de utilizadores, que facilitou todas as funcionalidades que
envolviam grupos de utilizadores e autenticação. Visto isto, é possível concluir que a arquite-
tura de prototipagem da Deloitte Digital, é uma ferramenta muito útil para acelerar o processo de
desenvolvimento, permitindo a criação de protótipos simples, como aquele que foi desenvolvido
nesta dissertação, mas também sistemas de maior escala, como aqueles que são desenvolvidos nos
projetos habituais da Deloitte.
Em relação ao desenvolvimento iterativo, este também se demonstrou muito útil para o desen-
volvimento de uma solução melhor, visto que, de iteração para iteração, a qualidade da solução foi
melhorando, sendo que o envolvimento de especialista da área do desgin de interfaces para utili-
zadores, levou a que a qualidade do protótipo aumentasse consideravelmente. O desenvolvimento
iterativo permitiu, por outro lado, o maior acompanhamento do estado de desenvolvimento por
parte da equipa de gestão, levando esta a sugerir, de iteração para iteração, as alterações necessá-
rias para a entrega de um produto que correspondesse às suas expectativas iniciais.
96
Capítulo 8
Conclusão
Com a descrição do resultado final do protótipo desenvolvido durante este projeto de disser-
tação, é agora o momento para serem apresentadas algumas das conclusões que se tiraram deste
projeto e ainda, apresentar quais as futuras etapas que irão suceder neste projeto. Neste capítulo
serão apresentadas as conclusões e perspectivas de trabalho futuro a partir desta dissertação.
8.1 Design thinking e as suas potencialidades
Uma das razões pelas quais as equipas de desenvolvimento recorrem às ferramentas do Design
Thinking para recolherem insigths sobre o produto que estão a desenvolver, é para conseguirem
compreender melhor o lado dos seus clientes/utilizadores [VVA+11], percebendo quais as suas
necessidades e expectativas em relação ao produto em desenvolvimento. Após ter estudado esta
metodologia e aplicado ao caso do modelo de negócio P2P Health Insurance, posso concluir
ao utilizar esta metodologia, que a equipa de desenvolvimento tem acesso a pontos de vista e a
realidades com os quais nunca tinha sido confrontada. Por exemplo, no decurso desta dissertação,
mesmo tendo realizado uma profunda pesquisa sobre o mercado dos seguros saúde, nunca fui
confrontado com a dificuldade que os clientes de seguros de saúde tinham em gerir os orçamentos
disponíveis pelas várias especialidades médicas ou em submeter despesas que foram realizadas
fora da rede de parceiros da sua seguradora. Sendo assim, no meu ponto de vista o recurso a
entrevistas exploratórias, bem como, o levantamento de pontos de melhoria nos workshops de
design thinking, é uma eficiente forma de recolher quais as reais expectativas e necessidades dos
clientes ou utilizadores de um serviço.
Por outro lado, o facto de os clientes ou potenciais clientes, serem motivados a pensar em
novas ideias e a materializarem essas ideias em protótipos, leva a que surjam ideias e funcionali-
dades, que para além de irem de encontro às necessidades dos utilizadores, introduzem uma nova
abordagem à resolução do problema em questão. Nos workshops realizados neste projeto, mui-
tas funcionalidades inovadoras foram sugeridas pelos participantes, nomeadamente, o motor de
97
Conclusão
pesquisa de profissionais de saúde ou a permissão para a avaliação dos prestadores de serviços
de saúde. Estas duas funcionalidades, criadas no decurso dos workshops, tinham como objetivo
corrigir dois problemas habituais na vida dos participantes: a dificuldade na procura de profissio-
nais de saúde referenciados e a falta de atenção do serviço prestado por parte dos profissionais de
saúde. Deste modo, os participantes dos workshops, além de terem sido convidados a referir quais
os pontos negativos na sua relação com os seguros de saúde e prestadores de serviços de saúde,
são também convidados a imaginarem a solução ideal para os seus problemas.
Do meu ponto de vista, o uso desta metodologia nos moldes em que foi utilizada ao longo
desta dissertação, levou a resultados muito positivos, materializados com a criação de funcionali-
dades úteis e inovadoras, que muito provavelmente não teriam sido alcançados caso fossem usadas
ferramentas mais tradicionais, como por exemplo, inquéritos. Com este método, os futuros uti-
lizadores são convidados a pensar, a expressar sentimentos e a sugerirem uma possível solução
para os seus problemas. Assim a equipa de desenvolvimento, aproxima-se do cliente e, principal-
mente, consegue fornecer soluções mais adequadas para os potenciais utilizadores. Tendo isto em
conta, considero que a utilização desta metodologia pode ser uma valiosa ajuda para as equipas de
desenvolvimento conseguirem melhorar a qualidade das soluções obtidas, assim como, o fator de
inovação introduzido por estas.
8.2 Avaliação das tecnologias escolhidas
Apesar de terem sido analisadas várias tecnologias para o desenvolvimento de protótipos, as
tecnologias escolhidas para a prototipagem da plataforma de P2P Health Insurance, foram o No-
deJS e o AngularJS, seguindo a arquitetura de prototipagem da Deloitte Digital. Esta escolha
baseou-se no facto de haver interesse por parte da Deloitte Digital em estudar a eficiência da ar-
quitetura e a rapidez com permite o desenvolvimento de novas soluções, bem como o facto de esta
arquitetura estar vocacionada para a criação de protótipos de ideias de negócio para a indústria
financeira.
A utilização desta arquitetura, demonstrou-se bastante útil, uma vez que todo o processo de
instalação das várias tecnologias e bibliotecas foi bastante rápido e está bem documentado. Por
outro lado, o facto de a estrutura base da aplicação já estar desenvolvida, leva a que o progra-
mador se consiga concentrar muito mais rapidamente no desenvolvimento das funcionalidades do
protótipo. Tal como foi referido no capítulo relativo ao estudo do estado da arte de tecnologias, a
eficiência do AngularJS e do NodeJS, comprova-se, assim como a facilidade em desenvolver caso
se tenha alguns conhecimentos em desenvolvimento web.
De uma forma geral, penso que a utilização desta arquitetura traz inúmeras vantagens, prin-
cipalmente se o programador já tem alguma experiência com nestas frameworks de JavaScritp,
pois as equipas de desenvolvimento não se têm de preocupar com todo o processo de criação dos
“alicerces” do projeto. Outra vantagem da utilização destas tecnologias, prende-se com o facto de
estas estarem a ser amplamente utilizadas e por serem uma tendência no desenvolvimento de apli-
cações web, o que coloca as soluções construídas na vanguarda do desenvolvimento tecnológico.
98
Conclusão
O único ponto negativo que foi possível registar com a utilização desta arquitetura, é o facto
de esta estar mais focada para protótipos de projetos muito grandes, contendo funcionalidades
desnecessárias quando o objetivo é a realização de uma prova de conceito de pequena escala como
foi o caso desta dissertação. Por exemplo, a existência de uma camada de Midleware e um Sistema
Central de Mensagens, é necessária em projetos de grande escala, contudo para projetos de menor
dimensão, poderá acrescentar uma complexidade desnecessária.
8.3 Trabalho Futuro
Sendo o objetivo principal desta dissertação o desenvolvimento de um protótipo de uma pla-
taforma web de P2P Health Insurance, existe um claro interesse em continuar a estudar esta ideia
num futuro próximo. Na minha opinião, nos próximos tempos seria importante estar atento ao
desenvolvimento das empresas que de momento estão a explorar esta ideia de negócio e àquelas
que irão entrar em breve, para tentar concluir se a ideia tem potencial e se pode ser ou não, uma
boa aposta para as empresas seguradoras. Visto que, este mercado é muito recente, é provável que
muitas empresas surjam nos próximos anos e que as abordagens atuais se alterem de forma a con-
seguir tornar os produtos de P2P Insurance mais atrativos, tanto para as empresas, como para os
clientes. Do ponto de vista não tecnológico, seria também importante estudar os contornos legais
por de trás desta nova forma de vender seguros, de forma a conseguir perceber quais podem ser as
restrições nos vários países.
Em segundo lugar, é importante voltar continuar a apresentar a solução aos vários interve-
nientes na aplicação, para continuar a melhorar as funcionalidades e todos os serviços que são
fornecidos pela aplicação, de forma a conseguir melhorar ao máximo a solução final, mas ao
mesmo tempo, desenvolver as funcionalidades deixadas de parte neste projeto. Podiam ainda ser
realizados workshops, mais específicos para os profissionais da indústria seguradora e para os
prestadores de serviços de saúde, para que fossem construídas mais funcionalidades que fossem
de encontro as reais necessidades e expectativas desses utilizadores.
Para além de incorporar as melhorias anteriores, seria interessante também evoluir o protótipo
atual de forma a conter integrações com outros sistemas. Por exemplo, no campo das funcio-
nalidades relacionadas com seguros de saúde, seria oportuno integrar o sistema de simulação da
apólice, com algum sistema de informação de uma seguradora, tais como, o TIA ou o Guidewire,
de forma a fornecer informação correta e de acordo com as especificações da seguradora em ques-
tão. No campo das funcionalidades relacionadas com o cálculo de taxas de esforço no exercício
físico, seria também importante, integrar o sistema com alguns dispositivos wearables, de forma a
provar que é possível que o processo de carregamento de dados relativos ao exercício físico pode
ser automático.
Numa fase mais avançada do projeto, seria também importante pensar que forma é que esta
aplicação poderia ser desenvolvida, aproveitando ao máximo as capacidades dos dispositivos mó-
veis. Para isso, provavelmente tivessem que ser realizados novos workshops de forma a compre-
ender melhor as especificidades destes dispositivos e também seria necessário redesenhar todas as
99
Conclusão
interfaces gráficas.
8.4 Avaliação do trabalho desenvolvido
Este projeto desenvolveu-se ao longo de 5 meses e foram muitas as atividades realizadas ao
longo deste período, podendo ser colocadas em 3 grupos: a pesquisa e trabalho de campo, defini-
ção da visão do sistema e desenvolvimento do protótipo.
Em relação à pesquisa realizada, considero que foi suficientemente exaustiva, tendo sido ana-
lisados variados artigos em diferentes áreas do conhecimento, nomeadamente, no âmbito da in-
dústria seguradora, das tecnologias de desenvolvimento web e na área da engenharia de requisitos
e do design thinking. Relativamente ao trabalho de campo, foram realizadas 11 entrevistas e 3
workshops, somando um total de cerca de 30 pessoas envolvidas no estudo dos problemas dos
seguros de saúde e recolha de novas funcionalidades, o que me leva a considerar que a amostra
é considerável e que os resultados podem ser considerados. A qualidade da informação obtida,
assim como, a qualidade das entrevistas e workshops realizados, levam-me a concluir que este
grupo de atividades teve resultados muito positivos.
No que diz respeito à construção da visão da plataforma de P2P Health Insurance, posso
concluir que foram obtidas muitas funcionalidades que potenciam e envolvem as três áreas desta
plataforma: os seguros de saúde, a saúde e o fator comunidade, sendo que também foram criadas
funcionalidades que poderão vir a ajudar os três intervenientes principais neste sistema: os pres-
tadores de serviços de saúde, os profissionais da indústria seguradora e os clientes dos seguros de
saúde. As funcionalidades foram enumeradas e são de possível implementação, contudo para o
seu funcionamento seria necessário que estes três atores deste sistema colaborassem ativamente na
plataforma. No entanto, podemos considerar que a visão do sistema faz um resumo muito útil de
quais os problemas e oportunidades encontradas no âmbito do P2P Health Insurance, assim como,
quais as funcionalidades que poderão ser criadas aproveitando estes problemas e oportunidades.
Depois de realizado o estudo de quais as funcionalidades que poderiam compor uma plata-
forma de P2P Health Insurance, foi implementado um protótipo com algumas das funcionalidades
consideradas de maior relevância. O protótipo construído foca-se muito nas vistas que são apre-
sentadas ao cliente, contudo algumas funcionalidades poderão ser verificadas em funcionamento,
tais como, a simulação do seguro de saúde, a partilha de informações e a marcação de consultas.
Visto que o principal objetivo deste protótipo era provar o conceito e demonstrar quais as fun-
cionalidades que poderiam estar incorporadas num sistema de P2P Health Insurance, considero
que o protótipo cumpre os objetivos propostos, no entanto, em iterações futuras poderá eventual-
mente ser melhorado de forma a contemplar as funcionalidades necessárias para ser colocado em
produção.
De um ponto de vista geral, considero que os objetivos propostos tanto pela empresa que
acolheu este projeto, como aqueles de âmbito académico, foram alcançados. A nível de enrique-
cimento pessoal, penso que este projeto me capacitou em algumas áreas, como por exemplo, a
indústria seguradora ou na metodologia de design thinking, por outro lado,também desenvolvi as
100
Conclusão
minhas capacidades no desenvolvimento web e na prototipagem de soluções. No entanto, o ponto
mais importante desta experiência, foi o facto de ser a minha primeira grande experiência de con-
tacto com o meio empresarial no campo das tecnologias de informação, na qual consegui aplicar
muitos dos conteúdos aprendidos ao longo dos últimos 5 anos.
101
Conclusão
102
Referências
[ADV] AdvanceCare - Website. URL: http://advancecare.pt/.
[AL08] Bryan Alexander e Alan Levine. Web 2.0 Storytelling - Emergence of a New Genre.EDUCAUSE, 2008.
[ANG] AngularJs - Website. URL: http://angularjs.org.
[BAC] BackboneJS - Website. URL: http://backbonejs.org.
[BB12] Angela Byron e Addison Berry. Using Drupal. 2012.
[BC14] Oliwia Berdak e Ellen Carney. Trends 2014 : European Digital Insurance. Technicalreport, Forrester, 2014.
[BECC14] Oliwia Berdak, Benjamin Ensor, Ellen Carney e Alexander Causey. Disrupting Fi-nance : Social Insurance. Technical report, Forrester, 2014.
[Ber16a] Oliwia Berdak. Disrupting Finance : Social Insurance. 2016.
[BER16b] Brooke Boyarsky, Will Enger e Ron Ritter. Developing a customer- experiencevision. pages 1–6, 2016.
[Bjö10] Martin Björemo. Evaluation of web application frameworks. PhD thesis, Universityof Gothenburg, 2010.
[BOA16] Chrisf Bradley, Clayton O’Toole e A. An incumbent ’s guide to digital disruption.Mckinsey Quarterly, (May):1–10, 2016.
[Boe11] Elizabeth Boehm. Innovation In Health Insurance Customer Experience. 2011.
[BOO] BootStrap - Website. URL: http://getbootstrap.com.
[BRA16] Alexandru Boicea, Florin Radulescu e Laura Ioana Agapin. MongoDB vs Oracle –Database Comparison MongoDB vs Oracle - database comparison. (SEPTEMBER2012), 2016. doi:10.1109/EIDWT.2012.32.
[Bro08] Tim Brown. Design Thinking. Havard Business Review, 2008.
[Cap15] Capgemini. Top 10 Trends in Insurance in 2016. 2015.
[Car15a] Ellen Carney. Haven Life Rethinks Life Insurance Distribution For A MillennialWorld. 2015.
[Car15b] Ellen Carney. Make The Business Case For Mobile Insurance. 2015.
103
REFERÊNCIAS
[CBGL14] Dimitra Chasanidou, P O Box, Andrea A Gasparini e Eunji Lee. Design ThinkingMethods and Tools for Innovation in Multidisciplinary Teams. pages 27–30, 2014.
[CdMA+11] Marcos Antonio Pereira Coelho, Fabiana Aguiar de Miranda, Jeferson Cabral Aze-vedo, Joyce Vieira Fettermann e Carlos Henrique de SouzaDaniella Costantini dasChagas Ribeiro Medeiros. O uso do cms joomla e suas ferramentas hipertextuais naprodução de sites educativos e de material didático. pages 38–47, 2011.
[Cho] Shilpi Choudhury. AngularJS, BackboneJS and EmberJS.URL: http://www.fusioncharts.com/blog/2014/08/angularjs-vs-backbone-js-vs-ember-js%E2%80%95choosing-a-javascript-framework-part-2/.
[CHR+] Mike Cantelon, Marc Harter, Nathan Rajlich, F Oreword By e Isaac Z Schlueter.Node.js in Action. Manning.
[CNT03] Jacob Cybulski, Lemai Nguyen e Theerasak Thanasankit. Understanding ProblemSolving in Requirements Engineering : Debating Creativity with IS Practitioners.7th Pacific Asia Conference on Information Systems, (July 2003):10–13, 2003.
[Coc16] Steve Cocheo. Amazon, Google, PayPal tops for millennials, 2016.URL: http://www.bankingexchange.com/news-feed/item/6087-amazon-google-paypal-tops-for-millennials.
[Col12] J.J. Colao. With 60 Million Websites, WordPress Rules The Web. So Where’sThe Money?, sep 2012. URL: http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/#721ceed855fe.
[Dcd15] OK! drive you: Uma app que induz a condução responsável,oct 2015. URL: http://www.ntech.news/mobilidade/ok-drive-you-uma-app-que-induz-a-conducao-responsavel-.aspx.
[DD16] George Demiris e George Demiris. The diffusion of virtual communitiesin health care : Concepts and challenges The diffusion of virtual communi-ties in health care : Concepts and challenges. (SEPTEMBER 2006), 2016.doi:10.1016/j.pec.2005.10.003.
[Del15] Deloitte. Insurance disrupted - General Insurance in a connected world. 2015.
[Des11] Des Toups. How many times will you crash your car?, jul 2011. URL:http://www.forbes.com/sites/moneybuilder/2011/07/27/how-many-times-will-you-crash-your-car/#74b4433c50f9.
[DiS11] David DiSalvo. The Fall of Kodak: A Tale of Disruptive Technology and Bad Bu-siness, oct 2011. URL: http://www.forbes.com/sites/daviddisalvo/2011/10/02/what-i-saw-as-kodak-crumbled/#54e735b120f5.
[DJA] Django - Website. URL: http://www.djangoproject.com.
[DRU] Drupal - Website. URL: https://www.drupal.org/.
[dS11] Nuno Miguel Queirós Arantes dos Santos. Bases de Dados alternativas para Web-sites. PhD thesis, Universidade do Porto, 2011.
104
REFERÊNCIAS
[dS15] Filipe Perdigão de Sousa. Criação de framework REST / HATEOAS Open Sourcepara desenvolvimento de APIs em Node . js. PhD thesis, Faculdade de Engenhariada Universidade do Porto, 2015.
[EMB] EmberJs - Website. URL: http://emberjs.com.
[FAL] Falcor - Website. URL: https://github.com/Netflix/falcor.
[FRI] FriendSurance - Website. URL: www.friendsurance.com/.
[GH15] Frederic Giron e Ryan Hart. Brief : Leverage Design Thinking To Spark ACustomer-Obsessed Innovation Culture Design Thinking Principles Help Create TheConfidence To Change Brief : Leverage Design Thinking To Spark A Customer-Obsessed. Technical report, 2015.
[GUE] Guevara Insurance - Website. URL: https://heyguevara.com/.
[GVJ+16] J. P. Gownder, Christopher Voce, David K. Johnson, Elinor Klavens e Vanessa Weg-ner. Harness The Potential Of Millennials With Your Workforce Technology Stra-tegy. Forrester, 2016.
[Hara] International Insurance Fact Book 2015. Technical report.
[Harb] Michael Hartl. Ruby On Rails Tutotial. Adison-Wesley.
[HBL07] Sean Hansen, Nicholas Berente e Kalle Lyytinen. Requirements in the 21st Century: Current Practice & Emerging Trends. In Dagstuhl Seminar Proceedings, pages1–57, 2007.
[HHD16] Ann M Hickey, Ann M Hickey e Alan M Davis. Elicitation Technique Selection :How Do Experts Do It ? Elicitation Technique Selection : How Do Experts Do It ?(February), 2016.
[Hou] Ayman Hourieh. Learning Website Development with Django.
[Hsu13] Yen Hsu. The Research for Exploring Product Design Characteristics by SEM viaCorrelated Innovation and Design Strategy. American Journal of Industrial andBusiness Management, 2013(January):8–16, 2013.
[HU15] Juho Hamari e Antti Ukkonen. The Sharing Economy : Why People Participate in.2015. doi:10.1002/asi.
[Hum05] Ws Humphrey. Why big software projects fail: the 12 key questions. The SoftwareEngineering Institute, pages 25–29, 2005. URL: http://www.stsc.hill.af.mil/.
[JOO] Joomla - Website. URL: https://www.joomla.org/.
[Jul] Nico Julius. WordPress 3.6 for Beginners.
[Keh13] Daniel Kehoe. What is Ruby on Rails, 2013. URL: http://railsapps.github.io/what-is-ruby-rails.html.
[KKP] Basel Kayyali, Steve Kelly e Madhu Pawar. Why digital transformation should be astrategic priority for health insurers. Mckinsey&Company.
105
REFERÊNCIAS
[LAR] Laravel - Website. URL: http://laravel.com.
[LKSR16] Markus Berger-de Leon, Jochen Kühn, Maximilian Straub e IldikoRing. Charting a path to customer centricity - How design thinkingcan transform life insurance. (March), 2016. URL: http://www.mckinsey.com/industries/financial-services/our-insights/transforming-life-insurance-with-design-thinking.
[LUS] Lusitania Seguros - Website. URL: http://www.lusitania.pt/.
[Mac15] By Mairi Macdonald. DIGITAL FRIENDS. Post Magazine, (January):12–13, 2015.
[McC14] Niall McCarthy. Americans Visit Their Doctor 4 Times A Year. Pe-ople In Japan Visit 13 Times A Year, sep 2014. URL: http://www.forbes.com/sites/niallmccarthy/2014/09/04/americans-visit-their-doctor-4-times-a-year-people-in-japan-visit-13-times-a-year-infographic/#5df8660f217c.
[MED] Medis Seguradora - Website. URL: http://www.medis.pt/pt-pt/Pages/default.aspx.
[MEN] Mendix - Website. URL: https://www.mendix.com/.
[Men15] Robert Mening. Wordpress vs Joomla vs Drupal - CMS Com-parison Chart, 2015. URL: http://websitesetup.org/cms-comparison-wordpress-vs-joomla-drupal/.
[MGR04] Neil Maiden, Alexis Gizikis e Suzanne Robertson. Provoking creativity: Ima-gine what your requirements could be like. IEEE Software, 21(5):68–75, 2004.doi:10.1109/MS.2004.1331305.
[MON] MongoDB - Website. URL: https://www.mongodb.com/.
[MR05] N. Maiden e S. Robertson. Integrating creativity into requirements processes: expe-riences with an air traffic management system. 13th IEEE International Conferenceon Requirements Engineering (RE’05), 2005. doi:10.1109/RE.2005.34.
[Nas98] Luís Nascimento. História Universal dos Seguros, 1998. URL: http://historiadoseguro.com/sobre/.
[NOD] NodeJs - Website. URL: http://nodejs.org.
[Ols14] Erik Olson. The Node.js Job Market, 2014. URL: http://8020.co/Blog/the-nodejs-job-market.
[OSC] Oscar - Website. URL: https://www.hioscar.com/.
[Out] OutSystems - Website. URL: https://www.outsystems.com.
[PB] Fernando Silva Parreiras e Marcello Peixoto Bax. Geração de Sistemas de Gestãode Conteúdo com Softwares Livres. pages 1–10.
[PEE] PeerCover - Website. URL: http://www.peercover.co.nz/.
106
REFERÊNCIAS
[Pra15] Financial Services Practice. Global Payments 2015 : A Healthy Industry ConfrontsDisruption Global Payments 2015 : A Healthy Industry Confronts Disruption In-troduction The Global Payments Industry : Healthy Growth , Shifting Drivers AChanging Landscape for Banks And Nonbanks. 2015.
[RA16] John R. Rymer e Clay Richardson And. The Forrester Wave TM : Low-Code Deve-lopment. 2016.
[RED] Redis - Website. URL: http://redis.io.
[Ree99] Js Reel. Critical success factors in software projects. Software, IEEE, (May/June1999):18–23, 1999. doi:10.1109/52.765782.
[Rob02] James Robertson. Eureka ! How analysts should invent their requirements. IEEESoftware, pages 20 – 22, 2002.
[RUB] Ruby on Rails - Website. URL: http://rubyonrails.org.
[Sal] SalesForce - Website. URL: https://www.salesforce.com/.
[SG] Shyam Seshadri e Brad Green. AngularJS Up & Running.
[Str] Christof Strauch. NoSQL Databases.
[TV10] Stefan Tilkov e Steve Vinoski Verivue. Node . js : Using JavaScript to Build High-Performance Network Programs. page 7801, 2010.
[Vo] Jack Vo. Learning Laravel : The Easiest Way Fastest way to learn developing webapplications using Laravel 4 framework.
[VVA+11] Maurício Viana, Ysmar Viana, Isabel Adler, Beatriz Russo e Brenda Lucena. DesignThinking. 2011.
[WOR] WordPress - Website. URL: https://wordpress.com/.
107
REFERÊNCIAS
108
Anexo A
Processo de Prototipagem
Ao longo deste anexo, apresentam-se os vários ecrãs resultantes das várias iterções realizadas.
A.1 Iteração 0 - Protótipo Estático
Antes de iniciar o processo de desenvolvimento, foram desenvolvidos alguns esquemas de
forma a orientar o programador na implementação. Nesta secção, são apresentadas alguns desses
esquemas construídos.
Figura A.1: Esquema representativo da página de perfil e de controlo
Figura A.2: Esquemas representativos da página de comunidade e da página de controlo
109
Processo de Prototipagem
Figura A.3: Esquemas representativos da página de marcação de consultas e do motor de pesquisade profisssionais de saúde
Figura A.4: Esquema representativo da apresentação do detalhe do sinistro
Figura A.5: Primeira estrutura pensada para a partilha de atividades entre os membros da comuni-dade
110
Processo de Prototipagem
Figura A.6: Primeira estrutura pensada para a criação de comunidades
Figura A.7: Estrutura para as página de procura por profissionais de saúde
Figura A.8: Estrutura da página de consulta do histótico de sinistros
111
Processo de Prototipagem
Figura A.9: Estrutura inicial da página de perfil pessoal
Figura A.10: Página de revisão do serviço prestado pelos profissionais de saúde
Figura A.11: Estrutura inicial da página de marcação de consultas
112
Processo de Prototipagem
Figura A.12: Estrutura inicial da página de controlo
A.2 Iteração 1 - Protótipo Funcional
Nesta secção do anexo, serão exibidos os ecrãs da primeira iteração do protótipo funcional da
plataforma de P2P Health Insurance.
Figura A.13: Página Inicial do protótipo funcional - possibilidade de simular a apólice
Figura A.14: Página de escolha do plano de saúde oferecido
113
Processo de Prototipagem
Figura A.15: Página de subscrição e registo na plataforma
Figura A.16: Página de controlo do primeiro protótipo
Figura A.17: Página de criação e adesão a comunidades
114
Processo de Prototipagem
Figura A.18: Página de procura de profissionais de saúde
Figura A.19: Página das atividades da comunidade
Figura A.20: Página de perfil pessoal
115
Processo de Prototipagem
Figura A.21: Página de consulta da cobertura do seguro
Figura A.22: Página de marcação de consulta - escolha do tipo de visita
Figura A.23: Página de marcação de consulta - escolha do tipo de especialidade
116
Processo de Prototipagem
Figura A.24: Página de marcação de consulta - escolha do profissional de saúde e data
Figura A.25: Página de revisão do serviço prestado pelos profissionais de saúde
Figura A.26: Página do histótico de informação clínica
117
Processo de Prototipagem
Figura A.27: Página de consulta do histórico dos sinistros
A.3 Iteração 2 - Protótipo Final
Tal como foi indicado no capítulo 7, após o desenvolvimento da primeira iteração, foram rea-
lizadas algumas sessões com designers especialistas em usabilidade de forma a criar um produto
mais interessante para o utilizador final. Ao longo desta secção, serão apresentados os ecrãs resul-
tantes desta iteração.
Figura A.28: Página inicial e de simulação da apólice
118
Processo de Prototipagem
Figura A.29: Página de exibição dos vários planos de saúde disponíveis
Figura A.30: Página de registo e subscrição da solução final
Figura A.31: Página de criação e adesão a comunidades do protótipo final
119
Processo de Prototipagem
Figura A.32: Página de partilha de atividades entre membros da comunidade
120
Top Related