Проблема передачи ответственности: что должна контролировать ваша команда до ухода консультантов

Что такое фактическое владение

Владение не ограничивается передачей документов в последний день. Это четыре практических возможности внутри вашей компании:

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

Большинство передач предоставляют только первую возможность и пропускают остальные три. Именно поэтому системы выходят из строя.

Важная документация

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

• Руководство по устранению неполадок при сбоях: пять наиболее вероятных проблем, как они выглядят снаружи и первые три шага для каждой из них. Написано для человека, находящегося на дежурстве, а не для инженера.
• Набор данных для оценки: от 100 до 200 реальных случаев с правильным ответом для каждого из них, согласованными людьми, которые выполняют работу. Это самый ценный артефакт всего проекта.
• Журнал изменений с обоснованием: не только что было настроено, но и почему правило существует. Правила без обоснований будут удалены следующим человеком.
• Таблица зависимостей и затрат: каждый модель, API и поставщик; стоимость в месяц; даты возобновления контракта; что сломается, если он исчезнет.
• Карта данных: куда идет данные, кто может на них посмотреть и как долго они хранятся. Ваши юридические и службы безопасности будут нуждаться в этом без предупреждения.

Все остальное — необязательно. Если документ не помогает кому-то управлять, изменять, оценивать или заменять систему, это украшение.

Три необходимых человека

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

• Владелец бизнеса, который решает, что должна делать система и контролирует бюджет. Они одобряют изменения и отказывают в расширении объема работ. Это не техническая роль.
• Технический хранитель, который может читать конфигурацию, вносить контролируемые изменения, тестировать их и выводить в производство. Часто это существующий разработчик или инженер по ИТ с выделенной мощностью. Им не нужно строить модели; им нужно уметь изменять и выводить в производство то, что существует.
• Владелец качества из отдела, которому служит система — старший специалист по требованиям, ведущий медсестра или руководитель службы поддержки. Они поддерживают набор данных для оценки и определяют, что такое "хороший" результат. Без этой роли качество превратится в вопрос мнения через несколько недель.

Общая стоимость внутри компании: обычно это доля одной полной ставки для каждого из них после стабильности системы. Модель неудачи — не затраты. Это то, что никто не был назван.

Тест передачи, пока вы еще можете пожаловаться

Не принимайте документацию в качестве доказательства передачи. Проведите тест в реальной среде в последние недели контракта, пока консультанты все еще находятся под контрактом.

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

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

Вставьте это в контракт с начала. Установите контрольные точки передачи, названную принимающую команду и контролируемый тест изменения — все это проще договориться до начала работы, чем после.

Мы строим так в Hercules A, и это означает, что наши проекты заканчиваются. И это именно то, что и нужно. Мера успешного проекта по искусственному интеллекту не в том, насколько глубоко консультанты внедрены через год — в том, как уверенно ваши собственные люди изменяют систему без вызова кого-либо.