Use Knowledge Management to Create Release Notes Templates and Streamline Your Product Delivery Process

훌륭한 출시 노트를 작성하는 비결, 템플릿에 포함해야 할 사항, 그리고 지식을 사용하여 제품 제공 프로세스를 간소화하는 방법을 배우십시오.
Table of Contents

사실: 제품 출시 소통이 문제가 된다

제품 출시 노트의 목적은 내부 팀(엔지니어링에서 고객 지원까지)과 외부 이해 관계자(고객 및 파트너)에게 제품에 변경 사항이 있음을 알리는 것입니다. 기술 분야에서는 모든 것이 빛의 속도로 움직이며, 제품 업데이트를 출시 노트를 통해 전달하는 것은 사실상 오래된 문제입니다.

내가 근무했던 모든 회사들은 출시 노트를 "올바르게" 작성하는 데 어려움을 겪었습니다. 그러나 이것을 올바르게 작성하는 것은 어려운 일입니다. 모든 변경이나 제품 출시의 중요성은 청중, 변경 사항이 특정 그룹의 기능과의 상호 작용을 어떻게 변화시키는지, 그리고 그 그룹이 매일 전반적인 제품을 어떻게 사용하는지에 따라 달라집니다.

이러한 제품 출시 소통(일반적으로 출시 노트로 알려짐)은 서로 다른 것에 관심이 있는 청중에게 전달되어야 합니다. 내가 Guru에서 수익 강화 리더인 경우, 내 이해 관계자는 제품 로드맵에 의해 직무 수행 능력에 영향을 받는 사람들입니다.

  • 제품/디자인/엔지니어링 팀
  • 영업 팀(영업 운영, 내부 영업, 부문별 계정 임원)
  • 고객 경험(성공 관리자 및 지원 담당자)
  • 마케팅 팀(제품 마케팅, 성장 마케팅, 브랜드, 콘텐츠, GTM 전략 및 보도 자료를 이끌 팀)
  • 비즈니스 개발 및 파트너

이 모든 파트너들은 제품 업데이트를 소화하고 이를 직무에 얼마나 적용해야 하는지 즉시 파악해야 합니다. 그들은 또한 최종 사용자가 어떤 변화가 그들에게 미치는지를 이해하도록 도울 수 있는 방법을 고려해야 합니다.

출시 소통을 작성하는 사람(또는 팀)은 제품 지식을 소비하게 될 모든 청중을 고려해야 합니다. 출시가 백엔드 엔지니어와 소매 산업의 잠재 고객에게 미치는 영향은 무엇입니까?

who-are-release-notes-for.png

출시 노트를 작성하는 방법

여러 청중의 필요를 고려하는 것이 어렵지만, 제품 관리자 또는 제품 마케팅 관리자(PMM)가 다섯 개의 서로 다른 버전의 내부 출시 노트를 작성하는 것은 스케일 할 수 없습니다. 내 경험에 따르면, 출시 노트는 너무 길고 맥락이 없거나 기술력이 부족합니다. 정적 출시 노트는 이러한 통찰력을 제공하지 않으며 종종 작성자를 위해 작성되므로 변경 사항을 이해해야 하는 사람을 고려하지 않습니다. 솔직히 말해, 그들은 대개 놓치는 기회입니다.  

how-not-to-write-release-notes.png

나는 제품 관리로부터 단조로운 목소리가 슬라이드에 대한 요점을 통과시키는 매주 한 시간짜리 출시 노트 호출을 앉아 있었습니다. 설명이 끝난 후, 같은 제품 관리자는 이메일, 전화(그것 기억하시나요?), 슬랙 등으로 고객 지원 팀에서 영업 팀까지 모든 사람에게 변화를 그들에게, 그들의 고객 및 잠재 고객에게 의미하는 것을 알리기 위해 연락을 받습니다. 당신이 통화를 놓쳤다면, 당신은 뉘앙스와 맥락을 놓쳤고 대신 원시 변경 로그만 받았습니다.

