Khi nói về dự án phần mềm, bạn đã từng xem qua cách các công ty phát triển phần mềm, công ty thiết kế dịch vụ phần mềm mô tả một dự án chưa? Sau khi đọc mô tả của họ, bạn có thể nhanh chóng hiểu được yêu cầu và bối cảnh cụ thể của dự án không?

Cách mô tả dự án phần mềm thường gặp thường liệt kê bốn điểm sau:

Giới thiệu ngành nghề của khách hàng

Khách hàng của dự án phần mềm thuộc nhiều ngành nghề khác nhau, mỗi ngành có đặc thù riêng. Để giới thiệu dự án cho người từ các ngành khác nhau, cần bắt đầu từ bối cảnh ngành. Nội dung giới thiệu bối cảnh ngành bao gồm cách ngành này kết nối với cuộc sống của con người, đối tượng bán hàng hoặc dịch vụ trên thị trường là ai? Doanh nghiệp hoặc cá nhân thuộc ngành này đóng vai trò gì? Có niềm tin hoặc đặc điểm gì? Tầm nhìn tương lai của doanh nghiệp là gì?... Để nhà phát triển phần mềm xử lý yêu cầu một cách thích hợp, việc giới thiệu ngành của khách hàng làm nền tảng giúp đội ngũ phát triển hiểu rõ quan điểm của khách hàng.

Vấn đề gặp phải trong quy trình kinh doanh (nơi phát sinh nhu cầu)

Đây là động lực lớn nhất khiến khách hàng xuất hiện, khách hàng gặp rắc rối vì tình huống nào trong môi trường làm việc của họ? Là quy trình làm việc hiện tại cần số hóa, hay hệ thống thông tin hiện tại cần tái tổ chức sau nhiều năm sử dụng, hoặc cần đưa ra các biện pháp số hóa để đáp ứng xu hướng mới của ngành? Cần hiểu khách quan và đặt mình vào hoàn cảnh của khách hàng.

Giải pháp đề xuất

Sau khi đạt được sự đồng thuận với khách hàng, công ty phần mềm đưa ra kế hoạch và thực hiện các hạng mục phù hợp với nhu cầu, và có thể áp dụng thành công vào quy trình làm việc của khách hàng.

Kết quả

So với giải pháp cũ, sau khi áp dụng giải pháp mới, đã mang lại sự khác biệt và thay đổi như thế nào cho khách hàng, ví dụ: nâng cao hiệu quả quy trình sản xuất, giảm thời gian tổng hợp thông tin, cung cấp kênh tiếp cận khách hàng mới...

Tổng hợp bốn điểm mô tả dự án phần mềm trên, có thể giúp chúng ta có cái nhìn sơ bộ về dự án. Trong quá trình thảo luận với khách hàng, quản lý dự án cũng cần đảm bảo rằng những mô tả này rõ ràng trong tâm trí chúng ta. Vì mô tả dự án phần mềm là linh hoạt, có thể ngắn gọn chỉ bằng một câu để nói lên dự án đang làm gì, hoặc dài dòng như một báo cáo mô tả nội dung dự án. Lúc này, có thể thử:

Xây dựng một "giá trị cốt lõi", để giá trị cốt lõi này có thể thiết lập phạm vi của dự án

Dự án là dự án vì nó đạt được mục tiêu cụ thể trong nguồn lực hạn chế. Tuy nhiên, trong quá trình đạt được mục tiêu cụ thể, nếu không giới hạn phạm vi, chắc chắn sẽ phát sinh các chức năng "liên quan". Sự xuất hiện của chức năng liên quan này có thể làm tăng giá trị lớn cho toàn bộ giải pháp, nhưng lại cần kéo dài thời gian phát triển, dẫn đến không thể ra mắt đúng hạn; cũng có thể không mang lại tác dụng cụ thể cho toàn bộ giải pháp.

Ví dụ:

Khách hàng muốn xây dựng một chức năng "nhấn nút khởi động, tự động thực hiện công việc theo lịch trình" cho hệ thống thông tin doanh nghiệp, trực giác có thể chỉ cần kết nối các quy trình công việc tiếp theo để thực hiện theo thứ tự, tuy nhiên, tình huống phát triển thực tế là: có thể cần thêm quyền thực thi, trạng thái thực thi lần trước, hệ thống có kết nối ổn định không... tùy thuộc vào lĩnh vực ứng dụng của hệ thống này, lúc này, khách hàng đột nhiên nói trong nhóm thảo luận: "Tôi muốn có cảm giác sống động, chuyển động khi nhấn nút khởi động."

Khi phát triển phần mềm, chúng ta thường cần thêm các phán đoán tình huống xảy ra và xem xét các logic kinh doanh liên quan khi lập kế hoạch chức năng dựa trên một câu chuyện người dùng đơn lẻ, và khi khách hàng không có ý kiến khác về khía cạnh chức năng, họ có thể chuyển sự chú ý sang màu sắc giao diện, sắp xếp, hành vi nút, chuyển trang, và bắt đầu có những yêu cầu kiên quyết, luôn muốn giao diện sống động hơn.

Trong thời gian phát triển hạn chế, khi chức năng phát triển và giao diện hệ thống mong đợi của khách hàng xung đột, phải làm gì?

Lúc này cần quay lại "giá trị cốt lõi" để xác nhận thời gian hiện có, nhân lực, sự cần thiết và ưu tiên của các chức năng liên quan. Giá trị cốt lõi thường là một khẩu hiệu ngắn gọn, giống như một câu thần chú mạnh mẽ, giúp chúng ta khi cân nhắc thêm bớt câu chuyện người dùng, đọc thầm ba lần, sẽ có câu trả lời rõ ràng trong tâm trí!

Từ ví dụ trên, khi khách hàng có yêu cầu kiên quyết, chúng ta có thể hướng dẫn thảo luận để suy nghĩ "Giao diện sống động hơn có lợi ích gì cho việc vận hành hệ thống thông tin doanh nghiệp không?" "Nếu để giao diện sống động hơn, chúng ta cần bắt đầu từ thiết kế, trong kế hoạch sẽ thêm một khoảng thời gian, có thể dẫn đến trì hoãn thời gian ra mắt, điều này có tốt không?" Sau đó, đề xuất "Nên sắp xếp thứ tự ưu tiên các yêu cầu theo 'giá trị cốt lõi' để có thể ra mắt đúng hạn trong thời gian đã định".

Dựa trên từng dự án, cùng khách hàng thảo luận và xác định "giá trị cốt lõi" phù hợp nhất

Giá trị cốt lõi của dự án giúp chúng ta dù đang thảo luận trong đội ngũ phát triển, hay phỏng vấn nhu cầu hoặc nghiệm thu với khách hàng, đều có thể như xây dựng một ngọn hải đăng, dẫn dắt chúng ta trong biển thảo luận mênh mông, không đi lệch chủ đề, quay lại trục chính của dự án để thảo luận.

Nếu hôm nay bạn đọc bài viết này và đang đau đầu vì yêu cầu của khách hàng, hãy thử liệt kê giá trị cốt lõi của dự án để thuyết phục bản thân và khách hàng nhé!