Vamos passar para a segunda parte da nossa oficina tentativa de aproximar pensamento projetual com o desenvolvimento de software. O lado mais teórico, mais filosófico, visando com isso gerar pontes e colaborações interdisciplinares entre o design thinking e a engenharia de software. Primeiro ponto que eu acho que vai ajudar muito nessa relação é a gente traduzir para o português design thinking como pensamento projetual. Então essa imagem aqui é bem legal que mostra que muitas vezes o design thinking é vendido como se fosse uma mágica, uma maneira incrível de você inovar, mas quando você tenta fazer na prática sozinho sem o instrutor que vai organizar a situação, você se vê numa situação parecida com esse meu ex-aluno aí. Então não tem mágica, na verdade. Design thinking não é um método mágico vindo do exterior. É uma coisa que já existe, inclusive, já existe dentro da engenharia de software. Então a gente pode fazer uma analogia. Assim como existe o pensamento jurídico no direito, existe o pensamento projetual no design. Então assim como existem o pensamento jurídico grego, romano, moderno, contemporâneo no direito, também existem vários tipos de pensamentos projetuais no design. E a palavra design aqui inclui a engenharia de software, porque você pode entender design como sendo design gráfico, design de produto, de uma maneira mais restrita, e é o que infelizmente acontece nos estudos acadêmicos no Brasil, mas você pode entender a palavra design como sendo projeto de maneira mais ampla como é na comunidade internacional. Se falar design na comunidade internacional não significa o design que é feito pelos designers aqui dessa escola de arquitetura e design, incluindo e principalmente também as engenharias e as artes, muitas vezes também. Então se a gente utiliza a tradução pensamento projetual é legal porque a gente consegue recuperar esse sentido mais amplo e perceber que já existem vários pensamentos projetuais nas disciplinas que pensam e desenvolvem projetos com frequência. Na arte o pensamento sobre o projeto nos leva a perceber a questão da obra, que é aquela coisa incrível que surge a partir de um projeto. Na arquitetura o projeto é uma forma, uma maneira de você intervir no mundo de maneira física, concreta e que também tem um significado. Na engenharia projeto é um método, é uma maneira de estruturar, um procedimento para você chegar num resultado. Para o desenho industrial, projeto é um processo de trabalho, não necessariamente um método, é o que realmente acontece, é o projeto, que muitas vezes não se segue em métodos, mas ainda assim você tem um processo. Para a educação, projeto é algo motivador, que vai fazer os estudantes trabalharem em conjunto para resolver, fazer alguma coisa, colocar no mundo. Para a computação, problema é o cerne de projeto e o projeto vai gerar um algoritmo para solucionar esse projeto de maneira computacional, de maneira automatizada. Na administração, finalmente, projeto é um recurso que tem que ser gerenciado ou uma série de recursos. Isso aqui é só uma visão ampla de diferentes maneiras de perceber projetos e agora eu vou dar uma perspectiva mais histórica. Onde começou essa discussão? Qual é a primeira disciplina a discutir e pensar projetos? A arte. A arte tem milhares de anos e a gente pode ver que a arte já vem desenvolvendo projetos desde esses tempos praticamente memoriais, difícil de você precisar quando surgiu o primeiro projeto artístico. Aqui nós temos uma representação de uma deusa, numa época, numa sociedade que ainda era matriarcal, 25 mil anos atrás, que as mulheres eram endeusadas porque não se entendia como que ela dava luz a um outro ser humano. E por isso ela tinha um poder especial que ninguém mais tinha. Por isso tinha esse projeto, então já está dando significado para uma relação social. Isso há 25 mil anos. Mais recentemente, já numa era cristã, ou próxima da era cristã, você tem um primeiro escrito, o primeiro livro sobre pensamento projetual, escrito pelo Vitruvius. É um clássico da arquitetura, é o fundador da arquitetura, mas não só da arquitetura, todas as disciplinas de projeto eventualmente citam esse trabalho onde é definido os principais características de um projeto bem feito. Nessa época ele vai utilizar a arquitetura grega como exemplo, mas o pensamento projetual do Vitruvius, ele se aplica a qualquer outro tipo de projeto, não necessariamente somente para arquitetura grega e rumana. Já a partir da revolução industrial, você tem o surgimento e consolidação da engenharia que está operacionalizando esse pensamento projetual para transformar ciência em tecnologia. Então a engenharia se preocupa com projetos de tecnologias aplicadas em contextos específicos. Ela às vezes é uma ciência aplicada, às vezes ela dialoga com a produção de ciência, mas muitas vezes ela está lá no final do processo aplicando apenas um conhecimento que foi gerado por cientistas. Aqui tem um exemplo de projeto de engenharia mecânica do primeiro motor a vapor que permitiu uma grande mudança nas rotinas de produção na Inglaterra e depois no resto do mundo. E o desenho industrial trouxe essa lógica de trazer tecnologia para o cotidiano. Se a tecnologia anteriormente, quando a engenharia começa a trabalhar, faz a ponte entre ciência e tecnologia, o desenho industrial vai fazer a ponte entre tecnologia e cotidiano, trazendo essas inovações que existiam de aplicação de conhecimento científico para o dia a dia da maneira mais banalizada possível. Então um telefone pode parecer uma coisa hoje antiquada, mas naquela época era ponta de linha da tecnologia, era uma coisa praticamente de outro mundo, um telefone físico. Mas ele também tinha desafios de como usar, como entender um telefone, que hoje a gente acha trivial, mas nem tanto. Para quem não nasceu nessa época você tinha que botar o dedinho aqui e girar até o final e daí soltar. Isso que é o que uma maioria das pessoas, crianças, você der para uma criança um telefone desses, ela pode até girar isso aqui, mas ela não vai saber que ela tem que soltar para discar o número. Então foi feito desse jeito, desse jeito que ainda dá para fazer isso, porque tinham alguns anteriores, uns telefones que eram mais difíceis do que esse, que é o do disco. Esse é um projeto bem interessante que não envolve somente a questão do daion, mas envolve também toda a ergonomia da pega para caber na mão de vários tipos de pessoas. Tem a questão estética também, icônica. Esse projeto é tão forte do Dreyfus, Henry Dreyfus, que até hoje a gente identifica telefone pelo formato desse fone. A gente abre o smartphone e clica em "telefonar" e o ícone, o shape, a silhueta desse modelo ainda está presente. Então vejam como é potente a forma enquanto um significado também. A educação, ela estudou como que os estudantes de design, arquitetura aprendiam nas artes também a partir de projetos e resolveu trazer isso para outras áreas com dois conceitos aí que são hoje muito fortes ligamente ligados à ideia de metodologias ativas, que é aprendizagem baseada em problemas e aprendizagem baseada em projetos, ou também mais conhecido como pedagogia de projetos. Essas duas ideias foram fundamentadas principalmente pelo Diyuin, que foi visitar essas escolas de arquitetura e design, se inspirou e resolveu escrever a respeito dessa maneira como se aprendiam nessas oficinas e como se poderia aprender também em outros contextos que não fosse só educação de disciplina de projeto, mas que todas as disciplinas pudessem desenvolver projetos. E por último a computação, que vai aproveitar esse pensamento projetal para criar novos mundos aqui, abrindo horizontes mais amplos até do que a educação abriu. Aqui nós temos um exemplo do mainframe system 360, que foi um dos grandes projetos da computação na primeira metade do século 20, que marcou praticamente o berço da engenharia de software. Quem fala muito sobre esse projeto é o Fred Brooks, que foi o gestor desse projeto. Teve vários atrasos, várias dificuldades no projeto que geraram as primeiras reflexões da necessidade de transformar o trabalho de computação numa engenharia de produção, que acaba se tornando conhecida mais como engenharia de software. E aí ele fala das dificuldades de organizar esse tipo de projeto e também de você criar mundos virtuais onde as pessoas pudessem interagir. Na verdade isso é algo que ele vai discutir mais num livro posterior, que é esse aqui, o projeto projeto, que eu vou falar um pouquinho mais daqui a pouco também. No fim a administração que já existia com uma disciplina separada desde o começo do século 20, ela acaba se apropriando da computação e com isso criando e sistematizando uma área chamada gestão de projetos, que tem uma noção muito forte de utilizar a computação para gerir recursos de maneira racional, distribuindo esses recursos de maneira que o projeto atinja minimamente os seus objetivos. Então todas essas diferentes disciplinas têm pensamentos projetuais muito diferentes, mas com algumas coisas em comum. Por isso que o Herbert Simon vai se perguntar lá no final dos anos 60, será que a gente pode considerar esses diferentes pensamentos como uma nova ciência? Uma ciência do artificial? Então ele vai escrever esse livro aqui, que é um livro fundamental para entender a história da computação e a história do design numa época que ainda era uma coisa só. Nessa época o Herbert Simon era oficialmente da engenharia elétrica, mas ele atuava num campo que chamava inteligência artificial, que na época era multidisciplinar, não era só a computação que contribuía para a inteligência artificial. Tinha muitos pesquisadores na psicologia, pesquisadores no design, pesquisando esse assunto e ele escreve com uma perspectiva bem abrangente, visando que já que existem ciências naturais que estudam fenômenos da natureza, porque não existia uma ciência artificial que estuda os fenômenos artificiais criados pelo ser humano. E aí você consegue valorizar as disciplinas de projeto, engenharia, arquitetura, design, design industrial e essas outras que eu mostrei aqui, dentro da academia, porque na época elas não eram como são hoje tão valorizadas. As disciplinas de ciências tradicionais tinham muito mais recursos para as suas pesquisas. É uma coisa que mudou em partes também por causa do trabalho do Herbert Simon, de valorizar as escolas técnicas, as universidades como o Massachusetts Institute of Technology, MIT, onde o Herbert Simon estava localizado. Só que depois da publicação desse livro, muita gente discutiu o assunto, se formou realmente uma espécie de ciência do design. Vários pesquisadores agregaram nessa área, pesquisadores de várias áreas, não eram pesquisadores da área de desenho industrial, como às vezes a gente imagina, a ciência do design é ciência da design industrial, não, era multidisciplinar, tinha gente de todas as áreas praticamente. Mas aí uma área que chama bastante a atenção é na área do urbanismo. Hitel e Weber escrevem um artigo criticando diretamente a ideia de ciência do design, não porque não possa existir uma ciência do design, mas que ela não é aplicável à prática, ou seja, o que os projetistas fazem na prática não é uma ciência. Eles não resolvem problemas da maneira científica como o Herbert Simon estava propondo nesse livro aqui. Ele propõe até inclusive a criação de um software de gestão de problemas genéricos, que pode ser aplicado a qualquer tipo de problema através da inteligência artificial. O Hitel e Weber tentam fazer isso e não consegue, não dá certo nos projetos urbanos, porque são projetos extremamente complexos que envolvem muitas pessoas diferentes, muitos aspectos diferentes e eles dizem, existem certos problemas que são problemas mansos, existem problemas que são problemas capciosos. Esses problemas capciosos, eles são muito comuns na prática de projeto e infelizmente não é possível resolvê-los como se resolve um problema científico bem estruturado. Depois disso, começa a se refletir então, não é bem uma ciência, então talvez seja mais uma disciplina, uma disciplina interdisciplinar de pesquisa em design, que vai dar origem a um conceito de design studies, em português estudo de design. Então Archer vai escrever um artigo que vai ser o artigo fundador dessa revista, esse periódico que é o Design Studies, que hoje é o periódico de maior impacto nesse estudo interdisciplinar do design. Esses caras todos que eu vou apresentar aqui nos próximos artigos, todos publicaram um ou outro artigo nesse periódico, eu publiquei também, então estou na história dos estudos de design e eu acho muito interessante essa ideia de você ter um espaço interdisciplinar para discutir design e muitas vezes as pessoas não entendem isso, acho que quando a gente fala design está discutindo só desenho industrial, mas não, a gente está discutindo arquitetura, engenharia e outras instâncias de projeto em outras áreas. E aí o Nigel Cross vai junto concordar com o Bruce Archer de que existe uma disciplina que não é nenhuma ciência, nenhuma arte, que é uma disciplina que estuda design e ela estuda de um jeito diferente que as outras disciplinas, existe um modo projetual de conhecer. Então esse design wave of knowing se torna um paradigma para a pesquisa do design que até hoje ainda não foi questionado, ainda se aceita que existe uma maneira de conhecer o mundo que é projetual, é uma maneira que envolve principalmente você construir coisas no mundo e ao você construir você está gerando conhecimento, da mesma maneira como você gera conhecimento quando você faz um experimento dentro de laboratório, da mesma maneira quando você gera conhecimento quando você escreve um artigo teórico, por exemplo. Então ele fala, na hora que você cria um protótipo, esse protótipo já traz um conhecimento sobre o mundo. Então existe também um tipo de conhecimento, um conhecimento projetual que deve ser valorizado pela disciplina que estuda o design dessa maneira ampla. E aí o Bruce Lawson, ele é um psicólogo cognitivista, mas também é um arquiteto e aí ele se pergunta, tá, então existe uma maneira específica de conhecimento de design, mas como que surge esse conhecimento e como ele é transformado pelo pensamento? E aí ele escreve esse livro aqui, Como os arquitetos e designers pensam, que é um livro fabuloso sobre processos cognitivos na área da arquitetura e do design. É um livro bem fácil de ler, pouco conhecido, talvez seja o livro mais detalhado hoje que tem em português sobre o que está se dizendo como design thinking. Ele explica como que os designers pensam, como os designers sabem. Inclusive nesse livro inclui também os projetistas de software. E aí o Donald Shawn, olha só. Meu Deus, olha só que incrível. Deixa eu dar um abraço aí. Uma salva de palmas para a Tânia aí. Meu Deus do céu, não podia ser mais sincronizado, né? Olha só, Tânia. Olha só, eu sou eu também. Olha, tira uma foto aí, tira uma foto. A minha filha, a Viada, é o autor definido da Tânia. Não é? Ela escreve só, ela tem que falar três vezes. Quatro vezes, em vez de uma introdução só, ela cita só o chão. A Tânia acabou de defender a dissertação de mestrado dela na segunda, e ela usou esse livro como uma das principais referências, que é o livro que pergunta o seguinte. Como que designers aprendem a pensar como designers? Se eles pensam de um jeito diferente, como é esse aprendizado? E como que pode ser melhorado esse aprendizado? E como que outras áreas que não são desenho industrial, por exemplo, ou arquitetura, podem também aprender a pensar como designer? Então esse livro também é um livro importantíssimo para o design thinking, porque ele coloca a questão do conhecimento tasto. Esse conhecimento que o designer tem não é um conhecimento explícito que você consegue, por ler um livro, apenas entender o design thinking. Você precisa participar de uma atividade de design thinking para você saber como é estar naquela situação. É um conhecimento que só se manifesta na situação específica. Isso é uma coisa que lá na Apple Developer Academy acontece muito e justifica porque que os estudantes têm que estar no problema para poder lidar com o problema. Não adianta você querer ensinar soluções genéricas para os problemas, porque quando você estiver numa situação vai ter aspectos específicos da prática que você tem que estar lá para você poder perceber e aprender isso. Então a Tânia apresentou, digamos assim, a citação de que explica a maneira como os estudantes da Apple Developer Academy por essa teoria da prática reflexiva, que eu vou falar mais um pouquinho daqui para frente. Então, esse pensamento projetual era um conhecimento tasto que só podia ser aprendido na vivência de ateliê de projetos. O que é um ateliê de projetos? É um lugar onde você tem instrutores ou mestres, que são pessoas que já estão projetando há muito tempo, que trazem no corpo, que trazem na sua experiência prática o seu conhecimento, que não consegue muitas vezes explicar. Se você pedir uma aula essa pessoa não vai conseguir, mas se você sentar do lado dela ela consegue te mostrar muito bem como você faz para resolver um problema da prática. Isso é algo que é muito comum lá na Apple Developer Academy, dos estudantes chegarem para o Vinicius, por exemplo, "Professor, eu estou com esse probleminha aqui bem específico, como é que você resolver esse problema?" Aí o Vinicius chega e fala "ó, dá para fazer desse jeito, desse outro jeito e desse outro jeito, tem essa vantagem, desvantagem", mas ele está dando uma instrução contextualizada, não é uma instrução genérica do tipo solução para todos os problemas de desenvolvimento. Existem momentos que isso acontece também, as aulas fundamentais, mas isso é a menor parte do tempo dos estudantes lá dentro, então por isso que a gente costuma estudar Apple Developer Academy como um caso de um ateliê de projetos, que funciona mais ou menos dessa maneira como funcionam os ateliés da área de arquitetura, de desenho industrial, que foram pioneiros nessa abordagem. Mas que também tem na engenharia, por exemplo, tem uma empresa chamada Arup, que é uma empresa de engenharia civil, que funciona toda baseada em ateliê de projetos, tem muitos arquitetos trabalhando lá, mas é uma empresa essencialmente de engenharia. A obra mais famosa deles é aquela ópera da Sydney, que tem todos aqueles arcos malucos lá, então não é uma exclusividade da arquitetura e do desenho industrial, porque também tem na engenharia civil. Então já mencionei que é um lugar onde você começava aprendendo no ateliê na universidade, na empresa que você ia trabalhar, elas também funcionavam por ateliê, você tinha os profissionais mais, os mestres, as pessoas que eram os mentores nas empresas que davam a dica de como fazer para os novatos, os estagiários. A partir dos anos 90 acontece uma ruptura nesse processo do ateliê de projetos, começam a entrar profissionais que não têm informação em disciplina de projeto, que não passaram nunca para o ateliê de projetos, essas pessoas começam a participar das equipes. Uma das empresas que é pioneira nisso é a IDO, eles escreveram dois livros bem importantes, o Tom Kelly, sobre faces da inovação e arte da inovação, que explicam porque eles contrataram antropólogos, psicólogos, teatrólogos, para trazer perspectivas diferentes para o projeto. E aí eles, sem uma intenção muito clara, recebem um programa de televisão chamado TV Nightline, no final dos anos 90, para mostrar como era o processo de trabalho multidisciplinar dentro da IDO. E aí esse programa bomba, ele mostra como que eles projetaram um carrinho de compras, que é esse que está aqui, o resultado final, de maneira multidisciplinar. O vídeo está no YouTube, quem quiser ver depois com calma, mais ou menos uns 10 minutos a reportagem, é incrível, porque todas essas experiências que você tiver agora há pouco usando o legacy display, eles mostram dentro de uma escala de um projeto real e fica muito convincente que essa multidisciplinaridade contribui para a melhoria do projeto, do produto final, porque tem várias perspectivas. Tem a perspectiva da comunidade, de você poder fazer o checkout de você mesmo, das perspectivas da questão da esforço, da tarefa, da ergonomia, de você não levantar muito peso porque você tira essas caixinhas e coloca para lá. Tem a questão da beleza também, de é um carrinho com uma forma mais futurista, que traz mais significados, e aí isso é resultado de um trabalho multidisciplinar. Então esse programa de televisão bomba, explode, numa época em que havia um desaquecimento da indústria nos Estados Unidos, essas empresas que trabalhavam com o design de produtos estavam começando a ir à falência porque não tinha mais cliente, a produção estava sendo levada para a China e outros países asiáticos, e ao mesmo tempo propagava-se uma ideologia neoliberal de que o Estado não precisava resolver os problemas que antigamente eram atribuídos ao Estado, que uma empresa poderia resolver esses problemas. O empreendedorismo social começa a surgir mais ou menos nessa mesma época. Então a ID.O. percebe isso como uma oportunidade de negócios, de ao invés de você vender um serviço de projeto de produto, que era o que eles tinham feito durante os anos 90 e 80, e ficado bastante famosos por isso, eles podiam vender o processo de trabalho deles para qualquer tipo de objeto, não mais um projeto industrial. E foi exatamente isso que as pessoas começaram a pedir ao verem o vídeo daquele programa de televisão. E aí o Tim Brown vai escrever esse livro que é traduzido e publicado no Brasil em 2010, o título original é Change by Design, eles traduziram como "I think" uma metodologia poderosa para decretar o fim das velhas ideias. E aí você vai ler o livro mesmo, você vai ver que o próprio autor fala que isso não é uma metodologia. Então o título está bem falacioso, deixa uma péssima tradução de título, mas de qualquer forma ajudou a disseminar o design thinking aqui no Brasil e no mundo. Mas depois eles vão explicar, vão transformar numa metodologia assim, se você quiser uma metodologia de design thinking é esse livro aqui, Human Centered Design Toolkit, mais ou menos, não me lembro se era 2012 ou 2013, a IDEO vai abrir uma empresa de terceiro setor chamada IDEO.org, é um spin-off para atender especificamente esses casos de projetos que visavam apenas o benefício da sociedade, não só o lucro de uma empresa. E aí eles fazem toolkits que disseminam o design thinking de um jeito incrível, muito mais forte do que o livro dele, que é esse lançado aqui no Brasil, vai ser esse kit porque ele é gratuito, ele é colocado na internet e ele é muito mais passo a passo, ele não tem tanto uma filosofia de projeto como tem o livro do Tim Brown, ele tem muito mais um faça isso, faça aquilo e muitas vezes as pessoas acham que isso aqui, que eu estou mostrando agora, é o design thinking, é tudo sobre design thinking, mas não é. Eu tinha mais algumas atividades planejadas para a gente interagir, mas acho que a gente acabou tomando muito tempo com as atividades de Lego, então não vale a gente fazer, mas fica aqui o registro de que existe uma maneira de fazer brainstorming no estilo IDO, inclusive você usa alguns materiais que eu trouxe aqui, que a pessoa ficou perguntando porque que você trouxe isso aqui. Se por acaso der tempo da gente fazer, a gente faz, mas eu vou pular porque demora um pouquinho de tempo para fazer esse brainstorming. Basicamente você vai utilizar vários recursos para o pensamento concreto ser aproveitado no processo criativo também e aí vestir roupas esquisitas faz a diferença no processo criativo. Bom, a maior parte do que a gente vê como design thinking hoje, visualmente, e que vai influenciar o layout dessa sala que a gente está aqui agora, olhe para os lados, veja como essa sala se parece com essa foto, de uma certa maneira. Então por quê? Porque alguns professores aqui da PUC foram na D.School, se não foram ouviram falar da D.School e se ouviram falar, viram fotos da D.School. Quando se fala design thinking, a primeira imagem que se vê é isso aqui, ou coisas parecidas com isso, são painéis quadros em branco, com um monte de post-it, com um monte de ideias necessariamente desorganizadas, não pode ser organizadinho, não segue um grid. Isso é uma característica do tipo de pensamento projetual cultivado pela D.School e não pela ID.O. A ID.O. tem um tipo de pensamento projetual, a D.School vai ter outro, embora a D.School tenha sido fundada por um professor que é da Stanford, mas que também é um fundador da ID.O. que é o David Kelly. Mas ela tem algumas diferenças, ele é mais simplificado o design thinking da D.School. A D.School foi fundada com um financiamento generoso da SAP, SAP, que é uma grande empresa aí da área de software, que eles participaram de uma oficina da ID.O., contrataram a ID.O. para uma consultoria, o Raso Platner, que era um dos diretores, ou se não ainda é, ele gostou tanto que ele falou "nós temos que espalhar isso para a empresa inteira" e aí perguntou para a ID.O. "como é que faz isso? A gente tem que abrir uma escola para formar essas pessoas", sugeriu um investimento na Stanford que podia receber esse dinheiro até com benefícios fiscais e tal, então 60 milhões foram investidos na fundação da D.School a partir da Raso Platner Institute, que é uma ONG fundada pelo Raso Platner, que depois vai levar esse modelo para a Alemanha, na Impulse Dan, então tem uma D.School também na Alemanha, pouco conhecida, mas muito mais acessível, barata e aberta do que a D.School do Stanford. Eles ofereciam até alguns anos atrás curso gratuito de design thinking durante quatro meses e eu conheci dois brasileiros que fizeram esse curso, voltaram para o Brasil, fundaram uma empresa chamada Design Echoes, que é uma das grandes responsáveis pela disseminação do design thinking no Brasil, do jeito que a gente conhece, esse estilo aqui que essa escola detecta aqui. Assim como eles, várias pessoas fizeram esse tipo de treinamento gratuito e espalharam pelo mundo design thinking, inclusive nesse lugar que a gente está aqui agora, nessa universidade, esse discurso de que design thinking é igual a inovação tem a ver com esse trabalho feito pela D.School e pela ID.O. Então no final das contas, o que aconteceu com o design thinking, ele virou uma abordagem genérica de inovação, fundamentada na cocriação multidisciplinar. Esse aqui é um trabalho que não é de ninguém da Stanford, nem da D.School, é do pessoal da Universidade de Delft, na Holanda, que olhando para essa transição do design histórica, tem um padrão de que existe uma atuação mais forte dos designers na época em que você não sabe exatamente o que você vai construir naquele projeto, que é o chamado fuzzy front-end. Você não sabe quais são os requisitos, você nem sabe qual o contexto, você nem sabe quem é o público, nem sabe quem é o cliente, você quer fazer alguma coisa, mas você não sabe o que. Então isso é o chamado fuzzy front-end. E essa é a parte mais importante de um projeto de software segundo o Fred Brooks. Então nesse livro ele vai falar, o desafio mais importante para o software não é como construir, mas o que construir, o que fazer, o que produzir, o que projetar. E é justamente no fuzzy front-end onde existe uma variação muito grande de ideias em que os designers vão contribuir com o tal do design thinking. Porém, depois que a Disco lançou um modelo de design thinking, aquele que eu mostrei lá no comecinho que era parecido com o Cascata, pipocaram diversos outros modelos derivados discutindo isso, discutindo aquilo, melhorando isso, melhorando aquilo ou, na minha opinião, piorando, jogando basicamente a grande vantagem do design thinking junto no lixo, porque a ideia do design thinking justamente era você, a sua organização, ter um pensamento projetual. E é isso que o livro do Tim Brau vai falar. Porém, as publicações posteriores, inclusive da própria Disco, já vão colocar uma série de passo a passo. Inclusive, é um modelo para vários cursos de design thinking, por exemplo, do Sebrae, os cursos de design thinking que tem aqui na universidade também são baseados nesse modelo da Disco, o que eu acho que é um desperdício, porque se você for pensar o que é pensamento projetual do jeito que eu estou tentando propor aqui, é muito mais abrangente. Então veja aqui, esse aqui é o fim da picada, que é o livro Design Sprint, não foi nem a Disco nem a ID. O que escreveu foi a Google, o Google Ventures, um grupo de pessoas que estavam aplicando, tentando reduzir e simplificar o design thinking, criou um método que você consegue em uma semana apenas resolver qualquer problema. Cada dia você faz uma coisa diferente, hoje em dia já existe o design sprint 2.0, tem o 3.0 também, cada vez vai reduzindo o tempo, se antes era uma semana, agora é 3 dias, daqui a pouco é 2 dias e tem agora o design sprint 5.0 que é 2 horas. Em 2 horas você resolve qualquer tipo de problema. Eu acho que isso é um reflexo de um fim, digamos assim, de uma decadência do design thinking enquanto uma ideia interessante para a inovação. Porque o grande desafio, segundo Tim Brown, lá na época que era o ápice da discussão, ele dizia "não é questão de uma pessoa pensar projetualmente, nem um projeto ser orientado pelo conhecimento projetual, mas da organização ter um pensamento, uma filosofia, uma abordagem de projeto". Isso significa que ela valoriza o projeto enquanto uma maneira de atuar, de estar no mundo. Então isso foi se perdendo até virar um método, uma receita de bolo, como design sprint, que dá a sensação de que qualquer pessoa pode pensar e resolver problemas tão bem quanto um designer. A palavra designer aqui não é o designer industrial, é o designer de qualquer área, basicamente um designer formado profissional que passou por um ateliê de projetos, por exemplo, nem que seja na faculdade ou no mercado de trabalho. Mas se você aplicar esse método aqui, não interessa se você tem essa experiência. Eu acho que isso é falacioso, é um dos problemas e motivo pelo qual eu estou fazendo essa crítica. Outro ponto importante é que desconsidera essa experiência corporificada, que vocês tiveram uma amostra grátis aqui no comecinho dessa oficina, que é você vivenciar aqueles tipos de pensamentos diferentes no contexto de um projeto. A longo prazo isso faz muita diferença e gera um tipo de conhecimento que é difícil de você transferir, como eu falei anteriormente, como o Shawn explicou, como a Tânia confirmou que isso existe na Apple Developer Academy. Então pensar que um método é tudo sobre design thinking, é reduzir demais. Então tem um livro que mostra que existem, na verdade, na literatura de design, quase cem métodos diferentes, é um livro chamado How Do You Design, livro muito bom, tem inclusive métodos de engenheiro de software lá dentro e compara os diferentes métodos. Mas o método é só uma parte de uma época que o pensamento projetual resolve se consolidar e muitas vezes também é na época que ele começa a entrar em decadência. Mais interessante do que aplicar o método é compreender o pensamento que gerou esse método, porque muitas vezes você vai ter que improvisar na prática um novo método ou um novo processo ou algo que nem é um método ainda porque você não tem tempo para pensar no método, mas ainda assim você pode ter e deve ter um pensamento coerente, algo que seja cultivado ao longo de vários projetos. É isso que eu estou falando quando eu penso em pensamento projetual. E agora a gente vai passar para uma terceira parte dessa piscina que é mais especulativa, mas antes de passar por isso eu queria perguntar se alguém tem alguma pergunta até aqui. Não? E aqui é o que é escrito que vocês são estudantes. A gente acha que era o item 2 quando você falou que quando a gente te entrega já o que a gente quer, a gente acaba tirando a criatividade das pessoas, colocando isso no movimento software, onde a gente às vezes defende documentação, defende documento de visão, defende o levador de revisitos, a gente já está entregando para o renovador algo que ele vai fazer para a funcionária acredita. Então isso está vindo meio que de encontro. Conflitante. Exato. Não tem uma proposta e ingerir software no requisito de software, requisito de funcionalidades, documentação é outra coisa. Ou seja, jogamos fora aquela parte do movimento de visão e vamos partir para isso para podermos entender o que a gente está fazendo. O que você está falando é um dilema. É um dilema que em cada projeto vai ser diferente a resposta. Tem projetos que você vai querer que o desenvolvedor seja criativo, como o projeto de um aplicativo, que precisa aparecer no mundo, que não existe ainda, ou tem projetos em que você está fazendo um sistema de segurança, de alta periculosidade, que você não vai querer que o desenvolvedor seja criativo. Depende de você entender qual é a abordagem de projeto, o seu pensamento projetal, eu vou falar agora de diferentes tipos de pensamento projetal, que é mais adequado. Vai ficar mais claro conforme eu for apresentando o resto. Quando você projeta, o projeto segura muita criatividade, de repente criação seria o nome correto. Especificamente para quê? Quando você projeta, você coloca passos, processos, métodos. É que você está pensando pelo ponto de vista da engenharia, lembra o que eu mostrei aqui? Para mim, projeto não é método, projeto é processo, processo não é método. Mas design think está morrendo porque o pessoal tem cara de ver essa forma. Isso, concordo. Como eu posso realmente esquecer o ponto da ideia de projeto, é só criação, o problema está aí. Sim, é com certeza. Projeto não se nome ao mundo de criação, não se nome ao processo bucatrático. A nossa palavra em português é uma só, para palavra design, para palavra project é a mesma coisa. Tem gente que traduz como modelagem. É, a gente fala design também. Na computação a gente não usa a palavra design, mas a gente evita traduzir. Quando a gente quer dizer design, a gente nem traduz mais. Se você for dar por que do Rio, você não usa design. É aí que é o negócio. É aí que eu entendi. Acho que é da Crípto. É design. Sim, a crítica em si, eu vi que você evitou falar sobre a crítica. Você tinha um slide que foi crítica, lá você evitou, pulou. Quando vem ideia, quando tem pessoas, quando tem essa interação, é natural o pensamento crítico. Que isso é até incentivado em alguns momentos, em alguns lugares. Esse pensamento crítico, esse elemento administrado, eu sempre entendi. E dificilmente eu não consigo não pensar que o pensamento crítico bem administrado é um pensamento que ele tem a contribuir. O problema do pensamento crítico muitas vezes é a cultura das pessoas que acabam influenciando que a crítica acaba sendo algo ruim. E daí ela acaba se minimizando. Então isso é meio clássico, ou até poderíamos abrir aqui uma discussão, mas não é o caso agora. Mas eu notei que você tirou essa parte da crítica, das ideias, para dizer mais ou menos assim, não critique, critique, ou qual é a tua posição sobre esse aspecto quando você está nesse momento de discussão. A gente estava discutindo isso outro dia na defesa da Tânia. A gente percebeu que uma das grandes coisas interessantes que o estudo etnográfico dela mostrou, é o importante e fundamental que a crítica tem dentro da Apple Developer Academy, e por outro lado a dificuldade que os estudantes têm de receber essas críticas, em especial da computação. Os estudantes de design estão mais acostumados a receber crítica. Na verdade existe uma cultura de crítica. A gente até tem um termo técnico para isso que vem da arquitetura que é sabatina, ou traduzindo, na verdade o original em inglês é design critique. É um momento específico e formal onde você mostra o projeto e o pessoal vai saraivar o teu projeto publicamente, ou às vezes só o professor que vai saraivar. E isso é visto como uma coisa bacana porque você não tem critérios bem definidos para avaliar o seu projeto. Então você não consegue avaliar o seu projeto com base numa checklist. Por quê? Seu projeto é uma criação de algo que não existe. Como é que você vai usar uma checklist para algo que não existe? Por exemplo, um novo aplicativo que nunca ninguém fez daquele tipo. Então, o que você pode ter como critério? O critério tem que ser criado. On the fly. Você precisa ter um feedback. Então não dá tempo para o professor fazer uma pesquisa para gerar o checklist. Ele tem que na hora te dar um feedback, criando critérios mais ou menos que fariam sentido para aquela situação, com base na experiência prévia dele. Então isso é basicamente uma das maiores dificuldades que o professor da Apple Developer Academy tem, porque ele tem que improvisar essa crítica, e também a dificuldade relacional, porque eu tive muitos problemas com os alunos lá. Porque eu fazia essas críticas que eu estava acostumado aqui do curso de design, e os alunos de design tudo bem, mas os alunos da computação ficavam muito chateados e iam lá reclamar com o Fábio. "Fábio, ele foi muito grosso, ele destruiu o nosso projeto e não soube a pé da profissão." "Aquele professor é muito grosso, Fábio." E no começo o Fábio também não entendia muito bem o que era essa tradição de crítica, porque também não é uma coisa normal esse jeito de criticar. Quando se critica na computação é uma crítica embasada em um critério pré-definido. Então você vai fazer uma crítica do tipo "olha, você não está seguindo o check list tal, você não está seguindo esse modelo, ou você não está seguindo essa norma técnica." Isso é uma crítica objetiva que você não pode questionar. Agora quando o professor vai fazer uma avaliação de uma coisa que não existe ainda, que não tem essas referências, vai parecer que a crítica dele vem de uma perspectiva subjetiva, ou seja, eu acho que está ruim. Mas não é "eu acho", na verdade com base da minha experiência, e muitos anos, por isso eu sou um mestre, por isso eu sou um instrutor, eu acho. Então é um achismo mais embasado, só que é difícil dizer de onde vem. É aí que vem a questão de uma certa contradição nessa crítica, que às vezes pode ser que seja embasada, às vezes pode ser que seja daquele momento que o professor falou aquilo. E aí a minha perspectiva é "não interessa, interessa o resultado". Se o aluno pegou aquela crítica, se a crítica é boa ou não, você vai avaliar pelo resultado dela. Se o aluno pegou aquilo, ficou em depressão, daqui a três dias ele voltou com uma ideia incrível, a crítica foi boa, mesmo que o professor falou foi besteira. Mas por outro lado, tem o aspecto relacional também, emocional, que eu acho que a gente tem que prestar mais atenção em outras situações, porque, enfim, a saúde mental também hoje está em voga e tudo mais, mas também a consciência de que eu como professor peguei pesado algumas vezes. Isso é uma aprendizagem também para mim, de ter mais tato, como fazer essa crítica de um jeito que o aluno não vai ficar travado completamente, vai odiar. Mas isso é uma questão temporal, contextual. Se essa crítica fosse feita há 20 anos atrás, ela teria menos impacto em mimisenta. Hoje em dia já, na cultura mimisenta, as pessoas têm que se trazer a isso. Porque eu vi que você evitou falar da crítica e eu vi que essas metodologias evitam esse embate. E é onde normalmente eu acabo criando o discrédito delas. E é onde o mimisenta entra... Mas você falou que tem coisas diferentes também, Antômer, porque uma coisa que se fala que não tira crítica é no momento da geração das ideias, porque elas estão nascendo e você não pode matar antes delas nascer. Ah, sim, sim. Isso, sim. Isso acho que é o momento de não crítica. Mas o que o Fred fala é mais adiante, quando você já está consolidando o que você quer, e aí você tem essa crítica que é a crítica do design critique, é o que eu tenho. Mas deixa eu responder através dos próximos slides, que acho que vai ficar mais claro também. Eu também concordo que esse é um dos pontos menos pesquisados sobre design thinking, que é o papel da crítica no projeto. E eu acho que tanto esse livro do Tim Brau quanto esse outro livro aqui... Deixa eu ver. Esse outro livro aqui também que fala sobre projeto, ele não fala muito sobre crítica. Eu acho que é um ponto que a gente precisa fortalecer na literatura. Bom, se alguém não tiver mais uma dúvida desesperada agora, puder aguardar mais um pouquinho, eu vou apresentar a terceira parte, pode ser? Então, eu estou trabalhando já há alguns anos, burilando uma taxonomia para organizar os diferentes tipos de pensamentos projetuais, para iniciar essa discussão, porque não existe uma organização muito clara de diferentes escolas de pensamento de design. Escola de pensamento projetual, traduzindo para o português. E eu, por enquanto, estou identificando uma escola que surge do Herbert Simon, bom, livro da ciência do artificial, uma escola que surge do trabalho do Shawn, que é a escola reflexiva, e uma terceira escola que eu estou ajudando a fundar junto com o Engelström, que é um teórico da teoria da atividade. Vamos começar com a primeira das escolas, que é a sistemática. Nessa escola, o pensamento projetual, ele vai tentar reduzir o problema a subproblemas, e esses subproblemas em subsubproblemas, e aí você resolve cada um desses subproblemas separadamente, depois você integra essas soluções individuais numa solução coerente, buscando uma visão sistêmica, que vá reduzir de novo a variação e a diferença para que as coisas sejam consistentes. Então, a redução é uma técnica inicialmente das ciências naturais, que é aplicada aqui na produção de um software, na produção de qualquer tipo de projeto, não só de software. Então, eu chamo isso de design redutivo na minha tese de doutorado. Algumas características marcantes do pensamento projetual sistemático. Definir requisitos antes de começar a projetar. Projetar módulos ou componentes em separado. Criar sistemas que conectam todos os componentes. Evitar o erro e falha. Tomar decisões baseadas em quantidades. Projetar com restrições explícitas. É bem provável que isso aqui seja bem familiar para vocês aqui na engenharia de software. Mas existem outras maneiras de pensar projeto além dessas. É legal e muito bacana que vocês tenham esse momento para debater e ver isso, porque a maioria das pessoas na computação não sabe que existe outra maneira diferente de projetar, ou se vê que existe uma outra maneira vai rotular de não ter processo, não ter método, não ter pensamento projetual, ou ser menos estruturado, ser pior, ou ser, enfim, um preconceito por não conhecer. Aqui a gente está tendo a oportunidade de ter esse debate e essa possibilidade interdisciplinar. Então, aqui estão alguns livros que apresentam esse tipo de pensamento projetual sistemático. O primeiro é a Bíblia do Pensamento Sistemático, projeto na engenharia. É um livro que trata principalmente de exemplos da engenharia mecânica, mas ele se aplica a qualquer disciplina de engenharia. Eu li esse livro. Obrigado a ler lá no meu doutorado. É um livro denso, pesado, gigante, muito minucioso. Ele trata o projeto como sendo um método bem detalhadinho. Aqui temos o Design Patterns na área da computação, que vai utilizar um conceito originalmente da arquitetura para organizar código, reutilizar o código de uma maneira racional. E aqui um livro mais abrangente, que vai apresentar uma abordagem para projeto de software, incluindo a interface de maneira sistemática. Então, todos os elementos do software cabendo dentro de um sistemão. Digamos assim, é o que propõe esse livro do Carlos Otero. Tem algumas atividades também, mas não vai dar tempo de a gente fazer. Vou pular elas, desculpem. Vou mostrar o resultado. É um jogo que a gente fez lá com o pessoal da Copel. Já são 4h30, queria terminar as 5h. Para dar tempo de a gente discutir também, se precisar. Enfim, você faz pontos entre A e B. Você marca qualquer ponto no papel, mas cada vez que você marcar um caminho, você tem que fazer um caminho diferente. Para ver nenhuma maneira de você ir de A a B. E aí olha só o que fez um dos colegas nossos lá da Copel. A solução dele é incrível. É uma ideia muito boa. Aplicou o pensamento sistemático e resolveu o problema através de um algoritmo, de geração de caminhos que vai de 1 até 1.000 e 1.000. É uma brincadeira, uma piada que faz sentido total, mas também expressa uma solução para um problema que é mal estruturado. Porque eu deixei bem vago a minha solução, digo, o meu problema. Cria um caminho de A até B, qualquer lugar. Então tem várias instruções que não estão sendo dadas. Tipo, onde que eu coloco A e B na folha? E assim como no primeiro exercício que a gente fez com os patinhos de Lego, a intenção é essa mesmo. É deixar a pessoa mais livre para trazer o que ela quiser. E por exemplo, no meu caso, trazer algo que a gente não esperava que alguém resolvesse esse problema através de um algoritmo. Então eles estruturaram o problema ao definir esse algoritmo. Transformaram um problema mal estruturado em problema estruturado. Isso aqui é uma parte da teoria fundamental do Simon. De que qualquer problema da nossa sociedade pode ser resolvido de maneira computacional se você estruturar aquele problema. É um argumento que vai ser rebatido pelo Shawn. Como eu disse, daqui a pouco vai dar origem ao próximo pensamento projetual, que é o reflexivo. O Shawn vai dizer o seguinte, que o pensamento projetual nas escolas de arquitetura e design que ele estudou, a arquitetura e design industrial, os estudantes ficam batendo contra as paredes conceituais do projeto dentro de uma, digamos assim, uma caixa. Cada vez que eles batem no campo dessa caixa, eles repensam essa caixa. Eles recebem, às vezes, uma crítica do professor, tipo, não vá por esse caminho, não vá por aquele caminho, não vai dar certo o que você está fazendo. Essa crítica que o Tôber estava falando agora há pouco. A crítica é o estopim para uma reflexão que não é feita do tipo, eu vou voltar para casa, chorar e pensar no meu projeto. Porque você não tem tempo para isso. Você na hora já vai mudar o seu curso de ação, o que você estava projetando. Então você vai mudar o seu lado, por isso que fica esse processo meio caótico, até chegar num conceito que já levou muita paulada. E esse conceito vai para fora. Então o projeto surge a partir de uma inspiração de uma pessoa, depois ele é visualizado através de esboços, alternativas, modelos, cada um deles é devidamente criticado ou recebe algum tipo de resistência do ambiente. E essa resistência vai provocar reflexão e consequência de redefinição do conceito. Então o conceito precisa ser muito forte, porque normalmente quem cultiva esse pensamento projetual são pessoas que não podem, não querem, não têm acesso aos meios de produção, ou seja, eles não produzem, só fazem o projeto. Então é característico do pensamento projetual reflexivo de você entregar para uma outra pessoa fazer. É claro que isso aqui é como o Shawn discute. Já quando a gente vai para a Apple Developer Academy tem uma diferença, né Tânia? Porque lá os estudantes não só fazem o projeto, eles também implementam. São coisas que a gente tem que repensar aqui nessa teoria do... A mensagem é exatamente a mesma que você falou. Conceitos surgem na inspiração, eles vão discutindo, são esboços, é exatamente igual. Então aqui tem o exemplo de um arquiteto maluco pensando numa nova disciplina que seria Worldcraft, que é você projetar mundos. É muito louco esse vídeo. Ele é um dos arquitetos hoje mais famosos do mundo, Gere Kingels. Então esses três livros que fundamentam essa visão, o Shawn querido da Tânia. E tem esse outro livro aqui que é pouco conhecido na engenharia de software, mas que é... - Não, ele é bem conhecido. - É? Bem conhecido? Enfim, eu não vi tanta citação desse trabalho dele. - Fred Brooks. - Fred Brooks. Não, é o primeiro livro dele, "Um Homem Mítico" é famosíssimo, é fundador. Mas esse segundo livro dele, que é dos anos 90, já não é tão citado. Mas é o livro mais completo que tem de filosofia e de pensamento projetual que eu vi até agora. E o legal é que ele não está no pensamento projetual sistemático. Ele já está refletindo sobre o pensamento projetual reflexivo, que é esse do Shawn. Inclusive ele cita e discute o Shawn em relação com o Simon. O Brooks conheceu o próprio Simon, discutiu, conversou, trabalhou com ele numa época. E o próprio Simon mudou de ideia sobre várias coisas, obviamente escreveu isso nos anos 60. Só que não foi atualizado esse livro. E o próprio Simon morreu antes de poder fazer essa atualização. Mas o Brooks fez o favor e trouxe essas discussões mais modernas. E na área do design industrial surgiu também uma discussão parecida quando os profissionais de design industrial começaram a se meter nas equipes de engenharia de software a partir dos anos 80 e 90. Então tem um livro muito bom chamado Thoughtful Interaction Design que é escrito com base no Shawn também. Eles vão fundamentar essa ideia de thoughtful, é parecido com reflexivo. Eles vão falar que os designers quando eles vão atuar na projeto de software eles precisam ser reflexivos porque o software tem um desafio que não é somente você atender os requisitos técnicos. Você vai ter também os requisitos humanos. E o requisito humano não existe. Você vai estar lá esperando para chegar. Você vai ter que criar. Você vai ter que criar observando, interagindo. Então tem todo um trabalho meio artístico, um trabalho manual e talvez meio artesanal de você descobrir o que vale a pena construir. E esse livro vai ser muito sobre isso e como se utilizam essas abordagens que a gente está utilizando aqui no design thinking. Mas nessa época não se usava esse termo. O design thinking como a gente conhece hoje é do livro de 2009. Esse livro aqui Thoughtful Interaction Design é de 2004. E nesse livro, nessa época, o termo utilizado era design de interação, interaction design. Tem toda uma linha de pesquisa em interaction design que ora acontece na computação, ora acontece no desenho industrial, mas que é focado em hardware e software. Não tem essa abrangência que tem por exemplo o trabalho do Shawn que envolve qualquer tipo de projeto. Então aí tinha mais um joguinho que... Fechem os olhos, por favor, para vocês não perderem essa chance de jogar esse jogo um dia. Ok, não vou mostrar. Eu sei que é sacanagem fazer isso, mas tudo bem. Os problemas que o pensamento projetual reflexivo lida são chamados de problemas capciosos. Não são problemas que podem ser estruturados como a gente viu anteriormente no caso da... No caso de um ATB. Não são problemas que você consegue definir quais são as variáveis. Porque esses problemas estão no mundo, as pessoas estão complicando o problema dia após dia, e você entrar no problema já aumenta esse problema. Perceber que aquilo é um problema e dizer que aquilo é um problema já afeta o problema. Por isso ele é chamado de capciosos. A complexidade só aumenta, nunca diminui. Quanto mais você cava, mais você descobre que o buraco está mais embaixo. Isso é documentado, isso é uma experiência que a gente tem na prática, que a gente acha às vezes que nós somos burros por não sabermos resolver aquele problema. Mas não, isso é uma característica inerente à prática de projetos. Certos problemas são capciosos. Você não consegue resolver ele de maneira técnica perfeita. O que você pode fazer é resolver da maneira mais correta do ponto de vista ético. Então nesse momento eu tenho recursos limitados, eu não consigo resolver esse problema, mas eu consigo dar uma amenizada, eu consigo dar uma passada de pano. E você vai ter que fazer isso para ser considerado ético. Ou, por outro lado, eu mexendo isso aqui, eu interferindo isso aqui, por exemplo, a relação dos indígenas com o homem branco. Então você tem as tribos lá no interior da Amazônia que nunca tiveram contato com o homem branco. O que você faz? Por um lado, você pode lá ajudar, que às vezes a FUNAI vai lá e passa com o helicóptero e joga um monte de facão para os indígenas poderem ter acesso à comida, poderem ter mais acesso a recursos, ou você deixa eles intactos sem ajudar eles. De repente, sendo vítima de caçadores, de grilheiros que querem culpar as terras deles, então é um problema capcioso que não tem uma solução muito clara e que a gente vem vivendo com esse problema já há mais de 300 anos aqui no Brasil. E aí, por fim, a gente vai trabalhar com pensamento projetal expansivo. Esse aqui ainda está em desenvolvimento, é um tipo de pensamento projetal que ainda não está muito bem fundamentado, mas o melhor exemplo de fundamentação é a minha tese doutorado, tcharam, momento mexan, né? Quem quiser dar uma olhada depois aqui tem a tese disponível para download gratuito também. A expansão é a técnica principal desse pensamento. O que é expansão? Tem um novo problema, traz para dentro. Tem uma nova pessoa para participar, traz para dentro. Tem uma nova ideia, traz para dentro. Caldeirão, qualquer coisa vale. E mesmo que isso cause um conflito, na verdade é porque causa um conflito que tem que entrar. Porque o conflito dentro desse pensamento é visto como sendo o impulsionador de novas ideias, o impulsionador de novas possibilidades. Então, o pensamento projetal expansivo, como eu falei, está constantemente incluindo novas pessoas, novos problemas, buscando com isso gerar uma visão ampla, mais holística dos fenômenos e eventualmente também visões contraditórias. Dentro desse caldeirão pode ter algumas pessoas que pensam isso, algumas pessoas que pensam aquilo. Pela fricção entre essas pessoas podem surgir ideias que não foram pensadas ainda. Outra questão também é que você não considera só o planejamento. Você considera também a execução e a experiência que acontece depois da execução ou durante a execução do projeto. Ou seja, tem a experiência do consumidor, do usuário, tem também a experiência do empregado, tem a experiência do trabalhador, também é considerado nesse pensamento projetal expansivo. Por isso que muitas vezes ele é ligado também a uma mudança na sociedade que envolve uma mudança organizacional ou envolve também uma mudança de políticas públicas. E a atitude é mais importante do que o processo. Então, pensar com as mãos através de protótipos, do jeito que a gente fez aqui, é uma maneira de ajudar a pensar junto. Isso é uma jurística que tem a ver com uma atitude. Se você vai fazer isso primeiro, no começo ou no final, isso não é tão importante quanto você seguir e ser coerente com as suas atitudes. Então, é muito comum na arte, no desenho industrial, na computação também tem bastante. Aqui tem três referências de pensamento projetal expansivo. Esse é o que tem menos referência, essas referências nem são tão acadêmicas assim. Por isso está precisando de mais pesquisa. Tem o trabalho do timbral, que eu já mencionei várias vezes, mas tem o trabalho na computação também, que foi difícil de achar. Mas refletindo, eu considerei o trabalho do Seymour Papert, que trabalhou muito com informação informática na educação, bem no começo dos anos 70, 80. Ele escreveu esse livro, o Logo, e também criou uma ferramenta lá na MIT que servia para as crianças aprenderem a programar desde cedo, usando metáforas e movimentações corporais. Ele fez a tartaruguinha lá do Logo e isso, digamos assim, ele tinha a visão de que os laboratórios de informática não deveriam ser laboratórios, eles iam ser mais parecidos com uma escola de samba, ele fala nesse livro. Na escola de samba você não tem uma maneira só de fazer uma coisa, tem várias maneiras diferentes, você tem uma sincronia entre os participantes e eles fazem aquilo coletivamente. Eles constroem, as fantasias juntos, constroem os carros alegóricos juntos, e você tem uma intenção de construir algo bonito. Então ele enfatiza muito esse lado estético também na criação computacional como sendo algo motivador para as crianças aprenderem a programar. Esse livro aqui também é o primeiro livro que cita o conceito pensamento computacional. Depois existem outros autores que vão puxar o pensamento computacional para o lado sistemático, mas originalmente ele era bastante expansivo. Esse ano foi lançado um livro que explica finalmente de maneira um pouquinho mais detalhada, mas sem perder o aspecto expansivo, porque tem muito livro de design thinking como esse aqui, Inovação em Negócios da MJV, que é uma empresa de tecnologia de informação brasileira que virou uma consultoria de inovação através do design thinking. Esse livro é mais sistemático do que expansivo, eu diria. Ele vai reduzir a um método, um conjunto de métodos, que é basicamente o que é esse livro aí. Já esse livro não, ele já vai falar dessas questões que eu estou discutindo aqui com vocês, são desafios mais do pensamento do que de métodos. Bem recente esse livro também, acabou de ser lançado em português. Tinha mais um joguinho aí, vou deixar para a gente outra oportunidade. Nossa, o Pradim, você não tem pena essa nossa oficia? É, não, eu sempre coloco mais do que realmente consigo fazer. Minha estimativa de tempo não está muito boa, de onde? Mas de qualquer forma, o pensamento projetual expansivo, ele busca a origem dos problemas e também das soluções, no conceito de contradição, que é o conceito central da minha tese de doutorado. O que seria uma contradição? É uma tensão que se acumula na sociedade entre forças opostas que não podem ser eliminadas. Então você não pode dizer essa força ganha, ou essa força é melhor, ou isso aqui é superior, ou isso aqui é mais evoluído. Você pode até tentar, mas você não vai conseguir evitar que o outro lado volte mais tarde para dar o troco. Então você pode em algum momento declarar esse aqui é o ganhador, essa força é mais forte, é mais importante. O que vai acontecer com a outra força? Ela vai ficar acumulando tensão, vai chegar uma hora que vai ter uma virada de mesa nesse processo. E isso vai dando também impulso para as coisas se modificarem, se transformarem. Então princípio, digamos assim, de mudança que está embutido em qualquer tipo de estrutura social. A única maneira de transformar uma contradição é você criar uma terceira força que junta aquelas duas forças numa maneira nova. O pensamento projetual expansivo pode ser visto como uma proposta de uma terceira força para os estudos de InDesign. Você tinha de um lado a escola sistemática dos simonianos e a escola reflexiva dos xonianos. O que eu estou querendo criar e fundamentar com o pensamento projetual expansivo é uma escola que está nesse meio do caminho. Então ele não está só no meio do caminho, está lá na frente, ou lá em cima, ou lá embaixo, que seria o pensamento projetual expansivo. Esse tipo de raciocínio que eu estou usando aqui agora também é chamado dialético. O raciocínio dialético é você pensar, partir e ir junto com as contradições. Os autores principais que me influenciam a esse pensamento é o Henry Lefevre, que é um sociólogo, e o Engstrom, que é um psicólogo, que escreveram sobre isso em diferentes contextos. Mas o que é legal dessa teorinha é que contradições é uma força motivadora. As pessoas percebem que aquilo ali é um "ó" do Borogodó, aquilo ali é uma coisa muito difícil de trabalhar, e elas ficam impertigadas, "eu quero esse desafio, esse desafio é tenso, aí que eu vou". Então motiva as pessoas, quando você consegue representar e mostrar que existe uma contradição, não precisa usar esse termo necessariamente, não precisa falar que é uma contradição, mas a pessoa percebe que aquilo ali é uma coisa muito tenso e difícil de trabalhar, pessoas que têm diferentes pensamentos podem vir a trabalhar juntas, e ao fazer isso, elas podem cruzar fronteiras entre as disciplinas e entre os pensamentos projetuais cultivados nas disciplinas. Então é por isso que o pensamento expansivo está no meio do caminho, porque ele não está tentando eliminar ou dizer que ele é melhor do que os outros pensamentos, pelo contrário, está botando de novo os dois outros pensamentos dentro do caldeirão para interagir e gerar fricção e atrito. Então eu tenho, desde que comecei o meu POSDOC, documentado as minhas leituras da Ingeria de Software com essa perspectiva, estou tentando identificar contradições dentro da Ingeria de Software. E já encontrei algumas, acho que tenho uma listinha de mais ou menos umas dez contradições que precisam validar melhor, quando eu estou identificando eu faço da seguinte maneira, eu pego um livro ou um artigo e eu vou puxando as ideias principais desse artigo, depois eu percebo que tem ideias contraditórias nesse artigo ou nesse livro, e aí eu marco como uma contradição. Por exemplo, nesse caso do livro do Meet the Man Month, ele fala de uma contradição entre a divisão do trabalho que você precisa fazer num projeto de software porque ele não consegue ser feito por uma pessoa, nem por uma equipe pequena de pessoas que vão se auto-organizando, ele precisa ser feito por uma equipe gigante de centenas, às vezes milhares de desenvolvedores, e quando você faz isso, você divide esse trabalho, você perde a integridade conceitual do seu software, porque ninguém mais sabe o que é o seu software, ninguém mais consegue ter a visão ampla e geral do sistema. Esse é um dos principais temas que ele trabalha no livro do Meet the Man Month, o Meet com o Homem Mês, e isso é uma contradição das clássicas, se você por um lado reduzir o número de pessoas trabalhando e dividir menos o trabalho delas, vai ficar uma zona, por outro lado, se você estruturar demais, dividir demais, também você pode perder essa integridade conceitual, então é uma espécie de faca de dois legumes ou caminhar na corda-bamba, ou se correr o bicho pega, se ficar o bicho come, são todas frases que a gente tem na nossa linguagem popular para se referir a lidar com contradições, que é o que eu particularmente acho que é muito interessante, pouquíssimo pesquisado na engenharia de software, normalmente você acaba tomando um dos lados, ou uma coisa é uma coisa, ou uma coisa é outra coisa, ou é zero ou é um, e esse trabalho que existe entre o zero e um, a área cinza, é uma área interessantíssima para pesquisa na área da computação, de modo geral, então desde que a gente começou esse trabalho mais histórico, de identificar essas contradições, já tiveram alguns trabalhos relacionados, que eu queria fazer, eles tinham que ir rápido, de colaborações orientando-se aqui da Sherida e da Andréa, que estão pesquisando essas contradições, às vezes de maneira intuitiva, sem saber que são contradições, mas eu acho que são, no caso do Elias, felizmente não está aqui hoje, mas defendeu também recentemente a dissertação dele sobre o tal do Deviner, o que é o Deviner? É uma tentativa de resolver essa questão de você ter diferentes pessoas numa equipe de software, pessoas que têm pensamentos projetuais completamente diferentes, vem o designer industrial com essa formação do pensamento mais reflexivo, vai trabalhar junto com alguém que vem da computação com pensamento projetual mais sistemático, essas pessoas não vão se entender, aí uma das ideias que surgiu na Apple Developer Academy é de ter um cara formado especificamente para ser um Deviner, um cara que consegue atuar nesses dois tipos de pensamento, então ele mostrou que esses caras têm histórias fabulosas, incríveis, e têm características comuns entre eles, essa foi a característica tanto de trajetória como características pessoais, com Rodolfo e com Guilherme, a gente está trabalhando com várias contradições, mas acho que essa a gente discutiu mais, o projeto começa a ficar cada vez mais complexo, mas por outro lado você quer cada vez mais controlar o projeto, o projeto é o que a gente sentiu depois que eu joguei no teu colo, por um lado é bom que as coisas aconteçam espontaneamente, por outro lado é horrível que você não tenha sensação de controle, que você sabe onde o projeto vai chegar, e quem é gestor de projetos nesse tipo de situação fica sentado em cima da contradição, com o popô ali movendo por um lado e por outro, sambando, porque se você tomar um lado e falar agora o projeto vai ser completamente estruturado e cada um vai fazer só aquilo que a gente está pedindo, você vai jogar o bebê fora junto com o sujeiro da banheira, então você não pode tomar uma decisão radical e unidirecional num projeto que tem complexidade crescente. Então a gente está escrevendo, tem um artigo aí na Transactions of Engineering Management, que trabalha, dentre outras, com essa contradição que a gente ainda recebeu aí uma major revision, extremamente arriscada disse o editor, mas a gente vai tentar, porque enfim, o tema é muito motivador, contradições motivam, os malucos aqui, cada semana que eu encontro eles, "não, mas peraí, eu descobri mais um detalhe dessa contradição e nunca termina", a gente lê, lê, lê e não consegue chegar a uma conclusão, e eu acho que nunca vai chegar, a questão que é chave aqui, fica a dica para nós, é o prazo, acabou o prazo, não adianta, você nunca vai chegar e ter a sensação de que você conseguiu cobrir uma contradição, ela vai estar sempre fugindo, ela vai estar sempre se tornando mais complexa, então você tem que estar atento ao prazo, acabou o prazo, beleza, é isso que eu consegui fazer. [Pedro] Eu vou pegar um gancho, tem alguns autores que utilizaram a dialética, mas não de uma forma expansiva, no caso eles delimitaram o mundo, delimitaram o que eles iam analisar com o caso lá do Altschuler da Trace, se você quiser utilizar essa dialética no mundo, ou seja, um pouco de conhecimento conhecido, é perfeitamente possível fazer a mesma análise de contradições. O que o Guilherme está falando faz parte dessas nossas discussões, tem um cara que a gente só encontrou até agora, um único cara na engenharia que discute contradições, que é o Altschuler, que era um engenheiro, não sei nem se era engenheiro, mas ele estudou no contexto da engenharia mecânica, ele analisou patentes, e aí ele mostrou que existiam princípios que eram mais ou menos parecidos entre várias patentes, ele chamou isso de contradição, e ele aplicou, na verdade, o pensamento projetal sistemático, no livro dele lá, como é que é o nome do livro dele, a invenção, assim que as coisas surgem, uma coisa assim, o inventor surgiu, uma coisa assim, assim surge o inventor, não me lembro, mas ele vai adotar o pensamento projetal sistemático, embora ele fale de contradições, eu não diria que é uma contradição o que ele está falando, eu diria que é um problema estruturado, porque ele estrutura o problema, ele cria até... Na verdade, o que eu acho que ele faz é o seguinte, ele pega milhares de patentes junto com o time dele, e ele verifica todos os parâmetros que existem em todas as patentes. Isso é estruturar, isso é estruturar. As parâmetros são... É estrutura. Não, são, são, quer dizer, que é igual ou que é diferente, não é isso? Foi? O padrão que ele acha é o padrão na solução, mas os parâmetros são as contradições, por exemplo, em patentes você tem algumas características que são características relacionadas à geometria, características relacionadas a, como é que é, a pressão, temperatura, coisas assim, são parâmetros, e ele, em todas as patentes que ele analisou, ele ficou, ó, esses parâmetros existem aqui, eram 39, e aí ele foi, olha, olha esse parâmetro aqui, ele está jogando contra esse outro parâmetro, existe esse problema, e aí ele olha, não histórico de como que as patentes foram evoluindo, como que as pessoas evoluíram, aí ele cria 40 soluções inventivas, que é como que escapou da conversão. E depois disso tem um algoritmo de solução de problema genérico que é extremamente complexo, burocrático, mas muito utilizado na engenharia mecânica, mas não utilizado em outras áreas pela dificuldade de você abranger outros tipos de problema. Pessoal meio que força a barra, mas a gente vê que o TRIS é meio limitado para a abrangência de problemas. O que a gente está tentando fazer no artigo, que eu estou escrevendo com o Rodolfo, com a Anne também, é mostrar que a gente resolveu problemas, ou melhor dizendo, mostrar que a gente lidou com contradições no projeto da Copel de um jeito mais expansivo do que sistemático. Aqui tem um terceiro trabalho, e daí tem mais a ver com o trabalho da Tânia, né, que por um lado, num projeto de software você tem pessoas, e você tem interações entre essas pessoas, e isso sendo uma maneira também de gerar valor, de você deixar as pessoas livres para elas interagirem no cafezinho, numa sala como essa. Por outro lado você tem processos e ferramentas que são essenciais para estruturar isso tudo. E quando você focaliza demais no lado, focalizando mais no outro, você vai ter efeitos diferentes, tanto na qualidade do processo quanto na qualidade do produto. No caso que a Tânia mostrou, é que apesar de parecer caótico o que acontece na Apple Developer Academy, os alunos aprendem muitas coisas, muitas habilidades que você só poderia aprender na prática de mercado, você aprende antes dentro da universidade, porque a universidade cria conflitos, cria situações de crítica, por exemplo, de fricção, que vai gerar esse tipo de aprendizagem. Ou seja, dentro da Apple Developer Academy também tem essa contradição entre as pessoas estarem livres para fazer o que quiserem, e você tem que seguir um processo porque o prazo está acabando e você tem que entregar o seu aplicativo no final do mês. E a última contradição que a gente já estudou é um artigo que a gente já escreveu várias vezes e que está bem difícil de passar, que vai mostrar que a programação pode ser encarada como uma arte também, isso é legal, isso é produtivo, e também é uma maneira de se aprender. Mas você pode estar interagindo com esses dois lados, arte e ciência, talvez seja a pegada para a próxima vez com o artigo, trazer o lado mais científico da questão. Estou escrevendo junto com o Fábio e a gente vai mandar de novo, talvez no ano que vem, né? Vamos ver, né? E aqui tem uma listinha de contradições que eu gostaria de estudar mais para frente, mas que ainda não tenho parceiros, fica a dica. A divisão do trabalho e integridade conceitual que eu já mencionei, seria super interessante fazer estudos de caso disso porque não tem, eu já fiz uma pesquisa, não consegui encontrar, embora o Brooks fale disso no livro dele, é um tipo de assunto que normalmente você não vê na pesquisa de engenharia de software, mas que eu acho interessante isso. A deletiva de divisão do trabalho aqui não chega, é divisão de tarefa ou divisão por tipo de atividade? É mais por... é de pessoas, é mais de pessoas mesmo, não é tanto a divisão da tarefa. Aqui tem outra, de responder a mudanças, você está preparado para responder a uma mudança quando ela surgir ou você seguir um plano independente das mudanças, isso é uma contradição bem forte, engenharia de software que dá origem ao desenvolvimento ágil, que daí eu acho que vai para o outro lado completamente, gera até um... Relação maior para engenharia de software contínua também. Também, com certeza. Terceiro ponto, considerações técnicas versus impacto social. Você, por um lado, pensar no software enquanto um negócio isolado que tem que funcionar bem, por outro lado, você pensar o software como algo no mundo que está interferindo na vida das pessoas. É o Carl Friedrich que escreve sobre isso, um artigo bem louco, filosófico, sobre engenharia de software e aprendizagem baseada em ateliês. Suporte de práticas versus mudança de prática, o que está relacionado com essa? Software serve para apoiar uma organização a continuar sendo o que ela já é ou software serve para uma organização se transformar e ser uma outra coisa completamente diferente? Só que é a história da IBM. Numa época a IBM está querendo fazer software para estruturar a organização para ela ser mais do que ela já é, agora, no momento atual, a IBM quer fazer software para inovar, para fazer transformação organizacional, transformação digital. Isso já foi mapeado, essa contradição, desde 88, que hoje a gente chama de transformação digital. E, por último, situações complexas e situações conflituosas, como uma coisa leva a outra, e o conflito gera complexidade e a complexidade gera conflitos, como é que você lida com isso? Tem um livro, um artigo muito interessante, sobre a dificuldade de formalizar atividades através de software por conta dessa complexidade e dos conflitos. Buenas, era isso. Eu corri um pouquinho, tive que pular os nossos exercícios, mas consegui terminar mais ou menos no tempo. E, enfim, se a gente tiver mais um tempinho, o pessoal puder ficar mais um pouco, a gente pode abrir para perguntas e debates.