• Nenhum resultado encontrado

Model for the Innovation Teaching (MoIT): um modelo baseado em Design Thinking, Lean Startup e Ágil para estudantes de graduação em computação

N/A
N/A
Protected

Academic year: 2021

Share "Model for the Innovation Teaching (MoIT): um modelo baseado em Design Thinking, Lean Startup e Ágil para estudantes de graduação em computação"

Copied!
85
0
0

Texto

(1)

Centro de Informática

Departamento de Ciência da Computação

Pós-graduação em Ciência da Computação

Model for the Innovation Teaching (MoIT): um modelo baseado em Design Thinking, Lean Startup e Ágil para estudantes

de graduação em computação Por

Danielly Ferreira Oliveira de Paula Dissertação de Mestrado

Recife 2015

(2)

Model for the Innovation Teaching (MoIT): um modelo baseado em Design Thinking, Lean Startup e Ágil para estudantes

de graduação em computação

Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Fe-deral de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Orientador: Cristiano Coelho de Araújo

Recife 2015

(3)

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

P324m Paula, Danielly Ferreira Oliveira de

Model for the innovation teaching (MoIT): um modelo baseado em design thinking, lean startup e ágil para estudantes de graduação em computação / Danielly Ferreira Oliveira de Paula. – Recife: O Autor, 2015.

84 f.: il., fig., tab.

Orientador: Cristiano Coelho de Araújo.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da computação, 2015.

Inclui referências e apêndice.

1. Ciência da computação. 2. Gestão da inovação. 3. Engenharia de software. I. Araújo, Cristiano Coelho de (orientador). II. Título.

004 CDD (23. ed.) UFPE- MEI 2015-45

(4)

______________________________________________ Prof. Ruy José Guerrra Barretto de Queiroz

Centro de Informática/UFPE

______________________________________________ Prof. Leonardo Augusto Gómez Castillo

Departamento de Design / UFPE

_______________________________________________ Prof. Cristiano Coelho Aráujo

Centro de Informática / UFPE

Visto e permitida a impressão. Recife, 2 de março de 2015.

___________________________________________________ Profa. Edna Natividade da Silva Barros

Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

(5)

Aos meus pais, Eliete Ferreira Oliveira de Paula e Joaci Albino de Paula Ferreira. Obrigada pelo amor infinito. Dedico a essência do meu ser à vocês.

(6)

proporcionar os momentos certos nas horas certas, pelas conversas acolhedoras, por ser meu plano de fuga nas horas de estresse. E claro, por me fazer companhia ao assistir seriados e filmes de terror sem sentido: hi friend.

Às minhas avós, tias, tios, primos e primas pelo imenso carinho ofertado, pelas palavras encorajadoras que fortalecem meu caminhar. Ter uma família unida não é comum esses dias, e a nossa soube como firmar esse ligação tão maravilhosa e cheia de sentimentos positivos.

Ao meu noivo, Cássio Leandro, por ter me ajudado a lembrar quem eu sou no momento em que estive perdida. Pelo carinho e companheirismo, pelo sentimento mútuo em querer avançar para uma nova etapa em nosso relacionamento e também por renovar minhas energias e me fazer sentir uma mulher tão amada.

Ás minhas amigas, responsáveis pelos meus sorrisos diários. Minhas madrinhas: Brhenna Chirley e Thaís Acioli e minhas daminhas: Mariana Monteiro, Bruna Chagas e Rayssa Bezerra. Muito obrigada pelo apoio, pelo carinho, pelo companheirismo, pelas risadas verdadeiras e histéricas, pelas loucuras... Enfim, por me fazerem sentir-me leve.

Aos meu amigos, José Paulo, José Leandro e Ygor Amaral, pelos conselhos, pelas palavras de conforto e pela ajuda nas horas em que mais precisei.

Ao meu orientador Prof. Dr. Cristiano Araújo que tanto me ensinou ao longo desses 2 anos através da sua persistência em perguntas que pareciam ter respostas óbvias, mas que na verdade não era bem assim.

À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo financiamento da minha pesquisa. E também ao Centro de Informática (CIn), por oferecer a melhor estrutura em que já tive oportunidade de trabalhar.

Por fim, à todas as pessoas que contribuíram direta ou indiretamente na realização de mais uma etapa da minha vida. Obrigada!

(7)

light”.

(8)

Lean Startup e Ágil são normalmente utilizadas por equipes de software para desenvolver produtos, porém não são suficientes para a criação de produtos inovadores. Alguns modelos existentes recomendam também o uso do Design Thinking durante o processo de criação de softwares inovadores, porém ainda não há um consenso na literatura sobre qual a melhor forma de combinar Design Thinking com processos de desenvolvimento de software. Portanto, a proposta deste trabalho de mestrado é testar dois modelos já existentes que integram Design Thinking, Lean Startup e Ágil com a finalidade de conceber um novo modelo baseado na análise das validações dos testes. O objetivo é integrar de forma mais natural o processo de Design Thinking a métodos já utilizados por equipes de software, reduzindo a curva de aprendizado. Os modelos selecionados foram: o modelo Hildenbrand e da Nordstrom. Estes foram testados em duas equipes de estudantes do Tech Center Recife. O Tech Center foi um ambiente desenvolvido pelo Centro de Informática da Universidade Federal de Pernambuco em parceria com a empresa BlackBerry, cujo objetivo era fomentar o espírito empreendedor nos estudantes de computação através do ensino da inovação. As equipes desenvolviam aplicativos mobile utilizando Lean Startup e SCRUM, porém não seguiam nenhum modelo que envolvesse práticas de design. Para fins de testes dos dois modelos, cada equipe do Tech Center seguiu um modelo diferente afim de desenvolver um aplicativo mobile com caráter de produto. Ao final, foram analisadas as opiniões dos usuários e as dificuldades da equipe. Baseado nesses resultados, um terceiro modelo foi concebido. O terceiro e novo modelo MoIT (Model for the Innovation Teaching) foi testado por uma das equipes com a finalidade de melhorar o aplicativo desenvolvido anteriormente, e consequentemente diminuir as dificuldades anteriores em relação ao desenvolvimento, além de promover uma maior satisfação nos usuários. Como resultado, o novo modelo apresentou um bom potencial de aprendizagem, visto que os estudantes conseguiram melhorar consideravelmente o aplicativo e assim, obtiveram uma excelente taxa de aceitação dos usuários. Além disso, estão obtendo reconhecimento, ao reproduzir os conceitos e práticas aprendidos, em seus novos empregos.

(9)

Software startups are responsible for developing products with a huge impact on the market and significant contribution to the local and global economy. However, eight out of ten IT-startups fail up to three years of its creation. The failure is caused mainly by the team’s inexperience in developing new products. This failure is driven by a lack of a program in universities that encourages entrepreneurial activity among students. Consequently, the majority of computing students have difficulty in identifying problems and validate solutions. The Lean Startup and Ágil approaches are commonly used by software teams to develop products, but they are not sufficient for the creation of innovative products. There are models that recommend the use of Design Thinking throughout the process of creating innovative softwares, but there is still no consensus in the literature about the best way to combine Design Thinking with software development processes. Therefore, the purpose of this master’s thesis is to test two existing models that combine Design Thinking, Lean Startup and Ágil in order to create a new model based on the analysis of the tests’ validation. The aim is to integrate more naturally the Design Thinking process to the methods already in use by a software team, and consequently reducing the learning curve. The two selected models were Hildebrand and Nordstrom. Those models were tested in two teams of students from Tech Center Recife. The Tech Center was an environment created by the Computer Center of Universidade Federal de Pernambuco in partnership with BlackBerry. The Tech Center aimed to encourage the entrepreneurial spirit in computing students by teaching innovation. It was composed of 12 students of computing and a coordinator. They were used to develop mobile applications using Lean Startup and SCRUM, but they did not follow any model involving design practices. With the purpose of testing the two models, each team of Tech Center followed a different model in order to develop a mobile application with the character of a product. Finally, the user’s opinion and the difficulties of the team were analyzed. Based on those results, a third model was created. The Model for the Innovation Teaching (MoIT) was tested by one of the teams in order to improve the application that was developed previously, consequently decrease the previous difficulties related to the development, and promote greater satisfaction among users. As a result, the new model showed a good potential for learning, as the students were able to considerably improve the application and thus it had an excellent users’ acceptance. Besides that, they are also gaining recognition to reproduce the concepts and practices in their new jobs.

(10)

Figura 7 – Modelo de Brown . . . 24

Figura 8 – As cinco categorias das técnicas de geração de ideias. . . 26

Figura 9 – Ágil e Lean. . . 29

Figura 10 – Modelo Lean Design Thinking. . . 31

Figura 11 – O modelo Hildenbrand. . . 32

Figura 12 – O modelo da Nordstrom. . . 34

Figura 13 – Etapas da Pesquisa. . . 40

Figura 14 – Persona Brasil +9. . . 48

Figura 15 – Reviews do Brasil +9. . . . 50

Figura 16 – Avaliação do site TechTudo sobre o Brasil +9. . . 50

