Trước tiên chúng ta hãy cùng tìm hiểu xem ticket là gì. Ticket là biểu mẫu yêu cầu gửi cho nhà phát triển. Khi bạn viết nội dung gửi đi là “hãy làm chức năng này chức năng kia” lúc đó nhà phát triển sẽ bắt đầu triển nội dung thông qua cơ sở này.
Ticket là trung gian tiếp nối giữa kết quả mà bạn muốn và kết quả được thực hiện. Nội dung của ticket viết tốt bao nhiêu thì chất lượng của quá trình phát triển và chất lượng kết quả theo đó cũng trở nên khác nhau. Con người là động vật cho dù có dùng chung một từ đi nữa vẫn sẽ nghĩ ra những điều hoàn toàn khác nhau nên quan trọng là tất cả đều tạo ra cùng một suy nghĩ. Vì thế bạn nên viết ticket thật rõ ràng.
1. Nguyên tắc cơ bản
Ticket gần giống như tạo đơn đặt hàng. Trọng tâm ở đây là sự ngắn gọn và rõ ràng. Hãy chú ý để nội dung không bị chồng chéo vào nhau và giải thích dài dòng không có ý nghĩa. Khi nhìn câu chữ dài quá trước tiên là thấy chán đọc rồi.
> Trước khi sửa: Cần update để luôn duy trì trạng thái online liên kết của server
> Sau khi sửa: Update để server luôn được duy trì ở trạng thái online
Trường hợp số lượng yêu cầu trở nên quá dài hãy chia ticket thành nhiều phần. Khi có nhiều việc đa dạng thì việc hiểu không chỉ khó khăn mà cả quá trình kiểm tra code cũng trở nên phức tạp hơn. Nếu có thể nên duy trì sự đơn giản bằng cách gói gọn thành nguyên tắc ‘1 ticket = 1 thay đổi ‘.
2. Tạo tiêu đề
Tiêu đề ticket phải rõ ràng. Nó phải cụ thể ở mức độ dẫu đọc tiêu đề thôi thì người khác cũng cảm giác đại khái được phải thay đổi phần nào của code đó( đồng thời phải ngắn gọn. Đúng là hơi khó nhỉ). Sự mạch lạc trong giao tiếp giữa mọi người với nhau là quan trọng. Càng nắm bắt được tính mạch lạc nhanh thì tâm trạng của người đọc càng trở nên thoải mái. Đầu bếp nổi tiếng Baek Jung Won cũng có câu nói tương đồng như thế này “ Bảng hiệu nhà hàng bắt buộc phải trực quan”.
> Trước khi sửa: Update trang trang Đăng ký thành viên(‘ Update cái gì nhỉ? Màu sắc tiêu đề? Vị trí button? Field nhập dữ liệu? Tỷ lệ trang? Không thì lật hết lên?)
> Sau khi đổi: Thay đổi vị trí button trang Đăng ký thành viên(‘ công việc sẽ làm là thay đổi vị trí button’)
Tiêu đề phải cẩn thận để đồng nhất với sắc thái và thực tế nội dung. Bạn phải cho người khác cảm giác an tâm rằng bạn đang theo đúng suy nghĩ của bản thân. Tạo rõ tiêu đề thì nhà phát triển cũng hiểu hơn và sau này lúc tìm kiếm cũng dễ thấy.
3. Nguyên văn nội dung
Giờ chúng ta hãy cùng tìm hiểu nội dung cơ bản khi tạo ticket. Thực ra không phải nhất định chọn đúng theo hình thức nào. Mà để nhà phát triển dễ hiểu và có thể theo đúng với công việc tiến hành có thể theo bất cứ hình thức nào. Tuy là hình thức tự do nhưng nếu bạn không biết bắt đầu từ đâu hãy thử bắt đầu từ việc sao chép hình thức ở dưới đây. Sau đó thay đổi cho đúng với tiến trình ở công ty bạn.
Tình huống (Motivation)
Não bộ con người thường phản ứng nhạy với câu hỏi tại sao. Một người qua đường đưa cho bạn 1000$ phản ứng đầu tiên xuất hiện là “sao lại cho tôi?” thay vì “oh yeah!”. Lập trình cũng như vậy. Những thắc mắc như “ Tại sao lại bỏ chức năng này này vào?” phải được giải quyết sớm để đẩy nhanh tốc độ. Khi biết tình huống trình bày bạn có thể suy nghĩ ra cách tốt hơn so với cách được viết trên tài liệu yêu cầu và lúc phải thay đổi code ở liên kết khác bạn có thể nhanh hơn trong việc đưa ra quyết định về cách thay đổi.
> Ví dụ: Để giảm tỷ lệ thoát ra của những người dùng thử dịch vụ lần đầu
Trạng thái hiện tại( Status Quo)
Khi đã giải thích xong tại sao phải phát triển tiếp theo đến thứ tự mô tả trạng thái hiện tại. Ý kiến của người viết nên chi tiết và truyền đạt một cách thực tế.
> Ví dụ:
- Khi nhấn button ‘Dùng thử dịch vụ’ thì chuyển sang trang Đăng ký thành viên
- Tỷ lệ tiếp tục đăng ký thực tế trên trang Đăng ký thành viên chưa đến 10%
Tài liệu yêu cầu(Requirement)
Đây là nội dung yêu cầu thay đổi. Tài liệu yêu cầu bắt buộc phải cụ thể. Yêu cầu như “ Hãy thay đổi sao cho gọn hơn” không thể tiến hành được. Nhà phát triển cần biết chi tiết về What để tập trung vào How.
> Ví dụ:
- Khi nhấp button ‘Dùng thử dịch vụ’ sẽ chạy vào trang demo thay vì trang Đăng ký thành viên( để trải nghiệm thử không có Đăng ký thành viên)
- Tạo button ‘Đăng ký’ trên đầu trang demo phía bên phải (nếu kèm theo ví dụ screenshot sẽ tốt hơn)
- Chèn pixel theo dõi của button ‘đăng ký’ (theo dõi tỷ lệ người dùng qua bước trải nghiệm sau đăng ký)
Tình huống đạt yêu cầu (Acceptance Scenario)
Mô tả kết quả sẽ như thế nào khi được phát triển theo các yêu cầu. Điều này giúp ích trong kiểm tra xem quá trình phát triển có diễn ra tốt hay không.
> Ví dụ:
- Nhấp button ‘ Dùng thử dịch vụ’ trên homepage
Chạy trang demo
Có thể trải nghiệm tự do dịch vụ ở trang demo.
Nhìn thấy button ‘Đăng ký’ trên đầu trang page demo phía bên phải.
Khi nhấp button ‘Đăng ký’ chuyển sang page Đăng ký thành viên.
- Những người dùng sau khi trải nghiệm KPI dashboard có thể kiểm tra tỷ lệ qua bước đăng ký
4. Tóm gọn nguyên văn
Tóm gọn câu chữ giúp khả năng đọc có thể tăng lên đáng kể. Nội dung dù có tốt thế nào nếu nhìn thoáng qua khó nhận biết được thì khả năng truyền tải sẽ giảm xuống.
Bảng
Trường hợp đính kèm data mẫu thay vì viết ra nên hiển thị qua bảng sẽ tốt hơn. Như câu ‘Don’t tell but show(đừng chỉ nói bằng lời hãy cho thấy)’ con người nhìn vào một bức tranh sẽ có phản ứng tích cực hơn. Những dòng giải thích dài hãy tạo vào trong một bảng. Như vậy bạn có thể nhìn thấy ngay được tính liên kết trong đó.
Ký tự mở đầu
Tuy nội dung không nhất thiết đều tạo ra bằng bảng nhưng khi hiển thị mục lục của cái gì đó hãy kèm ký tự mở đầu vào. Tùy theo mục đích mà bạn có thể đặt dấu chấm, số, chữ cái hay kanata.
- Dấu chấm: khi danh sách các hạng mục nằm ngang
- Number: nhận biết thứ tự
- Alphabets/ kanata: khi hiển thị các tùy chọn
Định dạng văn bản
Dạo gần đây có nhiều chương trình biên tập dùng cú pháp markdown mặc định. Nếu dùng đúng cách khả năng hiện thị càng được nâng cao hơn.
- Điều chỉnh kích thước phông chữ để tiêu đề, tiêu đề phụ, văn bản được tách biệt
- Các keyword liên quan về kỹ thuật nên kết hợp bằng dấu (‘) (ví dụ: thay đổi yêu cầu máy chủ theo phương thức ‘HTTPS’).
- Màu sắc nên duy trì là đen trắng trừ những trường hợp đặc biệt. ( khi quá nhiều màu sẽ dễ gây nhầm lẫn)
- Các link liên quan nên gom lại ở một nơi để việc đọc thuận tiện hơn là bỏ giữa những đoạn văn bản.
Ticket đọc dễ hiểu sẽ làm giảm chi phí giao tiếp. Trong quá trình phát triển nó có thể ngăn chặn nhiều tình huống hiểu lầm sẽ xảy ra, tính năng thiếu và các cuộc họp vô ích. Sẽ rất hữu ích nếu bạn viết trong khi kiểm tra xem ý kiến của bạn cũng như các chi tiết phát triển có được bao quát trong ticket hay không.
Tổng hợp
- Nội dung ticket trọng tâm là tính ngắn gọn và rõ ràng.
- Hãy duy trì sự đơn giản bằng ‘1 ticket = 1 thay đổi’.
- Tiêu đề ticket nên ngắn gọn và mang tính cụ thể.
- Ticket phải bao gồm tình huống, trạng thái hiện tại, yêu cầu, tình huống đạt yêu cầu.
- Hãy làm tăng khả năng hiển thị bằng bảng, ký tự mở đầu, định dạng văn bản.
This article is translated from an IT information site called yozmIT and Metacoders commits not to use this article for any commercial purposes
The topic: 쉽게 읽히는 티켓 쓰는 법
