Hình 1: Tài liệu FSD đảm bảo dự án phát triển phần mềm đi đúng hướng

FSD (Functional Specification Document) - Thông số kỹ thuật chức năng tài liệu, là bộ tài liệu hỗ trợ quản lí, phát triển phần mềm hạn chế những nhầm lẫn hay đi lệch hướng của dự án. FSD giúp bạn tạo ra một sản phẩm được người dùng yêu thích. Hãy cùng MangoAds tìm hiểu FSD là gì và phương pháp sử dụng FSD hiệu quả.

Điều quan trọng nhất của mọi dự án là giảm thiểu được rủi ro. Việc giảm thiểu mọi vấn đề tiềm ẩn không chỉ đảm bảo quá trình design và phát triển nội dung chiến lược sản phẩm diễn ra suôn sẻ, mà còn mang lại lợi ích cho các bên liên quan, tăng hiệu suất đáng kể.

Một phương pháp hiệu quả để giảm thiểu rủi ro, đảm bảo quá trình thiết kế UX, đồng thời đạt được teamwork hiệu quả là sử dụng tài liệu FSD. Tài liệu này đóng vai trò như "kim chỉ nam" cho toàn bộ dự án của bạn.

FSD là gì?

 Hình 2: Khái niệm tài liệu đặc điểm kỹ thuật chức năng

Tài liệu FSD gồm nội dung phần bàn giao của designer với nhà phát triển, cùng với các tài liệu quan trọng khác như: công cụ tạo mẫu hình ảnh, CSS, thông số kỹ thuật thiết kế và tài liệu nguyên mẫu.

Các tài liệu FSD được thiết kế theo cách báo cáo cho những nhà phát triển những gì họ sẽ làm, và kèm theo lý do cho những công việc ấy. FSD mô tả chính xác cách tính năng được đặt ra để giải quyết một số vấn đề nhất định cho người dùng. Những vấn đề này xuất hiện trong quá trình nghiên cứu về đặc điểm người dùng dựa trên yêu cầu của khách đưa ra.

Hiểu cách đơn giản, FSD là tổng hợp cách mà phần mềm hoạt động nhìn trên quan điểm của người sử dụng, đồng thời là công cụ chia sẻ, kết nối giữa nhà phát triển và người sử dụng.

FSD gồm những gì?

Tùy thuộc vào công ty, loại hình, quy mô của dự án và khách hàng, các tài liệu FSD có thể chứa một hoặc nhiều mục sau:

Các bên liên quan

Dưới mục các bên liên quan, bạn sẽ đặt tên và mô tả công việc của những người tham gia vào dự án.

Phê duyệt

Trong danh mục phê duyệt sẽ có tất cả các tính năng đã cung cấp cho khách hàng và các bên liên quan khác, chẳng hạn như người quản lý sản phẩm.

Dự án và phạm vi

Phạm vi của dự án sẽ gồm một bản tóm tắt về các yêu cầu, những đặc điểm kỹ thuật, những mục quan trọng như vấn đề và giải pháp.

Rủi ro và giả định

Đối với phần rủi ro và giả định, sẽ gồm bất kỳ rủi ro nào mà dự án có thể phải đối mặt: về mặt kỹ thuật, thời gian và tiền bạc. Hiểu đơn giản rủi ro chính là những thứ có thể tác động đến thiết kế chức năng của sản phẩm.

Trường hợp sử dụng

Trường hợp sử dụng là tổng hợp các tình huống người dùng gặp phải và cách sản phẩm của bạn giúp họ giải quyết vấn đề đó. Bạn có thể phân tích những trường hợp này thành các kịch bản người dùng, và luồng người dùng thông qua mô tả, sử dụng sơ đồ, từng giai đoạn trong quá trình sử dụng tính năng.

Thông số kỹ thuật yêu cầu

Thông số kỹ thuật yêu cầu là các tính năng mà sản phẩm cần phải có để cải thiện trải nghiệm người dùng, và giúp giải quyết các mục tiêu kinh doanh của doanh nghiệp.

Tổng quan về giải pháp

Giải pháp sẽ gồm những gì bạn đề xuất để giải quyết vấn đề (sơ đồ website, luồng người dùng, v.v.).

 Hình 3: Sơ đồ website

Cấu hình hệ thống

Tại đây, bạn sẽ liệt kê chi tiết các bước cần thiết để định cấu hình sản phẩm trong tương lai. Ví dụ: Mục này có thể là cách để tạo ra tài khoản người dùng.

Thông số kỹ thuật phi chức năng

Các thông số kỹ thuật phi chức năng trình bày chi tiết các đặc điểm chung của một hệ thống. Phần này thiên về mô tả hình thức, khả năng sử dụng, mức độ trực quan của sản phẩm, đường cong học tập và thời gian để hoàn thành một số nhiệm vụ.

