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ụ.
No comments:
Post a Comment