Quản lý chất lượng của dự án

21/03/2022 Nguyen Manh Bình luận 0 Bình luận

Chất lượng của sản phẩm

Tưởng tượng bạn bỏ tiền ra mua 1 phần mềm trên Apple Store hoặc Google Play, nhưng khi sử dụng thì bị đơ máy hoặc thi thoảng thông tin hiển thị sai. Lúc đó, chắc chắn ai cũng có cảm giác không thoải mái, thậm chí là muốn xóa ngay ứng dụng trong thiết bị của mình, thậm chí sẽ không bao giờ cài đặt lại ? Nếu là tôi chắc là tôi sẽ làm vậy, và cũng sẽ không bao giờ mua các sản phẩm khác của nhà phát triển đó nữa. Đặt khách hàng vào vị trí người mua sản phẩm, bạn là nhà phát triển thì chắc chắn bạn sẽ hiểu được tầm quan trọng và vai trò của chất lượng. Chất lượng thường tỉ lệ thuận với độ hài lòng của khách hàng.

Thương hiệu “Made in Japan”

Tôi nhận thấy một hiện tượng khá phổ biến không chỉ ở Việt Nam mà có lẽ trên toàn thế giới, đó là mọi người rất thích mua những sản phẩm “made in Japan” cho dù giá của nó thường khá đắt. Cụm từ “made in Japan” chỉ xuất xứ được ghi trên sản phẩm không phải là tên thương hiệu của sản phẩm nhưng có một sức mạnh vô hình nào đó mà bất cứ sản phẩm nào có ghi những dòng chữ này đều được phần lớn người tiêu dùng yêu thích, lựa chọn.

Dòng chữ đó như trở thành một “thương hiệu” nổi tiếng. Lý do đơn giản đó là vì “chất lượng”. Sản phẩm được sản xuất ở Nhật có chất lượng rất cao và rất bền. Do đó, mặc dù được bán với chi phí đắt hơn mặt bằng chung, nhưng lại rất nổi tiếng và được nhiều người Việt Nam ưa thích và mua về. Quan điểm về chất lượng của người Nhật rất cao. Họ thường có yêu cầu rất khắt khe về chất lượng.

Tình hình chất lượng dự án em đang như thế nào?

Có lần tôi hỏi một bạn quản lý dự án là “tình hình chất lượng dự án em đang như thế nào?”. Bạn ấy trả lời là “ổn anh ạ!”. Khi tôi hỏi thêm một câu nữa “cụ thể ổn như thế nào hả em?”. Thì bạn ấy lúng túng ngãi đầu một lúc rồi trả lời “là đang không có vấn đề gì anh ạ”.

Nếu không phải là tôi mà là khách hàng hỏi bạn là “tình hình chất lượng của dự án đang như thế nào, gửi cho họ có một bản báo cáo để hiểu được tình hình chất lượng của dự án”, thì bạn sẽ làm gì? Bạn có trả lời là “ổn anh ạ” không? Để trả lời những câu hỏi này đầu tiên bạn cần hiểu về các tiêu chí chất lượng và cách quản lý chất lượng của dự án.

Những tiêu chí đánh giá chất lượng dự án

Theo tiêu chuẩn chung của ISO thì có rất nhiều tiêu chí để đánh giá chất lượng của một sản phẩm phần mềm

Tính chức năng (Functionality): Đầy đủ tính năng, hoạt động chính xác và ổn định.
Tính tin cậy (Reliability): Khả năng chịu lỗi, bảo đảm tính toàn vẹn dữ liệu.
Tính hiệu quả (Efficiency): Hiệu quả làm việc, sử dụng tài nguyên
Tính sử dụng (Usability): Khả năng dễ sử dụng và vận hành hệ thống
Tính bảo trì (Maintainability): Khả năng dễ dàng bảo trì và mở rộng hệ thống
Tính tương thích (Portability): Khả năng tích hợp với các hệ thống khác
Tính bảo mật (Security): Khả năng bảo mật dữ liệu người dùng, ngăn chặn tấn công từ bên ngoài và ngăn chặn rò rỉ dữ liệu

Trên đây, tôi chỉ tổng hợp một số tiêu chí chung về chất lượng hay được nghe nói đến nhất, nội dung này hơi chung chung và trừu tượng nên có thể bạn sẽ cảm thấy khó hiểu. Nội dung này chỉ để bạn dễ hình dung và mang tính chất tham khảo, ở nội dung tiếp theo tôi sẽ giải thích chi tiết hơn về khái niệm quản lý chất lượng dự án và các hoạt động cụ thể để đảm bảo chất lượng của dự án.

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

