Đề tài Thực trạng và giải pháp cắt giảm chi phí chất lượng trong dự án phát triển phần mềm ở công ty TNHH thiết kế Renesas Việt Nam

Đề tài: GVHD: TS. TRƯƠNG THỊ LAN ANH LỚP : QTKD ĐÊM 2 K22 HVTH: ĐẶNG PHÚ QUỐC TP HỒ CHÍ MINH 05/2014 TRƯỜNG ĐẠI HỌC KINH TẾ TP. HỒ CHÍ MINH VIỆN ĐÀO TẠO SAU ĐẠI HỌC KHOA QUẢN TRỊ KINH DOANH TIỂU LUẬN CÁ NHÂN THAY ĐỔI VÀ PHÁT TRIỂN TỔ CHỨC THỰC TRẠNG VÀ GIẢI PHÁP CẮT GIẢM CHI PHÍ CHẤT LƯỢNG TRONG DỰ ÁN PHÁT TRIỂN PHẦN MỀM Ở CÔNG TY TNHH THIẾT KẾ RENESAS VIỆT NAM NỘI DUNG: PHẦN MỞ ĐẦU  .........................................................................................................................................  1   Chương 1: CƠ SỞ LÝ THUYẾT  ....................................................................................................................  3   1.1   Lý thuyết về chi phí chất lượng(Costs of Quality)  .......................................................................  3   1.2   Phân loại chi phí chất lượng  .........................................................................................................  3   1.2.1   Chi phí phòng ngừa (Prevention Costs)  ...............................................................................  4   1.2.2   Chi phí kiểm tra, đánh giá (Appraisal Costs)  .......................................................................  4   1.2.3   Chi phí hư hỏng (Failure Costs)  ...........................................................................................  4   Chương 2: THỰC TRẠNG VỀ CHI PHÍ CHẤT LƯỢNG TRONG DỰ ÁN PHÁT TRIỂN PHẦN MỀM TẠI CÔNG TY TNHH THIẾT KẾ RENESAS VIETNAM  ....................................................................................  6   2.1   Vài nét về công ty TNHH Thiết Kế Renesas Vietnam  .................................................................  6   2.2   Quy trình một dự án phát triển phần mềm của công ty  ................................................................  6   2.2.1   Phân tích yêu cầu khách hàng  ..............................................................................................  6   2.2.2   Thiết kế hệ thống  .................................................................................................................  7   2.2.3   Thiết kế chi tiết  ....................................................................................................................  7   2.2.4   Viết mã nguồn  ......................................................................................................................  7   2.2.5   Kiểm thử  ..............................................................................................................................  8   2.2.6   Phát hành  ..............................................................................................................................  8   2.3   Nhận diện và tính chi phí chất lượng  .........................................................................................  11   2.3.1   Phân tích yêu cầu khách hàng  ............................................................................................  13   2.3.2   Thiết kế hệ thống  ...............................................................................................................  14   2.3.3   Thiết kế chi tiết  ..................................................................................................................  14   2.3.4   Viết mã nguồn  ....................................................................................................................  15   2.3.5   Kiểm thử  ............................................................................................................................  15   2.3.6   Phát hành  ............................................................................................................................  16   2.4   Nhận xét về chi phí chất lượng  ..................................................................................................  17   Chương 3: CÁC CAN THIỆP OD NHẰM CẮT GIẢM CHI PHÍ CHẤT LƯỢNG TRONG DỰ ÁN PHÁT TRIỂN PHẦN MỀM  ...................................................................................................................................  20   3.1   Tiến hành thanh tra chất lượng  ..................................................................................................  20   3.2.1   Miêu tả giải pháp  ...............................................................................................................  20   3.2.2   Các bên ủng hộ  ...................................................................................................................  20   3.2.3   Các bên chống đối  ..............................................................................................................  20   3.2.4   Kế hoạch quản trị sự thay đổi  ............................................................................................  21   3.2   Tự kiểm tra công việc (self check) trước khi thực hiện kiểm tra chéo (cross check)  .................  22   3.2.1   Miêu tả giải pháp  ...............................................................................................................  22   3.2.2   Các bên ủng hộ  ...................................................................................................................  22   3.2.3   Các bên chống đối  ..............................................................................................................  22   3.2.4   Kế hoạch quản trị sự thay đổi  ............................................................................................  23   3.3   Xây dựng hệ thống đánh giá kỹ sư thông qua số lỗi mắc phải  ...................................................  23   3.2.1   Miêu tả giải pháp  ...............................................................................................................  23   3.2.2   Các bên ủng hộ  ...................................................................................................................  24   3.2.3   Các bên chống đối  ..............................................................................................................  24   3.2.4   Kế hoạch quản trị sự thay đổi  ............................................................................................  25   KẾT LUẬN  ...............................................................................................................................................  26   TÀI LIÊU THAM KHẢO  .........................................................................................................................  27   1   PHẦN MỞ ĐẦU 1. Lý do chọn đề tài Trong khoảng thời gian từ tháng 3 năm 2010 đến tháng 2 năm 2012, tôi đã có cơ hội tham gia vào một dự án phát triển phần mềm nhúng cho dòng chíp bán dẫn RMobile- U2 tại công ty TNHH Thiết Kế Renesas Vietnam. Tại đây, tôi đã tham gia vào đầy đủ các bước của một quy trình phát triển phần mềm và đã nhận thấy rằng nhóm thực hiện dự án đã làm phát sinh rất nhiều chi phí chất lượng trong các khâu của quá trình kiểm soát chất lượng sản phẩm. Các chi phí chất lượng này hoàn toàn có thể hạn chế bằng một số giải pháp mà tôi cho rằng có thể áp dụng và hi vọng sẽ mang lại hiệu quả cho nhóm dự án nói riêng và công ty nói chung. Trên tinh thần của môn học Thay Đổi và Phát Triển Tổ Chức, trong bài viết này, tôi sẽ thực hiện bước chẩn đoán các vấn đề liên quan đến chi phí chất lượng mà nhóm dự án đã mắc phải và cuối cùng đề xuất các can thiệp OD (Organization Development ) nhằm hạn chế các chi phí chất lượng đó. 2. Mục tiêu và câu hỏi nghiên cứu Nghiên cứu này nhằm mục đích 1) Nhận diện các chi phí chất lượng phát sinh trong một dự án phát triển phần mềm tại công ty Trách Nhiệm Hữu Hạn Thiết Kế Renesas Việt Nam để chẩn đoán các nguyên nhân gây ra tình trạng chi phí chất lượng tăng cao 2) Đề ra các can thiệp OD nhằm hạn chế chi phí chất lượng phát sinh trong quy trình phát triển phần mềm tại công ty 3. Đối tượng và phạm vi nghiên cứu Đối tượng của nghiên cứu này là các thành viên của nhóm thực hiện dự án phát triển phần mềm tại công ty TNHH Thiết Kế Renesas Vietnam bao gồm các trưởng nhóm, trưởng đội, phó trưởng đội và các kỹ sư thực hiện. Phạm vi nghiên cứu xoay quanh quy trình phát triển phần mềm của phòng phần mềm. 2   4. Phương pháp nghiên cứu Nghiên cứu này dựa trên lý thuyết về chi phí chất lượng trong quá trình quản trị chất lượng. Các số liệu được phát thảo lại nhờ quan sát thực tế của người viết trong quá trình phát triển phần mềm tại công ty. Các tài liệu về quy trình phát triển phần mềm của nhóm được vẽ lại dựa trên kinh nghiệm làm việc 2 năm tại công ty này của người viết. Các tính toán về chi phí chất lượng dựa trên cơ sở mức lương của các kỹ sư tại công ty này. Mức lương là loại dữ liệu rất nhạy cảm và được công ty liệt vào hàng dữ liệu bảo mật; tuy vậy, người viết cũng có được loại dữ liệu này dựa vào các trao đổi, quan sát, lắng nghe từ các đồng nghiệp của mình trong suốt thời gian làm việc tại đây. 5. Kết cấu đề tài Bài tiểu luận bao gồm các nội dung sau: • Phần mở đầu: giới thiệu sơ bộ về đề tài, lý do nghiên cứu, mục tiêu nghiên cứu, đối tượng và phạm vi nghiên cứu • Chương 1: giới thiệu nền tảng cơ sở lý thuyết cho bài nghiên cứu. Trong chương này, lý thuyết về chi phí chất lượng trong quản trị chất lượng sẽ được đề cập như là nền tảng của nghiên cứu. • Chương 2: giới thiệu đôi nét về công ty TNHH Thiết Kế Renesas Vietnam. Chương này cũng trình bày về cách nhận diện và tính chi phí chất lượng trong dự án phát triển phần mềm của công ty. Từ đó, các vấn đề nổi cộm liên quan đến chi phí chất lượng sẽ được chỉ ra. • Chương 3: đây là bước can thiệp trong quá trình thực hiện dự án Thay Đổi và Phát Triển Tổ Chức. Từ những kết quả phát hiện được ở chương 2, chương này sẽ đề cập đến việc thực hiện các giải pháp nhằm cắt giảm chi phí chất lượng dựa trên tinh thần quản trị sự thay đổi của một dự án OD. 3   Chương 1: CƠ SỞ LÝ THUYẾT 1.1 Lý thuyết về chi phí chất lượng(Costs of Quality) Để sản xuất một sản phẩm có chất lượng, chi phí để đạt được chất lượng đó phải được quản lý một cách hiệu quả. Những chi phí đó chính là thước đo sự cố gắng về chất lượng. Sự cân bằng giữa hai nhân tố chất lượng và chi phí là mục tiêu chủ yếu của một ban lãnh đạo có trách nhiệm. Theo ISO 8402: 1999, chi phi chất lượng là toàn bộ chi phí nảy sinh để tin chắc và đảm bảo chất lượng thỏa mãn cũng như những thiệt hại nảy sinh khi chất lượng không thỏa mãn. 1.2 Phân loại chi phí chất lượng Theo tính chất, mục đích của chi phí, chúng ta có thể phân chia chi phí chất lượng thành 3 nhóm: • Chi phí sai hỏng, bao gồm chi phí sai hỏng bên trong và chi phí sai hỏng bên ngoài. • Chi phí thẩm định • Chi phí phòng ngừa Hình 1-0-1: Chi phí chất lượng - Cost Of Quality ( 4   1.2.1 Chi phí phòng ngừa (Prevention Costs) Chi phí phòng ngừa là những chi phí liên quan đến các hoạt động nhằm ngăn ngừa sự không phù hợp có thể xảy ra hoặc làm giảm thiểu các rủi ro của sự không phù hợp đó. Chi phí phòng ngừa bao gồm: • Chi phí hoạch định chất lượng: chi phí cho các hoạt động thiết lập một kế hoạch chất lượng tổng thể; thực hiện công tác chuẩn bị các thủ tục cần thiết nhằm phổ biến các kế hoạch này cho các thành viên tham gia. • Chi phí kiểm soát quá trình: chi phí thực hiện kiểm tra và thử nghiệm trong quá trình sản xuất. • Đánh giá chất lượng: chi phí đánh giá hoạt động thực hiện kế hoạch chất lượng tổng thể. • Huấn luyện: chi phí chuẩn bị và tiến hành các chương trình huấn luyện liên quan đến chất lượng. 1.2.2 Chi phí kiểm tra, đánh giá (Appraisal Costs) Chi phí kiểm tra, đánh giá là những chi phí liên quan đến các hoạt động đánh giá việc đạt được yêu cầu chất lượng. Chi phí kiểm tra, đánh giá bao gồm: • Chi phí kiểm tra và thử nghiệm đầu vào: chi phí đánh giá chất lượng sản phẩm mua, chi phí thử nghiệm, xét nghiệm. • Chi phí kiểm tra và thử nghiệm trong quá trình: chi phí đánh giá mức độ thực hiện theo các yêu cầu về chất lượng trong quá trình sản xuất. • Chi phí kiểm tra và thử nghiệm cuối cùng: chi phí đánh giá chất lượng sản phẩm cuối cùng trước khi giao. • Chi phí đánh giá chất lượng sản phẩm: chi phí phát sinh do thực hiện đánh giá chất lượng sản phẩm trong quá trình sản xuất hay sản phẩm cuối cùng. 1.2.3 Chi phí hư hỏng (Failure Costs) 5   1.2.3.1 Chi phí hư hỏng bên trong (Internal Failure Costs) Đây là các khoản chi phí liên quan đến các khuyết tật của sản phẩm được phát hiện trước khi sản phẩm đến tay người tiêu dùng. Chi phí hư hỏng bên trong bằng 0 nếu mọi sản phẩm không bị khuyết tật nào trước khi giao hàng. Chi phí này bao gồm: • Chi phí về phế phẩm: chi phí lao động, nguyên liệu, và chi phí sản xuất chung đã được cấu thành trong phế phẩm và không có khả năng thu hồi. • Chi phi về sản phẩm làm lại: chi phí phục hồi các sản phẩm sai hỏng để biến chúng thành chính phẩm. • Chi phí về phân tích sai hỏng: các chi phí xác định nguyên nhân gây ra phế phẩm... 1.2.3.2 Chi phí hư hỏng bên ngoài (External Failure Costs) Đây là các chi phí liên quan đến các khuyết tật được phát hiện sau khi sản phẩm được đưa đến tay người sử dụng. Chi phí này bằng 0 nếu không có khuyết tật. Nó bao gồm: • Chi phí bảo hành: các khoản chi phí liên quan đến việc thay thế và sửa chữa các sản phẩm còn trong thời gian bảo hành. • Các chi phí về giải quyết thắc mắc, khiếu nại: chi phí liên quan đến việc thanh tra, giải quyết các thắc mắc khiếu nại từ phía khách hàng về sản phẩm hoặc dịch vụ lắp đặt. 6   Chương 2: THỰC TRẠNG VỀ CHI PHÍ CHẤT LƯỢNG TRONG DỰ ÁN PHÁT TRIỂN PHẦN MỀM TẠI CÔNG TY TNHH THIẾT KẾ RENESAS VIETNAM 2.1 Vài nét về công ty TNHH Thiết Kế Renesas Vietnam Công ty THHH Renesas Việt Nam là công ty 100% vốn Nhật Bản, là công ty con của Tập Đoàn Renesas, chuyên về thiết kế và sản xuất chíp bán dẫn. Công ty cũng có một Phòng Phần Mềm nhằm phát triển phần mềm hỗ trợ cho các chíp bán dẫn mà hãng sản xuất. • Website công ty: • Địa chỉ: Lô W 29-30-31A Tân Thuận Kcx Tân Thuận, Quận 7, Thành Phố Hồ Chí Minh • Số lượng nhân viên: 600 (tại thời điểm tháng 02, 2012) 2.2 Quy trình một dự án phát triển phần mềm của công ty Hiện tại công ty sử dụng quy trình phát triển phần mềm như ở hình 2-1. Trong đó gồm các giai đoạn sau: 2.2.1 Phân tích yêu cầu khách hàng Giai đoạn này nhằm làm rõ các yêu cầu tính năng và thông số mà phần mềm cần đạt được. Số người tham gia vào giai đoạn này gồm 2 trưởng nhóm (Group Manager), 2 trưởng đội (Team Leader), và 5 phó trưởng đội (Crew Leader) và 30 thành viên khác. Giai đoạn này cần thời gian 1 tuần để phân tích. Nhằm mục đích đạt chất lượng sản phẩm, công ty yêu cầu tổ chức 2 cuộc họp nội bộ để kiểm tra lại (review) các phân tích. Nếu sau khi đã kiểm tra lại việc phân tích mà còn thiếu sót thì sẽ tiến hành phân tích lại 7   trong vòng 2 ngày và lại tổ chức lại 1 cuộc họp nữa để kiểm tra lại các điểm sửa đổi, bổ sung. Mỗi cuộc họp kéo dài 2 giờ. Ngoài ra giai đoạn này còn nhằm mục đích lên kế hoạch phát triển dự án, đề ra các chỉ tiêu chất lượng. Công việc này do 2 trưởng nhóm và 2 trưởng đội đảm nhiệm, thời gian thường kéo dài 1 tuần. 2.2.2 Thiết kế hệ thống Giai đoạn này nhằm thiết kế phần mềm ở mức độ cấp cao trên phương diện người dùng. Số người tham gia vào giai đoạn này gồm 2 trưởng đội, 5 phó trưởng đội và 30 thành viên khác. Giai đoạn này mất 3 tuần để thiết kế. Nhằm mục đích đạt chất lượng sản phẩm, công ty yêu cầu tổ chức 6 cuộc họp chính thức để kiểm tra lại bằng cách kiểm tra chéo (cross check) các thiết kế. Trong 6 cuộc họp chính thức này, cứ sau mỗi cuộc họp mà còn phát hiện lỗi thì phải mất thêm 2 ngày để làm lại, sửa đổi; đồng thời phải tổ chức lại 1 cuộc họp để kiểm tra lại các sửa đổi. Mỗi cuộc họp kéo dài 2 giờ. 2.2.3 Thiết kế chi tiết Giai đoạn này nhằm thiết kế phần mềm ở mức thấp hơn đứng trên phương diện của người phát triển phần mềm. Số người tham gia giai đoạn này gồm 2 trưởng đội, 5 phó trưởng nhóm và 30 thành viên khác. Giai đoạn này mất 4 tuần để thiết kế. Nhằm mục đích đạt chất lượng sản phẩm, công ty yêu cầu tổ chức 8 cuộc họp chính thức để kiểm tra lại thông qua hình thức kiểm tra chéo. Trong 8 cuộc họp chính thức này, cứ sau mỗi cuộc họp mà còn phát hiện lỗi thì phải mất thêm 2 ngày để làm lại, sửa đổi; đồng thời phải tổ chức lại 1 cuộc họp nữa để kiểm tra các sửa đổi. Mỗi cuộc họp kéo dài 2 giờ. 2.2.4 Viết mã nguồn Đây là giai đoạn hiện thực hóa các thiết kế ở khâu trước bằng các dòng mã nguồn (source code). Số người tham gia giai đoạn này gồm 2 trưởng đội, 5 phó trưởng đổi và 30 thành viên khác. Giai đoạn này mất 3 tuần để viết mã nguồn. Nhằm mục đích đạt chất lượng sản phẩm, công ty yêu cầu tổ chức 6 cuộc họp chính thức để kiểm tra lại các mã 8   nguồn thông qua hình thức kiểm tra chéo. Trong 6 cuộc họp chính thức này, cứ sau mỗi cuộc họp mà còn phát hiện lỗi thì phải mất thêm 2 ngày để làm lại, sửa đổi; đồng thời phải tổ chức lại 1 cuộc họp nữa để kiểm tra các sửa đổi. Mỗi cuộc họp kéo dài 2 giờ. 2.2.5 Kiểm thử Giai đoạn này nhằm viết các đoạn mã nguồn để kiểm tra hoạt động của phần mềm đã viết ở giai đoạn 4. Gai đoạn này thực hiện rất nhiều loại test khác nhau nhằm kiểm tra tính năng và sự ổn định của phần mềm. Số người tham gia giai đoạn này gồm 2 trưởng đội, 5 phó trưởng đổi và 30 thành viên khác. Gai đoạn này mất 2 tuần để thiết kế các trường hợp test (test cases design), 2 tuần để viết mã nguồn test (test coding), và 2 tuần để chạy kiểm tra (test running). Trong khâu test cases design và test coding, tổng cộng phải tổ chức 8 cuộc họp chính thức để kiểm tra chéo các kết quả đã làm. Trong 8 cuộc họp này, cứ sau mỗi cuộc họp mà có phát hiện thấy lỗi thì phải làm lại trong 2 ngày và lại tổ chức 1 cuộc họp để kiểm tra lại các sửa đổi. Mỗi cuộc họp kéo dài 2 giờ. Trong khâu chạy test (test running), nếu có thấy lỗi (bug) mà người chạy test không biết nguyên nhân từ đâu thì vấn đề trở nên phức tạp và tốn thời gian hơn rất nhiều. Cụ thể, đối với 1 lỗi tìm thấy, có ít nhất 1 cuộc họp hội ý với tất cả thành viên (2 trưởng nhóm, 2 trưởng đội, 5 phó trưởng đội và 30 thành viên) để tìm nguyên nhân. Mỗi cuộc họp kéo dài ít nhất 2.0 giờ. Thường thì cả phòng phần mềm sẽ gặp 15 lỗi trong 1 dự án phát triển phần mềm. Trong trường hợp này, thời gian bị tiêu tốn có khi cò nhiều hơn liệt kê ở trên tùy theo lỗi phức tạp hay đơn giản. Nếu là lỗi phức tạp thì cần phải xem lại toàn bộ các khâu trước đó để tìm nguyên nhân và giải pháp. Trung bình việc làm lại mất 1 tuần cho một lỗi. 2.2.6 Phát hành Đây là giai đoạn giao sản phẩm cho khách hàng, bảo trì sản phẩm.Trong giai đoạn này, để chắc chắn sản phẩm không còn bất cứ lỗi nào trước khi giao cho khách hàng, trưởng phòng phần mềm đã lập nên một nhóm gồm 7 kỹ sư có kinh nghiệm đóng vai là người dùng cuối cùng để sử dụng sản phẩm. Nhóm này thường phải làm việc 2 ngày trước khi 9   sản phẩm được phát hành. Sau khi sản phẩm đã được phát hành, dự án được xem như kết thúc và cả nhóm sẽ chuyển sang một dự án mới. Tuy nhiên, song song với dự án mới là việc hỗ trợ khách hàng nếu như sản phẩm đã giao có lỗi mà lỗi này lại do khách hàng tìm thấy. Việc hỗ trợ này thường do 2 trưởng đội và 5 phó trưởng đội đảm nhiệm. Nếu lỗi là phức tạp thì sẽ mất khoảng 2 tuần để giải quyết. Thường thì một sản phẩm đã giao sẽ có 2 lỗi do khách hàng tìm thấy. 10   Hình 2-1: Quy trình phát triển phần mềm hiện tại của công ty TNHH Thiết Kế RenesasViệt Nam Yêu cầu của khách hàng (Customer requirements)) Phân tích yêu cầu của khách hàng (Customer requirements analysis) Thiết kế hệ thống (System design) Thiết kế chi tiết (Detailed design) Viết mã nguồn (Coding) Kiểm thử (Testing) Phát hành (Delivery) Kiểm tra lại (Review) Kiểm tra lại (Review) Kiểm tra lại (Review) Kiểm tra lại (Review) Kiểm tra lại (Review) Lỗi do thiết kế mã nguồn kiểm thử Lỗi do khách hàng phát hiện (Customer feedbacks) Có Không Đúng Lỗi Không lỗi Lỗi Không lỗi Sai Lỗi Lỗi Không lỗi Không lỗi Lỗi Không lỗi 11   2.3 Nhận diện và tính chi phí chất lượng Như đã chỉ ra ở trên, chi phí của quy trình phát triển dự án phần mềm của công ty tập trung ở số người tham gia vào dự án và thời gian để thực hiện các giai đoạn của dự án. Nhân lực tham gia vào dự án bao gồm 2 trưởng nhóm (Group Manager), 2 trưởng đội (Team Leader), và 5 phó trưởng đội (Crew Leader) và 30 thành viên khác. Tuy nhiên trong số 30 thành viên khác này, có 10 thành viên là nhân viên mới vào chưa có kinh nghiệm (được tuyển từ sinh viên mới ra trường). Do đó, 10 thành viên này được huấn luyện các kiến thức kỹ thuật, các quy tình phát triển phần mềm và chính sách chất lượng của công ty trong vòng 3 tháng trước khi chính thức tham gia vào dự án. Biết rằng: • Thông tin về mức lương của các vị trí như sau (tại thời điểm tháng 02/2012): lương của một trưởng nhóm là 19 triệu đồng/tháng, của một trưởng đội là 16 triệu đồng/tháng, của một phó trưởng đội là 12 triệu đồng/tháng, của một thành viên chưa có kinh nghiệm là 7.5 triệu đồng/tháng, của một thành viên đã có kinh nghiệm là 9 triệu đồng/tháng (tính trung bình). • Số ngày làm việc trong tháng là 22 ngày, 1 ngày làm 8 giờ, 1 tuần có 5 ngày làm việc. Quy ra tiền lương tính theo giờ là: ü Trưởng nhóm: !"######!!∗! = 107955 (VND/giờ) ü Trưởng đội: !"######!!∗! = 90909 (VND/giờ) ü Phó trưởng đội: 12   !"######!!∗! = 68182 (VND/giờ) ü Kỹ sư có kinh nghiệm: !""""""!!∗! = 51136 (VND/giờ) ü Kỹ sư chưa có kinh nghiệm: !"#####!!∗! = 42614 (VND/giờ) • Để chuẩn bị cho một buổi họp kiểm tra lại (review), các thành viên phải kiểm tra chéo các công việc của nhau tại bàn làm việc của mình trước khi chính thức vào họp. Việc kiểm tra chéo tại bàn này mất trung bình 1 giờ cho một thành viên sẽ tham gia buổi họp. Mục đích của buổi họp là nhằm cho các thành viên chỉ ra lỗi của nhau và đồng thời bàn luận về các giải pháp gợi ý, và các đề xuất khác. Theo cơ sở lý thuyết ở chương 1, chi phí chất lượng của dự án được chia nhỏ thành 3 loại: ü Chi phí phòng ngừa: đó là chi phí cho các nỗ lực nhằm ngăn ngừa sản phẩm xuất hiện lỗi. Trong dự án của công ty, chi phí phòng ngừa được thể hiện trong các khâu huấn luyện cho nhân viên chưa có kinh nghiệm, đề ra các mục tiêu chất lượng và quá trình thực hiện chính sách chất lượng. ü Chi phí đánh giá và kiểm tra: là chi phí để chắc chắn đạt được được các mục tiêu chất lượng. Trong dự án, chi phí đánh giá và kiểm tra được thể hiện ở việc kiểm tra lại các việc đã làm ở cuối mỗi giai đoạn (review) thông qua việc kiểm tra chéo giữa các thành viên trong các buổi họp. Chi phí đánh giá và kiểm tra còn được thể hiện ở giai đoạn kiểm thử (giai đoạn 5) và ở khâu kiểm tra lần cuối trước khi phát hành (giai đoạn 6) ü Chi phí sai hỏng: 13   o Chi phí sai hỏng bên trong: là chi phí do các thành viên làm không tốt công việc của mình và gây ra lỗi được phát hiện trong các buổi họp review và phải tốn thời gian làm lại rồi lại kiểm tra lại. Chi phí sai hỏng bên trong còn thể hiện ở giai đoạn kiểm thử (giai đoạn 5) khi phát hiện ra lỗi trong quá trình chạy test o Chi phí sai hỏng bên ngoài: là chi phí để sửa lỗi do khách hàng phát hiện ra sau khi đã giao sản phẩm cho khách hàng (sau giai đoạn 6). 2.3.1 Phân tích yêu cầu khách hàng 2.3.1.1 Chi phí phòng ngừa § Chi phí lập kế hoạch chất lượng: (Lương giờ của 2 trưởng nhóm + Lương giờ của 2 trưởng đội)* 1tuần = 2 ∗ 107955 + 2 ∗ 90909 ∗ 5 ∗ 8 = 15909120(𝑉𝑁𝐷) § Chi phí đào tạo kỹ sư chưa có kinh nghiệm: (Lương tháng của 10 kỹ sư chưa có kinh nghiệm)* (3 tháng đào tạo) = 10 ∗ 7500000 ∗ 3 = 225000000(𝑉𝑁𝐷) ð Tổng chi phí phòng ngừa: 15909120 + 225000000 = 240909120(𝑉𝑁𝐷) 2.3.1.2 Chi phí đánh giá và kiểm tra [Lương giờ của (2 trưởng nhóm + 2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(thời gian cho 2 cuộc họp review) = 2 ∗ 107955 + 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 2 ∗ 2 =8749992(𝑉𝑁𝐷) 2.3.1.3 Chi phí sai hỏng 14   [Lương giờ của (2 trưởng nhóm + 2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(2 ngày làm lại + 1 cuộc họp lại) = 2 ∗ 107955 + 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 2 ∗ 8 + 1 ∗2 = 39374964(𝑉𝑁𝐷) 2.3.2 Thiết kế hệ thống 2.3.2.1 Chi phí phòng ngừa Giai đoạn này không có chi phí phòng ngừa. 2.3.2.2 Chi phí đánh giá và kiểm tra [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(6 cuộc họp review) = 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 6 ∗ 2 = 23659056(𝑉𝑁𝐷) 2.3.2.3 Chi phí sai hỏng [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(2 ngày làm lại + 1 cuộc họp lại) = 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 2 ∗ 8 + 1 ∗ 2 =35488584(𝑉𝑁𝐷) 2.3.3 Thiết kế chi tiết 2.3.3.1 Chi phí phòng ngừa Giai đoạn này không có chi phí phòng ngừa. 2.3.3.2 Chi phí đánh giá và kiểm tra: [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(8 cuộc họp review) = 15     2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 8 ∗ 2 = 31545408(𝑉𝑁𝐷) 2.3.3.3 Chi phí sai hỏng: [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(2 ngày làm lại + 1 cuộc họp lại) = 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 2 ∗ 8 + 1 ∗ 2 =35488584(𝑉𝑁𝐷) 2.3.4 Viết mã nguồn 2.3.4.1 Chi phí phòng ngừa Giai đoạn này không có chi phí phòng ngừa. 2.3.4.2 Chi phí đánh giá và kiểm tra: [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(6 cuộc họp review) = 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 6 ∗ 2 = 23659056(𝑉𝑁𝐷) 2.3.4.3 Chi phí sai hỏng [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(2 ngày làm lại + 1 cuộc họp lại) = 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 2 ∗ 8 + 1 ∗ 2 =  35488584(𝑉𝑁𝐷) 2.3.5 Kiểm thử 2.3.5.1 Chi phí phòng ngừa: không có 16   2.3.5.2 Chi phí đánh giá và kiểm tra: [Lương giờ của (2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(8 cuộc họp review) = 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 8 ∗ 2 = 31545408(𝑉𝑁𝐷) 2.3.5.3 Chi phí sai hỏng [Lương giờ của (2 trưởng nhóm + 2 trưởng đổi + 5 phó trưởng đội + 10 kỹ sư chưa kinh nghiệm + 20 kỹ sư kinh nghiệm)]*(15 lỗi)*(1 cuộc họp hội ý + 1 tuần làm lại) = 2 ∗ 107955 + 2 ∗ 90909 + 5 ∗ 68182 + 10 ∗ 42614 + 20 ∗ 51136 ∗ 15 ∗ 1 ∗ 2 +5 ∗ 8 = 1378123740(𝑉𝑁𝐷) 2.3.6 Phát hành 2.3.6.1 Chi phí phòng ngừa Giai đoạn này không có chi phí phòng ngừa. 2.3.6.2 Chi phí đánh giá và kiểm tra (Lương giờ của 7 kỹ sư có kinh nghiệm)*(2 ngày) = 7 ∗ 51136 ∗ 2 ∗ 8 = 5727232(𝑉𝑁𝐷) 2.3.6.3 Chi phí sai hỏng [Lương giờ của (2 trưởng đội + 5 phó trưởng đội)]*(2 lỗi)*(2 tuần) = (2 ∗ 90909 + 5 ∗ 68182) ∗ 2 ∗ 2 ∗ 5 ∗ 8 = 83636480(𝑉𝑁𝐷) 17   Chi phí chất lượng của dự án được tóm tắt và tính theo bảng sau (đơn vị VND): Bảng 2-1 Tóm tắt chi phí chất lượng Giai đoạn (1) Phân tích yêu cầu khách hàng (2) Thiết kế hệ thống (3) Thiết kế chi tiết (4) Viết mã nguồn (5) Kiểm thử (6) Phát hành Tổng % Chi phí phòng ngừa 240909 120 0 0 0 0 0 2409091 20 12 .2 Chi phí đánh giá và kiểm tra 874999 2 23659 056 31545 408 23659 056 3154540 8 57272 32 1248861 52 6. 3 Chi phí sai hỏng 393749 64 35488 584 35488 584 35488 584 1378123 740 83636 480 1607600 936 81 .5 Tổng 289034076 59147 640 67033 992 59147 640 1409669 148 89363 712 1973396 208 100 % 15 3 3 3 71 5 2.4 Nhận xét về chi phí chất lượng Chi phí chất lượng của một dự án phát triển phần mềm tổng cộng là 1.973.396.208 VND. Đó là một con số khá lớn. Trong đó, chi phí chất lượng tập trung phần lớn ở chi phí sai hỏng (81% trên tổng các loại chi phí – hình 2-2). 18   Hình 2-2 Tỉ lệ các loại chi phí chất lượng Như chỉ ra ở hình 2-3, giai đoạn có chi phí chất lượng cao nhất là giai đoạn kiểm thử (71 % trên tổng các giai đoạn). Lý do là trong giai đoạn kiểm thử, nếu phát hiện lỗi thì sẽ rất mất nhiều nguồn lực và thời gian để xem lại tất cả các giai đoạn trước đó đã làm đúng chưa, nếu chưa đúng thì phải làm lại các giai đoạn đó. Như vậy, vấn đề đã được xác định: chi phí chất lượng trong khâu kiểm thử của quá trình phát triển phần mềm đạt tỉ lệ rất lớn và cao hơn các giai đoạn khác. Chương 3 tiếp theo sau sẽ đề xuất các giải pháp nhằm hạn chế chi phí chất lượng tại giai đoạn kiểm thử. Chi  phí  phòng  ngừa   12%   Chi  phí  đánh   giá  và  kiểm  tra   6%   Chi  phí  sai  hỏng   82%   % Các loại chi phí chất lượng 19   Hình 2-3 Tỉ lệ các chi phí chất lượng trong các giai đoạn phát triển phần mềm 15   3   3   3   71   5   0   10   20   30   40   50   60   70   80   Phân  Ech  yêu   cầu  khách  hàng   Thiết  kế  hệ   thống   Thiết  kế  chi  Oết   Viết  mã  nguồn   Kiểm  thử   Phát  hành   %  chi phí chất lượng ở các giai đoạn phát triển phần mềm 20   Chương 3: CÁC CAN THIỆP OD NHẰM CẮT GIẢM CHI PHÍ CHẤT LƯỢNG TRONG DỰ ÁN PHÁT TRIỂN PHẦN MỀM Như đã nhận xét ở chương 2, chi phí chất lượng xuất hiện lớn nhất là chi phí sai hỏng và ở khâu kiểm thử. Do đó chương này sẽ đề cập đến các giải pháp nhằm giảm chi phí chất lượng. 3.1 Tiến hành thanh tra chất lượng 3.2.1 Miêu tả giải pháp Cứ sau mỗi giai đoạn thiết kế hệ thống, thiết kế chi tiết, viết mã nguồn thì cần phải có việc thanh tra của một kỹ sư phụ trách chất lượng. Kỹ sư này sẽ theo dõi nhóm đã làm theo các bước, tuân thủ theo đúng quy trình phát triển phần mềm hay chưa. Chỉ cho nhóm tiếp tục làm giai đoạn kế tiếp, nếu thanh tra thấy giai đoạn trước đã đạt các chỉ tiêu chất lượng. Đây là giải pháp hợp lý vì như đã chỉ ra ở chương 2, chi phí sai hỏng xuất hiện phần lớn ở khâu kiểm thử. Mà nguyên nhân để dẫn đến điều này là các khâu trước đó đã chưa thực hiện tốt công việc của mình và còn sản sinh nhiều lỗi. Do đó, khi đến khâu kiểm thử thì các lỗi này được tìm thấy. Sau khi lỗi đã tìm thấy thì phải truy nguyên nhân của nó, mà nguyên nhân thì nằm ở các khâu trước đó. Do đó, việc hạn chế lỗi ở các khâu trước trước khi đi vào khâu kiểm thử sẽ giảm thiểu chi phí sai hỏng ở khâu kiểm thử. 3.2.2 Các bên ủng hộ Trưởng nhóm và trưởng đội sẽ là những người ủng hộ vì hai chức danh này chịu trách nhiệm chính đối với trưởng phòng và khách hàng. Nếu sản phẩm giao cho khách hàng mà bị khách hàng phát hiện thấy lỗi thì họ sẽ chịu trách nhiệm đối với trưởng phòng. 3.2.3 Các bên chống đối 21   Phó trưởng đội và các thành viên cấp dưới sẽ có khả năng bày thỏ thái độ bất hợp tác. Lý do là khi tiến hành một khâu kiểm tra chất lượng trước khi qua giai đoạn mới bắt buộc họ phải làm nhiều công việc thêm khác. Khi đó mức độ tập trung vào công việc sẽ tăng cao và có thể gây căng thẳng. Vị trí kỹ sư bổ sung để tiến hành kiểm tra chất lượng công việc của nhóm trước khi chuyển tới giai đoạn tiếp theo có thể sẽ chống đối. Vì khi thực hiện công việc mới, họ có thể bị bắt buộc tạm ngưng công việc yêu thích hiện thời của mình để chuyển qua công việc mới mà có thể là họ chưa quen và chưa có kinh nghiệm nhiều. 3.2.4 Kế hoạch quản trị sự thay đổi Nhân lực để tiến hành giải pháp này yêu cầu cần bổ sung thêm một kỹ sư có kinh nghiệm khoảng trên 3 năm làm việc để tiến hành thanh tra chất lượng công việc trước khi chuyển đến giai đoạn kế tiếp. Để giảm thiểu sự chống đối của vị trí kỹ sư thanh tra này, trưởng nhóm cần có một buổi nói chuyện riêng với anh ta. Buổi trao đổi này nhằm giúp anh ta biết được rằng vì sao nhóm cần có một người như anh ta để thực hiện việc tăng cường chất lượng sản phẩm. Và trưởng nhóm cũng nên giải thích vì sao việc thanh tra chất lượng là cần thiết. Một giải pháp để thúc đẩy sự hợp tác của anh ta là tạo ra cơ hội thăng tiến cho anh ta trong vòng 2 năm nữa nếu anh ta thực hiện tốt vai trò này. Với lý do chống đối là chưa có kinh nghiệm trong việc thanh tra chất lượng, trưởng nhóm cũng nên nói cho anh ta biết là công việc này không khó để mau chóng nắm bắt, và anh ta có thể học hỏi rất nhanh dưới sự chỉ đạo, kèm cặp của trưởng nhóm trong thời gian đầu. Đối với lý do chống đối từ các phó trưởng đội và thành viên cấp dưới (phải tập trung hơn vào công việc, có trách nhiệm hơn trong sản phẩm làm ra), trưởng nhóm cũng cần có cuộc họp riêng với các đối tượng này và chỉ ra rằng trước hết để trở thành một kỹ sư chuyên nghiệp có khả năng trên thị trường phần mềm toàn cầu, họ phải tự giác phấn đấu thông qua việc có trách nhiệm hơn với sản phẩm của mình làm ra. Các cam kết về chất 22   lượng sản phẩm mà họ đã đồng ý và thực tế họ đã hành động là cơ sở để trưởng nhóm đánh giá năng lực cuối năm, là cơ sở để khen thưởng và đề bạt. 3.2 Tự kiểm tra công việc (self check) trước khi thực hiện kiểm tra chéo (cross check) 3.2.1 Miêu tả giải pháp Giải pháp này hàm ý rằng việc kiểm tra chéo giữa các thành viên là chưa đủ mà cần phải có thêm giai đoạn tự kiểm tra (kỹ sư tự xem lại sản phẩm của mình) trước khi đưa sản phẩm của mình cho đồng nghiệp thực hiện kiểm tra chéo. 3.2.2 Các bên ủng hộ Các vị trí quản lý như trưởng nhóm, trưởng đội và phó trưởng đội là những người có khả năng ủng hộ. Lý do là, thứ nhất họ phải chịu trách nhiệm trực tiếp với khách hàng và trưởng phòng phần mềm(phó trưởng đội chịu trách nhiệm với trưởng đội, còn trưởng đội chịu trách nhiệm trước trưởng nhóm, trưởng nhóm chịu trách nhiệm trước trưởng phòng, trưởng phòng đến lược lại chịu trách nhiệm với khách hàng và cấp trên). Lý do thứ hai là các vị trí này tham gia vào việc phát triển phần mềm rất ít, đa phần thời gian họ tham gia vào các hoạt động quản lý, trao đổi với khách hàng. Điều đó kéo theo kết quả là nếu tiến hành thêm khâu tự kiểm tra thì họ khả năng tham gia của họ sẽ rất thấp, mà các kỹ sư cấp dưới mới chính là người trực tiếp tiến hành. 3.2.3 Các bên chống đối Các kỹ sư cấp dưới là những người có khả năng chống đối cho giải pháp này nhiều nhất. Lý do cho sự chống đối là họ phải làm thêm công việc mà trước đây họ không phải làm. Việc tự kiểm tra không phải là một công việc đơn giản, các kỹ sư phải xem đầu ra của mình đã đáp ứng đủ các tiêu chuẩn được đề ra trong một danh sách các tiêu chí chất lượng hay không. Nếu các danh sách tiêu chí chất lượng này là lớn thì thái độ chống đối của kỹ sư cũng sẽ theo đó mà tăng cao. 23   3.2.4 Kế hoạch quản trị sự thay đổi Cũng giống như kế hoạch quản trị sự thay đổi cho giải pháp thanh tra chất lượng ở mục trức, để thực hiện giải pháp này hiệu quả, các quản lý (trưởng nhóm, trưởng đội, phó trưởng đội) cũng cần có buổi nói chuyện với các kỹ sư về tính chuyên nghiệp và trách nhiệm/đạo đức nghề nghiệp của một kỹ sư phần mềm. Các quản lý cần cam kết các cơ hội thăng tiến và các khen thưởng dựa trên sản phẩm đầu ra của các kỹ sư. Cần cho họ biết rằng, họ đang trong quá trình vừa làm việc vừa tích lũy kinh nghiệm để phát triển lên ở một mức độ cao hơn bây giờ trong nấc thang nghề nghiệp của mình. Và việc tự kiểm tra sản phẩm của mình làm ra sẽ là một trong những phương tiện cốt lõi để họ thực hiện điều đó. Đối với lý do chống đối vì bảng danh sách các tiêu chí chất lượng quá dài có thể gây phiền phức và nản chí các kỹ sư, trưởng nhóm cần họp với các kỹ sư kinh nghiệm để xây dựng một bảng tiêu chí chất lượng vừa đủ dài mà cũng không quá ngắn nhưng bao hàm hết các tiêu chí để các kỹ sư có thể tự đánh giá chất lượng sản phẩm của mình. Thông thường bản tiêu chí chất lượng nên ở tầm khoảng 20 tiêu chí là phù hợp. 3.3 Xây dựng hệ thống đánh giá kỹ sư thông qua số lỗi mắc phải 3.2.1 Miêu tả giải pháp Cần có hệ thống đánh giá kỹ sư thông qua các công việc của họ dựa trên số lỗi mà họ tạo ra trong công việc của mình. Vì theo quan sát cá nhân của người viết bài này, công ty cũng có không ít kỹ sư còn làm việc cẩu thả và thiếu trách nhiệm. Hầu hết trách nhiệm của người phó trưởng đội là rất lớn vì người này nắm rất rõ tình hình làm việc trực tiếp của các kỹ sư. Một sản phẩm nhiều lỗi hay ít lỗi còn phụ thuộc rất lớn vào trình độ kỹ thuật, thái độ và đặc biệt trách nhiệm của người phó trưởng đội. Do đó, công ty cần cân nhắc kỹ lưỡng vị trí phó trưởng đội hơn. Hệ thống đánh giá này không bác bỏ hệ thống đánh giá năng lực nhân viên mà công ty đã sử dụng. Mà nó đóng vai trò như là một nhân tố bổ sung cho hệ thống hiện hành (tại thời 24   điểm tháng 2 năm 2012). Cụ thể là trong quá trình phát triển phần mềm, đội dự án có tổ chức các buổi họp kiểm tra (review) để kiểm tra chéo; thông qua việc kiểm tra chéo này, số lỗi mà mỗi kỹ sư bất cẩn (hoặc cố tình) gây ra đều được ghi nhận lại. Đến kỳ đánh giá cuối năm, số lỗi này sẽ được thống kê lại và là một nhân tố để đo năng lực của kỹ sư. 3.2.2 Các bên ủng hộ Cũng giống như hai giải pháp ở trên, các cấp quản lý (trưởng nhóm, trưởng đội và phó đội) là những người có khả năng ủng hộ nhiều nhất. Vì họ tham gia rất ít vào công việc phát triển phần mềm (mà chỉ tham gia chủ yếu ở công việc quản lý) và họ là những người chịu trách nhiệm cho sản phẩm cuối cùng của nhóm với cấp trên và khách hàng. Các kỹ sư có chí cầu tiến muốn nâng cao năng lực bản thân có thể là những người ủng hộ. Đây là những kỹ sư có trách nhiệm và yêu nghề, mong muốn trở thành một kỹ sư chuyên nghiệp. Các kỹ sư mới tuyển vào từ nguồn sinh viên mới ra trường là những người thuộc nhóm này. 3.2.3 Các bên chống đối Ngoài ra việc bổ sung các tiêu chí đánh giá năng lực kỹ sư vào hệ thống hiện thời sẽ làm liên quan đến phòng nhân sự, cụ thể là trưởng phòng nhân sự vì họ phải thay đổi hệ thống đánh giá nhân sự của phòng mình. Nhưng đó là cơ chế làm việc thông thường của các công ty, Renesas Việt Nam không theo cơ chế này. May mắn là ở Renesas Việt Nam, phòng nhân sự không trực tiếp xây dựng nên các chỉ tiêu đánh giá kỹ sư. Ngược lại công việc này thuộc về quyền hạn của trưởng nhóm. Do đó khả năng chống đối từ phòng nhân sự cho giải pháp này là không có. Các kỹ sư đã làm việc ở công ty trên một năm sẽ là những người có khả năng chống đối cho việc đánh giá nhân viên dựa trên số lỗi họ mắc phải. Lý do là bỗng dưng họ lại chịu thêm một sự giám sát vô hình là số lỗi họ mắc phải. Điều này sẽ rất khó chịu đối với họ, vì nó ảnh hưởng đến đánh giá của cấp trên đối với họ và cuối cùng là sẽ ảnh hưởng đến mức độ tăng lương và khả năng thăng tiến. 25   3.2.4 Kế hoạch quản trị sự thay đổi Nhằm hạn chế khả năng chống đối của các kỹ sư có kinh nghiệm làm việc trên một năm, cũng giống như hai giải pháp ở trên, người trưởng nhóm cần cho họ biết rằng nghề phát triển phần mềm là một ngành đặc biệt chú ý tới tính cẩn trọng; thiếu hay dư một dấu phẩy trong đoạn code cũng có thể làm cho cả sản phẩm chạy sai. Chính vì vậy mà nghề này đặc biệt chú trọng đến khả năng tạo ra lỗi của nhân viên. Nếu anh không thay đổi để sản phẩm của mình làm ra tốt hơn thì chính khách hàng sẽ là người sa thải anh chứ không phải là ông chủ của anh. Trưởng nhóm cần cho họ biết là họ nhận được rất nhiều từ hệ thống đánh giá này. Đó là khả năng làm việc tốt hơn, giúp rèn luyện kỹ năng lập trình giảm thiểu tối đa số lỗi mắc phải. Và hơn hết là họ sẽ trở nên một kỹ sư lập trình chuyên nghiệp hơn. Có thể họ sẽ rời khỏi công ty một ngày nào đó, nhưng cái mà họ mang đi nếu họ chấp nhận và làm theo hệ thống đánh giá này vẫn còn rất nhiều giá trị trên chặng đường tiếp theo. Tất nhiên, không ai mong muốn nhân viên của mình rồi một ngày phũ áo ra đi, nhưng đó là những gì trưởng nhóm cần truyền tải đến cho nhân viên cấp dưới để họ thấy được lợi ích lâu dài cho chính con đường sự nghiệp của mình. 26   KẾT LUẬN Phát triển phần mềm là công việc dễ dàng tạo ra các lỗi, thậm chí đôi khi là có lỗi mất đến hơn một tháng, hai tháng hoặc dài hơn để tìm ra nguyên nhân gốc rễ. Quá trình tìm ra nguyên nhân gốc rễ của lỗi phần mềm mà vì đó sẽ chiếm thêm nhiều chi phí của dự án hơn là dự tính ban đầu. Chính vì đó bài tiểu luận này hy vọng có thể giúp công ty TNHH Thiết Kế Renesas Việt Nam, mà cụ thể là các nhóm phát triển phần mềm, giảm thiểu chi phí cho công việc thiết kế phầ mềm. Các giải pháp đề ra cũng đã tính đến các khả năng chống đối của các bên liên quan và đi kèm theo các giải pháp là một kế hoạch thực hiện quản lý sự thay đổi để hạn chế tối đa các chống đối đó. Mở rộng ra, phương pháp nghiên cứu và các giải pháp để giảm thiểu chi phí chất lượng cho một dự án phát triển phần mềm được chỉ ra trong bài này không những áp dụng được cho công ty TNHH Thiết Kế Renesas nói riêng mà còn là một mô hình tham khảo để tiến hành cho các công ty phần mềm nói chung, đặc biệt là phần mềm nhúng. 27   TÀI LIÊU THAM KHẢO Ngoài bài giảng trên lớp và tài liệu của GVHD đã gởi, tôi có tham khảo thêm một số tài liệu như dưới đây : [1] Thomas G. Cummings & Christopher G. Worley, “Organization Development & Change – 9th Edition” [2] Tạ Thị Kiều An & Ngô Thị Ánh & Nguyễn Thị Ngọc Diệp & Nguyễn Văn Hóa & Nguyễn Hoàng Kiệt & Dinh Phượng Vương, “Quản lý chất lượng”, Nhà Xuất Bản Thống Kê, 2010 [3] Cost of Quality: Not Only Failure Costs failure-costs/ [4] Chi phí chất lượng phi-cht-lng&catid=98:c&Itemid=334&lang=vi [5]