ИИ пришёл в команду раньше правил

Элла Вен

ИИ пришёл в команду раньше правил

О примерах

Все ситуации в книге учебные. Они собраны из повторяющихся рабочих вопросов, но не описывают конкретную компанию, отдел или переписку.

Введение. Никто не назначал день внедрения

ИИ может появиться в команде без даты запуска и общей инструкции.

Один человек просит помочь с письмом. Другой собирает сводку из заметок. Третий разбирается в длинном документе. Если результат пригодился, способ остаётся в работе и постепенно расходится по команде.

Руководитель замечает это позже. Например, когда в готовом тексте появляется обещание, которого никто не давал. Или когда на простой вопрос «откуда взялась эта цифра?» нельзя получить внятный ответ.

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

Кто передаёт ИИ рабочие материалы? Что именно поручает? Как проверяет ответ? Где решение остаётся за человеком? Что произойдёт, если ошибку не заметят?

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

К последней странице у вас будут три рабочих документа:

— карта использования ИИ в команде;

— короткое соглашение о правилах и ответственности;

— план пилота на 30 дней с условиями продолжения и остановки.

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

Начнём с того, что уже лежит перед руководителем: с готового результата, по которому почти ничего не видно.

Глава 1. Готовый файл ничего не рассказывает о пути

Три одинаковых отчёта

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

Первый сотрудник собрал отчёт сам. Второй попросил ИИ убрать повторы, а затем сверил текст с заметками. Третий передал инструменту сырые сообщения из рабочего чата, получил сводку и почти не возвращался к источникам.

На экране это три одинаково законченные работы.

Разница проявится, если в одной из них обнаружится неверная договорённость. Первый и второй сотрудники смогут показать путь к исходным данным. У третьего останутся готовый текст и память о том, что нужная мысль «вроде была в переписке».

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

— какие материалы использовались;

— что было поручено инструменту;

— какое решение принял человек;

— как проверили результат;

— кто его утвердил;

— можно ли разобрать ошибку.

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

Список сервисов здесь не поможет

Можно спросить сотрудников, какими инструментами они пользуются, и получить аккуратный перечень. Для управления доступами он пригодится. Для понимания работы — почти нет.

Один сервис может участвовать и в безобидном черновике поздравления, и в документе с внутренними цифрами. Разные сервисы могут выполнять одну и ту же часть задачи. Само название ничего не говорит ни о данных, ни о проверке, ни об ответственности.

Поэтому начинать лучше не с инструмента, а с задачи.

Первая карта

Карта — это обычная таблица. Она не оценивает людей и не измеряет, кто «достаточно современный». Она показывает путь от исходного материала до принятого результата.

Это не образец политики. В вашей команде будут другие задачи, материалы и последствия. Нам сейчас важна сама логика: не «кто открыл ИИ», а «что произошло с работой».

Разговор без допроса

Прямой вопрос «Кто использует ИИ?» может прозвучать как проверка, даже если руководитель не собирался никого ловить. Люди ещё не знают правил и не понимают, что последует за честным ответом.

Я бы сначала объяснила цель разговора:

Мы хотим понять, где ИИ уже помогает, где создаёт риск и каких общих правил нам не хватает. Сейчас мы не оцениваем людей и не выбираем обязательный инструмент. Личные переписки показывать не нужно. Нас интересуют задачи и способы проверки.

После этого можно взять одну недавнюю задачу и пройти её по шагам:

1. Что вы делали?

2. Какие материалы использовали?

3. Какую часть поручили ИИ?

4. Что всё равно решали самостоятельно?

5. Как проверили результат?

6. Кто мог его принять?

7. Что произошло бы при незамеченной ошибке?

Если ответа нет, в карте появляется «не выяснили». Это полезнее, чем правдоподобная догадка руководителя.

Что собирать не нужно

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

Конкретные запросы могут остаться у исполнителя. Общий процесс не обязан делать всех одинаковыми.

Одна неделя вместо большого исследования

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

К концу недели не нужно выпускать политику. Посмотрите на две вещи:

— где люди уже действуют похоже, хотя общего правила нет;

— где одинаковые задачи проходят по несовместимым правилам.

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