Báo cáo lỗi và xử lý ngoại lệ

Tại đây, bạn sẽ chỉ định cách sản phẩm xử lý các lỗi do người dùng, cũng như cách mà sản phẩm hoạt động khi người dùng mắc phải “lỗi” thay vì chỉ đưa ra một quy trình thay thế.

Hệ thống Tiếp nhận – Phân phối – Xử lý – Theo dõi – Quản lý các yêu cầu của khách hàng

Ticketing system requirement là nơi thực hiện để xử lý bất kỳ lỗi hoặc sự cố nào xuất hiện trong và sau giai đoạn phát triển.

FSD dành cho ai?

Các tài liệu đặc tả chức năng chủ yếu dành cho các lập trình viên - những người viết mã để cung cấp giải pháp tối ưu cho người dùng.

 Hình 4: Đối tượng muốn nhắm tới

Tuy nhiên, tài liệu FSD phải được chia sẻ với mọi người trong nhóm, bao gồm cả khách hàng. Lưu ý, FSD nên là một nguồn duy nhất được chia sẻ trong suốt quá trình phát triển sản phẩm. FSD phải là tài liệu hướng dẫn, đồng thời là "chất keo kết dính" các phần dự án với nhau.

FSD nên sử dụng ngôn ngữ đơn giản kết hợp với sơ đồ giúp các lập trình viên dễ dàng hình dung các giải pháp liên quan đến phần mềm trước khi bắt tay vào code. Việc lập trình một hệ thống phần mềm mà không có tài liệu này trong tay thường sẽ gặp vấn đề về mã.

Ai sẽ viết FSD?

Đó là 1 người hoặc 1 nhóm các thành viên của dự án. Thông thường, người quản lý sản phẩm soạn thảo các tài liệu đặc tả chức năng trong công ty cho người dùng, khách hàng và các bên liên quan khác của dự án. Bằng cách cùng với các thành viên của các bộ phận khác để viết tài liệu đặc điểm chức năng. Trong quá trình viết FSD, các bên liên quan sẽ trao đổi và thống nhất các thông tin quan trọng trong dự án, đồng thời tự điều chỉnh tốc độ soạn thảo để đưa ra bản FSD sớm, chính xác và cụ thể nhất.

Lợi ích không thể phủ nhận của tài liệu FSD

Giảm thiểu rủi ro

Tài liệu đặc tả chức năng của bạn, đóng vai trò như một lộ trình cho các lập trình viên. Việc viết một phần mềm với mã mà không có kế hoạch hướng dẫn rõ ràng sẽ dẫn tới phải chỉnh sửa nhiều lần, đi sai hướng dự án và ảnh hưởng đến tiến độ.

Trên thực tế, hầu hết lập trình viên sẽ không bao giờ viết mã mà không có kế hoạch trước.

 

 Hình 6: Những yêu cầu liên quan đến đặc điểm kỹ thuật chức năng

Joel Spolsky cho rằng nếu không có tài liệu đặc tả chức năng thì bạn sẽ phải dành ra rất nhiều thời gian cho việc viết mã. Hậu quả ảnh hưởng đến hiệu quả, và chất lượng code, đồng thời khiến việc sửa lỗi sau này trở nên khó khăn hơn.

Tính huống xấu nhất là bạn phải bỏ những sản phẩm không có sự liên kết vì nó không giúp ích gì cả.

Tăng cường giao tiếp tránh "design by committee"

"Design by committee" là một thuật ngữ ám chỉ một dự án có nhiều designer tham gia nhưng không có kế hoạch hoặc tầm nhìn thống nhất.

Việc xây dựng tài liệu FSD sẽ giúp loại bỏ những giả định cá nhân đối với các tính năng sản phẩm, giúp bạn có thể tạo ra tính năng tối ưu giải quyết các vấn đề thực sự của người dùng.

Khi quy trình thu thập yêu cầu và đặc tả chức năng hoàn thành, bạn sẽ thấy rằng mọi thứ chạy trơn tru hơn nhiều. Mọi người sẽ biết những gì họ đang làm, và sẽ hoạt động từ cùng một nguồn đáng tin cậy (source of truth), tiết kiệm thời gian trao đổi giữa các bộ phận khác nhau.

Tăng hiệu quả

Vai trò và nhiệm vụ của các bên liên quan, và từng người tham gia dự án sẽ được xác định cụ thể nhờ đó giảm thiểu rủi ro, tăng hiệu quả thực hiện dự án.

Tránh tính năng không cần thiết

Cuối cùng, sở hữu một tài liệu thông số kỹ thuật chức năng ngay từ đầu, với tất cả các tính năng cần thiết để giải quyết cho người dùng sẽ giúp ngăn chặn sự phát triển những tính năng phức tạp, không mang lại lợi ích gì.