Chất lượng sản phẩm là khả năng đáp ứng nhu cầu và kỳ vọng của khách hàng và người dùng của sản phẩm đó.

Tức là chất lượng sẽ phụ thuộc vào khách hàng và người dùng nên thực sự là rất khó để có định nghĩa chính xác. Chất lượng được đo bởi sự thỏa mãn nhu cầu, do đó nếu sản phẩm không đáp ứng được nhu cầu của khách hàng và người dùng thì đương nhiên bị coi là kém chất lượng.

Tuy nhiên chính vì chất lượng được đo bởi sự thỏa mãn nhu cầu mà nhu cầu luôn luôn biến động nên chất lượng cũng luôn luôn biến động theo thời gian, không gian và điều kiện sử dụng. Do đó, để quản lý được chất lượng thì đầu tiên bạn cần hiểu được nhu cầu và kỳ vọng của khách hàng là gì. Định nghĩa chi tiết thành mục tiêu chất lượng thì bạn mới có thể quản lý được. Thường thì các yêu cầu này sẽ được miêu tả trong tài liệu đặc tả hệ thống.

Quản lý chất lượng dự án là việc thực hiện các hoạt động của chức năng quản lý nhằm đảm bảo cho dự án thỏa mãn tốt nhất các yêu cầu và mục tiêu chất lượng đề ra.

Trong tài liệu mô tả yêu cầu thì yêu cầu về chất lượng sẽ được chia làm 2 phần chính: một là yêu cầu về tính năng, và hai là yêu cầu phi tính năng. Nếu trong tài liệu không miêu tả yêu cầu chất lượng một cách cụ thể thì thường là sẽ tự hiểu là bạn cần cung cấp phần mềm có đầy đủ tính năng và có càng ít lỗi càng tốt, tốt nhất là không có lỗi. Và nhiệm vụ của bạn là phải tự thiết lập mục tiêu chất lượng cụ thể cho dự án.

Quản lý chất lượng là các công việc nhằm đảm bảo chất lượng của dự án theo đúng như kỳ vọng thông qua những hoạt động dưới đây:

Xác định mục tiêu chất lượng (các tiêu chuẩn chất lượng)
Định nghĩa các quy trình đảm bảo chất lượng.
Theo dõi đảm bảo chất lượng
Kiểm soát chất lượng.

Xác định mục tiêu chất lượng

Như tôi đã giải thích ở trang trước đó, chất lượng sản phẩm phụ thuộc vào nhu cầu của khách hàng. Để thiết lập được mục tiêu chất lượng bạn cần hiểu được kỳ vọng của khách hàng. Những kỳ vọng đó thường được thể hiện qua yêu cầu về tính năng và yêu cầu phi tính năng. Nhiều khách hàng không định nghĩa cụ thể được các mong muốn về chất lượng của họ. Trong trường hợp đó, bạn nên trao đổi với họ để làm rõ về các tiêu chí khi nghiệm thu. Mục tiêu chất lượng của dự án thường sẽ được xác định dựa vào các tiêu chí nghiệm thu này. Hãy hỏi khách hàng xem họ có tiêu chí gì khi thực hiện nghiệm thu sản phẩm (UAT) hay không. Nếu khách hàng cũng không có tiêu chí cụ thể thì bạn sẽ phải tự đặt ra mục tiêu và thống nhất với khách hàng. Khi thiết lập mục tiêu chất lượng chúng ta sẽ bám theo 2 loại yêu cầu sau:

Yêu cầu tính năng:

Số lượng tính năng đầy đủ
Hoạt động chính xác và ổn định (tức là ít lỗi nhất có thể)

Yêu cầu phi tính năng:

Một số yêu cầu về phi tính năng phổ biến bạn có thể quan tâm như là:

Mật khẩu phải được mã hoá (1 chiều hay 2 chiều).
Tuân thủ nguyên tắc khi lập trình (Coding Conventions).
Tốc độ tải trang và tốc độ xử lý.
Số lượng người dùng có thể sử dụng đồng thời.
Khả năng chịu tải của máy chủ.
Không lưu thông tin thẻ tín dụng trên cơ sở dữ liệu.
Dung lượng của file upload.

