Tất cả chúng ta đều hiểu rằng các yêu cầu chính xác được đưa ra từ các nguồn phù hợp và được thông báo rõ ràng cho các bên liên quan bị ảnh hưởng là chìa khóa thành công của dự án phần mềm.

 

Tuy nhiên, con đường dẫn đến good requirements không dễ dàng và cũng không trực tiếp. Rất nhiều điều có thể xảy ra sự cố trong quá trình thực hiện, dẫn đến sai lầm, lãng phí nỗ lực và khiến các bên liên quan thất vọng. Bài viết này chỉ ra sáu cạm bẫy yêu cầu phổ biến và đề xuất các cách để tránh chúng.

 

Hậu quả chính của các vấn đề về yêu cầu là làm lại – làm lại những gì bạn nghĩ là đã hoàn thành – chậm phát triển hoặc sau khi phát hành. Rất ít tổ chức phần mềm đo lường mức độ nỗ lực phát triển của họ để làm lại; và thường là những con số đáng sợ.

Các nghiên cứu đã chỉ ra rằng việc làm lại có thể tiêu tốn từ 40 đến 50% tổng chi phí phát triển của bạn (Charette 2005). Chỉ riêng lỗi yêu cầu đã chiếm 70 đến 85% chi phí làm lại (Leffingwell 1997).

 

Một số công việc làm lại làm tăng thêm giá trị và cải thiện sản phẩm, nhưng làm lại quá nhiều sẽ gây lãng phí và khó chịu. Hãy tưởng tượng cuộc sống của bạn sẽ khác biệt như thế nào nếu nhóm của bạn có thể cắt giảm một nửa nỗ lực làm lại của họ! Họ có thể tạo ra những sản phẩm tốt hơn nhanh hơn và thậm chí có thể thỉnh thoảng về nhà.

Có thể tốn nhiều chi phí hơn để sửa một lỗi phát hiện muộn trong dự án hơn là sửa nó ngay sau khi tạo ra. Giả sử tốn $10 để nỗ lực tìm và sửa lỗi yêu cầu trong khi bạn vẫn đang thực hiện các yêu cầu khác. Thay vào đó, nếu bạn phát hiện ra lỗi đó trong quá trình thiết kế, bạn phải trả $10 để sửa lỗi yêu cầu, cộng với $20 hoặc $30 khác để làm lại thiết kế dựa trên yêu cầu không chính xác đó.

 

Tuy nhiên, giả sử rằng không ai phát hiện ra lỗi cho đến khi người dùng gọi gặp với một sự cố. Cái giá bạn phải trả trở nên tồi tệ hơn rất nhiều. Tùy thuộc vào loại hệ thống, chi phí để sửa chữa một lỗi yêu cầu được tìm thấy trong quá trình vận hành có thể là $500 trở lên theo quy mô này (Grady 1999; Haskins 2004). Việc ngăn chặn các lỗi yêu cầu và bắt chúng sớm rõ ràng có tác dụng thúc đẩy rất lớn trong việc giảm chi phí làm lại.

Những thiếu sót trong việc thực hiện các yêu cầu gây ra nhiều rủi ro cho sự thành công của dự án, trong đó thành công có nghĩa là cung cấp một sản phẩm đáp ứng các mong đợi về chức năng và chất lượng của người dùng với chi phí và tiến độ đã thỏa thuận.

Hãy xem làm thế nào để tránh một số bẫy đó sau đây nhé!

 

𝟏. 𝐎𝐯𝐞𝐫𝐥𝐨𝐨𝐤𝐞𝐝 𝐒𝐭𝐚𝐤𝐞𝐡𝐨𝐥𝐝𝐞𝐫𝐬 (𝐂𝐚́𝐜 𝐛𝐞̂𝐧 𝐥𝐢𝐞̂𝐧 𝐪𝐮𝐚𝐧 𝐭𝐡𝐮̛̀𝐚)

 

