Коли переписувати свій застосунок на ШІ (а коли продовжувати ітерувати)
Кожен застосунок на ШІ доходить до роздоріжжя: продовжувати додавати до того, що є, чи почати з чистого аркуша. Ось як зрозуміти, який вибір насправді правильний.
Застосунок, що розрісся вбік
Марія почала будувати просту форму прийому клієнтів. За пів року в неї були запис на прийоми, сторінка оплати, автоматичні листи-нагадування, розділ нотаток для кожного клієнта й дашборд, що відстежував, скільки людей записалося того тижня. Воно працювало, здебільшого. Але кожна нова річ, яку вона додавала, наче ламала щось інше. Додавання розділу нотаток зробило так, що процес бронювання перестав правильно зберігати. Виправлення процесу бронювання зламало нагадування.
Вона запитала мене: «У який момент мені варто просто почати спочатку?»
Чесна відповідь така: не так часто, як ви думаєте, але є конкретні ознаки, що роблять аргумент на користь переписування важко спростовним.
Чому переписування здається спокусливим (навіть коли це хибно)
Коли застосунок стає повільним, чи починає поводитися непередбачувано, чи просто більше не виглядає так, як ви хочете, — інстинкт викинути його й почати з чистого аркуша. Чистий старт. Жодного старого багажу.
Цей інстинкт зазвичай хибний.
Переписування займає більше часу, ніж люди очікують. Ви втрачаєте всі крайні випадки, які ваш поточний застосунок тихо розв’язав. Ви втрачаєте звичність, яку напрацювали з тим, як ця річ працює. І ви часто переписуєте ті самі структурні проблеми, бо справжня проблема була не в застосунку — а в браку ясності щодо того, що застосунок мав робити.
Більшість застосунків на ШІ можна врятувати ітерацією. Хороший конструктор застосунків на ШІ може реструктурувати заплутану модель даних, спростити переплутану сторінку чи прибрати функцію, що вийшла з-під контролю. Що важить — це знати, коли ви на території «полагодь», а коли на території «почни спочатку».
Три ознаки, що вам справді варто переписувати
1. Змінилася основна ідея, а не лише функції
Якщо ви почали будувати інструмент прийому клієнтів, а тепер хочете B2B SaaS із підписками, командами користувачів і публічним маркетплейсом — це інший застосунок. Та сама технологія, цілком інший продукт. Намагатися перетворити одне на інше, нашаровуючи функції, — це як перетворювати велосипед на машину, додаючи деталі. Ви отримуєте щось, що ні те, ні те.
Запитання, яке варто поставити: Чи описав би я цей застосунок так само, як коли вперше його зібрав?
Якщо відповідь — ні, якщо назва, аудиторія й основна цінність усі відрізняються від того, що ви спочатку зібрали, — переписування, ймовірно, правильний хід. Ви отримуєте можливість проєктувати для того, що ви насправді хочете, замість того, щоб латати навколо того, що ви зібрали для чогось іншого.
2. ШІ більше не може зорієнтуватися в застосунку
Це практичний сигнал, а не філософський. Конструктори застосунків на ШІ працюють, читаючи наявну структуру вашого застосунку й вносячи зміни. Коли застосунок латали багато разів поспіль, структура стає неузгодженою — дані живуть у несподіваних місцях, сторінки посилаються на речі обхідними шляхами, кнопки під’єднані до логіки, скопійованої з інших кнопок і ніколи не прибраної.
Коли ви помічаєте, що кожна зміна ламає щось не пов’язане, чи ШІ постійно робить ту саму помилку (на кшталт неправильного визначення, до якої частини застосунку належить функція), ви, можливо, перейшли на територію «структурного боргу».
Переписування не розв’язує це за помахом чарівної палички — але дає змогу будувати чисто з самого початку, маючи на увазі повну картину.
3. У застосунку є користувачі, але він їх стримує
Якщо справжні люди користуються вашим застосунком, а ви постійно впираєтеся в ту саму стіну — «нам потрібен X, але немає способу додати його, не переробивши все», — це законний сигнал до переписування. Не тому, що застосунок поганий, а тому, що він був збудований для меншої версії проблеми, ніж та, яку вам насправді треба розв’язати.
Це хороша проблема. Вона означає, що застосунок працював достатньо добре, щоб люди користувалися ним серйозно. Переписування на цьому етапі — не провал, а випуск.
Що зробити перед переписуванням
Навіть якщо ви вирішили переписувати, зробіть спершу це:
Запишіть, що працювало. Пройдіться поточним застосунком і перелічіть усе, чим користувачі справді користуються. Ці функції довели попит. Вони мають бути в новому застосунку з першого дня.
Запишіть, що спричиняло проблеми. Не просто «це було повільно» чи «це багато ламалося» — будьте конкретні. «Функція нотаток конфліктувала з процесом бронювання, бо вони обидві зберігали дані в тому самому записі користувача». Ви хочете перенести уроки, а не код.
Задайте обмеження обсягу для переписування. Найбільший ризик переписувань — розповзання обсягу. Ви вирішуєте переробити все, а за два місяці все ще не закінчили, бо постійно додаєте функції «раз уже взялися». Переписування має випустити робочі функції зі старого застосунку плюс одну-дві речі, що були справді заблоковані. Усе інше додається потім.
Коли продовжувати ітерувати (більшість часу)
Ваш застосунок повільно завантажується? Ітеруйте — це зазвичай проблема запиту до даних чи забагато речей, що завантажуються одночасно.
Ваш дизайн виглядає застарілим? Ітеруйте — оновлення дизайну на 100% можливе в конструкторі на ШІ, не торкаючись базової логіки.
Ключова функція відчувається незграбною? Ітеруйте — перепишіть саме цю функцію, а не весь застосунок.
Ви додали забагато функцій, і все відчувається розкиданим? Ітеруйте — прибрати функції й спростити навігацію набагато швидше за повне переписування й часто ефективніше.
Засада: якщо модель даних усе ще має сенс для того, що ви намагаєтеся зробити, ітеруйте. Якщо модель даних неправильної форми для продукту, переписуйте.
Застосунок Марії
Ми пройшлися її застосунком разом. Основна структура — клієнти, прийоми, платежі — була насправді в порядку. Безлад прийшов від функції нотаток, прикрученої у спосіб, що конфліктував із тим, як зберігалися записи клієнтів.
Замість переписування вона сказала конструктору на ШІ точно, що відбувається: «Розділ нотаток і процес бронювання зберігають інформацію в місцях, що перекриваються, і це спричиняє конфлікти. Я хочу реструктурувати нотатки, щоб вони були цілком окремі від запису бронювання». Дві сесії потому це було виправлено. Решта застосунку лишилася незайманою.
Пів року накопичених функцій, не втрачено.
Справжнє запитання
Перш ніж вирішити переписувати, запитайте: Проблема в застосунку чи в моїй ясності щодо того, що застосунок має робити?
Більшість часу відповідь — ясність. А ясність не вимагає переписування. Вона просто вимагає бути конкретним зі своїм конструктором на ШІ щодо того, що ви насправді хочете.
Почніть звідти. Переписування завжди доступне. Воно нікуди не дінеться й за тиждень.
Якщо ви намагаєтеся зрозуміти, що насправді треба вашому застосунку — чи то підправлення, чи то свіжий старт, — Proyecta — гарне місце, щоб це обдумати. Зберіть щось маленьке, подивіться, що тримається, і ростіть звідти.