Личный проект, ставший единственной работой: скрипты, которые умеют говорить "нет", ночные прогоны, которым запрещено чинить, и люди, которые смотрят туда, куда тесты не умеют.

Девятнадцать лет я в ИТ, и почти все это время я был по ту сторону инструментов, которыми работают другие люди. Начинал с "принеси-подай", дорос до линуксового сисадмина, потом руководил системными администраторами. Потом сменил направление на техподдержку и, наконец, возглавил IT департамент международной финтех-компании: пятнадцать человек в команде, полторы тысячи сотрудников в тридцати странах, полсотни сервисов и сто тридцать интеграций, за которые кто-то должен отвечать. Должности менялись, одно не менялось: каждый день кто-то приходил ко мне с претензией к инструментам, в которых он вынужден работать.

Первое, что вспоминается из этих лет: день, когда пришел четкий приказ мигрировать наш трекер из серверной версии в облако, а дальше тишина. Не буду скрывать, это была Jira. Направления нет, и я хожу с мыслью "а что делать", пока готовлю почву: поддержка Атлассиана, реселлеры, условия подписки, все медленно, всем не очень интересно. На середине подготовки выясняется, что их инструмент миграции просто не работает, и огромную часть данных компании придется таскать руками. Клон прода, чистка данных, огромные батчи через scp на мой лэптоп, только чтобы честно повторить боевые данные в тестовой миграции. Вторым разочарованием оказался маркетплейс: аппы, с которыми мы годами жили без задней мысли, в облаке не существовали, ни они, ни их аналоги. Мы привыкли к ним как к части продукта, а они оказались просто чужим кодом, который никому ничего не должен. Миграцию мы дожали, техническую часть за три дня, а юридическую и финансовую почти за три недели (что было самой большой победой), и даже выбили сорок процентов скидки на три года. Но я запомнил не победу. Я запомнил вывод: такие инструменты должны быть гибче и при этом проще.

Все эти годы ко мне ежедневно приходили команды и описывали одно и то же разными словами: нарушенные договоренности, потерянные договоренности, сломанные права, кривые настройки, бесконечное ожидание доступов, бюрократия и непрозрачность процессов. Последние два года, уже директором IT, я проводил на звонках до двадцати пяти часов в неделю, днем и ночью: стратегия, инциденты, бюджеты, и это нормальная часть роли. Я не воюю с голосом: один на один со своими ребятами я считаю обязательными, а в департаменте держал простое правило "нужен звонок: скажите, обсудим голосом". Но заметная часть тех двадцати пяти часов была звонками другого сорта и исходили они от соседних департаментов. И их действительно могли заменить пара абзацев в документации и один тикет. С тех пор я убежден, что нет ничего лучше корректно оформленной задачи и правильного движения по воркфлоу: инженеры заняты своей работой, не очень полезный звонок исчезает, а след остается в документации и тикетах.

Так появился Quevell: трекер задач, проекты, оргчарт и кросс-командная работа в одном месте, где приватность и прозрачность существуют одновременно, а каждое действие остается в журнале, кем бы ты ни был: постоянным админом, временным, доверенным пользователем, человеком или агентом через MCP. 

Это мой продукт, он платный, и недавно он стал моей единственной работой. Я его делаю, потому что мне не все равно: я не могу видеть, когда к процессам относятся наплевательски, и никогда не мог. Эта статья про то, как один человек держит планку продакшна, и про то, что я понял в процессе разработки.

Как это собрано

Про использование ИИ в 2026 году уже неловко рассказывать как про достижение: это фон, на котором работают все. Поэтому скажу как есть, без гордости и без стеснения: примерно десятая часть продуктового кода написана моими руками, еще примерно десятая часть тестов тоже, а все остальное реализовали агенты. Проценты от разных баз, складывать их в двадцать не надо. И если вам кажется, что при таком раскладе продукт "написал ИИ", то вы просто еще не видели, из чего состоит оставшаяся часть работы.

