Ставим диагноз по базе знаний: ваш чек-лист по проблемам в процессах
Проблемы в организационных процессах компании заметны не сразу. Поначалу «звоночки» кажутся случайными ошибками.
Например, две разные команды обнаруживают, что занимаются решением одной задачи. С кем не бывает! Или уходит сотрудник, а с ним уходят и все знания об одной из систем. Или классные идеи бесконечно откладываются на потом, потому что сталкиваются со сложностями в реализации.
Эти и другие подобные ситуации — маркеры проблем в процессах, которые частично решаются с помощью базы знаний.
Меня зовут Саша Камзеева, я руководитель системного анализа в Lamoda Tech. На протяжении 8 лет помогаю создавать и поддерживать базы знаний в компании. В этой статье я перечислю проблемы в базе знаний, которые отражаются на организационных процессах, и расскажу, как искать решение этих проблем.
Статья будет полезна тем, кто влияет на организационные процессы в компаниях: менеджеры любого уровня, архитекторы, продуктологи, а также всем, кому небезразличны знания внутри компании. А в конце я дам чек-лист для самопроверки и постановки верного диагноза.
Как связаны база знаний и процессы?
Работая с 2010 года в IT, я замечала, как проблемы и их решение в базе знаний отражались на наших процессах.
Прежде чем доказать это на примерах, расскажу, что я понимаю под терминами «база знаний» и «организационные процессы».
База знаний — это не просто документация, а устоявшиеся процессы по передаче знаний друг другу через любые каналы связи. Например, разработчик выясняет с аналитиком в чате, как процессится заказ в зависимости от параметров. И этот чат и формат общения в нем — база знаний. Все чаты в корпоративных мессенджерах, переписки в электронной почте, techtalks, где инженеры делятся экспертизой, — ваша база знаний. Доска со стикерами в офисе, где был проведен командой event storming с action-листом — база знаний.
Организационными процессами в этой статье я обобщенно назваю все, что помогает идею преобразовать в бизнес-ценность: организационная структура, процессы планирования, найма, онбординга, проектирования, разработки, тестирования и т. д.
Один из самых ярких примеров, который вдохновил структурировать мысли в эту статью, произошел в 2021 году. У нас прошла трансформация команд разработки. Вместо команд, которые отвечали за конкретные системы, мы перешли на vTeams — кросс-функциональные команды, которые собираются для реализации определенной задачи. Об этом мы подробно рассказывали в статье. Я организовала встречу со всеми инженерами тестирования, чтобы обсудить, как правильно проводить интеграционное тестирование и UAT (операционное тестирование) после всех изменений. Спустя 5 минут разговора я обнаружила, что ребята встретились вместе впервые за год. И этот год они решали одни и те же вопросы самостоятельно, делали двойную работу: не объединялись, не передавали знания друг другу — каждый боролся в своем уголочке отдельно.
Так появилась гипотеза, что проблема в базе знаний может влиять на организационные процессы.
В этой статье я собрала восемь проблем в базе знаний, которые показывают, что в организационных процессах что-то идет не так. Развивая обмен знаниями, занимаясь базой знаний в команде можно прямо или косвенно решить проблемы в организационных процессах.
В конце вы найдете чек-лист для самопроверки. Присмотритесь к пунктам, рядом с которыми не можете поставить галочки: возможно, это ваша зона роста, и за нее стоит взяться прямо сейчас, пока проблемы не перешли на более высокий уровень.
Первая проблема: нет базы знаний
Когда мы говорим, что база знаний помогает выявлять проблемы в организационных процессах, возникает первый вопрос —, а если базы знаний нет?
Для меня это равносильно тому, что в компании нет культуры передачи знаний. Как следствие, нет синхронизации между командами и внутри команд. Из-за этого сотрудники могут тратить время на уже решенные вопросы, как было в истории с инженерами тестирования, которую я рассказывала выше.
Также есть риск дорогих ошибок. Проиллюстрирую историей из собственной практики. У нас была полезная для клиентов идея: добавить на экран чекаута поле «Комментарий» для доставки. С его помощью наши курьеры могли бы получать подробную информацию, как позвонить по домофону, добраться до покупателя и так далее.
В клиентских приложениях эту фичу быстро реализовали, но в приложении для курьеров поле долго не появлялось: задачу постоянно блокировали в системах доставки и order processing из-за низкого приоритета. Первая команда не ожидала, что поле пробрасывается через 6 систем, и базы знаний об этом не было, поэтому запланировала задачу у себя, не синхронизируясь с другими командами. В итоге все, что сделала первая команда, пришлось спрятать в стол. Мы потратили время и деньги, а задачу не решили.
Если в компании нет процесса передачи знаний, то они теряются безвозвратно. В 2016 году у нас был эксперт, который знал все про скидки. После его ухода нам понадобилось полгода, чтобы воссоздать те же знания. Шесть месяцев без знаний о скидках e-com — критичное для бизнеса время.
Когда процессы передачи знаний не выстроены, долго и сложно онбордить новых сотрудников. У меня была маленькая команда. Когда она пополнялась, я тратила по часу в день на то, чтобы рассказать, как устроен IT-ландшафт и все наши бизнес-процессы. Когда мы настроили базу знаний, новички стали справляться самостоятельно. Благодаря базе знаний я сэкономила месяцы работы своих сотрудников, т. к. команда росла и онбординг становился объемнее.
Если базы знаний нет, то классно начинать с простого способа сохранения знаний внутри компании — с TechTalks, небольших митапов, на которых специалисты из одной сферы выступают перед коллегами из других отделов с докладами. Так вы можете легко и дешево сохранить знания внутри компании в структурированном виде.
Еще один бонус — возможность дотянуться до «случайных» слушателей. Помните пример про корзину и поле «Комментарий» для курьерской доставки? Если бы команда знала, какие сложные у нас монолиты, они бы запланировали разработку иначе.
Вторая проблема: базой знаний не пользуются
Вторая популярная проблема касается документации в любом виде: Confluence, ReadMe, задачи в JIRA. Одни команды что-то пишут/сохраняют в том или ином формате, а другие не пользуются написанным.
В рамках компании эта проблема обходится дорого: одни тратят время, чтобы знания сохранить или передать, а другие этим не пользуются. Получается, что документация не нужна?
У нас тоже такие случаи были и для себя я выделила следующие причины:
База знаний неактуальная, поэтому какой смысл к ней обращаться? Если мы приняли решение какие-то данные сохранять, то важно выстроить процесс их актуализации. А если знания не требуются, то их безжалостно удалять, переносить в архив или отмечать, как неактуальные.
Неудобный поиск информации или непонятная структура приводят к плохому user experience. И как следствие, нежеланию что-то искать в документации. Поэтому нужно обкатывать структуру на пользователях, собирать обратную связь и ее отрабатывать.
Плохо и непонятно написано. В этом случае еще обиднее, так как уже много времени инвестировано в документацию, а из-за плохо составленного текста/диаграмм базой знаний пользоваться не будут. Поэтому крайне важно уметь четко и емко формулировать свои мысли, знать и обозначать цели статей, чтобы читающий мог с легкостью понять написанное.
О базе знаний не знают. Такое тоже бывает, именно поэтому важно об этом говорить, писать в корпоративных каналах, рассказывать на всех публичных мероприятиях.
Третья проблема: отсутствует единый источник знаний
Популярная проблема, что часть компании пользуется Confluence, другая — Google-документами, третья признает только Notion. Как следствие, в компании высокая вероятность ошибок. Непонятно, в каком документе самая актуальная информация, а еще не все коллеги знают о существовании разных источников.
У нас было так: бизнес смотрел в Google-документ, а ИТ — в Confluence. В итоге комментарии, их исправление и поддержка в актуальном состоянии приводила к двойным затратам, либо к неверному результату.
Также в этом случае нужно обеспечивать сохранность всех документов в случае ухода сотрудника. А это приводит либо к потерям источников информации, либо к двойным, тройным тратам, чтобы не потерять данные.
Выход тут один: добиваться единого источника информации, чтобы вся команда смотрела в одни статьи, в одни документы. В крайнем случае декомпозировать информацию таким образом, чтобы статьи в разных источниках дополняли друг друга, а не дублировали.
Четвертый маркер: отсутствие единого глоссария
Отсутствие единого глоссария и разделения по доменам, как и расхождение внутреннего глоссария с внешним, приводят к тому, что мы говорим на разных языках.
Раньше в Lamoda команды могли называть разные процессы и сущности одним и тем же словом — «возвраты». Одна команда говорила про те ситуации, когда клиент выкупил заказ, вернул товар, а теперь хочет получить за него деньги. А другая команда воспринимала это как товары, от которых клиент отказался на этапе примерки, не выкупив заказ.
Процессы разные, суть разная. Пока не пройдет полчаса, пока они не уткнутся в тупик, не вернутся к началу, не определят заново термины — так и не поймут, что говорили не об одном и том же.
Пятая проблема: нет знаний об организационных процессах
Этот блок отвечает за понимание и описание организационных процессов.
Если нет описания ролей, то нет и разделения зон ответственности. В этом случае задачи, которые попадают в зоны ответственности нескольких команд, могут одновременно решаться с двух сторон. Либо о них могут вообще забыть. Например, у системных аналитиков и техлидов есть похожие зоны ответственности. Если это нигде не зафиксировано, каждый из них будет постоянно задаваться вопросом о том, где проходит граница зон ответственности.
Если нет стандартов, то нет и понимания качества. Это свидетельствует о серьезной проблеме в организации. Что значит «хорошо спроектированные сервисы в рамках инициативы»? Что значит «хорошо протестированные сервисы» или «хорошо сделанный код-ревью»?
Если нет ответственности за процессы, то нет прозрачности и четких прогнозов по срокам перед бизнесом. Тоже довольно популярная история, когда есть бизнес, а есть IT. Бизнес ожидает, что IT довольно быстро будет доставлять бизнес-ценности и соблюдать спрогнозированные сроки и обещания. Если IT не может это сделать, то отсутствует прозрачность и понимание того, почему так долго. Еще хуже, если команда вообще не может спрогнозировать сроки. Когда нет ответственных и полной картинки, ничего нельзя сказать бизнесу, — значит, они не захотят инвестировать деньги в IT и в развитие компании.
Шестая проблема: нет знаний о доменных областях
Проблемы возникают, когда нет четкой декомпозиции доменных областей. Есть IT-департамент, есть IT-ландшафт, но никто не понимает, как формируется список продуктов или бизнес-процессов компании, на что он подразделяется.
Если знания о доменных областях не актуализируются, а изменения — не фиксируются, договоренности и прогресс по задачам не сохраняются. Это ведет к двум проблемам:
У команд в голове нет целевой картинки и доверия к базе знаний. Вернемся к проекту с полем «Комментарий» для доставки. У ребят не было представления о том, что информация должна пройти через все системы процессинга заказа и дойти до системы доставки, чтобы ее увидели торговые представители. Когда этой картинки нет в голове, невозможно декомпозировать задачи.
Если у сотрудников есть неактуальная информация, то нет доверия к базе знаний. В таком случае Confluence или другую подобную базу будут воспринимать как мусорку. Вы тратите время, чтобы разобраться в этом потоке, но это напрасно.
Особенно важно следить за тем, чтобы у коллег было выделенное время на актуализацию знаний после изменений. Звучит вполне логично и очевидно, но очень сложно выполнимо. Потому что обычно разработка после релиза фичи сразу же принимается за следующую задачу.
Это сложный волевой процесс — дать команде время на то, чтобы она актуализировала данные. Но только так базой знаний можно будет пользоваться.
Седьмая проблема: знания об архитектуре
Если нет архитектурной схемы, описания системы сервисов или контрактов, начинаются те же проблемы, что и в предыдущем кейсе, но под другим углом. У команды в голове нет целостной картинки, но уже не просто бизнес-процессов, а целого IT-ландшафта — и нет доверия к базе знаний.
У нас было такое, что из одного сервиса, критично важного для бизнес-процессов, ушел сотрудник, который был указан как ответственный. Произошел инцидент, поддержка искала решение больше 30 минут. Мы потратили полчаса времени, которым не располагали в критической ситуации.
Восьмая проблема: безопасная безопасность
Если в компании нет общего доступа к базе знаний или его непросто получить, вы не станете с этим мучаться и тратить время. Необходимость в ответе пропадет, вы решите проблему иначе.
Еще один пример — когда общая информация закрыта. В результате сотрудники не будут пользоваться базой знаний вообще или откроют дубликат. О проблемах двух источников информации мы говорили выше.
База знаний должна быть открыта. Все, что можно открыть, нужно открывать — тогда этим источником будут пользоваться, его будут актуализировать, и этот процесс получится налаживать.
Подведем итоги
Ниже вы можете проверить себя по чек-листу. Проставьте плюсы и минусы напротив каждого пункта и посчитайте их количество. Если плюсов больше, вас можно поздравить: организационные процессы работают хорошо. Конечно, нет предела совершенству, но это уже большой шаг вперед.
Если минусов больше, это еще один аргумент в пользу перемен. Как менять — это тема абсолютно другой статьи.
Чек-лист:
Процесс передачи знаний отлажен.
Есть ответственный за базу знаний.
У базы знаний один источник.
Базой знаний пользуются.
Сотрудники понимают, где и как искать информацию.
Сотрудники знают, как актуализировать базу знаний.
В компании проходят TechTalks.
В компании есть глоссарий.
Глоссарий разделен на доменные области.
Если есть внутренний и внешний глоссарии, то термины и определения не отличаются.
Коллеги используют термины из глоссария.
В коде также используются термины из глоссария.
Роли организационных процессов определены и описаны.
Команды знают о ролях организационных процессов.
В компании есть принятые стандарты.
Команды знают эти стандарты.
Есть ответственные за организационные процессы.
Команды знают ответственных за организационные процессы.
Определены доменные области с описанием продуктов и бизнес-процессов.
Есть ответственный за каждую доменную область.
Знания о доменных областях актуализируются.
У коллег есть выделенное время на актуализацию знаний после изменений.
Договоренности фиксируются и их можно найти в базе знаний.
Есть архитектурная схема.
Каждая система/сервис подробно описаны (ответственные, предназначение, схема взаимодействия, полезные ссылки).
Есть описание контрактов.
Информация о системе/сервисе актуализируется.
У ответственных есть время актуализировать знания о системе/сервисе сразу.
База знаний доступна для пользователей, получать отдельный доступны, согласования к необходимой информации не нужно.
