Jun 26, 2022

Change Requests là gì? Những điều các Software Business Analysts cần biết

Thuật ngữ “Change Request” trong ngành công nghiệp phần mềm có thể cắt ngang các ngành (hoặc khu vực địa lý). Nhiều đến mức thuật ngữ này đã trở thành một phần không thể thiếu trong thế giới IT Services và ngay cả trong các công ty sản phẩm phần mềm. Nó là giá trị kiểm tra tầm quan trọng của thuật ngữ này một cách chi tiết.

Change Request là bất kỳ sự thay đổi nào so với ban đầu

1. Change Requests là gì?

Change Requests (CR) hay yêu cầu thay đổi về cơ bản là bất kỳ thay đổi nào trong tập hợp các yêu cầu đã ký ban đầu. Vì vậy, thông thường trong triển khai mô hình thác nước, giai đoạn yêu cầu đảm bảo rằng tất cả các yêu cầu (tính năng hoặc chức năng hay chức năng và phi chức năng) được thống nhất và ghi lại trước khi bắt đầu phát triển.

Sau đó, bất kỳ phạm vi mới nào do khách hàng mang lại hoặc yêu cầu đều trở thành một yêu cầu thay đổi. Có một chi phí bổ sung liên quan đến việc thực hiện một yêu cầu thay đổi.

Ngay cả trong mô hình agile, mặc dù có sự linh hoạt trong việc thực hiện dự án nhưng các nhà cung cấp vẫn đảm bảo rằng một nhóm các yêu cầu cấp cao được thảo luận và thống nhất.

Cách thức làm việc lặp đi lặp lại đảm bảo rằng khách hàng để mắt đến sản phẩm khi sản phẩm đang phát triển và có thể đề xuất các chỉnh sửa hoặc căn chỉnh. Tuy nhiên, không nhà cung cấp nào có thể làm việc với các yêu cầu hoàn toàn linh hoạt. Nó không khả thi từ quan điểm lập ngân sách.

Vì vậy, những gì xảy ra trong các tình huống này là một “Change Request”.

2. Quy trình của Change Request

Các yêu cầu thay đổi có thể gây tranh cãi theo mọi nghĩa:

Khách hàng và nhà cung cấp phải đồng ý rằng yêu cầu được đề cập thực sự là một yêu cầu thay đổi chứ không phải là một yêu cầu ngầm đã được đồng ý.
Phải có một thỏa thuận về ước tính và mức độ ưu tiên của yêu cầu thay đổi. Không ai muốn các yêu cầu thay đổi ít ưu tiên hơn làm trật bánh dự án. Nhóm phát triển muốn đánh giá những thay đổi kỹ thuật cần thiết để thực hiện nó nếu được xác định ở giai đoạn muộn. Chi phí thực hiện các yêu cầu thay đổi phải được xác định theo ngày công hoặc bất kỳ đơn vị nào khác. Số tiền này phải được chuyển đổi thành một số tiền thực tế, mà chắc chắn phải được thỏa thuận trong khi biên soạn báo cáo công việc.
Sau khi đã đồng ý, các yêu cầu thay đổi phải được lập thành văn bản trong thông số kỹ thuật ban đầu với các tham chiếu thích hợp đến số yêu cầu thay đổi. Nó phải được giải thích, thảo luận và giao cho nhóm dev và QA để thực hiện và xác minh.

3. Một cuộc thảo luận Change Request có nguồn gốc như thế nào?

Trong khi UAT hoặc Demo: Khi tính năng hoặc sản phẩm đang được người dùng thực tế thử nghiệm hoặc khi bản demo được cung cấp cho khách hàng sau khi phát triển lặp đi lặp lại, khách hàng thường nhận thấy một chức năng bị thiếu. Chính lúc này mảnh ghép còn thiếu được chỉ ra. Mảnh ghép này sẽ trở thành CR nếu nó không thể được truy xuất trở lại tài liệu yêu cầu.

Trong khi thảo luận về lỗi: Hãy xem xét một tình huống trong đó nhà phân tích kinh doanh của nhà cung cấp và người dùng cuối hoặc nhà phân tích kinh doanh khách hàng / người kiểm tra khách hàng đang tham gia vào một trận chiến bằng lời nói để xác định rằng lỗi thực sự là hợp lệ hay không hợp lệ. Một lần nữa, khiếm khuyết sẽ trở thành CR trong trường hợp không thể truy nguyên hành vi trong khiếm khuyết về tài liệu yêu cầu đã ký.

4. Vai trò của một Software Business Analyst trong vòng đời của CR

