Quản lý chất lượng

Technical

Đặt tiêu chuẩn chất lượng và giữ nó khi áp lực tiến độ.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Kỹ thuật cho PM/BA — 2 người đã làm. Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Technical, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Chất lượng không phải giai đoạn cuối trước khi release — nó là chuỗi quyết định nhỏ suốt quá trình. Thứ quyết định chất lượng thật là ĐIỀU BẠN CHO PHÉP khi gần deadline, không phải quy trình viết trên giấy.

Khi đã làm được

Đặt được chuẩn chất lượng đo được và giữ nó khi có áp lực: định nghĩa xong rõ ràng, cổng chất lượng ở đúng chỗ, ghi nợ khi buộc phải bỏ qua, và dùng dữ liệu sự cố để sửa nguyên nhân thay vì sửa triệu chứng.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/13 mục · còn khoảng 5 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Quản lý chất lượng là gì?

Quản lý chất lượng là giữ cho sản phẩm đạt một chuẩn đã thống nhất, kể cả khi gấp.

Mọi đội đều nói chất lượng quan trọng. Khác biệt nằm ở lần đầu tiên phải chọn giữa chất lượng và ngày phát hành — lựa chọn đó là chuẩn thật.

Khi nào bạn gặp chuyện này

Tình huống	Bạn làm gì	Nếu không
Gần release, một lỗi nghiêm trọng vừa xuất hiện.	Có sẵn luật phân loại: lỗi mức nào chặn release. Quyết theo luật, không quyết theo cảm xúc.	Mỗi lần lại tranh luận từ đầu, và kết quả phụ thuộc ai nói to hơn hôm đó.
Cùng một loại sự cố lặp lại lần thứ ba.	Làm phân tích nguyên nhân gốc và sửa ở tầng hệ thống, không chỉ vá lần này.	Bạn tiêu thời gian chữa cháy đều đặn và không bao giờ có thời gian phòng cháy.
Đội bỏ qua chuẩn vì "lần này ngoại lệ", ba tháng liền.	Ghi mỗi ngoại lệ thành nợ có tên và có hạn trả. Đến hạn thì trả.	Ngoại lệ thành thông lệ, và chuẩn trở thành thứ trang trí.

Bốn thứ phải có

Định nghĩa xong (Definition of Done) viết ra, cả đội đồng ý.
Phân loại lỗi theo mức, và luật rõ mức nào chặn release.
Sổ nợ chất lượng: mỗi lần bỏ qua chuẩn là một dòng có hạn trả.
Xem lại sự cố hằng tháng — tìm mẫu lặp, không tìm người sai.

Template: phân loại lỗi và luật chặn

Mức	Nghĩa là	Chặn release?	Phải sửa trong
P0	Mất dữ liệu, mất tiền, hoặc hệ thống không dùng được	Có	Ngay lập tức
P1	Luồng chính hỏng, có cách đi vòng khó	Có	24 giờ
P2	Ảnh hưởng một phần người dùng, có cách đi vòng	Không	Sprint này
P3	Khó chịu, không chặn việc gì	Không	Khi có chỗ

Sai lầm thường gặp

Sai lầm	Vì sao hỏng	Làm thay bằng
Chất lượng là việc của QA	Người viết code không còn thấy đó là việc của mình.	Chuẩn nằm trong định nghĩa xong, áp cho mọi người.
Quyết theo cảm xúc lúc gấp	Chuẩn thành thương lượng, và ai cũng học điều đó.	Luật phân loại quyết định, không phải người.
Bỏ qua mà không ghi nợ	Nợ vô hình thì không bao giờ được trả.	Một dòng, có tên và hạn.
Xem lại sự cố để tìm người sai	Người ta giấu sự cố.	Tìm nguyên nhân hệ thống.

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Engineering Manager	Bạn là người quyết lúc gấp — và quyết định đó dạy đội chuẩn thật là gì.
Product Manager	Bạn bảo vệ chỗ cho việc trả nợ chất lượng trong roadmap, và giải thích được với stakeholder vì sao.
QA / Tester	Bạn giữ luật phân loại và làm nó hiện hình.
Head of Product	Chất lượng thấp xuất hiện muộn — dưới dạng tốc độ giảm dần mà không ai giải thích được.

Definition of done — dấu hiệu bạn đã đạt

Định nghĩa xong được viết ra và cả đội dùng.
Có luật phân loại lỗi, và quyết định lúc gấp theo luật đó.
Mọi lần bỏ qua chuẩn đều thành một dòng nợ có hạn.
Không loại sự cố nào lặp lại lần thứ ba.

Chất lượng không phải khâu cuối — nó là một loạt quyết định

Mô hình phổ biến: đội xây, QA kiểm, rồi phát hành. Mô hình này đặt toàn bộ gánh nặng chất lượng vào một khâu ở cuối, nơi việc sửa đắt nhất.

