Всем привет и добро пожаловать! Данная статья не является научной и не относится к разряду технических, она больше про коммуникации и командные процессы в IT. Это попытка систематизировать реальные практики по передаче контекста и знаний в IT команде, показать их актуальность и важность. Я уверен, что про что‑то из статьи вы уже слышали, видели, читали, или даже сами использовали. И для начала давайте определим основные понятия.
Контекст — совокупность различных факторов и/или сведений, необходимых для понимания или объяснения какого‑либо явления действительности.
Знание — проверенный практикой результат познания, то есть научные сведения, которые были проверены практикой и отражены в сознании человека.
В IT существует множество технологий, методологий, подходов, технических решений. Их комбинация определяет стек технологий компании, которых тоже оказывается множество. Найти специалиста с 100% совпадением по стеку технологий фактически очень сложно, да и знать всё на свете нереально. На самом деле это и не нужно, но статья немного про другое.
С контекстом, на мой взгляд, всё сложнее. Контекст — это не то, что вы можете изучить где‑то, прочитать статью, пройти курсы. Контекст плотно привязан к историческому наследию компанию. Это из разряда «так исторически сложилось». Я думаю, вам приходилось слышать эту фразу. Но даже в компании контекст от команды к команде может сильно отличаться, для каждой команды контекст тоже уникален.
Теперь представьте, у вас есть инфраструктура, проект, продукт, сервис, люди приходят и уходят, а вам нужно это сопровождать, чтобы всё работало стабильно, да ещё желательно, чтобы всё это не было завязано на одного человека. Именно поэтому важно делиться контекстом и знаниями в команде, а иногда даже и между командами.
Давайте попробуем подумать, какие практики нам могут помочь справиться с этим, организовать процесс, распределить нагрузку в команде, да и в целом облегчить жизнь команде.
Менторство
Это хорошая практика введения нового члена команды. Здесь есть положительные аспекты как для нового сотрудника, так и для самого ментора. Новому члену команды передаётся текущий контекст, например, какие проекты хранятся в каких репозиториях, или как деплоить новый сервис, а также исторический контекст, например, почему схема деплоя реализована именно так и как мы к ней пришли. На данном этапе ментор может поделиться какими‑нибудь знаниями, если не с глубоким погружением в предметную область, то по крайней мере на уровне сопровождения какого‑то технического решения. Но на данном этапе передача контекста имеет более приоритетное значение, чтобы новый сотрудник быстрее интегрировался в команду и её процессы.
Для ментора положительным аспектом является то, что у него появляется возможность взглянуть на всё с более широкого угла или даже с другой точки зрения, на процессы, на проекты. Это поможет освежить контекст, заполнить пробелы, провести ревью знаний, вспомнить, почему мы сделали именно так, и как мы к этому пришли. Как результат это может привести к активностям по модернизации, к роадмапам, к задачам.
Ментору на данном этапе важно признавать ошибки, не давить авторитетом, не бояться говорить «я не знаю». Всё это способствует погружению нового члена команды в контекст, процессы, проекты, позволяет ему не закрываться в себе, не бояться делать что‑то и совершать ошибки, не скрывать ошибки, проявлять инициативу.
На опыте оказалось сложно оценить, насколько эта практика эффективна и насколько высок процент полезного действия от неё. Потому что очень многое зависит от ментора, от новичка, от существующих процессов, от зоны ответственности команды и объёмов работ, от когнитивной нагрузки, да и от того, насколько человек готов погрузиться, разобраться, понять и выдать какое‑то решение. Но давайте попробую привести в пример два случая.
Случай без ментора. В компанию A в команду SRE вышел новый человек, был проведён онбординг, частично выданы права, проведено знакомство с командой, выбран начальный набор задач на испытательный срок. Были подобраны относительно не сложные задачи, из расчёта попробовать основной стек технологий, чтобы сформировать представление о новом члене команды, в том числе, для закрытия испытательного срока. Процесс организационно курировал лид команды. Человек приходил с конкретными вопросами, получал ответы, но ментор за ним не был закреплён. Всё проходило довольно спокойно, человек погружался в работу, после окончания испытательного срока были выданы расширенные права, как у всей команды. В итоге в рамках реализации очередной задачи по обновлению приложения были выполнены стандартные настройки, описанные в документации, но не учитывающие специфику реализации конкретно в компании A. В результате был поврежден один из серверов приложений. Конечно, данный случай очень сильно контрастирует, тем не менее он как раз наиболее показателен с точки зрения возможных проблем.
Случай с ментором. В компанию B в команду DevOps вышел новый человек, вводные процессы по своему составу не отличались от предыдущего случая без ментора, но за новым членом команды был закреплён ментор. Это позволило оперативно корректировать набор задач на период испытательного срока. Так как в процессе работы команды некоторые сервисы передавались на эксплуатацию в другие команды, некоторые, наоборот, приходили в команду, то удавалось оперативно убирать уже неактуальные задачи и добавлять более востребованные. Учитывая менее сильные технические знания в некоторых областях у нового члена команды, ментору удавалось делать корректировки плана на такие задачи. Передавая недостающие знания и контекст прокачивать менее сильные стороны. Было пару моментов, когда выстроенная доверительная коммуникация с ментором помогла не допустить повреждения инфраструктуры. Когда новый член команды просто пришёл и поинтересовался историческим контекстом процесса, и выяснилась одна особенность, сильно влияющая на процесс работы приложения. Конечно, в первом случае человек тоже мог прийти к команде и спросить. И выглядит так, что проблема не в процессах, а в человеке. Но спросить открыто у всей команды бывает сложнее, человеку может показаться, что задавать такие банальные вопросы глупо. Выстраивание процессов и использование озвученных практик как раз помогает решать такие проблемы, нивелировать человеческий фактор. И спросить ментора, один на один, с которым выстроены доверительные отношения, намного легче.
Мы рассмотрели процессы, связанные с введением нового сотрудника, но менторство может существовать и приносить свои плоды и в обычном жизненном цикле команды. Существуют практики, когда за более опытным членом команды закрепляются один или несколько коллег. На данном этапе менторства или для данного вида менторства больший приоритет приобретает передача знаний. Ментор может выступать и как центр экспертизы по каким‑либо направлениям. Он также может помочь составить карту развития. Такие активности желательно проводить по обоюдному согласию сторон. Иначе мы можем получить обратный эффект.
Карта развития
Составление карты развития может быть и самостоятельной активностью, когда человек осознаёт, куда он хочет двигаться, в каких направлениях развиваться, какие есть пробелы, что необходимо подтянуть, когда он сам для себя выстраивает процесс обучения, определяет цели, ставит сроки. Это реально, но бывает сложно в одиночку такое сформулировать. И это может быть не всегда объективно, оценивать себя со стороны — непростая задача. На начальном уровне обхват технологий может быть не большим, можно упустить, на какую технологию стоит обратить внимание, или что стоит учесть при изучении. Здесь на помощь может прийти более опытный коллега, дать профессиональную рекомендацию, показать сильные и слабые стороны, на что стоит обратить внимание. Это хорошо ложится в практику менторства.
Задачи
Задачи на самом деле являются конечной точкой, грубо говоря, результатом. Начнём с того, что команда должна привлекаться к написанию и обсуждению роадмапов, ведь именно команда обладает достаточным контекстом и знаниями, и именно она будет его реализовывать. Для управления роадмапом можно выделить отдельного человека, который будет лидировать данное направление. Хорошо, чтобы человек сам пришёл к этому, сам проявил инициативу, чтобы ему был интересен предмет. Управлять процессом он должен в контакте с командой, совместное обсуждение тут является важным аспектом вовлечённости всей команды в процесс.
Важно декомпозировать задачи, разбивать их на более мелкие логические части. Это позволит снять персональную нагрузку. Если один член команды берёт большую задачу с глубоким контекстом, погружается в неё на несколько недель или месяцев, то это может привести как к выгоранию, так и к потере командой крупной части контекста. Более мелкие декомпозированные задачи позволяют брать задачи из одного блока разным членам команды, погружаться в предметную область, приобретать знания и контекст по данной теме, быть в курсе происходящего.
На опыте встречал случаи, когда однотипные задачи поручались одному исполнителю. Объяснялось это просто, что у него уже есть опыт, и он сделает это быстрее. И это правда, но теряется весь смысл декомпозиции задач, команда в целом не приобретает новых знаний, не получает контекста. Ещё в качестве объяснений слышал такое: «Мы делаем (изменяем, обновляем) это только один раз, в будущем нам это не пригодится». Например, переход с версии 1.1.0 на версию 1.2.0 в рамках одной команды и в рамках одного сервиса может и делается один раз, но вот обновление сервиса — процесс неоднократно повторяющийся, а сколько таких сервисов в компании, а сколько команд, которые отвечают за разные сервисы и направления. Важно, чтобы такой опыт, знания и контекст были у нескольких членов команды. Не известно, кто через год пойдёт обновлять, например, этот же сервис, но уже на другую версию. Выстроить процесс вокруг такой активности полезно, но он в целом не заменит знания и контекст, и желательно, чтобы они не были сконцентрированы у одного человека.
Описание задач — важная составляющая. Описание задач по SMART'у (Specific (Конкретность), Measurable (Измеримость), Achievable (Достижимость), Realistic (Реалистичность), Time‑bound (Ограниченность по времени)) хорошая идея, но не всё так просто. На практике столкнулся с мнением, что не всегда имеет смысл описывать все детали, описание должно быть кратким, понятным, но не более того. Будет больше профита, в том числе для передачи контекста и знаний, если исполнитель сам обратится к заказчику уточнить детали. Устно можно передать больше деталей, предложить своё альтернативное решение, поделиться опытом, перенять контекст и знания от заказчика. Иногда так проще узнать и понять суть проблемы.
А вот что является действительно важным для задачи, на мой взгляд, так это definition of done (DoD). Это очень важный критерий, который позволяет определить конечную точку завершения задачи для любого её исполнителя, для каждого члена команды, для лида, для заказчика. Это позволяет команде синхронизировать понимание конечного результата, быть «на одной волне». DoD может в процессе или со временем измениться, и это нормально, это живой процесс. Но лучше, если DoD будет указан, чем его не будет совсем.
Парные задачи
Сложно сказать, что в разработке парное программирование или парные задачи являются частым явлением, но по крайней мере оно на слуху. В операционном блоке, например, у DevOps, SRE или системных администраторов это явление менее распространено, на своём опыте встречал его редко.
Парные задачи можно вводить для объёмных задач на исследование, включающих несколько объектов исследования. Коллеги смогут распараллелить активности, более детально погрузиться в тему, а результаты пошарить команде, дополняя друг друга. При этом у вас будет уже как минимум 2 человека, обладающих детальным контекстом и знаниями по теме, и не придётся тратить время всей команды.
Парные задачи могут быть эффективны, если в пару поставить более опытного коллегу. При чём не обязательно в широком смысле, он может обладать экспертизой в какой‑то конкретной области или технологии, которая нужна для данной задачи. В таком случае он может занять лидирующую позицию, обозначить общий план действий, консультировать напарника, погружать его в контекст или напрямую шарить знания.
На решение парных задач может уйти больше времени, но на выходе вы получите уже как минимум 2 человек, обладающих контекстом и знаниями, достаточными для сопровождения.
Груминг задач
Груминг — важная составляющая в процессах команды в целом, помогающая команде понимать, какие задачи она решает, что необходимо для их реализации. Вместе с этим всё это способствует передаче контекста, как исторического, так и текущего, а также члены команды приобретают новые знания в ходе обсуждения задач.
В процессе груминга происходит уточнение деталей, члены команды могут задавать вопросы, расширяя свой контекст, приобретая новые знания. Это способствует прозрачности и общему пониманию внутри команды.
Расстановка приоритетов по задачам способствует синхронизации виденья, команда в целом и каждый член команды в частности формируют представление, что сейчас важно для команды, для компании.
Как уже было озвучено, немаловажным является определение definition of done (DoD). Это важный момент, так как позволит команде одинаково оценивать задачу в дальнейшем, понимать, к чему данная задача приведёт, что мы получим на выходе.
В процессе обсуждения задачи формируются подзадачи или основные шаги по решению, что напрямую связано с передачей контекста и знаний. Например, чтобы поднять какой‑нибудь сервис, вам может потребоваться развернуть кластер и задеплоить в него сервис, или создать базу данных. Члены команды, имеющие в этом экспертизу и опыт, не раз сталкивающиеся с подобным, помогут сформулировать, что и в какой последовательности необходимо сделать, подскажут, например, как выбрать версию кластера, в каком регионе он должен быть размещён, какую базу данных выбрать, какие дополнительные настройки могут потребоваться. Всё это способствует приобретению новых знаний остальными и командой в целом, так как всё знать невозможно, но в целом команда может обладать экспертизой гораздо шире, чем один человек. При описании шагов и в ходе дискуссии, могут всплыть особенности. Например, при переключении трафика на новый сервис, нужно уведомить такие‑то команды и/или попросить их переключить трафик на новый сервис. Это позволит передать контекст по процессам, как внутри команды, так и во взаимодействии с другими командами в компании. В результате у команды сложится представление, какие команды отвечают за смежные сервисы, как строится взаимодействие команд, да и в принципе, от чего зависит сервис, или наоборот, какие сервисы зависят от данного.
Груминг позволяет декомпозировать сложные задачи, превращая их в набор более простых и типовых. Это позволяет не одному члену команды брать большую сложную задачу, создавая единственную точку компетенции и, как следствие, точку отказа, а планомерно распределять их по команде, давать каждому члену команды или хотя бы части поработать с этим, получить опыт, погрузиться в контекст, избежать завязывания экспертизы на одного. Это также способствует распределению нагрузки на команду, позволяет не зависеть от случаев, когда человек в отпуске, на больничном и т. п.
Оценка задач
Когда задачи прогрумлены, можно приступать к их оценке. Тут можно задать вопрос, а зачем вообще оценивать задачи, или как это связано с передачей контекста и знаниями. Оценка задач хоть и носит субъективный характер, но является количественным критерием оценки, которую разделяет команда. Она может выражаться как в абстрактных числах, так и в часах. И это уже понятное и измеряемое свойство, на основании которого можно планировать активности команды, сроки реализации.
Для передачи контекста и знаний важна не сама оценка как таковая, а процесс этому предшествующий. В процессе оценки задач желательно, чтобы все члены команды пришли к единой оценки, синхронизировали виденье происходящего. Каждый даёт оценку исходя из объёма работы, сложности, учитывая свой опыт, знание контекста, какую‑то долю неопределенности. Если у нас есть расхождение в оценке, мы пытаемся прийти к общему значению, происходит дискуссия, кто и почему поставил ту или иную оценку. Это иногда выявляет неочевидные вещи.
С простыми задачами всё, как правило, понятно, а вот в сложных задачах или задачах, которые выполняются не так часто, могут возникнуть вопросы. Как раз в ходе таких дискуссий члены команды делятся своим опытом, рассказывают про особенности, которые нужно учитывать. Это конечно тесно связано с грумингом, и вроде как шаги по решению задач или такие особенности мы должны отловить на том этапе, но вот понимание затрат на их решение может быть разным. Да и кто‑то из команды может знать, как легко это решить, поделиться знаниями, что повлияет на оценку задачи. Или поделиться контекстом, что, например, схожие работы уже выполнялись, и это может занять значительно больше времени и сил, чем мы планируем.
Шаринг результатов исследований
Ничто не стоит на месте, всё развивается, появляются новые технологии. Как результат, постоянно приходится изучать и приносить что‑то новое, обновлять текущее, это вечный процесс. Иногда задачи на ресерч выносятся отдельно, иногда они являются частью задач, относящихся, например, к конкретному сервису. Кидать всю команду на ресерч нового сервиса или технологии не целесообразно. Тем более, если учесть, что по результату ресерча может выясниться, что сервис или технология нам не подходят. Поэтому поручить ресерч можно одному члену команды, или сделать его парной задачей, если она достаточно объёмная и включает несколько объектов исследований.
Не стоит умалчивать про результаты исследований. Не важно, имели ли они положительный или отрицательный результат, команда должна обладать контекстом того, что происходит. Тем более, если им предстоит с этим работать. Результаты желательно зафиксировать в документации, отметить основные моменты, указать ссылки на официальную документацию, на примеры кода. Но также стоит рассказать команде, что это за сервис или технология, какие проблемы он решает, какие есть «подводные камни», плюсы и минусы, можно обсудить, решает ли он наши проблемы, сможем ли мы его внедрить, и дальнейший план действий. Команда получит дополнительный контекст и новые знания.
Ревью кода
Само по себе ревью кода является хорошей практикой. Иногда в CI/CD системах настраиваются правила для MR или PR, например, устанавливается минимальное количество человек, которые должны провести ревью кода и поставить апрув. Для нас важна не столько его ультимативность, как наличие договоренностей внутри команды по ревью кода. Можно даже без обязательного апрува, достаточно просто скинуть ссылку на MR или PR в чат команды.
Теперь про то, как это может быть нам полезно. Начнём с того, что взгляд со стороны может помочь увидеть тонкие места, коллеги по команде могут подсказать, как упростить какую‑то часть или куда стоит добавить проверку, и занести вместе с этим контекста и новых знаний по проблеме. Через ревью кода можно узнать, какие сервисы у нас есть и где лежит их конфигурация. Можно знакомить коллег с новыми фичами, которые приносятся в код, держать в курсе изменений.
Демо
Демо — это отличный способ, возможность и повод показать результаты, пускай даже и промежуточные, деятельности вашей команды, показать то, к чему вы пришли. Отрицательный опыт — тоже опыт, и об этом важно и нужно говорить. На демо можно поделиться своими знаниями и контекстом с другими командами. Можно показать, что есть такие‑то проблемы и есть такие‑то решения. Возможно ваши коллеги тоже сталкиваются с аналогичными проблемами и будут рады услышать решение. Демо способствует передаче контекста и знаний не только между командами, но и внутри команды. Тот, кто будет проводить демо от лица команды, всё равно будет готовиться к демо, собирать информацию у коллег, задавать им вопросы, погружаться в контекст, то есть так или иначе приобретать контекст и новые знания.
Дежурство, процесс передачи дежурства
Не во всех командах есть дежурства, но если они есть, то это отличная возможность пошарить знания и контекст внутри команды. Потому что во время дежурства тебе приходится решать абсолютные разные кейсы из разных областей, за которые отвечает команда. Дежурному в процессе обработки обращений и решения инцидентов приходится погружаться в предметную область, погружаться в детали. Если дежурный не знает что‑то, то он приходит с вопросами к команде и восполняет пробелы, приобретает новые знания и контекст по конкретному кейсу, и, как результат, приобретает ещё и навык, так как ему приходится решать проблему. Кроме того, дежурный получает дополнительный контекст из вне, от инициатора, от того, кто пришел с вопросом или проблемой. Его знания о системе, инфраструктуре, процессах расширяются, он получает возможность взглянуть на всё со стороны пользователей. Кроме этого, он получает опыт о реальном состоянии дел, реальных проблемах и может повлиять на их решение в ходе плановой деятельности команды.
Существует ещё одна хорошая практика, связанная с дежурством, которая завершает этот процесс — это передача дежурства. На мой взгляд, это правило хорошего тона и уважение коллег. Не все кейсы, алерты, инциденты заканчиваются на момент завершения дежурства, и чтобы не скидывать в тихую всё это на следующего дежурного, можно его уведомить, подготовить к возможным проблемам, передать ему текущий контекст. Это снимет частично с него нагрузку и уменьшит стресс, он уже будет готов к этому, у него будет контекст по кейсу, время погружения сократится, а скорость реакции увеличится. Например, ночью сработали такие‑то алерты, они связаны с тем‑то и тем‑то, их должны пофиксить тогда‑то, если они повторятся, нужно сделать то‑то и то‑то.
Из опыта в команде SRE до введения передачи дежурства была ситуация, что тратилось много времени на погружение в контекст или проблему при смене дежурного, возрастала когнитивная нагрузка, каждый придумывал свой способ решения проблемы, каждый применял свои утилиты для сбора данных и аналитики. В итоге всё равно члены команды отвлекались и переключались на проблемы, возникающие в рамках дежурства.
После введения практики передачи дежурства, каждый член команды, завершая дежурство, передавал список активностей с комментариями и то, что он посчитал важным озвучить, что по его усмотрению может помочь следующему дежурному. Это сделало процесс более прозрачным, помогло выявить повторяющиеся проблемы, оптимизировать мониторинг. Особенно хорошо это помогло с проблемами, которые переходили между сменами. Заступающий на дежурство получал контекст по существующей проблеме, у него были исторические данные, информация, на каких дашбордах можно увидеть текущее состояние, в каких логах можно найти ошибки, является ли это временной проблемой или готовится хотфикс, как можно снизить риски и влияние, даже какой сервис нужно перезагрузить при необходимости. То есть на момент входа у него уже были представление о текущем состоянии и контекст. Данная практика хорошо себя проявила при DDoS‑атаках, при обработке большого количества входящих запросов в течении длительного времени, при запуске продолжительных миграций и индексаций. То есть там, где процесс выходил за временные рамки одной смены дежурства.
Периодическая смена ролей в команде
В жизни команды формируются какие‑то процессы, иногда эти процессы приходят из вне. Это могут быть демо, планирование, груминг, ретро, дейли (он же стендап) и прочее. Неправильно если за все эти процессы отвечает один человек, например, лид. Это грубое завязывание контекста на одного человека и ставит всю команду в зависимость от факторов, на которые мы не всегда можем повлиять и как‑то их митигировать. Желательно, чтобы эти процессы и активности были распределены по членам команды. Но даже и это может привести со временем к завязыванию контекста, пускай и немного распределенному. Да и люди, ответственные за процессы, могут устать или выгореть. Поэтому важно периодически ротировать роли внутри команды. Это снимет персональную нагрузку и распределит её по команде, поможет пошарить контекст, с приходом новых людей принесёт новые идеи и подходы. Конечно хорошо, чтобы человек к этому пришёл сам, сам проявил инициативу, чтобы ему был интересен предмет, было желание попробовать что‑то новое.
Документация
Документация является не маловажным компонентом передачи знаний. Конечно лучше иметь документацию, чем совсем ни чего не фиксировать. При это документация не обязательно должна быть исчерпывающей или соответствовать каким‑то требованиям или стандартам. Мы сейчас говорим не про официальную документацию, которую пишут технические писатели в соответствии с требования и стандартами. Это больше про документацию внутри команды или внутри компании, которая описывает внутренние процессы, пошаговые инструкции, используется для внутреннего пользования.
Документация хороша тем, что каждый сам может освежить у себя знания с помощью неё. Особенно это помогает в кейсах, когда приходится сталкиваться с этим не каждый день. Или документацию можно предложить как закрепляющий материал для нового члена команды, когда он приступает к выполнению какой‑то задачи, и уже был введен в курс дела.
Но документацию не стоит возводить в абсолют, её наличие — это преимущество, но на сколько она должна быть подробной — ваше решение. Если вы копируете или пересказываете в документации какие‑то части из общедоступных источников, например, из документации облачного провайдера или какого‑то сервиса, имейте в виду, что всё очень быстро развивается и меняется, и возможно на следующий день это станет уже не актуальным и введет в заблуждение того, кто будет использовать её в работе.
Документацию можно использовать для передачи контекста, конечно не для всего содержания, но вот зафиксировать какие‑то договоренности, принятые внутри команды, всё‑таки стоит. Документация не может дать тебе полноценный ответ на то, почему было принято то или иное решение, передать тебе полноценный исторический контекст. Написать конечно можно, но на сколько это реально эффективно — большой вопрос. Для передачи контекста всё же есть более эффективные практики, которые мы перечислили выше.
Как вы уже наверное заметили, многое из перечисленного есть или пришло из методологии Scrum. У вас может быть разное отношение к Scrum или Agile в целом, но это не делает перечисленные практики менее эффективными. Некоторые из перечисленных практик связаны друг с другом, например, без груминга будет очень сложно реализовать оценку задач. Но по большей части все они могут существовать независимо, может не так эффективно, но тем не менее. Поэтому и внедрять их можно постепенно, что‑то корректируя под особенности своей команды, что‑то убирая, что‑то добавляя.
Уверен, что это не финальный список, но мы попытались рассмотреть основные практики. Все их приходилось либо лично применять на практике, либо участвовать, либо наблюдать.
Важно понимать, что всё вышеперечисленное не «серебряная пуля», не универсальное решение всех ваших проблем. Кроме того, на начальных этапах у вашей команды будет просадка по производительности. Выстраивание процессов трудоёмко и затратно, это в целом сложный процесс, многое зависит от человеческого фактора. Но опыт показывает, что всё это реальные и действенные практики, которые помогают решать проблему передачи контекста и знаний внутри команды, а иногда и в компании.