Сначала о том, что вообще собираем, чтобы дальше было предметно. Бэкенд на Kotlin, Postgres с изоляцией компаний на уровне строк, объектное хранилище для вложений, фронт на TypeScript. Сейчас это более сорока тысяч строк продуктового кода, полторы сотни миграций базы и несколько сотен тестов на каждый слой, от серверной логики до проверок живого сервера по HTTP. Через этот каркас проходит каждая строка, независимо от того, писал ее я или агент. Работа начинается со спецификации, в которой кроме "что сделать" всегда есть раздел "чего не делать" и критерии приемки: без них агент с одинаковым энтузиазмом сделает и нужное, и лишнее. Агент реализует, я разбираю дифф. Дальше verify.sh: одна команда, которая гоняет все тесты и проверки разом и обязана быть зеленой перед любым слиянием. Потом стейдж, и только после моего ревью и явного слова прод: скрипт выкатки физически отказывается везти на прод коммит, которого не было на стейдже.

Но каркас из скриптов закрывает только половину задачи. Вторая половина это решения, и с ними у одного человека проблема хуже, чем кажется: спорить не с кем, а забывается все (даже если у вас очень хорошая память). Поэтому каждое архитектурное решение оформляется как ADR (architecture decision record: короткий документ, где записаны контекст, само решение и причины, по которым отвергнуты остальные варианты). Их сейчас уже за полсотни, и это не бюрократия ради бюрократии, а единственный способ не спорить с самим собой по второму кругу через месяц. Когда через полгода возникает вопрос "почему здесь так", ответ не восстанавливается по памяти, он лежит написанным, вместе с отвергнутыми вариантами. И когда решение меняется, старый ADR не переписывается: к нему добавляется поправка, чтобы было видно не только текущее состояние, но и то, как оно менялось. По ночам по продукту ходит аудитор, которому запрещено чинить. Автономный прогон гоняет мутационное тестирование, перебирает все маршруты неавторизованным клиентом, щупает периметр, сверяет документацию с кодом, и все, что находит, только записывает. Правило "находить и записывать, не чинить без спроса" появилось не из недоверия к скриптам и агентам, а из простого соображения: находка это информация, а исправление это уже решение, и решения в этом продукте не принимаются в четыре утра без владельца. Утром меня ждет отчет с находками по критичности, и я разбираю его как почту от ооочень дотошного коллеги, который работал всю ночь.

Насколько это работает, показал случай, который я до сих пор считаю самым неприятным за все время. Временные права администратора выдаются на срок и снимаются сами, это одно из главных обещаний продукта. И вот выясняется, что пользователь, которому выдали такие права, может сам понизить себе роль до обычной, и права при этом остаются: проверка спрашивала, жив ли выданный доступ, и не спрашивала, жива ли роль. Две системы истины про одно и то же, и вторая никогда не была проверена. Хуже того, тем же путем компанию можно было оставить вообще без администратора, потому что защита "последнего администратора" считала не то множество людей, которое проверял вход.

Все тесты при этом были зелеными. Каждый из них проверял свою систему истины, и каждый честно ее подтверждал. Такие находки лечатся не заплаткой на найденный сценарий, а решением: теперь администратор это ровно одно, членство в группе, и все пути, где раньше спрашивали роль, спрашивают его. Это, кстати, отдельный ADR, и в нем записано не только что теперь так, но и почему раньше было иначе.

Про эту дыру я узнал не от тестов и не от ночного прогона. Ее нашел человек.

Приемка, которую не заменить прогонами