Глава 2. Разговор, после которого люди не уходят в тень

Карта есть. Доверия пока нет

Представим, что руководитель собрал первые строки карты и вынес их на общую встречу. На экране три задачи. И почти сразу разговор уезжает в сторону.

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

Здесь не поможет ещё один вопрос из списка. Сначала нужно договориться, что именно мы обсуждаем.

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

Эта рамка нужна не для мягкости. Без неё люди начинают защищать себя, и карта заполняется версиями, которые безопасно произнести перед руководителем.

Приглашение уже задаёт тон

Если встреча называется «Контроль использования ИИ», дальнейшие заверения о свободном разговоре мало что исправят. Я бы написала приглашение прямо:

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

В этой формулировке уже есть четыре границы:

— обсуждаем задачу, а не человека;

— не считаем использование успехом само по себе;

— отказ от инструмента тоже даёт информацию;

— не забираем личную рабочую кухню без необходимости.

Одна задача вместо общего мнения

Вопрос «Как вы используете ИИ?» слишком широкий. Человек начинает пересказывать впечатления, а нам нужен путь работы.

Лучше взять последний пример:

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

Конкретная задача удерживает разговор от двух крайностей: «ИИ решает всё» и «ИИ ничего не может». Обе фразы перестают работать, когда рядом лежит письмо, сводка или список вопросов и можно пройти от начала до конца.

Четыре ответа, на которых стоит задержаться

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

«Я использую его почти везде». Просим выбрать одну задачу. Широкая формулировка не показывает ни материалов, ни решений, ни проверки.

«Я не могу показать переписку». И не нужно. Для карты достаточно описать тип материала и путь результата. Если без чтения личного чата процесс нельзя понять, это отдельный вопрос к прозрачности работы, а не повод забирать переписку.

«Это сильно сэкономило время». Записываем как наблюдение сотрудника, а не как измеренный результат. Если экономия важна для решения о пилоте, позже понадобится исходное состояние и единый способ считать время. Сейчас спорить с человеком или превращать впечатление в цифру одинаково рано.

Что фиксировать после разговора

Протокол встречи не должен пересказывать все реплики. Нам нужны только решения и пробелы:

— какие типы задач появились в карте;

— какие материалы вызывают сомнения;

— где проверка уже существует;

— где непонятно, кто принимает результат;

— какие вопросы требуют решения владельца данных, юриста, безопасности или руководителя;

— что команда пока не выяснила.

Имя сотрудника нужно только там, где он взял на себя следующее действие. Карта использования не должна незаметно превратиться в рейтинг людей.

Если руководитель уже знает, как «правильно»

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

Сначала мы записываем: материал передавали, проверка была такой, результат принимал этот человек. Затем отдельно решаем, допустимо ли продолжать.

Это не отказ от полномочий. Это способ не перепутать два действия: узнать, что происходит, и изменить происходящее.

Результат главы

После разговора у вас не обязана появиться полная картина. Достаточно трёх вещей:

1. В карте есть реальные задачи, а не перечень сервисов.

2. Пробелы записаны как пробелы, а не заполнены догадками.

3. Вопросы, требующие решения, отделены от вопросов, на которые команда уже ответила практикой.

Теперь можно переходить к границам. Не к одному списку «можно/нельзя» на все случаи, а к трём рабочим зонам.

Глава 3. Три зоны вместо одного запрета

Одна задача может оказаться в разных местах

Фраза «готовить письма с ИИ можно» выглядит как правило. Но она ничего не говорит о конкретном письме.

Черновик приглашения на открытую встречу, ответ клиенту с обещанием срока и письмо с персональными данными — всё это письма. Материалы, полномочия и последствия у них разные.

Поэтому зона назначается не виду документа и не названию сервиса. Мы смотрим на сочетание трёх вещей:

— что передаём на входе;

— какое решение поручаем;

— что произойдёт, если результат окажется неверным или материал уйдёт не туда.

Свободная, условная и закрытая

Свободная зона даёт пространство для эксперимента, но не отменяет ответственность за результат. Закрытая запрещает конкретный путь, а не саму работу. Условная находится между ними и поэтому требует больше всего ясности.

Четыре вопроса для распределения

Можно ли передавать материал?