​​Самодеятельность, совсем не художественная

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

Небольшой бар, бильярд. И полностью с нуля написанная учетная система. Веб-приложение на PHP + MySQL, сервер и рабочие места под Linux, написано под конкретные задачи предприятия и полностью отражают все пожелания заказчика.

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

А торговля нынче у нас деятельность, требующая постоянного внимания и доработок. То ЕГАИС шагает по стране, то маркировка. Рано или поздно приходится вносить изменения в учетные системы.

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

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

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

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

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

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

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

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

Хотите дорабатывать их под себя? Берите 1С, да на 1С многие ругаются, многое из сказанного справедливо, но именно 1С позволяет допилить то, что надо и поддерживать основные функции и реализовывать нововведения стандартными средствами 1С.

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

И даже если у вас лютый самопис на платформе 1С вы всегда можете его достаточно малой кровью привести к современным требованиям используя БСП (Библиотека стандартных подсистем) и БПО (Библиотека подключаемого оборудования).

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

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