Prototipamos por código. Palestra do FrontTalks

Boas festas, amigos! Em preparação para o início do novo ano de trabalho, estamos concluindo uma série de materiais da conferência FrontTalks 2018. Esta é uma palestra de Andrei Salomatin filipovskii_off - um desenvolvedor da Polychops. Andrei oferece uma abordagem equilibrada à prototipagem: deixar de artesãos que executam pedidos em pesquisadores - aprender a trabalhar com incerteza e, possivelmente, manter a razão mesmo sem um plano claro.

O feedback quantitativo é um teste AV, resultados binários, quando a Opção A ou a Opção B. vence. É tudo o que podemos obter dos ciclos quantitativos. É como se estivéssemos em um quarto escuro e nada estivesse visível, mas temos um ponteiro laser. De tempos em tempos, brilhamos nos cantos, destacamos alguns pontos e entendemos o que há neles.

Em vez disso, o que gostaríamos? Um usuário que descreverá esse quarto escuro, que o conhece muito melhor que nós.

- Olá pessoal! Eu gostaria de falar sobre prototipagem: por que fazer protótipos, o que obtemos disso e como fazê-los, usando exemplos.





Vou começar com uma pequena história. Em 2012, entrei para esta startup, um cervo maravilhoso. Tínhamos algo parecido com uma plataforma de publicidade, eu vim como desenvolvedor Java. É claro que grandes volumes de tráfego, tarefas interessantes, a equipe é simplesmente louca - tudo é maravilhoso. Trabalhamos há cerca de oito meses, de cabeça no teclado, criamos recursos muito interessantes, rapidamente mudamos tudo. Mas em 2013, o cervo sobe cascos.

O que aconteceu Pensei nisso por muito tempo, posteriormente fui trabalhar como desenvolvedor front-end e back-end para diferentes empresas, então fui líder de equipe e gerente de produto. Ele trabalhou tanto em startups quanto em empresas de terceirização, em grandes empresas. Principalmente focado em startups.



Eu também fiz alguns desses projetos. Tive a sorte de trabalhar no MoscowJS, no Frontend Union Conf e no RadioJS. Talvez tenhamos cruzado com você em algum lugar. Agora estou fazendo o Code Podcast, um podcast em inglês sobre conceitos comuns em programação, e o Polychops, um projeto para músicos que trabalha em um navegador e ajuda a praticar o instrumento, a ter mais tempo e prática.

O que aconteceu com o HeyMoose? A empresa tinha pessoas muito inteligentes que agora trabalham como desenvolvedores seniores na Microsoft ou se tornaram STOs. Fizemos o que fizemos de melhor: resolvemos problemas técnicos complexos de maneira rápida e interessante. Mas algo deu errado.



E algo dá errado com muitas empresas, especialmente startups. As startups geralmente se esgotam por dois motivos: ou elas não entendem o produto, em algum lugar em que sentem falta do produto ou ficam sem dinheiro. Muitas vezes eles ficam sem dinheiro porque procuram um produto e não o encontram por tempo suficiente.

Mas por que o desenvolvimento personalizado nas empresas de terceirização não fecha? Ou por que as grandes empresas não estão fechando? Eles parecem ser mais lentos. Como regra, as equipes são pelo menos menos motivadas. Qual a diferença? Os mecanismos de trabalho são os mesmos: no desenvolvimento personalizado, escrevemos TK ou pedimos TK aos clientes, eles pintam para nós, nos dão, fazemos mock-ups, códigos e escrevemos - o mesmo processo. O que há em uma startup, que em grandes empresas, pode haver práticas de ponta. Tudo a mesma coisa. Então, por que as startups se esgotam?

Vamos primeiro imaginar uma situação hipotética: um gerente de produto chega até nós e pergunta se podemos adicionar um metrônomo que funcione em um navegador, emitir um som com intervalos periódicos e visualização sincronizada, para que diferentes luzes brilhem no mesmo ritmo do metrônomo um a um. E para que tudo isso seja preciso, independentemente do que está acontecendo no computador, em outros processos etc.