그러나 제품 관리자의 역할은 이러한 신성한 번역을 하는 것이 없으며, 그들의 역할은 시장을 위한 문제를 해결하는 제품을 만드는 것입니다. PMM의 역할은 그것의 의도를 번역하여 시장이 가치를 이해하도록 하는 것입니다.

우수한 소프트웨어 출시 노트를 작성하는 비결

나는 사운드 오브 뮤직 팬입니다(충격적이죠, 나는 알고 있습니다) 그리고 가능한 전문가로서 영화의 영원한 교훈이 진정합니다. "우리는 맨 처음부터 시작하자/정말 좋은 출발 장소다"가 매주 내 머리를 지나갑니다. 그러므로, 제품 전달 프로세스를 형성하거나 재형성하는 과정에서, 당신은 주제를 가르치기 전에 언어를 배워야 합니다.

1. 내부 용어집 개발

이 프로세스를 파악하는 첫 번째 단계는 모든 팀이 같은 언어를 사용하게 하는 것입니다. 공유된 용어를 소통하는 것은 분명한 것처럼 보이지만, 이는 조직 전체에서 발생하고 있지 않을 수 있습니다. 약어를 모르고 언어를 오해하는 것은 고립감을 느끼게 하며, 팀 간에 혼란과 단절을 초래할 수 있습니다.

예시: 우리 마케팅 팀은 기능으로 시장에 나갈 때 사용할 용어인 "출시"를 사용합니다. 그러나 엔지니어링 팀은 기능이 스테이징 환경에 출시되었을 때를 설명하기 위해 "출시"라는 단어를 사용합니다. 기능의 특정 출시가 고객이 이에 대해 알기 전에 엔지니어링에게는 "완료"된 상태입니다. 이것은 혼란스럽고 내부적으로 상충되는 상황이었습니다.

아무도 정의를 요청함으로써 무언가가 무엇을 의미하는지 공개적으로 말하는 사람 되기를 원하지 않습니다. 우리의 해결책: 우리는 크로스 기능 작업 그룹(엔지니어링, 제품, 제품 마케팅의 대표자의)에서 뉘앙스를 명확히 하고 제품 출시 정의를 문서화했습니다.

참고: 카드가 로드되지 않으면 페이지를 새로 고치는 것이 좋습니다!

2. 출시 노트에 포함해야 할 항목

공유된 언어가 확립되고 팀이 출시 용어를 설명할 수 있게 된 후, 노트를 작성할 수 있습니다. 가장 쉽고 빠른 방법은 출시 노트를 작성하기 위한 재사용 가능한 템플릿을 만드는 것입니다. 이런 식으로 이해관계자들이 몇 번의 반복 후 형식에 익숙해지고, 매번 처음부터 다시 만들 필요가 없어집니다.

최소한 좋은 출시 노트에는 다음과 같은 내용이 포함됩니다:

  • 출시 날짜
  • 내부 및 외부
  • 기능 또는 버그에 대한 설명
  • 영향을 받는 제품(여러 개 있을 경우)
  • 여러 소프트웨어 제품이 있는 경우, 버전 번호도 포함하는 것이 좋습니다.
  • 내부에서 질문할 수 있는 위치

그렇지만 훌륭한 출시 노트에는 또한 다음이 포함됩니다:

  • 예상되는 자주 묻는 질문(FAQ)
  • 새로운 공개 문서에 대한 링크, 사용 가능할 경우
  • 기능에 대해서:
  • 기능의 이름
  • 기능이 어떻게 구현되었는지 스크린샷
  • 기능을 시연하는 방법에 대한 비디오
  • 기능이 존재하는 이유
  • 해당 구매자/고객 페르소나에 미치는 영향

여기 템플릿을 내부적으로 사용합니다(복사하셔도 됩니다!):

💡참고: 이 작업을 위해 직접 책임 있는 개인을 지정하는 것이 유용합니다(공동 작업으로 두지 말고 누군가가 소유하도록 하세요). 엔지니어링 또는 제품 관리자는 노트의 기술적인 부분(이름/버전/제품/날짜/스크린샷)을 소유해야 하며, 제품 마케팅 관리자는 컨텍스트 정보(구매자 페르소나/왜 중요한지를) 소유해야 합니다.

