Một kế hoạch sản phẩm tốt là một danh sách các mục tiêu lớn mà bạn muốn đạt được trong vòng 3 - 6 tháng tới. Kế hoạch này sẽ chỉ dẫn cho nhóm của bạn (và tất cả những người khác) theo con đường đúng đắn nhất. Bạn cũng sẽ phải lên kế hoạch cho những bước tiếp theo, nghĩa là lên kế hoạch cho các design sprint (thiết kế nước rút). Cuối cùng, bạn sẽ phải định nghĩa cách làm việc giữa designer và developer. Trong bài này, tôi sẽ chia sẻ hết về những điều trên.

Một Quản lý sản phẩm trẻ tuổi kéo tôi sang một bên và nói với giọng vô cùng phấn khích. Anh ta cho tôi xem những thành quả của mình một cách đầy tự hào: một kế hoạch sản phẩm thật sự chi tiết. Đó là một trang Excel rất bài bản, với những vấn đề lớn được đánh dấu bằng màu khác, và phần thiết kế cũng như phát triển kỹ thuật của những tính năng khác nhau được ấn định vào những mốc thời gian cụ thể.

Tôi có thể thấy được niềm vui trong mắt anh ta khi mở những phần khác nhau và đi sâu hơn vào từng mục nhỏ. Và điều này thực sự làm tôi buồn. Sao mà tôi có thể nói được với cậu trai trẻ đầy nhiệt huyết này, người vừa mới nỗ lực hết mình, rằng kế hoạch của cậu ta thực sự vô giá trị?

Đơn giản là cậu trai này vừa làm những gì bạn KHÔNG nên làm với một kế hoạch phát triển sản phẩm.

Sự thật chẳng dễ chịu về kế hoạch phát triển sản phẩm

Có một sự thật chẳng mấy dễ chịu về kế hoạch phát triển sản phẩm mà rất nhiều người không hiểu được. Đó là những kế hoạch này chẳng bao giờ sống sót được trong thực tế. Khi chướng ngại đầu tiên xuất hiện, chúng sẽ chẳng còn hợp lý nữa.

Bạn có thể dễ dàng nhận thấy điều này khi mọi người đều đổ lỗi cho nhau về deadline, và một dự án trong mơ trước kia bỗng dưng trở thành địa ngục.

Vậy nên tốt nhất là đừng đặt deadline một cách cụ thể. Hãy nhớ rằng, với phương pháp Agile thì thứ duy nhất có ngày trả bài là những thứ có trong sprint hiện tại. Tất cả những thứ khác chỉ là ước đoán.

Liệt kê ra những tính năng chi tiết trong kế hoạch cũng chẳng có ý nghĩa gì. Bạn có thể quyết định những tính năng mà công ty hay người dùng cần giải quyết theo thứ tự quan trọng, nhưng thường thì bạn chẳng thể biết được tính năng nào sẽ bị ảnh hưởng trong giai đoạn khởi đầu này.

Ví dụ, nếu mục tiêu của bạn là tăng tỷ lệ chuyển đổi, thì điều này có thể ảnh hưởng đến rất nhiều phần của sản phẩm. Hãy nhớ rằng, mục tiêu của chúng ta không phải là ra mắt một tính năng đúng hạn. Mục tiêu của chúng ta là tạo ra một sản phẩm thỏa mãn nhu cầu của người dùng thực sự. Và nó không đơn giản chỉ là code ra một tính năng nào đó đúng hạn đâu.

Vậy nên hãy cẩn thận khi bạn gặp những dấu hiệu sau đây của một kế hoạch phát triển sản phẩm.

5 dấu hiệu của một kế hoạch tồi

• Liệt kê từng tính năng chi tiết
• Mọi thứ đều có deadline chính xác
• Là một kế hoạch phức tạp, với rất nhiều chi tiết
• Nhìn giống như một biểu đồ Gantt (Gantt chart)
• Các tính năng cụ thể được thiết kế và phát triển kỹ thuật gần như cùng lúc

Một kế hoạch phát triển sản phẩm tốt trông như thế nào?

Một kế hoạch phát triển sản phẩm tốt được làm nên bởi các chủ đề (theme). Một chủ đề là một mục tiêu lớn mà chúng ta muốn đạt được. Nó có thể là một mục tiêu kinh doanh, như là tăng một số lượng gì đó nhất định. Nó cũng có thể là một mục tiêu kỹ thuật, như là giảm thiểu bug khi nâng cấp hệ thống.

Và tất nhiên, nó cũng có thể là một mục tiêu định hướng người dùng, như là giải quyết một vấn đề mà nhóm mới phát hiện gần đây hoặc thiết kế một quy trình làm quen với sản phẩm theo hướng mới.

Trong kế hoạch, chúng ta sẽ sắp xếp ưu tiên những chủ đề này. Thay vì đặt ra những deadline khắt khe, chúng ta có thể sắp xếp thứ tự của chúng, kể một câu chuyện về cách chúng ta đi từ tình trạng hiện tại đến một sản phẩm mà chúng ta đang mơ ước sẽ thành hình.

