Khái niệm cơ bản liên quan tới chất lượng – Bài 3: mối liên hệ giữa “Chất lượng và giá” (Quality and Price), và “Chất lượng và chi phí” (Quality and Cost),

Chúng ta đã hiểu rằng giá, giao hàng là những hấp dẫn ban đầu với khách hàng, nhưng để giữ được khách hàng lâu bền thì chất lượng mới là vấn đề đáng bàn. Bài này nói về mối liên hệ giữa “Chất lượng và giá” (Quality and Price), và “Chất lượng và chi phí” (Quality and Cost):

1. Mối liên hệ giữa “Chất lượng và giá” (Quality and Price): Hầu hết mọi người vấn đề quan tâm đầu tiên về một sản phẩm/dịch vụ là giá, rồi mới đến chất lượng. Nếu giá quá cao so với khả năng chi trả, chúng ta thậm chí sẽ chẳng quan tâm đến sản phẩm/dịch vụ đó dù chất lượng của nó tốt thế nào đi nữa. Chúng ta cũng dựa vào giá để so sánh các sản phẩm/dịch vụ với nhau với hy vọng là chúng ta có thể mua được những thứ cùng tính chất (hoặc chất lượng tương đương) với giá rẻ hơn. Khi một mặt hàng/dịch vụ nào đó trở nên khan hiếm, thì giá của nó cũng có xu hướng bị đẩy lên cao, trong khi nếu quá nhiều, giá sẽ thấp hơn bất kể chất lượng của chúng thế nào. Cùng là một mặt hàng, bán ở những cửa hàng khác nhau thì giá bán cũng có thể khác nhau – giảm 50% ở chỗ này, tăng hơn 10% ở chỗ khác. Mua sỉ thì bạn có thể nhận được discount, do vậy bạn hãy trở thành khách buôn chứ đừng thành khách mua lẻ. Nếu bạn là du khách, bạn sẽ dễ dàng nhận thấy mua một món quà lưu niệm tại sân bay sẽ đắt hơn nhiều là ở một cửa hàng tại điểm du lịch, tuy nhiên, bạn cũng sẽ chấp nhận một thực tế là món quà mua được ở cửa hàng có thể là một món đồ bị lỗi hoặc là đồ second hand, còn khi mua ở sân bay, chúng là những mẫu tốt nhất. Có một thực tế là thường là giá cả tăng thì sẽ bao hàm dịch vụ tốt hơn, ví dụ các dịch vụ đi kèm khi một sản phẩm tăng giá là bảo hành tại chỗ, giao hàng miễn phí... Tất cả những điều trên cho thấy mối liên hệ giữa chất lượng và giá còn phụ thuộc vào rất nhiều yếu tố bên ngoài như địa điểm, thời gian, nhu cầu, và giá có thể thương lượng được… nhưng bỏ qua yếu tố thị trường thì giá sẽ tỉ lệ thuận với chất lượng, do vậy, để Fsoft tăng giá thì chúng ta hãy tăng chất lượng? Hoặc chúng ta chấp nhận chất lượng vẫn thế, muốn tăng giá chúng ta sẽ cần thêm các yếu tố thương lượng?

Giá niêm yết trên một sản phẩm / dịch vụ sẽ là cho sản phẩm / dịch vụ đó không có lỗi. Nếu có lỗi nào đó, trên niêm yết cần nói càng chi tiết càng tốt, nếu không thì nhà cung cấp có thể đang vi phạm luật pháp hoặc đạo luật quốc gia. Nếu nhìn theo khía cạnh này, giá của Fsoft có thực sự là đang cho sản phẩm / dịch vụ của chúng ta là không có lỗi, hoặc là vì dịch vụ của chúng ta vẫn đang deliver cho khách hàng các package có lỗi, nên họ thực sự không có ý muốn tăng giá mua với Fsoft?

Sẽ có người tranh luận rằng mua hàng chất lượng thì sẽ đắt, nhưng trên thực tế, việc tiết kiệm được một số tiền bằng cách mua hàng giá thấp là việc bạn bị che mắt với các dịch vụ kém hoặc sự chênh lệch về chi phí duy trì của người sở hữu. Tựa như việc bạn mua hàng giảm giá thì thường sẽ đi kèm điều kiện “mua rồi miễn đổi trả” dù có đúng là hàng lỗi hay không, hoặc mua một xe ô tô kém chất lượng về thì chi phí sửa chữa, bảo dưỡng, tỷ lệ hỏng vặt cũng sẽ khiến khoản tiền bạn tiết kiệm trước đó trở thành vô nghĩa. “Tiền nào của nấy” là tâm lý nên có của người tiêu dùng thông thái. J

2. Mối liên hệ giữa “Chất lượng và chi phí” (Quality and Cost): Đa số các nhà quản trị tin rằng, việc tìm và xử lý lỗi (removal of defects) là chi phí của việc tạo ra các sản phẩm/ dịch vụ, để đạt được chất lượng mong muốn, công ty phải trả cho những người tìm và xử lý lỗi. Vì thế, nếu chúng ta xử lý được hết lỗi (free of defects/ zero defects) thì chúng ta có thể không giảm được chi phí, nhưng chúng ta có cơ hội tăng được sự hài lòng khách hàng và somehow chúng ta sẽ được đền đáp bằng các đơn hàng lớn hơn. Thông thường, phương châm chất lượng của các nhà sản xuất sẽ là:

- Doing the right thing: Làm đúng những gì mà khách hàng yêu cầu, mong muốn -> Fsoft Leakage

- Doing it the right way: Làm đúng cách, theo thứ tự, không cắt xén, bỏ bớt các bước thực hiện -> Fsoft PCV rate

- Doing it the right at the first time: Làm đúng ngay từ đầu, hạn chế rework, sửa lỗi phát sinh -> Fsoft Correction cost

- Doing it ontime without exceeding cost: Làm đúng hạn mà không phát sinh chi phí vượt định mức (budget) -> Fsoft EE, Timeliness