제품 전달 프로세스 전략 구현

일관된 커뮤니케이션 형식 생성

용어를 통합하고 템플릿을 작성한 후에, 다음 단계는 일관된 전달 매체(예: 슬랙, 이메일, 룸, Guru, 구글 문서)와 방법론에 대해 동의하는 것입니다. 일관된 전달 매체는 당신의 출시 노트 이해 관계자들이 어디로 가야 하거나 뭘 살펴봐야 하는지, 또는 구독해야 하는지를 아는 것을 보장합니다.

이것은 또한 변경 관리에 필수적입니다. 왜냐하면 일반적으로 누군가에게 무언가를 완전히 흡수할 수 있도록 여러 번 말해야 하기 때문입니다. 출시 유형, UI/UX(사용자 인터페이스 및 사용자 경험)의 변경 사항에 따라 고객에게 미치는 영향이 다르며, 출시 노트 청중은 제품 지식을 전달받아야 합니다 (전달해야 합니다). Guru에서는 푸시 및 풀 방법을 모두 사용합니다.

풀: 지식을 찾을 수 있는 방법

우리의 경우, 이해관계자들은 슬랙 #release-notes 채널을 팔로우하며, 버그 수정부터 새로운 기능까지에 대한 일관되고 소화 가능한 형식을 유지합니다. 각각의 청중은 출시가 진행되고 있다는 것(슬랙이나 이메일의 풀을 통해) 만 아는 것이 아니라, 그들이 출시가 맥락에서 왜 중요한지 알아야 합니다.

implementing-product-delivery-process-strategy.png

출시가 단순히 이루어질 것이고 이미 발생했음을 아는 것은 가치가 없습니다. 당신의 팀이 실제로 그것을 가지고 행동할 수 없다면 말이죠. 일관된 형식을 개발하기 위해 적절한 맥락을 제공할 수 있도록, 나는 영업 담당자, 계정 개발 담당자, 비즈니스 개발 인사들(모두)에게 설문조사를 수행하여 "기능 분해 카드"라고 부르는 제품 전달 템플릿을 수립했습니다.

엔지니어링 관리자가 새로운 기능 개발을 시작할 때, 직접 책임이 있는 개인들은 Asana를 통해 기능별 기능 분해 카드를 생성하라는 알림을 받습니다. 새로운 기능 분해 카드는 우리가 출시하는 "기능의 두뇌"로, 견고한 단일 정보 출처입니다. 주제 전문가(SME) — PMM 및 영업 엔지니어와 같은 — 는 출시가 왜 가치가 있는지, 누구에게 가장 중요한지를 설명하고, 필요한 경우, 더 큰 스토리에 기능을 어떻게 시연해야 하는지를 안내합니다.

출시 노트 이해 관계자, 특히 계정 임원들은 기능 분해 카드를 반복적으로 참조합니다. 왜냐하면 그들은 이 카드에서 동적 지식이 신뢰할 수 있고, 관련성이 있으며, 적용 가능한 것을 배웠기 때문입니다. 이제 청중들은 같은 언어를 사용하고 동일한(동적) 플레이북을 읽고 있습니다. 기능 분해 카드에 대한 반응은 여전히 "풀" 방법의 일환입니다. 왜냐하면 이는 자율적이며, 영업 또는 지원 통화를 준비하거나, 잠재 고객이 로드맵에 대해 질문할 경우에 해당됩니다.

푸시: 능동적으로 지식을 제공하기

푸시 방법은 출시 정보가 시기적절하며 특정 팀에 중요할 때 사용됩니다. 여기에서, 이는 Guru의 공지 사항 기능을 통해 수행됩니다. 내 내부 청중에게 미치는 영향을 기반으로, 나는 공지 사항을 푸시합니다. 이를 위해 관련 그룹에 전달합니다. 그 후, 나는 알림을 확인한 사람들에 대한 보고서를 볼 수 있으며, 이를 잊은 사람들에게 공개적으로 검토(사기)하고 상기시킵니다.  