Quem tem 100% de certeza de que podemos fazer isso usando o navegador e a API do navegador? Nem uma única pessoa. Quem tem 80% de certeza de que provavelmente podemos fazer isso? 3-4 mãos. Quem tem certeza de 50 a 50? A maioria. Quem tem certeza de que não podemos fazer isso? Sinceramente.

O exemplo a seguir. Suponha que estamos trabalhando em outra empresa em um banco móvel. Pensamos mais no produto e acreditamos que é necessário aumentar o número de usuários que usam nosso banco móvel. Criamos um recurso: agora o usuário pode compartilhar uma compra ou reabastecer uma conta nas redes sociais. O dinheiro chegou até ele, ele é assim no Facebook - olha, o dinheiro chegou até mim. Você acha que isso ajudará a atrair mais usuários? Quem tem 100% de certeza disso? Nem um único. Quem tem 100% de certeza de que isso não vai nos ajudar de forma alguma? Duas ou três mãos. O resto está em algum lugar no meio.



E o último exemplo. Nós fazemos um serviço em nuvem, abrimos nossa empresa. O serviço de nuvem coletará logs de projetos, de front-end e back-end em pequenas e médias empresas, agregando-os, aprendizado de máquina, IA e tudo mais. Nós vamos vendê-lo. Quem tem certeza de que isso é 100% de sucesso ou 100% de perda? Algumas pessoas.



Há apenas uma resposta correta para todas essas três perguntas: "provavelmente". Temos 50 a 80% de certeza das respostas para algumas das perguntas. Depende muito do contexto, da implementação. O mesmo metrônomo com a visualização - eu trabalhei nele, não pode ser feito para que funcione em todos os contextos: por exemplo, com fones de ouvido Bluetooth. Mas isso pode ser feito em dois ou três casos generalizados. No meu entendimento, isso é "provavelmente" - e há uma razão pela qual as startups estão fechando, pelas quais o HeyMoose subiu nos cascos. Talvez façamos algo de bom, ou talvez estejamos perdendo tempo. E não temos como entender como estamos confiantes no que estamos fazendo.

Um pouco de teoria. Qual é a diferença entre desenvolvimento personalizado e startups? A diferença está no contexto. Estamos neste contexto de incerteza, temos uma probabilidade de sucesso e uma probabilidade de fracasso. É como se tentássemos usar os mesmos métodos e práticas quando corremos no chão e quando corremos no espaço sem gravidade. Parece que estamos correndo, mas nada acontece. O que estamos fazendo de errado?

Essa incerteza vem de três áreas principais. Vem do mercado - porque não sabemos claramente o que outras empresas estão envolvidas na agregação de logs. Talvez este mercado já tenha sido capturado por alguém? Que demografia no mercado, quais são os preços? A incerteza pode vir de um produto. Não sabemos qual é o problema do nosso cliente e como resolvê-lo. Este é um exemplo de um banco móvel. Parece que temos um entendimento, mas não temos certeza se os usuários têm esse problema e como resolvê-lo.

E há problemas de implementação. Um exemplo com um metrônomo. Não sabemos 100% se isso é teoricamente possível ou não.

Ou outro exemplo. Não temos nenhum problema com o mercado ou o produto, se inventarmos uma cura para o câncer, que é apenas uma pílula - aceita e saudável. Mas há um grande número de incertezas em como implementar esta pílula. Estamos no nevoeiro da guerra, mas ao mesmo tempo nos comportamos como se o nevoeiro não existisse, porque temos os mesmos princípios que funcionam no desenvolvimento personalizado. Nós simplesmente os movemos para o nosso contexto de incerteza.

Nós meio que fingimos que esse nevoeiro não existe, não há incerteza. E estamos tentando prever o futuro. Quando comecei a trabalhar como gerente de produto, fiquei impressionado após o processo de desenvolvimento pela quantidade de adivinhação que o gerente de produto deveria produzir. Quando você se reporta ao diretor ou a outra pessoa, precisa parecer confiante, dizer que faremos isso ou aquilo, conquistar o mercado até setembro, tudo vai doer. Tudo isso - bem feito, pensei em tudo. Embora, de fato, eu entenda que nada disso exista, estou apenas tentando adivinhar as cartas e tentando parecer confiante com isso. Não temos uma cultura de trabalho com incerteza, com probabilidade. Além disso, para parecer especialistas, precisamos lutar constantemente por uma reputação, ter confiança, conversar sobre o que devemos fazer, em vez do que devemos verificar ou do que não temos certeza.