Tuỳ từng khách hàng, từng dự án và tuỳ theo lĩnh vực của sản phẩm sẽ có những yêu cầu khác nhau. Thường thì các dự án về tài chính sẽ có yêu cầu rất cao về tính bảo mật. Nếu khách hàng thuộc dự án bạn đang quản lý không có yêu cầu phi tính năng cụ thể thì bạn cần đề xuất và tư vấn cho khách hàng các yêu cầu này.

Khi khách hàng không có yêu cầu về tính năng cụ thể thì mọi người thường tự ngầm hiểu với nhau là đội dự án cần cung cấp phần mềm có đầy đủ tính năng, càng ít lỗi càng tốt và tốt nhất là không có lỗi. Điều đó có nghĩa là, nếu không có thống nhất gì thì khách hàng sẽ kỳ vọng ngầm là ”không phát sinh lỗi khi nghiệm thu sản phẩm”. Tôi thường hay đặt mục tiêu là sau khi đội dự án giao sản phẩm cho khách hàng nghiệm thu sẽ không còn lỗi. Đây là mục tiêu rất thử thách và rất rủi ro, do vậy bạn nên có chiến lược và các tương tác rất rõ ràng về chất lượng thì mới nên đặt mục tiêu này.

Số lượng lỗi cho phép khi nghiệm thu

Nếu không có gì đặc biệt thì tôi khuyên bạn đặt mục tiêu dựa trên yêu cầu tính năng, mà cụ thể là xác định số lỗi có thể cho phép ở giai đoạn nghiệm thu.

Ví dụ như: chỉ số lỗi cho phép ở giai đoạn nghiệm thu trung bình là 0.15 bug/MM (man months). Nếu dự án của bạn có 7 người làm trong 3 tháng tương ứng với tống số 21 MM thì số lượng lỗi nghiệm thu phát sinh cho phép là 0.15 * 21 = 3 bugs. ( Chú ý: chỉ số 0.15 bugs/MM là chỉ số theo kinh nghiệm của tôi, nếu bạn chưa có thì có thể dùng tạm để tính toán, nhưng nên đánh giá phù hợp với khả năng thực tế trong dự án của bạn). Đương nhiên chúng ta cũng cần tự hiểu với nhau là sau khi nghiệm thu xong, thì sản phẩm đã được đảm bảo chất lượng, cơ bản là sẽ không còn lỗi nữa. Nếu bạn lại tiếp tục đặt mục tiêu số lượng bug cho phép sau nghiệm thu thì sẽ có rất ít khách hàng có thể chấp nhận được.

Định nghĩa các quy trình đảm bảo chất lượng.

Thông thường một dự án sẽ thực hiện các hoạt động sau để đảm bảo chất lượng: Review code, Unit Test, Integration Test, nghiệm thu. Cũng có một số dự án yêu cầu thực hiện thêm quy trình Performance Test hoặc Security Test. Do đó, bạn cần phải định nghĩa các quy trình đảm bảo chất lượng cho dự án của mình, thống nhất với đội dự án của mình và thống nhất với khách hàng là sẽ đảm bảo việc thực hiện đầy đủ các quy trình đó để đảm bảo chất lượng.

Ứng với mỗi quy trình sẽ có những tiêu chuẩn và yêu cầu riêng. Chất lượng của dự án được cụ thể hoá thành các chỉ số yêu cầu đối với sản phẩm.

Review code (giai đoạn rà soát mã nguồn): cần định nghĩa tần suất thực hiện, người thực hiện, và các quy tắc thực hiện rà soát mã nguồn

Unit Test (giai đoạn xây dựng mã nguồn kiểm thử đơn vị): cần định nghĩa cụ thể mức coverage (độ bao phủ).

Integration test (kiểm thử tích hợp): Cần định nghĩa tỷ lệ lỗi phát sinh trong giai đoạn này. Tôi thường đặt tỉ lệ này là 0.25 bugs/md (man days). Tức là trong 1 tháng, các phần công việc được làm của 1 lập trình viên chỉ được phát sinh tối đa là 5 lỗi khi tiến hành kiểm thử, nếu số lượng lỗi vượt quá tỉ lệ này thì chức năng tương ứng sẽ bị dừng kiểm thử để lập trình viên kiểm tra lại toàn bộ mã nguồn.

