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

Например, две разные команды обнаруживают, что занимаются решением одной задачи. С кем не бывает! Или уходит сотрудник, а с ним уходят и все знания об одной из систем. Или классные идеи бесконечно откладываются на потом, потому что сталкиваются со сложностями в реализации. 

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

Меня зовут Саша Камзеева, я руководитель системного анализа в Lamoda Tech. На протяжении 8 лет помогаю создавать и поддерживать базы знаний в компании. В этой статье я перечислю проблемы в базе знаний, которые отражаются на организационных процессах, и расскажу, как искать решение этих проблем. 

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

Как связаны база знаний и процессы? 

Работая с 2010 года в IT, я замечала, как проблемы и их решение в базе знаний отражались на наших процессах.

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

База знаний — это не просто документация, а устоявшиеся процессы по передаче знаний друг другу через любые каналы связи. Например, разработчик выясняет с аналитиком в чате, как процессится заказ в зависимости от параметров. И этот чат и формат общения в нем — база знаний. Все чаты в корпоративных мессенджерах, переписки в электронной почте, techtalks, где инженеры делятся экспертизой, — ваша база знаний. Доска со стикерами в офисе, где был проведен командой event storming с action-листом — база знаний. 

Организационными процессами в этой статье я обобщенно назваю все, что помогает идею преобразовать в бизнес-ценность: организационная структура, процессы планирования, найма, онбординга, проектирования, разработки, тестирования и т. д.

Один из самых ярких примеров, который вдохновил структурировать мысли в эту статью, произошел в 2021 году. У нас прошла трансформация команд разработки. Вместо команд, которые отвечали за конкретные системы, мы перешли на vTeams — кросс-функциональные команды, которые собираются для реализации определенной задачи. Об этом мы подробно рассказывали в статье. Я организовала встречу со всеми инженерами тестирования, чтобы обсудить, как правильно проводить интеграционное тестирование и UAT (операционное тестирование) после всех изменений. Спустя 5 минут разговора я обнаружила, что ребята встретились вместе впервые за год. И этот год они решали одни и те же вопросы самостоятельно, делали двойную работу: не объединялись, не передавали знания друг другу — каждый боролся в своем уголочке отдельно. 

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

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

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

Первая проблема: нет базы знаний

Когда мы говорим, что база знаний помогает выявлять проблемы в организационных процессах, возникает первый вопрос — а если базы знаний нет? 

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

Также есть риск дорогих ошибок. Проиллюстрирую историей из собственной практики. У нас была полезная для клиентов идея: добавить на экран чекаута поле «Комментарий» для доставки. С его помощью наши курьеры могли бы получать подробную информацию, как позвонить по домофону, добраться до покупателя и так далее. 

В клиентских приложениях эту фичу быстро реализовали, но в приложении для курьеров поле долго не появлялось: задачу постоянно блокировали в системах доставки и order processing из-за низкого приоритета. Первая команда не ожидала, что поле пробрасывается через 6 систем, и базы знаний об этом не было, поэтому запланировала задачу у себя, не синхронизируясь с другими командами. В итоге все, что сделала первая команда, пришлось спрятать в стол. Мы потратили время и деньги, а задачу не решили.

Если в компании нет процесса передачи знаний, то они теряются безвозвратно. В 2016 году у нас был эксперт, который знал все про скидки. После его ухода нам понадобилось полгода, чтобы воссоздать те же знания. Шесть месяцев без знаний о скидках e-com — критичное для бизнеса время.

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

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

Еще один бонус — возможность дотянуться до «случайных» слушателей. Помните пример про корзину и поле «Комментарий» для курьерской доставки? Если бы команда знала, какие сложные у нас монолиты, они бы запланировали разработку иначе. 

Вторая проблема: базой знаний не пользуются

Вторая популярная проблема касается документации в любом виде: Confluence, ReadMe, задачи в JIRA. Одни команды что-то пишут/сохраняют в том или ином формате, а другие не пользуются написанным. 

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

У нас тоже такие случаи были и для себя я выделила следующие причины:

1. База знаний неактуальная, поэтому какой смысл к ней обращаться? Если мы приняли решение какие-то данные сохранять, то важно выстроить процесс их актуализации. А если знания не требуются, то их безжалостно удалять, переносить в архив или отмечать, как неактуальные. 

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

3. Плохо и непонятно написано. В этом случае еще обиднее, так как уже много времени инвестировано в документацию, а из-за плохо составленного текста/диаграмм базой знаний пользоваться не будут. Поэтому крайне важно уметь четко и емко формулировать свои мысли, знать и обозначать цели статей, чтобы читающий мог с легкостью понять написанное.

4. О базе знаний не знают. Такое тоже бывает, именно поэтому важно об этом говорить, писать в корпоративных каналах, рассказывать на всех публичных мероприятиях.

Третья проблема: отсутствует единый источник знаний

Популярная проблема, что часть компании пользуется Confluence, другая — Google-документами, третья признает только Notion. Как следствие, в компании высокая вероятность ошибок. Непонятно, в каком документе самая актуальная информация, а еще не все коллеги знают о существовании разных источников.

