Создание и управление базой знаний, которую будут заполнять и будут пользоваться

Меня зовут Николай Елатонцев. Я руковожу профессиональной сервисной командой. Мы разработали свою методологию сопровождения проектов с помощью системы тректинга и регламентов. База знаний для нас – не просто важный инструмент, а тотальная необходимость.

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

Чем занимается наша команда? Мы сопровождаем 1С, CRM и крупные e-commerce проекты: разрабатываем и дорабатываем их. Мы – фанаты времени. Мы знаем, на что была потрачена каждая минута работы программиста. Отсюда и появилась методология трекинга для базы знания, о которой я сейчас расскажу.

С какими проектами приходится встречаться

1. Проект выполнен по ТЗ с уникальным функционалом, часто без документации, или с минимальным описанием.

2. Проект сдан по ТЗ, есть первоначальная документация. Проект развивается, но доработки не фиксируются и вскоре он теряет актуальность.

3. К нам попадает «чужой проект», в котором нет ничего.

Как работает стандартная команда на сопровождении

• Не заполняют базу знаний. Программистам лень написать даже комментарий в коде, а тем более работать с базой. Нет времени и нет мотивации.

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

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

• Не доходят руки. Работа в моменте. Прекрасно живем и без нее. Получается синусоида: «пока все вроде бы нормально» и избегаешь факапов на проекте – время на работу с базой не тратишь. Когда появляется проблема – возникают вопросы: «Почему это у нас не описано? Надо внедрять!»

  Проходит время, мы снова «на коне», и руки до базы знаний опять не доходят.

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

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

• Новому исполнителю требуется много времени на изучение корпоративного функционала.

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

Что база знаний дает команде

• Лояльность клиента. Лояльность - важнейший вектор, который помогает удерживать клиентов.

• Увеличение LTV. Это наша основная метрика, которая показывает, насколько мы полезны. Lifetime Value - это время между первым и последним платежом клиента. Для нас важно, чтобы LTV рос, потому что мы - сервисная команда.

• Минимизация ошибок. Когда вся информация есть в базе знаний, ошибок становится значительно меньше.

• Сокращение времени исполнения задачи. Самое главное для производства - это время. Когда мы работаем с уже существующим функционалом, который кем-то был написан давно, время исполнения сокращается.

• Уверенность, что ничего не сломали.

• Все ради денег. Все вышеописанные факторы дают хорошую прибыль. Но об этом чуть позже.

Как встроить документирование в работу команды

Базу знаний важно внедрить в процесс разработки или поддержки. Важнее всего – процессы, а в чем базу знаний вести, это уже вторично.

Есть первоначальная документация, которая приходит с проектом (ТЗ, описание функционала). PM или TeamLead препарирует документ, разделяя на блоки. Выкидывается все лишнее (а лишнего много).

Все это кладется в базу знаний.

Если оплатили аудит и предъявили хорошую информацию для заполнения базы знаний – прекрасно! Если аудит не оплачен – проект стартует без этого. Нет документации – ничего страшного. Проект начинает сопровождаться без нее.

Работа при новой задаче:

• Новая задача фиксируется в ServiceDesk.

• Если функционал новый, то кто-то старший (PM или тимлид) еще до выполнения задачи определяет, требуется ли описание. Они принимают решение, нужно или не нужно добавлять информацию об этой задаче или проекте в базу знаний.

• При исполнении добавляются оплачиваемые часы исполнителя на описание. Именно исполнитель добавляет в базу контекст или другую информацию. Иногда эту работу берет на себя PM. Время программиста оплачивается.

Работа над уже существующим функционалом:

В этом случае самое сложное – обеспечить корректное и быстрое обновление базы знаний.

• Новая задача фиксируется в ServiceDesk. Если описание уже есть в базе знаний, его нужно найти и по необходимости править.

• При использовании системы контроля версий (GitHub и т.п.) необходимо уведомление, что код, с которым работал разработчик, есть в описании БЗ.