UAT Test (giai đoạn nghiệm thu sản phẩm): Ở đây, tiêu chuẩn về tỉ lệ lỗi đã được đặt ra từ trước, bạn cần bổ sung thêm thời gian dự phòng trong trường hợp cần sửa lỗi ở giai đoạn này.

Ngoài các quy trình trên, nếu có yêu cầu phi chức năng hoặc yêu cầu nào khác về quy trình đảm bảo chất lượng thì bạn cũng cần phải định nghĩa rõ ràng các tiêu chi và các bước thực hiện sau đó lên kế hoạch và thống nhất với team và khách hàng.

Theo dõi giám sát chất lượng

Bước này là cần theo dõi và đảm bảo dự án được tiến hành đúng theo các quy trình đảm bảo chất lượng đã được định nghĩa. Đảm bảo việc review , tần suất review, test được thực hiện đầy đủ và triệt để. Bao gồm cả việc cập nhật tình hình một cách đầy đủ và chính xác trên các công cụ quản lý cũng là những việc cần làm để đảm bảo chất lượng. Thực hiện tổng hợp và phân tích lỗi và các vấn đề trong dự án để theo dõi được chính xác tình hình hiện tại của dự án.

Kiểm soát chất lượng

Thực hiện việc phân tích, đánh giá, điều chỉnh các kết quả được lưu lại trong quá trình theo theo dõi đảm bảo chất lượng. Xác định nguyên nhân của các quy trình kém chất lượng để có hành động loại bỏ chúng.

Một trong những hoạt động quan trọng trong quản chất lượng lý dự án là thực hiện phân tích các lỗi phát sinh (bug list). Đó là việc phân loại lỗi, phân loại nguyên nhân, qua đó có thể phán đoán và đánh giá đâu là nguyên nhân gây là nhiều lỗi nhất. Trong trường hợp này chúng ta có quy tắc 80/20 thường được áp dụng, tức là 80% lỗi phát sinh do 20% nguyên nhân gốc rễ gây ra. Tập trung xác định và giải quyết 20% nguyên nhân chính này sẽ giải quyết được 80% số lượng lỗi. Để cải thiện chất lượng đầu tiên chúng ta nên tập trung vào nhóm các loại lỗi này.

Thậm chí quy tắc này còn áp dụng với con người, 80% lỗi do 20% thành viên trong dự án gây ra, nên có tác động để những thành viên này cải thiện.

Quản lý chất lượng dự án là quá trình liên tục từ đầu đến cuối dự án và Quản lý chất lượng dự án là trách nhiệm chung của tất cả các thành viên. Đó là phương châm tôi thường xuyên nhắc đi nhắc lại trong các dự án mà mình quản lý. Không phải chỉ có Tester mới là người cần phải thực hiện đảm bảo chất lượng, mà Developer là người đầu tiên cần phải thực hiện điều đó, Developer cần phải đảm chất lượng từng dòng code khi họ viết ra. Để dự án thành công thì dự án cần phải có chất lượng tốt, mà để đạt được điều đó thì từng người từng người cần có ý thức để làm tốt từng công việc của mình ngay từ đầu, và đảm bảo chất lượng của từng công việc của mình.

Đối với Tester, thì tôi có quan điểm: Tester là người chốt chặn cuối cùng về chất lượng sản phẩm trước khi gửi cho khách hàng. Tức là sau khi Tester thực hiện kiểm thử và đánh giá là đạt thì sản phẩm sẽ được chuyển giao cho khách hàng. Đương nhiên là Tester cần có trách nhiệm đối với từng test case họ viết ra. Nhiệm vụ của Tester không đơn thuần chỉ là thực hiện hết số test case họ viết ra, mà là tìm ra tất cả những lỗi có thể có của sản phẩm, giống như thủ môn của đội bóng, nhiệm vụ của họ là không để một quả bóng nào lọt vào trong lưới. Để làm được điều đó thì ngoài testcase, bạn cần phải suy nghĩ phán đoán những trường hợp đặc biệt, những trường hợp giới hạn, những trường hợp ngoại lệ hoặc những trường hợp dễ có khả năng gây lỗi để nhanh chóng phát hiện và xử lý trong quá trình phát triển.

Luôn luôn chú ý đến việc cải tiến quy trình, template, checklist, guideline, rule … của dự án để cải tiến chất lượng cho dự án.