Точнее, человек, который прошел продукт как обычный пользователь, а не как его автор. Весь мой контур проверяет систему изнутри: тесты, прогоны, периметр. Снаружи ее не проверял никто, пока приемку не взял на себя профильный пользователь с максимальными ожиданиями, который случайно живет со мной. Моя жена по профессии проджект-менеджер, то есть человек, у которого от поведения досок, уведомлений и прав зависит рабочий день, а по образованию лингвист, и второе оказалось не менее важным, чем первое. Она завела настоящий второй аккаунт и прошла продукт тремя уровнями доступа, от обычного пользователя до администратора. Главную находку я запомню надолго, потому что она была не багом, а признанием, которое мне пришлось сделать самому себе: я написал инструмент, но не реализовал его исполнение по доставке. Упоминания в комментариях исправно записывались в базу, механизм учета работал, а события доставки уведомления за ними просто не существовало: тебя упомянули в тикете, а уведомление не пришло и во входящих почты пусто. То же самое вскрылось с правами: документация обещала письмо о решении по запросу доступа, механизм решений работал, письма не было. И вот что важно: все тесты при этом были зелеными, потому что тесты проверяли механизм, а не обещание пользователю. Ни один ночной прогон не нашел бы этого никогда.

Лингвистическое образование ударило по другому месту. Документацию писал человек, который построил систему, и это хуже, чем звучит: для меня каждая фраза была очевидной, потому что за ней стоял код. "Да потому что так работает" это не ответ пользователю, это единственное, что автор системы может сказать о ней изнутри. Нужен был кто-то, кто читает снаружи, и жена читала именно так: ловила кальки, термины, которые в интерфейсе называются одним словом, а в документации другим, и формулировки, которые понятны только тому, кто уже знает ответ. За один проход такой приемки набралось больше тридцати замечаний, от продуктовых дыр до формулировок, и почти каждое было того сорта, который не находится изнутри. Тесты находят дыры внутри систем. Человек в другой роли находит дыры между системами: между продуктом и обещанием, между интерфейсом и документацией, между тем, что записано, и тем, что доставлено.

Каждая крупная возможность с тех пор проходит и ручную проверку на пяти операционных системах: Windows на домашнем ПК и лэптопе, macOS, Linux, iOS и Android. Дешевый ритуал поверх автотестов, который ловит класс проблем, невидимый ни юнитам, ни прогонам: верстку, локали, поведение браузеров. Даже при всем этом что-то проскакивает, я это знаю и говорю прямо: мелкие баги и проблемы в интерфейсе все еще существуют. Правило на такие случаи одно, то же, что у ночных находок: найденное чинится причиной и механизмом, а не заплаткой. Упоминания после той приемки заработали не костылем поверх, а расширением словаря событий, с дефолтными правилами доставки для всех компаний сразу.

Что из этого стало продуктом

Теперь о том, что весь этот каркас произвел на свет, и я расскажу не каталогом возможностей, а по тому самому списку, с которого продукт начался.

Помимо постоянных прав администратора продукта есть еще и временные. Временное администрирование в Quevell выдается на срок и снимается само. Сколько раз вы воевали с держателями админок за "не знаю, не видел" и "запроси правильно"? Выданная на час админка равна выданной навечно: обещание "гляну и верну" не имеет механизма исполнения, а запрос доступа превращается в переписку о форме запроса. Здесь это устроено иначе: запрос, одобрение, срок, автоматическое снятие, и каждое из четырех в логах.

Уход человека это передача дел, а не удаление учетки. Оффбординг я много лет проживал с нескольких сторон: как владелец процесса и как человек, которого просят "быстро удалить учетку". Быстро удаленная учетка это осиротевшие задачи, роли-призраки и правила автоматизации, работающие (или тихо умершие) от имени того, кого нет. В Quevell администратор видит все, что числится на пользователе, передает преемнику одним действием, а удаление заблокировано, пока за человеком хоть что-то числится. Владение передается, авторство никогда.

Структура компании складывается из профилей людей и меняется вместе с ними. Есть возможность выводить на оргчарт любые поля профилей сотрудника: должность, команду, менеджера и т.д. У схемы нет отдельной жизни, поэтому она не устаревает: назначили нового руководителя, дерево перестроилось. Работает и через API.