Figura 17 – Protótipo de baixa fidelidade Pet Empires. . . 52

Figura 18 – Tela do Pet Empires após primeiro ciclo. . . 53

Figura 19 – MoIT - Model for the Innovation Teaching. . . 55

Figura 20 – Persona Pet Empires. . . 60

Figura 21 – Protótipo de alta fidelidade do Pet Empires. . . 61

Figura 22 – Versão final do Pet Empires. . . 62

(11)

Tabela 1 – Comparação de importantes aspectos do design thinking e lean startup. 30

Tabela 2 – Síntese dos procedimentos e técnicas metodológicas. . . 36

Tabela 3 – Protocolo de pesquisa do Brasil +9 . . . 46

Tabela 4 – Protocolo de pesquisa do Pet Empires . . . 47

Tabela 5 – Resultados dos testes de experiência no uso do aplicativo . . . 49

Tabela 6 – Cronograma Pet Empires . . . 59

(12)

1.4 Proposta da pesquisa . . . 16

1.5 Estrutura da Dissertação . . . 17

2 CONCEITOS BÁSICOS . . . 18

2.1 Lean Startup . . . 18

2.2 Métodos Ágeis para desenvolvimento de software . . . 20

2.2.1 SCRUM . . . 20

2.3 Design Thinking e Inovação . . . 22

2.3.1 Conceitos e modelos . . . 22

2.3.2 Os espaços da inovação do Design Thinking . . . 24

3 ESTADO DA ARTE . . . 28

3.1 Modelo para Desenvolvimento de software usando Lean Startup e Ágil . . . 28

3.2 Modelo para desenvolvimento de software usando Lean Startup e Design Thinking . . . 30

3.3 Um modelo de desenvolvimento de software que une Design Thin-king, Lean Startup e Ágil . . . 31

3.3.1 O modelo Hildenbrand . . . 32

3.3.2 O modelo Nordstrom Innovation Lab . . . 34

4 PROCEDIMENTOS METODOLÓGICOS . . . 36 4.1 Questões da pesquisa . . . 36 4.2 Quadro Metodológico . . . 37 4.3 Etapas da Pesquisa . . . 38 4.4 Planejamento da Pesquisa-ação . . . 40 4.4.1 Definição da amostra . . . 41 4.4.2 Protocolo da pesquisa . . . 42 4.5 Modelagem . . . 43 4.6 Avaliações . . . 43

(13)

4.6.2 Procedimento de Análise dos Dados . . . 44

4.7 Limitações da Pesquisa e ameaça à validade . . . 44

4.8 Considerações Éticas . . . 45

5 O MODELO MOIT . . . 46

5.1 Planejamento . . . 46

5.1.1 Criando o Protoloco de Pesquisa . . . 46

5.1.1.1 Brasil +9 . . . 46

5.1.1.2 Pet Empires . . . 46

5.2 Execução do Protocolo de Pesquisa . . . 47

5.2.1 Brasil +9 . . . 47 5.2.1.1 Primeira Semana . . . 47 5.2.1.2 Segunda Semana . . . 48 5.2.1.3 Teceira Semana . . . 49 5.2.1.4 Quarta Semana . . . 49 5.2.2 Pet Empires . . . 51 5.2.2.1 Primeiro Ciclo . . . 51 5.2.2.1.1 Primeiro Mês . . . 51 5.2.2.1.2 Segundo Mês . . . 53 5.2.2.1.3 Terceiro Mês . . . 53 5.3 Avaliação . . . 54 5.3.1 Modelo Hildenbrand . . . 54 5.3.2 Modelo Nordstrom . . . 54 5.4 Modelagem . . . 54 5.4.1 Unindo os modelos . . . 55 5.5 Execução . . . 59

5.5.1 Segundo Ciclo do Pet Empires . . . 59

5.5.1.1 Primeiro Mês . . . 60 5.5.1.2 Segundo Mês . . . 61 5.5.1.3 Terceiro Mês . . . 61 5.5.1.4 Quarto Mês . . . 62 5.6 Avalição . . . 63 5.6.1 Coleta de Dados . . . 63

5.6.2 Análise dos Resultados . . . 64

5.6.2.1 Impacto do Modelo MoIT na equipe . . . 64

5.6.2.2 Impacto do Modelo MoIT no produto desenvolvido . . . 64

6 CONSIDERAÇÕES FINAIS . . . 66

(14)

APÊNDICE B – QUESTIONÁRIO COM OS PARTICIPANTES DA EQUIPE PET EMPIRES . . . 75 APÊNDICE C – MANUAL ILUSTRATIVO - MODEL FOR THE

(15)

1 Introdução

Startups de software são responsáveis por produzir produtos com um enorme impacto no mercado e contribuição significativa para a economia global (PATERNOSTER et al., 2014). Porém, de acordo com Feinleib (2011), oito de dez startups de TI falham em até três anos de sua criação, sendo a principal falha durante o desenvolvimento do produto. Afim de amenizar essas falhas a literatura recomenda o uso de Design Thinking, Lean Startup e Metodologias Ágeis para desenvolver e escalar o novo produto de software (PATERNOSTER et al., 2014).

As abordagens Lean Startup e, principalmente Ágil, são bem conhecidas por equipes de desenvolvimento de software, porém não são suficientes para a criação de produtos inovadores. Logo, de acordo com Paternoster et al. (2014) também é necessário inserir práticas de design para colocar o usuário no centro do desenvolvimento (user-centered

design). As práticas de Design Thinking vêm sendo introduzidas em atividades educacionais

nas Universidades, porém ainda não há consenso sobre qual a melhor forma de combinar DT com processos de desenvolvimento de software (LINDBERG; MEINEL; WAGNER, 2011). Existem modelos que tentam unir as três abordagens, os mais referenciados são: o Modelo Hildenbrand proposto por Hildenbrand e Meyer (2012) e o modelo da Nordstrom

Innovation Lab proposto por Grossman-Kahn e Rosensweig (2012). Porém, ambos os

modelos possuem limitações que podem dificultar o desenvolvimento do novo produto de software, pois enquanto o modelo Hildenbrand foca muito em práticas ágeis, o modelo da

Nordstrom Innovation Lab foca muito em práticas de Design Thinking.

Apesar de diversos autores pesquisarem sobre como colocar essas abordagens para trabalharem em conjunto, a principal falha das startups é a inexperiência em utilizá-las. Esta falha é impulsionada devido à falta de um programa nas universidades que fomente a atividade empreendedora nos alunos, e que os prepare para o desenvolvimento de novos produtos (GATES et al., 2011). Dessa forma, não é ensinado aos estudantes um modelo de inovação durante a sua formação, assim, estes formam startups sem o conhecimento necessário para desenvolver e escalar produtos inovadores. Consequentemente, os estudantes de computação sentem um bloqueio em relação a realizar um estudo aprofundado do usuário, pois muitos sentem dificuldade em procurar entender o contexto que o usuário está inserido, e assim, identificar problemas e validar soluções.

Idealmente, as universidades deveriam fornecer um ambiente de inovação, em que seria possível aprender como desenvolver e escalar novos produtos de software utilizando na prática um modelo de inovação. A realidade é bastante diferente, especialmente no Brasil. As universidades, em sua grande maioria, não oferecem essa formação. Algumas iniciativas pontuais acontecem, mas com resultados ainda iniciais. Uma dessas iniciativas,

(16)

os ensinassem a entender o usuário.

Dessa forma, este trabalho propõe-se a testar os modelos de Hildenbrand e Meyer (2012) e Grossman-Kahn e Rosensweig (2012) nas equipes do Tech Center Recife, analisar os resultados e por fim melhorá-los através da concepção de um novo modelo. Pretende-se, assim, oferecer um modelo de integração de práticas de design mais aceitável de ser aprendido por estudantes de graduação em computação, que não possuem experiência em desenvolver, lançar e escalar um novo produto de software. Logo, serão abordados os seguintes problemas de pesquisa: Como facilitar a introdução das práticas de Design Thinking em equipes interdisciplinares de desenvolvimento de software? Quais resultados a inserção desse modelo, em equipes de estudantes de graduação de computação, provoca nos produtos de softwares desenvolvidos e na equipe?

1.1 Justificativa

As universidades, em sua maioria, não oferecem programas que promovam aos alunos de computação práticas em relação aos processos de inovação para novos produtos. Consequentemente, as startups formadas por estes estudantes tendem a falhar devido a inexperiência em desenvolver produtos inovadores Portanto, este trabalho oferece uma contribuição prática com a criação e validação de um modelo que auxilie o aprendizado dos estudantes no desenvolvimento de novos produtos de software, além de guiar a equipe a evitar escolhas que poderiam facilmente levá-los a criar produtos que ninguém quer. Oferece também contribuição teórica e empírica com extensos estudos que geraram na criação de um passo a passo sobre como introduzir o modelo em estudantes de computação com o objetivo de ensiná-los a desenvolver novos produtos com base em práticas de Design Thinking, Lean Startup e Metodologias Ágeis.

1.2 Contexto de desenvolvimento da pesquisa

