Ваш сайт не падає в день, коли йде розробник. Він починає падати за роки до цього.

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

Це не так.

Насправді збій зазвичай починається роками раніше. Він починається тихо. Пароль зберігається в особистому браузері замість корпоративного менеджера паролів. Сервер налаштовують, але ніхто не документує чому. Продакшн-фікс викочують прямо в п'ятницю ввечері, бо "терміново". Sitemap перестає оновлюватись після редизайну. Search Console починає повідомляти про помилки індексації, але ніхто їх не перевіряє. Розробник створює Git-репозиторій на особистому акаунті, бо так швидше. Інший співробітник налаштовує Cloudflare. Хтось інший купує домен. Маркетингове агентство створює Google Analytics. SEO-фахівець налаштовує Tag Manager. Ніхто не складає карту того, як усі ці частини пов'язані.

Все працює. Компанія росте. Приходять клієнти. Виручка зростає. І оскільки нічого не виглядає зламаним, усі вважають систему здоровою.

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

ЗБІЙ ПОЧИНАЄТЬСЯ

I. Збій починається задовго до того, як хтось його помічає

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

Пізніше стає наступним місяцем. Наступний місяць стає наступним роком. Зрештою компанія виростає настільки, що ніхто вже не пам'ятає, як усе це було зібрано. Люди, що приймали ці рішення, переходять на інші проєкти. Хтось міняє роботу. Хтось йде з індустрії. Хтось зникає повністю. Знання йде разом із ними.

Один із найпам'ятніших прикладів, що пережила наша команда, був викликаний не поганим менеджментом і не внутрішнім конфліктом. Він був викликаний війною.

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

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

Його код залишився. Його знання ні. Не було можливості поставити питання. Не було шансу прояснити архітектурні рішення. Не було можливості відновити незадокументовану інформацію.

Повний проєкт можна побачити в нашому портфоліо: Medpresso.

Цей досвід закріпив урок, що застосовний далеко за межами розробки ПЗ. Бізнес ніколи не повинен залежати від постійної присутності конкретної людини. Не тому що люди ненадійні. Тому що життя непередбачуване.

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

ЕКОСИСТЕМА

Ваш сайт: лише видима поверхня

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

Зрештою сайт перестає бути просто сайтом. Він стає екосистемою. Типовий сучасний бізнес може залежати від десятків взаємопов'язаних систем:

• Реєстратор домену

• DNS-провайдер

• Хостинг-інфраструктура

• CDN

• SSL-сертифікати

• Поштові сервіси

• CRM

• ERP

• Платіжні шлюзи

• Google Analytics

• Google Search Console

• Tag Manager

• Маркетингова автоматизація

• Git-репозиторії

• Пайплайни деплою

• Хмарне сховище

• API

• Сторонні інтеграції

Більшість власників бізнесу думають, що володіють своїм сайтом. Насправді вони володіють складною мережею цифрових залежностей. Сайт, лише видима поверхня. Справжній бізнес живе під нею. І саме там безперервність або продумується, або тихо занедбується. Ми вже писали про те, що насправді означає володіти всією цією мережею, а не лише видимою її частиною, у статті Most Companies Don't Own Their Website. They Own a Collection of Dependencies.

ВТРАТИЛИ СИСТЕМУ

II. Ви втратили не розробника. Ви втратили систему.

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

«Нам потрібен хтось, щоб продовжити підтримувати сайт».

Насправді їм потрібно зовсім інше. Їм потрібен хтось, хто відновить роки незадокументованих рішень. Це не одне і те саме завдання.

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

Чому було обрано саме цю архітектуру? Які інтеграції все ще активні? Які API-ключі все ще дійсні? Де зберігаються бекапи? Як працює деплой? Хто володіє продакшном? Які планові завдання критичні? Які сервіси спілкуються між собою? Навіщо існує ця функція? Який клієнт залежить від цієї недокументованої фічі?

Коли документації немає, кожна відповідь перетворюється на розслідування. А розслідування коштують дорого.