Các bên liên quan bao gồm bất kỳ nhóm hoặc cá nhân nào bị ảnh hưởng bởi một dự án hoặc những người có thể ảnh hưởng đến hướng đi của dự án. Một số stakeholders là khách hàng và một số khách hàng là người dùng, nhưng các dự án có thể có nhiều nhóm stakeholders tiềm năng khác, như Hình 1 chỉ ra (Wiegers và Beatty 2013).

 

 

Hầu hết các sản phẩm có nhiều nhóm người dùng có thể sử dụng các tập hợp con các tính năng khác nhau, có tần suất sử dụng khác nhau hoặc khác nhau về mức độ trải nghiệm của họ. Nếu bạn không xác định sớm các lớp người dùng quan trọng của mình, sản phẩm có thể sẽ không đáp ứng được một số nhu cầu của người dùng. Ngoài ra, hãy đảm bảo rằng mỗi lớp người dùng đều có phát biểu.

 

Ngoài những người dùng trực tiếp rõ ràng, hãy nghĩ đến nhân viên bảo trì và hỗ trợ, những người có yêu cầu riêng, cả chức năng và phi chức năng. Những người chuyển đổi dữ liệu từ một hệ thống kế thừa sẽ có các yêu cầu chuyển đổi không ảnh hưởng đến phần mềm sản phẩm cuối cùng nhưng điều đó chắc chắn ảnh hưởng đến sự thành công của giải pháp.

Một số bên liên quan khác thậm chí có thể không biết dự án tồn tại, chẳng hạn như các cơ quan chính phủ bắt buộc các tiêu chuẩn ảnh hưởng đến hệ thống của bạn. Tuy nhiên, bạn cần hiểu tầm ảnh hưởng của họ đối với dự án, đặc biệt nếu sản phẩm phải được chứng nhận để bán hoặc sử dụng.

 

𝟐. 𝐈𝐧𝐬𝐮𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭 𝐔𝐬𝐞𝐫 𝐈𝐧𝐯𝐨𝐥𝐯𝐞𝐦𝐞𝐧𝐭 (𝐒𝐮̛̣ 𝐭𝐡𝐚𝐦 𝐠𝐢𝐚 𝐤𝐡𝐨̂𝐧𝐠 đ𝐚̂̀𝐲 đ𝐮̉ 𝐜𝐮̉𝐚 𝐧𝐠𝐮̛𝐨̛̀𝐢 𝐝𝐮̀𝐧𝐠)

 

Không phải lúc nào khách hàng cũng hiểu tại sao đầu vào của họ lại rất cần thiết để phát triển các yêu cầu và đảm bảo chất lượng của họ. Các Developers có thể không nhấn mạnh sự tham gia của users, có lẽ vì họ nghĩ rằng họ đã hiểu những gì người dùng cần. Trong một số trường hợp, rất khó để tiếp cận những người thực sự sẽ sử dụng sản phẩm và những người đại diện cho người dùng không phải lúc nào cũng hiểu người dùng cuối thực sự cần gì. Sự tham gia của người dùng không đầy đủ dẫn đến các yêu cầu vi phạm muộn, tạo ra quá trình làm lại và hoàn thành chậm trễ.

 

Một rủi ro khác của việc không tham gia đầy đủ của người dùng là BA có thể không hiểu và ghi lại đúng nhu cầu thực sự của doanh nghiệp hoặc khách hàng. Đôi khi, một BA thẳng tay chỉ định những gì có vẻ là các yêu cầu “hoàn hảo” và các Developers thực hiện chúng, nhưng sau đó users không hài lòng với giải pháp. Có lẽ vấn đề đã bị hiểu nhầm hoặc thay đổi trong quá trình này. Sự tham gia liên tục với users và gia tăng các phương pháp tiếp cận có thể giảm thiểu rủi ro này.

 

𝟑. 𝐈𝐧𝐚𝐜𝐜𝐮𝐫𝐚𝐭𝐞 𝐏𝐥𝐚𝐧𝐧𝐢𝐧𝐠 (𝐋𝐚̣̂𝐩 𝐤𝐞̂́ 𝐡𝐨𝐚̣𝐜𝐡 𝐤𝐡𝐨̂𝐧𝐠 𝐜𝐡𝐢́𝐧𝐡 𝐱𝐚́𝐜)

 

