크게 상처받지 않도록 회사에서 지식 교환을 구축하는 방법

일반 IT 회사에는 요구 사항, 작업 추적기 내역, 소스(코드에 주석 포함), 생산 시 일반적이고 중요하고 복잡한 사례에 대한 지침, 비즈니스 프로세스 설명(온보딩부터 휴가 가는 방법까지)이 있습니다. ”) , 연락처, 액세스 키, 사람 및 프로젝트 목록, 책임 영역 설명 등 우리가 잊어버렸을 수도 있고 가장 놀라운 장소에 저장할 수 있는 기타 지식도 있습니다.

지식 =/= 문서화. 이건 설명할 수 없어 기억해야 해

이것으로부터 무언가를 알아야 하는 사람들이 그것을 어디서, 어떻게 찾을 수 있는지 이해하고, 개별 사항과 합의를 알아야 하는 모든 사람들이 그 변화를 즉각적이고 정확하게 알 수 있도록 하는 방법입니다.

"Team Lead Will Call" 팟캐스트의 마지막 에피소드에서 Skyeng 직원들은 Igor와 함께 지식 관리에 대해 이야기했습니다. 메이캣 Tsupko는 KnowledgeConf 프로그램 위원회의 회원이자 Flant의 "미지의 감독"입니다.

전체 녹음은 다음과 같이 제공됩니다. 유튜브 영상, 아래에는 오디오에서 언급되었거나 오디오 정보를 확장한 유용한 자료에 대한 몇 가지 흥미로운 팁과 링크가 수집되어 있습니다. 댓글로 여러분의 팀의 꿀팁을 공유해 주시면 좋을 것 같습니다.

첫 번째 해킹: 더 이상 어떤 시스템을 살펴봐야 할지 알 필요가 없습니다.

“저는 지식 소스를 가져와 일반적인 검색을 했습니다. 검색 영역을 줄이기 위한 필터링 시스템이 있는 단일 창이었습니다. 예, 동시에 품질을 모니터링하고 지식 기반을 보충하며 중복 및 잘못된 정보에 맞서 싸워야 합니다.

종이 한 장으로 그걸 찾을 수 있어

그러나 이미 Flant 엔지니어의 약 60%가 이 검색을 하루에 최소 1~2회 사용하며 일반적으로 첫 번째 또는 두 번째 위치에서 답변을 찾습니다. 그리고 개념 증명의 형태로 Google 문서(모든 dox, 폴더, 밴 드라이브 등)의 색인이 생성됩니다. 이 모든 것이 내부 검색에도 쉽게 적용됩니다."

두 번째 꿀팁: 수많은 채팅에서 매우 중요한 것들을 놓치지 않는 방법

“분산된 팀에서 일한다면 아마도 하루 중 상당 부분을 Slack에서 보낼 것입니다. 이 경우 다음과 같은 작업에 익숙할 것입니다. “@myteam, 도움말/보기/올바른 항목 입력... "." 하지만 정보가 너무 많아서 다른 메시지들 사이에서 별도의 언급이 누락될 수 있다는 문제가 있습니다.

Skyeng에서는 메시지를 작성하고 원하는 수의 사람이나 그룹에 태그를 지정할 수 있는 봇의 도움을 받습니다. 우리는 사람들이 읽거나 반응하는 것이 정말 중요한 경우에 이 기능을 사용합니다. "읽었습니다" 버튼을 누를 때까지 끝없이 찌르게 됩니다. 건너뛰거나 무시할 수 없습니다."

대답할 질문: 문서로 무엇을 해야 합니까?

“많은 지식은 기술 전문가에게서 나오지만 모든 사람이 이를 잘 설명하는 방법을 아는 것은 아닙니다.
결국, 당신은 당신이 제대로 하고 있는지 아닌지를 알려주는 컴파일러나 린터가 없으며, 종종 우리가 얻는 출력은 이해할 수 없고, 형식이 잘못되고, 불완전한 텍스트입니다. 물론, 누군가가 와서 "필요하다"고 말했기 때문에가 아니라 정상적으로 수행해야합니다. 스스로 잘 수행합니다. 한두 달 안에 읽고 이해하게 될 것입니다. 그리고 문서를 여는 다른 사람은 문서가 쓸모 없다는 것을 깨닫고 즉시 영원히 닫지 않을 것입니다.