Онбординг нового розробника в незнайому, недокументовану кодову базу зазвичай займає місяць-два, перш ніж він справді стає продуктивним, і це ще оптимістичний сценарій. На добре задокументованій системі цей самий період скорочується драматично, бо відповіді вже існують не лише в пам'яті однієї людини. Ми розбираємо, що насправді зберігає кодова база, а що ні, у статті The Code Remembers Every Version of the Business.

НЕ ОДИН ПРОДУКТ

Сайт, це не один продукт

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

Сам сайт може становити лише малу частину інфраструктури. За ним стоять домени, хостинг-провайдери, DNS-записи, конфігурації CDN, SSL-сертифікати, маршрутизація пошти, платформи аналітики, CRM, платіжні системи, сторонні API, пайплайни деплою, бекапи, маркетингова автоматизація, сервіси моніторингу, репозиторії, хмарне сховище, політики безпеки, планові завдання та незліченні дрібні інтеграції, накопичені за роки.

Більшість цих систем працюють тихо. Поки одного дня не перестають.

Одна ситуація повторюється напрочуд часто. Ми ставимо новому клієнту просте питання. «У вас є документація?» Майже кожен бізнес впевнено відповідає: «Так». Потім надсилають посібник з адмін-панелі, старе технічне завдання, можливо, PDF про те, як додавати пости в блог.

Ніщо з цього не є технічною документацією.

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

Різниця здається невеликою. На практиці вона часто визначає, чи відновиться проєкт за години, чи завмре на тижні. Якщо не впевнений, до якої категорії належить твоя власна документація, саме на це питання відповідає Usability Audit.

АРХЕОЛОГІЯ

Кожен новий розробник починає з нуля

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

Іноді єдина документація, що залишилась, це сам код. Іноді навіть він розповідає лише половину історії.

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

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

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

Ми розбираємо близьку за духом проблему, коли AI дає впевнену відповідь, яку ніхто так і не перевірив, у статті The Cost of AI Isn't Generation. It's Verification.

ВОЛОДІННЯ БЕЗ ДОСТУПУ

«Сайт належить нам». Справді?

Можливо, найнебезпечніше хибне уявлення з усіх: «Сайт належить нам». Юридично це може бути правдою. Операційно, часто ні.

Ми бачили бізнеси, що не могли отримати доступ до власного домену. Не могли увійти в Google Search Console. Не знали, хто керує DNS. Втратили доступ до аналітики. Не мали Git-репозиторію. Не знали, де розміщено продакшн. Не мали інструкцій з деплою. Не мали процедур відновлення. Не мали карти інфраструктури.

Сайт продовжував існувати. Володіння ні.

Бізнес може володіти кожним інвойсом, кожним дизайн-файлом і кожним рядком коду, і все одно не мати операційного контролю над власною цифровою платформою. Це дві абсолютно різні речі.

Саме тому організації рідко втрачають проєкти через відхід розробників. Вони втрачають проєкти, бо критичне знання йде разом із ними. Розробників можна замінити. Знання ні. Принаймні, не без того, щоб заплатити за них двічі. Якщо твій поточний сайт дістався тобі у спадок, а не був побудований з тобою з першого дня, Corporate Website Development, відправна точка, з якої ми почали б повертати це володіння.

ФРЕЙМВОРК

III. The Website Continuity Framework™

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

Складність сама по собі не проблема. Проблема, невидима складність.

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

Розробник звільняється. Агентство закривається. Хостинг-провайдер змінює політику. Платіжний шлюз оновлює API. Сервер падає. Ключовий співробітник йде на пенсію. Починається війна. Зникає ноутбук.

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

За роки ми помітили, що стійкі цифрові бізнеси розділяють одну спільну рису. Вони не залежать від людей. Вони залежать від систем.

Це важлива відмінність. Люди залишаються незамінними. Але знання належить організації. Не окремим людям.

Кожне критичне рішення можна відстежити. Кожна важлива інтеграція задокументована. Кожне продакшн-середовище можна відновити. У кожного пароля є власник. У кожного сервісу є призначення. У кожного деплою є процес.

Якщо завтра вся команда зникне, інша кваліфікована команда зможе продовжити роботу. Не тому що знає проєкт. Тому що проєкт знає сам себе.

