Что это означает для разработчиков, дизайнеров и менеджеров проектов?

Я думаю, что это зависит от команды. И что мы чаще всего видим в Webflow, так это то, что для разработчиков — даже несмотря на то, что концептуально многие люди думают, что мы пытаемся лишить разработчиков работы, верно? Но на самом деле, что происходит, так это то, что мы пытаемся автоматизировать те вещи, которые наиболее поддаются автоматизации — поэтому разработчики в восторге, потому что теперь они могут работать над сложными вещами, над действительно интересными проблемами.

Для дизайнеров это делает их героями. Это суперсила, верно? Потому что теперь они выполняют работу двух человек. И они чувствуют себя более творческими!

Проектовые менеджеры также могут действовать быстрее. Они могут быстрее проверять идеи. Они могут быстрее тестировать вещи. Они могут в большей степени полагаться на своих дизайнеров и этап исследования, в отличие от ожидания, которое происходит в классической водопадной модели, когда вы что-то проектируете, а затем должны ждать, пока разработчики это реализуют, или вам приходится создавать прототип в коде, а затем каким-то образом представлять его пользователям.

Часто все начинается с операционной стороны компании. Эти люди, возможно, нанимают множество инженеров, но эти инженеры часто занимаются разработкой основного продукта, который они создают. Это похоже на: «Эй, наша работа — создать этот продукт мирового класса X. И именно на X мы хотим тратить все свое время». Однако для ведения бизнеса нам нужны все эти другие вещи. Нам нужна CRM. Нам нужен инструмент для выставления счетов. Нам нужен электронный маркетинг. Нам нужно управление проектами. Нам нужны все эти другие вещи, и наши инженеры часто не помогают сделать так, чтобы все это лучше работало вместе.

Инженеры сосредоточены на действительно сложной задаче по доставке продукта конечным потребителям. И поэтому в деловой стороне бизнеса часто начинают участвовать специалисты по операционной деятельности, которые внедряют стек без кода и повышают эффективность, делают так, чтобы каждый продавец стал немного лучше выполнять свою работу, чтобы то, что раньше занимало весь день или всю неделю, теперь происходило мгновенно.

UX-дизайнеры имеют самые большие возможности, потому что они могут преодолеть следующий разрыв: я разработал дизайн, но теперь нужно отправить его кому-то другому для реализации или отправить этот дизайн кому-то другому для реализации. Они могут замкнуть этот круг и практически начать более комплексный дизайн-бизнес или дизайн-практику, имея доступ к этим инструментам без кода. Между принципом работы инструментов программного обеспечения без кода и принципом работы инструментов программного обеспечения для дизайна есть так много сходств, что, на мой взгляд, дизайнеры очень быстро осваивают их.

Для разработчиков, я думаю, это отличная вещь. Они не будут тратить время на проекты, которые не работают. Люди должны быть более уверены в том, что они пытаются создать, прежде чем обращаться к разработчику. Кроме того, 25% нашего сообщества составляют разработчики, которые рассматривают no-code как способ быстро запустить и проверить свои собственные идеи.

Дизайнеры могут реально создавать вещи, а не просто говорить, как они должны выглядеть. Им больше не нужно убеждать разработчиков создавать что-то.

Я считаю, что это позволит разработчикам сосредоточиться на создании ключевых технологий, которые приносят реальные результаты, и в некотором смысле освободит их. Когда я был инженером, мне часто хотелось создавать продукты, и я знал, что владелец бизнеса должен будет вернуться. Для этого разработчики должны рассматривать проблемы в более широком контексте, с большей детализацией. Я считаю, что это позволит им создавать гораздо более качественное программное обеспечение.

Я считаю, что это позволит дизайнерам сосредоточиться больше на самом контенте, а не на эстетике и макете. Поэтому вместо того, чтобы пытаться понять, как смешивать и сочетать части пазла, я как дизайнер сейчас больше заинтересован в том, чтобы создать реальный вид пазла, а не пытаться вписать его в ограничения платформы.

Я считаю, что проектные менеджеры и владельцы продуктов всегда являются людьми, которые жонглируют приоритетами, выясняя, как распределить ресурсы, чтобы как можно больше основных платформ было реализовано без использования кода, что позволит им сосредоточиться на приоритезации функций и сборок, которые помогают повысить выручку и прибыль, а не просто на инициативах типа «Эй, мы должны остаться на плаву».

Я думаю, что разработчики всегда говорили о том, что им очень нравится создавать многократно используемую функциональность общего назначения, которая может быть использована для множества различных вещей. Поэтому большинство разработчиков, которых я знаю и которые действительно квалифицированы, предпочтут написать компонент общего назначения, который можно использовать повторно, или библиотеку с открытым исходным кодом, или что-то в этом роде, в отличие от написания этой единственной вещи, которая будет использована только один раз. Я думаю, что использование навыков разработчиков для создания многократно используемой функциональности, которая затем может быть подключена и применена поверх чего-то вроде Adalo, обеспечивающего базовую стандартную функциональность, - это действительно лучшее из двух миров.