Để bắt đầu, vì nhà phân tích kinh doanh (Business Analyst) đã soạn thảo tài liệu đặc tả, anh ta phải ngồi với khách hàng và hiểu hoặc tranh luận về cái gọi là yêu cầu mới. Nếu thay đổi không được đề cập trong tài liệu hoặc không thể được suy luận một cách ngầm hiểu, họ phải thuyết phục khách hàng rằng đó thực sự là một CR. Đây là cuộc họp phức tạp nhất vì cả hai bên đều tranh luận về phía mình.

Business Analyst có vai trò then chốt trong vòng đời Change Request

Nếu CR thực sự được đồng ý, Business Analyst phải quay lại và cập nhật thông số kỹ thuật và được khách hàng ký. Trước đó, họ phải kiểm tra cẩn thận tính khả thi của CR và các mốc thời gian bị ảnh hưởng bởi chúng. Thông thường, các nhà phát triển không bao giờ hài lòng về những thay đổi mới mang lại cho phần mềm đã xây dựng. Vì vậy, một hướng dẫn thích hợp phải xảy ra với nhà phát triển và nhóm thử nghiệm.

5. Những điều Business Analyst cần lưu ý trong cuộc thảo luận CR

Giữ các thông số kỹ thuật thuận tiện, biết và sửa đổi những thay đổi đang được tranh luận và chuẩn bị cho các quan điểm của bạn.
Thảo luận về phương pháp xử lý CR với người quản lý hay quản lý cấp cao của bạn. Một số nhà cung cấp muốn linh hoạt hơn nếu đó là một khách hàng rất quan trọng. Số khác không muốn sử dụng CR do thiếu băng thông.
Đôi khi, hãy có cách tiếp cận cho và nhận. Nếu sự thay đổi thực sự nhỏ và mang tính thẩm mỹ, các Business Analyst có xu hướng chấp nhận chúng để duy trì mối quan hệ tốt đẹp với khách hàng. Tuy nhiên, hãy luôn kiểm tra tính khả thi của các yêu cầu dù là nhỏ. Những gì có vẻ nhỏ đối với bạn có thể rất khó khăn về mặt kỹ thuật đối với nhóm phát triển.

6. Change Request không phải lúc nào cũng xấu

Nhiều trường hợp các nhà cung cấp không có sự hiểu biết đầy đủ về các yêu cầu hoặc sự phức tạp của quy trình kinh doanh của khách hàng. Họ tiếp tục với các yêu cầu đã ký kết với sự hiểu biết chiến thuật với khách hàng rằng nhiều tính năng hơn có thể xuất hiện dưới dạng yêu cầu thay đổi.

Trong những trường hợp như vậy, khách hàng đang tìm kiếm cách triển khai nhanh chóng và đơn giản, sau đó xem xét các CR để nâng cao sản phẩm. Đôi khi CR giúp nhà cung cấp có công việc kinh doanh lặp lại và gắn bó lâu hơn với khách hàng. Đó là một kiểu đôi bên cùng có lợi cho các nhà cung cấp và khách hàng.

Quản lý các cuộc thảo luận và thực hiện CR là một kỹ năng tốt cần có đối với một Software Business Analyst. Điều này là vì lý do đơn giản rằng, không giống như hầu hết các ngành công nghiệp, các yêu cầu phần mềm có xu hướng thay đổi rất lớn. Đối với điều này, chúng ta nên sẵn sàng và linh hoạt để xem xét chúng.

Nhưng đảm bảo rằng CR không có nguồn gốc do bạn mắc lỗi khi soạn thảo các thông số kỹ thuật mơ hồ. Đó là một cú hích đối với sự tín nhiệm của bạn và đồng nghĩa với việc làm thêm cho nhóm ở giai đoạn sau.

Một số gợi ý để tránh xác định CR do thông số kỹ thuật không phù hợp:

Hãy thật chi tiết và dài dòng với các thông số kỹ thuật khi bạn cần.
Che tất cả các trường hợp góc và cạnh trong tài liệu.
Thông qua các thông số kỹ thuật với khách hàng càng nhiều càng tốt.
Lưu tất cả các liên lạc qua email với khách hàng nơi họ thảo luận về các yêu cầu. Hãy trình bày rõ ràng nhất có thể trong các email.

Yêu cầu thay đổi có thể là bạn của bạn hoặc kẻ thù của bạn tùy thuộc vào cách bạn xử lý chúng.

Trên đây là những điều mà một Software Business Analyst cần biết về Change Request. Mong rằng những thông tin trên sẽ hữu ích với bạn đọc, đừng quên đón xem các nội dung mới sẽ được cập nhật thường xuyên tại BAC's Blog.

Nguồn tham khảo:
https://www.modernanalyst.com/

Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất

Ban biên tập nội dung - BAC

Click để đọc tiếp

10 Thuật ngữ AI ai cũng nên biết

