Память команды. Как перестать терять знания и начать их накапливать

Каждая команда знает больше, чем может рассказать. Это не философская абстракция – это будничная реальность, которую легко проверить. Любой разработчик в состоянии подробно объяснить, как устроен сервис, за который он отвечает. Но стоит попросить его записать это – и он запнётся. Не потому, что не знает. А потому, что знание живёт в нём иначе, чем на бумаге: переплетённое с контекстом, привычками, десятками мелких решений, которые он принимал на ходу и давно перестал замечать.

Это знание нигде не хранится. Оно распределено между людьми – в головах, в привычках, в мимолётных разговорах у кофемашины. Команда пользуется им каждый день, не задумываясь, откуда оно берётся и что с ним случится завтра. А завтра кто-то уходит – и вместе с ним исчезает фрагмент, о существовании которого остальные даже не подозревали.

У этого знания есть свойство, которое мы предпочитаем не замечать: оно временное. Не потому, что кто-то решил его не сохранять. А потому, что носитель, в котором оно живёт, – временный.

1.1. Где живёт знание

Если попросить команду нарисовать карту своего знания – где что хранится, кто что помнит, какие решения записаны и какие нет, – задача окажется невыполнимой. Не из-за лени и не из-за нехватки времени. А потому, что такой карты не существует. Знание команды не лежит в одном месте. Оно распределено – между людьми, чатами, кодом, файлами, устными договорённостями и тем, что «все и так знают». Ни у кого нет полного реестра. Ни у кого нет даже приблизительного представления о том, какая доля общего знания зафиксирована, а какая существует только в чьей-то голове.

Это распределённое облако. Кто-то помнит, как настроена система авторизации – не в общих чертах, а с нюансами: какой ключ используется для внешнего API, почему таймаут выставлен именно таким, что произойдёт, если его изменить. Кто-то – почему два года назад отказались от микросервисов в пользу монолита, и какие три варианта рассматривали перед этим, и что сказал тогдашний архитектор, который с тех пор ушёл. Кто-то держит в голове схему взаимодействия с внешним партнёром, которая никогда не была формализована, потому что «да там всё просто, я на созвоне объясню». Кто-то знает, что раз в квартал нужно вручную обновить сертификат, и помнит это только потому, что однажды забыл – и потратил выходные на разбор последствий.

Целостную картину не видит никто – ни руководитель, ни тимлид, ни самый опытный член команды. Каждый владеет фрагментом и предполагает, что остальные фрагменты тоже на месте. Предположение это редко проверяется. Оно проверяется только тогда, когда фрагмент исчезает.

Облако кажется надёжным. Пока команда стабильна – а она обычно стабильна достаточно долго, чтобы создать иллюзию – система работает. Вопрос задают тому, кто знает. Он отвечает. Проблема решается. Знание передаётся из головы в голову, минуя любые носители, и это выглядит как эффективность: зачем записывать, если можно спросить?

Механизм настолько привычен, что становится невидимым. Новый человек в команде задаёт вопрос – его направляют к тому, кто знает. Через неделю он сам начинает отвечать на часть вопросов. Через месяц – уже направляет других. Знание циркулирует, команда функционирует, и кажется, что так будет всегда. Облако даже растёт: с каждым новым человеком, с каждым новым проектом, с каждым решённым инцидентом команда знает больше. Проблема в том, что это «больше» существует только в распределённой форме – и любое изменение конфигурации грозит потерей.

Но у этой эффективности есть скрытая цена. Каждый раз, когда знание передаётся устно, оно привязывается к новому человеку – и только к нему. Оно не становится доступнее. Оно просто меняет носитель, оставаясь таким же хрупким. Спросили одного – он ответил. Его ответ осел в голове спрашивающего, смешавшись с собственным контекстом, слегка исказившись, слегка упростившись. Детали, которые казались ответчику очевидными, не были произнесены – и не были восприняты. Оговорки, которые он держал в уме, не прозвучали, потому что вопрос был конкретным, а ответ – быстрым. Через месяц пересказ будет приблизительным. Через полгода – фрагментарным. Через год – легендой, в которой правда и домысел переплелись неразличимо.

Где в этот момент живёт знание? Формально – в двух головах. Фактически – нигде надёжно. Первый носитель мог забыть детали. Второй мог запомнить их неточно. Между ними – пустота, которую оба считают заполненной.

Чаты создают похожую иллюзию. Кажется, что если решение обсуждали в рабочем чате – оно зафиксировано. В каком-то техническом смысле так и есть: сообщения сохраняются, поиск работает. Но знание в чате – это знание, утопленное в потоке. Обсуждение архитектурного решения перемешано с обсуждением обеда, перебивается уточнениями и ссылками, растянуто на два дня и три ветки. Финальное «ок, давай так» – тридцатое сообщение в цепочке, и без прочтения предыдущих двадцати девяти оно лишено смысла.