Em 2013 o Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE) firmou parceria com a empresa de celular BlackBerry e assim, criaram o BlackBerry Tech Center Recife. O Tech Center foi fundado em fevereiro de 2013 com 8 desenvolvedores, 2 designers e 1 coordenador e teve seu fim em junho de 2014. Situado em um ambiente

(17)

acadêmico, seu objetivo era incentivar um perfil empreendedor nos estudantes e desenvolver produtos com impacto inovador no mercado. Apesar das equipes não serem startups, o ambiente promovido pelo Tech Center corresponde a um cenário que simula uma vivência de startup. A autora do trabalho iniciou sua pesquisa no Tech Center em março de 2013, no entanto, apenas como observadora de modo a entender o seu funcionamento. Assim notou que o tech center seguia a estrutura das Metodologias Ágeis, mais especificamente SCRUM e a filosofia do Lean Startup, porém sem nenhuma prática de design. Apenas em setembro a autora identificou modelos já existentes que combinassem práticas de desenvolvimento de software junto com práticas de design com o objetivo de criar produtos inovadores. Sendo assim, os modelos foram testados em dois grupos de desenvolvimento do tech center e avaliados. Logo após, um novo modelo foi criado baseado nas validações dos dois anteriores. Este trabalho narra como foi essa experiência e quais resultados foram provocados.

1.3 Objetivos

1.3.1 Objetivo Geral

Desenvolver um modelo para o aprendizado de desenvolvimento de novos produtos de software integrando o Design Thinking a Lean Startup e Metodologias Ágeis.

1.3.2 Objetivos Específicos

• Analisar o impacto dos modelos de Hildenbrad e da Nordstrom no Tech Center Recife.

• Criar um modelo de ensino de inovação baseado na análise dos modelos de Hilden-brand e da Nordstrom no Tech Center Recife.

• Analisar o impacto causado pela inserção do novo modelo nos produtos desenvolvidos e na equipe do Tech Center.

1.4 Proposta da pesquisa

Esta pesquisa tem como proposta oferecer um modelo de inovação baseado em Design Thinking, Lean Startup e Ágil para estudantes de graduação em computação que almejam formar startups de sucesso. O modelo tem caráter de ensino e foi baseado em outros modelos já existentes que servem como base para o desenvolvimento de novos produtos, mas que possuem limitações quando aplicadas ao aprendizado.

Os modelos selecionados foram o de Hildenbrand e Meyer (2012) e Grossman-Kahn e Rosensweig (2012). Estes foram testados e avaliados em duas equipes do BlackBerry Tech Center Recife. Baseado nas avaliações, um novo modelo foi construído e testado em uma

(18)

é composto por seis capítulos, são eles: Introdução, Conceitos Básicos, Estado da arte, Metodologia, a Pesquisa-ação e Resultados.

No capítulo 1 são abordados os problemas da pesquisa, a justificativa da realização do trabalho e os objetivos, além do escopo do estudo de modo situar o leitor sobre o tema. No capítulo 2 são abordadas definições básicas que serviram como base conceitual para este trabalho.

No capítulo 3 é levantado o estado da arte levando em consideração os artigos mais recentes sobre o tema.

O capítulo 4 apresenta os procedimentos metodológicos da pesquisa. Descreve as questões da pesquisa, a confecção do protocolo de pesquisa, além de detalhar todo o roteiro seguido. Tem como objetivo guiar o leitor no entendimento do trabalho.

No capítulo 5 é mostrada a pesquisa ação conduzida em equipes de desenvolvimento de novos softwares. Além de descrever detalhadamente as etapas citadas no capítulo anterior e a coleta de dados.

(19)

2 Conceitos Básicos

2.1 Lean Startup

Blank (2013) criou um modelo que une o Modelo de Desenvolvimento do Cliente (Customer Development model), com o Modelo de Desenvolvimento do Produto (Product

Development model) afim de oferecer o melhor suporte para as startups descobrirem os

clientes e desenvolverem o produto.

Figura 1: Modelo de Desenvolvimento do Cliente (Customer Development Model) . Fonte: (BLANK, 2013)

A maioria das startups falham em descobrir o mercado em que estão inseridas, localizar seus primeiros clientes, validar seus pressupostos, e assim crescer seu negócio (BLANK, 2013). Dessa forma, Blank (2013) desenvolveu o Modelo de Desenvolvimento do Cliente afim de resolver problemas que ocorrem frequentemente durante o desenvolvimento de novos produtos, tais como: maior ênfase na execução ao invés do aprendizado, falta de uma métrica para vendas, escala prematura, custos elevados ao lançar o produto, entre outros.

O modelo de Blank (2013) foi uma das bases para que Ries (2011) criasse o Lean Startup. Atualmente, o Lean Startup é uma das abordagens mais aceitas para startups de TI, devido as suas práticas encaixarem bem em um ambiente de extrema incerteza (PATERNOSTER et al., 2014).

O Lean Startup “é um conjunto de práticas para ajudar empreendedores a au-mentar suas chances de construir uma startup de sucesso” (RIES, 2011). Os princípios do Lean Startup são: Otimize o todo, elimine custos, construa com qualidade, aprenda constantemente, entregue rápido, envolva o usuáirio todo o tempo e continue fazendo melhor. Baseado nesses princípios Ries (2011) construiu o modelo Construa-Meça-Aprenda (Build-Measure-Learn), que pode ser observado na imagem abaixo:

(20)

Figura 2: Ciclo Build-Measure-Learn . Fonte: (RIES, 2011)

Este ciclo, também conhecido como validated learning loop, começa no estágio de Construir (Build Phase) com um conjunto de ideias ou hipóteses que são usadas para se criar artefatos (mockups, código, landing page, etc.) afim de testar uma hipótese previamente decidida (MAURYA, 2012). As respostas coletadas desse experimento são medidas (Measure Phase) de modo a analisar se as hipóteses foram confirmadas ou refutadas. Com essas informações a startup tem a capacidade de decidir as próximas ações (Learn), ou seja, se vai pivotar ou continuar a desenvolver o produto (MAURYA, 2012).

Durante este ciclo a startup tem a oportunidade de desenvolver o Business Model Canvas 1, que corresponde a um documento que serve para medir o progresso da startup, e de facilitar o aprendizado interno e externo (MAURYA, 2012). No livro Running Lean de Maurya (2012), é defendido o Lean Canvas. Este tem como objetivo ser uma ferramenta de validação do negócio da startup em que são descritos: problema, solução, proposta de valor, custo x receita, métricas, canais de acesso e diferencial.

Como resultado, a startup consegue construir o Mínimo Produto Viável – MVP, que corresponde a construção de um produto que entrega o valor que se propôs e que foi desenvolvido com o mínimo de custo e tempo (RIES, 2011). O MVP deve abordar os principais problemas que os usuários identificaram como importante para eles. Afim de reduzir o escopo do MVP é preciso: justificar a adição de cada novo ítem de acordo com o ponto de vista do usuário, começar com o problema, eliminar as funcionalidades

nice-to-have e do not needs (itens que seriam legais de ter, mas que não são realmente

necessários para a mensagem do produto)(RIES, 2011).

Afim de medir as etapas do desenvolvimento, Maurya (2012) defende as métricas AARRR (Aquisição, Ativação, Retenção, Receita e Recomendação). A etapa de aquisição serve para medir como usuários encontram o produto, a ativação mede quantos utilizam o produtos após terem o conhecido, a renteção mede quantos destes retornam após

(21)

utilizar uma vez. A métrica de receita mede como a startup ganha dinheiro e por fim, a recomendação mede se os usuários recomendam o produto para outras pessoas (MAURYA, 2012).

Apesar de ser bastante recomendado pela literatura, o Lean Startup apresenta algumas limitações: o ciclo do Lean Startup já começa com uma ideia, portanto não serve para aqueles que não sabem o que querem fazer ainda, não ensina a startup como solucionar problemas através de práticas criativas de modo a criar produtos inovadores (THORING; MÜLLER et al., 2011). E não possui um método de gerenciamento da equipe

de desenvolvimento (POPPENDIECK; CUSUMANO, 2012).

2.2 Métodos Ágeis para desenvolvimento de software

As metodologias ágeis vêm sendo consideradas como o processo mais viável para startups de base tecnológica, devido a sua natureza flexível (TAIPALE, 2010) (PATER-NOSTER et al., 2014). O objetivo das metodologias ágeis é gerenciar uma equipe de desenvolvimento de software por um conjunto de regras simples e funções flexíveis afim de estar apto ao inesperado (LINDBERG; MEINEL; WAGNER, 2011). Dentre as várias metodologias ágeis existentes, a mais popular e adotada é a Scrum (NUEVO; PIATTINI; PINO, 2011).

2.2.1 SCRUM

