Первый результат теперь появляется раньше, чем готова система
Раньше между идеей и работающим прототипом мог пройти заметный отрезок времени. Нужно было описать задачу, спроектировать интерфейс, реализовать хотя бы основной сценарий и только потом показать его пользователям.
ИИ в разработке программного обеспечения уже сократил эту дистанцию. Разработчик быстрее разбирает существующий код, готовит типовые фрагменты реализации и тесты. Бизнес может раньше получить прототип и проверить гипотезу, не вкладываясь сразу в полноценный проект.
Из-за этого меняется само восприятие разработки. Если личный кабинет уже открывается, пользователь авторизуется, отправляет заявку и видит историю операций, кажется, что основная работа сделана.
Но прототип отвечает прежде всего на вопрос: работает ли задуманный сценарий? Для корпоративной системы нужно ответить на другой набор вопросов: откуда берутся данные, что происходит при сбое, кто имеет доступ к информации, как решение взаимодействует с другими системами и что будет происходить после запуска.
Реальные данные быстро усложняют простую логику
На этапе прототипа данные часто существуют в максимально удобном для разработки виде. Их можно внести вручную, загрузить из тестового файла или хранить внутри самого сервиса. В рабочем ИТ-ландшафте такой свободы обычно нет.
Например, сведения о клиенте могут одновременно находиться в CRM, учётной системе и личном кабинете. Тогда нужно решить, какая система считается основным источником, откуда приходят изменения и что произойдёт, если информация в двух системах расходится. Похожая ситуация возникает с заказами, остатками, статусами документов, финансовыми операциями и другими сущностями, которыми одновременно пользуются несколько систем.
Технически получить данные через API можно довольно быстро. Гораздо сложнее определить правила их жизни: кто отвечает за достоверность, кто может менять информацию и какая система имеет приоритет при конфликте.
Интеграция — это больше, чем подключить API
Первую интеграцию тоже можно собрать достаточно быстро. Новый сервис отправляет запрос, получает ответ и показывает пользователю результат. Но в промышленной эксплуатации важнее другой сценарий: что произойдёт, когда ответ не придёт?
CRM может быть недоступна. Внешняя система может отвечать медленнее обычного. Запрос может выполниться дважды. Данные могут сохраниться в одной системе, но не попасть в другую.
Тогда нужно определить, следует ли повторять запрос автоматически, ставить операцию в очередь, откатывать изменения, показывать пользователю ошибку или позволять ему продолжить работу. Чем больше систем участвует в одном бизнес-процессе, тем больше таких зависимостей приходится учитывать.
Поэтому сложная интеграция — это не только обмен данными между двумя API. Это ещё и правила поведения всей цепочки, когда один из её элементов работает не так, как ожидалось.
Бизнес-правила становятся важнее скорости написания кода
ИИ ускоряет работу с уже сформулированной задачей: может структурировать исходные материалы, подготовить черновик требований, предложить варианты реализации или помочь описать пользовательские сценарии. Но есть принципиальная разница между тем, чтобы оформить решение, и тем, чтобы принять его.
Представим, что компания автоматизирует согласование заявки. В какой последовательности она должна проходить подразделения? Кто может вернуть её на предыдущий этап? Может ли один сотрудник одновременно создавать и согласовывать заявку? Что происходит после изменения суммы?
Если ответов нет у бизнеса, модель тоже не знает правильного варианта. Она может предложить логичную схему, но это будет предположение.
Такое предположение важно проверить до того, как оно ляжет в основу реализации. Поэтому при подготовке сложной системы стоит заранее зафиксировать бизнес-правила, ограничения и критерии результата. Подробнее мы разбирали эту часть работы в материале о том, как готовить ТЗ для разработчиков.
Основной сценарий — только часть эксплуатации
При создании прототипа логично начинать с ситуации, в которой всё работает правильно: пользователь вошёл в систему, нужные данные доступны, интеграция ответила, операция успешно завершилась. В эксплуатации значительную часть сложности создают исключения.
Пользователь дважды нажал кнопку оплаты. Данные изменились одновременно в двух системах. Сотрудник начал операцию, но потерял доступ до её завершения. Внешний сервис принял запрос, однако подтверждение не вернулось.
Для каждого такого случая нужно заранее определить поведение системы: что делать при повторном запросе, как восстановить состояние после сбоя, какие действия записывать в журнал и что увидит пользователь при ошибке.
Именно поэтому два продукта с похожим интерфейсом могут сильно различаться по трудоёмкости разработки. Пользователь видит одинаковую кнопку, но за ней может находиться либо один простой запрос, либо цепочка действий с проверками, повторными попытками, журналированием и восстановлением состояния после ошибки.
Когда появляются роли, система перестаёт быть «небольшим сервисом»
Небольшой внутренний инструмент может начинаться с нескольких пользователей, для которых достаточно одинакового доступа. По мере развития роли обычно расходятся.
Одни сотрудники только просматривают данные. Другие их изменяют. Третьи согласуют операции. Руководитель может видеть информацию по всему подразделению, а конкретный менеджер — только по своим клиентам. Внешний пользователь при этом должен видеть только доступные ему данные и действия.
В результате модель прав становится частью архитектуры. Нужно не просто спрятать несколько кнопок в интерфейсе, а ограничить действия и данные на уровне системы.
Если решение изначально создавалось как небольшой прототип без такой модели, переход к полноценной эксплуатации может потребовать заметной переработки.
Пять пользователей и пятьсот пользователей создают разные задачи
Ещё одно различие между прототипом и промышленной системой — условия, в которых они работают. Сервис может отлично показывать себя во время демонстрации и при этом начать замедляться после подключения реальных пользователей.
Причина не всегда только в их количестве. Нагрузку создают массовые операции, обмен данными между системами, фоновые задачи, отчёты, загрузка файлов и обращения к внешним сервисам.
Поэтому производительность нельзя полностью оставить на финал проекта. Если система должна работать с большим объёмом данных или выдерживать пиковую нагрузку, эти ограничения влияют на технические решения ещё до написания значительной части кода.
ИИ ускоряет и правильные, и ошибочные решения
Ускорение разработки само по себе не увеличивает цену ошибки. Напротив, благодаря прототипированию многие неудачные гипотезы теперь можно обнаружить раньше и дешевле. Проблема возникает, когда непроверенное предположение принимают за правильное правило и строят вокруг него остальные части системы.
Допустим, команда неверно поняла алгоритм расчёта. На его основе появились требования, реализация и тесты. Тесты могут успешно проходить, потому что проверяют именно ту логику, которая была записана в спецификации.
Позже к ней добавляются интеграции и другие сценарии. И только после сверки с реальным бизнес-процессом выясняется, что неверной была сама исходная постановка.
Исправлять приходится уже не одну строку требований.
Поэтому в проектах с активным использованием ИИ особенно важными становятся решения, которые принимаются до реализации.
Когда инхаус разработка требует полноценной команды
Пока сервис решает ограниченную задачу для небольшого числа пользователей, его действительно иногда можно развивать силами одного специалиста или небольшой внутренней команды. Граница начинает сдвигаться, когда решение становится частью критичного бизнес-процесса.
Появляются разные зоны ответственности: нужно разбираться в требованиях, принимать технические решения, проектировать интеграции, тестировать сценарии, контролировать качество и сопровождать систему после запуска. Это не означает, что каждому проекту нужна большая команда.
Смысл в другом: производство кода — только одна из функций разработки. И чем сложнее система, тем меньше вероятность, что один человек постоянно сочетает все необходимые компетенции.
Инхаус vs аутсорс: куда передать следующий этап
Когда прототип подтвердил идею и проект переходит к промышленной разработке, возникает организационный вопрос: кто будет отвечать за дальнейшее развитие.
Инхаус разработка даёт преимущество там, где система тесно связана с ежедневной работой бизнеса. Внутренняя команда постоянно сохраняет контекст, быстрее получает обратную связь и может оперативно реагировать на изменение приоритетов.
Аутсорсинг разработки полезен, когда проекту нужны компетенции, которых нет внутри компании, либо полноценную команду необходимо подключить быстрее, чем её получится собрать через найм. Например, отдельной экспертизы могут потребовать сложная миграция, модернизация существующей архитектуры, интеграция нескольких систем или работа с производительностью.
При этом необязательно выбирать одну модель для всего проекта. Инхаус разработка может отвечать за продуктовые решения, знания о бизнес-процессах и управление приоритетами, а внешней команде можно передать отдельный модуль, интеграцию или законченный контур модернизации.
Если используется аутсорсинг разработки, значение имеет не только стоимость команды. Важно понимать её опыт, состав, подход к оценке и ответственность за результат. Этому мы посвятили отдельный материал о выборе подрядчика на разработку программного обеспечения.
ИИ меняет требования к разработке, а не отменяет их
AI-инструменты уже используют для анализа существующего кода, подготовки типовых фрагментов, тестов и документации. Поэтому сам факт «мы используем ИИ» всё меньше говорит о качестве подрядчика или внутренней команды. Для проекта важнее результат: действительно ли благодаря новым инструментам сокращаются сроки отдельных этапов, как контролируется сгенерированный код и кто принимает технические решения.
Не стоит ожидать и линейной зависимости между ускорением написания кода и стоимостью всего проекта. Если реализация типового фрагмента стала в два раза быстрее, это не означает, что в два раза быстрее получится согласовать противоречивые требования, определить источник данных или спроектировать сложную интеграцию.
Именно поэтому ИИ в разработке программного обеспечения скорее перераспределяет трудозатраты, чем устраняет их.
Код становится дешевле, решения — заметнее
Первый работающий результат теперь можно получить раньше, быстрее показать пользователям и дешевле проверить. Но корпоративную систему по-прежнему нельзя свести к одному запросу к модели.
Часть небольших задач компания действительно способна закрыть внутри без расширения команды или привлечения подрядчика. Но после выхода за пределы прототипа проект всё равно сталкивается с данными, интеграциями, нагрузкой, бизнес-правилами, правами пользователей и эксплуатацией.
ИИ помогает быстрее реализовать принятые решения. Поэтому качество самих решений становится ещё заметнее.
Для корпоративной разработки вопрос постепенно смещается с «как быстро мы напишем код?» к «достаточно ли хорошо мы понимаем систему, которую собираемся построить?».
