5 sai lầm chết người trong việc quản lý các requirement và cách khắc phục chúng

Tìm hiểu các cách để nắm bắt 5 sai lầm chết người trong việc quản lý các requirement (với các dẫn chứng):

Mỗi tiêu chuẩn chuyên môn, certification và regulatory organization đều đề cập đến sự cần thiết và tầm quan trọng của các requirement được xác định trong quy trình phát triển sản phẩm.

Thật vậy có rất nhiều tài liệu dành cho các requirement và các cách làm tốt nhất.

Tuy nhiên, nhiều năm kinh nghiệm đã chỉ ra rằng các công ty vẫn nỗ lực không chỉ bằng văn bản mà còn bằng việc quản lý các requirement và tích hợp chúng vào quá trình phát triển sản phẩm của họ.

Các sai lầm của việc quản lý các requirement và cách khắc phục chúng

Danh sách dưới là 5 sai lầm chết người mà chúng tôi đã quan sát được trong lĩnh vực quản lý các requirement.

Hãy cùng khám phá!!

1. Sự suy luận – sự thiếu hụt trong giao tiếp

Trong những năm qua, chúng tôi đã thấy những nỗ lực với việc khởi động các requirement ngay khi bắt đầu các dự án. Có nhiều lý do mà thông qua đó mọi thứ có thể khởi đầu tốt đẹp, ít nhất không có sự thiếu hụt nào trong giao tiếp và sự hiểu biết giữa các bên liên quan.

Tôi đã từng tham gia trong 1 tổ chức mà đã sửa đổi quy trình phát triển sản phẩm để giải quyết sự gián đoạn yêu cầu giữa team sale và marketing và cảm nhận của họ về các yêu cầu mà team kỹ thuật đang cung cấp.

Dự án đầu tiên họ khởi động với quy trình mới kết quả là các vấn đề hầu hết giống như trước khi sửa đổi quy trình phát triển của tổ chức. Điều này chỉ là vì họ đã không giải quyết vấn đề gốc lõi trước tiên: Lỗi giao tiếp.

Giải pháp là thực hiện 1 văn bản điều kiện “stakeholder needs”. Đây là nơi mà tất cả các bên liên quan có thể thấy các yêu cầu của họ bằng chính câu chữ của họ.

Bên cạnh việc nắm bắt các yêu cầu bằng chính câu chữ của các bên liên quan, chúng ta phải có 1 phương pháp chấp thuận. Đây là 1 mô tả về những gì có thể thấy và cảm nhận giống như các end user. Sau đó chúng ta theo dõi những mong muốn hoặc nhu cầu đối với các requirement của các bên liên quan có thể đánh giá được.

Việc tạo tài liệu này trước khi các requirement thực tế bắt đầu làm việc sẽ giúp các bên liên quan của chúng ta thấy các khái niệm ban đầu của họ được biên dịch vào 1 requirement cụ thể.

2. Không tận dụng các yêu cầu có liên quan

Hầu hết các dự án của tôi trong những năm qua đều không được lưu trữ.

Tất cả các kỹ sư có thể thấy toàn bộ các tài liệu của dự án nếu họ muốn và biết nơi để tìm kiếm chúng. Môi trường mở và minh bạch này được hoan nghênh, và nó cung cấp 1 bối cảnh mà trong đó các yếu tố nằm trong sơ đồ lớn của 1 dự án.

1 trong những nhược điểm của tình huống này là trong giai đoạn đầu phát triển, 1 số team lập các kế hoạch để chia sẻ các tài nguyên của hệ thống mà không thực sự trao đổi và phối hợp với các chủ sở hữu của các hệ thống con.

Thông thường chúng tôi thấy rằng đây là kết quả của các cuộc trò chuyện ngoài lề hoặc các cuộc họp giữa các bộ phận không được ghi lại hay truyền đạt đúng cách. Các vấn đề phát sinh khi các tài nguyên phải thay đổi nhưng team khác mà đã lên kế hoạch để sử dụng tài nguyên đó đã không theo kịp các thay đổi.

Đây là 1 ví dụ đơn giản: Các kỹ sư cơ khí cần 1 cảm biến nhiệt không khí trong 1 khu vực nhất định của hệ thống. Các computer group có sẵn 1 thiết bị trong khu vực đó và 1 trong những kỹ sư của họ đã nói rằng nó có các cảm biến.

Các kỹ sư cơ khí xem xét và quyết định rằng điều này đáp ứng nhu cầu của họ, do đó họ đưa nó vào các kế hoạch thiết kế của mình. 6 tháng sau, trong quá trình cắt giảm chi phí, các thiết bị được thay thế và không ai đề cập đến nó với những thợ cơ khí và họ không tìm thấy nó cho đến khi thử nghiệm.

Các quy trình có thể được thực hiện để giảm thiểu các vấn đề này và hiện có những công cụ mà cho phép bạn tích hợp các kiểm tra này trong phần mềm quản lý các requirement của bạn. Giải pháp của chúng tôi là để triển khai 1 team check chéo tất cả các requirement bạn lên kế hoạch sử dụng, mà không chỉ các yêu cầu trong hệ thống con của bạn hay khu vực trách nhiệm của bạn.

