Как (не) нужно строить базу знаний для проекта с нуля. Часть Первая, утопическая
Сентябрь 2020 года. В этот момент, моей Суперучилке (имя вымышленное), платформе по поиску репетиторов в США, требуется срочно новая команда поддержки, потому что старая не справляется с бизнес-логикой и создает проблемы. А для новой команды нужна новая база знаний, чтобы обучить новичков с учетом ошибок ветеранов.
В октябре начинался новый сезон и приходили новые клиенты. Собеседовать и обучить новую команду надо позарез за неделю до сезона, чтобы успеть потренироваться. У меня есть три недели, и часики уже тикают. И все происходит в условиях качелей между удаленкой и офисом: собеседовал новичков я вживую, а учились мы уже в Google Meet.
Тут мой воспаленный мозг начал шевелиться. В июле как раз выстрелила моя статья о Zettekasten, методе ведения личной базы знаний для работы и творчества. Я уже полтора месяца сидел в сообществе Zettelkasten и проникался прелестями ассоциативных, нелинейных и экзотичных баз знаний. Мне за советом в телеграм пишут каждый день, и я добросовестно прокрастинирую, отвечая на вопросы.
Именно я был тем избранным, который осилит за три недели сделать что-то стоящее. Но это было неточно.
Вдруг в голову приходит безумная идея сделать коллективную базу знаний. Базу, что я напишу в соавторстве с новой командой, совместив созидание и обучение в одном порыве. Базу, которая станет воплощением демократии и взаимопомощи. И воплотит фантазии всех тех, кто хочет сделать Цеттель для команды и регулярно пишет об этом в русскоязычном сообществе. (Спойлер: не пытайтесь делать это без консультации с врачом).
И я пустился в незабываемое приключение. Сперва я обрадовался результатам, потом пожалел о своих решениях, но в итоге, создал идеальную систему для Суперучилки, которая живет по сей день. О подвигах и злоключениях — под катом. Осторожно, много картинок!
Немного предыстории, или как Машеньке было неудобно в чужих кроватях
Репетиторский проект был моим трудным, но любимым ребенком. Суперучилка отпочковался от родительской компании как маленький эксперимент. Но громадными усилиями опытных разработчиков, основателя родительской компании, маркетолога и дизайнера (и тогда еще неопытного меня), Суперучилка стала оправдывать надежды. А с надеждами пришли первые ожидания.
Проблема в найме новой команды и создании базы данных была в сложности системы. Суперучилка состояла с кабинетов клиента и репетитора; красивый у клиентов, брутальный — у репетиторов. К ним была прикручена самописная CRM с многолетней историей, которая досталась от компании-владельца. Первая часть CRM была нужна для управления заказами и работы с фрилансерами. Другая — для управления заказами и работы с клиентами.
В родительской компании, этими двумя частями CRM пользовались разные команды. Суперучилке, увы, нужны были обе, и объединить их было невозможно. При этом, весь богатый функционал CRM команда Суперучилки использовала лишь частично. Так как она запускалась сперва как эксперимент, прикрутить готовые решения было умнее, чем тратить деньги на разработку потенциально бесполезного функционала. А потом мы подсели на иглу гибкости в экспериментах с фронтом за счет универсальности CRM и бекенда.
К такому решению подтолкнуло и то, что сперва Суперучилку вела старая команда поддержки из родительской компании, и было проще использовать знакомые им интерфейсы. И эта команда заслуживает отдельного слова.
Это команда суперотрядом коммандос. Они летали между мини-проектами родительской компании поддерживали в них то, что плохо стоит. Этот трудовой подвиг был возможен того, что все проекты работали с одинаковыми ценностями и KPI: решение проблемы клиента важнее процедур, круглосуточная поддержка, время ответа максимум 5 минут, одинаковые правила для фрилансеров и сотрудников.
Но даже так «коммандос» было тяжело. Спустя некоторое время, их участь облегчили и избавили от нужды справляться с разными проектами. Все неудачные начинания потопили, всем удачным дали полноценную поддержку.
И начало этому положила Суперучилка. «Коммандос» выдержали то, что надо работать в двух CRM, хуже справились с правилами Суперучилки, которые отличались от обычных. Но когда платформа выросла, а её фишкой стал творческий подход к распределению заказов между фрилансерами, «коммандос» уже справиться не смогли и забили тревогу.
И в сентябре я получил долгожданное право нанять себе в Суперучилку собственную команду агентов.
Ад копипастера, или почему я не мог взять готовое
Итак, сентябрь 2020 года. Чтобы нанять новую команду, мне нужно найти правильных людей. А потом обучить их всем премудростям жизни репетитора и особенностям Суперучилки.
С отбором на собеседование мне помогла родительская компания — дала выбирать «звезд» из свежего набора агентов в другие проекты. Звезды уже прошли базовую тренировку с «чатовой» частью CRM и прошли все тесты, чтобы быть полноценными агентами. А звездами они назывались потому, что умели — и не боялись — думать. Ведь умных людей много вокруг, но не все имеют мужество умом пользоваться. И это мужество — как свет звезды.
Вопрос дальнейшего обучения «звезд» был сложнее. Чтобы обучать, мне нужно было создать новую базу знаний. А к ней — обучающие сценарии, чтобы откатать материал на деле до реальной работы.
Если бы я просто взял существующие процессы, бизнес-логику и правила, собрал их в одном месте и написал квесты, задача была бы проще. Но гордыня и чтение дерзких книг сподвигли меня на авантюру. Раз даже «коммандос» были недовольны существующими процессами, новички и вовсе повесятся. Значит, мне нужно не просто собрать знания и правила —, но и улучшить и оптимизировать их по ходу дела.
Вижу, на задних рядах уже смеются: знают, как я был неправ. Если вам нужно будет менять правила, сперва зафиксируйте текущее положение дел, а потом начинайте изменения. Оправдание я себе нахожу в том, что пусть у меня было только три недели, мне всё равно пришлось бы создавать всю базу знаний с ноля. Потому что позаимствовать мне было неоткуда.
Документацию «коммандос» я переиспользовать не смог. Действовали «коммандос» на всех проектах по одной логике, работали давно, и их базы содержали лишь специфичные для отдельных проектов вещи. Общая «суть» была у них голове, заученная в мышечную память, и на попытках ее уловить «коммандос» могли лишь показывать, но не рассказывать. Ну, а те руководства, что у них были для Суперучилки, меня не устраивали и я решил делать с ноля.
Еще у меня были базы знаний и правила других команд родительской компании, которые использовали те же инструменты CRM. Но они были максимально упрощены и строились вокруг бизнес-логики и запросов клиентов, а не функционала CRM. Такая организация была очень умной, но закрывала от меня двери к копипасту снова. Бизнес-логика у Суперучилки была совершенно другой
А еще мне не нравилась организация документации в родительской компании. Все было закатано в длиннющие инструкции, перегруженные таблицами с расписыванием вариантов ситуаций, цветным текстом и вложенными друг в друга страницами. А цвет, стили, шрифты — это тоже информационные слои. Злоупотребление им делает восприятие сложнее.
Цвет не дает глубины тексту, но может быть незаменим в другом контексте. Ильяхов в статье «Цвет как информационный слой» отлично объясняет, как цвет работает.
Вдобавок, редко можно было найти окончательный ответ просто навигацией по страницам. Приходилось использовать поиск и надеяться, что ты поймешь всё правильно. Я с таким смириться не смог.
С тех пор, команда управления знаниями в родительской компании сделала сто шагов вперед, и происходи мои метания сейчас, я бы просто скопировал их подход и не парился. Но тогда меня воротило от того, что моя собственная, единственная и неповторимая команда Суперучилки будет путаться в простынях текста. Мне хотелось простого и элегантного решения, где можно легко выучить правила и быстро найти ответ на любые вопросы.
С таким настроем, я создал аккаунт в своем любимом Notion и взялся за дело.
Практическая часть в построении базы знаний
Если изобразить ситуацию, с которой я начинал, она выглядела примерно вот так.
Все основные инструменты CRM и кабинеты репетиторов с клиентами находятся для новичка за туманом войны. Кроме того, где-то льется река живого процесса. С одной стороны, он течет по русле бизнес-логики, и мы можем примерно определить где и что. С другой стороны, так как Суперучилка — это платформа и продукт экспериментальный, то в русле бизнес-логики процессы между клиентами и репетиторами могут случаться самые разные: рабочие моменты, выяснения отношений, конфликты и споры.
Предвидеть все казусы и ситуации в реке процесса невозможно. Но вот дать принципы разрешения рабочих ситуаций (и сохранения опыта) — вполне. Чтобы пользоваться такими принципами, надо хорошо понимать и бизнес-логику, и реальный процесс, и инструменты. Это и стало моей целью в создании базы знаний для Суперучилки.
Шаг первый: словарь всему голова
Первым делом я решил, что нужно создать словарь. Так как и в инструментах CRM, и в бизнес-логике, и в процессах участвуют одни и те же самые актеры и сущности, умно их поймать и описать в отдельных статьях. Так я сразу получил карту местности, которая покрывала максимальное количество территории, и на которую можно опираться дальше.
У словаря было еще несколько преимуществ. Мало того, что там можно описать все главные вещи, вроде ценовой матрицы или что такое дедлайн, так еще ссылаться на них по всей базе знаний, прямо как на вики. В отличие от вики, статья словаря обрастала бы автоматическими обратными ссылками, в народе известными как бэклинки. Можно было бы зайти в словарь и посмотреть везде, где упоминается ценовая матрица, или где мы сталкиваемся с брендингом.
Так как вы не обязательно будете читать статью до конца, я буду сразу спойлерить: это было не самое лучшее решение. Нет, тема со ссылками сработала отлично, особенно при обучении. Но в будущем оказалось, что иногда проще переиспользовать текст из словаря сразу в контексте. Во избежание рассинхронизации, нужно было еще чтобы он синхронизировался в обе стороны при редактировании в одном месте.
Увы, трансклюзия в Ноушене раньше ставилась шаманскими манипуляциями, и я не решился на такой шаг кроме самых критических моментов. Сейчас в Ноушене это можно сделать с помощью Synced Blocks, при этом сразу можно посмотреть список страниц, которые блок используют.
При создании словаря стало понятно то, что в отрыве от бизнес-логики он существовать не может. При попытке описать, например, чем является Клиент, сразу возникает его связь с Заказом, Репетитором, Оплатой и Клиентским Сайтом. А связаны они через взаимодействие. Это сразу тащит внутрь словарной карточки полный рассказ о том, что Клиент может делать и как.
Я решил, что это не имеет особенного смысла, потому что зачем тогда все эти обратные ссылки? Поэтому, в словарных карточках я ограничился описанием самой сущности Клиента, и сделал задел под ссылки на его возможности. Получилось похоже на декларацию класса: мы говорим какие поля и функции он имеет, а реализацию функций предоставляют включенные внутрь объекты.
А моей следующей мишенью стала бизнес-логика.
Важный нюанс: бизнес-логика против бизнес-процесса
В этой разнице лежит ключ того, почему сейчас из Evernote массово бегут люди, прихватывая тысячи заметок за собой, а иногда и перенося их вручную. Или почему одни редизайны со временем вызывают восторг, а другие кладут в могилу вполне живые продукты.
Я заморачивался так с базой знаний именно из-за разницы между логикой и процессом: если бы ее не было, я бы справился за три дня. Так что готовьтесь — сейчас будет притча. Если у вас MBA и вы знаете секрет и так, то вот телепорт к следующему практическому шагу.
Бизнес-логика — это как русло реки. Русло определяет, где заканчивается река и где начинается берег, и решает куда, по идее, река должна течь. Русло можно расширить, углубить, а можно сузить и вовсе перекрыть течение. Оно дает стойкое впечатление о том, что рекой можно предсказать и управлять. Обычно у людей это получается, пусть и на время.
А бизнес-процесс — это река, поток воды в русле. Река течет по руслу и повинуется его поворотам. Но в зависимости от обстоятельств, река может выйти из берегов, перелиться через дамбы, а то и вовсе проложить новое русло. И даже у спокойной реки есть подземные течения и грунтовые воды, которые внезапно могут подмыть мост и затопить подвалы.
Конечно, обладатели MBA и осилившие PMBoK сейчас скажут, что в серьезных компаниях термины совсем другие, а в реках водятся жабы, и я не учел их коэффициент сопротивления течению. Но я счастлив работать над проблемами, а не определениями, покуда определения сами не являются проблемой.
В общем, с бизнесом — как с рекой. Бизнес-логика — это наши ожидания от того, как должны вести себя люди зарабатываться деньги. Клиенты приходят через лендинги А, Б и В, регистрируются через телефон, имейл, Гугл, Фейсбук или Спотифай, которые потом используются как каналы связи. Мы ищем им репетитора, исходя из критериев Альфа, Бета и Гамма, которые собираем из их профиля и запроса. Клиенты оплачивают работу репетитора пятью доступными способами оплаты, репетитор платит комиссию.
Это всё — русло бизнес-логики. Под нее мы рисуем дизайны, разрабатываем интерфейсы и бэкэнд.
Но на то есть река, чтобы по руслу не течь. Ведь бизнес-процесс — это то, что происходит на самом деле. Клиенты приходят по наводке знакомых по прямой ссылке в кабинет, сразу попадая на авторизацию мимо лендинга. А то и вовсе друзья дают свой аккаунт, потому что там есть бонусы. Клиенты указывают временный телефон, потому что хотят приватности, но зато школьный имейл с ФИО, потому что у него модный домен. Они пишут о запросе в общих чертах, а потом отклоняют всех репетиторов, пока не найдут того, кого искали: молодую-девушку математика, чтобы занималась с ребенком.
И потом переводят репетитору деньги без спроса на Пейпал, минуя нашу кассу. И отдают еще часть баллами местной сети супермаркетов, потому что репетитор и клиент оказались из одного штата.
Теперь репетитор ищет, как нам перевести комиссию. Это реальный случай из практики Суперучилки — радикальный, но далеко не единственный.
Бизнес-логика — это то, как мы жизнь видим. Бизнес-процесс — это настоящая жизнь. Частично продуктовый подход заключается в том, что мы регулярно ставим гипотезы и измеряем то, какая жизнь-процесс на самом деле. И на этом основании, обновляем бизнес-логику, допиливая новые фичи и улучшая старые.
Следовать за прихотями течения жизни обычно выгоднее, чем с жизнью спорить. В лучшем случае, бизнес-процесс просто перельется через вашу дамбу, и пользователи будут «неправильно» пользоваться услугой и нести деньги. В худшем, ваша «правильная» бизнес-логика убьет течение, и вода станет тухлой, как это случилось с Evernote. (Он стал еще и тормозной). По тухлой реке клиенты не смогут доплыть туда, куда хотят и разбегутся по другим рекам, как раки.
Шаг второй: путеводная звезда бизнес-логики
Вся эта притча нужна была для того, чтобы передать всю противоречивость задачи, которую я ставил перед базой знаний новой команды. Мне нужно было четко передать бизнес-логику в виде того, как работают сайт, CRM и правила. Если что-то не работает по логике вещей, это баг;, а так как мы активно разрабатывались, багов было немерено. Кроме того, было много правил, диктованных законодательством, правилами платежных систем, технологией и юристами. Их нельзя было нарушать.
При этом всем, я хотел создать свободу для обнаружения и использования бизнес-процессов. Для этого нужно было передать принципы принятия решений и ценности Суперучилки, а также дать инструменты для критического анализа ситуации. И чтобы это всё могли сделать новички в индустрии.
И поэтому я выбрал героем бизнес-логики заказ, а бизнес-логику для новой команды построил как путь заказа, от предпосылок к его появлению и успешного закрытия. Сюда же я включил все разветвления состояний заказа — вроде возврата денег, открытого спора или неоплаченного заказа-зомби, брошенного потенциальный клиентом в корзине. А состояния, в свою очередь, я привязал к сущностям из словаря.
Вот почему я решил выбрать именно заказ главным героем:
- Заказ — главная единица экономики проекта. Средний чек, цена привлечения клиента, пожизненная ценность клиента (LTV), доля репетитора — все это вертится вокруг заказа.
- Вся CRM, по сути — это система для управления клиентами и заказами. Весь инструментарий заточен под то, чтобы переводить заказ между разными состояниями бизнес-логики и изменять его свойства.
- Проблемы на Суперучилке, вроде возвратов денег или пропуска сроков, тоже связаны с заказами.
Такая постановка бизнес-логики заодно вдохновила Service Level Agreement (SLA) для команды. Так сейчас модно называть КПИ, то есть критерии, по которым мы знаем, хорошо работает человек или плохо. Например, на любом этапе «активного заказа», агент должен ответить максимум две минуты. А вот для «архивных» заказов, которые мы закрыли более месяца назад, агент может повозиться и час.
Так мы убедились, что усилия агентов поддержки тратятся разумно, и они воюют в ту сторону.
Шаг третий: практическое использования закона Мёрфи
Теперь, когда у меня была бизнес-логика Суперучилки, надо было рассказать агентам о том, как бизнес-процесс может выходить из берегов логики и переливаться через плотины. Как и говорил раньше, я хотел различить три главных класса событий:
- Что-то идет не так, и это неправильно. Если это происходит в программном обеспечении — это баг и надо идти к разработчикам. Если репетитор себя ведет неправильно, надо помочь ему вернуться на путь истинный и спасти клиента от негатива.
- Что-то идет не так, и это допустимо. Например, если клиент вместо создания нового заказа доплачивает за предыдущий, чтобы дальше работать с репетитором, агентам пресекать это не нужно. А взять на заметку, чтобы дизайнер со мной подумал, есть ли смысл развивать эту фичу.
- Что-то идет не так, и мы не знаем, что с этим делать. Например, как в том случае, когда клиент искал репетитора, не выбирая из списка профилей, а перебором автоматического матча. Тогда надо действовать творчески, чтобы сохранились Суперучилкины ценности: чтобы клиент остался защищен, репетитор получил деньги за проделанную работу, и так далее.
События второго класса, допустимые хаки бизнес-логики, легко описать полным списком. Но список неприятностей постоянно пополняется, а непредвиденные ситуации на то и непредвиденные.
И здесь я сделал первую ошибку. Я решил положиться на закон Мёрфи, и описать все возможные ситуация отклонений от бизнес-логики, а к ним — сценарии для решения. На тот момент, так было сделано в родительской компании, а сама Суперучилка была очень проста. Но и у меня были железные аргументы в пользу своего выбора:
- Новичкам сложно будет разобраться что хорошо, а что плохо без конкретных примеров и руководств.
- Есть ситуации, где закон требует действовать одним конкретным образом, вроде возвратов денег или чеков.
- Можно привязать ситуации к конкретным элементам бизнес-логики. Это упрощает жизнь агенту: если что-то идет не так, ты ищешь стадию жизни заказа в логике, и выбираешь подходящий под ситуацию протокол.
В результате, моё описание бизнес-процессов стало выглядеть вот так. Все возможные события на каждом этапе жизни заказа получили свои карточки. А инциденты — способы их решения. Это еще сильнее разогнало туман, показывая всё возможные личины Суперучилки.
Мне представлялось, что такую структуру ситуаций будет легко расширять. Технически, это была база данных в Ноушене, перелинкованная с бизнес-логикой и словарем. Ситуации можно было смотреть отдельно, а можно в контексте использования той или иной процедуры. Таким образом, когда появлялась новая ситуация или правило, её можно было
Для написания некритических процессов я подключил новую команду. На тот момент я уже собеседовал и нанял новых людей. Они дорабатывали свои последние смены на старых позициях, заодно начиная обучение Суперучилке. Процедуры мы генерировали следующим образом:
- Зная бизнес-логику и имея базу реальных случаев на руках, мы вместе придумывали ситуации, где что-то может пойти не так.
- Потом писали процедуру разрешения ситуации, руководствуясь ценностями Суперучилки: о проблеме клиента позаботились, репетитор не обижен, случай зафиксирован для обучения.
- Наконец, смотрели на текущие кейсы в продакшене и из архива, чтобы проверить, правильный ли придумали подход.
Мне надо было насторожиться, когда таких описаний бизнес-процессов собралось целых 30 штук. И это мы еще экономили, не создавая дубликаты для похожих ситуаций, вроде вопросов клиентов на разных стадиях перед оплатой. Но лихорадка ума у меня не проходила, а День Z, когда новую команду надо было высаживать, был всё ближе.
Поэтому, я двинулся дальше.
Забегая наперед, именно список бизнес-процессов стал перышком, что со временем сломало спину верблюду базы знаний. Для команды Суперучилки, надо было сделать иначе. Но прежде, чем все навернулось, я навернул в базу еще несколько фич.
Шаг Четвертый: технические руководства и сила глагола
Итак, новые агенты поддержки уже знали с чем работает Суперучилка, как должен проходить свой путь заказ, и как они должны действовать в том случае, если у заказа всё не слава богу. Оставалось лишь рассказать, как именно принимать и возвращать деньги, управлять заказами в CRM и общаться с клиентами.
С одной стороны, CRM была создана для того, чтобы воплощать бизнес-логику: она отражала ее так, как форма для хлеба отражает сам хлеб. С другой стороны, две тысячи триста восемьдесят слов назад я уже рассказал, что CRM у Суперучилки была неродная; её интерфейс и пользовательский опыт строились под другие логики. И потому положиться на хороший UX и дать новым агентам осваивать инструмент я не мог.
Меня выручил тот факт, что в родительской компании вся документация и переписка традиционно ведется на английском. Перечитывая написанное мною и новобранцами, я обнаружил совпадение. Все инструкции, которые подразумевали работу с инструментами, строились по схеме «глагол + объект = новое состояние». Например.
Новое состояние всегда отсылалось к бизнес-логике. Объекты совпадали с сущностями словаря, которые, в свою очередь, совпадали с разными секциями интерфейса CRM. А вот глагол был тем самым действием, которое надо совершить, чтобы агент добился от CRM желаемого.
Это не спасло меня от того, чтобы описать полностью интерфейсы CRM. Но я мог использовать языковые закономерности и низкую разнообразность словоформ в английском. Вот, что я сделал, чтобы превратить технические руководства из унылых талмудов в почти незаметную часть:
- Разделил описание интерфейса на секции и связал их с сущностями словаря Суперучилки, которыми они управляют.
- Внутри интерфейса, описал что делают и показывают кнопки и поля теми же конструкциями «глагол + объект», что и в карточках бизнес-логики, процедур и словаря.
- Теперь нужное действие всегда подхватывалось поиском и показывалось наверху.
На всякий случай, я поставил прямые ссылки в тех секциях, где принципиально был важен выбор части CRM, управляющей или общительной. Потому что вопреки пересечению, некоторые операции, вроде работы с фрилансерами или промокодами, можно совершить лишь в одной части.
Шаг пятый: вспомогательные средства
К тому времени, проходят три недели. На второй мы с агентами уже решали задачки, которые легли в основу бизнес-процессов, описанных в шаге третьем. И новая команда перешла полностью под моё командования как раз тогда, когда последняя страница тех руководства была готова.
У нас теперь было время для полноценного обучения перед тем, как выходить в настоящую Суперучилку. В родительской компании это назывался «онбординг»: специально выделенное время, чтобы ввести новобранцев в курс дела, а получивших повышение — в специфику новой роли.
На онбординге мы сперва решали «квесты», тестовые задачи на серверах стейджинга с фейковыми клиентами и репетиторами, чтобы нащупать интерфейс CRM в волю и отработать основы бизнес-процессов. Дополнительная цель была избавить агентов от страха «что-то сломать», очень распространенной штуки при работе со сложно выглядящими интерфейсами. Потом были ретроперспективы в архиве CRM, чтобы освежить память о логике и процессах. И, наконец, мы перехватывали реальных клиентов и заказы у старых «коммандос».
Это стало краш-тестом всей системы базы знаний. Исходя из первых результатов и организационных потребностей, я добавил несколько свистелок, без которых теперь никак.
▍Документы по трудоустройству
Это копия договора по трудоустройству — правила начисления зарплаты и ее выплаты, четко зафиксированные ожидания, отпуска и больничные, и прочие нужные вещи. Они были написаны в первую очередь еще до начала эпической истории с базой данных. И теперь просто поселились в базе, чтобы было удобно запросить отпуск или прикинуть зарплату за следующий период.
▍Журнал смен
А вот эту штуку я полюбил всем сердцем. По правилам Суперучилки, агенты сами выбирали себе график и разбирали смены на недели вперед, договариваясь за слоты между собой. Главное, чтобы на каждой из трех смен был человек. Для этого нужно было, чтобы агенты могли видеть эти самые слоты, и выбирать себе нужные.
Для этого я в Ноушене сделал календарь, в котором каждая страница соответствовала смене. В ней можно было выбрать тип смены и привязать её за собой.
Штука оказалась неожиданно удобной для передачи информации между сменами. Агенты стали сами писать о прогрессе задач, незавершенных процедурах и текущих задачах. Заодно получился тот журнал, который лог: можно было просмотреть летопись событий.
Так как зарплата в Суперучилке считается в зависимости от типа смены, дело дальше было за малым. Я добавил поле «Зарплата» и сделал шаблоны, где зарплата выставлялась в зависимости от типа смены. И все эти смены выводились в связанную таблицу-калькулятор, где можно было переключаться между фильтрами по каждому агенту и смотреть сумму за расчетный период.
▍Трекер заданий
Но журнал смен не справлялся еще с одной важной функцией: отслеживание задач, которые не входили в бизнес-логику. Например, отдельному агенту мог поставить задачу собрать случаи того или иного бизнес-процесса. Или мы могли затеять рекламную кампанию или эксперимент, где общаться с клиентами и репетиторами надо было по-другому. Нужно было сделать руководства, отметить ответственных и отслеживать прогресс.
Трекер я реализовал по той же логике, что журнал смен. Только вместо календаря, использовал вид канбана, чтобы двигать карточки по колонкам, и скрыл статус «Черновик», чтобы писать спокойно задачки. Кроме поля ответственного, добавил еще автора и временной промежуток.
Приятным бонусом Ноушен уведомлял ответственных при добавлении в задачу и при изменении статуса задачи. Естественно, и в журнале смен, и трекере можно было отсылаться с словарю, бизнес-логике, процессам и процедурам
▍Личные страницы
Иногда у агентов были их личные задания, а еще они писали свои заметки и конспекты во время обучения. Чтобы было легче давать обратную связь, мы все сделали как подстраницы в Ноушене базы знаний, куда доступ имели только агент и я. Туда же попали связанные таблицы смен и задач, отфильтрованные исключительно для агента.
▍Шпаргалка на смену
Наконец, сформировалась вполне стандартная процедура начала смены. Агент логинился в CRM, открывал обе ее части и конференцию репетиторов. Еще в одной вкладке была база знаний и трекер тасков. Руки так и просились собрать это в одном месте.
Так и сделал. Для всей команды появилась шпаргалка в Ноушене, которая собирала в одном месте ключевые правила, ссылки на рабочие и тестовые пространства, активные сегодня задачи, а также карточки предыдущей и следующей смены из журнала. Естественно, динамические компоненты Ноушен обновлял автоматически.
Не пугайтесь — самом деле, это не секретные документы КГБ. Просто решил показать живую шпаргалку.
Шпаргалка постоянно развивалась, и дополняется до сих пор. Так как мы сидели некоторое время в бесплатном Слаке, появились новости. А из-за моих фундаментальных ошибок в создании базы знаний, появились еще и патчи на бизнес-логику и процедуры. А после ошибок исправления, там появился список последних изменений и правок в базе знаний.
В чем я ошибся?
Вот мы и дошли до той части, где я оказался неправ. Так вот: описанная база знаний вполне рабочая и подходит многим проектам. Суперучилка просто оказалась сложнее, чем я полагал.
База знаний Суперучилки вводилась в действие постепенно, тестировалась в действии и обрела огромный успех. Агенты-новички уже были в нее вовлечены, и более того — напрямую влияли на её содержание, исправляя неадекватные реальности процедуры и добавляя новые. После работы в более линейной системе поддержки родительской компании, агенты почувствовали творческую свободу и возможность менять свою судьбу. Это правильные и желательные вещи для базы знаний.
За счет этого, вместо обычного срока онбординга в 3–4 недели, новички закончили свою тренировку за неделю. В какой-то момент, новички стали справляться со 100% нагрузки самостоятельно, и подстраховка коммандос им больше не требовалась.
А потом, ровно когда мы коммандос отключили и стали работать самостоятельно, у нас выстрелила рекламная кампания. Да так, что количество лидов увеличилось в сотни раз, и чаты стали разрываться от потенциальных клиентов. И пока я паниковал и искал подкрепление для новичков, оказалось, что новобранцы без труда отбиваются сами. Более того, перешли в наступление и придумали новый набор шаблонов и сценариев, специально под новый тип лидов.
Это был успех. Туман войны, который закрывал рабочие инструменты, правила и суть Суперучилки от новой команды агентов, развеялся.
И история о создании базы знаний Суперучилки имела бы только одну часть, если бы сама Суперучилка была завершенным продуктом. Тогда эта статья была бы универсальным руководством к действию.
Если бы Суперучилка была «готова», ее эволюция была бы медленным, но уверенным ползком по процентным делениям эффективности конверсии. Сложности приходили бы от масштабирования: завести больше клиентов, репетиторов и агентом, при этом не потеряв экономическую целесообразность. Доить денежную корову — приятная работа без лишнего стресса.
В таком случае, наша нелинейная, перекрестная база знаний, которая покрывала бизнес-логику и бизнес-процессы, оставалась бы актуальной вечно. Мы даже могли бы и документировать новые бизнес-процессы, обнаруживая их в жизни репетиторов и клиентов, и даже менять местами шаги бизнес-логики.
Такой подход к коллективной базе знаний работает, если у вас площадь области знания стремится в бесконечность, но система сущностей устоялась с конечной сложностью. Если же таксономия может меняться, нелинейный подход принесет кучу энтропии. А энтропия вытянет из команды и проекта энергию и выстрелит ею вам в ногу.
Получилось мудрено, потому вот пример из Википедии. Её авторы пытаются покрыть стремящееся в бесконечность человеческое знание, хаотично описывая зоны своих интересов, и так же бесконечно отстают от настоящего знания человечества. Но используя ссылки на несуществующие еще статьи, ссылаясь между статьями, и отпочковывая от больших статей маленькими, активисты Вики пускают в область знания корни и потихоньку прорастают дальше.
Это выглядит как эволюция видов, если бы у эволюции видо