Ця ідея лягла в основу того, що ми тепер називаємо Website Continuity Framework™. Він складається з п'яти областей, що кожен зростаючий бізнес має постійно підтримувати.

1. ВОЛОДІННЯ

1. Володіння

Чи може твоя компанія довести операційне володіння кожним критичним цифровим активом? Не лише юридично. Практично. Хто контролює домен? DNS? Хостинг? Git-репозиторії? Cloudflare? Google Analytics? Search Console? Платіжних провайдерів? Поштову інфраструктуру?

Володіння, це не контракт. Володіння, це безперервний доступ.

Коли цей доступ проходить через зовнішню команду, варто почитати про IT Outsourcing & Outstaffing, конкретно про те, як володіння має бути оформлене контрактно, а не лише технічно.

2. ДОКУМЕНТАЦІЯ

2. Документація

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

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

3. ОПЕРАЦІЙНА СТІЙКІСТЬ

3. Операційна стійкість

Чи може поточна робота продовжуватись без конкретної людини? Чи можливі релізи? Чи можна лагодити баги? Чи можна відновити бекапи? Чи можна впоратись з інцидентом безпеки? Чи можна мігрувати інфраструктуру?

Якщо відповідь залежить від однієї людини, у бізнесу є ризик безперервності. Ми розбираємо, як залучати зовнішню допомогу, не створюючи ту саму залежність заново, у статті How to Hire a Remote Dev Team Without Getting Burned.

4. ТЕХНІЧНА СТІЙКІСТЬ

4. Технічна стійкість

Технології ніколи не стоять на місці. Версії PHP застарівають. Фреймворки перестають отримувати оновлення безпеки. Бібліотеки втрачають підтримку. Браузери еволюціонують. Пошукові системи змінюються. AI-процеси розробки продовжують переформатовувати саму інженерію.

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

Ігнорування підтримки не заморожує технологію. Воно просто відкладає рахунок.

Вибір фреймворку зазвичай і є головним фактором, що визначає розмір цього рахунку роками пізніше, ми розбираємо це у статті Laravel vs Symfony: The Most Expensive Technology Decision Is Often the One You Never Make.

5. ЗНАННЯ ОРГАНІЗАЦІЇ

5. Знання організації

Можливо, найбільш недооцінений актив всередині будь-якої компанії, інституційне знання. Чому була побудована ця функція? Чому існує ця інтеграція? Чому не було обрано інше рішення?

Ці відповіді рідко існують всередині вихідного коду. Вони існують у пам'яті людей. Поки не задокументовані.

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

Одне спостереження супроводжувало нас через сотні розмов з клієнтами. Бізнеси майже ніколи не інвестують надто мало в розробку, бо їм байдуже. Вони інвестують надто мало в безперервність, бо не знають, що вона взагалі існує.

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

ЕРА AI

Безперервність важлива ще більше в епоху AI

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

Компанії, що отримують від AI найбільше користі, не обов'язково ті, у кого найновіші технології. Це ті, у кого найзрозуміліші системи. Структурована документація. Послідовна архітектура. Чисті репозиторії. Задокументовані бізнес-правила. Передбачувані процеси.

AI не усуває потребу в організаційному знанні. Він винагороджує організації, що його зберігають.

Ми зіткнулись саме з цим розривом самі, набагато пряміше, ніж очікували, у статті Four AIs Agreed. We Still Hadn't Verified Anything.

Зрештою кожен сайт доходить до точки, де постає просте питання. Не «Чи може ця платформа масштабуватись?» Не «Чи можемо ми її редизайнити?» Не «Чи варто перейти на інший фреймворк?»

Реальне питання набагато простіше.

Чи зможе цей бізнес продовжувати рости, якщо люди, що побудували сьогоднішню систему, завтра тут не опиняться?

Все інше вторинне.

ФІНАЛЬНА ДУМКА

Фінальна думка

Сайт, це не набір сторінок. Це не CMS. Це не фреймворк. Це не хостинг-акаунт. Це навіть не вихідний код.

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

Компанії, що це розуміють, не просто підтримують сайти. Вони захищають один з найцінніших бізнес-активів.

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

Автор: Євген Боровий, засновник Peretz Agency.