Своя система чи готова коробка: чесне порівняння

Коли коробка виграє

Коробка виграє тоді, коли ваш процес стандартний, і ви готові його не міняти. Бухгалтерія, пошта, бронювання кімнат, простий інтернет-магазин без складу — там сотні тисяч користувачів роблять те саме, що й ви, і продукт відточений на них. Робити своє в цій зоні — це платити за те, що вже зроблено краще.

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

Третя: у вас немає людини, яка відповідатиме за систему. Коробка приходить із підтримкою, оновленнями і чужою відповідальністю. Своя система приходить із вашою.

Коли виграє своє

Своє виграє там, де ваш процес і є вашою перевагою. Якщо ви заробляєте саме тому, що робите щось не так, як усі, — коробка змусить вас робити як усі, і перевага зникне разом із нею.

Друга зона — залізо. Коробки для роботи з обладнанням існують, але кожна написана під певний набір контролерів і приймачів. Як тільки на обʼєкті стоїть щось поза списком — а на обʼєкті майже завжди стоїть щось поза списком — коробка або не бачить пристрій, або вимагає його замінити. Контролери по Modbus, приймачі по ccTalk і MDB, термінал еквайра, фіскальний реєстратор: чотири світи, і коробка, яка знає всі чотири саме у вашій комбінації, трапляється рідко.

Третя — інтеграції. Коробка має свій список того, з чим вона дружить. Якщо ваш склад, банк або CRM у списку — добре. Якщо ні — ви платите за міст між коробкою і рештою, і цей міст уже є власною розробкою, лише без переваг власної розробки.

Третій варіант: готова система, адаптована під процес

Між двома крайнощами є те, як працюємо ми і, чесно кажучи, більшість тих, хто давно робить прикладні системи. Є готове ядро — журнал платежів, робота з контролерами й приймачами, звірка, документи, звʼязок із месенджерами. Воно вже пройшло через реальну експлуатацію: через наш платіжний шар на мережі мийок пройшло 14 мільйонів транзакцій, через систему продажів у месенджері — 260 замовлень на 22,2 млн грн. Це не демо.

Але ядро — не продукт із фіксованим інтерфейсом. Під кожного замовника воно адаптується: інші контролери, інший еквайр, інші документи, інша логіка зміни. Замовник отримує не коробку і не розробку з нуля, а систему, яка вже працює, з тими відмінностями, які справді потрібні його процесу.

Що це дає: строки ближчі до коробки, бо більшість коду вже написана й перевірена; гнучкість ближча до власної розробки, бо зміни робляться в коді, а не в налаштуваннях, які передбачив виробник. Що це коштує: залежність від того, хто це ядро розвиває, — і про це варто говорити прямо.

Привʼязка: до кого і чим

Привʼязка є завжди, питання лише в її формі. З коробкою ви привʼязані до постачальника: його цін, його планів, його рішення закрити продукт. Дані зазвичай можна вивантажити, але процес, побудований навколо його інтерфейсу, вивантажити не можна.

З власною розробкою ви привʼязані до людей, які її знають. Якщо це один розробник без документації — привʼязка сильніша, ніж до будь-якої коробки, бо коробку хоча б знають тисячі людей.

З адаптованою системою привʼязка — до того, хто розвиває ядро. Її послаблюють три речі, які варто прописати в договорі: код належить замовнику або ліцензований йому безстроково; документація й доступи до серверів у замовника з першого дня; система побудована на відкритих компонентах, які знає будь-який розробник, а не на власній платформі, яку знає лише автор.

Хто володіє кодом і що це означає насправді

Пункт «код належить замовнику» в договорі корисний, але сам по собі не рятує. Код без людини, яка його розуміє, — це архів. Володіння кодом означає щось лише тоді, коли інший розробник може його взяти й продовжити, а для цього потрібні репозиторій з історією, документація тієї частини, яку неможливо зрозуміти з коду, і відсутність закритих залежностей, які без автора не працюють.

Ми віддаємо код у репозиторій замовника і робимо так, щоб розгортання описувалось у скрипті, а не в голові. Це не благодійність: замовник, який може від нас піти, залишається з нами через якість роботи, а не через відсутність виходу. Це здоровіші стосунки для обох.

Підтримка і ризик переїзду

Коробка обіцяє підтримку, але підтримка коробки відповідає на питання «як зробити X у продукті», а не «чому наш пост не запускається після оплати». Другий тип питань — саме той, що коштує грошей, і в коробці на нього відповідає ваш власний інженер або ніхто.

Ризик переїзду варто оцінювати до вибору, а не після. Три питання: чи можна вивантажити всі дані в читабельному форматі; чи є в системі щось, що знає лише її автор; скільки часу процес може жити без системи, якщо вона зупиниться. Якщо на третє питання відповідь «жодного дня» — вам потрібна не найдешевша система, а та, в якій ви розумієте, як вона зупиняється і як піднімається.

Найчесніша перевірка будь-якого варіанта — попросити показати, як із нього виходять. Постачальник, який охоче показує експорт і документацію, впевнений, що ви не захочете піти. Той, хто ухиляється, знає, що захочете.

Часті питання