Scrum é um conjunto de práticas com o objetivo de otimizar o desenvolvimento de software introduzindo ideias de flexibilidade, adaptabilidade e produtividade (SCHWABER; BEEDLE, 2002). O foco é aprender como agir em um ambiente em que as variáveis técnicas (requisitos, recursos e tecnologia) estão em constante mudança (SCHWABER; BEEDLE, 2002). Como resultado, é desenvolvido um software com os requisitos que o cliente realmente quer. O Scrum trabalha com equipes pequenas de até 10 pessoas, que são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. A equipe se reúne diariamente para discutir o que foi feito até então e o que ainda precisa ser feito. Além das reuniões diárias, existe o ciclo de desenvolvimento, que são os sprints, de 30 dias. Segue uma imagem do modelo scrum:

(22)

Figura 3: Ciclo de vida do Scrum. Fonte: Schwaber e Beedle (2002)

O ciclo de vido do Scrum é composto por três fases: Pré-Planejamento, Desenvolvi-mento e Pós-planejaDesenvolvi-mento (SCHWABER; BEEDLE, 2002).

• A fase de pré-planejamento é o momento em que se define a equipe, as ferramentas que serão utilizadas e os riscos do projeto. Além disso é criado um documento chamado

Product backlog que corresponde a todos os requisitos do produto repassados pelo

cliente.

• Na fase de desenvolvimento o software é desenvolvido em ciclos, os chamados sprints. Diferentemente do product backlog, o Sprint backlog possui os requisitos que serão implementados durante aquele Sprint (geralmente 30 dias). A cada novo ciclo o sprint

backlog é refeito e a equipe adiciona novos requisitos de acordo com sua prioridade

de implementação. Diariamente são feitas reuniões com o objetivo de controlar o desenvolvimento do produto e assim evitar possíveis atrasos.

• Por fim, na fase de pós-planejamento o software é entregue para o cliente. Além disso, são feitos testes finais e a documentação. A equipe fica disponível para possíveis atualizações e manutenções para incrementar o software posteriormente.

Atualmente, as práticas de Scrum são bastante utilizadas por startups de TI, porém possuem algumas limitações. No Scrum o time não tem a liberdade de inovar, pois deve seguir os requisitos apresentados pelo cliente, o que diverge extremamente com o objetivo de uma startup. Além disso, possui pouca ênfase em equipes interdisciplinares, o foco maior é na equipe de desenvolvimento e não possui sistemas de métricas para medir o resultado do produto.

(23)

2.3 Design Thinking e Inovação 2.3.1 Conceitos e modelos

Inovação significa fazer as coisas diferentemente no reino da vida econômica (SCHUMPETER, 1934). Ainda de acordo com o autor, as inovações podem ocorrer da seguinte forma: introdução de um novo bem ou de uma nova qualidade de bem, intro-dução de um novo método de prointro-dução, abertura de novos mercados, descoberta de uma nova fonte de matéria prima e reorganização de uma indústria qualquer. Com o surgimento dessas inovações, ocorre a "destruição criativa": momento em que as velhas empresas verificam que seus mercados foram destruídos ou reduzidos pelo aparecimento de produtos competitivos vendidos a preços menores (SCHUMPETER, 1934). Perez (1985) também defende que é possível deduzir que competitividade, mercado, inovação e tecnologia estão inter-relacionados e que esta ultima estabelece um nexo entre o desenvolvimento científico e o sistema econômico, na medida que aumenta a competitividade das empresas e das instituições envolvidas.

Um bom empreendedor precisa identificar qual tipo de inovação ele pretende desenvolver: no modelo disruptivo ou sustentadora. O tipo disruptivo dá origem a novos mercados e modelos de negócio, apresentando soluções mais eficientes do que as existentes até o momento (CHRISTENSEN, 2013). Ainda de acordo com Christensen (2013), as inovações sustentadoras são obtidas por inovações incrementais (melhorias de produto e serviços das organizações) e que procuram atender principalmente os consumidores mais exigentes do mercado.

Afim de gerar essas soluções inovadoras, disruptivas ou sustentadoras, a literatura apoia abordagens centradas no usuário, sendo uma delas o Design Thinking. (PLATTNER; MEINEL; LEIFER, 2010). Uma solução é inovadora quando ela é desejável, factível e viável ao mesmo tempo (BROWN, 2009). Portanto DT é um processo criativo que usa mecanismos para identificar problemas e gerar soluções inovadoras. Para entender as estratégias de Design Thinking é preciso compreender termos fundamentais em sua estrutura: os espaços do problema e da solução (LINDBERG; MEINEL; WAGNER, 2011). O espaço do problema corresponde a fase de geração de hipóteses através da observação e entendimento do problema. O espaço da solução aborda a seleção de uma solução, e assim a sua prototipação. O conceito de espaço do problema foi primeiramente introduzido por Newell, Shaw e Simon (1959), mas Lindberg, Meinel e Wagner (2011) após suas pesquisas desenvolveram um modelo para representar graficamente esses conceitos e introduziu o conceito de “alinhamento dos espaços”, fazendo assim com que o processo seja iterativo. Segue a figura do seu modelo.

(24)

Figura 4: Espaços do Design Thinking. Fonte: Lindberg, Meinel e Wagner (2011)

Apesar de teoricamente a literatura convergir sobre a importância do Design Thinking e sobre a existência dos espaços problema e solução, ainda há muita divergência de opinião a respeito das fases dentro de cada espaço e assim, suas práticas (LIEDTKA, 2011). Vários modelos foram criados cada qual com sua nomenclatura específica, porém todos possuem como base os espaços para tratar o problema para abordar a solução. As imagens a seguir mostram os principais autores e seus respectivos modelos:

Figura 5: Modelo de Stanford. Fonte: D.School - Stanford

Figura 6: Modelo de Plattner et. al Fonte: Plattner, Meinel e Leifer (2010)

(25)

Figura 7: Modelo de Brown Fonte: Brown (2009)

Brown (2009) defende um modelo cíclico com apenas três fases. A d.school utiliza um modelo com 5 fases, e Plattner, Meinel e Leifer (2010) detalham mais o processo com 6 fases e acrescenta laços que indicam pra qual fase ir como próximo passo, a depender se a fase atual foi validada positivamente ou não. A fase de ideação de Brown (2009) corresponde as fases de empathize e define no modelo da d.school e também as fases de

understand, observe e point of view de Plattner, Meinel e Leifer (2010). Sendo esse o

momento para identificar os problemas do usuário e definir personas. A fase de ideação de Brown (2009), ideate da d.school e de Plattner, Meinel e Leifer (2010) correspondem ao momento que a equipe gera soluções baseado no problema e nas personas que foram definidas anteriormente. E por fim, Prototipação de Brown (2009) , Prototype e Test da d.school e de Plattner, Meinel e Leifer (2010) é o momento que a equipe prototipa a solução escolhida e testa com os usuários. Nessa fase, diferente dos outros autores, Brown (2009) acrescenta o momento de codificar a solução. Sendo assim, este entende o Design Thinking como uma metodologia, pois percorre todas as etapas da criação do produto.

O modelo de Brown (2009) resume melhor todas as etapas e inclui etapas de escrever códigos, sendo mais indicado para equipes mais experientes em práticas de design. Assim, o modelo de Plattner, Meinel e Leifer (2010) é mais recomendável para equipes com pouca experiência, pois facilita o entendimento através dos detalhes de como percorrer o processo e pra qual etapa ir quando o resultado da validação for positivo ou negativo. 2.3.2 Os espaços da inovação do Design Thinking

Dentro dos espaços de problema e solução, existem fases e cada fase possui suas respetivas técnicas. Além de existir diversos modelos, também há diversas práticas de pesquisa e ferramentas correspondentes a cada fase.

No espaço do problema, que corresponde a fase do entendimento do problema através das necessidades dos usuários, são utilizadas técnicas de pesquisas qualitativas,

(26)

(THORING; MÜLLER et al., 2011). As hipóteses são geradas baseadas no conhecimento prévio sobre o assunto. Estas serão verificadas com as pesquisas qualitativas. O problema é percebido através de discursões em torno do material pesquisado a respeito dos usuários. Nesta fase algumas equipes começam com um briefing, que corresponde a algumas espe-cificações do produto previamente estabelecidas por alguma empresa. Ao iniciar com o

briefing a equipe não precisa pensar em um ponto de partida, ou seja, no desafio, pois já

é dado a elas. Portanto, nesse caso esta fase começa com a pesquisa qualitativa afim de entender melhor os usuários.

No espaço da solução, que inicia-se com a fase da geração de ideias, são utilizadas várias técnicas, como: análise morfológica, brainstorming, 635 (LIEDTKA, 2011). O estágio de geração de ideias é bastante crítico, pois a escolha da técnica depende de fatores como: perfil do time e perfil do problema (SHAH et al., 2001). Ainda de acordo com Shah et al. (2001), as técnicas para gerar ideias podem ser classificadas nos seguintes métodos: intuitivo e lógico. O método intuitivo estimula o pensamento inconsciente, e o resultado é imprevisível (SHAH et al., 2001). A seguir é possível ver uma compilação feita pelo autor baseado no material de diversos autores em relação as principais técnicas de geração de ideia:

(27)

