Григорий Петров: Как повелевать знаниями

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

В комментариях или в ворде?

Относительно хранения информации, разработчики делятся на два лагеря. Примерно половина считает, что информацию лучше всего хранить рядом с кодом. В самом коде, в скриптах системы continuous integration, в комментариях, в сообщениях для коммитов, в тикетах. А если хранить ее где-то еще, например, в wiki или в документах Word, то очень быстро происходит рассинхронизация между кодом и «текстовым описанием» проекта. Другая половина разработчиков резонно полагает, что все в код не запихнуть.

В идеальном мире, действительно, лучше всего хранить все рядом с кодом. Целее будет. Зато в реальном мире есть сроки. Часто создание правильного скрипта деплоя для continuous integration может занять несколько дней, тогда как «прокликать» несколько кнопок в админке чужого сервиса — пару минут. Если такая задача возникает раз в день, то резонно напрячься и все-таки соорудить скрипт. А если раз в год? Перфекционист, конечно, и для такого случая будет скрипт пилить. Но мы ведь не перфекционисты, нам нужно решать задачи, и желательно — оглядываясь на сроки.

Поэтому многие придерживаются «сбалансированного» подхода. При появлении новой информации ее сначала пытаются запихнуть в код. Если не получилось, то в комментарии к коммитам. Если и туда информация не влезает, то рассматривают вопрос о написании комментария в коде. И только если информацию нельзя поместить даже в комментарий к коду, она заносится в систему управления знаниями. В Google Docs, например. Удобно рассматривать систему управления знаниями как «крайнюю меру» по хранению информации, чтобы она не превратилась в «кладбище», в котором участники проекта закапывают информацию для собственного спокойствия, а не для пользы проекта.

И снова о Кошельке Миллера

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

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

С воображением тоже не все так просто

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

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

Чем пользоваться?

До недавнего времени в качестве программ для работы со знаниями использовали общие (mediawiki) или специализированные (confluence) wiki движки. Концепция «вики» дает дополнительные инструменты для организации иерархии знаний, а значит — борьбы с Кошельком Миллера. А еще там поиск удобный. И фильтры.

В последнее время набирают популярность markdown файлы в системах контроля версий, которые удобно просматривать и редактировать через web-интерфейс вроде github, gitlab или bitbucket. Несомненным плюсом такого решения является то, что знания лежат максимально близко к коду, идеально — в одном с ним проекте. И меняются вместе с кодом, что дает сквозной поиск по версиям и историю изменений.

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