Hình 6: Những tính năng được xác định ngay từ đầu

Đồng thời, các tài liệu FSD giúp ngăn chặn việc thay đổi thiết kế mà bạn không mong muốn (chẳng hạn như thay đổi đột ngột do khách hàng, hoặc do các bên liên quan khác đề xuất). Nghĩa là nếu bạn làm đúng tài liệu thông số kỹ thuật chức năng của mình, tài liệu này giúp đưa ra câu trả lời toàn diện cho câu hỏi đối với vấn đề của người dùng, và cung cấp giải pháp thích hợp.

Cách xác định thông số kỹ thuật chức năng

Thu thập yêu cầu

Thu thập yêu cầu bằng cách lắng nghe khách hàng và thực hiện các nghiên cứu người dùng. Ở giai đoạn này, bạn sẽ viết ra rất nhiều thông tin. Để quản lý tất cả thông tin này, bạn có thể sử dụng công cụ thu thập yêu cầu.

Sau khi nguyên mẫu hoàn tất, bạn có thể bắt đầu vòng thử nghiệm người dùng đầu tiên để kiểm tra những giả định ban đầu của bạn. và khách hàng. Gồm mọi thứ về luồng người dùng, mô hình tinh thần của người dùng, và cách họ sử dụng phần mềm. Tuy nhiên, quan trọng nhất là bạn có thể kiểm tra xem các tính năng này có thực sự hữu ích cho khách hàng của bạn hay không.

Nếu bạn đã thử nghiệm xong các giả định, hãy bắt đầu viết tài liệu đặc tả chức năng và để các lập trình viên có thể viết mã sản phẩm cuối cùng.

Làm việc với các thành viên quan trọng trong nhóm

Đừng cố gắng tạo riêng một tài liệu đặc tả chức năng. Thay vào đó, nếu có thể bạn hãy cố gắng kết hợp với ít nhất một người từ mỗi bộ phận để tham gia vào quá trình phát triển sản phẩm, bao gồm cả khách hàng.

Cùng nhau thực hiện là cách để hình thành các tài liệu đặc tả chức năng, thay vì làm việc phong cách "silo".

Sử dụng phần mềm dễ dàng theo dõi các thay đổi

Nhiều tài liệu đặc tả chức năng được viết bằng Microsoft Word, tuy nhiên, Google Documents có xu hướng cho phép kiểm soát các phiên bản thay đổi thông qua nhiều lần chỉnh sửa tốt hơn. Việc theo dõi các thay đổi rất quan trọng trong quá trình phát triển sản phẩm.

Thông thường, các lập trình viên hay phàn nàn về việc kiểm soát các phiên bản lộn xộn trong tài liệu Word, cũng như việc khó nắm bắt thời điểm các phiên bản được chỉnh sửa. Tuy nhiên, với Google Documents, các lập trình viên có thể theo dõi các thay đổi đối với tài liệu nhờ tính năng đồng bộ hóa trên đám mây của nó.

Sử dụng ngôn ngữ dễ hiểu

Hầu hết, tài liệu "đặc điểm chức năng" của bạn sẽ được viết bằng ngôn ngữ dễ hiểu. Bởi việc thảo luận về các tính năng, và thiết kế các giải pháp của sản phẩm một cách dễ hiểu sẽ giúp việc thực hiện và sửa đổi những ý tưởng đó nhanh chóng hơn.

 Hình 7: Ngôn ngữ được dùng

Đây là lý do chính tại sao các tài liệu "đặc điểm chức năng" tồn tại. Ngôn ngữ thuần túy và sơ đồ giúp mọi thứ rõ ràng hơn ngay từ đầu. Các lập trình viên bắt đầu làm việc mà không có tài liệu này trong tay thường gặp sự cố sau này với việc viết mã.

Tóm lại, tài liệu FSD không nên lạm dụng thuật ngữ chuyên môn, hoặc ngôn ngữ lập trình khó hiểu mà chỉ nên mô tả nhiều giải pháp khác nhau cho một vấn đề cần được giải quyết với người dùng.

Tiết kiệm thời gian - Sử dụng mẫu

Thực tế, sử dụng mẫu tài liệu "đặc tả chức năng "rất phổ biến. Dưới đây là một số ví dụ tài liệu "đặc tả chức năng" mà bạn có thể tải xuống và điền vào ngay lập tức.

Hình 8: Sử dụng mẫu

Những mẫu này đã có sẵn mục lục, nhiều mẫu đi kèm với tất cả các phần, và tiêu đề mà bạn cần. Từ đây, bạn chỉ việc chỉnh sửa từng thông tin liên quan từ dự án của mình. Hầu hết chúng còn có thể được copy, và dán vào công cụ xử lý văn bản yêu thích của bạn.

