[Cơ bản] Hiểu về việc viết mô tả sản phẩm cho Product Owner

4 phút

Đây là một phần trong quá trình training một bạn Developer về cách hiểu và chuẩn bị tài liệu mô tả sản phẩm để làm việc với nhóm. Rất tiếc là quá trình training sau đó đã ngưng vì nhiều lý do khác nhau. Nay mình muốn chia sẻ lại tài liệu này dù không nhiều.

Điều kiện cần:

  • Hiểu và áp dụng Agile/Scrum hoặc Kanban trong quá trình làm việc.
  • Bạn đóng vai trò là Product Owner ở một vài dự án.
  • Có hiểu biết về UX ở mức cơ bản.
  • Có hiểu biết về wireframe, mockups.
  • Có học/tự học và biết cách viết use case sao cho dễ hiểu.

 

Thời điểm mình chuẩn bị tài liệu này vào ngày 17/8/2015. Về căn bản kiến thức vẫn nằm trên một khung sườn nhất định, tại thời điểm hiện tại có thể có nhiều thay đổi (hơn 2 năm) về cách viết nhưng chung quy có những quy tắc mà những người làm/ở vị trí Product Owner (PO) cần phải nắm.

Đối tượng đọc

Dĩ nhiên là Product Owner. Khi nhắc đến hai chữ này thì mặc nhiên bạn phải hiểu là bạn đang làm trong môi trường Agile/Scrum. Thực tế chúng ta có thể tách việc viết này ra và không liên quan gì đến Agile/Scrum nhưng rõ ràng làm phần mềm, phát triển web/app hay gì đó thì chúng ta thường hay sử dụng các phương pháp này, và đó là điều sớm muộn cũng phải gặp.

Mình xin được nhắc lại vài ý chính trong vai trò của một Product Owner:

  • Đóng vai trò như một khách hàng, hoặc đại diện cho Khách hàng (và cả khách hàng riêng của mình).
  • Có tầm nhìn về sản phẩm, ngắn hạn lẫn dài hạn.
  • Có hiểu biết về UX ở mức cơ bản.
  • Có hiểu biết về wireframe, mockups.
  • Có học/tự học và biết cách viết use case sao cho dễ hiểu.

Yêu cầu là gì?

Yêu cầu tức là…yêu cầu 😁. Thực tế từ yêu cầu này còn chung chung và chưa nói lên được điều mình muốn nói. Trong giới hạn bài viết thì Yêu cầu có nghĩa là: Điều cần phải đạt được trong một việc nào đó. Việc nào đó ở đây chính là việc làm của các Designer, Developer đối với sản phẩm/dự án.

Để viết cho các đối tượng Developer đọc thì chúng ta phải hiểu rằng cách nghĩ và tư duy của Developer thường rất khác và mang tính đặc thù. Công việc của họ là khi nhận yêu cầu, họ có xu hướng suy nghĩ tới các giải pháp kỹ thuật để xử lý vấn đề trước. Nói cách khác, cách họ nghĩ cũng là một dạng ngôn ngữ của riêng họ.

Vì vậy thử thách của chúng ta ở đây đó là làm sao Kết nối được các yêu cầu này với các cách nghĩ khác nhau của Developer. Trong mọi trường hợp, cách nghĩ của Developer sẽ tập trung quanh việc làm thế nào để tính năng này chạy được. Đây là một dạng Yêu cầu về chức năng (Functional Requirements). Có vẻ dễ hiểu 😁.

Trong bài viết này chúng ta sẽ bắt gặp 2 loại yêu cầu: Yêu cầu về chức năng (Functional Requirements) và Yêu cầu về kinh doanh, nghiệp vụ (Business Requirements). Riêng em Business Requirements này có vẻ khó nhằn 🏄🏽.

 

 

Yêu cầu chức năng (Functional Requirements)

Yêu cầu chức năng

Đối với các bạn Developers điều này rất dễ dàng, ở khía cạnh nhận thông tin, đọc và thực hiện công việc. Một số ví dụ mình có thể kể ra tại đây như: Thiết kế một tính năng giúp khách hàng đặt hàng sản phẩm, điền thông tin mua hàng và bấm nút Thanh toán, Thiết kế tính năng Report giúp Sales Manager có thể lọc thông tin theo ngày/tháng/năm và có thể xuất thông tin ra dạng PDF.

Để hiểu rõ hơn yêu cầu loại này, mình sẽ lấy một ví dụ kinh điển, đó là thiết kế một hộp sữa. Yêu cầu chức năng của nó có thể có yếu tố cơ bản sau: Thiết kế một hộp sữa (chưa cần nhãn hiệu, chưa cần hoàn thiện hình ảnh, bao bì) có khả năng chứa chất lỏng, và tất nhiên không được để rò rỉ chất lỏng.

Tại sao lại là Chất lỏng mà không phải là Sữa? Bạn có thấy lạ không? 🍼

Không hề lạ đâu. Chính vì mình yêu cầu một hộp sữa phải có chức năng cơ bản là chứa chất lỏng trước, còn chuyện chứa Sữa hay gì khác thì nó thuộc vào các yếu tố đặc thù khác liên quan đến Business Requirements bên dưới.

