SRS trong dự án E-commerce: Tài liệu gốc định hình cả sản phẩm

Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Healthcare

Trong thế giới phát triển phần mềm hiện nay, có một “bí kíp gốc” quyết định tới 70% sự thành công của dự án, đặc biệt trong các dự án E-commerce vốn phức tạp và nhiều stakeholder: đó chính là SRS – Software Requirements Specification.

Nói cách khác, SRS chính là “bản vẽ kiến trúc” cho cả hệ thống, nơi tất cả yêu cầu, quy trình nghiệp vụ, và ràng buộc kỹ thuật được gom lại, làm rõ và chuẩn hóa. Nhưng thực tế, nhiều công ty tại Việt Nam – kể cả doanh nghiệp thương mại điện tử – lại xem nhẹ tài liệu này. Hệ quả là dự án đi vào bế tắc, trễ deadline, hoặc hệ thống ra đời nhưng không đáp ứng được nhu cầu thật sự của người dùng.

SRS là gì và vì sao nó quan trọng trong E-commerce?

SRS (Software Requirements Specification) là tài liệu mô tả chi tiết:

• Mục tiêu của hệ thống (tại sao cần làm dự án này).
• Yêu cầu nghiệp vụ (business requirements).
• Yêu cầu chức năng và phi chức năng (functional & non-functional requirements).
• Use case, flow nghiệp vụ, wireframe, ERD… thể hiện rõ cách hệ thống vận hành.

Trong một dự án E-commerce, độ phức tạp cao hơn nhiều so với một ứng dụng nội bộ thông thường. Lý do là hệ thống E-commerce thường có:

• Nhiều module chồng chéo: product catalog, order management, payment gateway, CRM, marketing tools…
• Nhiều nhóm stakeholder khác nhau: khách hàng, nhân viên bán hàng, quản lý kho, kế toán, marketing, IT team, đối tác thanh toán.
• Quy trình nghiệp vụ thay đổi nhanh: hôm nay chạy flash sale, mai lại mở loyalty program, ngày kia phải tích hợp ví điện tử mới.

Nếu không có SRS, tất cả những yêu cầu này sẽ tồn tại trong… email, file Excel rời rạc, hoặc tệ hơn là trong đầu stakeholder. Và như vậy, rủi ro “hiểu nhầm” gần như chắc chắn xảy ra.

Ví dụ thực tế: trong một dự án E-commerce mình từng tham gia, team dev hiểu nhầm yêu cầu “cho phép khách hàng đổi trả sản phẩm” thành “đổi size trong 7 ngày”, trong khi business thật sự muốn cả refund về tài khoản ngân hàng. → Kết quả: hệ thống phải chỉnh sửa sau khi đã go-live, mất thêm 3 tuần và hơn 200 triệu đồng chi phí cơ hội. Chỉ vì… thiếu một bản SRS chuẩn ngay từ đầu.

Vai trò của BA trong việc “gom – chuẩn hóa – chuyển đổi” yêu cầu

Nếu ví SRS là “bản vẽ kiến trúc”, thì Business Analyst chính là người thiết kế bản vẽ đó. Vai trò của BA trong dự án E-commerce xoay quanh 3 từ khóa:

Thu thập yêu cầu (Elicitation)

BA phải phỏng vấn stakeholder, quan sát, phân tích hệ thống cũ, benchmark thị trường.

Trong E-commerce, BA thường phải làm việc với nhiều nhóm: từ team marketing (muốn tracking campaign), đến kho vận (muốn tối ưu picking – packing), và cả khách hàng (muốn trải nghiệm mượt mà khi checkout).

Chuẩn hóa (Analysis & Documentation)

Yêu cầu từ stakeholder thường mơ hồ: “checkout phải nhanh”, “website phải đẹp”, “tích hợp cổng thanh toán như Tiki

BA phải dịch ngôn ngữ này thành yêu cầu chuẩn hóa: “thời gian load page checkout < 2 giây”, “cổng thanh toán hỗ trợ Napas, MoMo, ZaloPay”, “UI theo chuẩn responsive trên desktop, mobile”.

