Bài học kinh nghiệm trong Requirements Management: Các lỗi chuyển đổi đơn vị

Trong quá trình phát triển sản phẩm phần cứng, các kỹ sư chia sẻ các con số mỗi ngày. Một giá trị được chuyển từ kỹ sư vào bản vẽ, từ đặc tả sang linh kiện, hoặc từ nhóm của bạn tới nhà cung cấp. Phần lớn thời gian, việc này diễn ra ổn vì mọi người đều biết con số đó có nghĩa là gì và dùng đơn vị nào.

Rủi ro xuất hiện khi giá trị đó đi qua một điểm bàn giao, và hai bên không hiểu nó theo cùng một cách. Một bên có thể làm việc theo pound trong khi bên kia lại mong đợi kilogram. Một tài liệu có thể dùng thiết kế hệ đo lường Anh cũ, trong khi dự án mới dùng hệ mét. Con số có thể trông vẫn đúng ở cả hai phía, nhưng nó không còn dẫn tới cùng một quyết định nữa.

Ba câu chuyện kỹ thuật dưới đây cho thấy điều đó có thể xảy ra dễ dàng như thế nào:

Ba Trường Hợp, Một Mô Thức

Ba sự cố kỹ thuật trong ba thập kỷ khác nhau cho thấy cùng một vấn đề bàn giao dưới những hình thức khác nhau. Trong mỗi trường hợp, một con số được chuyển từ phần này của quy trình sang phần khác. Con số đó có vẻ đúng đối với người dùng, nhưng lại có hai hệ đo lường cùng tồn tại. Điểm bàn giao đã không làm rõ con số đó dùng đơn vị nào.

Chuyến bay 143 của Air Canada: Gimli Glider

Ví dụ đầu tiên là Gimli Glider năm 1983. Nó cho thấy điều gì đã xảy ra khi hãng hàng không Air Canada chuyển từ đơn vị hệ Anh sang hệ mét. Chuyến bay 143, một chiếc Boeing 767 bay từ Montreal tới Edmonton, là máy bay hệ mét đầu tiên của hãng.

Vào ngày hôm đó, hệ thống chỉ thị lượng nhiên liệu (FQIS) không hoạt động, nên tổ bay đo nhiên liệu bằng tay. Họ dùng giá trị khối lượng riêng 1,77 do nhân viên tiếp nhiên liệu cung cấp, là pound trên lít, tiêu chuẩn của phần còn lại trong đội bay. Nhưng chiếc 767 hệ mét cần giá trị đó theo kilogram trên lít, trong đó con số đúng là khoảng 0,8.

Máy bay cất cánh chỉ với một nửa lượng nhiên liệu mà tổ bay nghĩ là có, khiến cả hai động cơ ngừng hoạt động trong lúc bay. May mắn là các phi công đã hạ cánh an toàn.

Mars Climate Orbiter

Mười sáu năm sau, tàu Mars Climate Orbiter đã bị mất do lỗi điều hướng gây ra bởi việc không chuyển đổi đơn vị Anh sang hệ mét. Phần mềm của Lockheed Martin gửi dữ liệu lực đẩy theo pound-force giây. Phần mềm điều hướng của NASA lại mong đợi đơn vị newton-giây, khác với pound-force giây theo hệ số 4,45.

Tàu vũ trụ được thiết kế để bay theo quỹ đạo ở độ cao từ 150 đến 200 kilômét phía trên Sao Hỏa. Thay vào đó, nó hạ xuống khoảng 57 kilômét và bốc cháy trong khí quyển Sao Hỏa.

Tàu lượn Space Mountain tại Tokyo Disneyland

Năm 2003, tàu lượn Space Mountain tại Tokyo Disneyland cho thấy một vấn đề tương tự thông qua các bản vẽ thiết kế. Trò chơi này được vẽ lại từ hệ Anh sang hệ mét vào năm 1995, thay đổi đường kính trục từ 44,14 thành 45 milimét. Tuy nhiên, các bản vẽ cũ không được ngừng sử dụng, và kết quả là đã tồn tại hai bộ bản vẽ thiết kế.