Bây giờ có một câu hỏi nhỏ cho bạn: Bạn hãy nghỉ tới cảm giác khi bạn cầm một hộp sữa ở siêu thị, ứng với vài nhãn hiệu khác nhau. Sau khi tưởng tượng hoặc nhớ lại cảm giác đó, mời bạn đọc tiếp phần dưới.

Yêu cầu phi (không bao gồm) chức năng

Phi chức năng (Non-functional requirements) thì tức là…không bao gồm các yêu cầu có chức năng nào đó. Thực ra bạn cũng không cần hiểu quá nhiều đến định nghĩa của loại yêu cầu này. Về cơ bản loại yêu cầu này liên quan đến Cảm giác của người dùng cuối, hay nói cách khác là Sự hài lòng của khách hàng.

Trong ví dụ hộp sữa trên, bạn có thể nhớ được bao nhiêu cảm giác khi bạn cầm hộp sữa, mở cái nắp hoặc xé cái miệng hộp ra và đưa lên miệng uống?

Giờ mình sẽ lấy tiếp một ví dụ khác để minh họa, bạn có nhớ tới cái mũ cối màu vàng ở trong công trường xây dựng không?

Với dạng mũ này, yêu cầu phi chức năng của nó phải nhắm tới các cảm giác về an toàn, tin cậy của người sử dụng (các công nhân, kỹ sư, sếp đi tham quan). Chính vì vậy mình viết ví dụ cho loại yêu cầu này như hình trên: Chịu được áp lực tối đa 700kg/cm2 và không được vỡ. Nghe có vẻ dễ hiểu hơn phải không? 😹.

Trong dạng yêu cầu này nó còn có 2 yếu tố quan trọng cần ghi nhớ: Đó là độ tin cậy của chức năng, và khả năng chịu đựng/phản hồi của chức năng đó, thông qua các chỉ số tính toán nghiệp vụ.

Quá trình nó diễn ra như thế nào?

OK giờ bạn đã hiểu các dạng yêu cầu căn bản cần có của sản phẩm/dự án là thế nào rồi. Trong phần này chúng ta sẽ tìm hiểu qua cách các loại thông tin này được chuẩn bị và dịch chuyển như thế nào.

Một cách vắn tắt, chúng ta viết/nhận các Yêu cầu về kinh doanh/nghiệp vụ (Business Requirements), trải qua quá trình làm việc, phân tích với các đối tượng liên quan để có thể viết ra các Yêu cầu chức năng/phi chức năng cần thiết (Functional Requirements).

Liệu như vậy có đủ không?

Câu trả lời: Chưa đủ hoặc Đủ. Đủ nếu team bạn làm dự án nhỏ, cần 1-2 tuần là xong, thậm chí nếu làm dự án cỡ 1-2 tháng vẫn Đủ, với điều kiện bạn quản lý ít dự án/sản phẩm. Miễn là trong tầm kiểm soát và bạn có khả năng Nhớ đủ.

Tuy nhiên mình không khuyến khích cách làm này. Thay vào đó, từ quá trình chuyển hoá các Yêu cầu nghiệp vụ sang Yêu cầu chức năng, chúng ta sẽ có thêm 1 loại yêu cầu liên quan đến người dùng cuối, gọi là User Requirements.

Trong thực tế công việc của mình trước đây và bây giờ, mình vẫn hay viết dưới dạng User Stories (trong Scrum). Một số trường hợp cụ thể thì mình sẽ viết theo cách khác, miễn đôi bên đều hiểu 😁.

Thực tế trong cách làm này, có 2 rủi ro có khả năng xảy ra, nếu chúng ta xác định sai bản chất vấn đề từ đầu thì khả năng khúc cuối (Functional Requirements) sẽ bị ảnh hưởng ghê gớm, và nếu vấn đề ban đầu xác định đúng, nhưng khúc cuối lại thêm vào những giải pháp không phù hợp thì lại càng chết nữa. Mời bạn xem tiếp hai hình bên dưới sẽ rõ (click vào để xem độ phân giải cao nhất).

Ví dụ minh họa

Cuối bài viết mình sẽ sử dụng 2 hình chụp từ 1 dự án thật trước đây của mình. Một hình mô tả về User Story và một hình về wireframe cơ bản.

Như vậy trong bài viết này bạn đã hiểu được các vấn đề cơ bản trong việc viết các Yêu cầu về sản phẩm/dự án để làm việc. Bạn có thể bắt gặp nhiều cái tên khác nhau tuỳ vào nơi bạn làm việc, chung quy vẫn là những điểm cơ bản mình nêu ra bên trên, việc áp dụng vào thực tế tuỳ vào quá trình làm việc và kinh nghiệm của chúng ta. Mình hy vọng bài viết này sẽ có ích cho một số bạn.

 

Quoc Huy Tran Written by:

I do digital product management. I grew up in Danang and moved to Ho Chi Minh City in 2003 where I've enjoyed the tech/startup scene since. I'm a minimalist in lifestyle. I'm passionate about technology, startups, design, football and basketball. For now I focus on building Web App/App products. I have 6+ years of tech startup experience and believe in the MVP approach of shipping early and often.