O que isso significa para os desenvolvedores, designers e PMs?
Acho que é um gradiente, dependendo da equipe. E o que mais vemos na Webflow é que para os desenvolvedores - embora conceitualmente muitas pessoas pensem que estamos tentando trabalhar com desenvolvedores fora do trabalho, certo. Mas na verdade, o que está acontecendo é que estamos tentando automatizar as coisas que são mais propensas à automação - por isso, para os desenvolvedores, eles estão entusiasmados porque agora começam a trabalhar nas coisas difíceis sobre os problemas realmente interessantes.
Para os projetistas, isso faz deles os heróis. É uma superpotência, certo? Porque eles estão fazendo o trabalho de duas pessoas agora. E eles estão se sentindo mais criativos!
Para os PMs, eles também podem se mover mais rápido. Eles podem validar as idéias mais cedo. Eles podem testar as coisas com vapor mais rápido. Eles podem confiar em seus projetistas e na fase de pesquisa, muito mais ao contrário da espera que acontece com a clássica cachoeira onde você projeta algo e depois tem que esperar que o Dev o implemente, ou você tem que fazer um protótipo em código e depois, de alguma forma, apresentá-lo aos usuários.
Muitas vezes, isso começa na área operacional da empresa. São essas pessoas que, talvez, tenham contratado vários engenheiros, mas esses engenheiros são frequentemente alocados para trabalhar no produto principal que estão desenvolvendo. É como se dissessem: “Ei, nosso trabalho é construir esse x de classe mundial. E esse x é realmente aquilo em que queremos dedicar todo o nosso tempo”. No entanto, para administrar o negócio, precisamos de todas essas outras coisas. Precisamos de um CRM. Precisamos de uma ferramenta de faturamento. Precisamos de marketing por e-mail. Precisamos de gerenciamento de projetos. Precisamos de todas essas outras coisas, e nossos engenheiros nem sempre ajudam a fazer com que tudo funcione melhor em conjunto.
Os engenheiros estão focados no problema realmente difícil de entregar um produto aos clientes finais. E é aí que o lado comercial da empresa entra em cena, com a equipe de operações começando a implantar uma pilha sem código para tornar as coisas mais eficientes, fazer com que cada vendedor seja um pouco melhor no seu trabalho e fazer com que aquilo que antes levava um dia ou uma semana inteira aconteça instantaneamente.
Os designers de UX têm a maior oportunidade, porque são capazes de preencher essa lacuna: eu projetei, mas agora você precisa enviar alguém para construí-lo ou enviar esse projeto para outra pessoa construir. Eles são capazes de fechar esse ciclo e quase iniciar negócios de design mais abrangentes ou práticas de design, tendo acesso a essas ferramentas sem código. Há tanta semelhança entre o funcionamento de uma ferramenta de software sem código e o funcionamento de ferramentas de software de design que acho que os designers aprendem muito rápido.
Para os desenvolvedores, acho que é ótimo para eles. Não vão perder tempo com projetos que não funcionam. As pessoas devem ter mais convicção sobre o que estão tentando construir antes de falar com o desenvolvedor. Além disso, 25% da nossa comunidade é composta por desenvolvedores que veem o no-code como uma forma de lançar e validar rapidamente suas próprias ideias.
Para os designers, eles podem realmente construir coisas, em vez de apenas dizer como elas devem ficar. Eles não precisam mais convencer os desenvolvedores a construir coisas.
Para os desenvolvedores, acredito que isso permitirá que eles se concentrem na criação de uma tecnologia essencial que mova a agulha e se libertem. Muitas vezes, quando eu era engenheiro, queria criar produtos ou sabia que o proprietário da empresa teria que voltar. Portanto, para fazer isso, os desenvolvedores precisam pensar nos problemas como algo muito maior ou em uma escala maior, com melhor granularidade. Acredito que isso tornará o software que eles criam muito melhor.
Para os designers, acredito que isso permitirá que eles se concentrem mais no conteúdo em si do que na estética e no layout. Portanto, em vez de tentar descobrir como misturar e combinar peças de um quebra-cabeça, estou mais interessado agora, como designer, em criar a aparência real do quebra-cabeça em vez de tentar fazer com que tudo se encaixe dentro das restrições da plataforma.
Acredito que os gerentes de projeto e os proprietários de produtos são sempre as pessoas que fazem malabarismos com as prioridades, descobrindo como alocar recursos para que o máximo de plataformas principais seja feito de forma não codificada, o que permitirá que eles se concentrem na priorização de recursos e construções que ajudem a movimentar os resultados financeiros e financeiros, e não apenas nas iniciativas do tipo "Temos que nos manter à tona".
Acho que o que sempre conversei com os desenvolvedores é que eles realmente gostam de criar funcionalidades reutilizáveis, de uso geral e que possam ser usadas para muitas coisas diferentes. Portanto, a maioria dos desenvolvedores que conheço e que são realmente habilidosos prefere escrever um componente de uso geral que possa ser reutilizado em algum lugar, ou uma biblioteca de código aberto ou algo parecido, em vez de escrever algo que só será usado aqui uma vez. Acho que realmente aproveitar as habilidades dos desenvolvedores para criar funcionalidades reutilizáveis que possam ser conectadas e aplicadas em algo como o Adalo, que fornece a funcionalidade padrão básica, é realmente o melhor dos dois mundos.
Para os designers, haverá uma mudança em que as linhas entre as fases iniciais do design — como a fase de design até o protótipo, passando pelo desenvolvimento com os desenvolvedores, até a produção — ficarão um pouco mais difusas. Se o que eu descrevi com os componentes realmente se tornar realidade, então os sistemas de design combinados com ferramentas sem código significarão que os designers poderão realmente construir o produto em um nível básico e, em seguida, conectar as coisas que os desenvolvedores estão construindo.
Os gerentes de produto não precisarão mais pedir permissão, eles podem simplesmente criar algo por conta própria e depois pedir ajuda ao designer para ajustar o produto. Em vez de seguir o caminho tradicional — eu quero criar um produto, preciso contratar um designer, contratar um desenvolvedor, obter a autorização do meu chefe para este projeto —, eles podem simplesmente criar o produto por conta própria em um fim de semana e depois apresentá-lo. Isso vai transformar totalmente a velocidade com que as organizações podem agir, porque muitas vezes uma das coisas que mais atrasa as pessoas são as dependências dentro de uma organização e a disponibilidade de recursos.
Sei que muitas pessoas nessas funções podem começar perguntando: “Vou perder meu emprego por causa dessas plataformas?”. Não acredito que isso vá acontecer — as plataformas sem código estão surgindo porque há uma grande escassez de engenheiros de software, designers e gerentes de produto — e todos querem criar. Não acho que essas funções vão desaparecer — acho que as pessoas nessas funções sempre serão necessárias para criar algo realmente incrível, mas talvez não sejam necessárias para criar algo básico. O futuro do no-code é capacitar desenvolvedores e designers para que se concentrem no que fazem de melhor e não se preocupem com coisas que não valem o seu tempo.
Além disso, o que você realmente obtém com o mundo sem código é uma verdadeira colaboração, permitindo que as equipes pulem grande parte do trabalho de “colocar em fila” e simplesmente façam o trabalho diretamente. Na maioria das empresas de software, 98% das pessoas na organização estão apenas colocando em fila o trabalho para os engenheiros concluírem. Por exemplo, se você está fazendo um trabalho de design, acaba criando histórias e especificações, e isso vai para um rastreador para um engenheiro implementar. Isso é muito ineficiente — por que não implementar você mesmo as mudanças no design? Colaboração verdadeira significa construir juntos. Acho que as ferramentas sem código e com pouco código permitem que todos nós realmente trabalhemos juntos.
Em termos de desenvolvedores, penso nisso como uma forma de agilizar tudo e, em muitos aspectos, o no-code é o ponto de partida para tentar fazer algo. Isso não significa necessariamente que será o produto final que você está criando. Mas será muito mais rápido criar essa estrutura, e você poderá brincar mais, fazer mais e talvez experimentar algo que, de outra forma, levaria muito tempo para aprender.
Para os designers, acho que o no-code tem sido um movimento incrivelmente empoderador. No meu caso, por exemplo, tenho formação em design e adorava poder criar designs lindos e completos no meu computador, mas eles não respiravam. Há algo um pouco especial em ver como esses movimentos, como as interações reais funcionam, e às vezes é um pouco chato ter isso e não ser capaz de comunicar totalmente ou ficar para trás quando você está tentando dar vida a isso. Então, acho que as ferramentas sem código realmente deram um impulso aos designers quando se trata de animar muitas das coisas que eles estão fazendo, dar vida a elas, criar sites, aplicativos web, mercados; há tantas coisas que eles fizeram.
Com os gerentes de projeto ou membros não técnicos nas equipes, isso abriu totalmente não apenas mais maneiras para eles darem vida aos MVPs e colocarem a mão na massa, mas também para desenvolverem empatia em relação às outras pessoas da equipe. Pessoalmente, acho que, ao mergulhar nas ferramentas sem código, aprendi mais sobre a lógica, as expectativas e as complexidades por trás do que estou pedindo, o que me tornou, acredito, mais empático como líder, mas também em termos de como gerencio ou espero o que pode ser realizado no escopo.
O gerente de projetos que obviamente precisa de algo do desenvolvedor ou do designer pode ser capaz de verificar várias tarefas por conta própria. Qualquer pessoa que tecnicamente não deveria estar fazendo essas alterações pode fazê-las.
[Penso que isto depende realmente da liderança de espaço em espaço. Acho que há muitos desenvolvedores que vêem a vantagem ali. [Vou ouvir coisas como] "Só quero que você saiba, encontrei o Webflow, e oh meu Deus, como o que é feito por mim, em vez de ter que passar todo este tempo trabalhando em micro interações, posso realmente voltar ao que está acontecendo na parte de trás e passar mais tempo lá".
É o mesmo para os projetistas e PMs também. Para um designer não apenas mostrar uma maquete Figma ou Sketch, mas para realmente mostrar a você, 'veja como é esta micro interação', ou 'veja como isto flui', você pode realmente clicar neste aplicativo e passar por todo o fluxo do aplicativo. Eu só acho que ele vai ajudar as pessoas ao redor dos desenvolvedores, designers, PMs, eu acho que ele desempenha um papel realmente grande. Eu já posso vê-lo fazendo isso. E acho que ele só vai continuar a fazer esse tipo de coisa.
