Самая большая проблема с гибким дизайном (и как её решить)

Разнообразие решений и координации, видимое в документальном фильме, практически невозможно описать — от планирования времени и места съёмки каждого отдельного кадра до координации полёта восемнадцатиметровой анимационной куклы на краю скалы и тщательной проверки каждой детали костюма и создания всех персонажей для грандиозной вечеринки в казино, которую Риан описал как самый сложный кадр в истории Звёздных войн.

Именно здесь современные инструменты разработки приложений изменили игру для команд разработчиков. Платформы вроде Adalo, конструктора приложений без кода для веб-приложений, основанных на базах данных, и нативных приложений iOS и Android — одна версия для всех трёх платформ, опубликованная в Apple App Store и Google Play, — позволяют командам в полной мере внедрять принципы гибкого дизайна. В отличие от кинорежиссёров или архитекторов, которые должны придерживаться одного финального видения, разработчики приложений могут быстро итерировать, тестировать и совершенствовать свои продукты на основе реальной обратной связи от пользователей.

Помимо множества решений, которые Риану пришлось принять, я не мог не восхищаться его уверенностью в своём видении фильма. До того как Последние джедаи вышли в прокат, Марк Хэмилл, исполнивший роль Люка Скайуокера, был полностью против интерпретации Рианом его персонажа— заявив, что он «принципиально не согласен практически со всем, что написано о Люке». И это напряжение пронизывает весь документальный фильм. Но несмотря на попытки Марка изменить его мнение, Риан остался непреклонен. Его общее видение фильма было незыблемо.

И что же общего между впечатляющим предприятием Риана по созданию фильма «Звёздные войны» и гибким дизайном?

Что ж, после просмотра всего процесса проектирования крупного фильма стало совершенно очевидно, насколько этот процесс отличается от того, что происходит в большинстве технологических компаний сегодня. В разработке программного обеспечения у вас есть возможность итерировать при обычно небольшом количестве неотменяемых сроков и возможность решать на ходу, что создавать дальше. Большинство команд создают минимально жизнеспособный продукт, а затем улучшают его на основе обратной связи. Это совершенно отличается от работы дизайн-команды крупного фильма, работающей над одним финальным сроком, когда они раскрывают весь продукт всем в конце — и с этим сроком не остаётся шанса внести последующие изменения или обновления.

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

Это заставило меня задуматься. Если мы считаем великие фильмы и великие произведения архитектуры одними из лучших дизайнов всех времён, но они не были созданы с использованием процесса гибкого проектирования, то, возможно, здесь есть чему поучиться. Другими словами: какие положительные аспекты процесса Риана отсутствуют в большинстве процессов гибкого проектирования?

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

Не верьте мне на слово. Райан Сингер, руководитель стратегии продукта в Basecamp, недавно получил много одобрения в Twitter за этот твит:

Типичная компания-разработчик ПО: 1. Невыполненные работы, которые кто-то решил, что команда должна делать -> 2. Роль «Продукта», которая на самом деле просто менеджер проекта -> 3. Дизайнеры и программисты перегружены неопределённой работой и просят работать всё быстрее и быстрее вместо того, чтобы работать умнее. - @rjs

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

Теперь я слышу голоса сторонников бережливого подхода: «Но в этом-то и смысл! Мы можем дать нашим пользователям именно то, что они хотят, потому что разрабатываем немного, смотрим, «работает» ли это, а затем разрабатываем ещё». И это совершенно верно. Я тоже большой сторонник такого типа мышления. Но проблема в том, как мы определяем слово «работает». «Работает» не должно просто означать, что мы выполнили запрос. Это должно быть: движемся ли мы в правильном направлении. Моя точка зрения в том, что этому процессу часто не хватает общего видения, создавая программное обеспечение «Франкенштейна» вместо финального связного и отполированного продукта.

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

Дилемма: возможно ли иметь лучшее из обоих миров?

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

Минимально жизнеспособный фильм и гибкая архитектура

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

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

Программное обеспечение с широкой перспективой

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

Ada, конструктор искусственного интеллекта Adalo, позволяет вам описать то, что вы хотите, и генерирует ваше приложение. Magic Start создает полные основы приложения из описания, а Magic Add добавляет функции на естественном языке.

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

Аналогично, Волшебное добавление позволяет добавлять функции через запросы на естественном языке, в то время как X-Ray выявляет проблемы производительности до того, как они повлияют на пользователей. Эти возможности искусственного интеллекта помогают поддерживать темп без ущерба для стратегического мышления, которое отличает отличные продукты от программного обеспечения «Франкенштейна».

Чтобы исправить проблему видения, команды гибкого проектирования должны:

• Привержены одному направлению (и, возможно, даже долгосрочным целевым датам!). Нам нужны целевые показатели на полгода, целевые показатели на год и пятилетний план. Это общее видение должно быть разделено всеми в компании. Мы не можем иметь разработчиков, которые не понимают, почему мы что-то делаем, и мы не можем иметь членов отдела продаж, которые обязываются реализовать функции, которые не входят в это общее видение будущего. Все должны верить в план и придерживаться его.
• Прекратите гнаться за каждым проходящим волшебным единорогом. Следующий шаг — на самом деле следовать этому обязательству. Только потому, что есть ещё одна возможность, которая могла бы быть ценной, не означает, что мы должны пойти по этому пути. Если все в компании действительно согласованы с долгосрочными целями, то должно быть ясно, какие функции входят в этот план, а какие — отвлекающий фактор.
• Создайте процесс определения того, должны ли вы изменить курс. Лучшая часть гибкой разработки в том, что если наши пользователи не получают пользу от того, что мы создаём, мы можем изменить курс. Поэтому мы не должны создавать эти долгосрочные планы без возможности изменить курс. Это означает, что все должны разработать и согласиться на критерии для изменения курса. Только потому, что какой-то крупный клиент хочет чего-то, не означает, что мы должны это делать. Посмотрите на конституцию. Её общее видение не изменилось так уж сильно, но есть чёткий план внесения поправок.
• Завершите важные детали перед тем, как переходить дальше. Одна из причин, по которым великие фильмы и великие произведения архитектуры вероятно, — это прекрасные дизайны — в том, что их мелкие детали служат общему видению. В гибком проектировании эти детали обычно откладываются в сторону для следующей крупной функции. Но если мы привержены долгосрочным планам, мы можем правильно отработать эти детали перед тем, как переходить дальше.
• Отметьте большие достижения. Когда мы достигаем одну из этих долгосрочных целей вовремя, нам всем нужно отпраздновать вместе. Наблюдать, как весь актёрский состав Последние джедаи собирается на финальную фотосессию, было невероятно. Чувство гордости и радости было заразительным и вдохновляющим. Если мы не найдём время отпраздновать наши достижения, то рискуем попасть в марш смертельного функционала.

Почему современные конструкторы приложений обеспечивают лучший гибкий дизайн

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

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

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

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

Часто задаваемые вопросы

Почему выбрать Adalo вместо других решений для создания приложений?

Adalo — это конструктор приложений на основе искусственного интеллекта, который создает истинные нативные приложения iOS и Android из единой кодовой базы. В отличие от веб-оболочек, он компилируется в нативный код и публикуется прямо в Apple App Store и Google Play Store. С Magic Start, генерирующим полные основы приложений из описаний и неограниченными записями базы данных на платных планах, вы получаете возможности масштаба предприятия без сложности предприятия.

Какой самый быстрый способ создать и опубликовать приложение в App Store?

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

Могу ли я легко итерировать и совершенствовать свое приложение на основе отзывов пользователей?

Да, Adalo позволяет вам быстро тестировать, обновлять и улучшать свой продукт в реальном времени. В отличие от кинорежиссеров или архитекторов, которые должны привержаться единому окончательному видению, вы можете постоянно итерировать. Magic Add позволяет вам добавлять функции через запросы на естественном языке, а X-Ray выявляет проблемы производительности до того, как они повлияют на пользователей.

Чем гибкое проектирование отличается от традиционных процессов кино или архитектурного проектирования?

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

Какая главная проблема процессов гибкого проектирования сегодня?

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

Как команды гибкой разработки могут поддерживать связное видение, одновременно итерируя?

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

Сколько стоит построить приложение с методологией гибкой разработки?

Веб-конструктор и истинный конструктор мобильных приложений Adalo начинаются с $36/месяц с неограниченным использованием и публикацией в приложение store. Это выгодно сравнивается с альтернативами, такими как Bubble (начиная с $69/месяц с платежами на основе использования и ограничениями записей) или FlutterFlow ($70/месяц за пользователя, плюс отдельные затраты на базу данных). Предсказуемое ценообразование поддерживает долгосрочное планирование.

Могут ли инструменты искусственного интеллекта помочь сбалансировать быструю итерацию с мышлением в масштабе всей компании?

Да. Функции искусственного интеллекта, такие как Magic Start, генерируют полные основы приложений из описаний, освобождая команды сосредоточиться на видении, а не на деталях реализации. Magic Add позволяет вам добавлять функции через запросы на естественном языке, сохраняя импульс, не теряя из виду общее направление продукта.

Будет ли мое приложение масштабироваться, если я привержаюсь долгосрочному видению?

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