Откуда взялся страх перед «самописом»
Слово «самопис» у владельца звучит почти как приговор: единственный разработчик написал что-то на коленке, ушёл, и теперь систему никто не понимает и не может починить. Страх обоснован — но он про плохой самопис, а не про любое собственное решение в принципе. Разница между «самописом-сиротой» и коробкой с поддержкой — это пропасть, и путать их не стоит.
Что превращает своё решение в проблему
Опасны не строки кода как таковые, а отсутствие сопровождения вокруг них. Самопис становится миной, когда совпадают факторы:
- его делал один человек и без документации;
- нет понятного владельца поддержки, к которому идти со сбоем;
- код закрыт даже от самого заказчика;
- нет бэкапов и нет плана действий на случай падения.
Любой из этих пунктов — про организацию процесса, а не про сам факт «решение не из коробки SaaS». Именно процесс, а не код, делает систему рискованной. Облачный сервис, кстати, не застрахован от того же: он тоже может уйти с рынка, отключить вас за неоплату или закрыть нужную функцию — просто эти риски выглядят привычнее.
Чем коробка отличается от мины
Коробочное решение — это тот же собственный софт, но упакованный как продукт: с понятной структурой, документацией и договором на поддержку с прописанными сроками. Признаки «нестрашного» самописа:
- зафиксированный SLA — известно, кто и за какое время устраняет сбои (SLA — договорное обязательство по срокам реакции и починки);
- данные и сервер у вас — вы не зависите от настроения одного фрилансера;
- передаваемость — решение можно отдать другому подрядчику, оно не заперто на авторе;
- прозрачность — вы понимаете, из каких частей состоит система.
При таких условиях своё решение оказывается надёжнее облака: вас не отключат за неоплату и не задерут цену в одностороннем порядке. Так устроена CRM, которую мы собрали для кредитного брокера, — с поддержкой и данными на стороне клиента.
Что спросить у подрядчика до старта
Чтобы не купить мину под видом коробки, задайте четыре вопроса:
- Кто и за какой срок чинит сбой — это записано в договоре?
- Кому принадлежат код, данные и сервер после сдачи?
- Есть ли документация, по которой систему подхватит другой разработчик?
- Как устроены бэкапы и что происходит в момент падения?
Если на все четыре есть внятный ответ — перед вами продукт, а не самопис-сирота.
Подводные камни
- «Поддержка есть» без SLA — пустой звук. Если срок реакции и починки не прописан в договоре, поддержка сведётся к «ответим, когда сможем». Требуйте конкретные часы.
- Документация «потом» не появляется. Её либо пишут по ходу разработки, либо не пишут никогда. Проверяйте наличие README и комментариев на приёмке, а не через год.
- Передаваемость проверяется до, а не после ухода автора. Заложите в договор право отдать проект другому подрядчику и получить исходники — иначе «своё» решение окажется чужим.
Боитесь остаться с системой один на один после запуска? Спросите про формат и сроки поддержки в форме или в Telegram.
