1. Product Specs là gì?

Product Specs (chỉ dẫn sản phẩm) là tài liệu liệt kê những yêu cầu thiết yếu, các yếu tố ảnh hưởng đến xây dựng và phát triển sản phẩm.

Viết Product Specs đặc biệt quan trọng vì một bản Product Spec chất lượng giúp team giao tiếp hiệu quả, định hướng trước và rõ ràng những yêu cầu nhất định về sản phẩm, từ đó giảm rủi ro nảy sinh những vấn đề liên quan đến sản phẩm trong quá trình thực thi, tiết kiệm thời gian giải quyết những vấn đề ấy.

Hãy thử đặt mình vào tình huống như sau:

Bạn là PM và có một ticket/story/roadmap với nội dung như sau:

Thêm live chat ở giai đoạn checkout để tăng conversion rate:
Conversion rate ở checkout hiện đang là 18% nhưng tiêu chuẩn chung trên thị trường là 30%. Test tính năng live chat khi khách hàng check out để xem có cải thiện được không.
Bên Customer Ops sẽ cho mượn một người.

Thời gian là vàng là bạc nên bạn làm luôn mà không cần spec:

1. Bạn trao đổi với team khi họp sprint về việc này
2. Bạn chọn 1 bên cung cấp giải pháp live chat
3. Bạn cập nhật ticket để yêu cầu 1 dev đóng thêm 1 tí Javascript vào
4. Bạn họp với bên Support để đảm bảo là họ nắm

Bam! Live chat có ngay ai cần spec nữa? Tất nhiên là nếu bạn là một startup nhỏ thì ảnh hưởng ít hơn, nhưng nếu công ty bạn có một kích cỡ nhất định rồi thì việc giải quyết vấn đề phát sinh về sau còn tốt nhiều thời gian và tài nguyên hơn, chẳng hạn như:

• Dev đánh dấu là done nhưng bạn chợt nhận ra họ không hỗ trợ live chat trên mobile → Toang. Mobile là kênh chiến lược của sản phẩm
• Designer dành mấy ngày liền để design animation cho live chat → Đây chỉ là test nhưng mà các bên liên quan không nắm được điều này
• Sau khi test được 1 tuần thì Business Intelligent báo là họ không viết report được vì không đủ metrics → Test lại từ đầu

Đây là một ví dụ đơn giản nên có vẻ không phải là vấn đề gì lớn lắm nếu không có spec, nhưng phải giải quyết những vấn đề phát sinh đột xuất sẽ ảnh hưởng tới tiến độ công việc và kế hoạch khác. Còn nếu là một dự án lớn thì bạn chắc cũng có thể dễ dàng hình dung được ảnh hưởng khi có vấn đề phát sinh đột xuất.

2. Product Specs cần có những nội dung gì?

1. Vấn đề (Problem):
   Nêu vấn đề mà bạn đang muốn giải quyết, đặc biệt là tại sao vấn đề đó nên được giải quyết đi kèm với những dẫn chứng, số liệu cụ thể.
2. Các mục tiêu có thể đo lường được (Measurable Goals):
   Cam kết những mục tiêu mà team cần đạt được. Mục tiêu cần rõ ràng, cụ thể để sau có thể đánh giá được mục tiêu đó có đạt được hay không.
3. Hoàn cảnh của vấn đề (Context):
   Cung cấp thêm dẫn chứng để người nghe đồng thuận với kế hoạch của bạn bằng những giả thiết, ví dụ thực tế, số liệu, v,v
4. Giải pháp chi tiết (Detailed Solution):
   Kế hoạch của bạn cần đủ chi tiết để cả team có thể dễ dàng thực hiện theo – như thể bạn đang viết code cho bộ não con người chạy vậy.
5. Tiến độ (Timeline):
   Liệt kê những mốc thời gian mà cả team cho là quan trọng. Ban đầu, phần này có thể chưa rõ ràng lắm, nhưng nó cần được hoàn thiện qua nhiều lần họp.

3. Các bước để viết một bản Product Spec

Tùy vào quy mô công ty, sản phẩm, dự án mà thời gian có thể khác nhau, nhưng về cơ bản thì bạn cũng có thể viết một bản Product Spec theo tỉ lệ thời gian như bên dưới:

B1: Viết dàn ý (1-2 tiếng):

Viết xuống các ý chính mà bạn nghĩ ra

B2: Thực hiện vài cuộc họp 1-1 30 phút (1-4 tiếng):