"좋은 문서를 작성하거나 일반적인 데모를 만들려면 몇 명의 사람이 필요합니까?"라는 질문에 대한 팟캐스트의 일부

그러나 문제는 남아 있습니다. 이를 위해 얼마나 많은 시간을 할당하고 어떻게 효율적으로 수행할 수 있습니까?
그리고 여기에 정직한 대답이 있다면, 비즈니스 담당자가 참여하지 않고 좋은 문서화의 영향을 경험적으로 경험하지 않는 한 노력해도 성과가 거의 없을 위험이 있습니다. 이것은 문화 변화에 관한 이야기에 가깝습니다.

나머지는 경험과 멘토링이 당신을 구할 것입니다. 페어 프로그래밍, 진행 상황 추적 및 코드 검토와 유사한 것이 여기에 적합할 수 있습니다. 모범 사례를 보여주고, 오류를 찌르고 결국 지루해집니다.”

보너스: "좋아요. 이렇게 말하면 이해해줄 거예요."

"이 작업에 소요되는 시간과 수행 수준은 어느 정도인가"라는 질문은 문서화 프레임워크 내에서뿐만 아니라 일반적으로 지식 전달에도 중요합니다. 데모는 정보 공유의 좋은 예이기도 합니다. 그러나 뉘앙스가 있습니다. 예를 들어 최소한의 시간이 소요되는지 확인하는 방법입니다.

개발 간 지식 공유 채널: 내부 보고서, 유용한 서적, 기사 등 구조화된 추출은 Notion에도 저장됩니다.

부분적으로 이러한 문제는 내부 보고를 통해 해결될 수 있습니다. 일주일에 한 번, 덜 바쁜 시간에 40~60분 정도 시간을 내어 서로 다른 프로젝트의 동료들을 위해 비디오 보고서를 만듭니다. 핵심제품 프론트엔드팀 - Vimbox - 말한 다른 프로젝트에 테마를 적용할 수 있는 UI 키트에 대해 알아보세요. 마케팅 개발 팀은 요청을 추적하고 기록하는 라이브러리에 대해 이야기했는데, 이는 즉시 다른 여러 프로젝트의 관심을 끌었습니다. 수학 프로젝트 팀은 REST API에서 GraphQL로 전환한 경험을 공유했습니다. 그룹 레슨 팀은 어떻게 처음으로 PHP 7.4로 전환했는지 공유하려고 합니다. 등등.

이 목록은 2018년 120월부터 유지되었으며 XNUMX개 이상의 항목이 있습니다.

모든 회의는 기업 Google Meet을 통해 시작되고 녹화되어 1.5시간 이내에 공유 Google 드라이브의 폴더에 표시되며 녹화 링크는 동일한 Slack에 복제됩니다. 즉, 긴급 상황이 발생하면 올 필요가 없지만 나중에 20배속으로 시청하세요. 일반적으로 보고서 자체는 최대 XNUMX분 동안 지속되고 토론은 어떻게 진행되는지 살펴보세요. 하지만 우리는 그 시간을 넘기지 않습니다)

PS 당신에게 효과가 있었던 것과 효과가 없었던 것은 무엇입니까?

유용한 링크 :

• Kaspersky Lab의 Rodion Nagornov 지식경영이란 무엇인가 그리고 이것이 문서가 아닌 이유(링크에 대한 Igor의 채널 덕분에) “아늑한 IT 지옥”, 그런 것이 더 많이 있습니다).

• 그것에 대해 Flant의 Igor Tsupko 지식 관리를 구현하는 방법 내 회사에서

• Skyeng의 Alexey Kataev 베이스 팩터를 모니터링하고 레벨링하는 방법에 대해 (기술 및 특정 영역의 지식 격차) 분산된 팀.

• 정보 전달에 관한 Flant의 Sergey Goncharuk- 언제, 누구에게 물어봐야 하는지 아는 방법, 분산된 팀에서 문제가 발생하는 경우.

출처 : habr.com