Defect hay Change Request

Cả hai đều đang nói thật, và đó là chỗ khó của tình huống này.

Bản chất của tranh chấp này

Đây không phải câu hỏi kỹ thuật mà là câu hỏi về việc hai bên đã thống nhất cái gì, và phần lớn dự án không có câu trả lời rõ ràng vì chưa bao giờ thống nhất đủ chi tiết.

Cần thừa nhận một chuyện ngay từ đầu, vì không thừa nhận thì phần còn lại của bài này thành ra thiên vị: theo kinh nghiệm của tôi, phần lớn tranh chấp defect hay change request xảy ra vì tài liệu viết không đủ rõ, chứ không phải vì khách đổi ý. Khách hàng đọc một đoạn mô tả, hiểu theo cách của người làm nghiệp vụ, và cách hiểu đó khác cách hiểu của người viết ra nó.

Chỗ tài liệu hay thiếu nhất là exception flow, tức những trường hợp không đi theo luồng bình thường. Luồng chính thì ai cũng viết, còn nếu hàng không đủ thì sao, nếu khách trả lại một phần thì sao, nếu đơn đã xuất hóa đơn rồi mới phát hiện sai thì sao, đó là những cái đó hay bị bỏ, và chính chúng là nơi tranh chấp nổ ra.

Tuy nhiên, cũng có tình huống mà không bên nào viết thiếu và vẫn tranh chấp. Tôi từng gặp trường hợp người ký xác nhận tài liệu đã nghỉ việc, và trường hợp người raise issue lúc UAT không phải người đã xác nhận lưu đồ; cả hai đều dẫn tới một cuộc tranh cãi mà không ai sai cả, và lúc đó căn cứ duy nhất là email xác nhận có tên ai, ngày nào.

Do đó, trước khi bàn tới cách phân loại thì cần nói thẳng: nếu tới lúc UAT bạn mới đi tìm ranh giới thì đã muộn, vì ranh giới được tạo ra từ trước.

Năm nhóm issue, không phải hai

Đây là bước bị bỏ qua nhiều nhất, và cũng là bước tiết kiệm thời gian nhất.

Khi một issue đổ về, phản xạ thường thấy là hỏi ngay đây là lỗi của mình hay khách yêu cầu thêm. Hỏi vậy là hỏi sớm, bởi phần lớn issue không thuộc cả hai loại đó. Trước hết phải phân loại theo nguyên nhân.

Đầu tiên là nhóm sai dữ liệu, khi ai đó nhập sai, hoặc file import có vấn đề, hoặc dữ liệu chuyển từ hệ thống cũ sang bị lệch. Nhóm này xử lý được ngay nhưng phải cẩn thận vì ERP có tính liên kết. Ví dụ, một sản phẩm bị khai sai đơn vị tính mà đã phát sinh dữ liệu đơn hàng thì trên Odoo 19 bạn không xóa được sản phẩm đó nữa, và muốn đổi phải nhờ đội kỹ thuật can thiệp.

Tiếp theo là nhóm thiếu hoặc sai cấu hình, chẳng hạn một tính năng chưa được bật, một quyền chưa được cấp, một quy tắc giá chưa được khai báo; nhóm này thường mất mươi phút để xử lý nếu đúng người làm.

Nhóm thứ ba là bug hệ thống, tức chức năng chạy sai so với thiết kế, và đây mới là defect theo nghĩa hẹp.

Bên cạnh đó còn nhóm hạ tầng không đáp ứng, gồm hệ thống chạy chậm, quá tải vào giờ cao điểm, in ấn không kịp; nhóm này không sửa bằng code được.

Và đặc biệt là nhóm thứ năm mà gần như ai cũng quên khi lập kế hoạch, đó là người dùng không biết thao tác ở đâu hoặc thao tác sai. Ở một doanh nghiệp có vài chục cửa hàng, mỗi cửa hàng ba nhân viên, chỉ cần một thao tác lạ là hàng chục người cùng báo lỗi; trong ba ngày đầu sau go-live thì nhóm này thường chiếm phần lớn số lượng issue.

Chỉ sau khi đã loại bốn nhóm còn lại: dữ liệu, cấu hình, hạ tầng và thao tác người dùng thì mới tới câu hỏi defect hay change request. Kỹ năng phân loại này là giá trị riêng của vai trò BA khi go-live, và tôi đã nói kỹ hơn ở bài về nghề BA ERP.