Nós, especialmente desenvolvedores, ainda temos a tendência de pensar sobre o que sabemos, entendemos e podemos controlar. Como desenvolvedores, gostamos muito de planejar arquiteturas, pensar no futuro, não se repetir, programar padrões e tudo mais.

Designers também sofrem com isso. Eles gostam de pensar no futuro, criar layouts perfeitos etc. Somos especialistas, embora na realidade possamos precisar nos tornar outra pessoa.

Como lidamos com a incerteza? Que métodos de luta nós temos? O primeiro método é o mais importante - colocar todas as cartas na mesa, admitir que não temos certeza sobre nenhum problema. Podemos ter 50% de certeza, mas para testar a hipótese, precisamos de dois dias. Então, por que simplesmente não testamos a hipótese? Podemos ter 90% de certeza de que o produto decolará, mas precisamos de oito meses para implementá-lo e testar a hipótese. Vamos apenas dar uma olhada? Ou talvez pensemos em como reduzir a incerteza para 90 ou 100%?

Esta é a primeira maneira. É necessário pendurar um distintivo nessa incerteza, dizer quão grande ou pequeno é, quanto trabalho é necessário para resolvê-lo, etc.

A segunda maneira pela qual a humanidade trabalha há 500 anos é o método científico. Não é perfeito, possui seus próprios bugs, mas esse é o melhor mecanismo que temos no momento. O método científico diz: para resolver a incerteza, primeiro adivinhamos, apresentamos uma hipótese baseada em nossas conclusões, depois pensemos em um experimento que confirmará ou refutará essa hipótese, depois execute um experimento, olhe os números e entenda se nossa hipótese é verdadeira.



No desenvolvimento, especialmente no front-end, temos uma oportunidade única de executar esses experimentos a uma velocidade muito alta. Este método é chamado de prototipagem. Protótipo é uma maneira de lidar com a incerteza. Isso não é uma invenção do produto, não é a criação de algo ideal que os usuários usarão. Esta é uma oportunidade para aprender mais sobre o mundo ao nosso redor. Aprendemos isso criando ilusões. O protótipo é uma ilusão, não um produto. É como se estivéssemos construindo o cenário no palco do teatro ou no palco para fazer filmes. Isso é apenas uma ilusão. O objetivo é reduzir a incerteza.

A prototipagem funciona em dois contextos: no contexto da implementação, quando não sabemos teoricamente do ponto de vista da API, é possível ou não, e no contexto do produto, quando não sabemos qual problema o usuário tem e como resolvê-lo. A criação de protótipos não funciona realmente em pesquisas de mercado - o Excel existe para isso.

O ponto é que, quando trabalhamos em um protótipo, precisamos abandonar a maneira de pensar como especialistas. Precisamos esquecer esses padrões de programação, precisamos esquecer como fabricamos produtos ideais - porque não fazemos. Estamos tentando iniciar a pesquisa, estamos nos tornando cientistas.



Assim, em vez de pensar nas arquiteturas, precisamos encontrar uma maneira de iterar muito rapidamente. Em vez de se aproximar e pensar no futuro, você precisa pensar em como fazê-lo agora, em pouco tempo.

Em vez de pensar em sua reputação, sobre o que acontecerá se eu disser que tenho certeza ou não ... Em vez disso, preciso abandonar minha reputação e me tornar recém-chegado. Burro. Como fazemos isso? Que coisas específicas podemos aplicar para nos tornarmos novatos?



O primeiro e mais importante ponto é o feedback. Mesmo antes de planejar nosso protótipo, desenhar um layout ou algo mais, pensamos em quem mostraremos esses modelos ou protótipo, como testaremos o produto e o que estamos tentando obter com esse experimento. Quanto mais curto esse ciclo de feedback, melhor para nós.