왜 지식 기반 문화가 핵심인가 🗝

knowledge-driven-culture-is-key.png

앞서 말한 모든 것에도 불구하고, 실제로는 용어에 동의하고, 뛰어난 출시 노트를 작성하고, 동적 제품 전달을 위한 메커니즘을 생성하는 것만큼 간단하지 않습니다. 팀은 지식을 협력하고 지속적으로 피드백을 제공할 수 있어야 합니다. 지식 공유를 통해 피드백을 제공하고 개선하는 것은 팀의 모든 구성원의 역할과 책임입니다.

우리에게는 이 말이 의미합니다. 지식 소비자(이 경우 출시 노트 이해관계자)가 질문이 있거나 새로운 것을 알게 되면 기능 분해 카드에 댓글을 답니다. 우리는 또한 슬랙에서 묻고 대답하는 질문을 기능 분해 카드에 댓글을 다는 방식으로 지속적으로 지식을 개선합니다. 주제 전문가(일반적으로 PMM)는 새로운 지식이나 관련 질문을 검토하고 통합하여 해당 기능 분해 카드에서 맥락에 맞게 그것을 정리합니다.

우리는 모든 출시 노트를 쉽게 접근 가능하게 만들며, 이를 기능 분해 보드의 향후 또는 출시된 섹션에 넣어 더욱 내부적으로 조직할 수 있습니다. 그렇게 하면 쉽게 한눈에 보기 좋습니다. 당신이 Guru를 사용하지 않는다면, 출시 노트 페이지를 만들거나 연결된 변경 로그를 만드는 것이 좋습니다.

다른 모든 프로세스와 마찬가지로, 이 프로세스 또한 지속적으로 진화합니다. 제품 전달 및 출시 노트는 결코 한 번에 끝나는 것이 아닙니다. 비즈니스의 요구가 변화함에 따라, 프로세스, 책임 및 템플릿도 그에 맞게 변화해야 합니다. 그러나 이해력, 맥락 및 사용성을 쉽게 만들려고 노력하면, 절대적으로 손해 볼 일이 없습니다.

사실: 제품 출시 소통이 문제가 된다

제품 출시 노트의 목적은 내부 팀(엔지니어링에서 고객 지원까지)과 외부 이해 관계자(고객 및 파트너)에게 제품에 변경 사항이 있음을 알리는 것입니다. 기술 분야에서는 모든 것이 빛의 속도로 움직이며, 제품 업데이트를 출시 노트를 통해 전달하는 것은 사실상 오래된 문제입니다.

내가 근무했던 모든 회사들은 출시 노트를 "올바르게" 작성하는 데 어려움을 겪었습니다. 그러나 이것을 올바르게 작성하는 것은 어려운 일입니다. 모든 변경이나 제품 출시의 중요성은 청중, 변경 사항이 특정 그룹의 기능과의 상호 작용을 어떻게 변화시키는지, 그리고 그 그룹이 매일 전반적인 제품을 어떻게 사용하는지에 따라 달라집니다.

이러한 제품 출시 소통(일반적으로 출시 노트로 알려짐)은 서로 다른 것에 관심이 있는 청중에게 전달되어야 합니다. 내가 Guru에서 수익 강화 리더인 경우, 내 이해 관계자는 제품 로드맵에 의해 직무 수행 능력에 영향을 받는 사람들입니다.

  • 제품/디자인/엔지니어링 팀
  • 영업 팀(영업 운영, 내부 영업, 부문별 계정 임원)
  • 고객 경험(성공 관리자 및 지원 담당자)
  • 마케팅 팀(제품 마케팅, 성장 마케팅, 브랜드, 콘텐츠, GTM 전략 및 보도 자료를 이끌 팀)
  • 비즈니스 개발 및 파트너

이 모든 파트너들은 제품 업데이트를 소화하고 이를 직무에 얼마나 적용해야 하는지 즉시 파악해야 합니다. 그들은 또한 최종 사용자가 어떤 변화가 그들에게 미치는지를 이해하도록 도울 수 있는 방법을 고려해야 합니다.