• Запускается регламент добавления описания.

Умение команды работать с базой знаний

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

Как решаются задачи без базы знаний

1. Приходит задача в ServiceDesk,

2. Исполнитель дает оценку,

3. Оценка одобряется клиентом,

4. Задача решается, заливается на прод,

5. На выходе клиент ставит еще четыре задачи с ошибками вне оплаты. Приехали!

Как решаются задачи, если база знаний есть, но никто не знает правил ее использования

1. Приходит задача в ServiceDesk,

2. Исполнитель заходит в БЗ,

3. Там он видит 25 статей из Wiki с крайней датой за 2021 год,

4. Исполнитель краем глаза посмотрел, посчитал информацию неактуальной.

5. Задача решается, заливается на прод,

6. На выходе опять видим четыре новые задачи с ошибками, которые ставит клиент.

Как правильно поступать

1. Приходит задача в ServiceDesk,

2. Исполнитель заходит в БЗ,

3. Там он видит те же самые 25 статей в Wiki,

4. Происходит «волшебство»,

5. Задача заливается на прод,

6. И все. Все счастливы. Никаких дополнительных доработок и никаких новых задач!

Теперь расскажу про это «волшебство» – конкретную практику, которую мы реализовали. Я буду очень рад, если она поможет вам улучшить процессы.

Волшебство: создание базы знаний

Что нужно знать, чтобы сделать магию

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

• Нужно знать, что искать. Если ты исполняешь задачу на проекте, то знаешь, что у проекта есть база знаний и структура. Работай, ориентируясь на нее.

• Нужно знать, как искать. В регламенте должна быть инструкция: как искать информацию, как найти нужный функционал или описание в базе знаний.

• Нужно знать, где искать. В базе должна быть ссылка или несколько ссылок, так как часто одна общая база знаний ведется в одной истории или системе, а более детальная разбросана по другим системам или кастомным решениям.

Знать, что искать и знать, как искать – эти правила должны быть зафиксированы в регламенте работы с базой знаний при аналитике.

Как сделать магию

При допуске к работе над задачами необходимо сделать обучающий курс по работе с БЗ вне зависимости от уровня исполнителя – будь то джуниор, мидл или сеньор. Если у вас уже внедрена система, этот человек должен пройти его и сдать тест или пройти собеседование.

Разработать методологию ведения базы знаний и поиска в ней.

Использовать удобный инструмент хранения всей информации. Про удобство инструментов – это отдельный разговор. Так сложилось из нашего опыта, что использовать только одну систему у нас не вышло. У нас около 80-100 активных проектов. Процессы постоянно обновляются, появляются новые задачи.

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

• Ключевые слова (теги), комментарии. Их использование должно стать обязательным. В базе знаний должно быть облако тегов, чтобы каждый мог их использовать.

• Регламенты (правила). Все реализуется через регламенты – документы с правилами.

• Ретроспектива. Очень важно регулярно проводить ретроспективы. На ретроспективе тимлид смотрит, что нужно дополнить или исправить. Обсуждается, почему нарушались регламенты: иногда – по объективным причинам (например, аварии); чаще – по субъективным (не было времени). В этом случае ситуация анализируется и принимаются решения. Проводить ретроспективы очень важно – это одна из ключевых практик любой команды. Главное – правильно их проводить. Ретроспективы – это не про неформальную тусовку, а про контроль. Они помогают выявлять проблемы и вносить коррективы. Если ретроспективу делать правильно, то магия с базой знаний, как у нас, очень быстро заработает. У нас она заработала через месяц.

На базе всей этой информации тимлид на выходе получает документ. Первоначально на этот работу определялась неделя (40 часов): с плотным погружением в процессы и с описанием.

Как тимлид будет контролировать исполнение

Контрольные точки (CI/CD) обязательно должны быть расставлены. В нашей компании для удобства инструментов разработана система контроля версий, в которой над кодом подсвечивается база знаний. Контрольные точки будут помогать фиксировать этапы исполнения.