Chuyển đổi thành deliverable (Specification)

BA cần viết tài liệu SRS với đầy đủ use case, diagram, flow, non-functional requirements.

Đây là cơ sở để Dev, QA, PM, và stakeholder thống nhất: “chúng ta đang cùng nói về một sản phẩm”.

Trong E-commerce, nơi vòng đời yêu cầu luôn thay đổi, BA lại càng quan trọng. Nếu không có BA, hoặc có BA nhưng không viết SRS, dự án giống như xây nhà mà không có bản thiết kế – kết quả dễ “sập” bất kỳ lúc nào.

Vì sao nhiều doanh nghiệp Việt Nam bỏ qua SRS?

Thẳng thắn mà nói, nhiều doanh nghiệp Việt Nam hiện nay không có văn hóa viết SRS. Lý do thường nghe là:

“Làm Agile thì không cần tài liệu, chỉ cần user story trên Jira là đủ.”

“Khách hàng thay đổi liên tục, viết SRS tốn thời gian, chưa kịp dùng đã lỗi thời.”

“PM/Dev hiểu yêu cầu rồi, viết ra chỉ mất công.”

Kết quả:

• Hiểu nhầm yêu cầu → Tính năng dev ra nhưng không ai dùng.
• Không có baseline để nghiệm thu → tranh cãi “đây không phải cái tôi muốn”.
• Khó onboarding nhân sự mới → dev/QA mới vào không hiểu hệ thống vì không có tài liệu gốc.
• Tốn kém chi phí chỉnh sửa → theo nghiên cứu của IEEE, chi phí fix bug giai đoạn vận hành có thể cao gấp 100 lần so với fix ngay từ giai đoạn requirement. Đặc biệt trong E-commerce, hậu quả này càng nặng nề. Một lỗi ở module payment có thể làm mất doanh thu trực tiếp. Một tính năng marketing campaign sai có thể làm thất bại cả mùa sale.

Bài học từ thực tế dự án E-commerce

Trong một dự án triển khai E-commerce cho thương hiệu thời trang Hàn Quốc tại Việt Nam, ban đầu team chọn cách “làm nhanh – ra MVP sớm”, không có SRS chi tiết. Sau 3 tháng, hệ thống có website, có app, nhưng khi khách hàng thực sự sử dụng, hàng loạt vấn đề phát sinh:

• Tích hợp cổng thanh toán chỉ chạy trên web, không chạy trên app.
• Tính năng voucher không cho phép kết hợp nhiều chương trình cùng lúc.
• Dashboard của quản lý bán hàng thiếu KPI về conversion rate – cái mà team marketing cần nhất.

Khi nhìn lại, tất cả vấn đề này đều bắt nguồn từ việc không có SRS chuẩn hóa yêu cầu ngay từ đầu. Team buộc phải quay lại viết SRS, tái phát triển một số module, mất thêm 2 tháng và chi phí đội lên 30%.

SRS không phải giấy tờ, mà là bản đồ sống của dự án

Nhiều người nghĩ SRS là “paperwork”, nhưng thực tế, nó là bản đồ sống định hướng toàn bộ dự án E-commerce. Không có nó, dự án giống như con tàu ra khơi mà không có hải đồ – có thể đi nhanh, nhưng rất dễ mắc cạn.

Với vai trò của một IT BA, mình luôn tin rằng:

SRS là deliverable quan trọng nhất của giai đoạn requirement.

Một bản SRS chuẩn có thể tiết kiệm cho doanh nghiệp hàng trăm triệu, thậm chí hàng tỷ đồng chi phí “sửa sai”.

Trong E-commerce – nơi mọi thứ thay đổi từng ngày – SRS càng cần được viết kỹ, để vừa làm baseline, vừa làm tài liệu đào tạo, vừa làm cơ sở cho các lần mở rộng sau.

Và có lẽ, thông điệp lớn nhất mình muốn gửi tới anh em BA, PM, và cả doanh nghiệp:

Đừng bao giờ coi nhẹ SRS. Bởi một dự án E-commerce thành công bắt đầu từ một bản SRS chuẩn.