Від начерку на серветці до робочого застосунку: як будувати софт з ідеї за допомогою ШІ

У кожного є ідеї застосунків. Більшість із них помирають на стадії «це було б круто» — не тому, що ідеї погані, а тому, що розрив між «хочу, щоб це існувало» і «це існує» раніше вимагав найняти розробника чи навчитися програмувати. Жодне з цього не трапляється у вівторок по обіді.

Цей розрив менший, ніж будь-коли. Конструктори застосунків на ШІ дають вам описати простими словами те, що ви хочете, і отримати назад робочий застосунок — базу даних, інтерфейс, логіку, усе це. Ви можете побудувати застосунок з ідеї за години, а не місяці.

Але «опишіть, що ви хочете» бере на себе чимало роботи в цьому реченні. Складною частиною ніколи не було програмування. Складно було зрозуміти, що вам насправді потрібно.

Почніть із дієслова, а не з іменника

Більшість людей описують ідею застосунку як річ: «Це як Uber для вигульників собак» чи «Це інструмент керування проєктами для фрилансерів». Це пітч, а не специфікація. Конструктор на ШІ мало що з цим зробить, бо це описує категорію, а не поведінку.

Почніть із того, що люди робитимуть із вашим застосунком. Запишіть три-п’ять дій:

• «Вигульник собак відкриває застосунок і бачить свої бронювання на сьогодні»
• «Власник собаки обирає часовий слот і бронює прогулянку»
• «Вигульник позначає прогулянку завершеною, і власник отримує фото»

Це вже можна побудувати. Кожна дія мапиться на екран, таблицю в базі даних і частину логіки. Конструктору на ШІ не потрібен ваш пітч у ліфті — йому потрібен ваш список справ.

Карлос, персональний тренер із Мехіко, хотів застосунок, де його клієнти могли б записуватися на сесії й відстежувати тренування. Його перша спроба була: «Побудуй мені фітнес-застосунок». Результатом стала загальна бібліотека вправ зі стандартними планами тренувань — нічого схожого на те, що йому було потрібно.

Його друга спроба перелічила те, що він справді робив щодня:

1. Клієнти бачать доступні часові слоти на тиждень
2. Вони бронюють слот і отримують підтвердження у WhatsApp
3. Після кожної сесії Карлос фіксує, що вони робили (вправи, підходи, вага)
4. Клієнти відкривають свою історію й бачать прогрес із часом

Цей другий опис дав щось, чим він міг користуватися вже за кілька годин.

Спершу побудуйте один екран

У вас у голові може бути десять функцій. Побудуйте одну.

Оберіть екран, найближчий до основної проблеми, — те, що ваш застосунок робить так, як нічого інше, або те, чим люди користуватимуться найчастіше. Для Карлоса це був екран бронювання. Усе інше (фіксація тренувань, графіки прогресу, сповіщення) могло прийти пізніше.

Коли ви починаєте з одного екрана, відбуваються три хороші речі.

Ви дізнаєтеся, як думає конструктор. У кожного конструктора на ШІ є свої уявлення про макет, структуру даних і патерни взаємодії. Побудова одного екрана навчить вас спілкуватися з ним — які описи дають хороші результати, а яким бракує деталей.

Ви швидко отримуєте щось придатне до використання. Один екран, що працює, набагато корисніший за десять напівготових. Карлос мав клієнтів, які бронюють сесії, вже за дві години. Фіксація тренувань з’явилася на три дні пізніше. Якби він спробував побудувати все одразу, то досі б усе доналаштовував.

Ви відкриваєте, що вам справді потрібно. Функції, які ви вважаєте важливими до побудови, рідко збігаються з тими, що мають значення після того, як ви почнете користуватися. Карлос припускав, що графіки прогресу будуть «вбивчою» функцією. Його клієнтів більше турбувало те, щоб можна було перенести бронювання у два дотики.

Описуйте це так, ніби пояснюєте другу

Коли ви говорите з конструктором на ШІ, уявіть, що пояснюєте застосунок другові, який збирається побудувати його для вас. Ви б не сказали «реалізуй RESTful API бронювання з виявленням конфліктів». Ви б сказали «коли хтось обирає часовий слот, що вже зайнятий, покажи йому наступний доступний».

Проста мова працює краще за технічну, бо вона описує результати, а не реалізації. ШІ сам розбирається з реалізацією. Ваша робота — бути конкретними щодо того, що користувач бачить і робить.

Деякі описи, що добре працюють:

• «Коли вони натискають „Забронювати“, перевір, чи час досі доступний. Якщо так — підтверди. Якщо хтось уже зайняв його, покажи повідомлення й запропонуй найближчий вільний слот».
• «Дашборд має показувати вгорі три числа: усього клієнтів, сесій цього тижня й дохід цього місяця. Нижче — список сьогоднішніх сесій з ім’ям клієнта й часом».
• «Після сесії я хочу набрати, що ми робили — наприклад „присід 3×10 80 кг, жим лежачи 3×8 60 кг“ — і щоб це збереглося в історію того клієнта».

Патерн у кожному: хто що робить, коли і що відбувається далі.

Користуйтеся, потім виправляйте