Hiển nhiên, Fsoft cũng đang thực hiện theo phương châm này bằng các công thức QCDP của công ty mà mình đã nêu ở trên. Tất cả những điều trên đều nằm trong chi phí sản xuất của công ty. Tuy nhiên, mình nghĩ rằng có ít người để ý đến chi phí phải bỏ ra khi không làm các điều trên, đó là chi phí phát sinh mà chúng ta phải gánh chịu bởi vì các sai hỏng có thể phát sinh sau đó. Tại thời điểm chúng ta làm dự án, chúng ta không thể biết trước chi phí sau này sẽ là bao nhiêu, chúng ta chỉ có thể biết và dự đoán rủi ro thông qua các bài học vấp ngã trong quá khứ, và tận tâm bỏ công sức để thực hiện đúng phương châm của công ty mà thôi. Mình biết đã có trường hợp dự án stop giữa chừng và khách hàng không trả cho mình một đồng nào mà nguyên nhân là mình đã không “Doing the right thing” (hoặc không hiểu làm thế nào cho đúng), hoặc trường hợp thường thấy bị phạt hợp đồng vì không “Doing it ontime”,… cái mà các PM cần biết là chi phí phát sinh chúng ta phải bỏ ra là như thế nào nếu không đạt chất lượng cam kết để chuẩn bị sẵn hết các trường hợp rủi ro, kể cả việc tính chi phí phát sinh sẽ thế nào và công ty sẵn sàng chấp nhận chi phí đó để keep cam kết chất lượng?

Đối với chi phí trong dự án, chúng ta có thể phân thành chi phí phải chi (unavoidable cost) và chi phí có thể phát sinh (avoidable cost), giống như công ty có chi phí cố định và chi phí dự phòng. Chi phí phải chi bao gồm lương member dự án, các loại tài nguyên, công cụ, máy móc, vận chuyển,... những thứ mà bắt buộc phải chi để vận hành dự án, cái này PM có thể estimate trước, hoặc có khung để chuẩn bị trước. Bên cạnh đó, chúng ta cũng phải bỏ thêm các chi phí để ngăn ngừa (prevention), phát hiện (detection) và xử lý lỗi (removal) – gọi chung là quality cost. Vậy Quality cost là chi phí phải chi hay chi phí phát sinh? Mình muốn đưa ra một số dự toán để chúng ta consider:

- Dự toán 1: Giả sử chi phí phải chi để vận hành dự án được dự toán là 100 đồng, trong đó chi phí ngăn ngừa lỗi là 8 đồng, chi phí phát hiện lỗi là 15 đồng, chi phí xử lý lỗi là 8 đồng, dự toán phát sinh là 10 đồng ngoài chi phí vận hành. -> tổng chi phí dự án có thể phải chi là 110 đồng.

- Dự toán 2: Giả sử chi phí vận hành dự án dự toán là 92 đồng không có dự toán chi phí ngăn ngừa, trong đó chỉ có chi phí phát hiện lỗi là 15 đồng, chi phí xử lý lỗi là 8 đồng, dự toán phát sinh 0 đồng (do PM suy nghĩ là mình sẽ làm tốt nên ko có phát sinh chi phí).

Giả sử bạn là BUL và review và approve 2 bản dự toán trên, bạn sẽ phê duyệt bản nào? Nếu bạn là PM lâu năm, chắc chắn bạn sẽ nghĩ kiểu gì cũng phải phát sinh chi phí sau khi bàn giao sản phẩm cho khách hàng, nên bản dự toán 2 là không thể phê duyệt. Với bản dự toán 1, bạn cũng sẽ có băn khoăn là liệu thực sự mình có cần bỏ ra 8 đồng để ngăn ngừa lỗi hay không, rồi chi phí phát sinh 10 đồng có quá nhiều không khi mà OB chỉ cho mình 110 đồng bmm trong khi EE thì cấp trên giao cho mình là 95%, tức là mình chỉ dc quyền chi tiêu 104 đồng? Chúng ta luôn bị giằng xé giữa việc chịu bỏ ra chi phí chất lượng hay là không, và lập luận để bảo vệ với cấp trên là gì để được phê duyệt? Hãy lập luận với supervisor của chúng ta: Chấp nhận bỏ ra quality cost để làm đúng ngay lần đầu tiên mà chúng ta có thể plan, monitor và adjust chi phí đó, hay bỏ ra chi phí phát hiện và sửa lỗi (bản chất vẫn là quality cost) phát sinh mà chúng ta không lường hết được sau khi đã giao hàng? Ở đây chỉ có một notes nho nhỏ: Vấn đề là chúng ta đang ở level: Không biết sai ở đâu để thay đổi, hay là biết sai nhưng không biết thay đổi thế nào? Câu trả lời cho 2 câu hỏi khác nhau chắc chắn sẽ khác nhau.

Thêm một điều nữa về quality cost mà mình muốn sharing là: Nếu bạn thiết lập cơ chế ngăn ngừa lỗi, bạn sẽ tốn ít chi phí để phát hiện và sửa lỗi. Minh họa của mình là coding convention. Bản chất hoạt động thiết lập, đào tạo, thực hiện và kiểm soát coding convention là một cơ chế để ngăn ngừa lỗi phát sinh trong tương lai cho hoạt động code hiện tại của dự án. Thử tưởng tượng 10 người cùng code 1 hệ thống, tùy tiện mỗi người một phong cách, tự define, tự tạo cơ chế kiểm soát memory riêng, không có cách define biến global, biến private thì mạnh ông nào ông ấy define,… thì chắc các bạn biết hệ thống nó sẽ thế nào rồi nhỉ? Vậy tại sao chúng ta không ngăn ngừa các chi phí phát sinh khi phải đi fix sai hỏng của hệ thống đó ít nhất thông qua coding convention? Thêm nữa, chắc bạn nào học Testing foundation, chắc nhớ đến biểu đồ chi phí phát sinh để sửa lỗi sẽ tăng dần theo từng công đoạn phát triển và phát hiện lỗi, nếu lỗi được tìm thấy ở requirement analysis chúng ta mất 200$ để sửa lỗi đó, thì nếu mãi đến khi vận hành để sửa lỗi thì lỗi đó đã lên đến 15k$, vậy tại sao chúng ta không bỏ các chi phí để ngăn ngừa lỗi ở các công đoạn đầu tiên của dự án?