Năm 2002, khi một bộ trục mới được đặt lại, đơn đặt hàng đã dựa trên phiên bản thiết kế trước năm 1995. Kết quả là các chi tiết được cung cấp có kích thước nhỏ hơn yêu cầu. Chênh lệch 0,86 milimét đó khiến khe hở ổ trục lớn hơn nhiều so với dự định. Sau nhiều tháng sử dụng, trục đã bị gãy.

Trong cả ba trường hợp, bản thân con số không hề trông đáng ngờ. Vấn đề bắt đầu khi con số đó trở thành cơ sở cho bước kỹ thuật tiếp theo, nhưng đơn vị hoặc nguồn gốc của nó lại không đủ rõ ràng.

Minh họa này là một lời nhắc rằng một giá trị có thể trông đúng với tất cả mọi người mà vẫn sai: liệu cả hai bên trong điểm bàn giao của bạn có thống nhất về đơn vị hay không?

Các Nhóm Phần Cứng Có Thể Học Được Gì Từ Những Câu Chuyện Này

Phần lớn các nhóm phần cứng không vận hành máy bay hay phóng tàu vũ trụ. Nhưng những điểm bàn giao tương tự diễn ra mỗi ngày. Một giá trị được chuyển từ yêu cầu sang bản vẽ, từ đặc tả sang linh kiện, hoặc từ nhóm của bạn tới nhà cung cấp. Ở mỗi điểm bàn giao, đơn vị phải luôn đi kèm với con số. Ba thực hành sau có thể giúp ích:

Chỉ Rõ Đơn Vị Cho Mọi Giá Trị Trong Yêu Cầu

Một con số đứng riêng là không đủ. “45” không cho người tiếp theo biết cần chế tạo hay kiểm thử cái gì. “45 mm” mang lại ý nghĩa cho con số đó. Hãy luôn giữ đơn vị nằm cạnh giá trị mỗi lần sử dụng. Đây không chỉ là chi tiết định dạng; nó là một phần của yêu cầu.

Phân Định Trách Nhiệm Tại Các Điểm Bàn Giao Kỹ Thuật

Việc nhầm lẫn đơn vị thường xảy ra khi thông tin được chuyển từ nhóm này sang nhóm khác. Một bên có thể đang làm việc theo một tài liệu tham chiếu, trong khi bên kia lại mong đợi một tài liệu khác. Điểm bàn giao đó cần có một người chịu trách nhiệm rõ ràng. Cần có người kiểm tra hệ đơn vị, định dạng dữ liệu và tài liệu nguồn trước khi giá trị được sử dụng ở các bước sau.

Giữ Cho Yêu Cầu Và Bằng Chứng Có Thể Truy Vết

Khi một giá trị thay đổi, nhóm cần xác định những gì phụ thuộc vào nó. Điều đó có nghĩa là yêu cầu, bản vẽ, linh kiện, phép thử và bằng chứng không nên tồn tại như những mảnh rời rạc. Khả năng truy vết giúp nhóm thấy được giá trị đến từ đâu, những gì đang sử dụng nó và những gì cần được xem xét khi nó thay đổi.

Cách Một Quy Trình Yêu Cầu Kết Nối Chặt Chẽ Có Thể Hỗ Trợ

Một quy trình yêu cầu tốt hơn sẽ giữ con số, đơn vị của nó, người chịu trách nhiệm và tài liệu nguồn ở gần nhau. Nó không coi giá trị đó chỉ là một con số rời rạc trong bảng tính, bản vẽ hoặc đặc tả.

Điều này đặc biệt quan trọng tại các điểm bàn giao. Khi một giá trị được chuyển từ yêu cầu sang công việc thiết kế hoặc xác minh, người tiếp theo có thể thấy giá trị đó có nghĩa gì, nó dùng đơn vị nào và nó đến từ đâu. Nếu giá trị thay đổi, nhóm cũng có thể xác định những gì cần được xem xét lại.

