Нейросети для бизнес аналитика: спор за переговорную
Нейросети для бизнес аналитика: как разобрать спорную заявку, согласовать правила бронирования переговорной и превратить ожидания команды в критерии приёмки.
Ольга
Основатель малого бизнеса, партнёр
10 мин чтения
В 11:00 у нашей переговорной оказались две команды. Первые ещё собирали вещи, вторые уже привели гостя. Я согласовала правило «брони не пересекаются» и была уверена, что предусмотрела такую ситуацию. Теперь пришлось разбираться с собственной уверенностью. С тех пор нейросети для бизнес аналитика я оцениваю по тому, помогают ли они обнаружить подобный спор до того, как он доберётся до живых людей.
Администратор считала, что между встречами нужны десять минут. Руководитель второй команды возражал: его бронь начинается в одиннадцать, значит, комната должна быть свободна в одиннадцать. А первая команда честно закончила встречу по расписанию. Неловко было всем. Особенно мне: ту короткую формулировку в заявке я одобрила сама.
Одну строчку мы согласовали, три ожидания пропустили
Первым желанием было дописать: «Просьба освобождать помещение вовремя». Но это не решало вопрос с подготовкой комнаты. Если администратору нужен промежуток, его надо откуда-то взять: сократить встречу, сдвинуть следующую или выделить отдельное время. Вежливое напоминание не выбирает ни один вариант.
Я собрала участников на короткий разговор и попросила каждого назвать момент, с которого следующая команда может войти. Тут и выяснилось, что слово «встреча» у нас означало разное. Для одного это разговор до последней минуты. Для другой — весь период, включая расстановку стульев и сбор вещей. Оба прочитали заявку внимательно. Просто заявка позволяла прочитать её по-разному.
Меня задело, как легко мы обсуждали будущий календарь. Цвета выбрали, подписи к кнопкам поправили, а на вопрос «чья комната в 11:00?» ответа не было. Я потратила внимание на то, что видно в макете. То, из-за чего люди могут столкнуться у двери, осталось за кадром.
После этого я перестала считать согласование состоявшимся по одному «да, всё понятно». Теперь мне нужен ответ на конкретную ситуацию. Если два человека ждут разных действий, дополнительный абзац в документе ещё ничего не исправляет. Сначала договариваемся о действии.
Нейросети для бизнес аналитика: ищу место разногласия
Когда занялась требованиями к бронированию, я начала с короткой заявки. Сотрудник выбирает комнату и время. Пересечения недопустимы. Встреча длится не больше двух часов. Организатор может отменить свою бронь, администратор — любую, указав причину. Всего несколько предложений. Очень удобно кивнуть и отправить дальше.
Раньше я попросила бы сразу развернуть это в техническое задание. Получить много аккуратных разделов приятно: работа будто продвинулась. Но мне уже было известно, где мы способны разойтись во мнениях. Поэтому задачу чату поставила уже: выписать заданные правила, собрать вопросы и предложить критерии для того, что действительно определено.
LibraChat разбирает текст и помогает его переписать. Для такой работы я использую его как собеседника, который смотрит на заявку ещё раз. Находить формулировки можно вместе. Решать, какой порядок устроит команду и администратора, всё равно приходится нам.
В сохранённом разборе заявки среди вопросов были и соседние интервалы, и то, что происходит с бронью после отмены. Последний вопрос я сначала недооценила. Человек отменил встречу, а время должно сразу стать доступным другим? Для нашей работы ответ кажется очевидным. В требованиях его всё равно надо произнести: иначе мы проверим кнопку отмены и забудем проверить доступность комнаты.
Я сделала для обсуждения такую таблицу. Слева оставила короткие правила, справа — ситуации, на которых нам предстояло выбрать поведение.
Запись в заявке · Ситуация для разговора · О чём надо договориться
Брони не пересекаются — Одна заканчивается в 11:00, следующая начинается в 11:00 — Допустим ли стык и где учитывать подготовку комнаты
Встреча не больше двух часов — Свободная комната, запрос на 10:00–12:00 — Принимается ли ровно предельная длительность
Организатор отменяет свою бронь — Встреча отменена, другой сотрудник выбирает то же время — Когда интервал снова доступен
Администратор отменяет любую бронь с причиной — Причина не заполнена — Можно ли завершить отмену
С таблицей разговор стал предметнее. Вместо длинного «как обычно бывает» у каждого появился короткий выбор. Мне это нравится больше подробного документа, который все одобряют, представляя разные процессы.
Заказчику пришлось выбрать между двумя расписаниями
Самый трудный вопрос оказался тем самым: что делать на стыке встреч? Я показала два варианта. В первом следующая команда может бронировать комнату ровно с окончания предыдущей встречи. Во втором между бронями предусмотрен перерыв. У второго варианта есть цена: часть рабочего времени комнаты нельзя отдать под встречи.
Тут уже не получилось сказать «сделайте удобно». Для администрации удобен запас на подготовку. Для команд удобна возможность плотнее поставить встречи. Попросила владельца процесса выбрать, какое обещание мы дадим человеку при бронировании.
На таких обсуждениях меня выручает один ход: говорить о результате для участника. «Вторая бронь принимается или отклоняется?» — вопрос гораздо точнее, чем «как обрабатывать пересечения?». На первый может ответить человек, который не занимается разработкой. Второй легко уводит разговор в устройство календаря.
Если выбираем перерыв, сразу появляются уточнения. Одинаковый ли он для всех комнат? Кто задаёт продолжительность? Считается ли он частью двухчасового ограничения? Не стоит прятать их в длинную переписку. Я выношу каждое отдельным вопросом и записываю ответ рядом с исходной ситуацией.
Для нашей комнаты в итоге выбрали десятиминутный промежуток между бронями. После встречи до 11:00 следующую можно назначить с 11:10; само время подготовки в двухчасовую длительность встречи не включаем. Я записала это решение и вернулась к обеим командам: теперь у них было одно расписание. Потеряли часть доступного времени. Зато перестали обещать его двум участникам по-разному.
Показатели загрузки комнаты могут помочь владельцу оценить последствия выбора. Это уже другая часть работы; для неё есть материал про нейросеть для аналитика данных. В нашем разговоре сначала требовалось договориться, что считать доступным временем. Иначе даже точные проценты загрузки будут описывать разные представления о расписании.
На 120 минутах я проверила себя ещё раз
С пределом длительности было спокойнее. «Не больше двух часов» включает ровно два часа. Я взяла одно начало, 10:00, и два окончания: 12:00 и 12:01. Получаются 120 минут и 121 минута. Первое значение укладывается в условие, второе превышает его. Здесь уже можно составлять проверку.
В ответе LibraChat к этому месту была точная подсказка: «Меняется только конец, чтобы отказ нельзя было спутать с пересечением». Я сохранила её. Если проверять длительность на уже занятой комнате, отрицательный результат мало что скажет: бронь могли отклонить из-за другой встречи. Кажется мелочью, пока не начнёшь принимать работу.
Поэтому для проверки предела я задаю свободную комнату. Остальные согласованные условия выполнены. Сначала пробую два часа, затем увеличиваю длительность на минуту. Когда меняется только один существенный параметр, легче понять, что именно подтверждает результат.
Но такой расчёт ещё надо соотнести с тем, как человеку разрешено вводить время. Если интерфейс допускает только получасовые интервалы, 12:01 выбрать не получится. Тогда проверку строим с учётом допустимого шага. Арифметика осталась верной; способ проверить реализованное ограничение придётся уточнить.
Эту часть я теперь не проглатываю со словами «ну это же понятно». Бизнес-правило может быть ясным, а проверка — плохо поставленной. Смысл приёмки в том, чтобы обе стороны одинаково понимали, какой результат они увидят. Разработчику не нужно угадывать мой мысленный эксперимент.
Нейросети для бизнес аналитика должны выдержать «а если»
После разбора времени я вернулась к отмене. Если организатор отменяет свою встречу, надо проверить именно его бронь. Если администратор отменяет чужую, в нашем условии требуется причина. Вопрос о пустой строке здесь полезнее просьбы «сделай удобную форму».
Я стала проходить по заявке в таком порядке:
Называю участника и то, что он пытается сделать.
Описываю состояние комнаты или брони до действия.
Записываю результат, который участник должен увидеть.
Меняю одно условие: длительность, владельца брони или наличие причины.
Отдельно помечаю развилки, где команда ещё не выбрала поведение.
Последний пункт удерживает от торопливости. Хорошо сформулированный вопрос хочется поскорее закрыть собственной догадкой. Особенно когда ответ кажется естественным. Но удобная догадка не становится решением заказчика оттого, что её гладко записали.
Для своего разбора открой чат LibraChat и вставь в чат небольшой фрагмент заявки. Я предлагаю начать с такой формулировки:
Найди в этой заявке ситуации, которые разные участники могут понять по-разному. Для каждой покажи два возможных ожидаемых результата и задай один вопрос владельцу процесса. Не выбирай ответ за него. Затем предложи проверяемые критерии для уже определённых условий: начальное состояние, действие, наблюдаемый результат. Новые функции не включай в согласованные требования. Заявка: [текст без лишних личных данных].
В будущем ответе посмотри прежде всего на пары результатов. Есть ли между ними настоящий выбор? Если одна сторона звучит заведомо нелепо, вопрос вряд ли поможет разговору. Мне нужны варианты, которые мог бы всерьёз ожидать живой участник процесса.
И ещё я проверяю, не появились ли в требованиях новые возможности. Напоминания о встрече, повторяющиеся брони и согласование руководителем могут пригодиться. Только обсуждать их нужно как предложения. Иначе мы рассчитываем объём одной задачи, а принимаем уже другую.
Как я теперь подписываю требования
На итоговом просмотре я больше не читаю документ с выражением человека, которому всё знакомо. Читаю глазами того, кто будет пользоваться комнатой или разбирать конфликт. Могу ли я по написанному объяснить, почему вторая бронь принята? Почему отмена не завершилась? Когда освободится интервал?
В документе перед согласованием у меня остаются три разных вида записей:
выбранное правило и человек, который его подтвердил;
открытый вопрос с понятной ситуацией для выбора;
предложение улучшения, которое пока не включено в объём работы.
Когда решение меняется, я исправляю связанные проверки. Одной замены предложения в начале ТЗ мало: старый ожидаемый результат в конце документа способен вернуть тот же спор. Мне проще найти все упоминания стыка встреч сразу, чем потом убеждать команду, какую страницу считать главной.
Для постоянной работы с требованиями я сверяю описание тарифов с тем, что мне предстоит разбирать: короткие заявки, документы или большие пакеты файлов. Но сама привычка начинается с короткого фрагмента. Нейросети для бизнес аналитика полезны, когда помогают задать точный вопрос к процессу, а ты не пропускаешь момент, где ответ должны дать люди.
В ту переговорную я теперь мысленно возвращаюсь перед каждым согласованием. Две команды, одна дверь, начало в 11:00. Если по моему документу они всё ещё могут ждать разного, подпись ставить рано. Возьми одно правило из своей задачи и устрой ему такую же встречу с двумя разумными ожиданиями. Обнаружить разницу до разработки приятнее, чем объяснять её гостю в коридоре.