“Đây là ý tưởng của tôi cho một sản phẩm mới; khi nào bạn xong việc? ” Đừng trả lời câu hỏi này cho đến khi bạn biết đủ về vấn đề. Các yêu cầu mơ hồ, kém hiểu biết dẫn đến các ước tính quá lạc quan. Những thứ đó có thể quay lại ám ảnh bạn.

 

Phỏng đoán từ đầu đến cuối của người ước tính nghe có vẻ giống như một lời cam kết với người nghe. Ước tính nỗ lực và thời gian phát triển có nghĩa là bạn cần biết đủ về quy mô của các yêu cầu được lên kế hoạch cho chu kỳ tiếp theo và năng suất hoặc tốc độ của nhóm phát triển. Các ước tính được trình bày tốt nhất dưới dạng một phạm vi, không phải một con số duy nhất.

 

𝟒. 𝐂𝐫𝐞𝐞𝐩𝐢𝐧𝐠 𝐔𝐬𝐞𝐫 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬 (𝐘𝐞̂𝐮 𝐜𝐚̂̀𝐮 đ𝐚́𝐧𝐠 𝐬𝐨̛̣ 𝐜𝐮̉𝐚 𝐧𝐠𝐮̛𝐨̛̀𝐢 𝐝𝐮̀𝐧𝐠)

 

Khi các yêu cầu phát triển trong quá trình phát triển, các dự án thường vượt quá lịch trình và ngân sách (thường quá lạc quan) của họ. Để quản lý phạm vi thay đổi , hãy bắt đầu bằng một tuyên bố rõ ràng về mục tiêu kinh doanh, tầm nhìn sản phẩm, phạm vi, giới hạn và tiêu chí thành công của dự án. Đánh giá tất cả các tính năng mới được đề xuất hoặc các thay đổi yêu cầu so với tham chiếu đó. Yêu cầu sẽ thay đổi và phát triển. Xây dựng bộ đệm dự phòng vào lịch trình để yêu cầu mới đầu tiên đi kèm không làm lệch lịch trình.

 

Các dự án Agile điều chỉnh phạm vi cho mỗi lần lặp để phù hợp với một khoảng thời gian cố định cho lần lặp. Các yêu cầu mới đi vào phần tồn đọng của công việc đang chờ xử lý và được phân bổ cho các lần lặp lại trong tương lai dựa trên mức độ ưu tiên của chúng. Chiến lược time-boxing theo thời gian này đảm bảo rằng công việc đã cam kết được hoàn thành đều đặn. Tuy nhiên, điều này dẫn đến sự không chắc chắn ở phía sau về sản phẩm sẽ bao gồm những gì và khi nào dự án được hoàn thành.

 

Quy trình thay đổi hiệu quả bao gồm phân tích tác động giúp nhóm đưa ra quyết định kinh doanh sáng suốt về những thay đổi nào cần kết hợp và chi phí liên quan về thời gian, nguồn lực hoặc sự đánh đổi tính năng. Thay đổi có thể là yếu tố quan trọng để thành công, nhưng thay đổi luôn trả giá.

 

𝟓. 𝐀𝐦𝐛𝐢𝐠𝐮𝐨𝐮𝐬 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬 (𝐘𝐞̂𝐮 𝐜𝐚̂̀𝐮 𝐤𝐡𝐨̂𝐧𝐠 𝐫𝐨̃ 𝐫𝐚̀𝐧𝐠)

 

Một triệu chứng của sự mơ hồ là người đọc có thể giải thích một câu lệnh yêu cầu theo nhiều cách. Một dấu hiệu khác là những người khác nhau khi đọc một yêu cầu sẽ giải thích nó theo những nghĩa khác nhau. Ngôn ngữ tự nhiên rất dễ bị mơ hồ.

 

Ảnh 2 (bảng) liệt kê nhiều thuật ngữ không rõ ràng về bản chất mà tốt nhất nên tránh trong các câu lệnh yêu cầu (Wiegers và Beatty 2013).

 

 