Khám phá 10 thuật ngữ quan trọng nhất trong lĩnh vực trí tuệ nhân tạo (AI) cùng BAC – từ AI, Machine Learning đến Generative AI, Copilot và hơn thế nữa. Bài viết được biên dịch từ nguồn Microsoft, giúp bạn hiểu rõ cách công nghệ này hoạt động và đang thay đổi thế giới. Một tài liệu nhập môn hoàn hảo cho người mới, chuyên viên công nghệ hay bất kỳ ai muốn bắt kịp làn sóng chuyển đổi số.
Học AI từ con số 0: Lộ trình đơn giản cho người mới bắt đầu

Khám phá lộ trình học AI đơn giản cho người mới bắt đầu cùng BAC. Bạn không cần giỏi lập trình để có thể học AI và trở thành chuyên gia. Những kiến thức này hoàn toàn có thể được tiếp thu và ứng dụng thực tế bởi tất cả mọi người.
Gemini là gì? So sánh Gemini và ChatGPT cho người mới bắt đầu

Gemini là gì? So sánh nhanh Gemini và ChatGPT một cách đơn giản, giúp người mới bắt đầu học AI chọn công cụ phù hợp để học tập, làm việc và sáng tạo nội dung. Mỗi công cụ đều có ưu và nhược điểm riêng, hãy cùng BAC khám phá chi tiết.
AI là gì? Giải thích đơn giản cho người mới bắt đầu

Bài viết này sẽ giúp các bạn tìm hiểu AI theo hướng đơn giản nhất. Bằng cách giải thích ngắn gọn, cô động, súc tích và dễ hiểu, BAC sẽ cho bạn lý giải về cụm từ “AI”. Qua đó, bạn không chỉ hiểu mà còn biết lý do vì sao mình phải học AI.

Bình luận

Lê Anh Tuấn

Chuyên viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi là nhân sự thuộc Trung tâm Phát triển CNTT – Khối Ngân hàng số, hiện đang đảm nhiệm vai trò kiểm thử phần mềm (tester). Việc tham gia khóa học Business Analyst đã mang lại cho tôi góc nhìn toàn diện và rõ ràng hơn về vai trò của BA trong lĩnh vực ngân hàng.

Khóa học Fundamental Business Analysis tại BAC không chỉ giúp tôi hiểu đúng bản chất công việc BA mà còn hỗ trợ phát triển tư duy nghiệp vụ – từ tiếp cận giải pháp kỹ thuật sang tập trung vào nhu cầu người dùng. Phương pháp giảng dạy kết hợp lý thuyết và thực hành thực tiễn, cùng các hoạt động mô phỏng, thảo luận nhóm đã giúp tôi nâng cao kỹ năng giao tiếp, phân tích và trình bày yêu cầu – những năng lực thiết yếu để phối hợp hiệu quả giữa các bên trong dự án công nghệ.

Xem chi tiết +
Huỳnh Cao Cường

Nhân viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi hiện đang công tác tại Trung tâm Phát triển CNTT – Khối CNTT, với vai trò là nhân sự chức năng phụ trách mảng Ngân hàng số, chuyên sâu về kiểm thử phần mềm (Tester). Trước khi tham gia khóa học Fundamental Business Analysis do BAC tổ chức, tôi từng hình dung BA chỉ đơn thuần là cầu nối giữa bộ phận kỹ thuật và nghiệp vụ.

Tuy nhiên, quá trình học đã giúp tôi nhận thức rõ hơn về bản chất và tầm quan trọng của vị trí này. BA không chỉ kết nối các bên liên quan, mà còn giữ vai trò định hình yêu cầu, đảm bảo giải pháp được thiết kế đúng mục tiêu và sát với nhu cầu thực tế. Khóa học đã trang bị cho tôi tư duy phân tích bài bản, khả năng diễn đạt yêu cầu rõ ràng, và kỹ năng phối hợp hiệu quả trong môi trường dự án đa chiều.

Với nền tảng công nghệ thông tin sẵn có, khóa học là bước chuyển hướng quan trọng giúp tôi phát triển tư duy nghiệp vụ vững chắc và sẵn sàng theo đuổi lộ trình nghề nghiệp chuyên sâu trong lĩnh vực Business Analysis tại Eximbank.

Xem chi tiết +
Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +

Professional Transfer Services in Batumi

Luxury Georgian Transfer Services – Tbilisi & Batumi

Airport Transfers in Georgia

10 Thuật ngữ AI ai cũng nên biết

Học AI từ con số 0: Lộ trình đơn giản cho người mới bắt đầu

Gemini là gì? So sánh Gemini và ChatGPT cho người mới bắt đầu

AI là gì? Giải thích đơn giản cho người mới bắt đầu

CÔNG TY CỔ PHẦN ĐÀO TẠO VÀ TƯ VẤN BAC