Шаг 10. Разработчики с уникальной экспертизой - боль бизнеса, которая осталась в прошлом

Разработчик, от которого зависела вся компания

В первый раз я стал свидетелем того, как система зависит от одного программиста, примерно двадцать лет назад. Тогда я работал техническим специалистом в компании Atlas Copco, и как-то на перекуре коллега показал мне на невзрачного сгорбленного мужичка, проходившего мимо.

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

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

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

Но ситуаций, когда разработчик ушёл, а заказчик остался один на один с самописным сервисом, я навидался немало. И это, пожалуй, самая частая беда малого и среднего бизнеса: сайт или система, которые пять лет пилил один человек, а теперь этого человека нет. Ни документации, ни комментариев, ни тестов. Иногда даже доступов нет — они были "у него".

Что изменилось

Такие ситуации теперь в прошлом. Не потому что разработчики стали добрее, а потому что разобрать чужой проект с агентом стало не просто "проще" — это стало быстро и недорого.

Раньше от слова Legacy программистам становилось физически плохо. Разбор чужого кода — самая неблагодарная работа на свете: медленная, скучная, без права на ошибку.

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

И самое интересное — когда ИИ начинает разбирать такой код, всплывает тонна косяков, которые стыдно было делать программисту с заявленным уровнем. Пароли в исходниках, SQL-инъекции, копипаста на две тысячи строк.

Те разработчики, которые раньше могли диктовать условия, теперь нервно курят в сторонке.

Внедрять большую CRM или быстро написать свою?

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

Сегодня развилка выглядит иначе, но однозначного ответа у меня нет. Есть здравый ориентир.

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

Своё решение с агентом имеет смысл, когда:

вам нужно 15% функционала комбайна, а платите вы за 100%;
ваш процесс нестандартный и как раз в этой нестандартности ваше преимущество;
нужно быстро — не "к следующему кварталу", а на этой неделе;
вы не знаете точно, что вам нужно, и хотите пощупать прототип, чтобы понять;
система внутренняя и цена ошибки — это "неудобно", а не "штраф и суд".

Цепочки бизнес-процессов

Самый большой эффект ИИ даёт не в разработке, а в местах, где человек работает "передатчиком данных". Там, где сотрудник берёт информацию из одного места, слегка её обрабатывает и перекладывает в другое.

Типичные цепочки, которые я видел собранными за день-два:

Входящая заявка. Письмо или заявка с сайта → извлечение сути → создание карточки в CRM → назначение ответственного → уведомление в Telegram → напоминание, если через два часа никто не взял.
Документы от контрагентов. Пришёл счёт или акт в PDF → распознавание → сверка суммы и реквизитов с договором → подготовка платёжного поручения → уведомление, если расхождение.
Прайсы поставщиков. Двадцать поставщиков присылают Excel в двадцати разных форматах → приведение к единой структуре → обновление цен → отчёт о том, что изменилось больше чем на 5%.
Резюме и найм. Отклики → извлечение ключевых данных → предварительная сортировка по формальным критериям → черновик вопросов для интервью под конкретного кандидата.
Поддержка клиентов. Вопрос → поиск ответа в базе знаний → черновик ответа → человек проверяет и отправляет. Именно так, а не "бот отвечает сам".
Отчётность. Выгрузки из нескольких систем → сведение → отчёт в одном формате → рассылка руководителям в понедельник в 9:00.

Обратите внимание на общий признак: во всех цепочках финальное решение или проверка остаются за человеком там, где есть деньги и ответственность.

Как оценивать эффект

Чтобы не заниматься автоматизацией ради автоматизации, я смотрю на четыре вещи.

Время. Сколько человеко-часов в месяц уходит на задачу сейчас и сколько останется после. Считать надо честно, включая переключения между задачами и "я забыл, надо переделать". Если экономия меньше 5–10 часов в месяц — скорее всего, не стоит трогать.

Цена ошибки. Что будет, если система сработает неправильно? Есть разница между "отчёт придёт с криво отсортированной колонкой" и "мы отправили деньги не тому контрагенту". В первом случае можно смело автоматизировать полностью. Во втором — только с обязательной проверкой человеком. Это самый важный из четырёх пунктов.

Доступы. Какие данные вы отдаёте наружу и кому. Персональные данные клиентов, финансы, коммерческая тайна — здесь нужен отдельный разговор про то, какая модель используется, где она крутится и что улетает в чужое облако. Универсальное правило: чем чувствительнее данные, тем локальнее должно быть решение.

Стоимость поддержки. Самописный сервис не бесплатен после запуска. Обновления, хостинг, бэкапы, изменения требований. Важный момент: с агентом стоимость поддержки самописного решения упала в разы — именно потому, что больше не нужен уникальный человек, который "помнит, как тут всё устроено".

Здесь от меня всё зависит

Так вот, к вопросу "а нужно ли лично мне держать руку на пульсе и разбираться с ИИ"?

Раньше между вашей идеей и её реализацией стоял посредник: разработчик, интегратор, вендор, отдел IT. Иногда хороший, иногда — заложник и держатель монополии на знание. Вы всегда ждали кого-то.

Сейчас этого посредника в значительной части задач просто нет. И это меняет расклад целиком: результат больше не зависит от того, найдёте ли вы правильного человека. Он зависит от того, готовы ли вы разобраться самостоятельно?