Когда пора звать второго человека на поддержку приложения, созданного с ИИ

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

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

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

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

Признаки того, что пора

Вы поймёте, что пора, когда сможете ответить «да» на большинство из этого:

Вы отказываетесь от изменений, которые хотели бы внести. Не потому, что это плохие идеи, — а потому, что у вас нет часов. Вы завели личный список «что бы я сделал, будь у меня время», и он всё растёт.
Один и тот же вопрос пользователей всплывает снова и снова. Вы восемь раз за две недели ответили «как мне выгрузить свои данные?». Это страница помощи, но написать её некогда, поэтому вы продолжаете отвечать вручную.
Вы избегаете приложения. Какой-то его уголок ощущается тяжёлым. Может, раздел администрирования, может, экран биллинга — что-то, где любое изменение похоже на хирургию. Вы даёте багам там стареть дольше, чем стоило бы.
Одна ошибка дорого обойдётся. У вашего приложения теперь реальные пользователи с реальными данными. Один неудачный деплой усталым вторничным вечером может стоить кому-то его работы. У вас нет второй пары глаз.
Вы — бутылочное горлышко роста. Три потенциальных клиента попросили небольшое изменение, прежде чем зарегистрироваться. Два месяца назад вы собрали бы его тем же вечером. Теперь вы не можете даже ответить три дня.

Если верны два пункта — возможно, вы в порядке. Если верны четыре — вы были горлышком дольше, чем сами осознаёте.

Кого звать первым

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

Ищите примерно в таком порядке:

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

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

Кто-то из вашего сообщества. Если ваше приложение для учителей — найдите учителя. Если для свадебных фотографов — найдите свадебного фотографа. Знание предметной области стоит больше, чем технический навык, потому что ИИ-конструктор приложений может восполнить технический навык, но не может восполнить «что свадебным фотографам на самом деле нужно в субботу в июле».

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

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

Какой кусок ему передать

Ошибка — передавать всё приложение целиком. Всё приложение — у вас в голове. Вы знаете, какие части хрупкие, какие вы так и не довели до конца, какие пользователь однажды чуть не сломал. Он — нет.

Передайте кусок. Настоящий, с краями:

Главная и маркетинговые страницы. Низкий риск, высокая видимость. Можно итерировать тексты, секции, скриншоты, отзывы. Если что-то сломают, вы заметите в течение часа и никто из пользователей не потеряет данные.
Центр помощи. Если вы постоянно отвечаете на одни и те же вопросы, это тот самый кусок. Он пишет ответы; вы вычитываете первые несколько, пока не начнёте доверять голосу; потом он публикует.
Одна конкретная функция, обращённая к пользователю. Может, это процесс экспорта, или система комментариев, или уведомления. Что-то с чистой границей, где баг не валит всё приложение.
Админ-инструменты, которыми вы пользуетесь сами. На удивление хороший стартовый кусок. Он может улучшать инструменты, которыми вы пользуетесь, не трогая ничего из того, что видят клиенты. Вы ежедневно ощущаете улучшения, и это укрепляет доверие.

Форма куска важна меньше, чем сам факт, что это кусок. Он им владеет. Вы не передумываете по каждому изменению. Вы договариваетесь о частоте сверок и даёте ему работать.

Чего не делать в первый день

Короткий список, в основном из наблюдений за тем, как другие делают это плохо:

Не давайте ему доступ к своей боевой базе данных. Большинство ИИ-конструкторов позволяют сделать staging-копию приложения. Начните его там. День, когда он впервые выкатит что-то в продакшен, должен быть маленькой церемонией, а не случайностью.
Не вываливайте на него всё сразу. «Вот Notion-док с 87 пунктами, бери любой». Это ошеломляет, и он уйдёт. Выберите первые три пункта вместе. Доведите их до конца. Потом выберите следующие три.
Не ждите, что он будет читать ваши мысли. Вы живёте с этим приложением месяцами. У вас есть сокращения для всего. Запишите пять вещей о том, как приложение работает и как вы принимаете решения по нему. Передайте ему это. Это займёт у вас полтора часа и сэкономит недели.
Не пропадайте. Вы нужны ему первые несколько недель. Задайте реальную частоту — короткий созвон раз в неделю, асинхронные сообщения между ними. Через месяц можно, наверное, перейти на раз в две недели. Не раньше.

Каково это на самом деле потом

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

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

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

Обычно это меньший прыжок, чем кажется.