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