Для дизайнеров произойдет некоторый сдвиг, когда границы между начальными этапами проектирования будут размыты - от этапа проектирования до прототипа, от разработки с разработчиками до производства. Если то, что я описал с компонентами, действительно станет реальностью, то системы проектирования в сочетании с инструментами "без кода" будут означать, что дизайнеры смогут создавать продукт в базовой степени, а затем подключать к нему то, что создают разработчики.

Для менеджеров по персоналу больше не нужно спрашивать разрешения, они могут просто пойти и построить что-то самостоятельно, а затем сказать: "Эй, дизайнер, помоги мне исправить эту вещь". Вместо того чтобы идти по традиционному каналу - я хочу создать продукт, мне нужно пригласить дизайнера, пригласить разработчика, получить разрешение босса на этот проект. Они могут просто построить его сами за выходные, а затем показать его. Это полностью изменит то, как быстро могут двигаться организации, потому что часто одна из вещей, которая больше всего тормозит людей, - это зависимость внутри организации и доступность ресурсов.

Я знаю, что многие люди, занимающие эти должности, могут сначала задаться вопросом: «Не потеряю ли я работу из-за этих платформ?». Я так не думаю — платформы без кода появляются из-за нехватки программистов, дизайнеров и менеджеров по продуктам, а все хотят создавать что-то новое. Я не думаю, что эти должности исчезнут — я думаю, что люди, занимающие эти должности, всегда будут необходимы для создания чего-то действительно великого, но они могут не понадобиться для создания чего-то базового. Будущее без кода — это предоставление разработчикам и дизайнерам возможности сосредоточиться на том, в чем они хороши, и не беспокоиться о том, что не стоит их времени.

Кроме того, в мире без кода вы получаете настоящее сотрудничество, позволяющее командам избежать большей части работы по «очереди заданий» и просто выполнять работу самостоятельно. В большинстве компаний-разработчиков программного обеспечения 98 % сотрудников просто составляют очередь заданий для инженеров. Например, если вы занимаетесь дизайном, вы в конечном итоге создаете истории и спецификации, которые попадают в трекер для реализации инженером. Это очень неэффективно — почему бы просто не реализовать изменения в дизайне самостоятельно? Настоящее сотрудничество означает совместное создание. Я думаю, что инструменты без кода и с минимальным кодом позволяют нам всем действительно работать вместе.

С точки зрения разработчиков, я считаю, что это ускоряет все процессы, и в многих отношениях no-code — это отправная точка для достижения какой-то цели. Это не обязательно означает, что это будет ваш конечный продукт. Но создать эту структуру будет настолько быстрее, что вы сможете больше играть, больше делать и, возможно, попробовать то, что в противном случае заняло бы очень много времени, чтобы научиться.

Я думаю, что для дизайнеров no-code стал невероятно вдохновляющим движением. Например, я сам имею опыт работы в сфере дизайна и мне нравилось создавать красивые и комплексные дизайны на своем компьютере, но они не дышали. Есть что-то особенное в том, чтобы видеть, как эти движения, как фактические взаимодействия происходят, и иногда бывает обидно, когда у тебя есть что-то, но ты не можешь полностью это передать или остаешься позади, когда пытаешься воплотить это в жизнь. Поэтому я думаю, что инструменты без кода действительно дали дизайнерам огромные возможности, когда речь идет о том, чтобы оживить многое из того, что они делают, создать веб-сайты, веб-приложения, торговые площадки; они сделали так много.

С помощью PM или нетехнических членов команды это не только открыло для них больше возможностей для воплощения MVP в жизнь и практического опыта, но и помогло им развить эмпатию по отношению к другим членам команды. Лично я считаю, что, погрузившись в инструменты без кода, я действительно больше узнал о логике, ожиданиях и сложностях, стоящих за тем, о чем я прошу, что, по моему мнению, сделало меня более эмпатичным как лидера, а также в плане того, как я управляю или ожидаю того, что может быть достигнуто в рамках задачи.

Продукт-менеджер, которому явно нужно что-то от разработчика или дизайнера, может самостоятельно выполнить ряд задач. Любой из сотрудников, которые технически не должны вносить эти изменения, может их внести.

[Бен] Я думаю, что это действительно зависит от руководства в каждом конкретном случае. Я думаю, что многие разработчики видят в этом преимущество. [Я слышу такие вещи, как] «Я просто хочу, чтобы вы знали, я нашел Webflow, и, о боже, что он для меня сделал! Вместо того, чтобы тратить все это время на работу над микроинтерактивными элементами, я могу вернуться к тому, что происходит на бэкэнде, и уделить этому больше времени».

То же самое касается дизайнеров и менеджеров проектов. Дизайнер не просто показывает вам макет в Figma или Sketch, а фактически демонстрирует: «Посмотрите, как выглядит это микро-взаимодействие» или «Посмотрите, как это работает», то есть вы можете пройтись по всему приложению и ознакомиться со всем его функционалом. Я просто думаю, что это поможет всем: разработчикам, дизайнерам, менеджерам проектов. Я считаю, что это играет действительно большую роль. Я уже вижу, как это работает. И я думаю, что это будет продолжаться и в дальнейшем.