Ở góc nhìn của kinh doanh, mình đề xuất Fsoft nên coi chi phí ngăn ngừa lỗi là chi phí đầu tư, vì nếu một khách hàng gắn bó với Fsoft lâu dài, bạn có thể thỏa mãn yêu cầu của khách hàng với chi phí thấp hơn (nhiều hoặc ít) so chi phí trước đó bạn đã bỏ ra ở các dự án trước đó, kể cả khách hàng có yêu cầu chúng ta giảm chi phí nội bộ để họ có thể mua hàng với giá thấp hơn, chúng ta vẫn có thể đáp ứng được yêu cầu đó mà vẫn có lãi.

Chất lượng chắc chắn là điều mà mỗi chúng ta đều hướng tới, nhưng làm nó như thế nào, chấp nhận bỏ chi phí thế nào thì chưa chắc mỗi chúng ta đều hiểu. Mình chỉ mong các PM khi thực hiện internal estimation hãy coi Quallity cost là một phần phải có để thực hiện estimating, và hãy estimate thêm các chi phí phát sinh nếu chúng ta không đạt vấn đề chất lượng, chi phí phát sinh đó có thể xảy ra trong quá trình dự án và/hoặc cuối dự án khi chúng ta giao hàng, nếu không được công nhận thì hãy đưa vào risk list để quản lý, sau này chẳng may có các dấu hiệu (trigger của risk) thì giải thích được tại sao chúng ta phải OT, phải thêm resouces, bị khách hàng complain và thậm chí bị stop dự án luôn.

Bạn không thể đạt được tất cả!

Một trong những nguyên nhân phổ biến dẫn đến thất bại của các dự án là donhà tài trợ yêu cầu nhà quản lý dự án phải hoàn thành công việc trong một thời gian nhất định, với ngân sách được cấp và ở quy mô xác định, trong khi vẫn phải đạt được chất lượng thực hiện cụ thể. Nói cách khác, nhà tài trợ quyết định cả 4 yêu cầu ràng buộc của dự án. Cách tiếp cận này không thể đem lại kết quả.

Chúng ta hãy giả định rằng nhà tài trợ yêu cầu dự án phải đạt yêu cầu:
chất lượng thực hiện nhất định, thời gian cụ thể và quy mô xác định. Nhiệm vụ của nhà quản lý dự án là xác định xem cần chi phí bao nhiêu để có thể đạtđược các kết quả đó. Tuy nhiên, tôi luôn cảnh báo các nhà quản lý dự án rằng họ cần đem theo một bác sỹ khi trình bày con số ước định chi phí chonhà tài trợ. Khi nghe con số đó, nhà tài trợ có thể lên cơn đau tim hoặc đột quỵ.Thể nào nhà tài trợ cũng sẽ kêu lên: “Sao nhiều thế?” Bản thân ông ta vốn đãhình dung ra một con số trong đầu, tuy nhiên con số của bạn lại lớn hơnnhiều. Và thế là ông ta có thể nói luôn: “Nếu dự án tốn kém như vậy, chúng tôi không làm được đâu.” Đúng là như vậy! Và đó là quyết định mà ông ta nên đưa ra. Thế nhưng, thông thường thì nhà tài trợ lại tìm cách buộc nhàquản lý dự án phải cam kết triển khai thực hiện dự án với một con số chi phíthấp hơn, và nếu bạn tuân lệnh, thì bạn đã thiết kế ra một cú ngã lớn sau này cho cả bạn và ông ta.

Trách nhiệm của bạn là phải cung cấp cho nhà tài trợ một mức chi phí hợp lý để ông ta có thể đưa ra một quyết định đúng đắn về việc dự án này nên hay không nên triển khai. Nếu bạn để cho mình rơi vào tình trạng buộc phải camkết thực hiện dự án với một con số chi phí thấp hơn, thì những gì diễn ra sauđó sẽ là thảm họa thực sự. Khổ trước sướng thà là bạn chịu đau bây giờ còn hơn là bị “lên đoạn đầu đài” sau này.

Dĩ nhiên còn có một khả năng khác. Nếu ông ta nhất định rằng ông ta chỉ cóthể chi trả được từng đó cho dự án, thì bạn có thể đề nghị giảm quy mô. Nếu công việc có thể điều chỉnh được theo quy mô đó, thì vẫn có thể triển khaithực hiện dự án. Nếu tất cả những khả năng trên không đạt được, thì tốt hơnhết là bạn hãy quên dự án này đi để bắt tay vào một việc khác có thể đem lại lợi nhuận cho công ty.

Có người đã rút ra kết luận rằng các công việc của một dự án có nhiều khả năng bất ngờ gặp rắc rối hơn là bất ngờ biến chuyển tốt đẹp hơn. Xét về góc độ chi phí, điều này có nghĩa là một dự án luôn có khả năng bội chi ngân sách chứ ít khi có chi phí dưới mức dự toán.

Khái niệm cơ bản liên quan tới chất lượng – Khái niệm “Các thuộc tính chất lượng” – Chất lượng sản phẩm

Xin được phép nhấn mạnh đây là bài trọng tâm trong seri chất lượng này, các khái niệm trong bài này chính là điều mà cá nhân mình nghĩ Fsoft nên hướng tới để xây dựng được các hoạt động phát triển phần mềm có chất lượng hơn. Bất kể tính năng sản phẩm hay đặc trưng của dịch vụ mà hướng đến thỏa mãn nhu cầu khách hàng hoặc đạt được sự phù hợp để sử dụng đều được gọi là “Thuộc tính chất lượng”. Với sản phẩm, thuộc tính chất lượng hầu hết hướng đến các tiêu chuẩn kĩ thuật (technical standard), còn với dịch vụ thì thuộc tính chất lượng lại được nhìn theo chiều của nhân sự cung cấp dịch vụ (human capability). Trong bài 5 này, một số thuộc tính chất lượng sản phẩm liên quan tới IT mà mình có thể list ra và lý giải ở bên dưới, tùy từng loại sản phẩm, sử dụng những công nghệ khác nhau, phục vụ mục đích khác nhau mà thuộc tính quality nào sẽ được ưu tiên cao, cái nào sẽ ưu tiên thấp,…