Altium Requirements Portal hỗ trợ kiểu quy trình này bằng cách giữ yêu cầu, quyền sở hữu, khả năng truy vết và công việc xác minh trong một môi trường dùng chung. Nó không thay thế phán đoán kỹ thuật. Nó giúp giữ cho đơn vị, người chịu trách nhiệm và bối cảnh kỹ thuật liên quan luôn hiển thị rõ trước khi một giá trị được sử dụng ở các bước sau.

Những Điểm Chính Cần Ghi Nhớ

• Nhầm lẫn đơn vị thường bắt đầu tại các điểm bàn giao, khi một giá trị được chuyển sang nhóm, tài liệu hoặc hệ thống khác mà đơn vị của nó không được làm rõ.
• Trước khi một con số dẫn dắt bước kỹ thuật tiếp theo, nhóm cần biết nó đến từ đâu và ai chịu trách nhiệm về nó.
• Khả năng truy vết giúp các nhóm thấy được những gì phụ thuộc vào một giá trị trước khi nó thay đổi hoặc được chuyển tiếp xuống các bước sau.

Mọi Con Số Trong Dự Án Của Bạn Đã Đầy Đủ Chưa?

Mỗi sự cố trong số này đều có thể phòng tránh được. Không phải bằng kỹ thuật tốt hơn, mà bằng những câu hỏi rõ ràng được đặt ra tại điểm bàn giao:

• Mọi giá trị trong yêu cầu của bạn có đi kèm đơn vị không?
• Mọi giao diện giữa các nhóm có người chịu trách nhiệm rõ ràng không?
• Đã rõ phiên bản nào của một đặc tả là phiên bản hiện hành chưa?
• Nếu có điều gì thay đổi vào ngày mai, quy trình của bạn có chỉ ra được những gì cần được xem xét lại không?

Bây giờ hãy tự đặt cho mình những câu hỏi tương tự về dự án của bạn. Nếu câu trả lời cho bất kỳ câu nào trong số này là "có lẽ", thì bạn đã biết mình nên bắt đầu từ đâu.

Giữ cho thông tin kỹ thuật quan trọng luôn rõ ràng và dễ kiểm tra tại mọi điểm bàn giao với một công cụ quản lý yêu cầu mà toàn bộ nhóm của bạn có thể sử dụng.

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

Câu Hỏi Thường Gặp

Vì Sao Lỗi Chuyển Đổi Đơn Vị Lại Xảy Ra Trong Các Dự Án Kỹ Thuật?

Những nhầm lẫn này hiếm khi xuất phát từ phép tính sai. Chúng xảy ra tại các điểm bàn giao, khi một giá trị được chuyển giữa các nhóm, công cụ hoặc tài liệu. Một bên có thể mặc định rằng giá trị đang ở một đơn vị, trong khi bên kia lại hiểu nó theo đơn vị khác. Giá trị đó vẫn có thể đúng, nhưng lại đúng cho một giả định sai.

Một Giá Trị Yêu Cầu Đầy Đủ Cần Bao Gồm Những Gì?

Một giá trị yêu cầu đầy đủ nên bao gồm con số, đơn vị và bối cảnh cần thiết để sử dụng nó đúng cách. Ví dụ, “45” là không đủ; “45 milimét” thì đủ. Nhóm cũng có thể cần biết điều kiện áp dụng giá trị đó, tài liệu nguồn và ai là người chịu trách nhiệm cho yêu cầu đó.

Khả Năng Truy Vết Giúp Giảm Sai Sót Khi Bàn Giao Như Thế Nào?

Khả năng truy vết liên kết một giá trị với mọi thứ phụ thuộc vào nó: từ yêu cầu cấp cao nhất cho tới linh kiện, phép thử và người chịu trách nhiệm đứng sau nó. Khi một giá trị thay đổi, các liên kết đó giúp việc tìm ra những gì khác có thể cần xem xét lại trở nên dễ dàng hơn. Điều này làm giảm khả năng một đặc tả cũ, một đơn vị không rõ ràng hoặc một phép thử lỗi thời tiếp tục bị dùng nhầm.