Чтобы восстановить контекст, нужно прочитать всё это заново – и понять, какие из сообщений содержат вывод, а какие были промежуточными мыслями, от которых потом отказались. Нужно отличить шутку от аргумента, предложение от решения, черновую идею от финального варианта. Нужно учесть, что часть обсуждения могла уйти в личные сообщения или в голосовой звонок, о котором в чате осталась только пометка «обсудили голосом, решили делать через очередь».

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

Код, казалось бы, надёжнее. Код – это зафиксированное решение, и в отличие от чата он не тонет в потоке. Но код хранит что, а не почему. Он показывает, как система устроена сейчас, но молчит о том, какие варианты рассматривались, почему выбрали именно этот, какие ограничения учитывались и какие компромиссы принимались. Комментарии, если они есть, объясняют механику – редко намерение. Коммит-сообщения описывают изменение – не причину изменения.

Через год команда смотрит на собственный код и не понимает его – не потому, что код плох, а потому, что контекст решения испарился. Осталась конструкция. Исчезло намерение. И вот уже три разработчика спорят, можно ли переписать этот фрагмент, – не зная, что он написан именно так из-за ограничения внешнего сервиса, которое было актуально год назад и, возможно, актуально до сих пор. Проверить некому: тот, кто знал, ушёл. Проверить негде: решение не было записано. Команда либо рискует и переписывает – и иногда наступает на те же грабли, – либо оставляет как есть из осторожности, накапливая технический долг из страха перед неизвестным.

У документации – там, где она существует – свои проблемы. Документ, написанный в момент создания системы, отражает реальность того момента. Но система меняется, а документ – нет. Через полгода он описывает архитектуру, которой больше нет. Через год он не просто неточен – он опасен, потому что создаёт ложную уверенность. Человек, который прочитал устаревший документ, думает, что знает. Он не знает – он введён в заблуждение. И что хуже: он не проверит, потому что у него нет причин сомневаться. Документ лежит на видном месте, выглядит официальным, датирован и подписан. Всё указывает на то, что ему можно доверять. Кроме одного: его никто не обновлял с тех пор, как реальность ушла вперёд.

Устные договорённости – ещё один призрачный носитель. «Мы решили на прошлой неделе», «мы же договорились на стендапе». Решение принято, все кивнули, никто не записал. Через месяц двое помнят решение по-разному. Через два – один не помнит вообще. Через три – третий человек принимает противоположное решение, не зная о первом, и никто не замечает противоречия, пока оно не всплывает в самый неудобный момент.

Таковы носители, в которых живёт командное знание. Головы, которые уходят. Чаты, которые тонут в потоке. Код, который молчит о причинах. Документы, которые устаревают. Устные договорённости, которые искажаются при передаче. Каждый из этих носителей кажется достаточным в моменте – и каждый ненадёжен на дистанции. Хуже того: команда использует их все одновременно, не задумываясь о том, что ни один не является хранилищем в строгом смысле слова. Это не места, куда знание кладут. Это места, где знание оказывается – случайно, попутно, как побочный продукт работы. И так же случайно оно оттуда исчезает.

Облако держится, пока ничего не происходит. Но команды – это не статичные структуры. Люди приходят и уходят, проекты трансформируются, приоритеты смещаются. Каждое такое движение создаёт нагрузку на облако, и в какой-то момент нагрузка превышает его невидимый предел прочности.

Стоит одному человеку уйти – и обнаруживается, что облако было с дырами. Человек, отработавший последний день, унёс с собой не только опыт и навыки – он унёс знание, которое существовало только в его голове. Как устроена интеграция с платёжной системой. Почему мониторинг настроен именно так, а не иначе. Где лежит скрипт, который запускают раз в квартал, и в каком порядке выполнять его шаги. Команда обнаруживает эти пустоты не сразу – а по мере столкновения с задачами, которые раньше решались одним вопросом к ушедшему. Теперь вопрос задать некому, и начинается археология: поиск в чатах, чтение коммитов, реконструкция из обрывков чужой памяти. Иногда удаётся восстановить. Иногда – нет, и приходится разбираться заново, как будто этого знания никогда не было. А иногда – и это самый коварный сценарий – команда даже не знает, что потеряла. Задача не возникает месяцами, а когда возникает, никто не помнит, что когда-то существовал человек, который решал её за пять минут.

Самое тревожное – масштаб невидимого. Команда знает, что теряет знание, когда уходит ключевой сотрудник. Это событие, его трудно пропустить. Но она не знает, сколько знания уже потеряно тихо – в незаписанных решениях, в забытых обсуждениях, в документах, которые перестали отражать реальность. Эта часть потерь не ощущается как потеря. Она ощущается как нормальная сложность работы: «ну, это нужно выяснить», «надо спросить у Миши», «кажется, это где-то обсуждали, но я не помню где».

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

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

