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

Cùng khám phá cách nắm bắt 5 sai lầm chết người trong quản lý requirement nhé các bạn:

Mỗi tiêu chuẩn, chứng nhận, và tổ chức quy định đều đề cập đến sự cần thiết và tầm quan trọng của việc xác định rõ requirement trong các quy trình phát triển sản phẩm.

Thật vậy, có rất nhiều nguồn dành cho requirement và có các cách thực hành 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 còn nỗ lực không chỉ trong việc viết requirement mà còn trong việc quản lý requirement và tích hợp chúng vào quy trình phát triển sản phẩm.

Những sai lầm trong quản lý requirement và các cách khắc phục chúng

Danh sách dưới đây 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ý requirement và kỹ thuật quản lý requirement.

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

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

Chúng ta đều thấy sự đấu tranh với requirement diễn ra ngay khi bắt đầu dự án. Có nhiều nguyên nhân mà thông qua đó có thể có sự khởi đầu tốt đẹp, ít nhất là không có sự thiếu hụt trong giao tiếp và sự hiểu biết giữa các bên.

Tôi đã từng tham gia vào một tổ chức để xem xét lại quy trình phát triển sản phẩm của họ, từ đó điều chỉnh sự gián đoạn giữa đội sale và đội marketing cũng như cảm nhận của họ với những gì đội kỹ thuật đang cung cấp.

Dự án đầu tiên họ kick off với quy trình mới, và kết quả hầu hết giống với những vấn đề xảy ra trước khi quy trình phát triển được xem xét. Lý do là do họ đã không điều chỉnh vấn đề gốc rễ trước, đó là: Lỗi giao tiếp.

Giải pháp đưa ra là thực hiện tài liệu pre-requirement "stakeholder needs". Đó là nơi tất cả các stakeholder có thể nhìn thấy 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 yêu cầu của các stakeholder thông qua câu chữ, chúng ta phải đo lường sự chấp thuận. Nó mô tả về những gì nhìn thấy hoặc cảm nhận thấy giống như người dùng cuối. Sau đó, chúng ta sẽ trace những mong muốn này để đo lường yêu cầu của các stakeholder.

Việc tạo ra tài liệu này trước khi requirement thực tế hoạt động sẽ giúp các stakeholder nhìn thấy cách các khái niệm ban đầu của họ trở thành requirement chính thức như thế nào.

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

Phần lớn những dự án của tôi các năm qua đều không được thực hiện.

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

Một trong những nhược điểm của giải pháp này là trong giai đoạn đầu phát triển, một vài team lập kế hoạch để chia sẻ tài nguyên hệ thống mà không thực sự trao đổi và tích hợp với các chủ sở hữu 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 trên hành lang hoặc cuộc họp ngẫu hứng giữa các bộ phận không được ghi lại hoặc truyền đạt đúng cách. Vấn đề phát sinh khi tài nguyên thay đổi, khi đội không chính thống thứ hai đã lên kế hoạch sử dụng tài nguyên đó mà không theo kịp được những thay đổi.

Đây là ví dụ đơn giản: Kỹ sư cơ khí cần một cảm biến nhiệt độ không khí ở khu vực trung tâm của hệ thống. Nhóm máy tính có một thiết bị mua sẵn dành cho khu vực đó và một trong các kỹ sư đề cập rằng nó có cảm biến.

Các "chàng trai cơ khí" điều tra và quyết định rằng nó thỏa mãn những điều họ cần, do đó họ thêm nó vào kế hoạch thiết kế của mình. Sáu tháng sau, trong thời gian giảm chi phí, thiết bị đó được thay thế và không một ai báo cho những kỹ sư cơ khí biết, và họ đã không tìm thấy nó cho đến khi thử nghiệm.

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

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

3. Thiết kế theo requirement

Một chủ đề định kỳ cho các công ty trẻ hoặc thiếu kinh nghiệm được thiết kế theo requirement.

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

Thiết kế có thể và sẽ trở thành requirement nhưng ở dạng tài liệu thiết kế và không phải là một requirement cá nhân high level.

Ví dụ: Các bên liên quan trong một tổ chức có thể chỉ định một device có màn hình cảm biến. Đây có thể là một ví dụ thiết kế theo yêu cầu. Các đặc tả hiệu năng, workflow, và môi trường yêu cầu đều có thể đưa ra quyết định cho các hệ thống điều khiển như thế này.

Tuy nhiên, trong trường hợp này, các quyết định thiết kế bị remove từ các kỹ sư bởi yêu cầu cụ thể trong tài liệu high level. Cách tốt nhất để handle những item này là phân chia những tính năng được yêu cầu thành các requirement chức năng và thiết kế.

Từ ví dụ trên, chúng ta có thể đặt câu hỏi về lý do tại sao màn hình cảm ứng được yêu cầu từ góc độ performance và đồng thời phát triển các tài liệu khái niệm cho các yêu cầu về thẩm mỹ và workflow.

Các đặc tả công nghệ sẽ chỉ dẫn các kỹ sư về hiệu suất họ cần, và khái niệm về artwork, workflow giúp giải quyết các vấn đề hơn là cảm nhận và quy trình.

4. Tránh thay đổi

Mọi tổ chức tôi đã tham gia đều thống nhất thay đổi specification sau khi cái gì đó bị sign off.

Catch-22 là những tổ chức tương tự không muốn chờ đợi tài liệu requirement toàn diện đầu tiên, do đó các tài liệu high level được viết đồng thời cùng với công việc thiết kế.

Cho dù đội của bạn giỏi đến đâu cũng không thể thiết kế và xây dựng những thứ mà bạn không thể hoặc không nói nó là gì.

Có một phim hoạt hình Dilbert cartoon tuyệt vời, ông chủ đã nói với Wally rằng anh ấy phải bắt đầu thiết kế vì họ không có thời gian viết requirement. Điều đó rất buồn cười cho đến khi đó là những gì ông chủ của bạn thực sự làm.

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

Không may, với một số loại vấn đề, không có hướng giải quyết hay cách xử lý nhanh chóng nào. Thiết lập và bảo trì traceability giữa các level đặc tả khác nhau là cách duy nhất để biết các yếu tố bị ảnh hưởng khi có điều gì đó thay đổi, và đặc biệt khi các thay đổi đó ảnh hưởng đến nhiều team.

5. Sử dụng Word và Excel

Qua nhiều năm, tôi thấy rằng hầu hết các tổ chức đều mặc định sử dụng Word và Excel để hỗ trợ quy trình requirement. Word và Excel là một cách không tốn chi phí và dễ dàng để viết requirement.

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

Tuy nhiên, rất nhanh, các phiên bản tài liệu trở thành vấn đề thực sự. Và traceability matric thường được maintain trong Excel, trở thành sự kết hợp chặt chẽ giữa các column với các tham chiếu đến các tài liệu bị ngắt kết nối. Maintain cả tài liệu Word và Excel matric là một nhiệm vụ vất vả.

Thậm chí nếu không tuân thủ tiêu chuẩn, và bạn có kế hoạch thay đổi dự án của mình, thì traceability là bắt buộc, và hệ thống quản lý requirement như Visure Requirement là cần thiết để làm một nhiệm vụ dễ dàng và giảm bớt gánh nặng.

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

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