1. Accessibility / Khả năng tiếp cận để sử dụng: Thuộc tính này cho thấy việc user có thể dễ dàng tiếp cận sản phẩm hay không, càng dễ tiếp cận thì sản phẩm càng dễ được user lựa chọn. Ví dụ như S.K.U portal của Fsoft hiện nay vì đang đề cao tính năng bảo mật cho các IP của Fsoft, do vậy chúng ta chưa được phép public internet, điều này dẫn đến khả năng tiếp cận từ bên ngoài công ty bị hạn chế rất nhiều.

2. Availability / Tính sẵn sàng để sử dụng: Thuộc tính này cho thấy khả năng luôn sẵn sàng cho người dùng có thể sử dụng mọi lúc mọi nơi. Ví dụ một công cụ có 10 tính năng được quảng cáo đã sẵn sàng, nhưng khi user trải nghiệm mới biết chỉ có 9 tính năng chạy mượt mà, 1 tính năng mới ở trạng thái thử nghiệm, như vậy chắc chắn user sẽ giảm sự hài lòng với sản phẩm. Một ví dụ khác khi chúng ta bàn giao sản phẩm cho khách hàng ở một mốc deliverables nào đó, khách hàng chắc chắn sẽ mong chờ mức độ availability theo đúng cam kết, giả sử cam kết là sẽ hoàn thành 10 functions, vậy chắc chắn họ sẽ mong chờ 10 functions chạy đúng với với requirements, nếu 1 function có vấn đề, customer satisfaction sẽ giảm xuống.

3. Adaptability / Khả năng thích ứng: Khả năng của một sản phẩm có thể chạy bình thường ở những môi trường khác nhau. Ví dụ dễ thấy nhất là đầu kén đĩa, có những “đầu Tàu” chỉ đọc được một số loại đĩa “xịn” nhất định, đó là do đầu đọc của chúng khả năng thích ứng thấp. Tương tự như vậy, có những phần mềm mà chỉ ứng dụng tốt trong những điều kiện nhất định như cấu hình thiết bị sử dụng cao, điều kiện môi trường lý tưởng (chẳng hạn). Những chiếc đồng hồ chịu nước, hoặc những chiếc camera, smart phone có thể hoạt động dưới nước được chính là ví dụ điển hình cho adaptability cao.

4. Flexibility / Tính linh hoạt: Khả năng thay thế / nâng cấp/ thêm mới một/nhiều tính năng/bộ phận của sản phẩm. Một sản phẩm mà gần như bị fix cứng các tính năng thì sẽ khó hấp dẫn user hơn là các tính năng có thể dễ dàng customize theo từng tập users nào đó.

5. Functionality / Chức năng sản phẩm: Đây gần như là thuộc tính bắt buộc của hầu hết các sản phẩm. Xây dựng một sản phẩm mà chức năng không phục vụ đúng nhu cầu/mục đích sử dụng sản phẩm thì chắc chắn user sẽ không thể ủng hộ sản phẩm đó được. Đồng thời một tiêu chí khác của chức năng sản phẩm là các chức năng cần độc lập, giảm sự phụ thuộc giữa tính năng này và tính năng khác (module hóa). Hiện nay thì thuộc tính chất lượng này đã khá rõ ràng theo từng domain, nhiệm vụ của chúng ta là nghiên cứu và phổ quát thuộc tính này cho các projects mà đã theo từng domain đó.

6. Maintainability / Khả năng bảo trì: khả năng hệ thống có thể dễ dàng thay đổi để đáp ứng nhu cầu/ yêu cầu mới của khách hàng và/hoặc fix các vấn đề của sản phẩm trong giai đoạn vận hành với chi phí thấp. Một sản phẩm trong quá trình vận hành có bug mà mãi không fix được thì coi là khả năng bảo trì thấp, đồng nghĩa với việc giảm sự hài lòng của user. Đồng thời, một sản phẩm mà để maintain được thì user phải bỏ ra chi phí quá cao để maintain thì chắc chắn user cũng sẽ không hài lòng.

7. Operability / Khả năng vận hành: Sự dễ dàng vận hành, quản trị hệ thống. Ví dụ như một hệ thống web form, admin muốn theo dõi, vận hành và kiểm soát hệ thống thì cứ phải chạy hẳn vào back-end và access vào database để quản trị thì sẽ bất tiện hơn nhiều so với việc sử dụng tính năng phân quyền và hoạt động trên front-end của hệ thống.

8. Portability / Khả năng di chuyển trên nhiều platform/framework/environment: Một sản phẩm có thể được thiết lập và chạy ổn định trên nhiều platform/framework/environment, thậm chí cùng một platform nhưng ở những phiên bản mới nhất sản phẩm đó vẫn có thể thiết lập lại được. Ví dụ một ứng dụng chạy tốt trên iOS 9 nhưng khi nâng cấp phiên bản lên iOS 10 thì hầu như không sử dụng được, vậy tính portability của ứng dụng đó là thấp. Portability và adaptability thường sẽ bị lẫn lộn nhưng ở 2 ví dụ cho thấy có sự khác nhau khá rõ ràng cho 2 thuộc tính này.

9. Reliability / Tính ổn định: Khả năng chạy ổn định ở những điều kiện khác nhau ví dụ như lúc giờ cao điểm, rồi khi có quá đông user sử dụng, khi có sự cố,… tính ổn định thường được break thành các hoạt động performance test như performance profiling test, load test, stress test, volumne test,… để kiểm chứng tính ổn định của sản phẩm/hệ thống. Nó cũng có thể được đo bằng sự downtime của hệ thống và thời gian phục hồi (recovering time) khi có sự cố,... tính ổn định cao thì sẽ luôn đảm bảo sự hài lòng của khách hàng.

10. Safety / Tính an toàn: Thuộc tính chất lượng này được tập trung trong các lĩnh vực liên quan tới sự an toàn và tính mạng của con người như Automotive, Healthcare, Factory Manufacturing,… trong thời đại 4.0, tính an toàn càng ngày càng được coi trọng và nó gần như luôn được set ở mức độ ưu tiên cao.