Mục đích của phần này là để bạn xem lại những giả thiết mình đặt ra và cải thiện bản kế hoạch. Cuộc họp này nên ít người nhất có thể, lý tưởng nhất là 1-1. Ví dụ, bạn có thể họp với 1 người bên tài chính hay 1 người bên kỹ thuật, v.v.

B3: Viết và chỉnh sửa spec (0.5-3 ngày):

Tổng hợp lại các nội dung mà bạn đã nghĩ ra và kiểm chứng với người khác một cách khoa học. Khi đã có bản nháp, hãy đọc và sửa đi sửa lại nó nhiều lần. Bạn nên chỉnh sửa sao cho spec ngắn gọn, súc tích. Thường spec có thể được viết trong khoảng 0.5-1 ngày, với các dự án lớn cũng có thể mất 2-3 ngày.

B4: Công khai spec và lên lịch họp để đánh giá spec (15 phút):

Gửi spec qua email cho các bên liên quan đến dự án. Sau đó, lên lịch họp khoảng 1 tiếng với những người chủ chốt: những người sẽ thực hiện dự án, và những người có quyền duyệt dự án.

B5: Đánh giá spec (1 tiếng):

Bắt đầu buổi họp bằng cách hỏi xem ai chưa đọc kỹ spec. Thường có thể có 1-2 người chưa đọc kỹ thì bạn có thể dành khoảng 10 phút cho những người ấy đọc còn những người khác có thể nghỉ. Mục tiêu của buổi họp là bạn lấy được sự đồng thuận từ nhà đầu tư và cam kết thực hiện kế hoạch từ các thành viên. Bạn có thể cần chỉnh sửa spec và lặp lại bước này từ những gì bạn học được.

B6: Sau buổi đánh giá, gửi bản cập nhật và soạn thảo các đầu việc (1-2 tiếng):

Gửi email bản spec đã được chỉnh sửa sau buổi đánh giá, các đầu việc cùng thời gian dự tính mà bạn sẽ cập nhật tiếp về tình hình dự án. Thông thường, sau product spec, bước tiếp theo là bên kỹ thuật có thể viết tech spec (chỉ dẫn kỹ thuật), nhưng không phải lúc nào cũng cần tech spec.

4. Một số tips để viết một bản Product Spec hiệu quả

a. Không để bản spec quá dài:

Viết ngắn gọn, xúc tích, cô đọng những thông tin cần thiết nhất

b. Dùng từ và cách trình bày đơn giản, khoa học:

Không dùng những từ hoa mỹ. Dùng các gạch đầu dòng và in đậm các đề mục, thông tin quan trọng. Ngoài ra, hãy viết với văn phong thoải mái, thú vị và thậm chí có thể là hài hước nữa. Có thể sử dụng hình ảnh, biểu đồ, v.v. Mục đích cuối cùng là để product spec của bạn dễ đọc nhất có thể.

c. Bắt đầu viết spec sớm:

Bạn nên bắt đầu viết spec khoảng 2-3 tuần trước khi team dev bắt đầu phát triển sản phẩm để có đủ thời gian review, có được sự thống nhất của các bộ phận và hoàn thiện bản spec.

d. Đặt mình vào vị trí của dev (cũng như các vị trí khác liên quan đến quá trình phát triển sản phẩm):

Thường dev bắt đầu viết code, mọi người bắt đầu xắn tay vào làm thì vấn đề mới nảy sinh. Nhưng bạn cũng có thể ngăn chặn tình trạng này bằng cách đặt mình vào vị trí của các thành viên để nghĩ xem thực tế cần những gì để phát triển được sản phẩm và chuẩn bị xử lý những vấn đề đó từ đầu.

e. Hướng product spec theo tầm nhìn:

Spec không phải chỉ để mô tả, định hình việc phát triển tính năng mới mà còn là để nêu lên tổng thể tại sao cần phát triển tính năng ấy cũng như hướng đi sắp tới của công ty. Hãy chỉ ra dự án này ảnh hưởng gì đến định hướng của công ty và những dự định tiếp theo sau dự án.

f. Hãy đảm bảo những người liên quan đến dự án đều đọc spec:

Đây là một cách để kiểm tra xem bạn có đang viết một spec tốt, không quá dài, khó hiểu hay đơn giản là chọn đúng đối tượng liên quan hay không. Xem lại bước 5 để biết một tip đảm bảo những người liên quan đã đọc spec.

g. Xin feedback từ team về spec:

Hỏi team xem bạn có thiếu chi tiết gì, vấn đề dễ nảy sinh trong tương lai gì không hay bạn có đang phân bổ thời gian, tiến độ hợp lý hay không, v.v