Sự mơ hồ dẫn đến kỳ vọng khác nhau của các bên liên quan khác nhau. Một số người trong số họ sau đó ngạc nhiên về bất cứ điều gì được giao. Các yêu cầu mơ hồ sẽ lãng phí thời gian khi các nhà phát triển triển khai giải pháp sai hoặc giải pháp cho vấn đề sai. Những người thử nghiệm mong đợi sản phẩm hoạt động khác với những gì mà các nhà phát triển đã xây dựng đã lãng phí thời gian để giải quyết các khác biệt.

 

Một cách để loại bỏ sự mơ hồ là nhờ những người đại diện cho các quan điểm khác nhau kiểm tra các yêu cầu (Wiegers 2002). Kiểm tra là một loại đánh giá ngang hàng chính thức của một số phần mềm có thể cung cấp được. Các bài đánh giá không chính thức trong đó người đánh giá chỉ cần tự mình đọc các yêu cầu sẽ thường không phát hiện ra sự mơ hồ. Nếu những người đánh giá khác nhau giải thích một yêu cầu theo những cách khác nhau nhưng nó có ý nghĩa đối với mỗi người trong số họ, họ sẽ không chỉ ra điều gì là mơ hồ.

 

Làm bài test theo yêu cầu theo mẫu là một cách khá hay để tiết lộ những điều còn mơ hồ.

 

𝟔. 𝐆𝐨𝐥𝐝 𝐏𝐥𝐚𝐭𝐢𝐧𝐠 (𝐌𝐚̣ 𝐯𝐚̀𝐧𝐠)

 

Gold Plating diễn ra khi nhà phát triển thêm chức năng không có trong yêu cầu – hoặc được coi là nằm ngoài phạm vi – Developers tin rằng “người dùng sẽ yêu thích.” Nếu người dùng không quan tâm đến chức năng này, thời gian thực hiện nó sẽ bị lãng phí.

 

Thay vì chỉ cần chèn các tính năng mới, các Developers và BA nên trình bày cho người ra quyết định những ý tưởng sáng tạo để họ xem xét. Các Developers nên cố gắng hướng tới sự tinh gọn và đơn giản, không vượt quá những gì các bên liên quan yêu cầu mà không có ý kiến và sự chấp thuận của họ.

 

Khách hàng đôi khi góp một kiểu gold plating khác. Họ có thể yêu cầu một số tính năng nhất định hoặc giao diện người dùng phức tạp trông hấp dẫn nhưng mang lại ít giá trị cho sản phẩm. Mọi thứ bạn xây dựng đều tốn thời gian và tiền bạc, vì vậy bạn cần tối đa hóa giá trị được giao. Để giảm thiểu rủi ro khi gold plating, bạn phải luôn biết từng yêu cầu đến từ đâu và lý do kinh doanh của nó, để mọi người biết lý do tại sao lại đưa nó vào.

 

Đảm bảo rằng những gì bạn đang chỉ định và phát triển nằm trong phạm vi của dự án. Có rất ít điểm trong việc triển khai chức năng mà khách hàng sẽ hiếm khi hoặc không bao giờ sử dụng, cũng như trong việc triển khai các phương pháp tiếp cận giao diện người dùng có thể trông kỳ lạ nhưng không cung cấp giá trị thực cho khách hàng.

 

𝟕. 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬 𝐀𝐫𝐞 𝐇𝐚𝐫𝐝! (𝐍𝐡𝐮̛̃𝐧𝐠 𝐲𝐞̂𝐮 𝐜𝐚̂̀𝐮 𝐤𝐡𝐨́)

 

Thực hiện đúng các yêu cầu là một trong những thách thức lớn nhất mà software team phải đối mặt. Tuy nhiên, nếu không có yêu cầu tốt, các nỗ lực kỹ thuật của nhóm có thể dễ dàng bị định hướng sai, dẫn đến việc làm lại phiền phức và lãng phí. Bạn sẽ không bao giờ nhận được các yêu cầu hoàn hảo hoặc đầy đủ, nhưng hầu hết các nhóm có thể hoàn thành công việc tốt hơn nếu họ đề phòng những rủi ro phổ biến này.