Ретроспектива. На ретроспективу еженедельно тимлид должен тратить 4 часа. О процессах нужно постоянно говорить. Каждую неделю на ретроспективе тимлид со своей командой должен обсуждать процессы.

• Все лишнее – убираем. Может появиться что-то, что «не работает» по мнению тимлида, бизнеса или заказчика. Избыточная тема, например, может привести команду к неправильному flow. Это надо пресекать.

• Все, что работает – оставляем.

• Все, чего не хватает – добавляем.

Волшебные цифры: по часам, деньгам и команде

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

Что происходит по часам

• Количество бесплатных часов на больших задачах или проектах уменьшилось до 15%. Мы трекаем абсолютно все часы, которые есть по задаче. Большую задачу, например, на 20 часов, декомпозируем на три мини-проекта по 6-7 часов. При этом клиент со своей стороны видит все транзакции: и платные, и бесплатные часы. Все прозрачно и удобно. До внедрения базы знаний по такой задаче могло быть 20 платных часов и 15 бесплатных, средняя стоимость часа по проекту при этом сильно снижалась. После внедрения базы знаний количество бесплатных часов сильно уменьшилось.

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

• На 40% уменьшилось количество времени на решение проблем. Это статистика за долгий срок. Происходит процесс накопления базы знаний, проект какое-то время с ней живет, задачи начинают выполняться быстрее, нет ошибок.

• На 30% уменьшилось количество обращений в поддержку, когда на каждую задачу клиент ставит четыре новые задачи, как в борьбе с Гидрой: одну голову срубаешь – новые вырастают. Благодаря базе знаний мы избавились от этой проблемы.

Что происходит по деньгам

• Рентабельность проекта увеличивается на 15-20%. Что мы считаем рентабельностью? Это отношение платных часов к общему числу затраченных часов на проекте. К сожалению, в нашей команде есть проекты, где рентабельность очень низкая: стоимость часа на этих проектах стремится к нулю. Это сильно влияет на экономику. Если задачу оценили в 3 часа, а сделали за 3 дня – потеря в деньгах очень большая. Важно это отслеживать и видеть, как распределяется время.

Что происходит в команде

• Загрузка команды становится более равномерной. Не стало страшно вводить новых исполнителей в проект, потому что есть инструмент, с которым они будут работать не хуже старых.

• Количество аварий на проекте уменьшается. Ничто так не триггерит команду, как авария, когда нужно срочно спасать аккаунты.

• Тушение пожаров прекращается.

• Обучение новых сотрудников происходит значительно быстрее.

Продажа базы знаний клиенту

Теперь, когда база знаний готова – ее нужно продать клиенту. Нужно показывать клиенту вашу базу знаний. Этим никто не занимается. Помните, что клиент выбрал вас, по умолчанию решив, что вы не будете фейлить и сдадите все в срок. Ваша предсказуемость – это его базовое ожидание.

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

• Стоимость часа только из-за наличия базы знаний можно увеличить на 15% (например с 3500 рублей до 4000 рублей). Для постоянных клиентов с крупными объемами задач поднятие стоимости происходит намного проще.

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

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

• Повышение прозрачности работы.

Что в итоге

Чтобы выбранный инструмент встроить в процессы, нужно:

• Разработать регламенты,

• Выставить контрольные точки,

• Следить за актуальностью и заполняемостью базы знаний,

• Активно ею пользоваться.

В чем конкретно можно вести базу знаний:

• в Google Docs – для старта,

• в Confluence, Notion, Obsidian – там есть и структурирование, и удобство, и интеграции,

• БЗ с ServiceDesk в одном окне – удобство высшего уровня. Клиент ставит задачу, мы нажимаем волшебную кнопку и прямо из задачи переходим в базу знаний по проекту. Сейчас мы допиливаем эту кнопку, чтобы переход осуществлялся именно в ту часть, которая касается текущей задачи.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.