Um exemplo da vida pessoal. A Productive Mobile é a empresa em que trabalhei recentemente, uma startup que criou uma plataforma que permite que você crie um aplicativo móvel a partir de um website de maneira que você arraste e solte. Nós o vendemos para grandes corporações porque eles têm produtos como SharePoint ou SAP que não podem ser usados ​​em um telefone celular, pitada de zoom, só isso. Oferecemos a eles uma opção: você pode criar um aplicativo móvel com base em um site real, digamos, em uma semana. O problema é que tínhamos uma equipe de desenvolvimento muito forte e um ciclo de vendas muito longo. Quando você vende um produto de uma empresa do tamanho da Daimler ou BMW, o ciclo de vendas é de no mínimo 8 meses. Durante esse período, uma equipe de desenvolvedores talentosos pode registrar muito.

O que fizemos e o que nos ajudou? Criamos uma mini equipe de usuários em nossa empresa que usaram o produto. E o número de recursos que começamos a fazer e lançar diminuiu. Mas, ao mesmo tempo, a qualidade dos recursos aumentou n vezes. E quando chegamos ao nosso usuário e dissemos que tínhamos tal e qual plataforma, vamos tentar, por alguma razão, situações de emergência pararam quando éramos assim: não pensamos nisso, isso é algo novo. Começamos a criar recursos que realmente começaram a trazer resultados. Isso se deve ao fato de termos simplesmente reduzido o ciclo de feedback.

Um exemplo com um metrônomo, o projeto Polychops no qual estou trabalhando agora. Primeiro, criamos um vídeo em pouco tempo, que publicamos em algum lugar na Internet. Nele, perguntamos como você gosta desse conceito, o que você acha dele. De acordo com as avaliações, não apenas apreciamos o quanto isso é interessante. Ainda temos leads com os quais poderíamos conversar, com quem poderíamos convidar para ligações, entrevistas, experimentar um protótipo etc.

Tentamos obter feedback muito cedo. E não apenas qualquer feedback, mas qualitativo, não quantitativo.



Qual a diferença? O feedback quantitativo é um teste AV, resultados binários, quando a Opção A ou a Opção B. vence. Isso é tudo o que podemos obter dos ciclos quantitativos. É como se estivéssemos em um quarto escuro e nada estivesse visível, mas temos um ponteiro laser. De tempos em tempos, brilhamos nos cantos, destacamos alguns pontos e entendemos o que há neles.

Em vez disso, o que gostaríamos? Um usuário que descreverá esse quarto escuro, que o conhece muito melhor que nós. Precisamos de entrevistas, chamadas de alta qualidade, algo mais para receber informações dos usuários de forma expandida.



Um exemplo de empresa que depende muito de feedback quantitativo é o Booking.com. Na minha opinião, há algo para trabalhar em seu site.

Um dos protótipos do projeto em que estou trabalhando é um recurso com o qual uma pessoa pode gravar a si mesma e, ao mesmo tempo, reproduzir por si mesma como tocou no metrônomo - bom ou ruim. Inventamos esse recurso porque solicitamos feedback de qualidade das pessoas que testaram o protótipo. Uma das pessoas escreveu que está tudo ótimo, eu gosto da parte do metrônomo, mas seria legal exportar essa faixa com o metrônomo como uma faixa de áudio. Nós somos assim - é ilógico, por quê? Ele diz: "Insiro isso no meu programa para trabalhar com música, depois me escrevo e posso ouvir se entro no ritmo ou não." Nós somos assim - é brilhante.

Mas, em vez de apenas exportar, decidimos testar a hipótese. Conversamos com as pessoas, perguntamos se elas se ouviam quando brincavam com o metrônomo. Muitos disseram que sim, geralmente temos um programa - um metrônomo, outro programa - um gravador de voz no telefone ou em outro lugar, apenas gravamos e ouvimos a nós mesmos. Somos assim - somos programadores, podemos combinar isso em uma aplicação. Como resultado, obtivemos esse recurso. Nós nunca teríamos adivinhado se tivéssemos feito o teste AV.



