Những Bài Học Rút Ra về Quản Lý Yêu Cầu: Chương Trình Tàu Ngầm S-80

Chương trình tàu ngầm S-80 cho chúng ta thấy vì sao các yêu cầu, ràng buộc, thay đổi thiết kế và các bước kiểm tra xác minh cần được giữ kết nối với nhau trong các dự án phát triển sản phẩm phần cứng.

Trong phát triển sản phẩm phần cứng, một thay đổi thiết kế có thể giải quyết vấn đề trước mắt nhưng lại làm phát sinh những câu hỏi mới ở nơi khác trong hệ thống. Đó là lý do quản lý yêu cầu không chỉ là việc ghi nhận sản phẩm cần làm gì, mà còn là duy trì khả năng nhìn thấy các ràng buộc liên quan, các quyết định thiết kế và các bước kiểm tra xác minh khi thiết kế tiếp tục phát triển.

Chương trình tàu ngầm S-80 của Tây Ban Nha cho thấy rất rõ mô hình này. Trong quá trình phát triển, chương trình đã gặp một thách thức lớn về khối lượng và lực nổi. Việc thiết kế lại giúp xử lý vấn đề đó, nhưng kích thước tàu sau khi cập nhật lại tạo ra một vấn đề thực tế mới: tàu ngầm giờ đã quá dài so với cảng mà nó được dự kiến sử dụng.

Đây là một bài học có thể áp dụng cho mọi nhóm phát triển sản phẩm phần cứng - dù bạn đang chế tạo tàu ngầm hay một thiết bị điện tử: khi các yêu cầu, ràng buộc, thay đổi thiết kế và bước kiểm tra xác minh bị tách rời, các nhóm sẽ rất khó nhìn ra một thay đổi có thể ảnh hưởng thêm đến điều gì.

Những điểm chính cần nhớ

• Xung đột yêu cầu thường xuất hiện khi các ràng buộc quan trọng nằm ngoài quy trình làm việc được dùng để xem xét các thay đổi thiết kế.
• Các nhóm có thể giảm rủi ro này bằng cách liên kết các yêu cầu với các ràng buộc, quyết định thiết kế và bước kiểm tra xác minh mà chúng tác động đến.
• Một quy trình làm việc về yêu cầu có tính kết nối sẽ giúp dễ dàng hơn trong việc nhìn thấy điều gì đã thay đổi, nó ảnh hưởng đến điều gì và điều gì cần được xem xét trước khi chi phí làm lại trở nên quá lớn.

Điều gì đã xảy ra trong chương trình S-80

Tây Ban Nha khởi động chương trình S-80 để phát triển một lớp tàu ngầm mới. Trong quá trình phát triển, chương trình đã gặp phải một vấn đề nghiêm trọng về khối lượng và lực nổi. Con tàu đã trở nên nặng hơn so với kế hoạch, làm dấy lên lo ngại về việc liệu nó có còn đủ biên độ lực nổi để có thể nổi lên một cách tin cậy sau khi lặn hay không.

Thiết kế đã được điều chỉnh để xử lý vấn đề này. Một trong những thay đổi chính là kéo dài thân tàu, giúp khôi phục biên độ lực nổi cần thiết. Việc điều chỉnh đó cũng làm thay đổi kích thước vật lý của con tàu. Sau đó, tàu ngầm được cập nhật phải được rà soát lại theo cơ sở hạ tầng nơi nó sẽ hoạt động, và quá trình rà soát này đã cho thấy một vấn đề thực tế: nó không còn vừa với cảng nữa.

Vấn đề về cơ sở hạ tầng đã làm tăng thêm một lớp công việc cho một chương trình vốn đã phải trải qua một đợt thiết kế lại lớn. Cuối cùng, chương trình trở nên phức tạp hơn, mất nhiều thời gian hơn và tốn kém hơn so với dự kiến ban đầu.

Minh họa này nhắc nhở rằng mỗi lần thiết kế lại luôn kéo theo một câu hỏi nữa cần được trả lời: Còn điều gì khác bây giờ cần phải được kiểm tra?

Các nhóm phần cứng có thể học được gì từ trường hợp S-80

Phần lớn các nhóm phần cứng làm việc ở quy mô nhỏ hơn một chương trình tàu ngầm, nhưng cùng một mô hình vẫn có thể xuất hiện trong phát triển sản phẩm hằng ngày: một thay đổi thiết kế có thể ảnh hưởng đến kích thước, các yêu cầu tuân thủ hoặc các ràng buộc giao tiếp ngoài vấn đề mà nhóm đang cố gắng giải quyết ở thời điểm hiện tại.

Chỉ biết các ràng buộc đó là chưa đủ. Đây chính là lúc quản lý yêu cầu trở nên quan trọng: nó giúp các nhóm duy trì khả năng hiển thị, tính kết nối và khả năng rà soát của chúng khi thiết kế tiếp tục phát triển. Với các nhóm phần cứng, điều đó quy về ba thói quen thực tế:

Giữ các ràng buộc quan trọng luôn hiển thị rõ ràng