Tạo các trường hợp sử dụng và tình huống cho người dùng

Như chúng tôi đã đề cập ở trên, bạn sẽ cần chuẩn bị sẵn một số trường hợp sử dụng để thêm vào tài liệu đặc tả chức năng của mình. Đây là cơ sở lý luận cho từng tính năng và đưa ra một số ngữ cảnh về cách tính năng hoạt động. Không cần phải là một trường hợp phức tạp, chỉ cần trường hợp làm nổi bật vấn đề mà tính năng sẽ giải quyết. Hãy tưởng tượng 1 trường hợp sử dụng ứng dụng cho thuê xe hơi:

“Người dùng đến một bãi đậu xe chỉ để phát hiện ra chiếc xe họ đặt không có ở đó. Họ kiểm tra đặt chỗ trên ứng dụng của chúng tôi và cho họ biết chiếc xe vẫn chưa được người dùng trước trả lại và đưa cho họ một chiếc xe khác trong bãi đậu xe với mức giá giảm. Sau đó, người dùng có thể chọn chấp nhận hoặc từ chối phương tiện đó”.

Tạo luồng người dùng

Luồng người dùng sẽ hiển thị các trường hợp người dùng và các tình huống sử dụng sản phẩm. Đối với phần này, bạn nên có sơ đồ các màn hình khác nhau của mô hình hoặc nguyên mẫu để biết cách người dùng sẽ tuỳ chỉnh qua ứng dụng của bạn.

 Hình 9: Luồng người dùng

Trong các luồng này, bạn nên đảm bảo có các luồng thay thế và luồng ngoại lệ.

Ví dụ như website đặt xe. Các luồng thay thế chỉ ra các cách khác nhau mà người dùng có thể đến màn hình hiển thị không có xe - có thể thông qua cách chạm vào thông báo hoặc bằng cách mở ứng dụng và tuỳ chỉnh đến đặt chỗ. Một luồng ngoại lệ sẽ là nơi người dùng redirect đến phần không chính xác của ứng dụng, chẳng hạn như "đặt trước phần xe mới".

Chỉ định tình trạng bài post của sản phẩm

Tình trạng bài post sẽ cho biết trạng thái hệ thống của ứng dụng sau khi load xong mục. Trong trường hợp của ứng dụng cho thuê xe mà chúng tôi đã đề cập ở trên, điều kiện đăng của sản phẩm sẽ phụ thuộc vào việc người dùng có chọn phương tiện mới hay không. Nếu họ chọn, bộ hẹn giờ thuê sẽ bắt đầu. Nếu không, người dùng có thể bị quay lại màn hình đặt chỗ.

Link đến nguyên mẫu, CSS và nội dung

Tài liệu thông số kỹ thuật chức năng là nơi bạn nên có một link đến mô hình hoặc nguyên mẫu, đến thư viện nội dung được chia sẻ của bạn. Bất kỳ phân phối bổ sung nào cũng sẽ hỗ trợ các nhà phát triển, chẳng hạn như bảng CSS, khoảng cách phần tử, phần đệm, và mã màu.

Xác định thời gian biểu để thử nghiệm người dùng, và giới thiệu sản phẩm

Bạn có thể đưa vào một dòng thời gian, hoặc lộ trình thiết lập khi hoạt động thử nghiệm người dùng.

Ví dụ: Sau mỗi thiết kế tính năng, bạn có thể chỉ định thời điểm bạn sẽ đạt đến giai đoạn MVP của sản phẩm mà bạn sẽ sử dụng với những người dùng đầu tiên.

 Hình 10: Thời gian biểu

Cuối cùng, khi các lập trình viên đã mã hóa tất cả các thông số kỹ thuật của tính năng, thì bạn đã có được sản phẩm hoàn thiện. Tuy nhiên, sẽ có một số "phạm vi" không hay cho các lần lặp lại tiếp theo trong tương lai dưới dạng tính năng, phiên bản mới và bản cập nhật.

Trong trường hợp này, chu kỳ chỉ được lặp lại, và bạn sẽ yêu cầu hoàn toàn mới và tạo ra một tài liệu đặc tả tính năng mới.

Tổng kết

Tài liệu FSD đóng một vai trò rất quan trọng không chỉ trong giai đoạn làm việc với đối tác mà còn cả với nội bộ. Góp phần giúp nội dung chiến lược sản phẩm của doanh nghiệp hoàn thiện. Tức là trong làm việc nhóm, và cả cá nhân mỗi người trong chúng ta cũng cần có tài liệu kỹ thuật chức năng. Chúc các bạn thành công và đón xem một số mẫu tài liệu kỹ thuật chức năng trên thực tiễn để có cái nhìn trực quan hơn về tài liệu này nhé!