Figura 8: As cinco categorias das técnicas de ger ação de ideias. F on te: Elab orado p elo autor baseado em: Shah et al. (2001), Zwic ky (1969), Osb orn (1953) , Hogarth (1987), BONFIM (2002) , Bono (1970) , Rohrbac h (1969), V anGundy (1988) , Mizuno (1988) , F og ler, LeBlanc e Rizzo (1995) , Gordon (1961) Cross (2008)

(28)

do produto através de um custo mínimo (LIM et al., 2006). Esse estágio corresponde à principal etapa do Design Thinking, pois é onde as ideias saem do abstrato e tornam-se tangíveis, sendo assim, possível realizar testes de usabilidade e experiência com os usuários (BROWN, 2009). Os protótipos são testados com os usuários e adaptados de acordo com as opiniões coletadas. Durante todas as fases, os resultados obtidos são validados com os usuários. Ao obter feedback positivo dos usuários na fase de prototipação, o time está apto para começar a implementação do produto, ou seja, escrever códigos.

(29)

3 Estado da Arte

Neste capitulo são abordados os trabalhos mais recentes na área de desenvolvimento de software utilizando Design Thinking, Lean Startup e Ágil.

3.1 Modelo para Desenvolvimento de software usando Lean Startup e Ágil

Desenvolvimento de software Ágil (ASD) é bastante utilizado devido aos seus benefícios em relação a diminuir o tempo de desenvolvimento e aumentar a flexibilidade qualidade do produto (DYBÅ; DINGSØYR, 2008). Porém, possui limitações em como escalar o produto (VILKKI, 2010). Assim, o Lean Startup vem sendo considerado uma maneira para solucionar essa limitação, além de auxiliar a reduzir custos (POPPENDIECK; POPPENDIECK, 2003). Como filosofias, Ágil e Lean possuem algumas diferenças. Como principal diferença, no Ágil a equipe já sabe quem é o cliente, que pode ser uma única pessoa, e o software vai ser voltado exclusivamente pra ele. Ao contrário do Lean que procura descobrir quem são os clientes/usuários, descobrir suas necessidades e desenvolver uma solução para resolvê-las. Além disso, o Ágil acredita em hierarquias, onde cada integrante tem a sua posição já especificada dentro da equipe. O Lean defende a integração da equipe como igual, em que todos participam das atividades de pesquisas quali-quanti com os clientes/usuários. A literatura argumenta que a implementação de um product

owner pode prejudicar o princípio Lean de “Otimizar o todo” (RODRÍGUEZ et al., 2014).

Apesar de possuírem essas duas diferenças filosóficas, Rodríguez et al. (2014) defendem que as duas abordagens possuem práticas que permite uní-las de maneira a incrementar o processo de desenvolvimento de software. Práticas como as sprints, product backlog, sprint

backlog do Ágil e, as etapas do Lean de descobrir quem é o cliente, medir o impacto do

produto, aprender com isso e decidir se pivota ou não. Ainda não há um consenso sobre o melhor modelo que uma as duas abordagens, porém o mais referenciado é o proposto por Blank (2013), e pode ser visto a seguir.

(30)

Figura 9: Ágil e Lean. Fonte: Blank (2013)

Cada estágio corresponde a ciclos que se repetem, sendo essencial buscar a opinião do cliente/usuário como meio de analisar os resultados de cada etapa. Por fim, o produto deverá ser lançado no formato MVP – contendo apenas funcionalidades essenciais. Através do MVP é possível medir a aceitação dos usuários e assim decidir os próximos passos e começar um novo ciclo afim de reestruturá-lo (BLANK, 2013). Apesar de ambas as abordagens serem bastante recomendáveis para o processo de desenvolvimento de software, certas limitações persistem. Como o Lean já começa com a ideia, e no Ágil a ideia é dada pelo cliente, o modelo possui uma deficiência em práticas de como gerar ideias. Para gerar essas ideias é preciso um estudo profundo com o público alvo, afim de identificar necessidades. Além disso, o modelo também carece de práticas de como realizar esse estudo. Portanto, é preciso adicionar uma filosofia que seja centrada no usuário para que a equipe não se afaste das necessidades dos usuários durante o desenvolvimento.

(31)

3.2 Modelo para desenvolvimento de software usando Lean Startup e Design Thinking O objetivo do Lean Startup é a construção de um loop de feedback contínuo com os usuários durante o ciclo de desenvolvimento do produto (MAURYA, 2012). Semelhante ao Lean Startup, o Design Thinking também é focado no público alvo, porém oferece um maior suporte para o relacionamento equipe-usuário (MÜLLER; THORING, 2012). A principal diferença entre as duas abordagens, é que o Design Thinking tem como partida o entendimento das necessidades dos usuários. O Lean Startup, por possuir uma estrutura cíclica, não possui início e fim, assim, sugere que o processo deva ser executado em um formato contínuo e repetido (MÜLLER; THORING, 2012). Apesar dessa diferença, é possível unir as duas abordagens afim de desenvolver produtos inovadores com menos custos. A seguir é mostrada uma tabela com as diferenças e similaridades de cada abordagem.

Tabela 1: Comparação de importantes aspectos do design thinking e lean startup. Características Design Thinking Lean Startup

Objetivo Inovação Inovação

Foco Usuário Cliente

Ideação Pesquisa-ação Não oferece suporte Métricas Não é o foco Métricas AARRR Prototipação É parte do processo É parte do processo

Business Model Não é abordado Faz parte do processo

Pivot Não é abordado Faz parte do processo

Fonte: Müller e Thoring (2012)

A tabela 1 tem como objetivo identificar os pontos fortes e fracos de cada abordagem afim de uní-las. Além disso, é preciso identificar também como relacionar as etapas de cada uma. De acordo com Müller e Thoring (2012), no Lean Startup a fase “Learn” pode ser interpretada como “Understand” ou “Point of View” no Design Thinking. “Build” no lean startup pode ser similar a “prototype” em Design Thinking. E “measure” em lean startup pode ser “observe” ou “test” em Design Thinking. Após identificar as diferenças e similaridades e como relacionar as etapas, um modelo foi desenvolvido por Müller e Thoring (2012),unindo Design Thinking e Lean Startup e pode ser visto na imagem a seguir:

(32)

Figura 10: Modelo Lean Design Thinking. Fonte: Müller e Thoring (2012)

A imagem acima une o modelo de Design Thinking proposto por Plattner, Meinel e Leifer (2010) e o modelo do Lean Startup citado no Capítulo 2 deste trabalho. No modelo, as primeiras etapas do Design Thinking são mantidas, a etapa de prototipação é unida com Lean Startup afim de adicionar o conceito de MVP e trabalho o Business

Model. A etapa teste foi removida do final, pois ela deve estar presente ao término de cada

etapa e deverá envolver coleta de dados qualitativamente e quantitativamente proposta pelas métricas Lean. A fase customer validation objetiva verificar se realmente o produto é algo que as pessoas querem. Ou seja, o cliente está disposto a pagar pelo produto, o produto é viável economicamente e o mercado é amplo o suficiente para o negócio. Validar positivamente está etapa, significa que o produto é inovador. Com o lançamento do produto, as próximas etapas têm a finalidade de escalá-lo, expandindo as vendas e consequentemente consolidar-se como empresa (MÜLLER; THORING, 2012). Como limitação, este modelo não leva em consideração uma forma de gerenciar a etapa de implementação da solução, ou seja, levantar requisitos, dividir o tempo necessário, etc.

3.3 Um modelo de desenvolvimento de software que une Design Thinking, Lean Startup e Ágil

Como descrito anteriormente as três abordagens citadas possuem limitações que podem prejudicar o desenvolvimento de software caso sejam utilizadas separadamente. Portanto, com o objetivo de suprir essas limitações, recomenda-se o uso de todas elas em conjunto (GROSSMAN-KAHN; ROSENSWEIG, 2012) (HILDENBRAND; MEYER, 2012) (HASSI; LAAKSO, 2011).

As práticas de Ágil e Lean Startup já vêm sendo praticadas para desenvolvimento de softwares há muito tempo, porém é preciso de um modelo que não apenas ajude em como

(33)

transformar ideias em produtos viáveis, mas também em como ter as ideias em primeiro lugar. Portanto as práticas de Design Thinking objetivam aumentar a possibilidade e confiabilidade de inovações desenvolvidas em equipes (BROWN, 2009). Porém, o ambiente startup é tão incerto que não segue nenhuma metodologia em si, e sim práticas de várias (PATERNOSTER et al., 2014). Ou seja, o novo modelo que une todas as três abordagens não representa todas as metodologias juntas, mas na verdade um conjunto de práticas selecionadas. Por ser tratar de um assunto bastante novo, ainda não há um modelo amplamente aceito pela literatura, pois poucos pesquisadores conseguiram lançar um modelo que unisse as melhores práticas das três abordagens. Os modelos mais conhecidos são dos pesquisadores Grossman-Kahn e Rosensweig (2012) e Hildenbrand e Meyer (2012). 3.3.1 O modelo Hildenbrand

