В четверг вечером Светлана из отдела продаж «Маяка» доделала калькулятор скидок: вводишь объём заказа и категорию клиента, он считает итоговую цену и подсвечивает, если скидка превышает лимит. Она собрала его сама, поговорив с нейросетью два вечера подряд. В пятницу утром она приходит к Игорю в ИТ: «Вот, я всё сделала, вам осталось только внедрить».
Игорь открывает ссылку, кликает по паре полей, и калькулятор действительно работает. А потом Игорь молчит дольше, чем Светлана ожидала. Не потому что придирается. Потому что «внедрить» для него значит совсем не то, что для неё.
Экран — это верхушка
Прототип показывает то, что видно: поля, кнопки, расчёт. Всё остальное, что нужно рабочему сервису, находится под водой и с экрана не считывается.
Под водой:
- вход и права — кто вообще может открыть калькулятор и видит ли стажёр те же лимиты, что и руководитель отдела;
- настоящие данные — в прототипе Светланы объём и категория клиента вымышленные, а в рабочей версии туда попадут реальные суммы сделок и, возможно, персональные данные заказчика;
- резервные копии — если у сервиса появится база, кто-то должен отвечать, что она не потеряется при сбое диска;
- журналы — кто и когда менял лимит скидки, если через полгода понадобится разобраться в споре;
- обновления библиотек — код, собранный за вечер, тянет чужие пакеты, и в одном из них через месяц могут найти уязвимость, о которой никто не узнает, если её не отслеживать;
- связь с другими системами — чтобы калькулятор видел актуальный список клиентов, его нужно подключить к учётной системе, а не переписывать список руками;
- нагрузка — выдержит ли самодельная страница пятнадцать человек одновременно, а не одного автора;
- кто чинит — если Светлана в отпуске, а у клиента к вечеру должна быть цена, к кому идти.
Ничего из этого не значит, что вечерняя работа была зря. Значит только, что «готово» и «работает у меня на компьютере» — не одно и то же.
Чем прототип ценен на самом деле
Прототип — это не недоделанный продукт, а живое техническое задание. Он показывает, что нужно человеку, точнее, чем десять страниц описания: видно, какие поля важны, в каком порядке их заполняют, что должно подсвечиваться красным. ИТ не приходится гадать и переспрашивать неделями — гипотеза уже проверена руками того, кто с задачей живёт каждый день. Про то, как строить такой прототип с самого начала — с вымышленными данными и без подключений — рассказано в статье «Как вайбкодить внутренний сервис».
Это экономит время именно на выяснении: не нужно тратить встречи на вопрос «а что вообще нужно показать на экране» — ответ уже есть, его можно потрогать.
Как прийти в ИТ, если прототип сделали вы
Разница в одной фразе. «Внедряйте» звучит как готовое решение и чужая задача. «Вот боль, вот как я её вижу, вот прототип» — это заявка, с которой можно работать.
Соберите пакет передачи перед разговором:
- какую боль решает и сколько людей или времени это затрагивает — своими словами, без придуманных цифр и процентов, которые потом нечем подтвердить;
- кто пользователи — вы одна, весь отдел, руководители;
- какие данные нужны и откуда они берутся — в самом прототипе должны быть только вымышленные значения;
- пара скриншотов или короткое видео с экрана;
- что вы уже проверили и что точно не сделано — не нужно выдавать вечерний код за законченную работу;
- промты и файлы, из которых собран прототип — так следующему человеку не придётся начинать с нуля;
- готовность быть заказчиком: отвечать на вопросы и тестировать, а не исчезнуть после передачи.
Чего не делать до разговора с ИТ: не выкладывать прототип самой в общий доступ, не подключать его к рабочим системам и не загружать туда реальные данные сотрудников или клиентов, даже «только чтобы проверить». Где именно проходит эта граница, разобрано в статье «Что можно и нельзя вводить в чат».
Что делать ИТ с тем, что принесли
Отмахнуться — плохой вариант: он злит автора и хоронит рабочую гипотезу. Но и «отдать в прод как есть» — плохой вариант тоже. У Игоря есть четыре пути.
Первый — выбросить код и оставить прототип как техническое задание, сделав сервис заново по своим стандартам. Второй — довести код до ума и принять его в эксплуатацию, если он в целом приличный, а задача маленькая. Третий — закрыть задачу готовым решением, которое уже есть в компании или на рынке: иногда окажется, что похожий калькулятор уже встроен в учётную систему, просто про него забыли. Четвёртый — оставить прототип личным инструментом автора на его собственном компьютере, без подключения к общим данным и без доступа других сотрудников.
Выбор между ними занимает не месяц, а полчаса разговора, если задать правильные вопросы: кто будет владельцем сервиса после запуска; какие данные он затронет; что случится, если он сломается или посчитает неверно; сколько человек им пользуются; нет ли уже похожего решения в компании. Ответы на эти пять вопросов почти всегда сразу подсказывают, какой из четырёх путей подходит.
Как договориться, чтобы не ссориться
Проще всего заранее объяснить разницу: вечер автора и месяц ИТ — это разная работа не потому, что ИТ делает лишнее, а потому что под водой айсберга — вход, данные, копии, обновления, нагрузка, поддержка. Полезно завести в компании простое правило песочницы: самодельные прототипы можно собирать и показывать коллегам, но нельзя подключать к рабочим системам и наполнять реальными данными без отдельного разрешения. Полезно назначить «час ИТ на прототип» — регулярное время, когда специалист смотрит на принесённые калькуляторы и трекеры и сразу говорит, в какую из четырёх категорий это попадает, вместо того чтобы разговор откладывался неделями. Тогда «внедряйте» превращается в обычный рабочий разговор, а не в конфликт между тем, кто сделал что-то быстро, и тем, кто отвечает за то, чтобы это не сломалось.
Чего эта статья не решает
Она не заменяет решение о бюджете и приоритетах — если у ИТ пять таких прототипов и один разработчик, порядок очереди всё равно придётся определять отдельно. Она не говорит, каким должен быть договор об оплате чужой доработки, если автор прототипа — не сотрудник ИТ и не подчинён тому, кто принимает решение. Она не решает вопрос интеллектуальной собственности на код, сгенерированный с помощью нейросети, — это отдельная тема, которую в спорных случаях стоит закрывать с юристом, а не по аналогии со статьёй. И она не про то, как оценивать качество самого кода: приличный он или нет, решает тот, кто будет его поддерживать, а не автор прототипа.
