Ai chịu trách nhiệm về Quality?

Ai chịu trách nhiệm về Quality?

Tôi mở đầu loạt ký sự của tôi bằng câu kết thúc trong một slide training của công ty về Quality Management: “Ai chịu trách nhiệm về Quality?” (Who is responsible for Quality?) Hình minh họa cho câu hỏi cũng khá funny, đội ngũ engineering thì trỏ về phòng QA khi súng ngắm bắn vào họ. Câu trả lời cũng rất cô đọng: Tất cả mọi người đều chịu trách nhiệm về Quality, bao gồm cả các quản lý cấp cao. (Everyone, including Top management). Các bạn hiểu câu trả lời trên thế nào? Trong những ngày đầu tiên tiếp cận với khái niệm này, tôi đã bật cười và nghĩ rằng: à, đây có thể là lý do mọi người hay đổ lỗi cho hệ thống. Khi có vấn đề xảy ra, họ nói đó là trách nhiệm của mọi người, ko chỉ riêng mình, do vậy, ý thức trách nhiệm của từng cá nhân bị giảm nhẹ đi rất nhiều khi đối mặt với các vấn đề. Tuy nhiên, trải qua những ngày tháng OT triền miên, những lần khách hàng mắng mỏ vì chất lượng dự án thấp, những buổi training mà khách hàng là trainer, họ đã rất kiên nhẫn giải thích từng vấn đề (kể cả vấn đề basic nhất) cho nhóm chúng tôi, tôi mới hiểu ra rằng suy nghĩ ban đầu của mình thật ấu trĩ và phiến diện. “Tất cả mọi người đều chịu trách nhiệm về Quality” cần được hiểu là: từng cá nhân phải chịu trách nhiệm về quality trong phạm vi công việc mà họ đảm nhận. Hãy hình dung thế này:    Trong một dự án, một sản phẩm output được tạo ra theo các bước sau:

1. Creator nghiên cứu input, hình dung về sản phẩm và tạo ra sản phẩm dựa trên sự hiểu biết của creator khi nghiên cứu các input và các yêu cầu chất lượng của sản phẩm output.
2. Sau khi creator tạo ra sản phẩm và confirm là sản phẩm đã ready để review, reviewer sẽ check quality của sản phẩm dựa vào các input đồng thời với các yêu cầu chất lượng của sản phẩm đó
3. Creator nghiên cứu các comment, dựa trên cơ sở là input và các yêu cầu chất lượng, creator sẽ xử lý (fix/không fix, giải thích lý do) các comment và trả lời reviewer.
4. Reviewer check lại các cách xử lý comment của creator cho đến khi toàn bộ các comment được closed.

Mỗi role ở 4 bước trên sẽ chịu trách nhiệm thế nào với quality mà họ tạo ra? Câu trả lời của tôi như sau

1. Ở bước này, creator cần nghiên cứu các input và trả lời câu hỏi: Mình đã hiểu rõ input chưa? Mình có thể biến input này thành các mô tả trong sản phẩm output của mình không? Có phần nào mình chưa hiểu rõ input không? Tiếp theo, creator cần hiểu các yêu cầu chất lượng của sản phẩm output bằng cách trả lời các câu hỏi: Mình đã hiểu sản phẩm đầu ra cần mô tả/ thực hiện thế nào chưa? Mình có cần hướng dẫn thêm để có thể tạo ra sản phẩm tốt hay không? Nếu các bạn lo lắng nếu muốn làm sản phẩm chất lượng tốt, nhưng lại làm chậm tiến độ dự án, hãy thẳng thắn chia sẻ với PM/TL lo lắng của mình, vì cuối cùng bạn sẽ nhận ra rằng nếu sản phẩm của bạn làm ra quá nhiều lỗi, thì thời gian bạn phải fix comment từ reviewer có khi còn vượt quá thời gian để bạn làm tốt sản phẩm ngay từ đầu.