Hildenbrand e Meyer (2012) realizaram um estudo de caso piloto com o objetivo de entender se um modelo que unisse DT, Lean e Ágil funcionaria em equipes de desenvol-vimento de software. Segue um diagrama do seu modelo e a seguir a descrição do estudo de caso de acordo com cada fase:

Figura 11: O modelo Hildenbrand. Fonte: Hildenbrand e Meyer (2012)

Como é possível observar na imagem acima o modelo segue três fases, que são descritas a seguir.

• Fase 1: O objetivo dessa fase é entender o mundo em que os usuários estão inseridos de modo a perceber suas necessidades e assim possíveis problemas. Neste momento, Hildenbrand e Meyer (2012) recorreram as práticas de Design Thinking, que são: observação, entrevistas e imersão no contexto. Os autores chamaram esta pesquisa de “360o Research” e durou 2 dias.

(34)

uma rodada de ideação. Nessa etapa, Hildenbrand e Meyer (2012) unem as fases do DT de ideação e prototipação, utilizando assim uma única prática. Como o produto deveria ser um aplicativo mobile, os membros da equipe geraram ideias desenhando as telas em papel. Repetiram o processo, até chegar em único fluxo de telas. Todas as práticas citadas foram selecionadas do Design Thinking. No segundo dia, mesmo com o fluxo de telas já prontos, eles ainda não tinham requisitos o suficiente para o product backlog, para isso recorreram a uma prática Scrum chamada “user story map”. Com esta prática conseguiram definir todos os requisitos, e assim, dividiram a história em histórias menores para que cada uma fosse executada durante um

Sprint. No terceiro dia a equipe decidiu como seria o plano de trabalho deles, em

relação a datas em horários, levando em consideração a filosofia Lean, ou seja, sem desperdícios.

• Fase 3: Nesta fase, a equipe começou a implementar e entraram mais profundamente na filosofia do Lean e nas práticas de controle de desenvolvimento do Scrum, porém tiveram que recorrer a algumas práticas de DT durante os Sprints, como ideação e prototipação de papel, para melhorar certos aspectos que não foram muito bem entendidos. Este modelo teve um resultado bastante positivo, a equipe conseguiu vender seu produto 3 meses após o início de sua construção.

O trabalho de Hildenbrand e Meyer (2012) conseguem unir com sucesso as três abordagens em uma equipe de desenvolvimento de software. Porém, uma das limitações do modelo é ausência do pivotar do Lean, logo não oferece um direcionamento a startup quando o desenvolvimento do seu produto não vale a pena ser continuado. Uma segunda limitação é não ensinar a startup como solucionar problemas criativamente através de práticas de ideação, sendo esta etapa importantíssima para o desenvolvimento de uma solução inovadora. E por último, o modelo também não aborda como testar o produto com os usuários antes de ser implementado de modo a fazer testes de usabilidade e experiência, ou seja, é necessário incluir práticas de prototipação.

(35)

3.3.2 O modelo Nordstrom Innovation Lab

O pesquisador Grossman-Kahn e Rosensweig (2012) afirmam em sua pesquisa que o seu modelo permitiu que a Nordstrom Innovation Lab (localizado nos Estados Unidos) criasse ideias inovadoras através das práticas criativas do DT, as práticas flexíveis e adaptáveis do Ágil, e conseguiram escalar através das práticas do Lean. Segue a imagem do modelo.

Figura 12: O modelo da Nordstrom.

Fonte: (GROSSMAN-KAHN; ROSENSWEIG, 2012)

Grossman-Kahn e Rosensweig (2012) defendem que o desenvolvimento de um novo produto deve começar com práticas de Design Thinking, pois o time precisa o mais cedo possível descobrir as necessidades dos usuários, identificar problemas e propor soluções inovadoras. Todas as práticas do Design Thinking seguiram o Human Centered Design Toolkit da IDEO 1 . Somente após realizar o passo-a-passo do manual da IDEO, o time está hábil para dar início as práticas de Ágil, seguindo a filosofia do Lean. O modelo de Grossman-Kahn e Rosensweig (2012) foi validado positivamente pela equipe do laboratório da Nordstrom, porém o time não conseguiu vender o produto que construíram. Além disso não especifica quais práticas de Ágil e Lean são seguidas, e nem detalha o passo-a-passo de cada fase.

Utilizar as três abordagens juntas têm a capacidade de oferecer um maior potencial para o desenvolvimento de produtos de software inovadores. O modelo de Hildenbrand e Meyer (2012) reforça as práticas Ágil e introduz sutilmente práticas de Design Thinking,

(36)
(37)

4 Procedimentos Metodológicos

Este capítulo visa descrever os procedimentos e técnicas escolhidos para este projeto de mestrado. A proposta deste trabalho segue uma metodologia que foi organizada visando o objetivo de analisar o impacto causado ao inserir o novo modelo MoIT (Model for the

Innovation Teaching) de desenvolvimento de software com práticas de design em estudantes

de graduação inseridos em um ambiente que simula a vivência de uma startup. A seção 4.1 traz as questões que esta pesquisa pretende responder. Na seção 4.2 é abordado o quadro metodológico adotado nessa pesquisa. Na seção 4.3 são descritas as etapas que a pesquisa percorreu para atingir seu objetivo. O planejamento do protocolo da pesquisa e descrição da amostragem são abordados na seção 4.4. A seção 4.5 aborda sobre a modelagem do novo modelo. Na seção 4.6 descreve a técnica de coleta de dados e procedimentos de análise. E por fim, as seções 4.7 e 4.8 referem-se a aspectos de validade, confiabilidade e limitações da pesquisa, além das considerações éticas que o trabalho adotou. Na tabela a seguir são apresentados quais métodos e técnicas foram utilizadas no desenvolver da pesquisa:

Tabela 2: Síntese dos procedimentos e técnicas metodológicas. Tabela Metodológica

Abordagem da pesquisa Qualitativa e Quantitativa De acordo com o propósito Exploratória e Descritiva

Métodos da pesquisa Pesquisa-ação

Técnica de coleta de dados Questionários e Observação-Participante Fonte: Elaborado pelo autor (2015)

4.1 Questões da pesquisa

A elaboração das questões da pesquisa é uma etapa inicial de um estudo qualitativo (EASTERBROOK et al., 2008). As questões a seguir servem de guia para direcionar o desenvolvimento do projeto de mestrado. Assim, com o objetivo de identificar falhas em startups e possíveis soluções foram definidas as questões a serem respondidas no decorrer do estudo.

Q1: Como introduzir práticas de Design Thinking em equipes de desenvolvimento de software?

Q2: Como construir um modelo que ensine estudantes de graduação em computação a como desenvolver novos produtos de software utilizando Design Thinking, Lean Startup e Ágil?

(38)

4.2 Quadro Metodológico

De acordo com Lakatos e Marconi (1991, p. 46) "método é um conjunto de atividades sistemáticas e racionais que, com maior segurança e economia, permite alcançar o objetivo". Uma variedade de métodos e suas combinações podem ser aplicados em uma pesquisa a fim de entender completamente o problema (EASTERBROOK et al., 2008). Portanto considerando o problema de pesquisa e os objetivos a serem atingidos, as seguintes estratégias foram selecionadas:

• Quanto a abordagem e metodologia: Esta pesquisa caracteriza-se como um estudo qualitativo e quantitativo. É qualitativo, pois leva em consideração opiniões afim de descrever a complexidade de introduzir Design Thinking em estudantes de graduação em computação. Além disso, foi necessário compreender e classificar os processos dinâmicos vividos nos grupos, contribuir no processo de mudança, possibilitando o entendimento das mais variadas particularidades dos indivíduos. No caso desta pesquisa, segue uma abordagem qualitativa afim de compreender o funcionamento de um ambiente de ensino de inovação, identificar processos a serem seguidos, propor um novo modelo, entender a interação dos integrantes com a solução proposta e por fim, propor melhorias. É também quantitativo, pois os pesquisados responderam questi-onários fechados afim de coletar algumas informações a respeito das modificações provocadas pela pesquisa. Dessa forma, os dados serão medidos qualitativamente e quantitativamente, portanto a informação coletada pela pesquisadora é tanto expressa em números quanto em opiniões e comportamentos dos pesquisados. • Quanto ao propósito: De acordo com os propósitos esta pesquisa caracteriza-se como

exploratória e descritiva. É exploratória, pois este tipo de estudo visa proporcionar um maior conhecimento para a autora acerca do assunto, a fim de que seja possível formular problemas mais precisos ou criar hipóteses com a finalidade básica de desenvolver, esclarecer e modificar conceitos e ideias através de experiências práticas com o problema pesquisado (GIL, 2010). Portanto, este trabalho caracteriza-se quanto a este propósito, pois procura obter um maior conhecimento sobre processos de desenvolvimento de software para startup, afim de identificar a principal falha e formular problemas, criar hipóteses e testá-las. É descritiva, pois de acordo com

(39)

Hyman (1967) este tipo de pesquisa descreve um fenômeno e registra a maneira que ocorre. Logo, este trabalho descreve a criação e validação de um modelo que serve para facilitar a introdução de práticas de design em equipes de graduação em computação, mais especificamente de desenvolvimento de software.