Kế hoạch là một tài liệu chiến lược cấp cao. Nó nên được trình bày đơn giản, chỉ với một số chủ đề theo thứ tự nhất định. Chỉ thế thôi. Nếu làm đúng, kế hoạch sẽ có thể được sử dụng để giao tiếp giữa sản phẩm và chiến lược phát triển UX một cách dễ dàng.

Kế hoạch không phải là một thứ tĩnh tại. Nó cần được xem xét mỗi 2 - 6 tháng, tùy thuộc vào ngành và bản thân sản phẩm mà bạn đang làm. Roman Pichler đã tạo ra một biểu đồ rất hay về việc này. Tôi khuyến khích việc cập nhật kế hoạch cùng với nhóm của bạn trong các buổi workshop về UX.

Bạn có thể thấy, kế hoạch là thứ có liên quan chặt chẽ với sản phẩm. Chẳng có thứ gì gọi là Kế hoạch UX (UX roadmap). Kế hoạch nằm dưới sự định hướng của cả nhóm làm sản phẩm. Và chúng ta lên kế hoạch cho từng phần thiết kế hay phát triển kỹ thuật chỉ là để cho sprint sau mà thôi. Tuy vậy thì lên kế hoạch cũng không hề dễ dàng chút nào.

Những khó khăn khi lên kế hoạch trong khâu thiết kế

Thiết kế diễn ra từ những ngày đầu tiên, khi mọi thứ đều thay đổi rất nhanh chóng. Vì vậy việc thiết kế rất khó để dự đoán. Theo thời gian, nhóm làm việc cùng nhau và tiến gần hơn đến một bản thiết kế UI chuẩn-từng-pixel, thì mọi thứ sẽ trở nên dễ dàng hơn để ước lượng thời gian cho từng tác vụ thiết kế nhất định.

Giả sử chúng ta thiết kế một phần mềm e-mail marketing chẳng hạn. Chúng ta đã thực hiện một vài cuộc phỏng vấn với người dùng, và hóa ra là một trong số những điều khiến người dùng khó chịu là việc trình bày kết quả marketing với các bên khác. Trong giai đoạn cực sớm này, chúng ta không thể biết được làm thế nào để giải quyết vấn đề này.

Giải pháp có thể hoặc là một tính năng mới rất nhỏ trong module thống kê, hoặc chúng ta phải thiết kế lại hoàn toàn phần thống kê, hoặc thậm chí là tạo mới một sản phẩm riêng biệt để giải quyết vấn đề này. Chúng ta gần như không thể ước lượng được thời gian ta cần cho thiết kế và phát triển kỹ thuật ở thời điểm đó.

Sau khi làm và thử nghiệm một số nguyên mẫu sản phẩm và đưa ra hướng giải quyết, chúng ta mới có thể quyết định tính năng nào sẽ đưa vào phát triển tiếp. Khi chúng ta có một danh sách những tính năng, chúng ta có thể ước lượng thời gian cần cho code và design, nhưng nó cũng sẽ vẫn không chính xác, chắc chắn luôn. Trong quá trình thiết kế, chúng ta sẽ còn điều chỉnh wireframe và thử nghiệm với người dùng để giải quyết các vấn đề về tính hữu dụng, và chúng ta chẳng bao giờ biết được là cần làm những chuyện đó bao nhiêu lần cho vừa ý.

Sau khi wireframe đã sẵn sàng, tất cả đều đồng ý về chuyện nhìn và cảm (look & feel), chúng ta mới có thể ước lượng được thời gian cần để lên thiết kế UI chi tiết.

Và câu hỏi lớn ở đây là: làm thế nào để quản lý được những điều không chắc chắn này và làm thế nào để lên kế hoạch cho hoạt động thiết kế?

Cách giải quyết: sắp xếp những tác vụ rủi ro vào những luồng song song

Để giải quyết những vấn đề không chắc chắn của việc thiết kế trong giai đoạn đầu, chúng ta có thể sắp xếp chúng vào từng “luồng” riêng biệt, nơi mà quá trình khám phá sản phẩm diễn ra cùng lúc với việc thiết kế và phát triển kỹ thuật của những tính năng lớn.

Một số công ty đã lập nên nhóm Khám phá, còn một số khác thì dành thời gian của cả nhóm cho việc này. Điều này phụ thuộc khá lớn vào cấu trúc nhóm UX.

Sau khi đã khám phá xong (kết quả là một danh sách đã được đồng thuận về các tính năng sẽ giải quyết được vấn đề của người dùng), chúng ta có thể đưa những vấn đề này cho designer và developer để khởi tạo và phát triển những tính năng này. Chúng tôi gọi đó là 2 luồng Khám phá và Áp dụng.

Luồng Khám phá thì cơ bản được hoàn thiện bởi UX researcher và designer. Họ sẽ thu thập những phản hồi của người dùng bằng các phương pháp như phỏng vấn và kiểm thử ý tưởng bằng landing page, fake door test hoặc thông qua nguyên mẫu sản phẩm.

