ERP: купить, выстрадать или навайбкодить?

Всем привет, меня зовут Марат, последние 15 лет я занимаюсь развитием системы складского учета СКИФ. Система размещается на хостинге клиента, потому клиент может самостоятельно вносить нужные ему доработки. В основном из-за возможности индивидуальных доработок нашу систему и выбирают. 

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

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

Написать могу и качество будет приемлемое, но есть нюансы.

Да, снова они, нюансы…

Что получится хорошо: корректное учётное ядро: движения по регистру остатков, документы, взаиморасчёты, аудит-лог, отчёты. Где всё равно потребуется человек:

1. Решения, а не код. Нужно зафиксировать десяток правил: разрешать ли отрицательные остатки, что делать с правкой задним числом, где округляется НДС, что происходит при пересортице. Я могу предложить дефолты - но выбор ваш, и он определяет, будет система «правильной» или нет.

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

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

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

Другой пример уже из СКИФ: у нас в дистрибутиве по умолчанию нет возможности запретить продажу в минус. За такой доработкой очень часто обращаются: «Нужно запретить, продавцы очень глупые, думать не хотят, к работе относятся наплевательски». На практике, обычно причина продажи в минус не глупость продавца. А например, то, что товар в магазин привезли, а в офисе поставку еще не оприходовали. Или оприходовали, но есть пересорт. Или никто не удосужился уделить достаточно времени для обучения продавца, рассказать, что есть похожие товары, как искать, как сканировать штрихкоды и т.д. Просто «запретить» кажется решит все проблемы.
Обычно я на такую просьбу отвечаю так: «Хорошо, мы сделаем вам такую опцию, но для её реализации опишите, пожалуйста, как должен поступить продавец, если товар фактически привезли, покупатель стоит с деньгами и товаром в руках перед кассой, а в системе этого товара еще нет, потому что в офисе его не оприходовали?»

2. Российская специфика. НДС, УПД, маркировка, ККМ, ЭДО - здесь я напишу формально корректно, но ошибусь в деталях.

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

3. Объём. Это не одна функция. Минимальное честное ядро - несколько тысяч строк, 15–25 таблиц, десятки экранов. Это недели работы кусками, а не один запрос.

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

4. Первые полгода эксплуатации. Любая учётка приобретает зрелость только на реальных данных. Та самая накопленная вами за годы обвязка - она не пишется заранее, она нарастает.

Это так. Можно написать хороший код, но хорошей в работе программой он станет только когда будет «выстрадан», «объезжен» тобою и клиентами, которые используют его не так, как ты и никаким тестированием это заранее не выявишь. Часто, когда клиенты пишут об ошибке, начинаешь разбираться, как это могло случиться. Оказалось, сотрудник нажал куда-то не туда, и ты сидишь и думаешь, как вообще это могло прийти в голову человека нажимать кнопки вот так, и почему это не пришло в твою голову при проектировании, и почему никто раньше не тыкал клавиши в такой оригинальной последовательности? 

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

И самое главное. Мы ОТВЕЧАЕМ за свой код, ошибки исправляем бесплатно и всегда можем посмотреть, что произошло и почему произошло.

ИИ ответственность на себя не берет, но справедливости ради нужно заметить, что это тоже не его персональная проблема. Многие клиенты, которые пришли к нам с готовыми магазинами на Опенкарт для интеграции с учетом, позже перенесли магазины на наш движок. Самый частый ответ на вопрос о причинах звучит примерно так: «Заколебало, что при установке любого нового плагина, все остальные могут слететь к чертям и никто не берет на себя ответственность и никто не берется это починить». (Я, вообще говоря, к Опенкарт отношусь хорошо, но вот этот его плюс в плане открытости и популярности, стал одновременно и минусом в плане ответственности за работоспособность).

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

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

А если коротко: нравится – вайбкодьте, но поверх фундамента, за который кто-то отвечает.