Cái giá của việc phân loại sai không chỉ là thời gian chờ, mà còn là một issue cấu hình bị đưa nhầm vào danh sách bug, làm hỏng luôn con số chất lượng bạn báo cáo ở cuối giai đoạn.

Cây quyết định

Sau khi đã xác định đây là vấn đề chức năng, hãy hỏi hai câu theo đúng thứ tự này.

Câu thứ nhất: hệ thống hiện tại có chạy đúng như tài liệu đã được xác nhận không?

Câu thứ hai: tài liệu đó có mô tả trường hợp này không?

Kết luận theo tổ hợp câu trả lời:

Với ô dẫn tới change request, còn một câu thứ ba nữa mới quyết định được bạn báo giá hay xử lý thiện chí: yêu cầu này có nằm trong phạm vi đã chốt không. Nếu có thì đó là việc bạn phải làm dù tài liệu chi tiết chưa mô tả; nếu không thì mới thực sự là yêu cầu phát sinh.

Ô thứ tư trong bảng đáng chú ý hơn nó có vẻ. Khi hệ thống chạy sai mà tài liệu cũng không mô tả thì khả năng cao là yêu cầu đã bị hiểu sai từ giai đoạn khảo sát chứ không phải bị làm sai ở giai đoạn lập trình, do đó sửa code lúc này thường không giải quyết được gốc và bạn sẽ gặp lại vấn đề đó ở một chỗ khác.

Ô khó nhất trong bảng

Hệ thống chạy đúng như đã mô tả, nhưng tài liệu không hề đề cập tới tình huống mà khách đang gặp.

Về mặt hợp đồng thì bạn có lý, vì cái gì không cam kết thì không phải làm. Về mặt thực tế thì đây thường là lỗi của bên viết tài liệu, và nói với khách rằng chúng tôi không cam kết cái này trong khi họ đang cầm một hệ thống không chạy được nghiệp vụ của họ là cách nhanh nhất để hỏng quan hệ.

Có ba cách xử lý tùy tình huống, và nên có ngưỡng định lượng để khỏi phải cân nhắc lại mỗi lần.

Nếu khối lượng dưới khoảng nửa ngày công và tình huống rõ ràng là thiếu sót phân tích thì làm luôn, đừng mở một cuộc thương lượng còn tốn thời gian hơn chính việc phải làm. Nhưng vẫn ghi vào Issue Log và đánh dấu là out-scope được xử lý thiện chí và ghi lại không phải để đòi tiền, mà để tới cuối dự án bạn có con số thật về khối lượng phát sinh và lần sau ước tính chính xác hơn.

Từ khoảng một ngày công trở lên thì phải đưa ra thương lượng, kể cả khi bạn biết lỗi thuộc về mình, bởi một ngày công lặp lại mười lần là mất nửa tháng của dự án. Cách nói hiệu quả nhất không phải là tranh luận ai đúng mà là trình bày lựa chọn: cái này không nằm trong phạm vi đã chốt, làm thì mất chừng này thời gian và ảnh hưởng tới lịch go-live thế này, anh chị muốn đưa vào phase này hay để phase sau.

Còn nếu tình huống có thể tránh được bằng cách hướng dẫn người dùng làm khác đi thì đề xuất phương án đó trước, vì nhiều yêu cầu phát sinh thực ra xuất phát từ việc người dùng đang cố làm theo thói quen của phần mềm cũ.

Ba tình huống và câu nên nói

Phần này khó viết ra nhất và cũng hữu ích nhất, bởi trong lúc căng thẳng người ta thường nói câu đầu tiên nghĩ ra, mà câu đầu tiên nghĩ ra thường là câu tệ nhất.

Khi khách nói rằng cái này rõ ràng là lỗi của bên anh, câu không nên nói là "cái này trong tài liệu có ghi rồi mà anh", tuy đúng nhưng nó biến cuộc trò chuyện thành cuộc tranh cãi về việc ai đọc kỹ hơn, và cuộc tranh cãi đó bạn không thắng được. Câu nên nói, đại ý là em ghi nhận, để em kiểm tra xem hệ thống đang chạy có khớp với thiết kế không rồi báo lại anh trong hôm nay; sau đó bạn đi kiểm tra thật và quay lại với kết quả cụ thể gồm hệ thống đang chạy thế này, thiết kế đã thống nhất là thế này, chỗ lệch nằm ở đây. > Mấu chốt là tách việc xác minh ra khỏi việc thương lượng, và đừng làm cả hai trong cùng một cuộc gọi.