• Quanto aos métodos de procedimentos: Esta pesquisa caracteriza-se como uma pesquisa-ação. Esse tipo de pesquisa tem base empírica e é concebida e realizada em estreita associação com uma ação ou com a resolução de um problema coletivo no qual os pesquisadores e os participantes representativos da situação ou do problema estão envolvidos de modo cooperativo ou participativo (THIOLLENT, 2011). E de acordo com Susman e Evered (1978), é uma abordagem que combina geração de teoria com a mudança do sistema social através da ação do pesquisador no sistema social. Portanto, no caso desta pesquisa, a autora observa, mas também participa em conjunto com os pesquisados através de uma forte cooperação entre ambos de modo a facilitar o aprendizado das práticas de Design Thinking por equipes de desenvolvimento de software.

4.3 Etapas da Pesquisa

Toda pesquisa precisa de um bom planejamento, portanto as etapas que ela vai seguir precisam ser definidas logo no início do estudo. Portanto, a seguir é descrito cada etapa que esta pesquisa percorreu até atingir seu objetivo. Ao final da sessão é apresentada uma imagem que sintetiza o roteiro da pesquisa.

• Revisão Bibliográfica: Inicialmente, definiu-se o tema de pesquisa: Startups de software. Tendo o tema em mente, iniciou-se a Revisão Bibliográfica, momento em que pesquisou-se sobre o cenário das Startups de software, motivos que levam uma Startup de software a falhar e práticas de desenvolvimento de software já existentes que adequam-se a este cenário. O objetivo foi adquirir um conhecimento maior sobre o funcionamento das Startups e suas falhas mais comuns, afim de levantar novos questionamentos a respeito deste cenário e assim, definir um problema a ser resolvido. Para definição do problema de pesquisa, selecionou-se como falha a inexperiência dos integrantes das startups a respeito de um processo de desenvolvimento de novos softwares que tenha práticas de design e que possa ser seguido por um ambiente startup. Assim o problema de pesquisa é “Como facilitar a introdução das práticas de Design Thinking em equipes interdisciplinares de desenvolvimento de software?”. Após a exploração do tema, as questões da pesquisa foram refinadas em conjunto com o problema definido, portanto, a partir disso a pesquisa passou a ter um roteiro a ser seguido.

(40)

positivos e negativos de cada um.

• Avaliação: Com a conclusão do protocolo de pesquisa, os resultados coletados foram analisados e mapeados de modo a identificar as dificuldades e as adaptações neces-sárias no modelo de acordo com desfecho da pesquisa de campo. As informações serviram de base para o desenvolvimento do novo modelo.

• Modelagem: Os resultados da avaliação anterior serviram para a modelagem do terceiro modelo. O novo modelo MoIT (Model for the Innovation Teaching) tem a finalidade de resolver as dificuldades e falhas encontradas nos dois modelos anteriores. Além disso, tem como objetivo ensinar a estudantes de graduação em computação a como desenvolver produtos inovadores utilizando Design Thinking, Scrum e Lean Startup.

• Execução: O novo modelo MoIT (Model for the Innovation Teaching) foi introduzido em uma das equipes afim de testar se realmente as falhas dos modelos anteriores foram solucionadas.

• Avaliação: Após solucionar as dificuldades encontradas na aplicação do protocolo, são descritos os resultados da execução do Modelo MoIT através de uma análise do impacto do modelo na equipe e no produto desenvolvido. Esta etapa tem como objetivo verificar se a intervenção feita pela autora resultou na melhoria do cenário.

(41)

Figura 13: Etapas da Pesquisa. Elaborado pelo autor (2015)

4.4 Planejamento da Pesquisa-ação

A fase de planejamento tem a finalidade de definir os objetivos e problemas que serão tratados durante o desenvolvimento da pesquisa, definir os procedimentos de coleta e análise dos dados. Neste caso escolheu-se o seguinte problema “Como facilitar a introdução das práticas de Design Thinking em equipes interdisciplinares de desenvolvimento de software?”. Com o objetivo de solucionar este problema, dois modelos foram escolhidos e são abordados a seguir:

• Modelo Hildenbrand: o modelo de Hildenbrand e Meyer (2012) foi escolhido, pois apesar de ser novo é o mais referenciado. Ele propõe práticas simples de como unir Design Thinking, Lean Startup e Metodologias Ágeis. Porém não aborda algumas práticas importantes, como: pivotar do Lean e como escalar o produto.

• Modelo Nordstrom Innovation Lab: apesar de pouco testado e pouco referenciado, o modelo de Grossman-Kahn e Rosensweig (2012) é mais completo do que o modelo proposto por Hildenbrand e Meyer (2012), pois além de agregar as práticas de Design

(42)

Ágeis, o modelo da Nordstrom Innovation Lab apresenta mais práticas de Design Thinking e Lean Startup. As limitações foram percebidas inicialmente em teoria, logo após, ambos os modelos foram testados em equipes diferentes afim de confirmá-las. Com as avaliações, foi possível unir os dois modelos, criar um terceiro e assim testá-lo em uma das equipes de desenvolvimento. Assim, com a união dos dois modelos é possível preencher as lacunas existentes no processo de ensino de criação de produtos.

Com o objetivo de medir se a inserção do novo modelo na amostragem foi positiva, foi aplicado um questionário com os integrantes das equipes a respeito das modificações no cenário antes do modelo e depois de modelo, além disso foi verificado qualitativamente se os usuários sentiram-se satisfeitos com os novos produtos lançados.

Após definir o problema de pesquisa, o método a ser aplicado e como medir o seu sucesso, foi preciso escolher qual amostragem iria participar do estudo.

4.4.1 Definição da amostra

Foram escolhidas duas equipes interdisciplinares, compostas por estudantes de graduação em design e computação, de desenvolvimento mobile situadas no BlackBerry Tech Center Recife. O BlackBerry Tech Center Recife localizava-se no Centro de Informática da Universidade Federal de Pernambuco (UFPE). Era composto por estudantes de graduação de Computação e Design, duas alunas de mestrado e um Coordenador, sendo este último doutor e professor da instituição citada. O objetivo do Tech Center era fomentar o empreendedorismo e inovação no desenvolvimento aplicativos para a plataforma BlackBerry 10 (BB10), sendo assim, um ambiente de criação de aplicativos mobile que simula a vivência de uma startup e seu processo de concepção de produtos.

O Tech Center foi um laboratório para o ensino da inovação. Ele foi escolhido devido a possibilidade em acompanhar as equipes diariamente enquanto durasse o contrato. Dessa forma, a autora frequentou o Tech Center de segunda à sexta de março/2013 à junho/2014, o que proporcionou um excelente acompanhamento da evolução no aprendizado das equipes, o que não seria possível em uma turma da graduação durante período de 6 meses de uma disciplina.

(43)

• Brasil +9: Composta por três alunos da graduação, onde dois são desenvolvedo-res e um designer. Todos na faixa etária entre 19 e 23 anos. Os três integrantes possuíam pouco conhecimento sobre métodos de design, e já possuíam experiência com desenvolvimento de aplicativos mobile. Brasil +9 é um aplicativo que insere automaticamente o dígito 9 em números cujo DDD são de São Paulo. Desde agosto de 2013, os números de telefone da capital paulista e do interior passaram de oito para nove dígitos, devido a nova norma da Anatel. Apesar de já existirem vários aplicativos no mercado, as pessoas tinham grande dificuldade em utilizá-los por diversos motivos, como: erros de funcionalidade, falhas em confiabilidade, entre outros. O objetivo do aplicativo é oferecer uma experiência agradável através de um aplicativo fácil e confiável para os usuários que querem adicionar o digito nove aos números de sua agenda. Nessa equipe foi testado o modelo de Hildenbrand e Meyer (2012).

• Jogo Pet Empires: Composta por 3 alunos da graduação, dois desenvolvedores e um designer. Todos na faixa etária entre 19 e 23 anos. Os três integrantes possuíam pouco conhecimento sobre métodos de design e nunca tinham construído um jogo antes. O Pet Empires tem como objetivo ser um jogo de estratégia disputado em turnos para jogadores que querem competir com pessoas reais e sem perder muito tempo. Inicialmente, foi testado nessa equipe o modelo de Grossman-Kahn e Rosensweig (2012), e logo após o novo modelo MoIT.

4.4.2 Protocolo da pesquisa

Após definir a amostragem, foi preciso planejar o protocolo da pesquisa. O protocolo é um documento dinâmico, pois pode sofrer atualizações ao longo do estudo devido a mudanças de algum plano (RUNESON; HÖST, 2009). Assim, o protocolo da pesquisa consiste em quais etapas seguir para aplicar o novo modelo. Como foi citado no tópico anterior, a amostragem consiste em duas equipes: Pe tEmpires e Brasil +9, a seguir é descrito o planejamento para cada situação.