Luồng Áp dụng sẽ được hoàn thiện bởi designer, researcher và developer. Trong luồng này, designer sẽ thiết kế low-fidelity wireframe trước, kiểm thử và tinh chỉnh để loại bỏ hết những vấn đề gặp phải trong thiết kế, sau đó sẽ tiến hành thiết kế chi tiết và đưa cho dev để xây dựng kỹ thuật.

Hệ thống 2 luồng song song này sẽ đảm bảo rằng chúng ta có thể phản hồi nhanh chóng với yêu cầu của người dùng, vì ta đang liên tục khám phá sản phẩm của mình. Nhóm Khám phá sẽ chỉ đưa về những tính năng đã được kiểm định và có mô tả rõ ràng, hợp lý, từ đó nhóm Áp dụng sẽ có thể ước đoán được phần nào công việc của mình. Họ sẽ có thể lên được kế hoạch tốt hơn cho một hoặc nhiều sprint tiếp theo.

Khi sự mơ hồ của giai đoạn khám phá sản phẩm đi qua, và bạn nghĩ bạn chỉ cần thiết kế giao diện của các tính năng đó, thì bạn sẽ còn gặp khá nhiều bất ngờ ở phía trước nữa đấy. Để tránh những trường hợp này, hãy cố trả lời danh sách các câu hỏi dưới đây trước khi bạn lên kế hoạch cho sprint tiếp theo.

• Liệu những tính năng mới có ảnh hưởng đến phần thiết lập của hệ thống quản trị không?
• Có cần phải có hồ sơ người dùng (user profile) không, hay những tính năng mới có ảnh hưởng gì đến hồ sơ người dùng không?
• Có cần hiện thị trạng thái trống (khi người dùng chưa nhập thông tin) hay không?
• Có tồn tại Bảng điều khiển (dashboard) hay không?
• Có cần một hệ biểu tượng (icon) hay logo đặc trưng hay không?
• Có cần trải nghiệm thử phần nhìn và cảm (look & feel) của sản phẩm không, hay chỉ cần theo một thiết kế đã có sẵn rồi?
• Sẽ thiết kế cho nền tảng nào? Mobile? Desktop? Native hay web?
• Có biết được hết các bước của tất cả các hành động hay không? Có bước nào ẩn hoặc rẽ nhánh sang phần khác không?
• Tìm kiếm bộ ba Danh sách - Chi tiết - Chỉnh sửa. Nếu một nội dung có trang riêng, chắc chắn là sẽ có một danh sách và một chức năng chỉnh sửa nữa.
• Có cần mô tả chuyển động của các phần không?
• Có màn hình nào có rất nhiều những tương tác nặng hay không (đóng mở panel, kéo thả, … )?

Một phần quan trọng nữa mà tôi luôn lưu ý, đó là bạn không thể code và design cùng một tính năng ở cùng một thời điểm. Tin tôi đi, chúng tôi đã cố thử và nó luôn kết thúc trong loạn lạc. Hãy gửi tính năng cho developer một khi design đã hoàn chỉnh.

Designer và developer nên đồng thuận với nhau trước về cách chuyển giao văn bản thiết kế. Việc chuyển giao này không chỉ qua e-mail, mà họ nên ngồi xuống với nhau và rà lại một lượt để chắc chắn rằng mọi người đều hiểu mọi ngõ ngách của bản thiết kế. Và khi một thứ đã được phát triển, designer nên kiểm tra lại một lần nữa xem có đúng với ý tưởng thiết kế hay không.

Gọn lại, đây là những thứ bạn cần cho một kế hoạch phát triển sản phẩm:

Hãy tiến hành khám phá sản phẩm liên tục và đồng thời với những hoạt động khác để làm rõ nhu cầu của người dùng.

Tổ chức các buổi workshop chiến lược mỗi 2 - 6 tháng, nơi bạn có thể thu thập và đặt mức độ ưu tiên cho các vấn đề cần phải giải quyết.

Kết quả của buổi workshop chiến lược này nên là một văn bản đơn giản: kế hoạch chiến lược cao cấp với các chủ đề trong đó.

Hãy cho designer thời gian họ cần để tinh chỉnh nguyên mẫu. Khi lên kế hoạch từng sprint cho developer, hãy chỉ đưa cho họ các tính năng đã thiết kế và chốt xong, từ đó bạn có thể dễ dàng ước lượng thời gian thiết kế UI và phát triển kỹ thuật.

Tôi chắc rằng rất nhiều bạn nghĩ việc có một kế hoạch phát triển sản phẩm sẽ khiến đời dễ thở hơn bao nhiêu. Qua bài viết này, chúng tôi hy vọng bạn sẽ có thể làm một mẫu kế hoạch của riêng mình, thứ mà bạn có thể giở lại xem mỗi lần cuộc sống bế tắc.

Có lẽ sẽ dễ hơn nếu bạn sử dụng kế hoạch theo phương pháp cổ điển kiểu thác nước (waterfall). Nhưng phương pháp này cùng với các buổi workshop chiến lược và công tác khám phá sản phẩm, nếu không muốn nói là chắc chắn, thì hoàn toàn có thể tạo ra những giá trị kinh doanh liên tiếp cho bạn trong một thời gian dài.

Tác giả Dávid Pásztor