Trong ví dụ trên, nhóm cơ khí của chúng tôi sẽ gắn cờ requirement đó và nếu nó đã bị sử hay thay đổi, họ sẽ nhận được thông báo. Điểm mấu chốt là đảm bảo rằng bạn có 1 phương pháp để theo dõi các chức năng được chia sẻ hoặc bổ sung khi lỗi truyền thông có thể xảy ra.

3. Thiết kế theo các requirement

1 chủ đề thường xuyên được nhắc đến cho các công ty non trẻ hoặc thiếu kinh nghiệm là thiết kế theo các requirement.

Các team tập trung vào việc các thiết bị trông sẽ như nào chứ không phải các thiết bị cần làm gì. Mọi người thường bắt đầu chỉ ra kích thước các màn hình, số lượng nút, các workflow và các mục khác trước khi xác định nhu cầu cụ thể của thiết bị.

Các thiết kế có thể và sẽ trở thành các requirement nhưng ở dạng tài liệu thiết kế và không phải là 1 yêu cầu riêng lẻ ở các cấp độ cao.

Ví dụ, 1 số bên liên quan trong các tổ chức có thể chỉ ra rằng 1 thiết bị sẽ có 1 màn hình cảm ứng. Đây có thể là 1 ví dụ của 1 thiết kế theo các requirement. Các thông số kỹ thuật hiệu năng, quy trình làm việc, và các yêu cầu về môi trường đều có thể đóng vai trò đưa ra quyết định cho các hệ thống điều khiển giống như này.

Tuy nhiên, trong trường hợp này, những quyết định thiết kế đó được loại bỏ bởi các kỹ sư theo các requirement cụ thể trong 1 tài liệu high level. Cách tốt nhất để xử lý các mục này là chia tính năng được yêu cầu thành các functional và design requirement.

Từ ví dụ trên của chúng tôi, chúng tôi có thể đặt các câu hỏi về lý do màn hình cảm ứng được yêu cầu từ 1 góc độ hiệu năng và đồng thời phát triển các tài liệu khái niệm thiết kế cho các requirement về thẩm mỹ và workflow.

Các thông số kỹ thuật sẽ hướng dẫn các kỹ sư về hiệu năng và đó là những gì họ cần, và các khái niệm artwork & nghiên cứu các workflow giải quyết định hình các vấn đề như luồng cảm nhận và quy trình.

4. Tránh các thay đổi

Mỗi tổ chức tôi đã tham gia đều thống nhất thay đổi thông số kỹ thuật sau khi 1 thứ gì đó ngừng lại.

Điều khó khăn là các tổ chức này không muốn đợi tài liệu toàn diện cơ bản của các requirement , do đó các tài liệu high level được viết cùng lúc khi thiết kế công việc được thực hiện.

Cho dù team của bạn giỏi thế nào cũng không thể thiết kế và xây dựng thứ gì đó khi bạn không thể hoặc sẽ không nói với họ nó sẽ làm gì.

Sự thật là mọi thứ luôn luôn thay đổi trên con đường hoàn thành 1 dự án. Chúng ta nên học cách nắm lấy những thay đổi và chuẩn bị cho chúng. Nhu cầu của khách hàng sẽ thay đổi, và chúng ta sẽ học hỏi những thứ như các kỹ sư và nhà thiết kế. Tất cả những điều này cung cấp cho chúng ta nhiều thông tin và kiến thức để xây dựng 1 dự án tốt hơn.

Thật không may, đối với các loại vấn đề này, không có hướng giải quyết hay 1 cách khắc phục nhanh chóng nào cả. Thiết lập và duy trì khả năng truy tìm giữa các mức cấp độ khác nhau của các thông số kỹ thuật là cách duy nhất để biết yếu tố nào bị ảnh hưởng khi có gì đó bị thay đổi, và đặc biệt là khi những thay đổi đó ảnh hưởng đến nhiều nhóm.

5. Sử dụng word và Excel

Trong suốt nhiều năm, tôi đã thấy rằng hầu như tất cả các tổ chức mặc định để Word và Excel để hỗ trợ xử lý các requirement của họ tại 1 số điểm. Word và excel là 1 cách không tốn chi phí và dễ dàng để bắt đầu viết các requirement.

Hầu hết mọi người trong các tổ chức biết cách sử dụng các công cụ này.

Tuy nhiên, rất nhanh, các phiên bản tài liệu trở thành 1 vấn đề thực sự và các ma trận truy xuất, thường được duy trì trong excel, trở thành 1 tổ hợp các cột không thể tách rời với các tham chiếu tới các tài liệu không liền nhau. Duy trì cả các tài liệu Word và các ma trận excel đồng bộ là 1 việc vất vả.

Thậm chí không giải quyết các tuân thủ tiêu chuẩn, nếu bạn lên kế hoạch thực hiện các thay đổi tới dự án của mình (cái mà bạn nên làm), thì việc truy xuất là bắt buộc, và đây là khi 1 hệ thống quản lý các requirement như các Visure requiremnet trở thành tất yếu để làm giảm bớt các task và gánh nặng.

Các công cụ quản lý các requirement trở thành nguồn duy nhất của sự tin cậy, để giữ cho tất cả dữ liệu có thể truy cập và liên kết với nhau.

Tham khảo: https://www.softwaretestinghelp.com/mistakes-in-requirements-management/