Qu'est-ce que cela signifie pour les développeurs, les concepteurs et les gestionnaires de projets ?
Je pense que c'est un gradient, selon l'équipe. Et ce que nous voyons le plus chez Webflow, c'est que pour les développeurs - même si conceptuellement beaucoup de gens pensent que nous essayons de faire en sorte que les développeurs n'aient plus de travail, d'accord. Mais en réalité, ce qui se passe, c'est que nous essayons d'automatiser les choses qui sont les plus susceptibles d'être automatisées - donc pour les développeurs, ils sont ravis parce qu'ils peuvent travailler sur les choses difficiles sur les problèmes vraiment intéressants maintenant.
Pour les designers, cela fait d'eux des héros. C'est un super pouvoir, non ? Parce qu'ils font le travail de deux personnes maintenant. Et ils se sentent plus créatifs !
Les chefs de projet peuvent également agir plus rapidement. Ils peuvent valider les idées plus tôt. Ils peuvent tester les choses à la vapeur plus rapidement. Ils peuvent s'appuyer sur leurs concepteurs et sur la phase de recherche, beaucoup plus que l'attente qui se produit dans le cas de la cascade classique où vous concevez quelque chose et vous devez ensuite attendre que le dev aille le mettre en œuvre, ou vous devez le prototyper dans le code et ensuite le présenter d'une manière ou d'une autre aux utilisateurs.
Souvent, ça commence du côté opérationnel de la maison. Ce sont ces gens qui, peut-être, ont un tas d'ingénieurs qui sont embauchés, mais ces ingénieurs sont souvent déployés contre le produit primaire qu'ils construisent. C'est comme "Hey, notre travail est de construire ce x de classe mondiale. Et ce x est vraiment ce sur quoi nous voulons passer tout notre temps." Cependant, pour faire fonctionner l'entreprise, nous avons besoin de toutes ces autres choses. Nous avons besoin d'un CRM. Nous avons besoin d'un outil de facturation. Nous avons besoin de marketing par e-mail. Nous avons besoin d'une gestion de projet. Nous avons besoin de toutes ces autres choses, et nos ingénieurs ne nous aident pas souvent à faire en sorte que tout cela fonctionne mieux ensemble.
Les ingénieurs se concentrent sur le problème vraiment difficile de la livraison d'un produit aux clients finaux. Et c'est donc souvent dans le cadre de la gestion de l'aspect commercial des choses que les responsables des opérations commencent à intervenir et à déployer une pile sans code pour rendre les choses plus efficaces, faire en sorte que chaque vendeur soit un peu plus compétent dans son travail, faire en sorte que cette chose qui prenait toute la journée ou toute la semaine se produise instantanément.
Les designers UX ont la plus grande opportunité, parce qu'ils sont capables de combler ce fossé : Je l'ai conçu, mais maintenant vous devez envoyer quelqu'un d'autre pour le construire ou envoyer ce design à quelqu'un d'autre pour le construire. Ils sont en mesure de boucler cette boucle et de créer des entreprises ou des pratiques de conception plus complètes en ayant accès à ces outils sans code. Il y a tellement de similitudes entre le fonctionnement d'un outil logiciel sans code et celui des outils logiciels de conception que les concepteurs les assimilent très vite.
Pour les développeurs, je pense que c'est une excellente chose. Ils ne perdront pas leur temps sur des projets qui ne fonctionnent pas. Les gens devraient avoir plus de conviction autour de la chose qu'ils essaient de construire avant de parler au développeur. En outre, 25 % de notre communauté sont des développeurs qui considèrent le no-code comme un moyen de lancer et de valider rapidement leurs propres idées.
Les concepteurs peuvent désormais construire des objets plutôt que de se contenter de dire à quoi ils doivent ressembler. Ils n'ont plus à convaincre les développeurs de construire des choses.
Pour les développeurs, je pense que cela va leur permettre de se concentrer sur la création de technologies de base qui font avancer les choses et de se libérer en quelque sorte. Souvent, lorsque j'étais ingénieur, je voulais créer des produits ou je savais que le propriétaire de l'entreprise devrait revenir. Pour ce faire, les développeurs doivent envisager les problèmes de manière beaucoup plus large ou à plus grande échelle, avec une meilleure granularité. Je pense que cela rendra les logiciels qu'ils créent bien meilleurs.
Pour les concepteurs, je pense que cela va leur permettre de se concentrer davantage sur le contenu lui-même plutôt que sur l'esthétique et la mise en page. Ainsi, au lieu d'essayer de trouver comment mélanger et assortir les pièces d'un puzzle, je suis plus intéressé, en tant que concepteur, par la création de l'aspect réel du puzzle que par la tentative de le faire tenir ensemble dans le cadre des contraintes de la plate-forme.
Je pense que les chefs de projet et les propriétaires de produits sont toujours les personnes qui jonglent avec les priorités, qui déterminent comment allouer les ressources pour que la plus grande partie des plates-formes de base soit réalisée sans code, ce qui leur permettra de se concentrer sur les fonctionnalités et les constructions prioritaires qui aident à faire progresser le chiffre d'affaires et le résultat net, et pas seulement les initiatives du type " Hé, nous devons rester à flot ".
Je pense que la chose dont j'ai toujours parlé avec les développeurs, c'est que les développeurs aiment vraiment construire des fonctionnalités qui sont réutilisables, et à usage général, et qui peuvent être utilisées pour beaucoup de choses différentes. Ainsi, la plupart des développeurs que je connais et qui sont vraiment compétents, préfèrent écrire un composant à usage général qui peut être réutilisé quelque part, ou une bibliothèque open source ou quelque chose comme ça, plutôt que d'écrire cette chose unique qui ne sera utilisée qu'une seule fois. Je pense que le fait de tirer parti des compétences des développeurs pour créer des fonctionnalités réutilisables qui peuvent ensuite être ajoutées et appliquées à quelque chose comme Adalo, qui fournit la fonctionnalité standard de base, est vraiment le meilleur des deux mondes.
Pour les concepteurs, il va y avoir une sorte de changement où les lignes s'estompent entre les phases initiales de conception - comme la phase de conception jusqu'au prototype, jusqu'au développement avec les développeurs, jusqu'à la production. Si ce que je décrivais avec les composants devient vraiment une réalité, alors les systèmes de conception combinés aux outils no-code signifieront que les concepteurs pourront réellement construire le produit dans une certaine mesure, et ensuite brancher les choses que les développeurs construisent.
Pour les chefs de projet, ils n'auront plus à demander la permission, ils pourront simplement aller construire quelque chose eux-mêmes et ensuite dire, hey, le concepteur m'aide à réparer cette chose. Plutôt que de devoir passer par le canal traditionnel - je veux construire un produit, je dois faire appel à un designer, à un développeur, à mon patron pour autoriser ce projet. Ils peuvent juste aller le construire eux-mêmes en un week-end et ensuite le montrer. Cela va totalement transformer la vitesse à laquelle les organisations peuvent évoluer, car souvent, l'une des choses qui ralentissent le plus les gens, ce sont les dépendances au sein d'une organisation et la disponibilité des ressources.
Je sais que beaucoup de personnes dans ces rôles pourraient commencer par se demander : "Vais-je perdre mon emploi à cause de ces plateformes ?". Je ne le pense pas. Les plates-formes sans code sont apparues parce qu'il y a une telle pénurie d'ingénieurs en logiciels, de concepteurs et de chefs de produit, et que tout le monde veut construire. Je ne pense pas que ces rôles vont disparaître - je pense que les personnes occupant ces rôles seront toujours nécessaires pour construire quelque chose de vraiment génial, mais qu'elles ne seront peut-être pas nécessaires pour construire quelque chose de basique. L'avenir du no code est de permettre aux développeurs et aux concepteurs de se concentrer sur ce qu'ils savent faire et de ne pas s'inquiéter de ce qui ne vaut pas la peine de leur consacrer du temps.
De plus, ce que vous obtenez en réalité avec le monde du no-code, c'est une véritable collaboration, qui permet aux équipes d'éviter une grande partie du travail de "mise en file d'attente" et de faire le travail elles-mêmes directement. Dans la plupart des entreprises de logiciels, 98 % des personnes de l'organisation ne font que mettre en file d'attente le travail à réaliser par les ingénieurs. Par exemple, si vous faites du travail de conception, vous finissez par créer des histoires et des spécifications, et cela va simplement dans un tracker pour qu'un ingénieur le mette en œuvre. C'est tellement inefficace - pourquoi ne pas simplement mettre en œuvre les changements de conception vous-même ? Une véritable collaboration signifie construire ensemble. Je pense que les outils no-code et low-code nous permettent à tous de travailler ensemble.
En ce qui concerne les développeurs, je pense que cela accélère tout et que le no-code, de bien des façons, est le point de départ pour essayer de faire quelque chose. Cela ne signifie pas nécessairement que ce sera le produit final que vous ferez. Mais il sera tellement plus rapide de mettre cette structure en place que vous pourrez jouer davantage, faire davantage, et peut-être essayer cette chose qui aurait autrement pris beaucoup de temps à apprendre.
Avec les designers, je pense que le no-code a été un mouvement incroyablement responsabilisant pour eux. Par exemple, moi-même, je viens d'un milieu de conception et j'ai adoré pouvoir faire ces dessins magnifiquement complets sur mon ordinateur, mais ils ne respiraient pas. Il y a quelque chose d'un peu spécial à voir comment ces mouvements, comment les interactions réelles se jouent, et ça craint parfois d'avoir cette chose et de ne pas être capable de la communiquer complètement ou d'être un peu laissé derrière quand vous essayez de lui donner vie. Je pense donc que les outils no-code ont permis aux concepteurs de se surpasser lorsqu'il s'agit d'animer beaucoup de choses qu'ils font, de les faire vivre, de créer des sites Web, des applications Web, des places de marché ; il y a tant de choses qu'ils ont faites.
Avec les chefs de projet, ou les membres non techniques des équipes, cela a totalement ouvert la voie non seulement à de nouveaux moyens de donner vie aux MVPs, de se salir les mains, mais aussi de développer de l'empathie envers les autres membres de leur équipe. Personnellement, je trouve qu'en me plongeant dans les outils no-code, j'en ai appris davantage sur la logique, les attentes et les complexités derrière ce que je demande, ce qui m'a rendu, je crois, plus empathique en tant que leader, mais aussi en termes de gestion ou d'attente de ce qui peut être accompli dans le champ d'application.
Le gestionnaire de projet qui a manifestement besoin de quelque chose de la part du développeur ou du concepteur pourrait être en mesure de cocher un certain nombre de tâches à accomplir par lui-même. Toutes les personnes qui ne sont pas techniquement censées effectuer ces changements pourraient le faire.
[Je pense que cela dépend vraiment de la direction de l'espace à l'espace. Je pense qu'il y a beaucoup de développeurs qui y voient un avantage. [J'entends des choses comme] "Je veux juste que vous sachiez, j'ai trouvé Webflow, et oh mon dieu, comme ce qu'il a fait pour moi, au lieu d'avoir à passer tout ce temps à travailler sur les micro interactions, je peux en fait revenir à ce qui se passe sur le back-end et y passer plus de temps."
C'est la même chose pour les concepteurs et les chefs de projet. Un concepteur ne peut pas se contenter de vous montrer une maquette Figma ou Sketch, mais il peut vous montrer " regardez à quoi ressemble cette micro-interaction " ou " regardez comment cela s'écoule ", par exemple, vous pouvez cliquer sur cette application et parcourir tout le flux de l'application. Je pense simplement que cela va aider les gens autour des développeurs, des concepteurs, des PM, je pense que cela joue un rôle très important. Je peux déjà le voir faire ça. Et je pense que ça va continuer à faire ce genre de choses.