У нас было так: бизнес смотрел в Google-документ, а ИТ — в Confluence. В итоге комментарии, их исправление и поддержка в актуальном состоянии приводила к двойным затратам, либо к неверному результату. 

Также в этом случае нужно обеспечивать сохранность всех документов в случае ухода сотрудника. А это приводит либо к потерям источников информации, либо к двойным, тройным тратам, чтобы не потерять данные.

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

Четвертый маркер: отсутствие единого глоссария

Отсутствие единого глоссария и разделения по доменам, как и расхождение внутреннего глоссария с внешним, приводят к тому, что мы говорим на разных языках.

Раньше в Lamoda команды могли называть разные процессы и сущности одним и тем же словом — «возвраты». Одна команда говорила про те ситуации, когда клиент выкупил заказ, вернул товар, а теперь хочет получить за него деньги. А другая команда воспринимала это как товары, от которых клиент отказался на этапе примерки, не выкупив заказ. 

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

Пятая проблема: нет знаний об организационных процессах

Этот блок отвечает за понимание и описание организационных процессов. 

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

Если нет стандартов, то нет и понимания качества. Это свидетельствует о серьезной проблеме в организации. Что значит «хорошо спроектированные сервисы в рамках инициативы»? Что значит «хорошо протестированные сервисы» или «хорошо сделанный код-ревью»?

Если нет ответственности за процессы, то нет прозрачности и четких прогнозов по срокам перед бизнесом. Тоже довольно популярная история, когда есть бизнес, а есть IT. Бизнес ожидает, что IT довольно быстро будет доставлять бизнес-ценности и соблюдать спрогнозированные сроки и обещания. Если IT не может это сделать, то отсутствует прозрачность и понимание того, почему так долго. Еще хуже, если команда вообще не может спрогнозировать сроки. Когда нет ответственных и полной картинки, ничего нельзя сказать бизнесу, — значит, они не захотят инвестировать деньги в IT и в развитие компании. 

Шестая проблема: нет знаний о доменных областях

Проблемы возникают, когда нет четкой декомпозиции доменных областей. Есть IT-департамент, есть IT-ландшафт, но никто не понимает, как формируется список продуктов или бизнес-процессов компании, на что он подразделяется. 

Если знания о доменных областях не актуализируются, а изменения — не фиксируются, договоренности и прогресс по задачам не сохраняются. Это ведет к двум проблемам: 

1. У команд в голове нет целевой картинки и доверия к базе знаний. Вернемся к проекту с полем «Комментарий» для доставки. У ребят не было представления о том, что информация должна пройти через все системы процессинга заказа и дойти до системы доставки, чтобы ее увидели торговые представители. Когда этой картинки нет в голове, невозможно декомпозировать задачи.

2. Если у сотрудников есть неактуальная информация, то нет доверия к базе знаний. В таком случае Confluence или другую подобную базу будут воспринимать как мусорку. Вы тратите время, чтобы разобраться в этом потоке, но это напрасно. 

Особенно важно следить за тем, чтобы у коллег было выделенное время на актуализацию знаний после изменений. Звучит вполне логично и очевидно, но очень сложно выполнимо. Потому что обычно разработка после релиза фичи сразу же принимается за следующую задачу.

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

Седьмая проблема: знания об архитектуре

Если нет архитектурной схемы, описания системы сервисов или контрактов, начинаются те же проблемы, что и в предыдущем кейсе, но под другим углом. У команды в голове нет целостной картинки, но уже не просто бизнес-процессов, а целого IT-ландшафта — и нет доверия к базе знаний.

У нас было такое, что из одного сервиса, критично важного для бизнес-процессов, ушел сотрудник, который был указан как ответственный. Произошел инцидент, поддержка искала решение больше 30 минут. Мы потратили полчаса времени, которым не располагали в критической ситуации. 

Восьмая проблема: безопасная безопасность

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

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

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

Подведем итоги

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

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

Чек-лист:

• Процесс передачи знаний отлажен.

• Есть ответственный за базу знаний.

• У базы знаний один источник.

• Базой знаний пользуются.

• Сотрудники понимают, где и как искать информацию.

• Сотрудники знают, как актуализировать базу знаний.

• В компании проходят TechTalks.

• В компании есть глоссарий.

• Глоссарий разделен на доменные области.

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

• Коллеги используют термины из глоссария.

• В коде также используются термины из глоссария.

• Роли организационных процессов определены и описаны.

• Команды знают о ролях организационных процессов.

• В компании есть принятые стандарты.

• Команды знают эти стандарты.

• Есть ответственные за организационные процессы.

• Команды знают ответственных за организационные процессы.

• Определены доменные области с описанием продуктов и бизнес-процессов.

• Есть ответственный за каждую доменную область.

• Знания о доменных областях актуализируются.

• У коллег есть выделенное время на актуализацию знаний после изменений.

• Договоренности фиксируются и их можно найти в базе знаний.

• Есть архитектурная схема.

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

• Есть описание контрактов.

• Информация о системе/сервисе актуализируется.

• У ответственных есть время актуализировать знания о системе/сервисе сразу.

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