Рабочие схемы (так в Quevell называются воркфлоу проекта) живут ревизиями, которые нельзя переписать задним числом: правишь черновик, публикуешь, и у вопроса "кто и когда сломал процесс" всегда есть ответ, включая возврат к прошлой ревизии одним действием. Журнал изменений под всем этим пишется сам и отвечает на "кто это передвинул и что изменилось" одним запросом, включая вход администратора от имени пользователя: такая запись хранит оба имени. Годы рядом с аудитами приучили меня к тому, что "не записано" означает "не было".

Автоматизация обязана объяснять себя. Правило можно проверить на живых данных без последствий: проверка проходит через настоящий движок и откатывается, а у каждого срабатывания есть ответ, почему оно случилось и почему не случилось. Правил, которые "сработали, и никто не знает почему", в том списке было больше одного.

И дверь для агентов, раз уж они пишут большую часть кода: Quevell говорит с ними по MCP и стандартному OAuth. Сервисные аккаунты заводятся в админке компании, у каждого свои права, токены и OAuth-клиенты. Агент видит ровно то, что видел бы человек с его правами, каждое его действие ложится в тот же журнал с пометкой агента, а токен агента это обычный токен продукта: отзыв клиента убивает все, что тот выдал. Никаких обходных API с божественными правами. Поток с браузерным согласием для ассистентов вроде Codex и Claude в очереди, врать не буду.

Все это описано: четырнадцать статей документации на русском и английском, включая справочник API и язык запросов, и каждое утверждение в них сверяется с кодом отдельной проверкой при сборке сайта.

Под всем этим мультитенантность с изоляцией на уровне строк базы и двухфакторная аутентификация с резервными кодами, политикой компании "требовать второй фактор" и защитой от перебора. Свой типизированный язык запросов, у которого время выполнения предсказуемо и не зависит от формулировки. Канбан и Скрам доски со спринтами и учетом времени для тех, кто работает итерациями. Цены живут в самом продукте, в разделе биллинга: там калькулятор честно считает вашу конфигурацию, а триал на тридцать дней как раз позволяет понять, сколько мест и сервисных аккаунтов вам на самом деле нужно.

И это далеко не полный список того, что уже есть: статья не каталог, полный я сюда не потащу. Продукт растет постоянно, но растет в адекватном формате: тот самый вывод из миграции, гибче и при этом проще, работает здесь правилом отбора. Я не создаю монстра.

И чтобы закрыть вопрос серьезности: продакшн живет в российском дата-центре, а не у меня в подвале, данные не покидают страну, а за продуктом стоит ООО с офертой и политикой обработки персональных данных, которые прошли вычитку живых юристов с реальной практикой. Все официально, и это не шутки. Про то, как один человек открывает ООО и что у него при этом происходит с налоговой, упрощенкой и бухгалтерией, Роскомнадзором, как-нибудь расскажу отдельно: приключений там набралось на свою статью.

Что я понял

На продукт сейчас уходит около четырнадцати часов в сутки, а думается о нем все двадцать четыре: совет по тайм-менеджменту из этого не получится. Страшно ли было менять директорское кресло на продукт без единого клиента: конечно. Но список, который копился девятнадцать лет, либо закрывают, либо носят с собой дальше. И именно этот режим окончательно объяснил мне, зачем нужно все, что описано выше. Планка держится не героизмом. Она держится скриптами, которые умеют сказать мне "нет", отчетами, которые нельзя подделать, и людьми, которые смотрят туда, куда тесты не умеют.

Куда это растет, я примерно вижу, но обещать буду то, что прошло тесты. Продукт живой, регистрация открыта, триал не просит карту: если в этом тексте вы прочитали что-то близкое вам, зайдите и посмотрите сами на quevell.com.

И последнее.

Девятнадцать лет ко мне приходили люди и рассказывали о своих технических испытаниях. Я по этому, как выяснилось, скучаю. Напишите мне, с какими сложностями встречаются ваши команды, здесь в комментариях или на почту с сайта: читаю все.