Знание команды существует как распределённое облако – кажущееся надёжным, но хрупкое. Целостную картину не видит никто, а значит, никто не видит масштаба того, что может быть потеряно.

1.2. Анатомия потери

Когда в команде говорят о потере знания, почти всегда имеют в виду одно: ушёл человек. Это понятный, осязаемый сценарий. Человек написал заявление, отработал две недели – и вместе с ним исчезло то, что существовало только в его голове. Как настроен сервис, к которому, кроме него, никто не прикасался. Почему выбрана именно эта архитектура – и какие три альтернативы рассматривались перед тем, как остановиться на ней. Где лежат скрипты миграции, в каком порядке их запускать и что произойдёт, если порядок нарушить. Какие неочевидные зависимости связывают два модуля, которые на диаграмме выглядят независимыми, – и как эти зависимости проявляются под нагрузкой.

Две недели отработки создают иллюзию передачи. Ушедший проводит несколько встреч, отвечает на вопросы, иногда – пишет документ. Но передать можно только то, о чём спросили. А спросить можно только о том, о чём знаешь. Команда задаёт вопросы о том, что на поверхности: где лежит такой-то файл, как запускается такой-то процесс, кто контактное лицо на стороне партнёра. Эти ответы легко дать и легко записать. Но под поверхностью – слой знания, который не выражается в ответах на прямые вопросы. Почему настроено именно так. Какие варианты пробовали и от каких отказались. Какие неочевидные связи существуют между компонентами. Какие хрупкие места требуют внимания раз в сезон.

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

Уход – событие. Его видно. О нём можно говорить, к нему можно готовиться – хотя бы попытаться. Но уход – лишь самый заметный из путей, которыми знание покидает команду. Самый заметный – и далеко не самый разрушительный. Основной объём потерь происходит в обычные рабочие дни, по каналам, которых никто не отслеживает, и каждый из них по отдельности выглядит безобидно.

Первый из этих каналов – растворение. Знание, возникшее в разговоре, имеет срок жизни. Не формальный, а практический: период, в течение которого участники разговора помнят, о чём договорились. Этот период короче, чем принято думать. Решение, принятое на совещании в понедельник, к пятнице помнят все. Через две недели – большинство. Через месяц детали размываются: помнят суть, но не нюансы. А нюансы часто и есть суть. «Мы договорились перейти на новую версию» – помнят все. «Мы договорились перейти после того, как стабилизируем текущий релиз, и только если нагрузочное тестирование покажет не более пяти процентов деградации» – это помнят двое, и через месяц их версии будут различаться в цифрах.

Чат ускоряет растворение. Обсуждение в мессенджере течёт быстро, решения принимаются между другими темами, контекст не фиксируется. Через неделю сообщение уплыло за пределы видимого экрана. Через месяц – найти его можно только целенаправленным поиском, и то если помнить ключевые слова. Поиск по слову «миграция» выдаёт сотню результатов, и нужное обсуждение неотличимо от десятка других на ту же тему. Но кто будет искать решение, которое, как кажется, и так все помнят? Растворение происходит именно потому, что оно незаметно в каждый отдельный момент. Команда не чувствует, как решение тускнеет – она чувствует только результат, когда через три месяца два человека помнят его по-разному, и ни один не может доказать свою версию.

Второй канал – искажение. Знание, передаваемое устно, мутирует при каждой передаче. Это не злой умысел и не небрежность – это свойство устной коммуникации. Человек, пересказывая решение коллеге, неизбежно упрощает. Он опускает то, что считает очевидным – а для слушающего это может быть ключевым. Он расставляет акценты иначе, чем тот, кто принимал решение. Он добавляет собственную интерпретацию – не намеренно, а потому что иначе не умеет: мы не воспроизводим информацию, мы реконструируем её каждый раз заново, достраивая пробелы тем, что кажется логичным.

При первой передаче искажение минимально. При второй – оно накладывается на уже искажённую версию. При третьей – оригинал становится неразличим. Команда из десяти человек, в которой знание передаётся устно, через полгода оперирует не одной версией реальности, а несколькими. Различия между ними незаметны в обычной работе – они проявляются только в моменты конфликта, когда выясняется, что двое уверенно помнят разное, и оба правы в рамках своей версии. Спор заходит в тупик, потому что проверить невозможно: первоисточника нет. Есть только пересказы пересказов.

Третий канал – устаревание. Это, возможно, самый коварный из всех, потому что знание формально остаётся на месте. Документ существует. Страница в вики доступна. Файл лежит в папке. На первый взгляд всё в порядке – знание зафиксировано, оно никуда не делось. Но реальность, которую эти артефакты описывают, изменилась – а они нет. Система обновлена, процесс перестроен, интеграция заменена – а документ всё ещё описывает предыдущую версию с уверенностью первоисточника.