11. Security / Tính bảo mật: Khả năng phân quyền, theo dõi và kiểm soát thông tin cá nhân trong hệ thống, phát hiện và báo động các role lạ, thay đổi/thêm/xóa quyền của user/role trong hệ thống là những tính năng cơ bản đáp ứng tính bảo mật này. Tính bảo mật có thể được xử lý bằng hardware và software, và đi kèm một số khái niệm liên quan tới an ninh mạng: vulnerability – khả năng dễ bị tấn công, threat – mối đe dọa tấn công, risk – rủi ro bị tấn công. Hiện tại Fsoft đang dần chú ý hơn tới thuộc tính security thông qua một số program secure code, thành lập trung tâm SOC,… để đảm bảo sản phẩm source code của chúng ta cung cấp cho khách hàng giảm được rủi ro bị tấn công.

12. Supportability / Khả năng hướng dẫn thiết lập/ sử dụng cho user, hỗ trợ phát hiện và xử lý vấn đề cho user đều sẽ chỉ đến thuộc tính chất lượng này. Có thể nói tính năng diagnostic và auto report của Windows là ví dụ tiêu biểu cho supportability cao hướng tới user.

13. Testability / Khả năng có thể test được. Chắc chắn không một khách hàng nào muốn sử dụng một sản phẩm mà được nói là sản phẩm đó không thể/chưa thể test được. Với vai trò của người cung cấp sản phẩm, chúng ta cần hiểu các tiêu chí yêu cầu có thể test được, nếu một yêu cầu nào đó mà không test được, hãy thay đổi các yếu tố như thời gian, không gian, điều kiện môi trường hoặc bỏ đi yêu cầu đó nếu nó thực sự không thể kiểm chứng được. Kể cả để test được một yêu cầu thì sẽ có nguy hiểm, ví dụ test túi khí trên ô tô, thì chúng ta vẫn phải thực hiện test, giả sử nếu chúng ta không test mà vẫn đưa vào sử dụng, vậy điều gì sẽ đảm bảo túi khí sẽ bung ra khi có tai nạn thật xảy ra? Lúc đó người lái xe sẽ là tester? Và giả sử lúc đó túi khí không hoạt động thì…?

14. Traceability / Khả năng truy vết: Khi làm việc trong lĩnh vực Automotive, mình mới thấy tầm quan trọng của post-mortem meeting, với CMMi thì là cách chúng ta nhìn lại một milestone phát triển sản phẩm, nhưng với Automotive, post-mortem meeting là cuộc họp để thảo luận và tìm ra root cause của một vụ tai nạn giao thông. Trong cuộc họp đó, các vấn đề của người lái xe, các hệ thống hoạt động trên xe và cả hệ thống luật giao thông đường bộ đều được mổ xẻ và tìm root cause. Nếu các nhà phân tích tìm thấy một lỗi trong hệ thống của xe hơi, họ sẽ truy vết để tìm lại lỗi đang nằm trong công đoạn nào/của vendor nào, từ đó các actions để xử lý lỗi, ngăn chặn lỗi không bị lặp lại trong tương lai được định nghĩa và thực hiện. Nếu không thể traceable được, vendor bị điều tra đến sẽ phải tự họ bỏ effort để xử lý vấn đề, và chắc các bạn sẽ tưởng tượng được quality cost sẽ lớn thế nào khi một lỗi đã lọt đến tận giai đoạn production.

Theo mình biết, rất nhiều checklist của khách hàng được xây dựng dựa theo sự hiểu biết và lý giải của họ về các tiêu chí chất lượng này. Checklist của Fsoft somehow cũng có phản ánh một phần các thuộc tính trên, nhưng thực sự để đi lên world class, chúng ta cần đầu tư nghiêm túc để phân tích các thuộc tính chất lượng sản phẩm, phản ánh vào các phương châm chất lượng, review checklist, phương châm test để đảm bảo rằng sản phẩm mà chúng ta làm cho khách hàng sẽ được đảm bảo phù hợp với các thuộc tính chất lượng đã được chỉ ra.

Bài tiếp theo chúng ta sẽ nghiên cứu các thuộc tính chất lượng dịch vụ.

Khái niệm cơ bản liên quan tới chất lượng: Khái niệm “Chất lượng cao và chất lượng thấp, chất lượng tốt và chất lượng xấu”

chúng ta có nên làm chất lượng vượt chuẩn không, vì làm thế thì tốn effort, để effort đó làm việc khác hoặc tiền lời cho Fsoft. Bài này mình chia sẻ về các khái niệm “Chất lượng cao và chất lượng thấp, chất lượng tốt và chất lượng xấu”, và đề xuất câu trả lời cho vấn đề bạn Kiên nêu ra.

Đã bao giờ bạn có suy nghĩ: Sản phẩm/dịch vụ nào đáp ứng được nhu cầu của chúng ta thì đó là sản phẩm/dịch vụ tốt, ngược lại là chất lượng xấu; còn sản phẩm/dịch vụ đáp ứng vượt quá nhu cầu của chúng ta thì đó là sản phẩm/dịch vụ chất lượng cao, ngược lại quá không đạt yêu cầu thì chúng ta gọi là chất lượng thấp? Nếu có, bạn cũng mắc lỗi như mình ban đầu lý giải về vấn đề chất lượng, đó hoàn toàn là nhận định chủ quan của từng cá nhân, và sai lầm này kéo theo một loạt định kiến về chất lượng, bởi vì sản phẩm/dịch vụ này có thể tốt với chúng ta, nhưng lại có thể là dở tệ với một ai đó.

1. Chất lượng cao và chất lượng thấp (High quality and low quality): Khái niệm này xuất hiện đi kèm với những tiêu chuẩn nhất định. Nếu chất lượng vượt quá những tiêu chuẩn đó, chúng ta gọi là sản phẩm/dịch vụ chất lượng cao, ngược lại là thấp, bằng với tiêu chuẩn thì gọi là trung bình (acceptable quality). Từ khái niệm này, định nghĩa level/rating star cho các dịch vụ ra đời và kéo theo đó chúng ta hiểu được giá của các sản phẩm/dịch vụ đó. Điều này cũng giúp chúng ta benchmarking giá của các loại sản phẩm/dịch vụ dễ hơn và user dễ dàng trong việc chọn lựa sản phẩm/dịch vụ phù hợp với mình hơn. Với việc hiểu được khái niệm này, chúng ta mới không bị lẫn lộn với chất lượng tốt/xấu. Chất lượng cao chưa hẳn đã tốt, chất lượng thấp chưa hẳn đã xấu, vì nó còn phụ thuộc vào các cá nhân mua hàng. Một số câu hỏi đặt ra:

- Khi Fsoft định hướng vươn lên tầm world class, giả sử chất lượng đạt được là cao, vậy khách hàng sẽ sẵn sàng trả tiền mua dịch vụ của chúng ta với giá cao hơn?

- Ở chiều ngược lại, nếu chúng ta chất lượng vẫn thế, giá bán vẫn thế thì chúng ta vươn lên world class bằng gì?

2. Chất lượng tốt và chất lượng xấu (Good quality and bad quality): Khái niệm này chính là được đánh giá theo từng khách hàng cụ thể, mức độ đánh giá có thể khác nhau ví dụ như khách hàng Nhật thì thường khó tính hơn khách hàng Âu Mỹ, do vậy điểm đánh giá mức độ hài lòng với Nhật Bản thì thường sẽ thấp hơn các thị trường khác. Tuy nhiên, với các khách hàng thì họ vẫn có những kỳ vọng/yêu cầu/mong muốn nhất định với chúng ta, có thể được phân thành các yếu tố sau:

- Receiving the right product for their use / Nhận được sản phẩm đúng sản phẩm phù hợp với mục đích sử dụng. Ví dụ đơn giản nhất là chúng ta cần gửi 1 file exe để chạy sản phẩm khách hàng cần, nhưng khi nhận được file exe đó, khách hàng click phát tool bị đơ, máy bị treo luôn. Như vậy thì bao nhiêu công lao của anh em trước đó gần như là về 0 luôn. Để ngăn chặn việc này xảy ra, quy trình yêu cầu Final Inspection phải được thực hiện bởi bên thứ 3 – thường là QA vì lúc đó QA sẽ đóng vai trò như khách hàng, đơn giản nhất là nhận sản phẩm, chạy sản phẩm và đóng vai khách hàng để đảm bảo khách hàng sẽ nhận đúng sản phẩm họ cần.

- Being satisfied that their needs have been met (whether it conform to their requirements or not) / Thỏa mãn nhu cầu của khách hàng bất kể chúng có thỏa mãn yêu cầu hay không. Chính vì điểm này mà nhiều dự án có thể đàm phán với khách hàng các mốc deliverables cho một sản phẩm, và cũng có những dự án sẵn sàng đánh đổi chỉ số Timeliness để lùi lịch deliver sản phẩm cũng như, có dự án phải làm việc ngày đêm để keep deadline chỉ đảm bảo cho khách hàng có thể demo với end-user của họ. Miễn là chúng ta lý giải được nhu cầu thực sự của khách hàng, chúng ta sẽ đưa ra được giải pháp tối ưu khi có vấn đề xảy ra trong dự án mà vẫn đem lại sự hài lòng cho khách hàng.

- Meeting their expectations / Thỏa mãn kì vọng của khách hàng. Chắc các bạn đã đồng ý khó nhất là nắm bắt và thỏa mãn kì vọng của khách hàng, nhưng cá nhân mình cho rằng nó cũng khá dễ dàng nếu mình đóng vai trò là khách hàng và có sự benchmarking giữa số tiền mà mình bỏ ra với output sản phẩm/dịch vụ mà mình nhận được. Nếu bạn là PM dự án, trước khi deliver cho khách hàng, hãy tự hỏi: Nếu mình là khách hàng, mình có hài lòng với sản phẩm này không? Nếu câu trả lời không tự tin là “Có” thì có thể là trigger để mình xem xét lại toàn bộ các sản phẩm một lần nữa.

- Being treated with integrity, courtesy and respect / Được đối xử chính trực, lịch sự và tôn trọng. Dĩ nhiên, khi đóng vai một khách hàng thì ai cũng muốn được đối xử chính trực, lịch sự và tôn trọng, kể cả khi khách hàng có nói sai/chưa đúng một điều gì đó, nhiệm vụ của chúng ta vẫn là kiên nhẫn giải thích cho khách hàng và sử dụng ngôn từ nhã nhặn. Đấy là với những khách hàng professional, còn cũng có trường hợp mình biết khi khách hàng quá đáng quá, thì chúng ta cũng nên phản ứng lại để giữ gìn tôn nghiêm của bản thân, team, công ty.

Túm lại, chất lượng cao hay thấp thì cần so sánh với tiêu chuẩn nhất định, còn chất lượng tốt hay xấu thì do chính khách hàng so sánh theo thang điểm mà họ tự đánh giá. Chất lượng cao chưa hẳn đã tốt, chất lượng thấp chưa hẳn đã xấu, chỉ có chất lượng phù hợp với nhu cầu của khách hàng mà thôi.

Mình đoán là nhiều bạn PM chưa tự đặt mình vào vị trí khách hàng để phân tích, hiểu nhu cầu và chuẩn bị thật tốt các deliverables đạt được kì vọng của khách hàng, hãy thử một vài lần xem sao.

Khái niệm cơ bản liên quan tới chất lượng – Bài 2: Giá, chất lượng, và giao hàng.

Bài 2: Giá, chất lượng, và giao hàng.

Ở bài trước, chúng ta đã nói đến các khái niệm: Nhu cầu, yêu cầu, mong muốn, và kỳ vọng. Ở bài này mình chia sẻ tiếp các khái niệm: Giá (Price), chất lượng (Quality) và giao hàng (Delivery), mối liên quan của 3 khái niệm này.

