Xử lý bất đồng với Dev và QC: đổi yêu cầu, tranh cãi bug và ranh giới vai trò

Vẫn dùng tiếp tính năng quên mật khẩu ở bài trước làm ví dụ, để khỏi phải dựng bối cảnh mới. Nếu bạn chưa đọc bài trước cũng không sao, chỉ cần nhớ: một tính năng cho người dùng tự đặt lại mật khẩu qua email, có link hết hạn sau một khoảng thời gian.

1. Khi dev nói "cái này không làm được"

Sớm muộn bạn cũng gặp câu này, hoặc phiên bản nhẹ hơn của nó: "làm kiểu đó phải đập cấu trúc dữ liệu cũ, mất ít nhất hai tuần", "chỗ này nặng lắm, chạy là treo server".

Người mới hay phản ứng theo một trong hai hướng, và cả hai đều hỏng. Hướng thứ nhất là tin ngay, về báo lại là không làm được, rồi tính năng chết ở đó. Hướng thứ hai là ép: "nhưng sếp chốt với khách rồi, các anh cố giúp em" — câu này chỉ làm dev đóng cửa lại với bạn.

Điều bạn cần nhớ là hầu hết câu "không làm được" thật ra là "không làm được trong khung này" — khung thời gian, kiến trúc hiện tại, hoặc một ràng buộc kỹ thuật cụ thể. Việc của bạn là tìm ra khung đó nằm ở đâu, chứ không phải phán xem dev nói đúng hay sai; phần kỹ thuật thì họ đúng hơn bạn.

Ba câu hỏi thường mở được bế tắc:

• "Phần nào trong này tốn thời gian nhất ạ?" — để biết cắt chỗ nào thì nhẹ đi được nhiều nhất.
• "Nếu bỏ phần X thì còn khoảng bao lâu?" — để có một phương án rút gọn mang đi thương lượng.
• "Cái mình cần thật ra là [mục đích nghiệp vụ]. Có cách nào khác đạt được chỗ đó mà nhẹ hơn không?" — câu này hay nhất, vì nó chuyển cuộc nói chuyện từ giải pháp về lại mục đích.

Rồi mang các phương án đó đi cho người có quyền chọn, kèm cái giá của từng phương án. Bạn không phải người chốt, nhưng bạn là người làm cho việc chốt trở nên dễ.

Nếu bạn thật sự nghi ngờ một câu trả lời kỹ thuật, đừng tranh cãi tay đôi. Hỏi lại một cách thành thật: "chỗ này em không rành, anh giải thích giúp em vì sao nó nặng được không?". Người biết việc thường rất sẵn lòng giải thích — và nếu ai đó không giải thích được, chính điều đó cũng là một câu trả lời.

2. Đổi yêu cầu giữa chừng: nói trước, ghi sau

Dev đang code dở thì bên nghiệp vụ đổi ý: link hết hạn rút từ 24 tiếng xuống còn 30 phút, và thêm một bước nhập mã OTP.

Trước khi nói tới cách báo, có một chuyện phải rõ: quyết định nhận thay đổi này vào ngay hay đẩy sang đợt sau không phải của bạn. Đó là việc của người sở hữu sản phẩm cùng cả team, dựa trên mục tiêu của đợt làm việc hiện tại và khối lượng dev đang gánh. Việc của BA là làm rõ thay đổi gồm những gì và kéo theo ảnh hưởng gì, để người ta có cái mà quyết. Nhận thay khách rồi về ép dev là bạn đang lấn sang phần của người khác.

Giả sử team đã đồng ý làm ngay. Đổi yêu cầu giữa chừng nghe thì đáng sợ nhưng dự án nào cũng có. Cái làm hỏng mọi thứ không phải việc đổi — mà là đổi trong im lặng.

Phản xạ tự nhiên của người mới là mở tài liệu ra sửa cho đúng trước đã, xong xuôi rồi thông báo sau. Nghe rất có trách nhiệm. Nhưng trong lúc bạn ngồi sửa tài liệu, dev vẫn đang code theo bản cũ, còn QC vẫn đang chuẩn bị kịch bản test cho cái link 24 tiếng.

Thứ tự đúng thì ngược lại — nói trước, ghi sau:

1. Hô ngay vào nhóm chung, ngay khi bạn vừa biết. Một câu là đủ: "Khoan đã mọi người, phần quên mật khẩu vừa chốt đổi: link còn 30 phút và thêm bước OTP. Em cập nhật ticket trong hôm nay."
2. Cập nhật ticket, vì đó là chỗ dev đang mở.
3. Báo riêng cho QC, vì kịch bản test của họ vừa hỏng và họ cần biết sớm nhất.
4. Cuối cùng mới ngồi sửa tài liệu cho tử tế.

Ba bước đầu tốn của bạn chưa tới năm phút. Bước cuối tốn cả buổi, nhưng nó là bước duy nhất có thể chờ.

3. Bug không phải một trận đấu

QC log bug, dev đọc xong bảo "tài liệu không yêu cầu", QC bảo "vậy người dùng bấm tiếp rồi mới báo lỗi à". Hai bên đá qua đá lại vài vòng, rồi cùng quay sang nhìn BA.

Đây là lúc bạn dễ chọn sai nhất. Bênh dev thì QC thấy mình bị coi nhẹ. Bênh QC thì dev thấy mình bị đổ vỏ. Mà thật ra không bên nào cần bạn bênh cả — họ cần bạn phân loại.

Mình hay xếp bug về ba nguồn gốc:

Thiếu spec. Tài liệu không nói tới trường hợp đó. Ví dụ tài liệu ghi "link hết hạn sau 30 phút" nhưng không nói người dùng bấm vào link đã hết hạn thì thấy gì. Đây là phần của BA, không phải của ai khác.

Sai spec. Tài liệu có nói, nhưng cái đang chạy thì khác. Cũng có trường hợp tài liệu viết đúng mà cả dev lẫn QC đều đọc lướt rồi hiểu theo một hướng khác — lúc đó đừng vội mừng là "không phải lỗi của mình", vì một chỗ mà hai người cùng đọc sai thì thường là do mình viết khó hiểu chứ không phải họ ẩu.

Đúng spec nhưng nghiệp vụ đã đổi. Tài liệu đúng ở thời điểm viết, chỉ là bên nghiệp vụ nghĩ lại sau khi nhìn thấy sản phẩm chạy thật. Đây không phải bug của ai cả, nó là một yêu cầu mới đội lốt bug.

Ba loại này xử lý khác hẳn nhau, nên việc đầu tiên khi có tranh cãi là xác định nó thuộc loại nào, chứ không phải tìm xem ai sai.

Riêng loại thứ nhất, bạn cần một câu để nhận trách nhiệm mà không mất mặt. Mình dùng đại khái thế này: "Chỗ này tài liệu em chưa nói rõ, lỗi của em. Em bổ sung ngay trong hôm nay, anh cứ làm tiếp phần còn lại đã." Nghe thì đơn giản, nhưng bạn thử để ý mà xem — trong một cuộc tranh cãi mà có người nhận phần của mình trước, nhiệt độ hạ xuống ngay lập tức.

Điều ngược lại cũng đúng: nếu bạn quen miệng nói "đúng như spec mà" để đẩy bug đi, chỉ vài lần là QC sẽ ngừng hỏi bạn và log bug thẳng cho dev. Lúc đó bạn mất luôn cái kênh phát hiện sớm tốt nhất mình đang có.

4. Ai quyết cái gì

Phần lớn tranh cãi kéo dài không phải vì hai bên bất đồng thật, mà vì không ai biết chuyện này thuộc quyền ai. Phần này mình viết kỹ vì tài liệu tiếng Việt hay chép sai của nhau.

Chỗ thứ ba trong bảng, nói thêm cho bạn mới đỡ áp lực: không ai đòi một người mới vào nghề phải tự đánh giá được một thay đổi sẽ làm vỡ chức năng nào. Bạn nêu phần mình nhìn thấy về mặt nghiệp vụ, còn phần hệ thống thì hỏi thẳng dev rồi ghi lại câu trả lời của họ. Gom đủ hai phần đó là đã đủ cho người ta quyết.

Bốn chỗ hay bị nói sai:

Chất lượng không phải việc riêng của QC. Người viết code chịu trách nhiệm về chất lượng phần mình làm; QC giúp phát hiện và đánh giá rủi ro. Nếp "code xong ném cho QC" là nếp xấu, không phải quy trình.

