Управлять знаниями = Идентифицировать артефакты знания - логировать критические знания и навыки, фасилитировать обмен и находить узкие места
- Risk-management
- Онбординг новичков и ротация
- Профессиональный рост внутри команды, компании
- Формирование культуры - прозрачность
-
Знания делятся на непосредственно знания об устройстве фичи, сервиса, на знания о процессах и принятых паттернах и знания о бизнесе
-
Если что-то не в релизном процессе - оно умирает. Решение: Включить знания, например, в виде диаграмм последовательности о работе логики, описаний конфигов в релизный пайплайн.
- Договоримся понимать DevOps не как набор инструментов, а как методологию и культуру взаимодействия в компании: отказ от жесткого разграничения ролей, право на эксперименты, быстрая доставка изменений
-
Часто существует разрыв между знаниями в коде, настройкой конфигураций в команде доставки и базой знаний компании. Его нужно устранить. Хранить файлы с описанием работы фичи, файлы конфигураций, например, puppet, в репозиториях, пушить в базу знаний.
-
Чаще всего работают по принципу share tools not knowledge
-
Управление знаниями, документирование при срочных релизах часто уходит в техдолг как и тесты
-
Идентифицировать = вести логи применяемых знаний
-
Распределить роли и встроить в процесс (автоматизация)
-
Поощрять и создавать культуру обмена
-
P.S. Его можно поворачивать и применять к разным кейсам.
- Экстремальные коммуникации - когда разработчикам запрещено общаться лично или в чатах по задачам, вся комммуникация через баг-трекер, еще один виток этого подхода - общение через документацию, которая располагается в папке с фичей или модулем
- DDD - Domain Driven Development, представитель бизнеса, аналитик объясняет разработчику бизнес-задачу, что делает каждая форма, поле клиенту, затем разработчик это фиксирует в виде описания, некой рамки, система проектируется, и уже по этой рамке пишет код
- Стимулирование и поощрение шэринга и изучения новых технологий, кто-то из разработчиков улучшил перфоманс в проекте или отдельном компоненте на н миллисекунд и рассказывает об этом на пятничном KSS (Knowledge Sharing Session) или митапе. Внедрять или нет эту оптимизацию уже на совести проектных команд, как продать клиенту
- А если навязывание нового похода, который принес профит? Способы: провести KSS, разослать письма счастья, обновить гайдлайны
- Расследование инцидентов, постмортемы (вскрытия) по итогам инцидентов в публичной очереди в JIRA, вести базу инцидентов, по итогам инцидента меняется сеттинг метрик и алертов в других проектах, наиболее критичные/дорогие для бизнеса - обсуждаются опять же на пятничном митапе, KSS. Можно включить в процесс ретроспективы на спринте.
- Консистентность наименований начиная от элементов UI, через функции и классы в коде, до названия настроек в конфиге и коммуникации в бизнес
- Адаптационный план для новичка, больше практики, плейграунд проекты, обязательно назначить тьютора, снизить перегрузку информацией
- Поощрять передачу знаний, освоение новых технологий - прям в KPI вбейте
- Star Map - список, таблица скиллов, необходимых команде/позиции
- Ньюслеттеры, ревью и обзоры достижений между командами и со стороны менеджмента, бизнеса, между UI и бэкэнд, между опсами и разработчиками, быть на одной волне
- Сколько это (обновление артефакта знания) может и должно отнимать в разрезе общего времени затраченного на задачу? 10 процентов времени - нормально, но это сокращает время оценки, декомпозиции, расследования и в перспективе - time to market
- Как мерять покрытие? Проверять при сборке наличие файлов описаний и их обновление
- Продуктовая разработка, продукт из 60 отдельных компонентов, как разработчикам не делать двойную работу как узнать что есть похожий компонент. Например, лекции КСС между командами отдельных компонентов о последних самых интересных фичах, также можно делать граф, ментальную карту продукта с описанием фич
- Микросервисы - знания по каждому сервису в головах отдельных разработчиков и полная специализация,распределенное хранение или же наоборот генерализация, частая ротация между сервисами. Поощрение культуры обмена - парное программирование, выстроенная система ревью между сервисами с фиксацией результатов. Deep dive с экспертами.
- История успеха: описал от и до как работает биллинг с диаграммами последовательности, хранится в репозитории с этой фичой, с тех пор она не ломалась
- А может наоборот лучше максимально специализировать и брать человека на одну небольшую функцию, например, писать SQL запросы? Знания о полном устройстве системы, продукта тогда можно не давать ему? Будет ли это работать?
- Self-documented code - все знания - в коде, в комментариях. Как мотивировать обновлять? документирование в коде входит в definition of done фичи. Можно хранить не в комментариях, а рядом в виде файлов, например MD. в peer-review один из критериев - обновлен ли файл с описанием, это можно автоматизировать и проверять при коммите или деплое, билд сломается
- Больше - не значит лучше
- Бутылочное горлышко само устройство CI/CD, если его настраивают 1-2 человека
- Это всегда технический долг
- Соревнование между разработкой и инфрой
- Лучше никакой документации, чем устаревшая
Ссылка на канал в телеграме https://t.me/the_know_all Ссылка на слайды https://drive.google.com/file/d/11cTdrrEQKgshfbncKvPP3PgCqOnhl7qJ/view?usp=sharing