2. Ở bước này, điều đầu tiên reviewer hãy tự hỏi và trả lời ngay: Mình có đủ năng lực để review sản phẩm này hay không? Nếu câu trả lời là không, hãy báo ngay cho PM/TL để họ tìm người khác, hãy nhớ câu “cố quá thì quá cố”, làm việc quá sức mình thì sẽ chỉ có hại (cho bản thân và cả người khác). Nếu câu trả lời là có, vì mục tiêu của review là tìm ra tính hợp lý của sản phẩm output so với input và các yêu cầu quality của sản phẩm đó, bạn hãy chỉ ra càng nhiều điểm không hợp lý càng tốt, đừng ngại đặt những câu hỏi trong tình huống mình confuse, tất cả những nghi vấn trong quá trình review nên được ghi nhận lại để xử lý, đừng bỏ qua bất cứ chi tiết nào cả, và khuyến khích các tiêu chí chất lượng reviewer dùng để xem xét sản phẩm được viết ra thành review checklist. Đòi hỏi quan trọng nhất khi review là sự tập trung, do vậy, nếu online review (peer review/TL review) thì hãy hoàn thành nó trước khi rẽ ngang sang các task khác, còn nếu offline review (group review) thì hãy book phòng đàng hoàng để thực hiện. Nhân tiện nói về group review, tôi xin chia sẻ best practice của một trong những ODC đầu tiên lĩnh vực embedded (PSC) đó là tính Training-on-job khi thực hiện hoạt động này rất cao, bằng chứng là tôi – từ một kẻ ngoại đạo – sau 1.5 năm chăm chỉ tham gia group review, bây giờ tôi có thể tự tin đọc hiểu tài liệu ADD của một hệ thống embedded cơ bản như hệ thống encode-decode ảnh, hệ thống xử lý audio,…

3. Ở bước này, creator cần duyệt từng comment/câu hỏi của reviewer và đưa ra xử lý thỏa đáng. Đừng ngần ngại đặt câu hỏi trở lại khi không hiểu comment của reviewer, cũng đừng lo lắng vì đó là bug phải fix, đừng cố fix comment khi bạn không hiểu fix thế nào, hãy hỏi trở lại reviewer/TL/PM những điều mình chưa biết. Trách nhiệm của bạn là cung cấp sản phẩm output có chất lượng tốt, nên hãy xử lý hết những comment, thậm chí cả những lỗi mà bạn phát hiện thêm ngoài comment thì cũng xử lý hết luôn. Một điều cần thiết nữa, hãy nghĩ lại tại sao bạn lại để xuất hiện những comments này, nếu do bạn chưa biết mà làm sai, hãy yêu cầu PM training cho bạn, nếu do bạn hiểu lầm nên đã làm sai theo ý hiểu của bạn, hãy cố gắng bàn bạc nhiều hơn với anh em trong dự án, và cố gắng đừng vì phải keep deadline, phải tăng năng suất mà làm ẩu, làm không suy nghĩ, hãy nhớ câu “Chậm rùa còn hơn nhanh thỏ” nhé...

4 . Ở bước này, reviewer hãy confirm từng answer của creator cho từng comment/câu hỏi, đừng ngần ngại reject những xử lý chưa đúng, hãy dùng phương pháp facing để trao đổi với nhau những vấn đề chưa hiểu/chưa rõ ràng thay vì mail đi lại quá 3 lần cho cùng 1 vấn đề. Cuối cùng, trước khi kết luận là sản phẩm của creator đạt yêu cầu chất lượng, reviewer nên rà soát lại review checklist của mình xem còn sót lại vấn đề nào chưa xem xét hay không, nếu đã OK rồi thì nên gửi mail confirm officially là sản phẩm đã passed qua phần review của mình.Đến đây có thể bạn đã mệt với mớ lý thuyết của tôi, nhưng tôi tin nếu bạn là người có trách nhiệm với công việc/ với bản thân thì những điều nhỏ nhặt trên đây sẽ tạo nên chất lượng công việc của bạn. Hãy nhớ mỗi người chỉ cần làm tốt phần việc của mình, thì chất lượng công việc chung của cả nhóm đã được nâng lên rất nhiều. Không tin, bạn hãy thử xem.