Ваші найкращі розробники не працюють в ІТ

Десь у вашій компанії є квиток, схожий на цей.

Він був створений у березні 2023 року. У ньому запитується щось скромне: один екран з цифрами, які команда переглядає кожного тижня. Пріоритет "Середній" і ніколи не змінювався. Поле призначення порожнє. Нижче особа, яка відкрила запит, тричі чемно запитала, чи він ще в дорожній мапі. Останнє з цих питань було у червні 2026 року. Ніхто не відповів.

Тим часом ця команда відновлює той самий звіт вручну в електронній таблиці кожного понеділка вранці.

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

Податок на переклад

Ось як зазвичай створюється внутрішнє програмне забезпечення.

Хтось має потребу. Вони перекладають цю потребу на письмовий запит, перетворюючи професійні знання на слова, які хтось з іншої професії повинен інтерпретувати. Запит потрапляє в чергу, де конкурує з усім іншим, за що відповідає ІТ — і більшість з цього є критичнішим. Через кілька місяців хтось, хто не виконує цю роботу, створює інструмент для людей, які це роблять, на основі документа, написаного кимось, хто не створює програмне забезпечення. Результат — це наближення. До того часу, коли інструмент прибуває, процес, для якого його створили, змінився. І запит на виправлення означає початок з першого кроку.

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

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

Клієнт завжди був у будівлі

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

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

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

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

Це не про заміну вашого ІТ-відділу

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

У цій моделі ІТ не зменшується. Воно переходить на вищий рівень. Завдання перестає бути "написати кожну частину програмного забезпечення у компанії" і стає "зробити можливим для всіх інших писати програмне забезпечення безпечно". Конкретно, це означає чотири речі.

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

**Встановити кордони.** Вирішіть, що співробітники можуть будувати, а що — ні. Які дані можна чіпати, що ніколи не повинно покидати певну систему, де інструмент може працювати. Записано, а не передбачено.

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

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

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

Що йде не так і як цього уникнути

Ми б краще розповіли вам про режими відмов заздалегідь, ніж ви виявите їх самі.

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

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

**Будівництво неправильних речей.** Все, що стосується грошей, персональних даних, регульованих процесів або виробничих систем, залишається у професіоналів. Корисним тестом є не "чи може ІІ це побудувати," а "що станеться, якщо це буде тихо неправильним протягом трьох місяців?" Якщо відповідь серйозна, це не є кандидатом.

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

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

Як почати

Якщо ви хочете перевірити це, не ставлячи на це чогось значного, послідовність проста.

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

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

Де ми входимо в гру

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

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

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

Напевно, настав час дозволити їм будувати його.