출시 소통을 작성하는 사람(또는 팀)은 제품 지식을 소비하게 될 모든 청중을 고려해야 합니다. 출시가 백엔드 엔지니어와 소매 산업의 잠재 고객에게 미치는 영향은 무엇입니까?

who-are-release-notes-for.png

출시 노트를 작성하는 방법

여러 청중의 필요를 고려하는 것이 어렵지만, 제품 관리자 또는 제품 마케팅 관리자(PMM)가 다섯 개의 서로 다른 버전의 내부 출시 노트를 작성하는 것은 스케일 할 수 없습니다. 내 경험에 따르면, 출시 노트는 너무 길고 맥락이 없거나 기술력이 부족합니다. 정적 출시 노트는 이러한 통찰력을 제공하지 않으며 종종 작성자를 위해 작성되므로 변경 사항을 이해해야 하는 사람을 고려하지 않습니다. 솔직히 말해, 그들은 대개 놓치는 기회입니다.  

how-not-to-write-release-notes.png

나는 제품 관리로부터 단조로운 목소리가 슬라이드에 대한 요점을 통과시키는 매주 한 시간짜리 출시 노트 호출을 앉아 있었습니다. 설명이 끝난 후, 같은 제품 관리자는 이메일, 전화(그것 기억하시나요?), 슬랙 등으로 고객 지원 팀에서 영업 팀까지 모든 사람에게 변화를 그들에게, 그들의 고객 및 잠재 고객에게 의미하는 것을 알리기 위해 연락을 받습니다. 당신이 통화를 놓쳤다면, 당신은 뉘앙스와 맥락을 놓쳤고 대신 원시 변경 로그만 받았습니다.

그러나 제품 관리자의 역할은 이러한 신성한 번역을 하는 것이 없으며, 그들의 역할은 시장을 위한 문제를 해결하는 제품을 만드는 것입니다. PMM의 역할은 그것의 의도를 번역하여 시장이 가치를 이해하도록 하는 것입니다.

우수한 소프트웨어 출시 노트를 작성하는 비결

나는 사운드 오브 뮤직 팬입니다(충격적이죠, 나는 알고 있습니다) 그리고 가능한 전문가로서 영화의 영원한 교훈이 진정합니다. "우리는 맨 처음부터 시작하자/정말 좋은 출발 장소다"가 매주 내 머리를 지나갑니다. 그러므로, 제품 전달 프로세스를 형성하거나 재형성하는 과정에서, 당신은 주제를 가르치기 전에 언어를 배워야 합니다.

1. 내부 용어집 개발

이 프로세스를 파악하는 첫 번째 단계는 모든 팀이 같은 언어를 사용하게 하는 것입니다. 공유된 용어를 소통하는 것은 분명한 것처럼 보이지만, 이는 조직 전체에서 발생하고 있지 않을 수 있습니다. 약어를 모르고 언어를 오해하는 것은 고립감을 느끼게 하며, 팀 간에 혼란과 단절을 초래할 수 있습니다.

예시: 우리 마케팅 팀은 기능으로 시장에 나갈 때 사용할 용어인 "출시"를 사용합니다. 그러나 엔지니어링 팀은 기능이 스테이징 환경에 출시되었을 때를 설명하기 위해 "출시"라는 단어를 사용합니다. 기능의 특정 출시가 고객이 이에 대해 알기 전에 엔지니어링에게는 "완료"된 상태입니다. 이것은 혼란스럽고 내부적으로 상충되는 상황이었습니다.

아무도 정의를 요청함으로써 무언가가 무엇을 의미하는지 공개적으로 말하는 사람 되기를 원하지 않습니다. 우리의 해결책: 우리는 크로스 기능 작업 그룹(엔지니어링, 제품, 제품 마케팅의 대표자의)에서 뉘앙스를 명확히 하고 제품 출시 정의를 문서화했습니다.

참고: 카드가 로드되지 않으면 페이지를 새로 고치는 것이 좋습니다!

