Use Knowledge Management to Create Release Notes Templates and Streamline Your Product Delivery Process
Tìm hiểu bí quyết viết ghi chú phát hành tuyệt vời, những gì cần bao gồm trong mẫu của bạn, và làm thế nào để sử dụng kiến thức để tối ưu hóa quy trình giao hàng sản phẩm của bạn.
Sự thật: Việc truyền thông phát hành sản phẩm gặp vấn đề
Mục đích của ghi chú phát hành sản phẩm là để thông báo cho các đội ngũ nội bộ của bạn (từ kỹ thuật đến hỗ trợ khách hàng) và các bên liên quan bên ngoài (khách hàng và đối tác) rằng đã có những thay đổi đối với sản phẩm. Trong công nghệ, nơi mọi thứ diễn ra với tốc độ ánh sáng, việc cung cấp cập nhật sản phẩm qua các ghi chú phát hành thực tế là một vấn đề đã tồn tại từ lâu.
Mọi công ty mà tôi đã làm việc đều gặp khó khăn trong việc làm cho ghi chú phát hành trở nên “đúng đắn”. Nhưng đó là một điều khó để làm cho chính xác; tầm quan trọng của mỗi thay đổi hoặc ra mắt sản phẩm sẽ khác nhau tùy thuộc vào đối tượng, cách thay đổi đó làm thay đổi sự tương tác của một nhóm cụ thể với tính năng đó, và cách mà nhóm đó sử dụng sản phẩm tổng thể hàng ngày.
Các thông báo phát hành sản phẩm này (thường được gọi là ghi chú phát hành) cần phải được gửi đến các khán giả mà quan tâm đến những điều khác nhau. Là một nhà lãnh đạo năng lực doanh thu tại Guru, những người mà tôi đại diện là bất kỳ ai mà khả năng làm việc của họ bị ảnh hưởng bởi lộ trình sản phẩm, bao gồm:
Các đội ngũ Sản phẩm/Thiết kế/Kỹ thuật
Đội ngũ Bán hàng (Vận hành bán hàng, Bán hàng trong nhà, Nhân viên tài khoản trên các phân khúc)
Trải nghiệm Khách hàng (Quản lý Thành công và đại diện hỗ trợ)
Đội ngũ Marketing (Marketing sản phẩm, Marketing tăng trưởng, Thương hiệu, Nội dung mà sẽ dẫn dắt chiến lược GTM và các hoạt động truyền thông báo chí cho sản phẩm)
Phát triển Kinh doanh và Các Đối tác
Tất cả các đối tác này phải tiếp nhận các cập nhật sản phẩm và lập tức xác định mức độ mà họ cần áp dụng những cập nhật đó vào công việc của họ. Họ cũng cần xem xét cách họ có thể giúp người dùng cuối hiểu được tác động của bất kỳ thay đổi nào sẽ có với họ.
Người (hoặc nhóm) tạo ra các thông báo phát hành cần phải xem xét tất cả các đối tượng sẽ tiêu thụ kiến thức sản phẩm. Những tác động của việc phát hành đối với một kỹ sư phía sau so với một khách hàng tiềm năng trong ngành bán lẻ là gì?
Cách Không tiếp cận Ghi chú phát hành
Mặc dù khó khăn trong việc tính toán nhu cầu của các đối tượng khác nhau, nhưng việc một Quản lý sản phẩm hoặc một Quản lý Tiếp thị sản phẩm (PMM) viết năm phiên bản khác nhau của ghi chú phát hành nội bộ cũng không khả thi. Theo kinh nghiệm của tôi, ghi chú phát hành thường quá dài và không phù hợp bối cảnh hoặc không đủ về mặt kỹ thuật. Các ghi chú phát hành tĩnh không cung cấp cho chúng tôi cái nhìn này và thường được viết cho tác giả, không phải cho người cần hiểu những gì đã thay đổi. Nói thẳng ra, chúng thường là những cơ hội bị bỏ lỡ.
Tôi đã tham gia qua những cuộc gọi ghi chú phát hành hàng tuần kéo dài một giờ mà giọng nói đơn điệu từ bộ phận quản lý sản phẩm nói qua các điểm trên các slide. Sau khi cuộc gọi kết thúc, quản lý sản phẩm đó sẽ nhận được email, cuộc gọi điện thoại (hãy nhớ chúng không?), Slacks, v.v. từ mọi người từ hỗ trợ khách hàng đến bán hàng muốn biết thay đổi có nghĩa là gì với họ, khách hàng của họ, và những khách hàng tiềm năng. Nếu bạn đã bỏ lỡ cuộc gọi, bạn đã bỏ lỡ sự tinh tế và bối cảnh, và thay vào đó chỉ nhận được nhật ký thay đổi thô.
Nhưng vai trò của quản lý sản phẩm không phải để thực hiện việc dịch thuật thiêng liêng này; công việc của họ là xây dựng một sản phẩm giải quyết một vấn đề cho thị trường. Đó là công việc của PMM để dịch cái đó ý định để thị trường hiểu giá trị của nó.
Bí quyết để viết các ghi chú phát hành phần mềm tuyệt vời
Tôi là một fan lớn của Âm thanh của Âm nhạc (nghe thật sốc), và với tư cách là một chuyên gia liên quan, những bài học bất hủ trong bộ phim vẫn đúng. “Hãy bắt đầu từ những điều rất cơ bản/nó là một nơi rất tốt để bắt đầu,” việc này luôn diễn ra trong đầu tôi hàng tuần. Vì vậy, trong việc định hình hoặc định nghĩa lại quy trình giao hàng sản phẩm, bạn phải học ngôn ngữ trước khi bạn có thể dạy môn học.
1. Phát triển một từ điển nội bộ
Bước đầu tiên khi đào sâu vào quy trình này có nghĩa là cần có tất cả đội ngũ nói cùng một ngôn ngữ. Việc phổ biến các thuật ngữ chung có vẻ hiển nhiên, nhưng nó có thể không diễn ra trong toàn tổ chức của bạn. Không biết các từ viết tắt và hiểu nhầm ngôn ngữ có thể khiến người ta cảm thấy cô lập, tạo ra sự nhầm lẫn và các silo giữa các nhóm.
Ví dụ: Đội ngũ marketing của chúng tôi sử dụng thuật ngữ “ra mắt” để mô tả khi nào và làm thế nào chúng tôi sẽ tiếp cận thị trường với một tính năng. Tuy nhiên, đội ngũ kỹ thuật lại sử dụng từ “ra mắt” để mô tả khi một tính năng đã được phát hành đến môi trường staging của chúng tôi. Việc ra mắt cụ thể tính năng là “hoàn tất” đối với kỹ thuật trước khi khách hàng của chúng tôi biết về nó. Đây thật sự gây nhầm lẫn và xung đột nội bộ.
Không ai muốn trở thành người lên tiếng công khai thừa nhận rằng họ không hiểu ý nghĩa của một điều gì đó bằng cách hỏi định nghĩa. Giải pháp của chúng tôi: Trong một nhóm làm việc đa chức năng (có đại diện từ kỹ thuật, sản phẩm, tiếp thị sản phẩm), chúng tôi đã làm rõ các sắc thái và tài liệu định nghĩa phát hành sản phẩm của chúng tôi:
Lưu ý: Nếu có bất kỳ thẻ nào không tải được, chỉ cần làm mới trang!
2. Những gì cần bao gồm trong ghi chú phát hành của bạn
Khi một ngôn ngữ chung được thiết lập và đội ngũ của bạn có thể diễn đạt các thuật ngữ phát hành, bạn có thể viết ghi chú của mình. Điều dễ nhất là tạo một mẫu có thể tái sử dụng để viết ghi chú phát hành. Theo cách này, các bên liên quan sẽ quen thuộc với định dạng sau một vài lần thử nghiệm, và sẽ tiết kiệm cho bạn rắc rối phải tái phát minh bánh xe mỗi lần.
Ít nhất, ghi chú phát hành tốt bao gồm:
Ngày phát hành
Nội bộ và bên ngoài
Mô tả về tính năng hoặc lỗi
Sản phẩm bị ảnh hưởng (nếu bạn có nhiều hơn một)
Nếu bạn có nhiều sản phẩm phần mềm, bạn cũng có thể muốn bao gồm cả số phiên bản
Nơi có thể hỏi câu hỏi nội bộ
Ghi chú phát hành tuyệt vời, tuy nhiên, cũng bao gồm:
Các câu hỏi thường gặp (FAQs) được dự đoán
Liên kết đến tài liệu công khai mới, nếu có
Đối với các tính năng:
Tên của tính năng
Ảnh chụp màn hình về hình thức của tính năng
Video về cách trình diễn tính năng
Tại sao tính năng này lại tồn tại
Cách nó ảnh hưởng đến các nhân vật người mua/khách hàng liên quan
Đây là mẫu mà chúng tôi sử dụng nội bộ (cảm thấy tự do để sao chép!):
💡Lưu ý: Thật hữu ích khi giao nhiệm vụ cho những cá nhân có trách nhiệm trực tiếp cho nhiệm vụ này (thay vì để nó trở thành nỗ lực chung mà không ai sở hữu). Những người Quản lý Kỹ thuật hoặc Sản phẩm nên giữ phần kỹ thuật của ghi chú (tên/phiên bản/sản phẩm/ngày/ảnh chụp màn hình), trong khi các Quản lý Tiếp thị Sản phẩm hoặc Kỹ sư Bán Hàng nên giữ thông tin bối cảnh (nhân vật người mua/tại sao nó có ý nghĩa).
Triển khai chiến lược quy trình giao hàng sản phẩm
Tạo một định dạng truyền thông nhất quán
Giờ đây, khi bạn đã thống nhất ngôn ngữ và viết mẫu của mình, bước tiếp theo là đồng ý về một phương tiện giao hàng nhất quán (ví dụ: Slack, email, Loom, Guru, Google Docs) và phương pháp. Một phương tiện giao hàng nhất quán đảm bảo rằng các bên liên quan đến ghi chú phát hành của bạn biết nơi họ nên đến hoặc nhìn hoặc đăng ký (để lấy thông tin) để biết về một bản phát hành.
Điều này cũng rất quan trọng cho quản lý sự thay đổi vì bạn thường phải cho ai đó biết điều gì đó nhiều lần để đảm bảo rằng họ hoàn toàn hấp thụ điều đó. Tùy thuộc vào loại phát hành, những thay đổi đối với UI/UX (giao diện người dùng và trải nghiệm người dùng), và tác động đến khách hàng, khán giả ghi chú phát hành của bạn sẽ cần được đẩy kiến thức sản phẩm (để đẩy). Tại Guru, chúng tôi sử dụng cả phương pháp đẩy và kéo.
Phần Kéo: Nơi tìm kiến thức
Đối với chúng tôi, các bên liên quan có thể theo dõi trong kênh Slack của chúng tôi #release-notes, nơi có một định dạng nhất quán và dễ tiêu hóa cho mọi thứ từ sửa lỗi đến các tính năng hoàn toàn mới. Hãy nhớ rằng các khán giả của bạn không chỉ phải biết rằng các bản phát hành đang diễn ra (thông qua việc kéo trong Slack hoặc email) mà quan trọng hơn, họ cần phải biết tại sao bản phát hành đó lại có ý nghĩa trong bối cảnh.
Kiến thức rằng một bản phát hành đơn giản sẽ xảy ra hoặc đã xảy ra không có giá trị trừ khi đội ngũ của bạn thực sự có thể làm gì đó với nó. Để phát triển một định dạng nhất quán sẽ cung cấp bối cảnh phù hợp, tôi đã khảo sát các nhân viên bán hàng, các nhân viên phát triển tài khoản, những người phát triển kinh doanh (các công việc), để thiết lập mẫu cho việc giao hàng sản phẩm mà chúng tôi gọi là “Thẻ Phân tích Tính năng”, mà bạn có thể tìm thấy ở trên.
Khi một Quản lý Kỹ thuật bắt đầu phát triển một tính năng mới, những người có trách nhiệm trực tiếp sẽ được thông báo qua Asana để tạo Thẻ Phân tích Tính năng cụ thể cho tính năng đó bằng cách sử dụng mẫu ghi chú phát hành. Thẻ Phân tích Tính năng mới trở thành nguồn thông tin chính xác và duy nhất hoặc “bộ não của tính năng” mà chúng tôi đang phát hành. Các chuyên gia về vấn đề (SME) — chẳng hạn như PMM và kỹ sư bán hàng — bao gồm các chi tiết về lý do bản phát hành có giá trị, mà ai sẽ là người chịu ảnh hưởng nhiều nhất, và ở những nơi phù hợp, hướng dẫn cách trình diễn tính năng như một phần của một câu chuyện lớn hơn.
Các bên liên quan đến ghi chú phát hành, đặc biệt là Nhân viên Tài khoản, cần trở lại với cùng một thẻ nhiều lần vì họ đã nhận ra rằng kiến thức động trên Thẻ Phân tích Tính năng là đáng tin cậy, liên quan, và có thể áp dụng. Các khán giả giờ đây đều nói cùng một ngôn ngữ và đọc từ cùng một (tài liệu động). Quay lại Thẻ Phân tích Tính năng vẫn là một phần của phương pháp “kéo” vì nó tự chủ, và được thực hiện để chuẩn bị cho một cuộc gọi bán hàng hoặc hỗ trợ, hoặc nếu một khách hàng tiềm năng có một câu hỏi về lộ trình sản phẩm.
Phần Đẩy: Cung cấp kiến thức một cách chủ động
Phương pháp Đẩy trở thành hữu ích khi kiến thức về một bản phát hành là thời gian nhạy cảm, và rất quan trọng cho các nhóm cụ thể. Ở đây, điều này được thực hiện thông qua chức năng thông báo của Guru. Dựa trên tác động đến khán giả nội bộ của tôi, tôi đẩy một thông báo qua Guru đến một nhóm liên quan. Sau đó, tôi có thể thấy một báo cáo về những người đã xác nhận hoặc đọc cảnh báo và công khai nhắc nhở những người chưa làm vậy.
Tại sao văn hóa dựa trên kiến thức là chìa khóa 🗝
Mặc dù tất cả những điều trên, thực sự không đơn giản như việc đồng ý về thuật ngữ, viết ghi chú phát hành thực sự hấp dẫn, và tạo ra một cơ chế cho việc giao hàng sản phẩm động. Các đội ngũ cần phải có khả năng hợp tác trong việc chia sẻ kiến thức và cung cấp phản hồi theo thời gian. Đối với chúng tôi, điều đó có nghĩa là khi những người tiêu thụ kiến thức (trong trường hợp này, các bên liên quan đến ghi chú phát hành) có một câu hỏi hoặc học được điều gì mới, họ sẽ bình luận trên Thẻ Phân tích Tính năng.
Đối với chúng tôi, điều đó có nghĩa là khi những người tiêu dùng kiến thức (trong trường hợp này, những người liên quan đến ghi chú phát hành) có một câu hỏi hoặc học được điều gì mới, họ sẽ bình luận trên Thẻ Phân Hạng Tính Năng. Chúng tôi cũng kết hợp những câu hỏi đã được hỏi và trả lời trong Slack bằng cách bình luận như một cách liên tục cải thiện kiến thức. Chuyên gia về vấn đề (thường là PMM) sẽ xem xét và đưa vào kiến thức mới hoặc câu hỏi phù hợp, đặt nó vào bối cảnh trong thẻ Phân tích Tính năng cụ thể.
Chúng tôi cũng làm cho tất cả ghi chú phát hành của mình dễ tiếp cận bằng cách đưa chúng vào các phần sắp tới hoặc đã phát hành trong Bảng Phân tích Tính năng của chúng tôi, nơi chúng có thể được tổ chức hơn nữa một cách nội bộ. Bằng cách đó, chúng dễ theo dõi chỉ bằng một cái nhìn. Nếu bạn không sử dụng Guru, chúng tôi khuyên bạn nên tạo một trang ghi chú phát hành hoặc nhật ký thay đổi có liên kết.
Giống như bất kỳ quy trình nào khác, quy trình này cũng đang liên tục phát triển. Việc giao hàng sản phẩm và ghi chú phát hành chưa bao giờ đơn giản chỉ là một lần xong. Khi những nhu cầu của doanh nghiệp bạn thay đổi, quy trình, trách nhiệm và mẫu công việc của bạn cũng nên thay đổi theo. Nhưng bằng cách phấn đấu cho sự hiểu biết dễ dàng, bối cảnh, và tính sử dụng, bạn không thể thất bại.
Sự thật: Việc truyền thông phát hành sản phẩm gặp vấn đề
Mục đích của ghi chú phát hành sản phẩm là để thông báo cho các đội ngũ nội bộ của bạn (từ kỹ thuật đến hỗ trợ khách hàng) và các bên liên quan bên ngoài (khách hàng và đối tác) rằng đã có những thay đổi đối với sản phẩm. Trong công nghệ, nơi mọi thứ diễn ra với tốc độ ánh sáng, việc cung cấp cập nhật sản phẩm qua các ghi chú phát hành thực tế là một vấn đề đã tồn tại từ lâu.
Mọi công ty mà tôi đã làm việc đều gặp khó khăn trong việc làm cho ghi chú phát hành trở nên “đúng đắn”. Nhưng đó là một điều khó để làm cho chính xác; tầm quan trọng của mỗi thay đổi hoặc ra mắt sản phẩm sẽ khác nhau tùy thuộc vào đối tượng, cách thay đổi đó làm thay đổi sự tương tác của một nhóm cụ thể với tính năng đó, và cách mà nhóm đó sử dụng sản phẩm tổng thể hàng ngày.
Các thông báo phát hành sản phẩm này (thường được gọi là ghi chú phát hành) cần phải được gửi đến các khán giả mà quan tâm đến những điều khác nhau. Là một nhà lãnh đạo năng lực doanh thu tại Guru, những người mà tôi đại diện là bất kỳ ai mà khả năng làm việc của họ bị ảnh hưởng bởi lộ trình sản phẩm, bao gồm:
Các đội ngũ Sản phẩm/Thiết kế/Kỹ thuật
Đội ngũ Bán hàng (Vận hành bán hàng, Bán hàng trong nhà, Nhân viên tài khoản trên các phân khúc)
Trải nghiệm Khách hàng (Quản lý Thành công và đại diện hỗ trợ)
Đội ngũ Marketing (Marketing sản phẩm, Marketing tăng trưởng, Thương hiệu, Nội dung mà sẽ dẫn dắt chiến lược GTM và các hoạt động truyền thông báo chí cho sản phẩm)
Phát triển Kinh doanh và Các Đối tác
Tất cả các đối tác này phải tiếp nhận các cập nhật sản phẩm và lập tức xác định mức độ mà họ cần áp dụng những cập nhật đó vào công việc của họ. Họ cũng cần xem xét cách họ có thể giúp người dùng cuối hiểu được tác động của bất kỳ thay đổi nào sẽ có với họ.
Người (hoặc nhóm) tạo ra các thông báo phát hành cần phải xem xét tất cả các đối tượng sẽ tiêu thụ kiến thức sản phẩm. Những tác động của việc phát hành đối với một kỹ sư phía sau so với một khách hàng tiềm năng trong ngành bán lẻ là gì?
Cách Không tiếp cận Ghi chú phát hành
Mặc dù khó khăn trong việc tính toán nhu cầu của các đối tượng khác nhau, nhưng việc một Quản lý sản phẩm hoặc một Quản lý Tiếp thị sản phẩm (PMM) viết năm phiên bản khác nhau của ghi chú phát hành nội bộ cũng không khả thi. Theo kinh nghiệm của tôi, ghi chú phát hành thường quá dài và không phù hợp bối cảnh hoặc không đủ về mặt kỹ thuật. Các ghi chú phát hành tĩnh không cung cấp cho chúng tôi cái nhìn này và thường được viết cho tác giả, không phải cho người cần hiểu những gì đã thay đổi. Nói thẳng ra, chúng thường là những cơ hội bị bỏ lỡ.
Tôi đã tham gia qua những cuộc gọi ghi chú phát hành hàng tuần kéo dài một giờ mà giọng nói đơn điệu từ bộ phận quản lý sản phẩm nói qua các điểm trên các slide. Sau khi cuộc gọi kết thúc, quản lý sản phẩm đó sẽ nhận được email, cuộc gọi điện thoại (hãy nhớ chúng không?), Slacks, v.v. từ mọi người từ hỗ trợ khách hàng đến bán hàng muốn biết thay đổi có nghĩa là gì với họ, khách hàng của họ, và những khách hàng tiềm năng. Nếu bạn đã bỏ lỡ cuộc gọi, bạn đã bỏ lỡ sự tinh tế và bối cảnh, và thay vào đó chỉ nhận được nhật ký thay đổi thô.
Nhưng vai trò của quản lý sản phẩm không phải để thực hiện việc dịch thuật thiêng liêng này; công việc của họ là xây dựng một sản phẩm giải quyết một vấn đề cho thị trường. Đó là công việc của PMM để dịch cái đó ý định để thị trường hiểu giá trị của nó.
Bí quyết để viết các ghi chú phát hành phần mềm tuyệt vời
Tôi là một fan lớn của Âm thanh của Âm nhạc (nghe thật sốc), và với tư cách là một chuyên gia liên quan, những bài học bất hủ trong bộ phim vẫn đúng. “Hãy bắt đầu từ những điều rất cơ bản/nó là một nơi rất tốt để bắt đầu,” việc này luôn diễn ra trong đầu tôi hàng tuần. Vì vậy, trong việc định hình hoặc định nghĩa lại quy trình giao hàng sản phẩm, bạn phải học ngôn ngữ trước khi bạn có thể dạy môn học.
1. Phát triển một từ điển nội bộ
Bước đầu tiên khi đào sâu vào quy trình này có nghĩa là cần có tất cả đội ngũ nói cùng một ngôn ngữ. Việc phổ biến các thuật ngữ chung có vẻ hiển nhiên, nhưng nó có thể không diễn ra trong toàn tổ chức của bạn. Không biết các từ viết tắt và hiểu nhầm ngôn ngữ có thể khiến người ta cảm thấy cô lập, tạo ra sự nhầm lẫn và các silo giữa các nhóm.
Ví dụ: Đội ngũ marketing của chúng tôi sử dụng thuật ngữ “ra mắt” để mô tả khi nào và làm thế nào chúng tôi sẽ tiếp cận thị trường với một tính năng. Tuy nhiên, đội ngũ kỹ thuật lại sử dụng từ “ra mắt” để mô tả khi một tính năng đã được phát hành đến môi trường staging của chúng tôi. Việc ra mắt cụ thể tính năng là “hoàn tất” đối với kỹ thuật trước khi khách hàng của chúng tôi biết về nó. Đây thật sự gây nhầm lẫn và xung đột nội bộ.
Không ai muốn trở thành người lên tiếng công khai thừa nhận rằng họ không hiểu ý nghĩa của một điều gì đó bằng cách hỏi định nghĩa. Giải pháp của chúng tôi: Trong một nhóm làm việc đa chức năng (có đại diện từ kỹ thuật, sản phẩm, tiếp thị sản phẩm), chúng tôi đã làm rõ các sắc thái và tài liệu định nghĩa phát hành sản phẩm của chúng tôi:
Lưu ý: Nếu có bất kỳ thẻ nào không tải được, chỉ cần làm mới trang!
2. Những gì cần bao gồm trong ghi chú phát hành của bạn
Khi một ngôn ngữ chung được thiết lập và đội ngũ của bạn có thể diễn đạt các thuật ngữ phát hành, bạn có thể viết ghi chú của mình. Điều dễ nhất là tạo một mẫu có thể tái sử dụng để viết ghi chú phát hành. Theo cách này, các bên liên quan sẽ quen thuộc với định dạng sau một vài lần thử nghiệm, và sẽ tiết kiệm cho bạn rắc rối phải tái phát minh bánh xe mỗi lần.
Ít nhất, ghi chú phát hành tốt bao gồm:
Ngày phát hành
Nội bộ và bên ngoài
Mô tả về tính năng hoặc lỗi
Sản phẩm bị ảnh hưởng (nếu bạn có nhiều hơn một)
Nếu bạn có nhiều sản phẩm phần mềm, bạn cũng có thể muốn bao gồm cả số phiên bản
Nơi có thể hỏi câu hỏi nội bộ
Ghi chú phát hành tuyệt vời, tuy nhiên, cũng bao gồm:
Các câu hỏi thường gặp (FAQs) được dự đoán
Liên kết đến tài liệu công khai mới, nếu có
Đối với các tính năng:
Tên của tính năng
Ảnh chụp màn hình về hình thức của tính năng
Video về cách trình diễn tính năng
Tại sao tính năng này lại tồn tại
Cách nó ảnh hưởng đến các nhân vật người mua/khách hàng liên quan
Đây là mẫu mà chúng tôi sử dụng nội bộ (cảm thấy tự do để sao chép!):
💡Lưu ý: Thật hữu ích khi giao nhiệm vụ cho những cá nhân có trách nhiệm trực tiếp cho nhiệm vụ này (thay vì để nó trở thành nỗ lực chung mà không ai sở hữu). Những người Quản lý Kỹ thuật hoặc Sản phẩm nên giữ phần kỹ thuật của ghi chú (tên/phiên bản/sản phẩm/ngày/ảnh chụp màn hình), trong khi các Quản lý Tiếp thị Sản phẩm hoặc Kỹ sư Bán Hàng nên giữ thông tin bối cảnh (nhân vật người mua/tại sao nó có ý nghĩa).
Triển khai chiến lược quy trình giao hàng sản phẩm
Tạo một định dạng truyền thông nhất quán
Giờ đây, khi bạn đã thống nhất ngôn ngữ và viết mẫu của mình, bước tiếp theo là đồng ý về một phương tiện giao hàng nhất quán (ví dụ: Slack, email, Loom, Guru, Google Docs) và phương pháp. Một phương tiện giao hàng nhất quán đảm bảo rằng các bên liên quan đến ghi chú phát hành của bạn biết nơi họ nên đến hoặc nhìn hoặc đăng ký (để lấy thông tin) để biết về một bản phát hành.
Điều này cũng rất quan trọng cho quản lý sự thay đổi vì bạn thường phải cho ai đó biết điều gì đó nhiều lần để đảm bảo rằng họ hoàn toàn hấp thụ điều đó. Tùy thuộc vào loại phát hành, những thay đổi đối với UI/UX (giao diện người dùng và trải nghiệm người dùng), và tác động đến khách hàng, khán giả ghi chú phát hành của bạn sẽ cần được đẩy kiến thức sản phẩm (để đẩy). Tại Guru, chúng tôi sử dụng cả phương pháp đẩy và kéo.
Phần Kéo: Nơi tìm kiến thức
Đối với chúng tôi, các bên liên quan có thể theo dõi trong kênh Slack của chúng tôi #release-notes, nơi có một định dạng nhất quán và dễ tiêu hóa cho mọi thứ từ sửa lỗi đến các tính năng hoàn toàn mới. Hãy nhớ rằng các khán giả của bạn không chỉ phải biết rằng các bản phát hành đang diễn ra (thông qua việc kéo trong Slack hoặc email) mà quan trọng hơn, họ cần phải biết tại sao bản phát hành đó lại có ý nghĩa trong bối cảnh.
Kiến thức rằng một bản phát hành đơn giản sẽ xảy ra hoặc đã xảy ra không có giá trị trừ khi đội ngũ của bạn thực sự có thể làm gì đó với nó. Để phát triển một định dạng nhất quán sẽ cung cấp bối cảnh phù hợp, tôi đã khảo sát các nhân viên bán hàng, các nhân viên phát triển tài khoản, những người phát triển kinh doanh (các công việc), để thiết lập mẫu cho việc giao hàng sản phẩm mà chúng tôi gọi là “Thẻ Phân tích Tính năng”, mà bạn có thể tìm thấy ở trên.
Khi một Quản lý Kỹ thuật bắt đầu phát triển một tính năng mới, những người có trách nhiệm trực tiếp sẽ được thông báo qua Asana để tạo Thẻ Phân tích Tính năng cụ thể cho tính năng đó bằng cách sử dụng mẫu ghi chú phát hành. Thẻ Phân tích Tính năng mới trở thành nguồn thông tin chính xác và duy nhất hoặc “bộ não của tính năng” mà chúng tôi đang phát hành. Các chuyên gia về vấn đề (SME) — chẳng hạn như PMM và kỹ sư bán hàng — bao gồm các chi tiết về lý do bản phát hành có giá trị, mà ai sẽ là người chịu ảnh hưởng nhiều nhất, và ở những nơi phù hợp, hướng dẫn cách trình diễn tính năng như một phần của một câu chuyện lớn hơn.
Các bên liên quan đến ghi chú phát hành, đặc biệt là Nhân viên Tài khoản, cần trở lại với cùng một thẻ nhiều lần vì họ đã nhận ra rằng kiến thức động trên Thẻ Phân tích Tính năng là đáng tin cậy, liên quan, và có thể áp dụng. Các khán giả giờ đây đều nói cùng một ngôn ngữ và đọc từ cùng một (tài liệu động). Quay lại Thẻ Phân tích Tính năng vẫn là một phần của phương pháp “kéo” vì nó tự chủ, và được thực hiện để chuẩn bị cho một cuộc gọi bán hàng hoặc hỗ trợ, hoặc nếu một khách hàng tiềm năng có một câu hỏi về lộ trình sản phẩm.
Phần Đẩy: Cung cấp kiến thức một cách chủ động
Phương pháp Đẩy trở thành hữu ích khi kiến thức về một bản phát hành là thời gian nhạy cảm, và rất quan trọng cho các nhóm cụ thể. Ở đây, điều này được thực hiện thông qua chức năng thông báo của Guru. Dựa trên tác động đến khán giả nội bộ của tôi, tôi đẩy một thông báo qua Guru đến một nhóm liên quan. Sau đó, tôi có thể thấy một báo cáo về những người đã xác nhận hoặc đọc cảnh báo và công khai nhắc nhở những người chưa làm vậy.
Tại sao văn hóa dựa trên kiến thức là chìa khóa 🗝
Mặc dù tất cả những điều trên, thực sự không đơn giản như việc đồng ý về thuật ngữ, viết ghi chú phát hành thực sự hấp dẫn, và tạo ra một cơ chế cho việc giao hàng sản phẩm động. Các đội ngũ cần phải có khả năng hợp tác trong việc chia sẻ kiến thức và cung cấp phản hồi theo thời gian. Đối với chúng tôi, điều đó có nghĩa là khi những người tiêu thụ kiến thức (trong trường hợp này, các bên liên quan đến ghi chú phát hành) có một câu hỏi hoặc học được điều gì mới, họ sẽ bình luận trên Thẻ Phân tích Tính năng.
Đối với chúng tôi, điều đó có nghĩa là khi những người tiêu dùng kiến thức (trong trường hợp này, những người liên quan đến ghi chú phát hành) có một câu hỏi hoặc học được điều gì mới, họ sẽ bình luận trên Thẻ Phân Hạng Tính Năng. Chúng tôi cũng kết hợp những câu hỏi đã được hỏi và trả lời trong Slack bằng cách bình luận như một cách liên tục cải thiện kiến thức. Chuyên gia về vấn đề (thường là PMM) sẽ xem xét và đưa vào kiến thức mới hoặc câu hỏi phù hợp, đặt nó vào bối cảnh trong thẻ Phân tích Tính năng cụ thể.
Chúng tôi cũng làm cho tất cả ghi chú phát hành của mình dễ tiếp cận bằng cách đưa chúng vào các phần sắp tới hoặc đã phát hành trong Bảng Phân tích Tính năng của chúng tôi, nơi chúng có thể được tổ chức hơn nữa một cách nội bộ. Bằng cách đó, chúng dễ theo dõi chỉ bằng một cái nhìn. Nếu bạn không sử dụng Guru, chúng tôi khuyên bạn nên tạo một trang ghi chú phát hành hoặc nhật ký thay đổi có liên kết.
Giống như bất kỳ quy trình nào khác, quy trình này cũng đang liên tục phát triển. Việc giao hàng sản phẩm và ghi chú phát hành chưa bao giờ đơn giản chỉ là một lần xong. Khi những nhu cầu của doanh nghiệp bạn thay đổi, quy trình, trách nhiệm và mẫu công việc của bạn cũng nên thay đổi theo. Nhưng bằng cách phấn đấu cho sự hiểu biết dễ dàng, bối cảnh, và tính sử dụng, bạn không thể thất bại.
Trải nghiệm sức mạnh của nền tảng Guru trực tiếp - tham gia tour sản phẩm tương tác của chúng tôi