• Brasil +9: Devido ao fato que esse aplicativo reconfigura os contatos da agenda do usuário, este precisa depositar uma grande confiança na funcionalidade do aplicativo. Portanto, a equipe teve uma difícil missão no desenvolvimento desse aplicativo que foi: como oferecer um aplicativo confiável de modo que o usuário tenha a melhor experiência possível? Diante disso, este aplicativo precisou de um estudo muito extenso sobre práticas de design. Baseado nessas informações, a equipe percorreu toda as etapas do processo proposto por Hildenbrand e Meyer (2012). A diferença desse aplicativo para o Pet Empires, consiste no fato que um briefing foi dado a equipe pela BlackBerry, portanto, a equipe estava mais direcionada.

(44)

ao briefing fornecido, como o público-alvo.

4.5 Modelagem

Os dois modelos foram introduzidos em duas equipes do Tech Center Recife. Como resultado, dois produtos diferentes foram desenvolvidos e submetidos a opinião dos usuários. Ambos os processos de desenvolvimento foram observados pela autora. Baseando-se nessas observações e na opinião dos usuários, os dois modelos foram modelados e um terceiro modelo foi criado. O novo modelo tem como finalidade solucionar as falhas dos modelos anteriores e diminuir as dificuldades em apender a utilizar práticas de Design Thinking.

4.6 Avaliações

Nesta seção são descritos os instrumentos de coleta e análise de dados utilizados durante a avaliação da introdução dos três modelos.

4.6.1 Definição do Instrumento de Coleta de Dados

Para esta pesquisa foram utilizadas as seguintes técnicas de coleta de dados:

• Observação-Participante: As equipes foram observadas durante a introdução dos três modelos afim de identificar as dificuldades enfrentadas pelos integrantes durante o processo de desenvolvimento. Também foram observadas no decorrer do processo de aplicação do modelo, com o intuito de identificar expressões e reações que muitas vezes são imperceptíveis para quem faz, mas que constituem dados importantes para a pesquisa por ser a resposta natural em relação ao que está ocorrendo. Além de observar, a autora também participou do desenvolvimento dos projetos, ajudando com a aplicação do modelo.

• Questionário: Uma das equipes respondeu a um questionário aberto após a introdução do modelo MoIT (Model for the Innovation Teaching) afim de verificar se a solução proposta resolveu as dificuldades identificadas. As perguntas foram divididas de acordo com os seis tipos de questões defendidos por Merriam (2014). As perguntas do

(45)

tipo Experiência têm como objetivo obter dados sobre a experiência do participante. As perguntas do tipo opinião são feitas quando é do interesse do pesquisador obter a opinião do participante. As perguntas do tipo Sentimento foca na dimensão afetiva do participante e têm como objetivo adjetivos como resposta. As perguntas do tipo sensoriais têm como objetivo identificar a percepção do participante sobre os acontecimentos ao seu redor. E por fim, as perguntas do tipo background tem como objetivo obter dados básicos sobre a vida do participante, como idade, profissão, etc. O questionário pode ser visto no Apêndice B.

Além disso, com o objetivo de medir a aceitação dos usuários dos produtos desenvolvidos (Brasil +9 e Pet Empires), os usuários responderam um questionário fechado. Através do questionário fechado é possível obter respostas mais precisas e analisá-las estatisticamente. Além disso, o questionário é uma boa escolha quando não é possível entrevistar toda a amostragem devido a diversos fatores. Portanto, como os usuários dos novos produtos são muitos e não tinha disponibilidade para entrevistas, um questionário teve que ser aplicado. 4.6.2 Procedimento de Análise dos Dados

O objetivo de uma análise qualitativa é derivar conclusões de forma clara, sistêmica e evidenciada a partir dos dados (RUNESON; HÖST, 2009). Portanto, após coletar os dados, estes foram analisados levando em consideração as duas etapas da pesquisa: M1: momento antes da inserção do modelo MoIT, M2: momento depois da aplicação do modelo MoIT.

Após a inserção do modelo MoIT (M2) foram analisados os resultados dos questio-nários e as percepções da autora em relação às diferenças entre M1 e M2. Os dados foram confrontados qualitativamente afim de verificar a satisfação da equipe de desenvolvimento em relação as novas práticas inseridas. Dessa forma é possível verificar se a equipe aprendeu o modelo, se o modelo melhorou o processo de desenvolvimento e se gerou mais problemas ou desafios.

Além disso, também foi confrontado qualitativamente as diferenças entre os antigos e novos produtos desenvolvidos, neste momento foi levado em consideração as reviews na BlackBerry World e em sites famosos.

4.7 Limitações da Pesquisa e ameaça à validade

A principal limitação foi devido ao risco da BlackBerry encerrar o contrato com a universidade, e assim fechar o Tech Center. Durante o desenvolvimento da pesquisa, esse risco concretizou-se. Portanto, como o desenvolvimento de produtos mobile exige um período extenso de meses, esta pesquisa limitou-se a percorrer apenas uma vez o ciclo do modelo proposto.

(46)

mesmas conclusões e resultados. De acordo com Strauss e Corbin (2008), em uma pesquisa qualitativa é impossível reproduzir o mesmo fenômeno e as mesmas condições da pesquisa original, portanto é difícil obter o mesmo resultado. Apesar disso, com a intenção de aumentar a confiabilidade da pesquisa, elaborou-se o protocolo da pesquisa-ação detalhando quais procedimentos e técnicas foram utilizados nessa pesquisa.

4.8 Considerações Éticas

Esta pesquisa envolve a participação de seres humanos para a obtenção de dados, portanto seguirá as orientações do Conselho Nacional de Saúde, através da resolução 196/96. Esta regulamentação contém o TCLE (Termo de Consentimento Livre e Esclarecido). Este termo tem como objetivo esclarecer os participantes a respeito do propósito da pesquisa, os procedimentos do qual eles participarão e políticas de privacidade. De acordo com Filgueiras e Silva (2008) é o documento mais importante no que se refere o envolvimento de seres humanos em uma pesquisa. O termo pode ser visto no Apêndice A.

(47)

5 O Modelo MoIT

Neste capítulo é mostrado todo o caminho percorrido até o desenvolvimento e avalição do Model for the Innovation Teaching (MoIT). As etapas resumem-se em: Planejamento, Execução, Avaliação, Modelagem, Execução e Avaliação.

5.1 Planejamento

Nesta seção é descrito como o protocolo de pesquisa foi desenvolvido com o objetivo de facilitar a introdução dos modelos.

5.1.1 Criando o Protoloco de Pesquisa

O protocolo de pesquisa tem como objetivo guiar a pesquisadora sobre as etapas de como inserir o novo modelo na amostragem, ou seja, nas equipes do BlackBerry Tech Center Recife. As equipes são: Brasil +9 e Pet Empires.

5.1.1.1 Brasil +9

Na equipe do Brasil +9 foi testado o modelo de Hildenbrand e Meyer (2012). A equipe recebeu o briefing da BlackBerry em agosto de 2013. O aplicativo deveria ser construído em um mês com o seguinte desafio: como nós podemos construir um aplicativo que adicione o nono dígito nos contatos da agenda telefônica do usuário? Diante dessas informações, o protocolo foi construído e pode ser observada na Tabela 3

Tabela 3: Protocolo de pesquisa do Brasil +9

SEMANA FASE

Primeira Primeira Fase + Segunda Fase

Segunda Segunda Fase + Terceira Fase

Terceira Terceira Fase

Quarta Terceira Fase

O MVP foi entregue a Blackberry e o app foi postado na BlackBerry World Fonte: Elaborado pelo autor (2015)

Com o protocolo em mente, a equipe estava preparada para começar o desenvolvimen-to.

5.1.1.2 Pet Empires

Na equipe do Pet Empires, inicialmente, foi testado o modelo da Nordstrom. O desenvolvimento começou em outubro de 2013 e durou 3 meses. Segue a Tabela 4 do

Referências

Documentos relacionados

Não se está perante a situação de uma única falta injustificada; só se pode falar em falta de assiduidade se houver alguma continuidade, o que não implica que tenham de ser faltas

Resumidamente a forma de comercialização dos apartamentos FLAT e operação de locação dos apartamentos do HOTEL para uma bandeira hoteleira proposta a seguir objetiva a

Para disciplinar o processo de desenvolvimento, a Engenharia de Usabilidade, também conceituada e descrita neste capítulo, descreve os métodos estruturados, a

Este estudo, que tem como objetivo a investigação do imaginário de estudantes de Psicologia sobre o primeiro atendimento clínico, insere-se num

[Informar a data, o nome e a assinatura do dirigente máximo que aprovou o documento Termo de Abertura do Projeto antes deste projeto ser solicitado ao Governador pelo

Para atingir este fim, foram adotados diversos métodos: busca bibliográfica sobre os conceitos envolvidos na relação do desenvolvimento de software com

Gottardo e Cestari Junior (2008) efetuaram análise de viabilidade econômica na implantação de silo de armazenagem de grãos utilizando os seguintes modelos VPL,

Quando os dados são analisados categorizando as respostas por tempo de trabalho no SERPRO, é possível observar que os respondentes com menor tempo de trabalho concordam menos que