Khi khách nói chỉ sửa tí thôi mà cũng tính tiền, đây là câu khó vì nó chạm vào cảm giác bị bắt chẹt, mà cảm giác đó thường có cơ sở, nên nếu mọi thay đổi nhỏ đều thành báo giá mới thì khách có quyền bực. Cách xử lý là đừng báo giá từng cái nhỏ mà hãy gom lại: ghi nhận các yêu cầu phát sinh vào Issue Log, đánh dấu out-scope, rồi tới cuối giai đoạn thì trình bày cả cụm cùng một lúc. Cách này có ba cái lợi: khách thấy bức tranh tổng thể thay vì bị hỏi tiền liên tục, bạn tránh được việc thương lượng năm lần một tuần, và những yêu cầu nhỏ mà khách không thực sự cần sẽ tự rơi ra khi họ nhìn cả danh sách.

Còn trong nội bộ, khi đội phát triển nói cái này SRS có ghi mà, mà bạn biết là SRS ghi mơ hồ, thì đây là tình huống hay bị xử lý sai nhất vì cách dễ nhất là im lặng đứng về phía đội mình. Nếu tài liệu mơ hồ thật thì việc bảo vệ nó chỉ trì hoãn vấn đề; cách xử lý đúng là thừa nhận trong nội bộ rằng chỗ đó viết chưa rõ, quyết định xem cách hiểu nào đúng với nghiệp vụ hơn, rồi sửa tài liệu trước khi sửa hệ thống. Không sửa tài liệu thì ba tháng sau có người đọc lại và làm sai lần nữa.

Vận hành Issue Log

Toàn bộ những gì nói ở trên chỉ chạy được nếu có một chỗ ghi lại, và chỗ đó là Issue Log. Vị trí của nó trong bộ tài liệu dự án thì tôi đã nói ở bài về bộ tài liệu ERP; ở đây là chuyện vận hành.

Có một chi tiết nhỏ trong cách tôi đặt cột mà hóa ra lại giải quyết được đúng vấn đề của bài này. Ngoài cột in-scope và out-scope, cột độ ưu tiên không chỉ có High, Medium, Low mà còn một giá trị nữa là Feature. Một issue được gắn Feature nghĩa là nó không phải lỗi, nó là thứ khách muốn có thêm và gắn nhãn ngay từ lúc ghi nhận thì tới cuối giai đoạn bạn lọc ra được danh sách yêu cầu phát sinh chỉ bằng một bộ lọc, thay vì phải ngồi đọc lại từng dòng để phân loại.

Về nơi tiếp nhận issue thì có một thứ tự ưu tiên rõ ràng và có cả cách hướng dẫn người dùng ghi cho đúng, nhưng đó là chuyện của giai đoạn vận hành nên tôi để ở bài về hai tuần đầu sau go-live; điều cần nhớ ở đây chỉ là phải phổ biến chỗ ghi nhận cho người dùng trước khi bắt đầu UAT chứ không phải sau.

Thực tế thì nhiều dự án chạy gấp tới mức không có tài liệu này. Tôi từng gặp dự án ký hợp đồng xong khoảng bốn mươi lăm ngày là go-live, và kết quả là ba ngày đầu có cả trăm issue đổ về cùng lúc, không ai biết cái nào đã cam kết cái nào chưa, nên phần lớn được xử lý theo kiểu ai kêu to hơn thì làm trước.

Ba việc làm từ đầu

Ranh giới giữa defect và change request không được tạo ra trong cuộc tranh luận lúc UAT, mà được tạo ra từ buổi kick-off và từ mỗi lần bạn gửi tài liệu cho khách xác nhận. Ba việc dưới đây làm từ đầu dự án.

Chốt danh sách tài liệu bàn giao và phạm vi công việc ngay từ buổi kick-off, vì bạn phải nắm được cái gì trong hợp đồng và cái gì không trước khi bắt đầu làm.

Gửi mọi tài liệu ra quyết định cho hai bên review và xác nhận bằng email chứ không xác nhận miệng, đặc biệt là lưu đồ quy trình, bởi đó là base mà mọi thứ khác dựa vào.

Viết exception flow bám theo business rule, vì đó là phần tài liệu tốn công nhất và cũng là phần cứu bạn nhiều nhất về sau; công thức để viết không sót thì tôi đã nói riêng ở bài về ba loại luồng.

Việc còn lại là chuẩn bị cho ngày hệ thống lên thật, khi số lượng issue tăng lên gấp nhiều lần và bạn không còn thời gian để suy nghĩ từng cái một.