Trước hết, phải khẳng định Giá, Chất lượng và Giao hàng là 3 tham số quan trọng để xác định khả năng bán được hàng của một sản phẩm/dịch vụ. Khách hàng thường yêu cầu sản phẩm/dịch vụ phải đạt được một số tiêu chuẩn chất lượng nhất định, giao hàng đúng ngày họ cần và giá cả cần phản ánh đúng giá trị đồng tiền họ bỏ ra để mua sản phẩm/dịch vụ đó. Một tổ chức sẽ luôn tồn tại và phát triển nếu tổ chức đó tạo ra và giữ được sự hài lòng của khách hàng, điều này chỉ đạt được nếu chúng ta đưa ra các sản phẩm/dịch vụ đáp ứng được nhu cầu, yêu cầu, cũng như kỳ vọng của khách hàng. Cùng là một khách hàng, mọi yếu tố đều mang tính thời điểm, do vậy, xác định đúng kỳ vọng của khách hàng tại một thời điểm sẽ là điểm quyết định cho việc duy trì sự hài lòng của khách hàng: có lúc giảm giá sẽ đáp ứng nhu cầu, có lúc giao hàng đúng thời điểm (ví dụ đảm bảo thời gian lên kệ của 1 sản phẩm nào đó), có lúc lại là tăng chất lượng sản phẩm lên một mức độ chất lượng cao hơn,…

Nếu giá là chức năng của chi phí (cost), tỷ suất lợi nhuận (profit margin), nguồn lực thị trường (market forces); và giao hàng là chức năng của sự hiệu quả và hiệu suất của tổ chức, thì chất lượng được xác định theo mức độ mà một sản phẩm hoặc dịch vụ phục vụ thành công mục đích của người dùng trong quá trình sử dụng (không chỉ tại điểm bán hàng). Tức là, tại thời điểm sale khách hàng hoàn toàn có thể tin rằng chúng ta có thể giao hàng theo cam kết, với giá được niêm yết (và khách sẵn sàng trả), nhưng chất lượng thì chỉ khi họ nhận hàng, kiểm tra (test/review/inspection) thì họ mới kết luận được chất lượng có đạt yêu cầu (hay cao hơn là đạt kỳ vọng) hay không. Cả giá và giao hàng thì đều chỉ là những yếu tố tạm thời (tại thời điểm bán hàng), trong khi đó sự ảnh hưởng của vấn đề chất lượng thì sẽ kéo dài sau khi sự hấp dẫn / nỗi đau của giá và giao hàng lắng xuống. Tức là coi như khách hàng sẽ đặt hàng chúng ta vì giá cả hấp dẫn, giao hàng đúng thời điểm họ mong muốn, vậy thì yếu tố khiến họ tiếp tục đặt hàng chúng ta là do vấn đề chất lượng. Đặt vấn đề với Fsoft: phải chăng chúng ta chưa thay đổi được hình ảnh bán hàng giá cả cạnh tranh, quân số đông để có thể bán đúng giá (hoặc nâng giá với các khách hàng hiện tại) là vì chúng ta chưa thực sự đạt đến mức độ chất lượng (extent of quality) như kỳ vọng của khách hàng? Ở một view khác, có khách hàng nói là họ đã thuê Fsoft với giá khá cao (cao hơn mức thuê trung bình mà họ có thể chấp nhận), nhưng sau đó họ nhận được một sản phẩm mà chất lượng phù hợp với nhu cầu của họ, vậy theo các bạn thì họ có tiếp tục/sẵn sàng thuê Fsoft với giá cao như vậy không? Tôi thì đoán là họ sẽ thuê tiếp. Chốt lại, giá và giao hàng là cái để hấp dẫn khách hàng thời điểm ban đầu, nhưng chất lượng sẽ là cái níu giữ khách hàng lâu dài.

Như trên chúng ta đã thấy chất lượng là vấn đề có thể níu chân khách hàng, vậy chúng ta sẽ đi sâu vào khái niệm chất lượng, chất lượng là gì? Cũng giống như anh Nam già đã chia sẻ, có khá nhiều định nghĩa về khái niệm chất lượng: Mức độ xuất sắc (degree of excellent), sự đáp ứng các yêu cầu (conformance with requirements), tập hợp các thuộc tính của sự vật để thỏa mãn những nhu cầu đã được/chưa được phát biểu (satisfy stated or implied needs), phù hợp để sử dụng (fitness for use), không còn lỗi (freedom of defects), hoặc một thuật ngữ đang ngày càng trở nên phổ biến “làm khách hàng sửng sốt” (delighting customer). Với cá nhân của mình, mình thường sử dụng thuật ngữ “phù hợp để sử dụng” (fitness for use) làm phương châm để đánh giá vấn đề chất lượng. Ví dụ, nếu 1 công ty thiết lập giá trị tiêu chuẩn chất lượng (quality standard norms) của công ty không phù hợp với nhu cầu của khách hàng, khách có thể phàn nàn là chúng tôi không thấy sản phẩm của các bạn có chất lượng (mặc dù chúng ta sản xuất ra sản phẩm đạt tiêu chuẩn của chúng ta). Ngược lại, một công ty có chất lượng cao vượt quá yêu cầu của khách, họ có thể nghi ngại giá họ sẽ phải bỏ ra quá lớn so với khả năng chi trả. Tóm lại, người đánh giá, nhận xét, phản biện cuối cùng về chất lượng sản phẩm/dịch vụ là khách hàng. Nhà cung cấp (như Fsoft) hãy luôn có mindset chấp nhận khách hàng là người duy nhất đánh giá hài lòng hay không, điều này cũng được thể hiện qua CSS, hay sự tăng giảm của giá trị bán hàng, hay việc stop một business với một khách hàng nào đó, câu hỏi đặt ra ở đây: Fsoft đã thực sự coi trọng việc phân tích kết quả feedback từ khách hàng?

Nếu các bạn có các định nghĩa khác, hoặc tâm đắc với một định nghĩa nào đó về khái niệm “chất lượng”, các bạn hay share cho mình để cùng phản biện và hiểu đúng về khái niệm này nha.

Bài tiếp theo sẽ là mối liên hệ giữa “Chất lượng và giá” (Quality and Price), và “Chất lượng và chi phí” (Quality and Cost), từ đó dẫn đến các khái niệm “Chất lượng cao và chất lượng thấp, chất lượng tốt và chất lượng xấu”

Khái niệm cơ bản liên quan tới chất lượng phần mềm - (1) Nhu cầu, Yêu cầu, Mong muốn, và Kỳ vọng.

Bài 1: Nhu cầu, Yêu cầu, Mong muốn, và Kỳ vọng.