2. 출시 노트에 포함해야 할 항목

공유된 언어가 확립되고 팀이 출시 용어를 설명할 수 있게 된 후, 노트를 작성할 수 있습니다. 가장 쉽고 빠른 방법은 출시 노트를 작성하기 위한 재사용 가능한 템플릿을 만드는 것입니다. 이런 식으로 이해관계자들이 몇 번의 반복 후 형식에 익숙해지고, 매번 처음부터 다시 만들 필요가 없어집니다.

최소한 좋은 출시 노트에는 다음과 같은 내용이 포함됩니다:

  • 출시 날짜
  • 내부 및 외부
  • 기능 또는 버그에 대한 설명
  • 영향을 받는 제품(여러 개 있을 경우)
  • 여러 소프트웨어 제품이 있는 경우, 버전 번호도 포함하는 것이 좋습니다.
  • 내부에서 질문할 수 있는 위치

그렇지만 훌륭한 출시 노트에는 또한 다음이 포함됩니다:

  • 예상되는 자주 묻는 질문(FAQ)
  • 새로운 공개 문서에 대한 링크, 사용 가능할 경우
  • 기능에 대해서:
  • 기능의 이름
  • 기능이 어떻게 구현되었는지 스크린샷
  • 기능을 시연하는 방법에 대한 비디오
  • 기능이 존재하는 이유
  • 해당 구매자/고객 페르소나에 미치는 영향

여기 템플릿을 내부적으로 사용합니다(복사하셔도 됩니다!):

💡참고: 이 작업을 위해 직접 책임 있는 개인을 지정하는 것이 유용합니다(공동 작업으로 두지 말고 누군가가 소유하도록 하세요). 엔지니어링 또는 제품 관리자는 노트의 기술적인 부분(이름/버전/제품/날짜/스크린샷)을 소유해야 하며, 제품 마케팅 관리자는 컨텍스트 정보(구매자 페르소나/왜 중요한지를) 소유해야 합니다.

제품 전달 프로세스 전략 구현

일관된 커뮤니케이션 형식 생성

용어를 통합하고 템플릿을 작성한 후에, 다음 단계는 일관된 전달 매체(예: 슬랙, 이메일, 룸, Guru, 구글 문서)와 방법론에 대해 동의하는 것입니다. 일관된 전달 매체는 당신의 출시 노트 이해 관계자들이 어디로 가야 하거나 뭘 살펴봐야 하는지, 또는 구독해야 하는지를 아는 것을 보장합니다.

이것은 또한 변경 관리에 필수적입니다. 왜냐하면 일반적으로 누군가에게 무언가를 완전히 흡수할 수 있도록 여러 번 말해야 하기 때문입니다. 출시 유형, UI/UX(사용자 인터페이스 및 사용자 경험)의 변경 사항에 따라 고객에게 미치는 영향이 다르며, 출시 노트 청중은 제품 지식을 전달받아야 합니다 (전달해야 합니다). Guru에서는 푸시 및 풀 방법을 모두 사용합니다.

풀: 지식을 찾을 수 있는 방법

우리의 경우, 이해관계자들은 슬랙 #release-notes 채널을 팔로우하며, 버그 수정부터 새로운 기능까지에 대한 일관되고 소화 가능한 형식을 유지합니다. 각각의 청중은 출시가 진행되고 있다는 것(슬랙이나 이메일의 풀을 통해) 만 아는 것이 아니라, 그들이 출시가 맥락에서 왜 중요한지 알아야 합니다.

implementing-product-delivery-process-strategy.png

출시가 단순히 이루어질 것이고 이미 발생했음을 아는 것은 가치가 없습니다. 당신의 팀이 실제로 그것을 가지고 행동할 수 없다면 말이죠. 일관된 형식을 개발하기 위해 적절한 맥락을 제공할 수 있도록, 나는 영업 담당자, 계정 개발 담당자, 비즈니스 개발 인사들(모두)에게 설문조사를 수행하여 "기능 분해 카드"라고 부르는 제품 전달 템플릿을 수립했습니다.

