С чего начать проект вайбкодинга при решении бизнес-задач

В школе Ивана Замесина подготовка очередного учебного потока занимала около четырёх часов. Программа курса уже была готова, уроки и материалы тоже — сотруднику приходилось заново собирать привычную структуру для новой группы. Потоки Boost Pro запускались примерно раз в две недели, и работа повторялась.

В новой учебной платформе появился мастер-курс — образец с готовой структурой. Сотрудник открывает новый поток, нажимает «Синхронизировать мастер» и получает его основу. По приблизительной оценке Замесина, подготовка сократилась до десяти минут.

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

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

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

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

Когда она взялась за новую систему, требования появились из повседневных действий: создать поток, добавить урок, изменить материалы. Например, при очередном запуске курса хотелось повторно использовать уже подготовленную структуру. Так в новой платформе появился мастер-курс.

По словам Замесина, создание новой LMS заняло около двух месяцев активной работы. К моменту рассказа команда уже пользовалась ею и продолжала поддерживать.

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

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

Сначала можно просто пройти по экранам

Сотрудница Ивана записала задачи первой версии приложения в нескольких файлах. На их основе Claude создал кликабельный прототип: HTML-файл с предполагаемыми экранами и переходами. Можно было открыть страницу урока и посмотреть, как будет устроена работа.

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

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

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

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

Вакансия, ради которой приходилось настраивать несколько сервисов

Похожая повторная работа обнаружилась в найме. Описание вакансии размещали в Notion, кандидаты заполняли Typeform, ответы через Zapier попадали дальше в таблицу. Для уведомлений в боте требовалась ещё одна интеграция.

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

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

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

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

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

Что было готово до первого запроса к ИИ

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

Все эти материалы использовали в работе с Claude. После созвона сайт передали дизайнеру и продолжили дорабатывать.

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

Например, для подготовки коммерческого предложения нужны состав заказа, цены, правила скидок, условия поставки и образец готового КП. По этим материалам можно объяснить, что именно должна делать программа, и проверить её ответ на знакомом заказе.

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

Как понять, что работа стала проще

У подготовки учебного потока есть понятный результат: новая группа получила нужную структуру уроков и материалов. Есть и способ оценить изменение — сравнить время подготовки до и после появления инструмента.

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

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

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

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

Кто поможет довести приложение до повседневной работы

В школе сотрудники создавали инструменты внутри среды, которую подготовили разработчики. Технический руководитель участвовал в работе над внутренними системами; например, финансовый менеджер делала CRM совместно с ним. Дизайнер помогал доводить интерфейсы.

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

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

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

Один документ, с которого можно начать свой проект

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

• Пользователь. Кто будет работать с инструментом и что ему нужно сделать? Например, менеджеру нужно подготовить предложение по входящей заявке.

• Текущий процесс. Как он выполняет эту работу сегодня? Перечислите шаги, сервисы, ручной перенос данных и места, где приходится ждать или перепроверять.

• Критерий успеха. Что должно измениться и как вы это заметите? Укажите подходящий показатель: время работы, число обработанных заявок, количество ошибок или другой результат.

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

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

• Данные. Какие сведения поступают на вход, откуда они берутся, что должно получиться на выходе и кому это доступно?

• Ответственные. Кто подтвердит требования, кто проверит техническую часть и кто будет поддерживать приложение после запуска?

• Проверка. Кто пройдёт рабочий сценарий, на каком примере и какой результат должен получить?

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

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

Материал подготовлен по рассказу Ивана Замесина «Как мы навайбкодили школу». Сроки и результаты проектов приведены по его оценкам. Ниже — исходная запись с демонстрацией инструментов школы.