Перша версія будь-чого буде неправильною так, як ви не могли передбачити. Це не провал — це процес. Перевага побудови з ШІ не в тому, що ви робите все правильно з першого разу. Вона в тому, що виправлення займає хвилини, а не тижні.

Коли Карлос побачив першу версію свого екрана бронювання, його турбували три речі:

1. Часові слоти показувалися 30-хвилинними блоками, але його сесії тривали 50 хвилин
2. Клієнт не міг скасувати запис, не написавши йому напряму
3. Повідомлення-підтвердження було англійською, а його клієнти говорять іспанською

Кожне виправлення зайняло менш ніж десять хвилин. Він описував проблему, конструктор підлаштовувався, і він рухався далі. У традиційній студії розробки будь-яке з цього було б запитом у підтримку й очікуванням.

Ключова звичка: користуйтеся власним застосунком, перш ніж показувати його комусь іншому. Клікніть кожну кнопку. Заповніть кожну форму. Спробуйте його зламати. Баги, які ви знайдете самі, дешевше виправити, ніж ті, що знайдуть для вас ваші користувачі.

Покажіть це комусь, хто не ви

Щойно ви накористуєтеся ним достатньо, щоб довіряти йому, покажіть його одному справжньому користувачу. Не п’ятьом. Не десятьом. Одному.

Карлос дав посилання на бронювання своєму найбільш технічно підкованому клієнту першим. Вона забронювала сесію, перенесла її, а потім написала йому: «А де я бачу, що ми робили минулого тижня?» Він ще не побудував перегляд історії тренувань. Але тепер він точно знав, яку функцію будувати далі — не з здогадів, а зі спостереження за тим, як справжня людина намагається зробити справжню річ і впирається в стіну.

Один користувач каже вам, що заплутано. П’ять користувачів кажуть, що популярно. Вам потрібен перший вид зворотного зв’язку, перш ніж другий стане корисним.

Запускайте до того, як ви готові

Вашому застосунку не потрібно бути завершеним, щоб бути корисним. Йому потрібно вирішувати одну проблему достатньо добре, щоб хтось скористався ним замість того, що робить зараз, — а це, мабуть, таблиця, група у WhatsApp чи нічого взагалі.

Карлос запустив свою систему бронювання для всіх 15 клієнтів лише з трьома функціями: забронювати слот, скасувати слот і переглянути найближчі сесії. Без фіксації тренувань. Без графіків прогресу. Без інтеграції платежів.

Він додавав це наступними тижнями, по одній функції за раз, на основі того, чого справді просили його клієнти. Фіксацію тренувань побудували після того, як троє клієнтів попросили її одного тижня. Інтеграція платежів з’явилася за місяць, коли Карлос усвідомив, що досі збирає оплату готівкою та через Venmo.

Через шість тижнів після того першого суботнього пообіддя побудови він мав застосунок, яким 15 платних клієнтів користувалися щодня. Він опрацьовував бронювання, відстежував тренування, показував прогрес і надсилав нагадування про прийоми. Він витратив, мабуть, годин 20 загалом — розкиданих по вечорах і вихідних — і 0 $ на розробку.

Його попередня система складалася з Google Календаря, Google Таблиці та списку розсилки у WhatsApp. Вона працювала, але помилки з бронюваннями траплялися щотижня, бо клієнти забували перевірити календар, перш ніж попросити час.

Три помилки, що сповільнюють людей

Спроба побудувати все одразу. Почніть з одного екрана. Зробіть так, щоб він працював. Потім додайте наступне. Розповзання обсягу вбиває більше ідей застосунків, ніж будь-коли вб’є поганий код.

Копіювання конкурента замість опису свого процесу. Якщо ви описуєте свій застосунок як «Calendly, але для персональних тренерів», ви отримаєте клон Calendly з іншими кольорами. Опишіть натомість свій реальний процес — і отримаєте щось, що пасує тому, як працюєте ви, а не тому, як вирішив Calendly, що ви маєте працювати.

Очікування досконалості. Ваша перша версія матиме шорсткі краї. Запускайте її все одно. Ви дізнаєтеся більше з одного спантеличеного обличчя справжнього користувача, ніж із тижня полірування екранів, яких ще ніхто не пробував.

Справжнім бар’єром ніколи не було щось технічне

До того, як з’явилися конструктори застосунків на ШІ, у вас було три варіанти, якщо ви мали ідею й не вміли програмувати: навчитися програмувати (місяці), найняти розробника (тисячі доларів) чи відпустити ідею (безкоштовно). Більшість людей обирали третій варіант — не тому, що їхні ідеї були погані, а тому, що інші два були дорогими в часі чи грошах.

Тепер ви можете побудувати застосунок з ідеї за день. Не прототип. Не макет. Робочий застосунок із базою даних, обліковими записами й справжньою логікою. Бар’єр більше не технічний. Це ясність — чи можете ви описати те, що вам потрібно, достатньо конкретно, щоб ШІ зміг це побудувати?

Якщо ви можете пояснити це другу — ви можете це побудувати.

Якщо ви засиділися над ідеєю, спробуйте побудувати її з Proyecta. Почніть з одного екрана — того, що має найбільше значення, — і подивіться, що станеться.