Lỗi được phát hiện ở đâu	Chi phí sửa tương đối	Vì sao
Lúc bàn yêu cầu	1×	Sửa một câu trong tài liệu
Lúc thiết kế	~3×	Vẽ lại một màn hình
Lúc lập trình	~10×	Sửa code chưa ai dùng
Lúc QA kiểm	~20×	Sửa + kiểm lại + có thể ảnh hưởng việc khác
Sau khi phát hành	~100×	Sửa + phát hành gấp + dữ liệu sai đã phát sinh + niềm tin

Kết luận thực tế: đầu tư vào việc phát hiện sớm gần như luôn có lợi tức cao hơn đầu tư vào việc kiểm kỹ hơn ở cuối. Một buổi đi qua thiết kế cùng nhau rẻ hơn nhiều so với một vòng QA.

Bốn lớp chất lượng — mỗi lớp bắt một loại lỗi khác nhau

Lớp	Bắt được gì	Ai làm
Yêu cầu rõ ràng	Hiểu sai vấn đề — loại lỗi đắt nhất	BA, PO
Đọc duyệt mã nguồn	Lỗi logic, lỗi bảo trì, kiến thức không lan	Engineer
Kiểm thử tự động	Hồi quy — thứ đã chạy nay hỏng	Engineer, QA
Kiểm thử thủ công và UAT	Vấn đề trải nghiệm, ca thật phức tạp	QA, người dùng

Không lớp nào thay được lớp khác. Sai lầm phổ biến là dồn hết vào lớp thứ tư vì nó dễ thấy nhất — và kết quả là QA trở thành nút thắt, đồng thời vẫn bỏ sót loại lỗi mà chỉ lớp thứ nhất bắt được.

Đo chất lượng — bốn chỉ số, và cái nào nói dối

Chỉ số	Nó nói gì	Cách nó nói dối
Số lỗi tìm được	Hoạt động kiểm thử	Giảm vì kiểm ít đi, không vì chất lượng tăng
Lỗi khách phát hiện trước đội	Chất lượng thật	Khó nói dối — chỉ số tốt nhất trong bảng
Tỉ lệ bao phủ kiểm thử	Có bao nhiêu code được chạy qua	Cao mà kiểm thử không khẳng định gì vẫn vô dụng
Thời gian khôi phục sau sự cố	Năng lực phản ứng	Ít bị bóp méo; nên theo dõi

Dùng chỉ số thứ hai làm chỉ số chính. Nó đo đúng thứ quan trọng: ai phát hiện vấn đề trước. Đội tự tìm ra và sửa trước khi khách gặp là chất lượng; khách gặp trước là thất bại, bất kể tổng số lỗi là bao nhiêu.

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Product Owner	Hiểu vì sao đầu tư vào lớp thứ nhất rẻ hơn nhiều so với kiểm kỹ ở cuối
QA	Thoát khỏi vai trò nút thắt cuối đường bằng cách đẩy chất lượng lên sớm
Engineer	Đọc duyệt mã nguồn và kiểm thử tự động là hai lớp thuộc về bạn
Business Analyst	Lớp đầu tiên là của bạn, và nó bắt loại lỗi đắt nhất
Team Lead	Chọn chỉ số đúng; số lỗi tìm được là chỉ số dễ bị bóp méo nhất

Tình huống thực tế — vì sao QA thành nút thắt

Triệu chứng: mỗi sprint, việc dồn về QA vào hai ngày cuối. QA làm không kịp, việc tràn sang sprint sau, và đội bắt đầu coi QA là nguyên nhân chậm trễ.

Điều thật sự đang xảy ra — đo trong một sprint:

Loại lỗi QA tìm được	Số lượng	Lẽ ra bắt được ở lớp nào
Hiểu sai yêu cầu	7	Lớp 1 — yêu cầu rõ ràng
Thiếu ca ngoại lệ	11	Lớp 1 — điều kiện xác nhận
Lỗi logic	4	Lớp 2 — đọc duyệt mã nguồn
Hồi quy (thứ cũ nay hỏng)	9	Lớp 3 — kiểm thử tự động
Vấn đề trải nghiệm thật	3	Lớp 4 — đúng chỗ

Đọc ra: 31 trong 34 lỗi lẽ ra phải bị bắt ở lớp trước. QA không phải nút thắt — QA đang làm việc của ba lớp khác.

Cách sửa không phải thuê thêm QA. Nó là: đưa điều kiện xác nhận kèm ca ngoại lệ vào danh sách "sẵn sàng", bắt buộc đọc duyệt mã nguồn, và viết kiểm thử tự động cho phần hay hồi quy. Sau hai sprint, số lỗi tới tay QA giảm mạnh và họ làm được đúng việc của lớp 4 — thứ không ai khác làm được.

Definition of done

Có đủ bốn lớp chất lượng, không dồn hết vào kiểm thử cuối.
Chỉ số chính là lỗi khách phát hiện trước đội.
Không dùng tổng số lỗi làm thước đo chất lượng.
Có theo dõi thời gian khôi phục sau sự cố.
Việc phát hiện sớm được đầu tư tương xứng với chi phí lỗi muộn.
Khi QA thành nút thắt, đã đo xem lỗi lẽ ra thuộc lớp nào trước khi kết luận là thiếu người.