Nhân bài của anh Nam già: "Chất lượng là gì", mình xin sharing những lý giải của mình một cách đơn giản nhất, dễ hiểu nhất về các khái niệm chất lượng. Mình rất vui nếu các anh chị em đọc và phản biện các lý giải của mình, để chúng ta hiểu hơn vấn đề chất lượng, từ đó các bạn hiểu hơn về con đường trở thành chuyên nghiệp.

Trước khi đi vào khái niệm “chất lượng”, mình giải thích một số khái niệm liên quan: Nhu cầu (needs), yêu cầu (requirements), mong muốn (wants), và kỳ vọng (expectation). Mình nghĩ rằng nhiều bạn thường nhầm lẫn và sử dụng sai các khái niệm này, dẫn đến các hiểu lầm trong việc tạo ra các sản phẩm và dịch vụ có chất lượng.

- Nhu cầu (Needs): Là những thứ cần thiết cho cuộc sống để duy trì một trạng thái ở một tiêu chuẩn nhất định – tháp nhu cầu của Maslow là dùng để chỉ khái niệm này. Ví dụ đơn giản là nhu cầu sinh tồn của con người là có cái để ăn, có không khí để hít thở, có nước để uống; khi con người đang sống trong các hình thái xã hội cao hơn thì nhu cầu cũng cần được đáp ứng ở tiêu chuẩn cao hơn như hạ tầng, phương tiện giao thông, dịch vụ,… Còn đối với một sản phẩm/dịch vụ thì nhu cầu là những điều cần thiết để đáp ứng mục đích sử dụng khi người tiêu dùng mua sản phẩm/dịch vụ đó. Ví dụ: Cùng là mua một chiếc ô tô, người có nhu cầu mua xe nhưng phải tiết kiệm chi phí xăng dầu, bảo dưỡng thì sẽ nhắm mua những ô tô giá tiền vừa phải, tiêu thụ ít xăng (~6l/100km); người có nhu cầu chứng tỏ mình là doanh nhân thành đạt thì có thể chọn mua Mercedez, Lexus,… ở phân khúc hạng sang; người muốn thỏa mãn thú chơi tốc độ và cũng chứng tỏ mình có tiền thì chơi xe ở phân khúc hạng siêu sang, tốc độ cao mà ko quan tâm đến chi phí bảo dưỡng, xăng dầu có thể gấp trăm lần loại xe tiết kiệm… Về cơ bản nhu cầu rất đa dạng và có thể hoặc không thể phát biểu thành lời, nhưng nếu những người bán hàng (sale), người cung cấp dịch vụ (service provider) hiểu khách hàng, đánh đúng vào tâm lý, nhu cầu của khách hàng thì sẽ dễ bán được hàng và làm hài lòng khách hàng bất kể sản phẩm/dịch vụ đang cung cấp với tiêu chuẩn chất lượng cao hay thấp (siêu sang, sang hay tiết kiệm/kinh tế)

- Yêu cầu (Requirements): Là những câu phát biểu để người khác có thể thực hiện/cung cấp đúng những gì mà chúng ta mong muốn, yêu cầu có thể bao gồm hoặc không bao gồm nhu cầu, nhưng thường chúng ta không thể nói rõ nhu cầu của chúng ta là gì cho đến khi chúng ta phát biểu được các yêu cầu là gì. Ví dụ: Đối với yêu cầu phát triển hệ thống hỗ trợ sử dụng di động trong khi đang lái xe, yêu cầu này sẽ là thừa với những nước chưa phát triển, nhưng với các nước phát triển và smart phone đã trở thành một trong những công cụ giao tiếp cơ bản, thì hệ thống này thực sự là một trong những nhu cầu cần thiết của các cư dân thành thị nơi đó. Hiểu được mối liên hệ giữa yêu cầu và nhu cầu, chúng ta có thể cân nhắc tư vấn khách hàng thêm/ thay đổi/ bỏ đi yêu cầu dựa vào nhu cầu thực sự của khách hàng.

- Mong muốn (Wants): Những điều thêm vào có thì tốt, không có cũng không sao, và/hoặc có sẽ tốt hơn nhưng không cần thiết. Yêu cầu cũng sẽ bao gồm cả mong muốn, do vậy, nếu muốn giảm scope của khách hàng thì thường chúng ta sẽ bỏ đi các yêu cầu là mong muốn của khách hàng, vì có hay không có các mong muốn này thì cũng không ảnh hưởng tới nhu cầu của khách.

- Kỳ vọng (Expectations): Kỳ vọng thường ngụ ý cả nhu cầu (needs) và yêu cầu (requirements). Kỳ vọng thường không được phát biểu rõ bằng lời vì khách hàng coi đó là đương nhiên, có thể hiểu là một dạng tiêu chuẩn chấp nhận được, cũng giống như khi chúng ta bước vào một nhà hàng sang trọng, chúng ta sẽ kì vọng nhà hàng sẽ phục vụ chu đáo, đón tiếp lịch sự, đồ ăn ngon, chúng ta sẽ không phát biểu kỳ vọng ra bằng lời mà thông qua các dịch vụ của nhà hàng đó họ sẽ đáp ứng/hoặc không đáp ứng kỳ vọng của khách. Kỳ vọng có thể là những thứ quen thuộc với chúng ta dựa trên thời trang, phong cách, xu hướng, hoặc các kinh nghiệm trong quá khứ. Ví dụ: các sale man thì thường phải lịch thiệp và nhã nhặn, các sản phẩm điện tử thì phải an toàn và đáng tin cậy khi sử dụng, cảnh sát thì phải trung thực,… là những kỳ vọng thường thấy trong xã hội. Theo kinh nghiệm của mình thì khó có thể nói nhu cầu hay yêu cầu quyết định sự đáp ứng/không đáp ứng kỳ vọng của khách hàng, nhưng mình thấy ít nhất nếu chúng ta hiểu được đúng nhu cầu của khách hàng thì họ sẽ không phát biểu sự thất vọng của họ với các sản phẩm/ dịch vụ của chúng ta.

Trên đây là 4 khái niệm đầu tiên tác động tới Fsoft, một công ty cung cấp các dịch vụ/ sản phẩm IT cho khách hàng trên 3 yếu tố: Giá (price), chất lượng (quality) và bàn giao (Delivery).