Устаревшее знание хуже отсутствующего. Когда знания нет – команда это знает и действует осторожно: проверяет, уточняет, разбирается. Когда знание есть, но неверно – команда действует уверенно и ошибается. Разработчик, прочитавший устаревшую документацию по деплою, не станет перепроверять каждый шаг. Он выполнит инструкцию, столкнётся с ошибкой – и потратит часы на выяснение причины, которая окажется тривиальной: инструкция просто описывает процесс, которого больше нет.

Устаревание коварно ещё и тем, что оно кумулятивно. Одна устаревшая страница – досадность. Десять – системная проблема. Когда команда не знает, каким документам можно доверять, а каким нет, она перестаёт доверять всем. Каждая встреча с неточным документом подтачивает доверие ко всей базе. Вики превращается из источника знания в источник сомнений, и люди возвращаются к привычному: спрашивают коллегу. Документация, которую никто не обновляет, становится документацией, которую никто не читает. А документация, которую никто не читает, гарантированно не будет обновляться. Круг замыкается.

Четвёртый канал – рассеивание. Знание, которое возникает в процессе работы, часто не осознаётся как знание. Разработчик, потративший день на отладку сложной ошибки, нашёл причину и исправил. Он знает теперь, что конкретный сервис ведёт себя неожиданно при определённых условиях. Это ценное знание – но оно не оформлено как знание. Оно осело в голове как опыт, как «теперь буду знать». Он не записал его, потому что в этот момент нужно было двигаться дальше – следующая задача уже ждала. Да и как это записать? Куда? В каком формате? Ради одного наблюдения заводить документ кажется избыточным. Написать в чат – утонет. Через год он сменит проект – и знание уйдёт вместе с ним, даже формально не будучи потерянным, потому что никто и не знал, что оно у него было.

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

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

Так же и команда. Она теряет знание через десятки невидимых каналов одновременно. Скорость потери в каждом отдельном канале ничтожна – сообщение, забытое за неделю; нюанс, искажённый при пересказе; документ, устаревший на один шаг. Но каналы работают параллельно, и совокупная потеря за месяц, за квартал, за год – значительна. Её невозможно измерить, потому что невозможно посчитать то, чего не стало. Но её можно ощутить – по косвенным признакам, которые команда привыкла считать нормой: растущему времени онбординга, вопросам без ответа, спорам о том, как было «на самом деле», инцидентам, которые повторяются, потому что выводы из прошлого не сохранились.

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

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

1.3. Цена забывания

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

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

Масштаб повторений трудно оценить, потому что они не выглядят как повторения. Разработчик, разбирающийся с ошибкой деплоя, не знает, что его коллега решал ту же проблему три месяца назад. Он тратит четыре часа и находит решение – на пятнадцать минут позже того момента, когда нашёл бы его в документации, если бы она существовала. Четыре часа – мелочь. Но четыре часа, помноженные на десятки подобных ситуаций в год, – это недели рабочего времени, потраченные на переоткрытие уже открытого.

Это не редкость и не крайний случай. Это повседневность. В любой команде, где знание хранится преимущественно в головах, повторное решение – норма. Его не считают потерей, потому что не с чем сравнивать: команда не знает, сколько времени сэкономила бы, если бы решение было записано. Она знает только, что задача заняла два дня. Что в прошлый раз она тоже заняла два дня – у другого человека, в другом контексте – никто не помнит.

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

Это означает, что онбординг нового сотрудника – нагрузка не только на него, но и на всю команду. Каждый вопрос – это прерывание чьей-то работы. Каждое объяснение – время, потраченное на передачу того, что могло бы быть записано. Самые опытные члены команды – те, кто знает больше всех – оказываются и самыми загруженными вопросами. Их производительность падает в периоды онбординга, и чем больше новых людей приходит одновременно, тем сильнее проседает команда. Парадокс: рост команды на время делает её слабее, потому что знание приходится передавать вручную, по одному вопросу за раз.

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

Можно поделать многое. Но пока знание не зафиксировано – онбординг остаётся устным пересказом, растянутым на недели и месяцы. Каждый новый человек получает слегка другую версию реальности, потому что объясняют ему разные люди, в разное время, с разной степенью полноты. Один коллега рассказывает подробно, другой – схематично, третий – с оговорками, которые забываются быстрее основного объяснения. К моменту, когда новый сотрудник начинает работать самостоятельно, его картина мира – лоскутное одеяло из чужих объяснений, собственных наблюдений и додуманного. Где-то оно совпадает с реальностью. Где-то – нет. Расхождения обнаружатся позже, обычно в неудобный момент – когда решение, принятое на основе неполной картины, оказывается ошибочным.