pensando e fazendo software com design thinking. Muitas vezes o software é pensado como sendo
 uma atividade extremamente abstrata, cognitiva, uma atividade de solução de problemas. Mas existe
 um aspecto também do fazer, do making, de colocar mão na massa, um aspecto que tem muito a ver
 também com arte, que tem a ver com o design, tem a ver com a ciência. E todas essas diferentes áreas,
 e a engenharia também, obviamente, juntas elas conformam várias maneiras de você pensar projetos.
 E é isso que eu vou trabalhar e dissertar um pouquinho nesse mini tutorial. Eu vou focalizar
 no fundamento conceitual do pensamento projetual design thinking. Ao invés de ter atividades
 práticas como era previsto, se fosse realizado presencialmente, eu vou mostrar exemplos de
 atividades práticas que vocês podem fazer. Então vai ser um tutorial mais compacto do que
 ele seria originalmente presencialmente. Bom, só enfatizando na minha formação de que eu venho da
 área do design de serviço, design de experiências, estou buscando na engenharia de software um diálogo,
 diferente da maior parte dos pesquisadores que trabalham com design thinking na engenharia de
 software. Normalmente são pessoas que vêm originárias da computação e vão buscar no design.
 Aqui nesse caso é o oposto. O bacana é que dentro desse grupo da engenharia de software do PPG,
 da PUC do Paraná, existe esse espaço para esse tipo de colaboração interdisciplinar de pessoas
 que vêm de várias outras áreas. Eu não sou o único que tem um background diferente da computação.
 Para começar, vamos desbancar o mito de que design thinking é um modelo, uma metodologia de
 possibilidade ou de inovação. Da mesma maneira como na engenharia de software se discute que não
 existe apenas um método ou uma única metodologia e nem tudo dentro da engenharia de software se trata
 de métodos ou processos, da mesma maneira existe esse pensamento dentro do design thinking. Então
 quando as pessoas falam da engenharia de software, normalmente elas mencionam esse modelo simplista,
 que é o chamado cascata, modelo cascata de desenvolvimento. Primeiro você define as categorias mais
 abstratas até chegar às categorias mais concretas. Primeiro você pensa muito bem no que você vai
 fazer antes de começar a construir o seu software, antes de colocar a mão na massa. Isso é como as
 pessoas normalmente comunicam o modelo de cascata criado pelo Royce em 1970, porém no artigo em que
 o Royce apresenta esse modelo ele já diz que esse modelo está furado, ele não vai funcionar porque
 é bem provável que não consiga antecipar todas as variáveis que vão ser importantes para o software
 antes dele ser desenvolvido. Por isso ele recomenda e tem um outro modelo nesse mesmo artigo que haja
 uma fase preliminar de criação de o que depois viria a ser chamado de protótipos. Então o modelo
 cascata não foi inventado pelo Royce, ele foi na verdade criticado pelo Royce e algumas pessoas
 pensam que ele foi inventado. Da mesma maneira, similarmente, existe um preconceito também de
 que o design think se resume a esse modelo criado pela Stanford na D.school, que é a escola que
 promove o design think lá dentro. Esse modelo foi criado para uma oficina específica para ajudar
 os estudantes a entenderem que eles poderiam construir os seus próprios modelos de design
 think, não necessariamente seguindo essa ordem de desenvolver empatia, definir que você vai construir,
 idear, prototipar e testar. Não precisava ser nessa ordem, tanto é que cada uma etapa ela tem
 o formato de um hexágono para que os hexágono seja encaixados de diferentes maneiras de acordo
 com a demanda do projeto. O que acontece é que infelizmente muitas pessoas não vão a fundo na
 pesquisa do design think, assim como muitas pessoas também não vão a fundo na pesquisa em
 um software e acabam reproduzindo modelos lineários e simplistas como esse. Portanto,
 eu não vou fazer isso nesse tutorial e ensinar como aplicar cada uma dessas etapas, porque não
 acredito que isso seja a essência do design thinking, assim como também não acredito que
 o modelo waterfall ou o modelo ágil de desenvolvimento de software seja a essência do que é a engenharia
 de software. Eu busco algo mais profundo do que isso e eu convido vocês a caminhar nessa
 aventura transdisciplinar, novamente discutindo o design thinking não só numa única área,
 mas não como método de uma área, um modelo de uma área específica, mas como uma prática que
 integra o pensar e o fazer em diferentes disciplinas. Esse insight eu estou puxando de um artigo muito
 bacana escrito pela Lucy Kimball em 2011 e complementado em 2012, é um artigo maravilhoso
 e que ela fala que o design thinking é uma prática e não só um método ou um processo.
 Essa prática evolui, ela se transforma e ela precisa ser internalizada. Como toda prática,
 ela tem um aspecto de pensar que se expressa muitas vezes nos métodos, nos processos,
 mas existe um processo tácito também do fazer, do colocar a mão na massa e de um saber que muitas
 vezes é difícil de verbalizar. Então, resumindo, design thinking é pensar fazendo e fazer pensando
 com o corpo inteiro e não só com a mente. Então, um desafio muito grande fazer um tutorial sobre
 design thinking a distância, porque a gente não pode estar como os meus alunos costumam estar,
 dentro de oficinas de design thinking como essa que vocês veem na foto, usando o corpo inteiro e
 fazendo a comparação de você criar ideias sentado, sem se mexer numa cadeira, sem escrever nada,
 só no "gó, gó, gó" e depois você vai escrevendo nos papezinhos, introduz papéis coloridos, aí você
 vai colocar os roupas e figurinos bizarros para estimular as pessoas a se soltar e colocar o corpo
 todo para pensar. E o posicionamento corporal nesse espaço físico é fundamental para as relações
 entre os participantes da oficina e muda tudo. A gente testa isso em sala de aula através de
 experimentos e eles percebem os estudantes que faz diferença assim, apesar de parecer ridículo para
 quem está de fora, é justamente esse ridículo para quem está de dentro que ajuda a explorar um
 espaço de possibilidades que não foi explorado ainda, que está fora do clichê. E o design thinking
 não é só pensar e fazer integrado, mas também pensar e fazer junto com outra pessoa. Aqui temos
 uma foto de uma última oficina de design thinking que eu conduzi aqui no grupo de engenharia de
 software da PUC do Paraná, vocês podem ver as shares do evento, a Sheila Heiner, a Andrea
 Schaele lá atrás, elas estão brincando com esse material que eu adoro utilizar, os legos de patinhos,
 que você construir patinhos, é tão gostoso de você construir porque é tão simples, mas tem
 desafios muito interessantes que exigem que as pessoas façam e pensem sem separar uma coisa
 da outra. Nesse caso, a Sheila e o colega dela, Vinícius, têm que transmitir a informação de
 uma pessoa e construir um pato para outra pessoa sem mostrar o pato só através do verbo, então
 tem que fazer uma transmissão de informações e uma transposição dessa informação para um formato
 diferente e falar diferentes linguagens, que é um desafio muito importante dessa colaboração
 interdisciplinar, um desafio também importante para o desenvolvimento de software. E o que é legal
 desse pensar e fazer junto é que você começa a desenvolver uma visão positiva sobre a complexidade
 e a incerteza. Então, ao invés de temer a incerteza, temer a complexidade, quando você começa a fazer
 e criar, você começa a ver que você começa a fazer parte da complexidade e não mais uma coisa
 separada, distante, uma coisa que a gente começa a sentir e aproveitar não só a nossa habilidade
 completamente racional, explícita, cognitiva do pensamento para decupar a complexidade, mas também
 nossos sentimentos, a nossa intuição. Isso tudo junto fica com substanciado, objetificado através
 de quem constrói fisicamente. Então, quando a gente no design thinking faz essas painéis na parede cheios
 de post-it, que é o, digamos assim, clichê do design thinking, não é por nada. A gente tem interesse
 de fazer uma espécie de download do que está no cérebro de várias pessoas para que se torne mais
 explícito. E esse download tem que acontecer rápido para que as pessoas se sincronizem e consigam
 de uma complexidade emergente do projeto. Então, pode parecer um pouco desestruturado a abordagem,
 se você comparar com outras maneiras de trabalhar a informação, mas a vantagem é que ela permite
 esse fazer e pensar esse ciclo rápido. Ao invés de você ficar várias horas pensando e depois você
 fazer, que é o que as abordagens mais conhecidas na engenharia do software fazem, no design thinking
 ela promove esse ciclo iterativo muito rápido de pensar e fazer, avançando então gradualmente em
 cima da complexidade e entendendo que a incerteza é inerente ao processo. A complexidade e a incerteza,
 dentro da engenharia de software, tradicionalmente é vista como sendo uma coisa negativa que precisa
 ser ou eliminada ou a gente tem que se acostumar com viver com ela. O Fred Brooks, que é um
 ator, um dos fundadores da engenharia de software, escreveu um artigo em 1987 em que ele compara essa
 complexidade crescente com um lobisomem, como se fosse um bicho que aparece do nada, no meio da
 noite, quando você menos espera e que ele tenta te cercar de todos os lados, te perseguir, você
 não sabe o que fazer contra ele, ele é praticamente imortal. Você usa qualquer tipo de ferramenta para
 fazer o lobisomem e ele não morre. E essa piada, que é bastante divertida, tem a ver um pouco com a
 realidade mesmo das equipes de software, que experimentam um processo de aumento dos requisitos
 depois que o projeto foi iniciado, porque clientes, porque stakeholders não sabiam especificar o que
 eles queriam para aquele projeto. Nesse artigo ele diz que isso é absolutamente normal e nunca vai
 ser eliminado. Essa complexidade inerente do software não pode ser eliminada. Então, por isso que ele
 diz que não existem balas de prata para matar lobisomens na engenharia de software, pois o software
 é abstrato, ele é difícil de visualizar mesmo, ele é feito por humanos e não por Deus, por isso
 ele não é perfeito, ele vai ter falhas. E a comunicação entre as pessoas, que se torna cada vez
 mais necessária quanto maior é o projeto de software, ela se torna mais difícil também, porque
 maior o projeto de software, mais camadas e níveis de abstração necessários. Então o que acontece é
 que essa abstração nunca vai retirar a complexidade do software, na verdade ela muitas vezes pode
 aumentar. Então isso é visto por ele como uma coisa que a gente tem que aceitar na engenharia de
 software. Esse artigo foi bastante influente, algumas pessoas questionaram e disseram "não temos
 a bala de prata, agora sim conseguimos". Mas eu quero lembrar ele porque o design think hoje está
 vazio para a engenharia de software como se fosse uma nova bala de prata do desenvolvimento de software,
 como se ele pudesse resolver magicamente todos os problemas de colaboração, de criatividade e inovação
 que a própria engenharia de software tem buscado resolver por diferentes outras colaborações com
 outras disciplinas, porque o design não é a única disciplina que colabora com a engenharia de software.
 Existem contribuições da administração, contribuições da engenharia de produção, contribuições de várias
 áreas, sociologia, antropologia, que não necessariamente passam pelo design. E o próprio design
 já tem um histórico de colaboração e de contribuição para engenharia de software de muito tempo.
 Desde 1980 já tem livros específicos que tentam aproximar design da engenharia de software. O primeiro
 é o mais conhecido sobre design centrado no usuário, com vários autores comparando diferentes
 teorias do design da arquitetura, como elas poderiam ser úteis para projetar sistemas mais
 aplicados ao usuário. Tem também o grupo do design participativo escandinavo também propondo
 uma aproximação também com o design de produtos, como uma maneira de prototipar com materiais simples
 e sujos, materiais rápidos como papel, cartolina. Esses métodos foram criados através dessa
 interdisciplinaridade, que depois acaba se tornando uma questão mais epistemológica lá nos anos 90,
 quando se começa a perguntar qual é a essência da engenharia de software, seria justamente o projeto,
 engenharia de software ou software design? Como que a gente vai chamar essa disciplina? Qual o futuro
 dela? Então tem dois livros maravilhosos, um editado pelo Terry Vinograd, o outro pelo Bruce Bloom,
 um pouco conhecido, mas os dois discutindo a epistemologia da engenharia de software frente
 à questão do design, se ela se muda alguma coisa a pensar a partir do projeto. E aí depois tem uma
 tecnologia mais forte com o mercado de trabalho, com livros como o do Alan Cooper, do "Inmates are
 running the Alzheimer", que é um livro divertidíssimo, que ele fala que os profissionais
 trabalham com tecnologia de informação, são os malucos que adoram tecnologia de informação,
 então eles colocam e complicam a tecnologia de informação e eles são como se fossem os malucos
 que estão presos dentro de um hospício, eles não podem estar dirigindo hospício, temos que chamar
 pessoas que tenham sensibilidade humana para dirigir a produção do software. É uma questão que eu
 realmente questiono, porque eu sou muito mais a favor do design participativo, mas é interessante
 pontuar que também é uma aproximação possível de um design mais voltado à direção de arte,
 direção de interação da experiência, que vai se desdobrar numa aproximação com a interação
 humana no computador, em um livro também fantástico e importantíssimo aqui no Brasil,
 porque foi traduzido logo cedo, que é o "Design de Interação" da Prisci, Roger de Sharp. Depois tem
 um outro livro que complementa e questiona esse outro livro, que é pouco conhecido, o "Thoughtful
 Design" do Jonas Lufgren e do Eric Stolterman. E por fim, o último livro que eu menciono é o
 próprio livro do Fred Brooks, muitos anos depois de ter escrito aquele sobre a bala de prata na
 engenheira de software, de não ter, ele começa a ir atrás e pesquisar toda a história do pensamento
 projetual, do design thinking na arquitetura, no design de produtos e ele escreve um livro maravilhoso,
 pouco conhecido, mas traduzido para o português e que tem ideias excelentes de como aproximar
 essas duas áreas. Então não é de hoje, não é de sei lá, cinco anos atrás que o design thinking
 chegou na engenheira de software. O fazer e o pensar juntos, integrados, já esteram discutidos
 por todos esses livros, né? Porém, o que que esse design thinking novo que está se falando hoje em
 mais de novo? Tem coisa nova? Bom, primeiro de tudo eu gostaria de traduzir o termo de design thinking,
 gostaria de traduzir para pensamento projetual. Pensamento projetual, ele ajuda-nos a reduzir o
 jargão, né? Porque muitas vezes fala-se design thinking e como não é uma palavra nem do português,
 nem do espanhol, às vezes as pessoas ficam perdidas. O que significa? E aceitam qualquer coisa que venha,
 a partir daqui ficam assim, como se esse rapaz aí, meu aluno, num workshop, uma oficina de design
 thinking, nossa que coisa incrível, não sei de onde veio, não sei para que que serve, mas eu gostei.
 E eu acho que é bom discutir o que que significa esse termo. Então ele não é um método mágico de
 criatividade vindo do exterior. Ele pode ser comparado com, em outras áreas, no direito, por
 exemplo, existe o pensamento jurídico. Por que que não podemos ter também o pensamento projetual
 no design? E não é só o direito que estuda pensamento jurídico. Sociologia também estuda,
 a antropologia também estuda o pensamento jurídico. E eu também acho que outras disciplinas,
 como a engenharia de software, também podem estudar o pensamento projetual do design.
 E existem vários tipos de pensamentos projetuais. Quando a gente traduz, tem a vantagem do plural,
 então a gente pode distinguir escolas de pensamento projetuais, assim como escolas
 de pensamento jurídico. Lá tem o grego, o romano, moderno, contemporâneo, porque não teria também
 escolas de pensamento projetual. Eu tenho feito uma pesquisa já há alguns anos, tentando identificar
 diferentes escolas de pensamento projetual. A minha tese de doutorado, ela já começa a trabalhar com
 isso, mas eu ainda não tenho uma publicação que consolida e defina claramente elas, ainda está em
 curso e eu estou compartilhando aqui com vocês essas reflexões. Então eu identifico três principais
 escolas. A escola sistemática, que é aquela que se baseia numa técnica da redução conceitual dos
 problemas, ela pode ser representada pelo Herbert Simon e o livro Ciências do Artificial, que também
 está traduzido para o português. É um livro muito interessante que ele tenta propor a ideia de que
 podemos ter uma nova ciência só para as áreas de projeto, isso inclui a engenharia, inclui a
 arquitetura, inclui qualquer... a própria ciência da computação entraria dentro dessas ciências do
 artificial. E lá pelas tantas ele fala que uma abordagem muito interessante para entender os
 fenômenos artificiais é quebrar os problemas maiores e problemas menores e esses problemas
 não se subem problemas para resolvê-los passo a passo. Você resolve um problema de cada vez e cria uma
 visão do todo depois para integrar as diferentes partes do problema. Isso é a escola sistemática,
 ela é muito influente dentro da engenharia de software. Não é só porque as ciências do
 artificial, né, tenha dado origem, por exemplo, a um método de pesquisa também bastante utilizado
 na engenharia de software, mas mais ainda nos sistemas de informação que é o Design Science Research,
 DSR. Não é a única maneira de se fazer ciências do artificial, existem outros métodos, outras
 abordagens, mas principalmente os fundamentos epistemológicos e metodológicos gerais, os
 princípios que estão nessa obra aparecem também em várias publicações da engenharia de software.
 Já na arquitetura, nas artes, na publicidade, na comunicação e no próprio design reina a
 escola reflexiva do pensamento projetual, que se baseia numa prática de reflexão nação. Essa
 escola valoriza muito a intuição, o sentimento, a percepção subjetiva dos problemas e a
 transformação desses problemas a partir dessa reflexão nação. Então, ao invés de você pensar
 primeiro e depois você agir, como falei, você tenta pensar e fazer ao mesmo tempo, gerando um
 ciclo retroalimentante de agir e refletir, agir e refletir, porque não se separa a reflexão da
 ação, por isso que existe o IFFEN, que junta a reflexão na ação. Essa escola foi muito bem
 representada por um livro do Donald Shun, que é um pesquisador advindo da área da arquitetura,
 que escreveu em 1983, sobre como que esse modo de pensar reflexivo era fundamental para o ensino de
 arquitetura e como isso também poderia ser fundamental para outras áreas profissionais que
 não fossem necessariamente da arquitetura. Por isso, esse livro teve um impacto muito grande na
 área de educação e hoje é utilizado como uma das áreas, como um dos fundamentos para o que se
 chamava pedagogia de projetos, que é uma das metodologias ativas de educação. Teve influência,
 então, do ensino da arquitetura e mais atrás do ensino de belas artes, da onde a própria
 arquitetura surgiu. O ensino de arquitetura se inspirou muito no estudo das escolas de
 belas artes, que são anteriores, datam lá do renascentismo. Por fim, a última escola de
 projeto projetual que eu identifico é a escola expansiva, essa assim é mais recente e ela tenta
 expandir constantemente o escopo do projeto, sempre incluindo novas pessoas, novos problemas,
 novas soluções, de uma maneira que é até mesmo caótico. A escola expansiva não nega nenhuma
 possibilidade nova, as possibilidades novas aparecem e elas vão ser incorporadas, às vezes elas são
 guardadas ou descartadas, mas isso não impede que elas passem pelo crivo do pensamento projetual.
 Então, ao invés de restringir o pensamento, aquilo que você consegue quebrar em pedaços e definir
 os pedaços, que é a escola sistemática, ao invés de restringir o pensamento, aquilo que você consegue
 através de um ciclo constante de ação e reflexão entender, na expansiva qualquer coisa que vai
 entrando vai influenciando o processo de design, vai entrando dentro desse espaço abstrato de
 possibilidades que é fundamental para superar as ideias clichê, as ideias que estão acostumadas a
 serem reproduzidas, repetidas. Então, a escola expansiva tem uma preocupação muito grande com o
 que se pode chamar da gestão de inovação, ou seja, uma mudança dos paradigmas do que se considera
 possível. Aí eu vou fazer uma referência própria, a minha tese de doutorado é uma das primeiras
 publicações que tenta sistematizar historicamente o pensamento projetual expansivo e eu tenho,
 depois da minha tese, evoluído esse conceito para essas comparações que eu estou mostrando aqui
 e também para uma prática que eu vou mostrar no final dessa apresentação. Eu só queria pontuar
 alguns exemplos aqui práticos como essas escolas vão gerar uma maneira completamente diferente de
 encarar a mesma situação de projeto. Digamos que a sua situação de projeto seja, invente
 1001 maneiras de chegar do ponto A até o ponto B e aí essas pessoas que vão fazer isso dentro
 de uma oficina de criatividade ou de pensamento visual, elas vão usar as referências que elas
 têm nas suas disciplinas, os seus pensamentos projetuais e ao colocar para fora e materializar
 as soluções para esse mesmo problema, já se torna visível as diferenças das escolas que
 essas pessoas tiveram, contato. No lado esquerdo a gente vê a solução de alguém que vem de uma
 escola sistemática, então ao invés de desenhar manualmente diferentes caminhos para ir de A a B,
 foi escrito um código que poderia gerar diferentes caminhos de A a B de maneira com uma
 forma totalmente randômica. No meio vemos alguém que está usando o pensamento reflexivo e criando
 ideias que são cada vez mais complexificadas, você vê que o A a B mais simples está ali no meio e
 depois vai ficando cada vez mais complexo, conforme vai se interagindo com o material e refletindo como
 fazer diferente. Já no terceiro exemplo a gente vê algo completamente diferente, uma quebra de
 forma do que era possível, ao invés de fazer uma linha e representar uma linha de A a B, são representados
 objetos concretos que são de fato coisas que levam a gente de um lugar ao outro, um avião ou um avião
 em chamas e aí você tendo que pular no avião de chamas para chegar no lugar onde você está indo,
 pode ser que você não chegue até B, então nem sempre você vai chegar até B e essa reflexão
 da problema vem porque começa a trazer pessoas que questionam até mesmo os fundamentos do problema,
 será que esse é o problema que a gente quer resolver mesmo? Então no expansivo existe uma
 tendência de mudar, não só a solução, mas mudar também o próprio problema, os problemas
 são expansivos tanto quanto as soluções. Enfim, agora eu queria fazer uma pausa então para
 verificar se vocês têm alguma dúvida, se vocês tiverem dúvidas agora, nesse momento já coloquem
 um bate-papo, queria perguntar aí para a equipe, Luca e os colegas, nós temos alguma questão no
 bate-papo para que eu possa esclarecer agora nesse momento, Luca? Então eu vou continuar agora
 elaborando um pouquinho mais sobre pensamento projetual expansivo, que é o meu tema principal
 de interesse, é o tema da minha tese de doutorado. Primeiro, deixar bem claro, o que se chama atualmente
 de design thinking, eu prefiro definir de maneira mais científica e específica como pensamento
 projetual expansivo. Esse pensamento projetual expansivo, o que ele traz de novo se eu fazer e
 pensar juntos já existia em outras abordagens, inclusive no sistemático? Aqui tem a inclusão
 de contradições no projeto, então além de problemas e soluções, o pensamento projetual
 expansivo traz um elemento inignominável, um elemento insistematizável, um elemento de incerteza
 constante, um elemento que pode gerar construção de novas ideias, assim como destruição de novas
 ideias. Tudo pode acontecer a partir de uma contradição, ao invés de eliminar essa contradição,
 de dizer "não queremos que isso exista no projeto, não queremos que haja conflitos no projeto derivados
 das contradições", o pensamento projetual expansivo ele acolhe. Então veja o que que acontece, se você
 tem um pensamento fechado para conflitos, você vai pensar dentro da caixa, porque aquilo que envolve
 conflitos é justamente aquilo que vai transformar o estado das coisas, o paradigmas, então as pessoas
 têm medo, é o lobisomem, lobisomem está fora da caixa, então você pensa dentro da caixa porque
 ele não tem conflito. Agora, se você usa o pensamento projetual expansivo ele vai te estimular a
 pensar nas bordas, nas fronteiras, nas margens da caixa, sempre tentando empurrar um pouquinho mais,
 vai mais um pouquinho, vai mais um pouquinho aí, e aí o que acontece? Quando você começa a expandir a caixa,
 começam a surgir as contradições, essas contradições não são ainda conflitos, tá? Contradição é um
 aspecto diferente, ele fala de uma tensão acumulada que pode gerar conflito, se gerar não tem problema,
 a gente vai acolher, mas a gente não vai empurrar tanto que o conflito seja totalmente destrutivo,
 vamos empurrar um pouquinho para que a gente tenha o conflito produtivo, conflito que vai fazer as
 disciplinas, as pessoas buscarem ideias diferentes, elas vão gerar atrito, isso vai gerar uma
 sensação do espaço de possibilidades que não era antes explorada porque tinha lobisomem lá,
 que as pessoas tinham medo, o ar dos tabus, né, a área fora da caixa. Então o pensamento projetual
 expansivo ele não existiu sempre dentro do design da arquitetura, isso é realmente um desenvolvimento
 histórico recente de mais ou menos uns 20 anos para cá, até mais ou menos 1990 o pensamento
 projetual dominante dentro das escolas de arquitetura e design e artes mesmo era o reflexivo, né, era um
 conhecimento tasto que só podia ser aprendido pela vivência naquele ateliê de projetos que descreve
 muito bem, descrito muito bem pelo Donald Shawn no livro dele em 1983. Esse ateliê de projetos
 também era, também acontecia dentro das empresas onde futuros arquitetos e designers iam trabalhar,
 lá dentro tinha profissionais especializados com diferentes áreas de projeto para construir
 ideias e detalhar elas, vejam o que que esse povo está fazendo aí atrás, eles estão fazendo os
 rascunhos de uma grande construção que antigamente não tinha o CAD, Computer Aided Design, então era
 tudo na mão, né, e esses caras aprendiam a fazer isso fazendo, né, exigia muito desenvolventura e
 de uma qualidade manual mas também projetual de você pensar aquele projeto. Nessa época os
 escritórios eles eram disciplinares, então tinha o escritório de arquitetura, o escritório de
 engenharia, o escritório de engenharia x, né, de PTO e cada um se preocupava com a sua disciplina, né.
 A partir dos anos 90 é que começam a surgir os escritórios e as equipes multidisciplinares que
 foram criados por diferentes designers ou arquitetos, engenheiros e inclusive profissionais de outras
 áreas que não são das áreas de projeto como a IDO, né, que em 1990 começou a contratar engenheiro
 geneticista, começou a contratar antropólogos, sociólogos, psicólogos para participar desse
 ateliê e eles gravaram um programa de televisão no TV Nightline que é um programa bastante
 bem feito da televisão americana mostrando como funcionava essa equipe multidisciplinar para
 resolver um problema simples que era inovar dentro dos carrinhos de compra nos supermercados e eles
 fizeram uma coisa fantástica, né, projeto muito bacana, esse vídeo vale muito a pena ver quem
 quiser entrar no YouTube e procurar por Deep Dive ou Deep TV Nightline IDO, vocês vão encontrar esse
 vídeo. É muito bacana para aprender os fundamentos básicos desse pensamento projetual expansivo que é
 muito bacana, mas as pessoas acham que era esse projeto que mudou tudo, não, existia toda uma
 conjuntura, né, que gerou inclusive o interesse da IDO de aparecer na televisão em cadeia nacional
 mostrando o que poderia ser o segredo fechado a sete chaves deles, porque que eles abriram
 esse segredo das sete chaves? Por que eles não guardam aquilo só para os clientes deles? Porque
 eles já tinham percebido que o projeto que, o foco no desenho industrial que eles tinham nos anos
 80, 70, já não era mais suficiente para atrair novos clientes, né, porque a industrialização
 estava saindo dos Estados Unidos e indo para a China e eles precisavam ter um diferencial nessa
 nova economia que ficou conhecida como economia de experiências. Então tem um livro muito bacana
 também do Pine Gilmore que descreve essa evolução ou progressão econômica das ofertas das empresas,
 né, de mercadoria para produto, para serviço e experiência, na experiência onde se atinge o maior
 valor econômico, mas também valor de uso. E nesse livro se explica que é uma lógica completamente
 diferente você projetar uma experiência do que projetar um produto. Então precisa ter uma atenção
 maior e uma colaboração maior entre os diferentes departamentos da mesma empresa. Eles precisam
 colaborar mais, porque a experiência não é oferecida por uma única departamento. Cada
 departamento interage com o cliente de uma maneira direta ou indireta e se esse departamento não se
 desenvolve com a experiência do usuário, essa experiência ela é abalada, porque a experiência
 é um conceito integrador, um conceito holístico que vai envolver todas as interações que o cliente
 tem, o usuário, com aquele determinado empresa. Então a ID.O percebendo essa conjuntura,
 ela começa a vender serviços que vão muito além do desenho industrial, do projeto de produto que
 é uma especialidade deles antes disso. E eles começam a vender o próprio processo de trabalho
 que eles usavam para o produto físico, eles começam a usar e aplicar e expandir esse pensamento
 projetual reflexivo para um pensamento projetual expansivo que vai envolver problemas cada vez
 mais complexos. Eles também começam a interagir com várias empresas da área do desenvolvimento
 de software, em especial a SAP, que é uma gigante, a SAP, o Raso Platner, que é o CEO da SAP,
 ele se encanta com o trabalho da ID.O e fala "quero que todo mundo aqui na minha empresa conheça
 a intenda de design thinking" e aí ele recebe a proposta do David Kelley da ID.O e também da
 Stanford, ele também era professor da Universidade Stanford, de abrir uma escola específica para
 os interesses profissionais da SAP e de outros lugares também, promovendo uma mudança global
 na área de tecnologia da informação e depois uma mudança ampla no próprio empreendedorismo
 de alto impacto. Essa D.School foi financiada então pelo pelo Raso Platner com uma doação
 generosa em 2005 e desde então tem sido o principal ponto de referência para disseminar
 essa essa prática de design thinking ou pensamento projetual expansivo. Porém, além de estar localizado
 em Stanford, o Raso Platner, como ele é a da SAP, a SAP vem originalmente da Alemanha, ele perde
 também para que haja uma D.School dentro da Universidade Pouls D'Am. Esses 200 começam a formar
 profissionais a partir de 2005 e acabam gerando um movimento global. Inclusive no Brasil tem uma
 D.School de Design Thinking em São Paulo já funcionando há muito tempo disseminando esse
 pensamento projetual expansivo. Paralelo a isso, cresce uma ideologia, que está por aí, uma
 ideologia liberal, que está cada vez mais forte, de que os estados, ou melhor dizendo, as empresas
 devem assumir contradições ignoradas pelo estado, como o déficit de moradia ou a falta de
 pensamento bolígico, que vocês estão vendo de maneira, o encontro desses dois problemas na mesma
 situação da foto. E aí a IDO começa a capitalizar em cima disso. Ela funda uma empresa sem fins
 lucrativos, ido.org, em 2013 e começa a disseminar ainda mais o tal do design thinking através
 desse toolkit Human-Centered Design, que eles disponibilizam gratuitamente. Ele é voltado
 para empresas do terceiro setor, iniciativas de terceiro setor e governos, mas ele acaba sendo
 utilizado também para empresas lucrativas, porque ele está aberto, disponível, o PDF, quem quiser
 baixar, está convidado. Isso espalha esse pensamento projetual expansivo ainda mais do que já tinha
 sido feito através dos treinamentos. Isso também gera uma certa divergência nesse processo, porque
 eles têm o controle, digamos assim, da curadoria do que significa esse design thinking. E acabam surgindo
 outros modelos, outros métodos derivados, que reduzem esse pensamento projetual, que originalmente
 tinha uma proposta mais ampla, a seguir um método modelim. E quando você digita design thinking no
 Google, você vai ver trocentos mil modelos coloridos. O mais famoso desses modelos derivados do design
 thinking, do pensamento projetual expansivo, é o design sprint, criado por profissionais que
 trabalhavam no Google Ventures. Em 2016, o Jake Knapp publica esse livro, e esse design sprint se
 espalha que nem uma praga, mais ainda do que os workshops e oficinas do design thinking, que às
 vezes duravam dias, às vezes eles ficavam vários dias pensando o problema do projeto. No caso do
 design sprint, uma semana você faz tudo do design thinking, então você reduz o design thinking a uma
 semana, e aí tem o design sprint 2.0, que é dois dias, tem o 3.0, que é quatro horas, e você faz tudo.
 Eu não acho que haja problema nenhum em você ter métodos ágeis para trabalhar ideação, definição
 de problemas, o que eu acho que muitas vezes as pessoas têm impressão de que design thinking é
 mais, ou que pensamento projetual expansivo, pensando de maneira mais ampla, se resume a aplicar um método,
 e que se você aplicar esse método, você vai ser tão bom quanto um designer treinado que tem aquela
 vivência de atelier de anos e anos e anos aprendendo de maneira tácita. Não vai! Isso é o maior engodo
 que existe hoje no mercado, e que infelizmente não está sendo questionado pela academia. Eu acho que
 a gente precisa questionar e criticar essas fórmulas prontas vendidas através do design sprint e de
 outras variações, de que se pode resolver qualquer tipo de problema. Não é verdade. Muitas vezes o que
 vai acontecer é que você vai escolher o problema errado para o projeto, você vai resolver o problema,
 aquilo não vai gerar valor, e você vai manchar o nome desse design thinking, do pensamento projetual
 expansivo. Outro dia cheguei para o diretor de um grande banco no Brasil, falei "olha, eu trabalho
 com design thinking", ele falou "já testamos, isso não funciona para a inovação aqui dentro da nossa
 empresa". Que pena, né? Porque tem vários outros bancos em outros países que testaram e deu certo,
 mas eles tiveram mais paciência, eles foram além dessas fórmulas prontas. Eles falaram com quem era
 autoridade no assunto, quem estava pesquisando e vivenciando aquele assunto há muito tempo. Então,
 o que acontece? Pensamento projetual expansivo vai além do método, porque ele tem um aspecto
 muito bem-vindo que é o fazer, que a gente não pode esquecer, que eu falei desde o começo, que é a marca
 registrada. Você pensa fazendo. E aqui está um exemplo de um laboratório dentro da ID.O, que eles
 estão desmontando um brinquedo interativo, o Furby, para ver como ele funciona, hackear ele e criar
 outras coisas a partir do Furby. E não tem um propósito específico, é apenas para entender melhor
 o que dá para fazer com um brinquedo interativo, que outros brinquedos podem surgir a partir dele.
 Então, não segue necessariamente um caminho abstrato, um método pré-definido. O pensamento
 projetual também explora o que é concreto e o concreto surge do nosso corpo. Para você criar,
 a partir desse fazer concreto, a gente precisa aceitar o nosso corpo, se movimentar, ter posturas
 diferentes, trabalhar com diferentes ritmos. Por isso que dentro da D.School, na Stanford,
 e também lá em Pouls D'Han, existem vários treinamentos de teatro, treinamentos de postura
 corporal, treinamentos para se soltar, música, dança, como ferramentas fundamentais para se
 encontrar com esse lado concreto do fazer. Esse fazer, lembrando, não é só um fazer individual,
 é um fazer junto. E quando a gente faz junto, a gente faz coisas que nenhum de nós estava imaginando
 possível, nem que a gente imaginasse que a gente quisesse aquilo, como sair andando uma bicicleta
 pelo laboratório. Essa liberdade que existe dentro dos laboratórios, dos espaços de projeto orientados
 ao pensamento projetual expansivo, é fundamental para ter ideias inovadoras. E além disso, é
 necessário ter muitos materiais de diferentes variedades à mão para a gente criar e materializar
 as coisas rapidamente. Então não é só utilizar post-it, muitas vezes as pessoas não sabem que
 dentro do design thinking também se utilizam materiais de colagem, materiais de costura,
 materiais diversos que estão disponíveis na sua papelaria mais próxima, no armário, e que você
 pode construir com isso um espaço bastante estimulante à criatividade. Agora, se não houver o pensar
 junto com o fazer, eu não estou descartando o pensar, os materiais vão ficar parados lá,
 e ninguém vai ter ideia de usar esses materiais de maneira útil para o projeto. Qual que é maneira
 útil? Fazer junto para antecipar as tais das contradições entre os diferentes pensamentos
 envolvidos dentro de um projeto. Então se faz útil não porque é mais rápido, não porque é mais
 divertido, mas a principal razão é antecipar as contradições inerentes ao projeto que estão
 envolvidas, que vão incomodar mais lá para frente e que se a gente antecipar agora a gente consegue
 se preparar melhor para essas contradições. Porém, a gente não vai conseguir fazer isso se a gente
 sistematizar a nossa representação do espaço projetual antes de abrir ou antes de ter uma
 convergência, né? Antes de ter uma convergência tem que ter uma divergência. E por isso que muitas
 vezes dentro da Ingenier do Software alguns autores que não têm essa vivência de ateliê de projetos
 tentam explicar e reduzir, simplificar o design thinking em modelos como esse que vocês estão
 vendo nesse slide, né? Reduzir o pensamento projetual expansivo ao sistemático como se fosse só você
 colocar dentro de uma caixinha, executar cada uma dessas caixinhas e no final você tem uma inovação.
 Não funciona. Isso aqui não é uma experiência real, pode ser uma ideia abstrata interessante, mas
 no sistema sistemático o que gera inovação que tem a ver com a mudança das contradições é uma
 mistura desse pensamento projetual expansivo com um momento suficiente para você refletir, para você
 fazer e refazer, mas também lidar com a contradição. E depois, aí sim, depois que você trouxe a baila as
 contradições, resolveu elas da medida que possível, aí o pensamento projetual sistemático é muito
 importante para aumentar a escala, mas antes de você aumentar a escala do projeto e aumentar o
 ritmo, você precisa ter certeza de que você está construindo aquilo que vale a pena ser construído.
 Fred Brooks diz o maior desafio da engenharia do software não é você saber o como fazer, mas saber
 o que construir e é justamente isso que o pensamento projetual expansivo tenta apoiar a
 engenharia do software. Então, resumindo, pensamento projetual expansivo, na minha visão, é pensar e
 fazer junto com pessoas diferentes, mesmo que isso implique novas contradições dentro do projeto.
 Existem várias estratégias para pensar e fazer junto com contradições, formar times multidisciplinares,
 construir objetos interdisciplinares, estabelecer espaços antidisciplinares, educar profissionais
 transdisciplinares. Veja, cada uma desses termos significa uma coisa diferente, que eu não vou
 entrar em detalhes aqui porque vai distanciar um pouco do meu foco da apresentação, mas a disciplina
 precisa ser questionada, porque a verdade do pensamento projetual expansivo não está dentro
 de uma disciplina ou de outra, mas justamente nos espaços que ainda não foram ocupados pelas
 disciplinas, onde estão os lobisomes, e lá não tem disciplina. Por isso que é importante pular
 entre uma disciplina e outra, às vezes até deixar para trás as disciplinas para poder expandir além
 do espaço projetual conhecido, pensar fora da caixa. Pessoas de fora da organização e que não
 tenham nem mesmo uma disciplina acadêmica ou profissional podem ser fundamentais nesse momento.
 A própria ID.O. diz que nós temos o grupo desfocal, a gente convida as pessoas mais malucas
 da sociedade para participar dos nossos projetos, de modo que elas tragam perspectivas inimagináveis.
 Enfim, queria fazer mais uma pausa então aqui para a gente acolher perguntas. Ok, então agora nessa
 última parte da minha apresentação eu vou apresentar alguns exemplos práticos da minha
 pesquisa engajada. Lembrando que a minha pesquisa acadêmica também é calcada no
 projeto expansivo, não é só uma prática útil para o mercado de trabalho, para a indústria,
 mas também é útil para pesquisa acadêmica. Eu não vou entrar nos detalhes da epistemologia do
 design que justifica e que permite que eu faça pesquisa usando experimentos, usando análise de
 dados qualitativa, porque isso foge um pouco o escopo do tutorial. Mas eu vou deixar os links
 nas publicações que detalham como essa pesquisa foi desenvolvida, que vai ter obviamente um nível
 de aprofundamento muito maior do que eu conseguiria passar aqui. A minha primeira experiência,
 tentando juntar desenvolvimento de software com o design, com esse pensamento projetual expansivo,
 de maneira organizacional, institucionalizada, foi com o Instituto Faber-Lundens, uma entidade
 de indústria, de indústria, que é uma entidade de indústria, que é uma entidade de indústria,
 que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma entidade de indústria, que é uma entidade de indústria, que é uma entidade de
 indústria, que é uma parte dessa página. Na época, a tecnologia de customização de páginas para cada
 usuário não era tão disponível, então não existia essa possibilidade. Tinha que ter um modelo só
 para todo mundo, mas a gente queria chegar no modelo médio. Então a gente perguntou para 140
 pessoas que responderam essa pesquisa como que ficaria melhor o arranjo dessa página inicial.
 Projeto bem bacana, pioneiro que ajudou a mudar minha maneira de ver as relações possíveis de
 diversão entre engenheira de software e design, a tal ponto que a gente em 2011 lançou uma plataforma
 chamada Corais, dentro do Instituto Faber Ludens também, que tinha várias ferramentas de software
 livre customizadas para apoiar o pensamento projetual expansivo. E aconteceu um processo muito
 curioso que vários grupos ao redor do Brasil que estavam ligados com o ativismo político, com
 a sensação cultural, com valorização de culturas ancestrais, com o contato entre o rural e urbano,
 agroecologia, pessoas que estavam à margem basicamente dos sistemas tradicionais como o do
 Google e não queriam se render ao software proprietário e ficar presos, buscaram dentro da
 plataforma Corais uma maneira de se libertar, mas aí elas tiveram contato com uma base de conhecimento
 sobre design que estava dentro dessa plataforma Corais, que ainda está lá, e começaram a misturar
 conhecimentos de movimentos sociais de ativismo político com design. Isso gerou inovações muito
 interessantes, como por exemplo um banco de economia solidária com a própria moeda digital,
 lá nos anos 2013, quando ainda nem se falava tanto de blockchain, já tinha essa inovação.
 Mais um outro projeto que saiu da plataforma Corais também foi o XCards, que é um baralho,
 um card game para jogar com diferentes stakeholders de um projeto que quer priorizar a experiência do
 usuário, cada carta é um método tipo entrevista, bodystorming, pesquisa etnográfica, teste de
 usabilidade e a grande questão para quem planeja um projeto desses é quando fazer esse método,
 qual o resultado, como encaixar um método com outro, ao invés de a gente promover um método
 fechado, a gente promoveu um framework que vários métodos podem ser encaixados, que é a ideia desse
 jogo, então esse jogo não tem uma maneira simples de fazer um projeto de experiências, ele tem N
 maneiras e o jogo tem papéis do tipo gestor de projetos que vai apontar os riscos, os recursos,
 tem o cliente que aponta as necessidades dele e tudo mais, então também existe um incentivo na
 própria mecânica do produto, que é esse card game, de estimular as pessoas a se confrontarem e
 vivenciarem aquelas contradições que são fundamentais para o projeto. Mais tarde, quando eu fiquei
 um período fazendo doutorado na Holanda, trabalhei com coisas muito distantes da engenharia de software
 e arquitetura de hospitais, voltei ao Brasil como professor da PUC do Paraná e comecei como professor
 Rodrigo Gonzato, que é da Escola de Belas Artes, a colaborar em várias pesquisas muito interessantes
 de expandir outras ferramentas para vivenciar essas contradições dentro do projeto de software ou
 projeto de tecnologia digital de modo geral, como parte das atividades nossas pedagógicas do curso
 de design digital da PUC, que existia naquela época. Hoje é um curso de design unificado que também
 tem uma linha, uma trilha de especialização na área digital. A gente usou o teatro do oprimido,
 que é uma técnica que vem da complicação que eu estava falando, de você usar o teatro como uma
 maneira de analisar uma situação social e identificar uma opressão, como por exemplo,
 a vigilância generalizada que a gente vive hoje em dia através das tecnologias da informação e
 da software, que muitas vezes não é questionada, mas que quando é questionada geram leis como a GDP,
 aquela lei nova da União Europeia, que tem influência muito grande dentro da engenharia do software,
 mas que dentro da engenharia do software já poderia ter sido adiantada essas contradições
 com esse tipo de atividade como o teatro do oprimido que a gente utilizava em sala de aula.
 Essa dinâmica também é muito boa para envolver o corpo inteiro e o fazer junto,
 porque o teatro não se faz com uma pessoa só, apesar de que existe um monólogo, a gente não
 trabalha com esse gênero, a gente trabalha com teatro de improviso, um teatro que não tem script,
 um teatro que vai improvisando novas ideias, por exemplo, você quer criar uma nova tecnologia no
 teatro do oprimido, uma pessoa vem e ela faz o papel de câmera de vigilância. Então você vê ali
 essa mãozinha aqui, eu sou uma câmera e eu vou processar a sua face, eu vou identificar que você
 é uma pessoa branca, negra, mulher, homem e eu vou usar isso para mandar anúncios para você
 customizados. Veja, já estou prototipando uma tecnologia que pode ter implicações éticas,
 morais, drásticas, questões fundamentais hoje, grandes desafios do Vale do Silício,
 que está sendo tratado de uma maneira muito abstrata, muito no pensar, quando existe também
 um fazer, a ética também se faz nas nossas interações, no nosso dia a dia, na nossa prática
 e principalmente na nossa atitude, é na atitude que se mostra a ética, porque o discurso pode ser lindo,
 mas se não tiver a atitude junto com o discurso, que é uma coisa, a atitude se faz, vira um discurso
 e essas questões hoje estão no centro da discussão do Vale do Silício, eu não vou entrar em muitos
 detalhes. Outra maneira também de pegar, de fazer interações e experiências de uma maneira mais
 corporal e em conjunto, é vídeos improvisados, criados com o celular, com o smartphone, você
 rapidamente ali cria uma interação improvisada com papel, caneta, expandindo a capacidade da
 conversação de papel, porque o vídeo você pode acrescentar fala, ter interface de fala, você pode
 ter sons, você pode ter transições, criando uma ilusão de que aquele protótipo já é funcional.
 E mais ainda, você tem as histórias que você pode contar com bonequinhos, teatro de bonecos ou
 blocos de montar, usando o que tradicionalmente dentro de interação no computador, é conhecido
 como "scenario-based design", design através de cenários é possível ser feito com vídeos improvisados
 e Lego, contando uma história completa que deixa o contexto de uso, os requisitos não funcionais do
 projeto muito explícitos. Por que as pessoas vão usar aquele aplicativo? Nesse caso é uma história
 de um aplicativo que vai guardar imagens de museus, para se por acaso o museu queimar por conta de
 alguma coisa errada que foi feita na administração pública, essa pessoa que tirou as fotos do museu
 possa vender as fotos do acervo e ganhar dinheiro com isso. Uma ideia neoliberal, uma solução para um
 problema que é estatal, mas de novo, o vídeo improvisado permitindo visualizar toda essa
 complexidade do contexto político e cultural num vídeo de aproximadamente um minuto.
 Além disso, temos muitas colaborações interessantíssimas lá com o grupo, depois de eu ter essas
 experiências com o professor Rodrigo Gonzardo na Escola de Belas Artes da PUC do Paraná, aí tive
 experiência muito legal de conhecer a Xelha e a Andréia do PPG, da PUC do Paraná também, e elas
 me apresentaram a Apple Developer Academy junto com o professor Fabio Binder também, que é super
 interessante as ideias que ele tem de como integrar a engenharia de software com o pensamento
 projetal expansivo, e nesse bojo dessas colaborações apareceu a Tânia Maradors como uma estudante de
 mestrado interessada nesse assunto e interessada em sair fora da caixa da engenharia de software e
 trazer um método da antropologia para estudar essa colaboração. Ela ficou vários meses trabalhando e
 convivendo com os estudantes desse ateliê de software que é fundamentado naquela ideia do
 pensamento projetal reflexivo e ela estudou e pesquisou de maneira qualitativa como que
 se dava essas interações e como elas contribuíam para a formação desses futuros profissionais.
 O Elias Harmutneto, outro estudante de mestrado também, ele pesquisou outra coisa nesse mesmo
 que é o caso específico dos "deviners" que são conhecidos mais popularmente como unicórnios,
 são designers que podem codar ou programadores, desenvolvedores que também sabem projetar
 interfaces gráficas e ele entrevistou esses "deviners", ouviu as histórias deles, identificou
 características similares, né, que eles eram curiosos, autodidatas, criativos, comunicadores,
 isso era importantíssimo para esse papel mediador que eles tinham dentro das equipes em que eles
 atuavam porque eles tanto entendiam a linguagem do desenvolvedor quanto a linguagem dos designers,
 ele chamou isso de um profissional transdisciplinar na testa, na dissertação de mestrado dele.
 Tem um outro estudo que ainda não está publicado sobre codificação criativa também nesse
 atelier que é a programação orientada à expressão artística, expressão de sentimentos, que é um
 desafio que todo ano a Apple faz para os estudantes lá dentro, né, que gera vários, gerou vários
 reconhecimentos e bolsas internacionais dos estudantes desse atelier para apresentar o trabalho lá no
 Vale do Silício. Temos também sessões de crítica pública de software, que é algo que não é muito
 simples, dentro da engenharia de software você abrir o software e criticar ele como um objeto também de
 arte, né, como se fosse um objeto que você pudesse criticar por perspectiva subjetiva e diferentes
 perspectivas subjetivas se confrontando, né, permite capturar esse aspecto da experiência do
 usuário que é tão abstrato para quem não trabalha nessa área, né, que muitas vezes é fundamental para
 ter um sucesso no mercado tão competitivo quanto o mercado das apps, né, que os estudantes estavam
 estudando os seus projetos. Outra questão também muito bacana que surgiu lá é a prototipação de jogos
 com lego, daí o lego permitindo você materializar mecânicas antes de escrevê-las em código ou mesmo
 em diagramas, dá para você testar essa mecânica usando peças de lego, que tem uma estrutura
 semi-formal. A gente levou essa estrutura semi-formal ao nível de uma linguagem, até um sistema de
 informação que a gente carinhosamente chamou de lego ml, em alusão a um ml, né, e o lego ml serve
 para pensar as interações que as pessoas vão ter com o software ao mesmo tempo que se pensam as
 abstrações necessárias para reunir os dados, para pensar os fluxos de informação, pensar as
 metáforas e as estruturas básicas daquele aplicativo. É um apoio à arquitetura de softwares
 participativa, uma ferramenta fantástica que foi criada aí dentro da Apple Developer Academy,
 depois aplicada num projeto em colaboração do PPG com a Copel. Também outra coisa interessantíssima
 é a prototipação com materiais digitais ao mesmo tempo que analógicos, né, esse é um jogo que foi
 prototipado com papel e caneta, como se recomenda já na literatura de interação no computador,
 e também protótipos digitais aumentando a experiência de interação que vai ser futuramente
 utilizada pelo usuário. Por fim, o estudo que a gente tem feito também sobre toolkits, né,
 essas, esses baralhos com várias ideias diferentes que podem ser aplicadas em qualquer tipo de
 projeto, nesse caso os estudantes estão usando um baralho dos valores humanos e pensando como é que
 o aplicativo vai gerar esse tipo de valor na sociedade. Agora com a pandemia estamos estudando
 aqui na UTF-PR também como utilizar materiais digitais no co-design, a Larissa Pascoalim está
 estudando como que esses materiais permitem perceber o tempo, a temporalidade de maneira
 diferente, assim como a espacialidade do projeto de maneira diferente. Recentemente a gente fez
 um experimento com teatro do oprimido online com figurinos de realidade aumentada, então eu sou
 o Pelégo Designer aí do lado direito com cara de lumpa-lumpa, a gente estava discutindo a
 precarização do trabalho nas plataformas digitais e como os estudantes e os futuros designers eram
 responsáveis por essa precarização do trabalho, por exemplo, dos entregadores de delivery, né,
 eles estão extremamente precarizados porque os designers de experiência dos usuários só se
 preocupam com a experiência do consumidor final e não a experiência do trabalhador e esse entregador
 é um trabalhador também, às vezes ele nem é visto dessa maneira, então nesse teatro a gente
 inverteu os papéis e resolveu precarizar o trabalho do design numa plataforma digital que facilitaria
 um cliente pedir encomendar um logo em uma identidade visual para ele por uma inteligência
 artificial e essa inteligência artificial é representado por um personagem neutro que tá aí
 no meio, né, que fazia mediação com os lumpa designers, que são esses dois que estão aparecendo
 aí, que não eram verdadeiras inteligências artificiais, eram pessoas, a inteligência
 artificial ela fingia que era um processo automático quando na verdade eram pessoas que estavam fazendo a
 inteligência artificial funcionar. Uma crítica que a gente faz através do teatro para vários
 processos de automação como Amazon Mechanical Turk que parecem inteligência artificial e não são,
 são pessoas que muitas vezes têm um trabalho bastante precarizado, sem nenhuma segurança no
 trabalho, sem nenhuma garantia de que elas vão estar bem de saúde numa situação como a pandemia e por aí vai.
 E por fim o meu estudo já está durando vários anos que tem a ver com o meu pós-doc lá na
 engenharia de software com a Sheila e com a André, que é identificar as contradições históricas que
 estão acontecendo no CERN da engenharia de software, que já levantei algumas, né, como por exemplo se
 você divide o trabalho da engenharia de software quanto mais você divide menos integridade
 conceitual você tem, essa contradição muito, você quer um software bem feito tem que ter uma equipe
 pequena, poucos papéis, mas quer um software grande, complexo, você vai ter que dividir o trabalho.
 E como é que você mantém essa integridade conceitual muito difícil é uma contradição.
 Gente, essas são as referências bibliográficas, depois vou passar os slides para quem quiser
 consultar elas. Muito obrigado até aqui e vamos abrir para mais um round de perguntas se tiver,
 se não a gente finaliza. Obrigado!
 [silêncio]