От бумажных анкет к своему приложению: история Джона Блэкмана

Джону Блэкману 91 год. На благотворительных мероприятиях своей церкви он регистрирует посетителей: записывает сведения о людях и заполняет бумажные «паспорта» с выбранными услугами. Ему захотелось перенести эту работу в компьютер.

Внук Бретт предложил попробовать ИИ. Джон сначала описал процесс в Word, уточнил требования с Claude и передал их Replit Agent — инструменту, который создаёт приложение по текстовому заданию. Первую ночь они просидели за работой до трёх утра. За первые два дня, по словам Джона, программа в основном заработала.

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

За бумажной анкетой скрывался целый рабочий процесс

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

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

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

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

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

Сначала Джон объяснил, как всё должно работать

До обращения к ИИ у Джона уже был документ Word. В нём он описал регистрацию, необходимые сведения и набор доступных услуг. Он также знал, что хочет использовать «паспорта» участников и QR-код для перехода к форме с телефона: обе идеи подсмотрел в другой церкви.

Документ в Word-формате передали Claude и сразу уточнили, что приложение будут создавать в Replit. Джон попросил Claude составить план разработки и добавил указание: задавать вопросы, если информации недостаточно.

В ходе разговора с ИИ появились требования к первой версии: регистрация, административный интерфейс, генерация паспортов, управление данными. Claude помог описать потребности разных людей. Что должен сделать посетитель? Какие сведения нужны администратору? Что понадобится пастору после мероприятия?

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

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

Полезная подготовка для похожего проекта — описать один процесс так, как вы объяснили бы его новому сотруднику:

• С чего начинается работа и кто в ней участвует?

• Какие сведения появляются на каждом шаге?

• Кто и куда передаёт их дальше?

• Какие документы должны получиться в конце?

• Что приходится переписывать, уточнять или проверять вручную?

С таким описанием уже можно обсуждать будущий ИТ-инструмент. ИИ поможет задать дополнительные вопросы, но основные правила работы нужно будет подтвердить человеку, который знает процесс.

С десяти вечера до трёх утра

Подготовленные материалы Джон скопировал из Claude в Replit Agent. Вместе с внуком Бреттом они начали около десяти вечера и закончили примерно в три часа ночи. На следующий день вернулись к работе в десять утра и продолжали до пяти вечера. Затем он продолжил развивать приложение сам, добавлять функции и исправлять ошибки.

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

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

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

Ранее он работал инженером-электриком, осваивал AutoCAD и создавал логические правила для IntelliCAD. С TypeScript, на котором строилось новое приложение, прежде не работал. В проект он принёс опыт описания задач, готовность учиться и понимание своей регистрационной работы. Бретт помог начать, а при сложностях Джон обращался к нему и другому внуку, Брэндону.

Почему владельцу процесса всё равно приходится смотреть в экран

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

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

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

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

Джон выработал простой порядок проверки. Когда агент сообщает о готовности, он открывает приложение и пробует нужное действие. Если что-то идёт не так, объясняет проблему. Если видит, что агент уходит в сторону, останавливает его короткими сообщениями «Подожди» и «Стоп».

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

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

Паспорт был готов, но в письмо не попадал

Самое неприятное затруднение возникло при публикации приложения. В среде разработки PDF-паспорт прикреплялся к письму с подтверждением регистрации. В рабочей версии вложение пропадало.

Для Джона это ломало важную часть замысла. Он хотел отправлять «паспорта» заранее, чтобы посетители могли распечатать их дома. Без вложения эту работу снова пришлось бы делать на мероприятии.

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

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

Джон объяснял это тем, что вместо актуального ключа доступа подставлялся старый. Ведущая предложила помочь разобраться с настройками рабочей версии. В конце разговора на вопрос, чем ему можно помочь, он ответил: починить поиск по VIN.

Эти две проблемы хорошо показывают, из чего состоит запуск. Нужно пройти весь путь уже в опубликованном приложении: отправить форму, получить письмо, открыть вложение, проверить результат запроса к внешнему сервису. Именно на этом этапе Джону потребовалась помощь с техническими настройками.

Что получилось за 350 долларов

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

Но на мероприятиях приложение тогда ещё не внедрили. Джон продолжал добавлять функции и устранять неисправности. Поэтому экономию времени, сокращение очередей и удобство для посетителей предстояло проверить в работе.

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

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

С чего начать свой проект

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

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

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

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

Материал подготовлен по интервью Джона Блэкмана и его внука Брэндона в подкасте How I AI с Клэр Во. Смотреть выпуск. Состояние проекта описано на момент этого разговора.