API для смысла. Рассказ.

Когда в компании внедрили семантический слой, Ольга первой сказала: «Будет красивая фигня». Она работала инженером по данным уже шестой год и успела пережить три ребрендинга корпоративных ценностей, два внедрения Agile и одно «давайте просто общаться лучше». Семантический слой был поставлен вендором, который на демо показывал, как Slack сам превращает «надо пофиксить авторизацию» в тег «authentication-fix» с приоритетом. Генеральный тогда встал и сказал: «Это будущее». Ольга промолчала. Ей платили не за споры.

Будущее наступило через неделю. Slack запестрел тегами: deliverable, roadmap-item, ASAP, Q4-goal. В таск-трекере карточки обрастали ими, как днище лодки ракушками. Только задачи не делались. Тестировщики — трое вымотанных людей, которые пили кофе литрами и уже не верили ни в какие улучшения, — первыми подняли шум. Половина тикетов с deliverable содержала в описании строку «нужно сделать интеграцию» и больше ничего. Не было ни endpoint’ов, ни критериев, ни ответственного за приёмку. Менеджер, который раньше хотя бы ворчал в личке, теперь просто нажимал кнопку «создать deliverable» и шёл на кофе. Мониторинг выл красным, но никто не разбирал инциденты — все были заняты перекладыванием карточек из колонки в колонку с красивыми тегами.

Ольгу попросили «посмотреть, что можно сделать с данными». Она пошла не к данным, а к тестировщикам. Села напротив, спросила: «Что вам реально нужно, кроме тегов?» Старший тестировщик, Сергей, мужик с лицом человека, который видел продакшен в час ночи, ответил: «Чтобы они писали, что делать и как проверять. Хотя бы тупо: нажать эту кнопку — увидеть это». Ольга кивнула и за вечер написала скрипт на Python, который работал как прокси между корпоративным ботом и Jira. Логика была примитивной: когда кто-то через бота создаёт задачу с типом deliverable, скрипт требовал заполнить два поля — «описание конкретного действия» и «способ проверки». Если поля пусты или содержат меньше двадцати символов, бот не создавал задачу, а задавал уточняющий вопрос обратно в чат. Никакого машинного обучения, только регулярки и счётчик символов.

В первый день случился не конфликт — холодная война. Менеджер отдела доставки, Игорь, привыкший генерировать по десять deliverable в неделю, наткнулся на вопрос бота: «Что конкретно должно быть сделано? Как именно мы проверим результат?» Он написал: «Сделать интеграцию с CRM». Бот ответил: «Уточните: какая интеграция? Какие системы затронуты? Критерий успеха?» Игорь написал: «Интеграция с CRM. Успех — она работает». Бот не принял. Игорь пошёл к руководителю Ольги. Сказал, что инструмент блокирует бизнес-процессы. Руководитель вызвал Ольгу. Она молча открыла лог и показала: из последних пятнадцати deliverable Игоря двенадцать не имели ни одного критерия проверки, восемь были переоткрыты тестировщиками минимум дважды. Руководитель, который сам боялся не уложиться в OKR, сказал: «Оставь пока. Но если ещё одна жалоба — отключаем».

Ольга вернулась за стол и добавила в скрипт минимальную длину текста в полях — пятьдесят символов. На следующий день Игорь вписал в «способ проверки»: «проверим, что интеграция работает корректно и без ошибок». Пятьдесят два символа. Бот пропустил. Задача ушла в бэклог. Тестировщики Сергея, открыв карточку, выматерились, но промолчали. Они уже привыкли, что любой инструмент в этой компании превращается в ритуал.

Через месяц к боту адаптировались. Менеджеры выучили паттерны: «что сделать» всегда начиналось с «Реализовать возможность…», «как проверить» — с «Убедиться, что функциональность соответствует ожиданиям». Семантический слой исправно вешал тег deliverable. Внешне всё выглядело прекрасно: в карточках появились заполненные поля, отчёт для руководства показывал рост дисциплины. Ольга смотрела на логи скрипта и видела, что процент уникальных последовательностей символов стремится к нулю. Задачи по-прежнему переоткрывались — но теперь у каждой стоял штамп «проверено» с формальной отмазкой.

Прорыв случился не там, где ждали. Продуктовый топ-менеджер, тот самый, что на all-hands говорил про инновации и красивые deliverable для инвесторов, лично создал задачу: «Подготовить отчёт к квартальному файналу». Бот спросил про конкретику. Топ раздражённо написал: «Автоматический отчёт по загрузке CPU, latency, error rate. Проверка — стандартная». И улетел на встречу. Позже выяснилось, что «стандартная» означало: инвесторы увидят графики, которые менеджер топ-уровня даже не открывал. Их нарисовала смежная команда по старым скриншотам. Отчёт приняли. Никто не заметил, что данные в нём были трёхнедельной давности.

Ольга к тому моменту перестала верить в цифры. Она добавила в скрипт детектор стоп-слов: «корректно», «функциональность», «соответствует ожиданиям». При появлении этих фраз бот требовал переформулировать. Игорь написал коллективную жалобу в HR: «инструмент демотивирует и создаёт токсичную среду». Ольгу вызвали на ковёр, попросили «смягчить проверки». Она смягчила. Убрала детектор. Оставила только проверку на пустоту.

Через полгода тестировщик Сергей уволился. В прощальном письме он написал: «Ребята, вы научились создавать красивые карточки. Научитесь, пожалуйста, создавать работающий софт. Поля „как проверить“ недостаточно, если вы потом не смотрите на результат». Ольга прочитала это письмо в опенспейсе, где пахло перегретым пластиком и чьим-то обедом. На мониторе висела очередь задач с тегом deliverable. В каждой в поле «способ проверки» значилось: «проверим по факту выполнения». Скрипт тихо работал, накручивая счётчик «успешно созданных структурированных задач».

Ольга закрыла крышку ноутбука и пошла курить с коллегами из техподдержки. Они обсуждали, как завтра будут презентовать дашборд «зрелости процессов» на основе заполняемости полей. График шёл вверх. Компания выглядела зрелой.

Где-то в глубине Jira API для смысла всё ещё отвечал на запросы. Но запросы давно никто не читал. Их просто создавали, тегировали и закрывали.