CHƯƠNG 3 HIỆN TRẠNG CÔNG TY CỔ PHẦN VNG
3.4. Phân tích vấn đề
Từ những vấn đề mà bộ phận phát triển phần mềm web tại công ty VNG đang gặp phải như trên, có thể nhận thấy bộ phận đang sở hữu nguồn lực lớn mạnh về cơ sở vật chất, trang bị kỹ thuật, cũng như đội ngũ nhân viên giàu kinh nghiệm, có nền tảng tốt (là cơ sở để tiếp nhận nhanh kiến thức mới), nhưng tất cả lại không được tổ chức trong một trật tự tốt, gây nên những xáo trộn và hoạt động không hiệu quả cả về nguồn lực máy móc thiết bị lẫn con người.
Bằng các thông tin tổng kết từ việc phỏng vấn các thành viên trong nhóm dự án (15 người) về những khó khăn và bài học kinh nghiệm được đúc kết từ cuối mỗi dự án (tham khảo thêm ở phụ lục C), có thể nhìn nhận sâu xa hơn về vấn đề hoạt động không hiệu quả từ phía bộ phận thông qua khâu quản lý, sử dụng nguồn lực và qui trình hoạt động của các dự án tại bộ phận. Điều này thể hiện qua 7 điểm tổng kết như sau:
1. Qui trình hiện tại không đáp ứng được yêu cầu phát triển nhanh và thay đổi yêu cầu thường xuyên từ các dự án
Trong năm 2011, công ty VNG với chiến lược phát hành và phát triển nhiều sản phẩm mới, đồng thời cập nhật nhiều bản nâng cấp cho các sản phẩm cũ nhằm duy trì khách hàng cũ và tìm kiếm khách hàng mới, đã đưa ra nhu cầu phát triển nhiều dự án web hỗ trợ với tương tác phức tạp, thời gian hoàn thành ngắn, có khả năng mở rộng và tiếp nhận thay đổi yêu cầu thường xuyên, qua đó mang lại lợi thế cạnh tranh cho các sản phẩm của công ty trên thị trường cạnh tranh
ngày càng xuất hiện nhiều đối thủ. Qui trình thác nước truyền thống, với sự phát triển sản phẩm tuần tự qua từng bước, đã trở nên ì ạch hơn trong các dự án hiện nay do yêu cầu ban đầu của hầu hết các dự án chỉ ở mức thô sơ (khả năng thay đổi yêu cầu rất cao), không chi tiết và ổn định như các dự án trước đây.
2. Chi phí phát triển, vận hành, bảo trì các sản phẩm của bộ phận tăng cao
Với qui trình hiện tại, thời gian chờ giữa các khâu trong quá trình phát triển dự án tương đối lớn, đặc biệt là khâu tiếp nhận và phân tích yêu cầu khách hàng, điều này làm giảm thời gian của các khâu khác, nhất là khâu kiểm thử (thường bị bỏ qua do không kịp tiến độ), làm ảnh hưởng đến chất lượng sản phẩm, gây nhiều lỗi trong thời gian vận hành, qua đó làm tăng chi phí sửa lỗi, bảo trì sản phẩm. Ngoài ra, nguồn nhân lực chưa được tối ưu hóa do cấu trúc dự án vẫn còn ở mức đơn giản của mô hình thác nước, phù hợp với những dự án có nội dung đơn giản trong giai đoạn đầu của bộ phận nên chi phí đầu tư cho dự án tăng cao, tỉ lệ thuận với độ phức tạp của các dự án hiện tại.
3. Phân bổ thời gian giữa các giai đoạn trong qui trình chưa hợp lý
Các yêu cầu thay đổi thường xuyên hơn và mong muốn được đáp ứng tốt những thay đổi đó từ khách hàng nội bộ đã đẩy các thành viên trong bộ phận làm việc với cường độ cao, song vẫn không thể nào làm hài lòng được khách hàng nội bộ. Nguyên nhân xuất phát từ việc phân bổ thời gian chưa hợp lý trong qui trình hiện tại, ưu tiên quá nhiều cho phần phân tích yêu cầu và thiết kế, chiếm nhiều thời gian từ phía lập trình, làm cho các vấn đề phát sinh trong quá trình lập trình không có thời gian để giải quyết, trực tiếp tạo nên các lỗi tiềm ẩn trong sản phẩm.
4. Xác định độ ưu tiên của các yêu cầu và giá trị của nó chưa chính xác
Sự phối hợp không nhịp nhàng giữa các bên liên quan, giữa khách hàng và nhóm dự án, giữa các thành viên trong dự án đã gián tiếp tạo ra các quyết định không chính xác, dẫn đến việc thực hiện những quyết định này cũng không giúp giải quyết nhiều vấn đề mà bộ phận đang gặp phải. Nhìn nhận từ phía cấp quản lý bộ phận, việc tăng hiệu suất làm việc từ phía nhân viên là điều đáng mừng,
nhưng theo nguyên lý 80:20, việc quyết định đúng những công việc cần thực hiện trước và sau, nói cách khác là xác định độ ưu tiên của công việc chính xác, đưa 20% công việc cần giải quyết gấp để đem lại 80% sự ổn định cho hệ thống, lại không được thực hiện tốt, tạo nên hiệu quả làm việc không tốt của toàn bộ phận. Điều này không được thể hiện trong qui trình hiện tại.
5. Bài học kinh nghiệm (lesson learned) được rút ra sau mỗi dự án, đã không được tận dụng để giảm rủi ro cho các dự án tiếp theo
Ở hầu hết các công ty hoạt động trong lĩnh vực CNTT, việc đánh giá và rút ra các bài học kinh nghiệm sau mỗi dự án là việc làm rất quen thuộc, góp phần tạo nên kho kinh nghiệm quý báu, phục vụ cho công tác hoạch định, quản lý rủi ro và lên danh sách các điều cần phải đáp ứng (check list) trong các dự án tiếp theo. Tuy nhiên, kho kinh nghiệm này lại không được tận dụng tốt ở bộ phận phát triển phần mềm web, gián tiếp tạo nên các lỗi không đáng có và lặp lại nhiều trong quá trình phát triển các sản phẩm.
6. Thời gian chờ trong giao tiếp giữa các bộ phận hỗ trợ và khách hàng với nhóm dự án tăng cao
Giao tiếp chủ yếu giữa bộ phận phát triển với khách hàng và với các bộ phận hỗ trợ trực tiếp cho dự án, hầu hết đều gián tiếp qua email và sử dụng các tài liệu tự định nghĩa. Điều này làm kéo dài thời gian thực hiện dự án, tạo nên các chi phí gia tăng không hợp lý, góp phần làm trễ kế hoạch dự án. Trung bình các tài liệu được hoàn tất và chuyển giao sau mỗi cuộc họp từ 3 đến 5 ngày, trong thời gian này, bộ phận lập trình không bắt đầu viết mã được do thông tin yêu cầu cụ thể cho tính năng chưa được rõ ràng.
7. Cấu trúc nhóm dự án phức tạp, nhiều cấp gây thất thoát và làm chậm dòng thông tin di chuyển
Các thành viên trong nhóm không chủ động trong công tác tiếp nhận yêu cầu từ khách hàng hoặc ra quyết định kiến trúc sử dụng trong dự án mà phải thông qua nhiều cấp (từ Project Manager, đến Team Leader), làm cho luồng thông tin về yêu cầu, cũng như thay đổi yêu cầu từ phía khách hàng chậm đến
với thành viên nhóm phát triển hoặc bị sai lệch (do người tiếp nhận thông tin không có chuyên môn về phát triển sâu sản phẩm), tạo nên những cuộc họp không cần thiết và lặp lại để thống nhất yêu cầu giữa các bên, chiếm nhiều thời gian của dự án (khoảng 35-40% tổng thời gian dự án), góp phần làm trễ tiến độ dự án.
Kết luận: Từ những vấn đề phân tích ở trên, có thể thấy được tầm quan trọng
của qui trình phát triển phần mềm trong các dự án của bộ phận. Các vấn đề 1,2 và 3 đã phân tích mối quan hệ này. Ở vấn đề 4, sự xác định các yêu cầu chủ chốt, đem lại giá trị cao cho dự án không được yêu cầu trong qui trình hiện tại mà dựa vào kinh nghiệm của người tiếp nhận, phân tích và quản lý yêu cầu của khách hàng. Tuy nhiên, việc xác định rõ mục tiêu của dự án trong nguồn lực (thời gian) hạn hẹp dựa trên các thực hành tốt từ phía qui trình là điều nên có.
Bên cạnh đó, việc giao tiếp trong dự án được đưa ra ở vấn đề 6 cũng cho thấy các qui định sử dụng phương thức truyền/nhận tin trong qui trình hiện tại chưa được định nghĩa, đa phần dựa trên thói quen của các thành viên trong nhóm dự án.
Tương tự, vấn đề 7 cũng chỉ ra được cấu trúc nhóm được tổ chức dựa trên mô hình phát triển hiện tại được sử dụng trong qui trình của dự án không còn phù hợp nữa.
Như vậy, một qui trình phát triển phần mềm nhằm cải thiện những hạn chế từ bộ phận phát triển phần mềm web tại công ty VNG là một trong các lựa chọn nhằm nâng cao hiệu quả các dự án, nâng cao chất lượng và sự hài lòng của khách hàng đối với sản phẩm.