엔지니어링 관리자가 새로운 기능 개발을 시작할 때, 직접 책임이 있는 개인들은 Asana를 통해 기능별 기능 분해 카드를 생성하라는 알림을 받습니다. 새로운 기능 분해 카드는 우리가 출시하는 "기능의 두뇌"로, 견고한 단일 정보 출처입니다. 주제 전문가(SME) — PMM 및 영업 엔지니어와 같은 — 는 출시가 왜 가치가 있는지, 누구에게 가장 중요한지를 설명하고, 필요한 경우, 더 큰 스토리에 기능을 어떻게 시연해야 하는지를 안내합니다.

출시 노트 이해 관계자, 특히 계정 임원들은 기능 분해 카드를 반복적으로 참조합니다. 왜냐하면 그들은 이 카드에서 동적 지식이 신뢰할 수 있고, 관련성이 있으며, 적용 가능한 것을 배웠기 때문입니다. 이제 청중들은 같은 언어를 사용하고 동일한(동적) 플레이북을 읽고 있습니다. 기능 분해 카드에 대한 반응은 여전히 "풀" 방법의 일환입니다. 왜냐하면 이는 자율적이며, 영업 또는 지원 통화를 준비하거나, 잠재 고객이 로드맵에 대해 질문할 경우에 해당됩니다.

푸시: 능동적으로 지식을 제공하기

푸시 방법은 출시 정보가 시기적절하며 특정 팀에 중요할 때 사용됩니다. 여기에서, 이는 Guru의 공지 사항 기능을 통해 수행됩니다. 내 내부 청중에게 미치는 영향을 기반으로, 나는 공지 사항을 푸시합니다. 이를 위해 관련 그룹에 전달합니다. 그 후, 나는 알림을 확인한 사람들에 대한 보고서를 볼 수 있으며, 이를 잊은 사람들에게 공개적으로 검토(사기)하고 상기시킵니다.  

왜 지식 기반 문화가 핵심인가 🗝

knowledge-driven-culture-is-key.png

앞서 말한 모든 것에도 불구하고, 실제로는 용어에 동의하고, 뛰어난 출시 노트를 작성하고, 동적 제품 전달을 위한 메커니즘을 생성하는 것만큼 간단하지 않습니다. 팀은 지식을 협력하고 지속적으로 피드백을 제공할 수 있어야 합니다. 지식 공유를 통해 피드백을 제공하고 개선하는 것은 팀의 모든 구성원의 역할과 책임입니다.

우리에게는 이 말이 의미합니다. 지식 소비자(이 경우 출시 노트 이해관계자)가 질문이 있거나 새로운 것을 알게 되면 기능 분해 카드에 댓글을 답니다. 우리는 또한 슬랙에서 묻고 대답하는 질문을 기능 분해 카드에 댓글을 다는 방식으로 지속적으로 지식을 개선합니다. 주제 전문가(일반적으로 PMM)는 새로운 지식이나 관련 질문을 검토하고 통합하여 해당 기능 분해 카드에서 맥락에 맞게 그것을 정리합니다.

우리는 모든 출시 노트를 쉽게 접근 가능하게 만들며, 이를 기능 분해 보드의 향후 또는 출시된 섹션에 넣어 더욱 내부적으로 조직할 수 있습니다. 그렇게 하면 쉽게 한눈에 보기 좋습니다. 당신이 Guru를 사용하지 않는다면, 출시 노트 페이지를 만들거나 연결된 변경 로그를 만드는 것이 좋습니다.

다른 모든 프로세스와 마찬가지로, 이 프로세스 또한 지속적으로 진화합니다. 제품 전달 및 출시 노트는 결코 한 번에 끝나는 것이 아닙니다. 비즈니스의 요구가 변화함에 따라, 프로세스, 책임 및 템플릿도 그에 맞게 변화해야 합니다. 그러나 이해력, 맥락 및 사용성을 쉽게 만들려고 노력하면, 절대적으로 손해 볼 일이 없습니다.

Experience the power of the Guru platform firsthand – take our interactive product tour
투어 신청