Scope không mặc định do BA quyết. Bạn phân tích và đề xuất, người chốt là bên sở hữu sản phẩm hoặc khách hàng tuỳ mô hình dự án. Chưa biết ai có thẩm quyền thì đi tìm cho ra, đừng tự hứa với dev cũng đừng tự từ chối QC.

Quyền đổi trạng thái bug là do team thoả thuận. Thông lệ phổ biến là ai log bug thì người đó test lại rồi đóng — tức là QC — và cứ theo thông lệ đó nếu team chưa nói gì. Nhưng nó là thoả thuận và cấu hình của từng nơi, không phải luật chung, nên việc đầu tiên vẫn là hỏi cho biết luật ở chỗ mình.

Dev nói chuyện thẳng với bên nghiệp vụ không phải là sai. Nhiều bạn mới ôm khư khư nguyên tắc "mọi thứ phải qua BA" vì sợ mất vai trò. Khi hai bên đã đủ bối cảnh để nói chuyện với nhau, việc của bạn là ngồi cùng và ghi lại kết quả, chứ không phải chen vào giữa để chứng minh mình cần thiết.

Nắm được cái bảng này rồi thì bạn tránh được cả hai cái bẫy: nhận bừa mọi thứ về mình cho êm chuyện, và ôm khư khư quyền quyết định không phải của mình.

5. Ở Việt Nam, ranh giới BA và QC đang mờ dần

Phần này không có trong sách, mình lấy từ chuyện anh em trong cộng đồng kể lại.

Đi xem tin tuyển dụng bây giờ sẽ thấy khá nhiều chỗ ghi kiểu "Senior BA kiêm manual QC, ưu tiên ứng viên biết auto test". Có bạn đang làm BA chính nhưng gánh luôn phần kiểm thử. Có người nhận xét thẳng là giờ nhiều công ty tuyển một người làm luôn cả BA lẫn QC lẫn PO, chứ không còn là hỗ trợ qua lại nữa.

Mặt tốt là hiểu góc nhìn của QC thật sự làm bạn viết yêu cầu tốt hơn. Người quen đi tìm chỗ hở sẽ tự động hỏi những câu mà BA hay quên: dữ liệu rỗng thì sao, bấm hai lần thì sao, thế nào mới tính là đúng. Bạn nên học cách nghĩ đó, kể cả khi không ai bắt bạn kiêm nhiệm.

Mặt còn lại thì cần nói thẳng: kiêm cách nghĩ là một chuyện, kiêm khối lượng công việc là chuyện khác. Có một câu trong cộng đồng mình thấy đáng nhớ — gom hai vai vào một người mà tổng thời gian không đổi thì kiểu gì cũng gãy, và cái gãy đầu tiên thường là chất lượng. Nếu bạn rơi vào tình huống đó, cách xử lý không phải là im lặng gánh, mà là nói trước với quản lý rằng ngắn hạn thì được, còn lâu dài thì đừng kỳ vọng kết quả như có hai người.

Với bạn mới thì mình nghĩ đây là tin tốt hơn là tin xấu: thời gian bỏ ra học cách nghĩ của QC không bao giờ phí.

Nhìn lại cả hai bài

Nếu để ý thì mọi tình huống trong bài này đều quy về cùng một việc: tách cho rõ cái gì là sự thật, cái gì là ý kiến, và cái gì là quyết định của người khác.

Dev nói "không làm được" — đó là một ràng buộc kỹ thuật cần làm rõ, không phải một lời từ chối. Khách đổi ý — đó là một quyết định của người có thẩm quyền, việc của bạn là truyền đi cho nhanh. Bug đang cãi nhau — đó là một câu hỏi về nguồn gốc, không phải một phiên toà.

Người mới hay biến cả ba thứ đó thành chuyện cá nhân, rồi hoặc là nhận hết về mình, hoặc là cố chứng minh mình đúng. Cả hai đều mệt và đều không giải quyết được gì.

Bài tiếp theo mình sẽ nói về các loại dự án IT mà BA hay tham gia — vì cùng những tình huống trên, đặt vào dự án outsourcing hay dự án product thì cách xử lý lại lệch nhau khá nhiều.