A parte mais importante do protótipo é a interface. Em um sentido global. Se tivermos algum tipo de serviço com algum tipo de API, nossa interface é uma API, com a qual o usuário interage. Se estamos trabalhando em um metrônomo, nossa interface é a parte visual e o som. Se estamos apenas trabalhando em um aplicativo móvel, nossa interface é uma interface visual. No protótipo, a interface é a única parte importante. Tudo o mais que podemos falsificar, substitua por pelúcia.

Outro exemplo do Mobile produtivo. Em algum momento, decidimos reescrever a API interna neste editor de aplicativos móveis para arrastar e soltar. A API permite que o JS revive algumas partes complexas do seu aplicativo móvel. Como gerente de produto, eu poderia escrever uma especificação e fornecê-la aos desenvolvedores. Estou certo de que, no máximo, um mês estaria tudo pronto, testado e maravilhoso. Mas decidimos tentar um caminho diferente. Acabamos de documentar a API que tínhamos em mente, no papel e entregá-lo para as pessoas que estavam criando aplicativos móveis. Eles perguntaram: se você tivesse essa API, como construiria seus aplicativos em teoria?

Eles pegaram outro papel, verificaram tudo. Sem implementação. A API não funcionou nesta fase. Então, fizemos de 5 a 10 iterações antes de percebermos qual deveria ser a forma da API. Economizamos muito tempo para implementação. Depois de entendermos o formulário, documentamos a especificação e a implementamos. Tudo se tornou maravilhoso.



Outro exemplo do metrônomo. A primeira idéia para Polychops é um metrônomo para trabalhar com polirritmos. Fizemos o primeiro protótipo em cerca de 20 minutos, escreveu no Flash. Era assim que ele parecia. Houve até um som. Nós apenas fomos e mostramos a outros músicos, perguntamos - como você gosta? Esta é a única coisa importante.



Então fizemos um metrônomo real no navegador, funcionou, animação, blá, blá, tudo é lindo.


Mas demorou cerca de um mês e meio, e o protótipo anterior levou 20 minutos.

Concentre-se na interface.



Para economizar tempo, use um sistema de design. Um exemplo rápido de Polychops.



À esquerda, está o protótipo inicial, onde apenas todos os botões pensamos em toda a interação. Depois de algum tempo, decidimos que precisávamos de um menu, navegação, menus suspensos, algo mais. Poderíamos sentar e refletir com os designers a cada menu suspenso, a cada botão, mas isso é uma quantidade enorme de tempo, o que, em princípio, não precisamos gastar. Portanto, pegamos o sistema de design acabado, pegamos o design do material, eles têm tudo perfeitamente documentado. Ferrou, está tudo bem.



Roubar. Não roube dos concorrentes. Não faz sentido roubar dos concorrentes. Se algo funcionar para os concorrentes, você não precisa verificar, basta copiá-lo. Roube produtos paralelos aos seus, que não são exatamente o seu produto, mas algo semelhante.



Outro exemplo de Polychops. A interface de gravação é praticamente lambida de programas de som existentes, como o Logic. Naturalmente, simplificamos bastante, mas as pessoas já entendem como usar o Logic, o que significa que podem entender como usar o Polychops.

. , . .



: , . , , .



, , . , , . , , , , , . .



— . , , . , .



, , — . . , React . React, React. , , , Redux Apollo, . . .



— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .



, , . . , . — , , .

, . , . . , . . . — , . , .

? « ?» — , . ?



. , . . 10% , , 10%, , — .

. , 90% , . , , 10%. — , . .

, . Productive Mobile , . , , - , .

. React, — React Native. , , — React, React Native. - : «, React Native, , ». .

? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .

, , … ?

Polychops - , . , , , , , . - , , . . .

Espero que você tente você mesmo. Talvez você não trabalhe em uma startup, mas sua empresa possui projetos nos quais há incerteza. É importante para mim que você pense sobre isso, converse com sua equipe, com seus gerentes, pense em como trabalhar com incerteza, como construir seus processos, para que o processo de tomada de decisão melhore, para que você pare de perder tempo com coisas que não são necessárias.

Se você obtiver sucesso e criar um ótimo produto, espero que em algum momento eu seja um dos seus usuários muito felizes. Obrigada