Trang này hoàn toàn đang trong quá trình xây dựng!
Viết kỹ thuật trực tuyến sẽ vẫn miễn phí.Thông tin sau đã được điều chỉnh với sự cho phép từ một bài viết của appcues.com (được trích dẫn bên dưới).
Tại sao hầu hết các ghi chú phát hành không được đọc (và cách khắc phục điều đó)
Hầu hết các bản ghi chú phát hành đều không được đọc. Không phải vì người dùng không quan tâm đến những gì đang thay đổi trong sản phẩm, mà vì các ghi chú được viết cho nhóm đã phát hành tính năng, chứ không phải cho người cần hiểu về nó.
Bạn có thể đã thấy điều này trước đây: một ghi chú phát hành mở đầu bằng "Đã triển khai lớp lưu trữ dữ liệu nâng cao để cải thiện thông lượng" khi điều người dùng thực sự cần nghe là "Báo cáo của bạn giờ tải nhanh gấp đôi." Phiên bản đầu tiên chỉ đánh dấu vào một ô. Phiên bản thứ hai thúc đẩy việc áp dụng.
Khoảng cách đó quan trọng hơn hầu hết các đội nhận ra. Một ghi chú phát hành là một khoảnh khắc giao tiếp sản phẩm. Đó là khoảng thời gian giữa việc phát hành và việc người dùng áp dụng. Làm đúng nó và người dùng sẽ khám phá điều bạn đã xây dựng. Bỏ lỡ nó thì tính năng giống như chưa được phát hành.
Bài viết này cung cấp cho bạn những gì bạn cần để thu hẹp khoảng cách đó: 13 ví dụ về ghi chú phát hành từ các công ty làm điều này hiệu quả (được tổ chức theo những gì làm cho mỗi ví dụ đáng để học tập), một mẫu mà bạn có thể lấy và điều chỉnh ngay hôm nay, và một hướng dẫn viết từng bước bao gồm các nguyên tắc cơ bản. Dù bạn là một quản lý sản phẩm đang viết ghi chú phát hành đầu tiên hay một nhà tiếp thị sản phẩm đang hoàn thiện quy trình, bạn sẽ có được những gì có thể sử dụng ngay lập tức.
Ghi chú phát hành là gì?
Ghi chú phát hành là một báo cáo ngắn gọn, hướng tới người sử dụng, được công bố cùng với phần mềm mới hoặc đã được cập nhật. Nó giải thích điều gì đã thay đổi, lý do tại sao điều đó quan trọng và ai chịu ảnh hưởng. Đối với các bản phát hành mới, ghi chú phát hành cung cấp cho người dùng tóm tắt về chức năng của sản phẩm. Đối với các bản cập nhật sản phẩm hiện có, ghi chú giải thích điều gì là mới, điều gì được cải tiến và điều gì đã được sửa chữa kể từ phiên bản trước.
Ví dụ ghi chú phát hành hiển thị các phiên bản trước đây
Ghi chú phát hành so với nhật ký thay đổi
Các điều khoản này thường bị sử dụng thay thế cho nhau, nhưng chúng là những thứ khác nhau. Ghi chú phát hành mô tả chi tiết một phiên bản hoặc bản cập nhật cụ thể: những gì đã thay đổi, tại sao điều đó quan trọng, ai bị ảnh hưởng. Sự phân biệt giữa changelog và ghi chú phát hành đáng để hiểu: changelog là nhật ký liên tục của tất cả ghi chú phát hành theo thời gian. Hãy nghĩ về nó như một kho lưu trữ. Nhiều sản phẩm duy trì cả hai: ghi chú phát hành riêng cho mỗi bản cập nhật và một trang changelog nơi tất cả chúng cùng tồn tại theo thứ tự thời gian đảo ngược.
Việc duy trì bản ghi liên tục là quan trọng. Nó cho thấy sản phẩm đang không ngừng cải tiến và rằng những thay đổi gần đây được xây dựng dựa trên những thay đổi trước đó. Nó cũng báo hiệu rằng công ty lắng nghe phản hồi và cam kết với trải nghiệm người dùng.
Các loại ghi chú phát hành
Không phải tất cả các cập nhật đều xứng đáng nhận được sự chú ý như nhau. Định dạng và độ sâu của ghi chú phát hành của bạn nên phù hợp với quy mô của sự thay đổi:
Ghi chú phát hành chính: Tính năng mới, thay đổi giao diện đáng kể, khả năng mới. Những điều này xứng đáng được trình bày đầy đủ với hình ảnh, ngữ cảnh về lý do thay đổi và hướng dẫn rõ ràng về cách sử dụng.
Ghi chú cập nhật nhỏ: Cải tiến từng bước, thay đổi UX nhỏ. Định dạng ngắn hơn hoạt động ở đây, thường từ một đến ba dòng cho mỗi mục.
Ghi chú sửa lỗi: Đã giải quyết các vấn đề. Định dạng danh sách, ngôn ngữ đơn giản, tập trung vào những gì người dùng đã trải qua trước đây so với những gì xảy ra bây giờ.
Ghi chú về bản vá bảo mật: Ngắn gọn và thực tế. Ưu tiên những điểm dễ bị tổn thương và những gì đã được khắc phục mà không có chi tiết kỹ thuật gây nhầm lẫn.
Tại sao thông báo phát hành lại quan trọng
Họ là cầu nối giữa việc giao hàng và sử dụng. Người dùng hiểu những gì đã thay đổi có khả năng khám phá và chấp nhận các tính năng mới hơn. Ghi chú phát hành là khoảnh khắc giao tiếp sản phẩm mà bạn chuyển đổi những gì đội ngũ kỹ thuật đã xây dựng thành những gì người dùng thực sự muốn thử. Nếu không có sự chuyển đổi đó, các tính năng sẽ bị bỏ qua, và việc chấp nhận tính năng gặp khó khăn vì nỗ lực mà đội của bạn đã đầu tư vào việc xây dựng chúng không đạt được tiềm năng.
Chúng giảm tải công việc cho đội ngũ hỗ trợ của bạn. Ghi chú phát hành chủ động giảm số câu hỏi đến về việc tại sao một cái gì đó trông khác hoặc hoạt động khác. Khi người dùng gặp phải một sự thay đổi mà họ không mong đợi, họ mở một vé hỗ trợ. Khi họ đã đọc một lời giải thích rõ ràng, họ sẽ không làm vậy. Toán học thật đơn giản: ghi chép sự thay đổi trước khi người dùng vấp phải nó.
Họ xây dựng niềm tin và giữ chân khách hàng. Các ghi chú phát hành rõ ràng và thường xuyên báo hiệu rằng sản phẩm đang được cải thiện tích cực. Đối với khách hàng đang xem xét việc gia hạn hoặc mở rộng, một nhật ký thay đổi là bằng chứng cho thấy sản phẩm đang phát triển. Đối với khách hàng đã gửi yêu cầu tính năng, việc thấy phản hồi của họ được phản ánh trong ghi chú phát hành làm sâu sắc thêm lòng trung thành.
Chúng sắc nét sự căn chỉnh nội bộ. Kỷ luật viết ghi chú phát hành tốt, đặc biệt là trả lời "điều gì đã thay đổi, cho ai, và tại sao điều đó quan trọng," buộc các đội sản phẩm phải giao tiếp rõ ràng trong tổ chức. Tiếp thị sản phẩm, thành công của khách hàng và bán hàng đều hưởng lợi khi thông tin phát hành rõ ràng và nhất quán. Ghi chú phát hành thường trở thành nguồn sự thật mà các đội khác tham khảo khi nói chuyện với khách hàng về những gì mới.
Nên bao gồm những gì trong ghi chú phát hành
Hãy coi đây như nội dung của một bản phát hành. Mỗi bản phát hành chắc chắn đều đề cập đến các yếu tố này, mặc dù độ sâu có thể khác nhau tùy thuộc vào việc bạn đang công bố một tính năng lớn hay một bản sửa lỗi thường xuyên:
Tiêu đề: Tên sản phẩm, số phiên bản hoặc ngày, và môi trường nếu có liên quan (web, iOS, API, v.v.).
Tóm tắt các thay đổi: Một hoặc hai câu mô tả nội dung bản phát hành này và những ai bị ảnh hưởng. Đây là phần người dùng đọc đầu tiên, vì vậy hãy làm cho nó ấn tượng.
Các tính năng mới: Được đặt tên, với tác động ngắn gọn đến người dùng. Nhấn mạnh vào những gì người dùng hiện có thể làm, không phải phần triển khai kỹ thuật.
Cải tiến: Những gì đã thay đổi từ góc độ của người dùng. "Kết quả tìm kiếm hiện tải nhanh hơn 40%" tốt hơn "Đã tối ưu hóa quy trình lập chỉ mục tìm kiếm."
Sửa lỗi: Mô tả bằng ngôn ngữ đơn giản về những gì người dùng đã trải nghiệm trước đây và bây giờ xảy ra điều gì. "Bảng điều khiển không còn bị đông lại khi lọc theo khoảng thời gian nữa" cho người dùng biết chính xác điều gì đã sai và rằng nó đã được sửa.
Các vấn đề đã biết hoặc giới hạn: Nếu có điều gì đó chưa được giải quyết hoàn toàn, hãy nói ra. Người dùng tôn trọng sự minh bạch hơn là họ ghét sự không hoàn hảo.
Cách viết ghi chú phát hành
Biết điều gì nên bao gồm là nền tảng. Cách bạn viết nó quyết định xem liệu ai đó có thực sự đọc nó hay không. Bảy bước này được sắp xếp theo trình tự hợp lý: bắt đầu với việc nói gì, sau đó cách nói ra sao, và cuối cùng là cách trình bày nó.
1. Tập trung vào người dùng, không phải tính năng
Đây là nguyên tắc quan trọng nhất trong việc viết ghi chú phát hành. Mỗi thay đổi được tạo ra để giải quyết một vấn đề hoặc mở khóa một khả năng cho người dùng. Hãy dẫn dắt với điều đó.
Bản năng là mô tả những gì đội ngũ của bạn đã xây dựng. Hãy kháng cự lại. Thay vào đó, hãy mô tả những gì người dùng giờ đây có thể làm (hoặc không còn phải đối phó với).
Trước: "Đã triển khai xử lý lô cho xuất dữ liệu với kích thước phần có thể cấu hình."
Sau: "Bây giờ bạn có thể xuất dữ liệu lớn mà không bị hết thời gian xử lý. Các lần xuất trước đây thất bại sau 10.000 hàng giờ nay có thể xử lý tới 500.000."
Phiên bản đầu tiên mô tả công việc kỹ thuật. Phiên bản thứ hai mô tả trải nghiệm của người dùng. Viết phiên bản thứ hai.
2. Làm cho ý định của sự thay đổi trở nên rõ ràng.
Người dùng quét qua ghi chú phát hành muốn hai điều: cái gì đã thay đổi và có ảnh hưởng đến họ hay không. Hãy làm cho cả hai câu trả lời trở nên rõ ràng trong câu đầu tiên của mỗi mục.
Sự rõ ràng rất quan trọng vì người dùng web không đọc một cách liền mạch. Họ quét. Vì vậy, hãy làm cho ghi chú phát hành của bạn dễ quét. Làm nổi bật các từ khóa quan trọng. Sử dụng chữ đậm cho tên tính năng và loại thay đổi. Đưa thông tin quan trọng nhất lên đầu mỗi dòng.
Trước: "Đã sửa lỗi và cập nhật được áp dụng."
Sau: "Chúng tôi đã sửa một lỗi gây ra sự cố không mong muốn khi chuyển đổi giữa các ứng dụng. Việc chuyển đổi ứng dụng giờ đây đã ổn định trên tất cả các thiết bị được hỗ trợ."
Phiên bản đầu tiên ngắn gọn nhưng không cung cấp thông tin gì cho người dùng. Phiên bản thứ hai vẫn súc tích nhưng trả lời các câu hỏi mà người dùng thực sự có.
3. Sử dụng ngôn ngữ đơn giản
Ghi chú phát hành có thể phục vụ nhiều mục đích khác nhau: quảng bá tính năng mới, xây dựng mối quan hệ với người dùng, giúp mọi người tìm kiếm giải pháp. Nhưng không có điều nào trong số đó hoạt động hiệu quả khi các ghi chú đầy rẫy thuật ngữ kỹ thuật mà chỉ đội ngũ kỹ thuật của bạn hiểu.
Nếu bạn không chắc rằng khán giả của mình sẽ dễ dàng hiểu được ngôn ngữ chuyên ngành, hãy giảm bớt thuật ngữ. Sử dụng cách diễn đạt đơn giản, dễ hiểu. Một bài kiểm tra tốt: đọc ghi chú phát hành cho ai đó không biết về nền tảng kỹ thuật. Nếu họ hiểu, người dùng của bạn cũng sẽ vậy.
Trước: "Chúng tôi đã triển khai khả năng sử dụng hình ảnh bitmap định dạng Graphics Interchange Format, bao gồm nén tệp, độ trong suốt, giao thoa và lưu trữ nhiều hình ảnh trong một tệp duy nhất cho dịch vụ nhắn tin của chúng tôi."
Sau: "Bây giờ bạn có thể sử dụng GIF trong dịch vụ nhắn tin của chúng tôi."
Ngôn ngữ đơn giản không phải là làm cho mọi thứ trở nên ngu ngốc. Đó là tôn trọng thời gian của người dùng.
4. Thêm hình ảnh cho những thay đổi phức tạp
Nếu ghi chú phát hành của bạn cần một lời giải thích dài, đó là dấu hiệu để thêm một hình ảnh thay vào đó. Một GIF ngắn hoặc hình chụp màn hình có chú thích cho thấy một tính năng đang hoạt động truyền đạt nhiều hơn hai đoạn mô tả cho bất kỳ thay đổi giao diện người dùng nào.
Điều này đặc biệt hữu ích cho:
Các yếu tố giao diện người dùng mới hoặc thay đổi bố cục (hiển thị trước và sau)
Quy trình làm việc mới hoặc tính năng nhiều bước (một video ghi màn hình dài 15 giây)
Các tính năng trực quan hóa dữ liệu (một ảnh chụp màn hình của đầu ra thực tế)
Hình ảnh giảm bớt gánh nặng cho người đọc và làm cho các ghi chú phát hành của bạn trở nên đáng nhớ hơn. Khi một thay đổi có tính chất trực quan, hãy thể hiện nó một cách trực quan.
5. Tổ chức để quét
Người dùng trở nên tê liệt khi được yêu cầu đọc một khối văn bản dài. Hãy giữ mọi thứ được tổ chức và phân chia với tiêu đề phụ, danh mục, danh sách gạch đầu dòng và ngắt đoạn. Phân chia các khối văn bản lớn giúp người dùng tìm ra những thay đổi nào áp dụng cho họ mà không cần đọc tất cả.
Những mô hình tổ chức tốt bao gồm:
Nhóm các thay đổi theo loại: tính năng mới, cải tiến, sửa lỗi
Sử dụng nhãn hoặc thẻ (như "Mới," "Cải tiến," "Đã sửa") để quét nhanh.
Thêm một tóm tắt ngắn ở đầu cho những người dùng chỉ muốn những điểm nổi bật.
Sử dụng các phần có thể thu gọn cho các ghi chú kỹ thuật chi tiết mà chỉ một số người dùng cần.
6. Sử dụng một mẫu và tuân theo nó
Tính nhất quán là một đặc điểm, không phải là hạn chế. Khi ghi chú phát hành của bạn tuân theo một cấu trúc dễ đoán, người dùng sẽ biết nơi tìm thông tin mà họ quan tâm. Họ sẽ dành ít thời gian để phân tích và nhiều thời gian hơn để hiểu.
Chọn một mẫu (có một cái ở phần tiếp theo mà bạn có thể sao chép), tùy chỉnh nó cho sản phẩm của bạn, và sử dụng nó mỗi lần. Điều này cũng giúp tăng tốc quá trình viết cho đội ngũ của bạn, vì cấu trúc đã được quyết định.
7. Khớp giọng điệu thương hiệu của bạn, không phải giọng điệu kỹ thuật của bạn.
Ghi chú phát hành của bạn nên nghe giống như thương hiệu của bạn, chứ không phải như một thông điệp cam kết. Nếu thương hiệu của bạn ấm áp và thân thiện, ghi chú phát hành của bạn cũng nên như vậy. Nếu thương hiệu của bạn chính xác và chuyên nghiệp, hãy phù hợp với điều đó.
Chìa khóa là chân thành mà không làm quá. Bạn có thể thêm cá tính mà không hy sinh sự rõ ràng. Một chút ấm áp có thể tạo ra sự khác biệt lớn, nhưng quảng cáo bản thân quá mức sẽ làm suy giảm lòng tin. Một hướng dẫn hữu ích: 80% nội dung nên là thông tin thật sự hữu ích, và chỉ 20% nên phản ánh vị thế hoặc giọng nói của thương hiệu.
Những điều cần tránh: "Chúng tôi ở đây để cách mạng hóa quy trình làm việc của bạn, điều mà chúng tôi đã thực hiện thành công với mỗi bản cập nhật. Bạn được chào đón. Bản sửa lỗi mới của chúng tôi bao gồm mức tiêu thụ năng lượng giảm 50%."
Sửa lỗi: Phần mềm hiện giảm tiêu thụ năng lượng của người dùng cuối xuống 50%. Một trong nhiều cách chúng tôi đang hướng tới một tương lai bền vững hơn.
Phiên bản đầu tiên thổi phồng thương hiệu và hứa hẹn quá mức trước khi đề cập đến sự thay đổi. Phiên bản thứ hai cho bạn biết cách khắc phục, sau đó thêm khía cạnh thương hiệu một cách tự nhiên.
Mẫu ghi chú phát hành
Dưới đây là mẫu ghi chú phát hành mà bạn có thể sao chép và điều chỉnh. Nó bao gồm những điều cần thiết cho hầu hết các bản cập nhật. Điều chỉnh độ sâu tùy theo phạm vi phát hành của bạn: các phiên bản lớn cần nhiều chi tiết hơn cho từng tính năng, các phiên bản nhỏ có thể nén các phần, và các bản sửa lỗi chỉ có thể bỏ qua phần "Có gì mới".
Ghi chú phát hành [Tên sản phẩm] - [Số phiên bản hoặc ngày]
Tóm tắt: [Tổng quan 1-2 câu về việc phát hành này giải quyết vấn đề gì và ai bị ảnh hưởng]
Có gì mới vậy?
- [Tên tính năng]: [Nó hoạt động như thế nào và tại sao nó quan trọng đối với người dùng]
- [Tên tính năng]: [Nó hoạt động như thế nào và tại sao điều đó quan trọng đối với người dùng]
Cải tiến
- [Điều gì đã thay đổi] - [Cách nó ảnh hưởng đến trải nghiệm của người dùng]
Sửa lỗi
- [Những gì người dùng đã trải qua trước đây] - [Những gì xảy ra bây giờ]
Các vấn đề đã biết
- [Mô tả sự cố] - [Giải pháp tạm thời hoặc thời gian nếu có sẵn]
Câu hỏi? [Liên kết đến tài liệu trợ giúp hoặc liên hệ hỗ trợ]
Cách điều chỉnh mẫu: Đối với một bản phát hành lớn với ba tính năng mới, mở rộng phần "Có gì mới" với một đoạn cho mỗi tính năng. Đối với một bản phát hành nhỏ với năm cải tiến nhỏ, bạn có thể kết hợp "Có gì mới" và "Cải tiến" thành một danh sách duy nhất. Đối với một bản phát hành chỉ có sửa lỗi, hãy bắt đầu với các bản sửa lỗi và bỏ hẳn phần tính năng. Cấu trúc nên phục vụ cho nội dung, chứ không phải ngược lại.
13 ví dụ ghi chú phát hành, được tổ chức theo những gì chúng làm tốt nhất
Các ví dụ dưới đây được tổ chức thành năm danh mục dựa trên những gì mà ghi chú phát hành của mỗi công ty làm đặc biệt tốt. Đối với mỗi ví dụ, bạn sẽ tìm thấy: công ty làm gì, ghi chú phát hành của họ đúng ở điểm nào, và một bài học cụ thể, có thể áp dụng cho riêng bạn.
Thông tin liên quan
https://learn.microsoft.com/en-us/microsoft-365/copilot/release-notes?tabs=all LÀ MỘT VÍ DỤ THỰC TẾ! https://learn.microsoft.com/en-us/sharepoint/dev/spfx/release-1.23.0 LÀ MỘT VÍ DỤ THỰC TẾ! https://slite.com/learn/release-notes https://documentero.com/templates/it-engineering/document/release-notes/ https://projectmanagers.net/7-free-release-notes-templates/ https://www.smartsheet.com/content/release-note-examples https://clickup.com/blog/how-to-write-release-notes/ https://www.releasenotes.io/ https://clickup.com/blog/release-notes-software/ https://www.launchnotes.com/blog/release-notes-examples https://www.geeksforgeeks.org/software-engineering/overview-of-software-release-note/ 13 ví dụ ghi chú phát hành (và những gì làm cho chúng hiệu quả). appcues.comThông tin và chương trình được cung cấp bởi admin@mcmassociates.io.