Чи варто це будувати? Питання, яке ми ставимо, перш ніж писати код

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

Чи справді нам це варто будувати?

У Libertas Software Research (LSR) ми вважаємо, що знати, чи варто розробляти програмне забезпечення, так само важливо, як знати, як. Іноді індивідуальний застосунок, саме те, що потрібно. Іноді усталена SaaS-платформа повністю закриває потребу, а іноді з'єднання вже наявних систем дає результат без витрат і збоїв, пов'язаних з їх заміною. Мета, покращити роботу організації, а не додати ще один застосунок у й без того складне середовище.

Починайте з проблеми, а не з рішення

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

Візьмімо щомісячний управлінський звіт, який вручну збирають з кількох таблиць і систем. Це забирає дні, а коли звіт готовий, дані вже застаріли. Очевидний висновок: потрібна програма для звітності. Якщо придивитися, справжня проблема часто в розрізнених даних і неузгоджених процесах: скромний інтеграційний проєкт, а не новий застосунок. А якщо дослідження покаже, що потрібні особливі робочі процеси чи засоби контролю, яких не підтримує жоден продукт, саме тоді індивідуальна розробка виправдовує себе.

Коли купівля має більше сенсу

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

Але порівнюйте сукупну вартість володіння, а не ціну підписки. Продукт за 500 £ на місяць, це 30 000 £ за п'ять років, ще до налаштування, інтеграцій, додаткових ліцензій і змін у ваших власних процесах. Перевірте, як зростає ціна, чи можна експортувати дані та що буде, якщо постачальник змінить модель. І стережіться змушувати бізнес відмовлятися від того, що його справді вирізняє, лише тому, що продукт передбачає інакше.

Іноді відповідь: з'єднати те, що вже є

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

Замінити все одним застосунком спокусливо, але ризиковано. Наявні платформи зберігають роки операційних знань і приховані інтеграції. Продуманий інтеграційний рівень (підключення API, автоматизація передавання даних, зведення звітності з авторитетних джерел) може продовжити життя цих інвестицій. Він потребує уваги до автентифікації, володіння даними, обробки помилок та аудиту, але рекомендувати інтеграцію замість заміни, не гірша інженерія. Часто це більш виважене архітектурне рішення.

Коли індивідуальна розробка: правильна інвестиція

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

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

Не кожна проблема потребує більше програм

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

Якщо документу потрібно п'ять погоджень, не питайте, як автоматизувати п'ять погоджень, питайте, навіщо існує кожне з них і який ризик воно закриває. Програми чудово застосовують єдині правила, але не скажуть, чи розумний процес. Спрощення робочого процесу або уточнення відповідальності може дати реальний ефект без ще однієї системи, яку треба опановувати й підтримувати.

Дивіться далі за початкову вартість

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

Врахуйте й вартість бездіяльності. Неефективний процес, що з'їдає 20 робочих годин на тиждень,, це близько 1 040 годин на рік. За ілюстративної ставки 35 £ на годину це приблизно 36 400 £ на рік за умови, що цей час справді можна повернути й спрямувати на інше. Додайте низьку якість даних і повільні рішення, які важче оцінити, але які не менш реальні. Найкращий варіант, не найдешевший, а той, де найсильніше поєднуються цінність, прийнятний ризик і довгострокова стійкість.

Навіщо компанії-розробнику радити не розробляти ПЗ?

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

Але одна річ, надавати потужності для розробки, і зовсім інша, бути партнером з досліджень та архітектури ПЗ. Наша робота починається ще до того, як з'являється специфікація: зрозуміти проблему, оцінити варіанти й допомогти вам вирішити, куди інвестувати. Це має цінність незалежно від результату, і зазвичай залишається робота з аналізу, архітектури, планування та інтеграції, навіть коли індивідуальна розробка, не відповідь.

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

Можливість будувати: не причина будувати

ШІ та сучасні інструменти роблять код швидшим і дешевшим у виробництві. Це корисно, але робить попередні роздуми важливішими, а не менш важливими, бо зусилля, які раніше змушували питати «а чи справді нам це потрібно?», зникають. Цілком можливо збудувати щось технічно чудове, ефективно здати й виявити, що це була хибна відповідь.

Перш ніж почнеться розробка, ми хочемо мати чіткі відповіді щодо бізнес-проблеми, вартості її невирішеності, вимог, яких наявні продукти не можуть задовольнити, способу вимірювання успіху (час обробки, точність, прозорість, відповідність вимогам, а не кількість функцій) та того, хто експлуатуватиме й підтримуватиме рішення після цього.

Будуть проєкти, де індивідуальне ПЗ очевидно правильне, інші, де інтеграція вигідніша, і треті, де справляється готова платформа. Важливо, щоб рекомендація випливала з розуміння вашої організації, а не з припущення про те, що хоче продати компанія-розробник.

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

Libertas Software Research допомагає організаціям досліджувати, оцінювати, проєктувати й розробляти програмні рішення, роблячи акцент на довгостроковій підтримуваності, операційній цінності та обґрунтованих технологічних інвестиціях.