3.3.2.1 Lãng phí do thao tác thừa
Không có tài liệu mô tả hệ thống
Các sản phẩm phần mềm sau khi đã triển khai sang khách hàng sẽ đƣợc khách hàng vận hành. Trong quá trình vận hành, sản phẩm đôi lúc sẽ phát sinh lỗi, hoặc khách hàng cần biết thêm một số thông tin về sản phẩm. Khi đó, khách hàng sẽ yêu cầu cán bộ hỗ trợ kỹ thuật của ELCOM hỗ trợ xác định nguyên nhân và cung cấp thông tin về sản phẩm. Khách hàng cũng thƣờng đề nghị nâng cấp, bổ sung tính năng cho sản phẩm trong quá trình khách hàng vận hành.
Các cán bộ hỗ trợ kỹ thuật thƣờng phải theo hỗ trợ rất nhiều sản phẩm, còn cán bộ sản xuất phần mềm, sau khi xong một sản phẩm thì thƣờng sẽ đƣợc nhập vào một nhóm dự án làm sản phẩm khác. Sau một thời gian, các cán bộ hỗ trợ kỹ thuật và cán bộ sản xuất sẽ không nhớ đƣợc các thông tin về sản phẩm. Trong khi đó, thông tin về sản phẩm là rất cần thiết để xác định nguyên nhân lỗi, cung cấp thông tin về sản phẩm hoặc bổ sung tính năng cho sản phẩm. Nếu không có tài liệu về sản phẩm thì cán bộ sản xuất sẽ phải làm các việc sau
Đọc mã nguồn để tìm thông tin cần thiết
Kiểm tra lại thông tin bằng cách giả lập tình huống trên hệ thống giả lập
Các công việc đó đều lãng phí thời gian mà không đem lại giá trị gia tăng. Qua biểu đồ, tác giả thấy rằng, lãng phí này xảy ra khá nhiều.
Biểu đồ 3.7 Kết quả khảo sát cho câu hỏi “Anh/chị có gặp trƣờng hợp khi khắc phục sự cố thì không biết hệ thống nhƣ thế nào do không có tài liệu mô tả hệ
55
Nguồn: Kết quả khảo sát năm 2015 của tác giả
Không có thông tin về hệ thống giả lập
Sau khi sửa lỗi hoặc bổ sung tính năng, cán bộ sản xuất phần mềm cần triển khai sản phẩm trên hệ thống giả lập trƣớc khi triển khai thật bên khách hàng. Hệ thống giả lập này thƣờng đƣợc dựng lên trên các máy chủ tại ELCOM trong quá trình thực hiện dự án sản xuất. Tuy nhiên, qua khảo sát, sau khi vẽ biểu đồ, tác giả thấy rằng, nhiều cán bộ sản xuất không lƣu thông tin về hệ thống giả lập này. Các thông tin đó là: thành phần A đặt ở thƣ mục nào, trên máy chủ nào. Khi đó cán bộ sản xuất sẽ phải tìm kiếm hoặc dựng lại hệ thống giả lập. Điều đó gây lãng phí thời gian.
Biểu đồ 3.8 Kết quả khảo sát cho câu hỏi “Anh/chị có gặp trƣờng hợp cần kiểm tra một chức năng, nhƣng lại không biết hệ thống giả lập đặt ở đâu, dẫn đến
phải dựng lại hệ thống giả lập”
Nguồn: Kết quả khảo sát năm 2015 của tác giả
56
Công ty có quy định về thƣ mục lƣu giữ tài liệu, mã nguồn. Ví dụ: các tài liệu về Kinh doanh nhƣ là hợp đồng thì để ở thƣ mục Business, các tài liệu Kế hoạch và Báo cáo để ở mục Plans&Report, các tài liệu Yêu cầu kỹ thuật để ở mục Requirements
Hình 3.3 Cấu trúc các thƣ mục để tài liệu.
Nguồn: Dự án tác giả đang thực hiện
Qua khảo sát, tác giả nhận thấy nhiều nhân viên chƣa tuân thủ quy định này (32,5% nhân viên bị khoảng 1 lần/tháng, 25% bị 1 lần/2 tuần). Điều này dẫn đến việc những ngƣời khác trong nhóm dự án sẽ mất nhiều thời gian để tìm kiếm các tài liệu cần thiết.
Biểu đồ 3.9 Kết quả khảo sát cho câu hỏi “Anh/chị có gặp trƣờng hợp mất nhiều thời gian để tìm tài liệu giải pháp, thiết kế, mô tả về sản phẩm hoặc hệ
thống do chúng không đƣợc đặt ở thƣ mục hoặc nơi quy định”
Nguồn: Kết quả khảo sát năm 2015 của tác giả
Xác định đúng phiên bản
Trong quá trình thực hiện dự án, sẽ có rất nhiều những thay đổi về sản phẩm do nguyên nhân khách quan, ví dụ nhƣ khách hàng yêu cầu thay đổi chức năng, hoặc các cán bộ trong dự án đề nghị thay đổi thiết kế ban đầu. Khi có thay đổi, các
57
cán bộ trong dự án thƣờng có thói quen vẫn lƣu phiên bản cũ của tài liệu, phiên bản cũ mã nguồn để khi cần thiết có thể lấy lại đƣợc các thông tin cũ.
Hình 3.4 Một tài liệu có nhiều phiên bản.
Nguồn: các tài liệu của dự án tác giả đang thực hiện
Có nhiều trƣờng hợp mà phiên bản tài liệu, phiên bản mã nguồn mới nhất lại không phải là phiên bản đang sử dụng. Ví dụ: phiên bản sản phẩm đang sử dụng bên khách hàng đƣợc đánh mã là 3.3, khách hàng yêu cầu bổ sung một tính năng, do đó, cán bộ sản xuất tạo một phiên bản mới của sản phẩm, đặt thứ tự phiên bản là 3.4. Tuy nhiên, sau đó khách hàng nói rằng, chƣa cần cần bổ sung tính năng vào thời điểm này, chính vì vậy, phiên bản 3.3 vẫn là phiên bản mới nhất đang sử dụng. Bản 3.4 vẫn đƣợc lƣu để khi cần thì có thể triển khai ngay.
Biểu đồ 3.10 Kết quả khảo sát cho câu hỏi “Anh/chị có mất thời gian để xác định đúng phiên bản tài liệu, phiên bản mã nguồn mà mình đang cần tìm do
lƣu nhiều phiên bản nhƣng không có chú thích về tài liệu không?”
Nguồn: Kết quả khảo sát năm 2015 của tác giả
Chính vì vậy, việc lƣu thông tin mô tả về phiên bản tài liệu và mã nguồn là cần thiết. Tuy nhiên, qua khảo sát, tác giả nhận thấy nhiều nhân viên thƣờng không lƣu thông tin mô tả về tài liệu và mã nguồn, dẫn đến khi cần, sẽ lãng phí thời gian để xác định phiên bản tài liệu hoặc mã nguồn mà nhân viên đó đang cần. Việc này còn tiềm ẩn rủi ro nếu xác định sai phiên bản.
58
3.3.2.2 Lãng phí do kiến thức, thông tin rời rạc
Thiết kế sản phẩm không tốt
Sản phẩm của công ty ELCOM là các hệ thống phần mềm Công nghệ thông tin để giúp khách hàng kinh doanh, tìm kiếm lợi nhuận. Vì thị trƣờng thƣờng xuyên thay đổi nên nhu cầu bổ sung tính năng cho sản phẩm để đáp ứng các thay đổi trong chiến lƣợc kinh doanh của khách hàng diễn ra thƣờng xuyên. Các sản phẩm phần mềm của công ty ELCOM cần đáp ứng đƣợc nhu cầu này của khách hàng là thay đổi nhanh nhƣng vẫn phải đảm bảo chất lƣợng, không bị lỗi.
Biểu đồ 3.11 Kết quả khảo sát cho câu hỏi “Anh/chị có gặp khó khăn khi cần bổ sung tính năng cho các module phần mềm do thiết kế ban đầu chƣa tốt?”
Để đáp ứng đƣợc yêu cầu là sản phẩm dễ dàng nâng cấp mà vẫn đảm bảo chất lƣợng thì khâu thiết kế ban đầu tốt là rất quan trọng. Tuy nhiên, qua khảo sát, tác giả nhận thấy tỷ lệ nhân viên mất nhiều thời gian để bổ sung tính năng cho sản phẩm do việc thiết kế ban đầu chƣa tốt là lớn. Ngoài lãng phí thời gian, việc chậm cập nhật sản phẩm có thể làm mất cơ hội kinh doanh của khách hàng. Từ đó làm giảm uy tín của công ty ELCOM.
Chƣa nắm vững công nghệ
Khi sản xuất một phần mềm, nếu khi thực hiện sản xuất, ngƣời lập trình viên có đầy đủ các kiến thức về các công cụ, ngôn ngữ lập trình thì họ sẽ nhanh chóng thực hiện đƣợc sản phẩm của mình. Nếu không, họ sẽ phải dành thời gian để tìm hiểu sâu hơn về các công cụ, ngôn ngữ lập trình mà họ đang sử dụng để thực hiện yêu cầu đề ra. Qua khảo sát, tác giả nhận thấy số ngƣời phải bỏ thời gian khi đang thực hiện dự án để nghiên cứu về công cụ mình đang dùng là khá lớn (34% thƣờng
59
thƣờng, 33% nhiều và 18% luôn luôn). Đây cũng là một loại lãng phí do kiến thức rời rạc.
Biểu đồ 3.12 Kết quả khảo sát cho câu hỏi “Khi làm một sản phẩm mới, anh chị có hay mất thời gian để tìm hiểu xem phải dùng các công cụ, thƣ viện mình
nhƣ thế nào để đáp ứng đƣợc yêu cầu?”
Nguồn: Kết quả khảo sát năm 2015 của tác giả
Truyền đạt thông tin
Lĩnh vực sản xuất phần mềm là lĩnh vực cần sự phối hợp làm việc nhóm. Nhƣ trong sơ đồ Quy trình sản xuất phần mềm, chúng ta có thể thấy, thƣờng xuyên có những trao đổi thông tin, chuyển giao thông tin giữa các phòng ban (sản xuất, triển khai, kiểm thử), giữa các nhân viên trong cùng phòng ban thuộc dự án, giữa trƣởng bộ phận với QTDA, giữa QTDA với nhân viên sản xuất … Do đó, việc truyền đạt thông tin một cách chính xác khi làm việc nhóm là rất cần thiết. Qua khảo sát, tác giả nhận thấy, tỷ lệ nhân viên gặp tình huống làm sai do việc truyền đạt thông tin thiếu chính xác chiếm khá lớn. Điều này có thể gây ra lãng phí thời gian do nhân viên phải làm lại sản phẩm để đáp ứng đúng yêu cầu.
Biểu đồ 3.13 Kết quả khảo sát câu hỏi “Anh/chị có gặp trƣờng hợp thực hiện một công việc sai so với yêu cầu do ngƣời đƣa ra yêu cầu truyền đạt thông tin
thiếu chính xác?”
60
Sử dụng công cụ
Để phục vụ cho việc quản lý, hỗ trợ trong công việc, Công ty ELCOM sử dụng rất nhiều những công cụ hỗ trợ. Đó là công cụ nhƣ SVN: quản lý phiên bản phần mềm; ET: quản lý công việc; AMIS: quản lý nhân sự … Nếu nhân viên có thể tận dụng tốt các công cụ đó thì sẽ hỗ trợ rất nhiều trong công việc. Qua khảo sát, tác giả nhận thấy, phần lớn nhân viên không bị sai sót trong việc sử dụng các công cụ hỗ trợ. Tuy nhiên cũng vẫn còn những trƣờng hợp nhân viên thao tác nhầm lẫn. Các nhầm lẫn đó có thể là mất tài liệu, mã nguồn do không hiểu rõ về SVN. Điều đó gây ra sự lãng phí thời gian để khôi phục tài liệu, mã nguồn.
Biểu đồ 3.14 Kết quả khảo sát cho câu hỏi “Anh/chị có thao tác nhầm với các công cụ hỗ trợ nhƣ SVN, ET, EP rồi sau đó mất thời gian để khắc phục?”
3.3.2.3 Lãng phí do chờ đợi
Trong công ty phần mềm, hầu hết các dự án sản xuất đều đƣợc tổ chức dạng nhóm thực hiện. Các thành viên trong nhóm dự án thƣờng xuyên phải phối hợp và tƣơng tác trong công việc. Qua khảo sát, tác giả thấy rằng, nhiều nhân viên vẫn gặp tình trạng phải dừng công việc họ đang làm do cần phối hợp với ngƣời khác nhƣng ngƣời ấy đang bận việc khác. Điều này gây ra sự lãng phí do phải chờ đợi.
Biểu đồ 3.15 Kết quả câu hỏi “Anh/chị có hay gặp trƣờng hợp phải dừng công việc hiện tại do cần sự phối hợp của một ngƣời khác trong nhóm nhƣng mà
61
Nguồn: Kết quả khảo sát năm 2015 của tác giả
Một dạng lãng phí do chờ đợi khác là khoảng thời gian mà nhân viên rảnh rỗi nhƣng vẫn nhận lƣơng. Qua khảo sát, tác giả nhận thấy, lãng phí này diễn ra tại công ty với tỷ lệ khá cao – 30% là khoảng 1 ngày/1 tháng, 25% là khoảng 1 ngày/2 tuần.
Biểu đồ 3.16 Kết quả khảo sát cho câu hỏi “Anh/chị có thời gian rảnh trong công việc không?”
Nguồn: Kết quả khảo sát năm 2015 của tác giả
3.3.2.4 Lãng phí do gia công thừa
Trong công ty, các nhóm dự án thực hiện các dự án khác nhau. Trong các dự án thì sẽ phân chia cho mỗi nhân viên làm một thành phần nào đó. Trong thực tế, có nhiều những thành phần của các nhóm dự án đƣợc làm ra để đáp ứng những chức năng, mục đích tƣơng tự nhau. Do đó, nếu không thể tận dụng đƣợc những thành phần tƣơng tự nhau này thì sẽ làm lãng phí nguồn lực. Qua khảo sát, tác giả thấy rằng, tỷ lệ nhân viên thƣờng gặp trƣờng hợp này cũng khá cao.
Biểu đồ 3.17 Kết quả khảo sát cho câu hỏi “Anh/chị có bao giờ mất nhiều thời gian để làm một giải pháp, phát triển một chức năng, sau đó anh/chị phát hiện
62
ra rằng, một nhóm dự án c đã làm giải pháp, phát triển chức năng, tƣơng tự rồi?”
Nguồn: Kết quả khảo sát năm 2015 của tác giả
3.3.2.5 Lãng phí do sản xuất lỗi và sự sửa lỗi
Sản xuất lỗi
Theo nhƣ quy trình sản xuất phần mềm, các thành phần của sản phẩm khi thực hiện xong cần phải đƣợc ngƣời làm ra thành phần đó kiểm thử để đảm bảo chúng hoạt động đúng những tình huống cơ bản nhất của yêu cầu sản phẩm. Tiếp theo, thành phần đó đƣợc chuyển giao sang bộ phận đảm bảo chất lƣợng để kiểm tra theo các tình huống kiểm thử (test case) chi tiết. Khi đáp ứng đƣợc yêu cầu kiểm tra, thành phần sẽ đƣợc triển khai sang khách hàng để vận hành.
Biểu đồ 3.18 Kết quả khảo sát cho câu hỏi “Anh/chị có thƣờng kiểm thử sản phẩm với các tình huống kiếm thử cho các sản phẩm do mình viết ra hoặc
63
Nguồn: Kết quả khảo sát năm 2015 của tác giả
Nếu việc kiểm thử không làm tốt, sản phẩm khi vận hành có thể sẽ có lỗi. Khi đó, khách hàng sẽ là ngƣời chịu thiệt hại, và công ty sẽ bị mất lòng tin từ khách hàng, nghiêm trọng hơn là công ty còn có thể bị phạt nếu trong hợp đồng có điều khoản này. Do đó, việc kiểm thử là khâu quan trọng. Qua khảo sát, tác giả nhận thấy, việc kiểm thử sản phẩm vẫn còn đƣợc thực hiện chƣa nghiêm túc, 48,8% ngƣời đƣợc hỏi thƣờng chỉ kiểm thử 1 trong khoảng 4 sản phẩm mình làm ra. Chỉ có 12% ngƣời đƣợc hỏi là luôn luôn kiểm thử với các tình huống kiểm tra cho sản phẩm của mình làm ra.
Nguồn lực sửa lỗi
Một sản phẩm bị lỗi khi vận hành cũng dẫn đến việc công ty phải bỏ thời gian để xác định nguyên nhân gây lỗi, lên phƣơng án khắc phục lỗi. Các nhân sự sau khi xong một dự án, họ sẽ đƣợc phân công làm sản phẩm tại một dự án khác. Nếu một sản phẩm cũ bị lỗi, họ sẽ phải dừng công việc hiện tại để tìm nguyên nhân và khắc phục lỗi. Việc tìm nguyên nhân lỗi là rất phức tạp và mất thời gian vì các sản phẩm lỗi phần mềm thƣờng có nhiều nguyên nhân chủ quan do ngƣời vận hành hoặc khách quan do phần cứng, hạ tầng hoặc các thành phần kết nối đến hệ thống phần mềm bị lỗi. Qua khảo sát, tác giả thấy rằng, 40% ngƣời đƣợc hỏi rất hay gặp trƣờng hợp đang làm một sản phẩm khác mà phải dừng công việc đó để khắc phục lỗi của một sản phẩm cũ.
Biểu đồ 3.19 Kết quả khảo sát cho câu hỏi “Anh/chị có gặp trƣờng hợp đang rất bận với một dự án, mà khách hàng lại yêu cầu xử lý lỗi gấp với một sản phẩm đang vận hành hoặc một kế hoạch, một giải pháp đã hoàn thành trƣớc
64
Nguồn: Kết quả khảo sát năm 2015 của tác giả
3.3.2.6 Lãng phí do không khai thác sức sáng tạo của ngƣời lao động
Để tìm lãng phí này, tác giã đã tiến hành thu thập thông tin về hoạt động sáng tạo ở công ty. Công ty ELCOM có một hoạt động là Câu lạc bộ Sáng tạo. Mục đích của câu lạc bộ sáng tạo là để tạo sân chơi cho các nhân viên đề xuất ý tƣởng kinh doanh. Tuy nhiên, Câu lạc bộ sáng tạo chỉ hoạt động hiệu quả đƣợc trong một thời gian ngắn (khoảng 2 tháng), sau đó thì hoạt động không hiệu quả.
Hình 3.5 Cây sáng kiến ý tƣởng tại ELCOM
Qua khảo sát, tác giả nhận thấy rằng, phần lớn nhân viên biết đến CLB Sáng tạo và hiểu về hoạt động của CLB (chiếm 63%).
Biểu đồ 3.20 Kết quả khảo sát cho câu hỏi “Anh/chị có biết về hoạt động của Câu lạc bộ Sáng tạo ELCOM?”
65
Một câu hỏi tiếp theo là “Anh/chị có bao giờ nghĩ cách để cải thiện quy trình sản xuất, kinh doanh tại công ty để giảm lãng phí về thời gian, nguồn lực không?”.