peer to peer health insurance · saúde, utilizando metodologias ágeis de desenvolvimento que...

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

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

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

“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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


é 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


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


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


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


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


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


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


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


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



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


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


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


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


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


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


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


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


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


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


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


• 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


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


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


• 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


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


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


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


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


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.


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



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


• 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


• 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


• 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.


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



• 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


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


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


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


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


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


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


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


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


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


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


Figura 6.3: Diagrama de Casos de Uso do Cliente alavancando o fator comunidade

77


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


• 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

http://advancecare.pt/

http://angularjs.org

http://backbonejs.org

http://getbootstrap.com

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

http://www.fusioncharts.com/blog/2014/08/angularjs-vs-backbone-js-vs-ember-js%E2%80%95choosing-a-javascript-framework-part-2/

http://www.fusioncharts.com/blog/2014/08/angularjs-vs-backbone-js-vs-ember-js%E2%80%95choosing-a-javascript-framework-part-2/

http://www.bankingexchange.com/news-feed/item/6087-amazon-google-paypal-tops-for-millennials

http://www.bankingexchange.com/news-feed/item/6087-amazon-google-paypal-tops-for-millennials

http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/#721ceed855fe

http://www.forbes.com/sites/jjcolao/2012/09/05/the-internets-mother-tongue/#721ceed855fe

http://www.ntech.news/mobilidade/ok-drive-you-uma-app-que-induz-a-conducao-responsavel-.aspx



http://www.forbes.com/sites/moneybuilder/2011/07/27/how-many-times-will-you-crash-your-car/#74b4433c50f9

http://www.forbes.com/sites/moneybuilder/2011/07/27/how-many-times-will-you-crash-your-car/#74b4433c50f9

http://www.forbes.com/sites/daviddisalvo/2011/10/02/what-i-saw-as-kodak-crumbled/#54e735b120f5

http://www.forbes.com/sites/daviddisalvo/2011/10/02/what-i-saw-as-kodak-crumbled/#54e735b120f5

http://www.djangoproject.com

https://www.drupal.org/

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

http://emberjs.com

https://github.com/Netflix/falcor

www.friendsurance.com/

https://heyguevara.com/

http://www.stsc.hill.af.mil/

http://www.stsc.hill.af.mil/

https://www.joomla.org/

http://railsapps.github.io/what-is-ruby-rails.html

http://railsapps.github.io/what-is-ruby-rails.html

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

http://laravel.com

http://www.mckinsey.com/industries/financial-services/our-insights/transforming-life-insurance-with-design-thinking



http://www.lusitania.pt/

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




http://www.medis.pt/pt-pt/Pages/default.aspx

http://www.medis.pt/pt-pt/Pages/default.aspx

https://www.mendix.com/

http://websitesetup.org/cms-comparison-wordpress-vs-joomla-drupal/

http://websitesetup.org/cms-comparison-wordpress-vs-joomla-drupal/

https://www.mongodb.com/

http://historiadoseguro.com/sobre/

http://historiadoseguro.com/sobre/

http://nodejs.org

http://8020.co/Blog/the-nodejs-job-market

http://8020.co/Blog/the-nodejs-job-market

https://www.hioscar.com/

https://www.outsystems.com

http://www.peercover.co.nz/

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

http://redis.io

http://rubyonrails.org

https://www.salesforce.com/

https://wordpress.com/

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


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


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


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


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


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


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


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


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


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


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


Figura A.32: Página de partilha de atividades entre membros da comunidade

120

peer to peer health insurance · saúde, utilizando metodologias ágeis de desenvolvimento que...

Documents