Các ràng buộc quan trọng không nên chỉ tồn tại trong ghi chú cuộc họp, bảng tính hay trí nhớ của ai đó. Chúng cần được ghi lại rõ ràng và, khi có thể, được diễn đạt bằng các tiêu chí đo lường được để các nhóm có thể kiểm tra chúng khi thiết kế thay đổi.

Kết nối yêu cầu với các quyết định thiết kế

Một yêu cầu sẽ hữu ích hơn khi được liên kết với khu vực hệ thống, khối, đối tượng thiết kế hoặc hoạt động kỹ thuật mà nó tác động đến. Sự kết nối đó giúp các kỹ sư hiểu vì sao một quyết định thiết kế lại quan trọng, nó hỗ trợ những yêu cầu nào và còn điều gì khác có thể bị ảnh hưởng khi thiết kế thay đổi.

Sử dụng truy xuất nguồn gốc để xem xét tác động của thay đổi

Truy xuất nguồn gốc giúp các nhóm trả lời một câu hỏi thực tế: Thay đổi này còn ảnh hưởng đến điều gì khác? Khi các yêu cầu luôn được liên kết với các quyết định thiết kế, ràng buộc, bước kiểm tra xác minh và bằng chứng, các nhóm có thể thấy điều gì đã thay đổi, điều gì vẫn còn được bao phủ và điều gì cần được xem xét trước khi chi phí làm lại trở nên quá lớn.

Quy trình làm việc về yêu cầu có tính kết nối giúp ích như thế nào

Các nhóm phần cứng cần nhiều hơn là chỉ một nơi để lưu trữ nội dung văn bản của yêu cầu. Tài liệu và bảng tính có thể ghi nhận các yêu cầu, nhưng chúng trở nên khó quản lý hơn khi độ phức tạp của dự án tăng lên và mỗi yêu cầu cần phải duy trì kết nối xuyên suốt chuỗi kỹ thuật.

Altium Requirements Portal được thiết kế để hỗ trợ quy trình làm việc đó bằng cách quản lý yêu cầu, truy xuất nguồn gốc, quyền sở hữu và xác minh trong một môi trường dùng chung. Thay vì xem các yêu cầu như những đoạn văn bản riêng lẻ, các nhóm có thể thấy điều gì đã thay đổi, nó ảnh hưởng đến điều gì, ai chịu trách nhiệm cho bước tiếp theo và yêu cầu đó sẽ được kiểm tra như thế nào.

"Tàu ngầm" trong dự án của bạn là gì?

Mọi dự án phát triển phần cứng đều có những ràng buộc dễ bị bỏ sót khi thiết kế đang thay đổi nhanh chóng. Chúng có thể liên quan đến cơ khí, điện, quy định, vận hành hoặc quy trình. Rủi ro không nằm ở chỗ các nhóm thiếu kiến thức, mà ở chỗ kiến thức quan trọng không phải lúc nào cũng được ghi nhận, kết nối và rà soát khi thiết kế thay đổi.

Đó là điều khiến trường hợp S-80 trở nên hữu ích vượt ra ngoài quy mô của nó. Mô hình tương tự có thể xuất hiện trong phát triển sản phẩm hằng ngày khi ý đồ kỹ thuật, các quyết định thiết kế và bằng chứng không được duy trì kết nối với nhau theo thời gian.

Hãy giúp việc truy vết tác động của thay đổi trở nên dễ dàng hơn với một công cụ quản lý yêu cầu mà toàn bộ nhóm của bạn đều có thể truy cập.

Bắt đầu với Requirements Portal →

Các câu hỏi thường gặp

Điều gì gây ra các vấn đề quản lý yêu cầu trong các dự án phần cứng?

Các vấn đề quản lý yêu cầu thường xuất hiện khi các yêu cầu không được kết nối với công việc thiết kế, các ràng buộc và các bước kiểm tra xác minh mà chúng tác động đến. Một yêu cầu có thể tồn tại, nhưng nếu nhóm không thể thấy nó được kết nối với điều gì, những tác động quan trọng có thể bị bỏ lỡ khi thiết kế thay đổi.

Vì sao bảng tính trở nên khó dùng cho quản lý yêu cầu?

Bảng tính có thể ghi nhận nội dung yêu cầu, nhưng chúng trở nên khó quản lý hơn khi độ phức tạp của dự án tăng lên. Các nhóm cần một cách để giữ cho các yêu cầu được kết nối với công việc thiết kế, lịch sử thay đổi, trạng thái xác minh và bằng chứng xuyên suốt chuỗi kỹ thuật.

Truy xuất nguồn gốc giúp giảm việc làm lại ở giai đoạn muộn như thế nào?

Truy xuất nguồn gốc giúp các nhóm trả lời một câu hỏi thực tế: Thay đổi này còn ảnh hưởng đến điều gì khác? Bằng cách liên kết các yêu cầu với các quyết định thiết kế, ràng buộc, bước kiểm tra xác minh và bằng chứng, các nhóm có thể thấy điều gì cần được xem xét trước khi chi phí làm lại trở nên quá lớn.