Working with "Old style" Japanese customer

Đầu tiên, khi dự định viết bài viết này, tôi đã định gửi tới người đọc như một case study trong quá trình thực hiện dự án. Nhưng sau khi suy nghĩ, tôi thấy nên viết bài viết như là kể một câu chuyện về dự án của tôi, một kinh nghiệm và là một bài học rất lớn đối với cá nhân tôi. Tôi mong muốn được chia sẻ kinh nghiệm này với mọi người, cũng như mong nhận được những đóng góp ý kiến của các bạn, vì chắc chắn, trong mỗi câu chuyện, chúng ta luôn có rất nhiều ý kiến trái chiều…

Tôi xin giải thích về khái niệm “Old style” mà tôi đã đưa vào tựa đề bài viết. Chắc hẳn, mọi người đều đã biết, người Nhật là những người vô cùng tỉ mỉ và cẩn thận. Sản phẩm của họ luôn hướng đến chất lượng cao nhất. Nhưng cũng chính vì hướng tới sự “hoàn mỹ” của sản phẩm, mà đôi khi việc phát triển sản phẩm ở Offshore trở nên rất khó khăn. Ở đây, có thể hiểu “Old style” ở khách hàng Nhật chính là sự cầu toàn quá mức, là không chấp nhận những điều chưa tốt dù nhỏ nhất. Hãy thử tưởng tượng, phát triển sản phẩm với khách hàng chưa thực sự rõ về requirements ở một dự án Fix price. Chúng ta sẽ gặp những điều gì !? Đây chính là câu chuyện mà tôi muốn chia sẻ tới tất cả mọi người.

Nói qua về dự án, đây là một dự án khá lớn, khách hàng cũng thuộc vào nhóm Enterprise customer, một khách hàng "to" và có tiếng ở Nhật. Dự án theo plan ban đầu là sẽ kéo dài 6 tháng với 12 members. Về sản phẩm, dự án của tôi làm Windows application, và khách hàng cũng là lần đầu tiên làm việc với một Offshore team của Việt Nam. Không những thế, source code base của dự án, cũng không phải của nhóm khách hàng này phát triển từ đầu, mà họ được hand-over từ một phòng ban khác trong công ty. Khi Offshore team bắt đầu tìm hiểu specification, thì bên khách hàng cũng mới bắt đầu thực hiện công việc này. Vì cũng tin tưởng khách hàng là người có kinh nghiệm lâu năm, và cũng vì team còn nhiều phần non kinh nghiệm, nên quá trình xác định và soạn thảo ra worklist của dự án đã diễn ra nhanh chóng, nội dung của bản worklist đã quá sơ sài, không đủ thông tin, thiếu những cam kết chặt chẽ. Đây chính là sai lầm đầu tiên của dự án, và bài học rút ra là: Cần phải làm rõ requirement để xác định được worklist của dự án chi tiết nhất có thể.

Vì mới làm việc với Offshore, dường như khách hàng chưa thực sự chấp nhận framework làm việc của team. Team đã giới thiệu một tool khá "xịn" là JIRA, với mong muốn khách hàng cùng quản lý và tracking dự án với team. Tuy nhiên, khách hàng vẫn rất truyền thống, họ thường xuyên yêu cầu team báo cáo bằng Excel, thay đổi template liên tục, chỉ sử dụng JIRA để export tài liệu ra file Excel và quản lý ở SVN. Effort về mặt quản lý của team đã tăng lên rất nhiều để thỏa mãn các template của khách hàng. Đây là điểm sai tiếp theo mà đã khiến cho dự án rơi vào trạng thái “rối” và chồng chéo về mặt quản lý. Bài học rút ra là: Khi bắt đầu dự án, cần phải thống nhất framework làm việc để đỡ tốn effort nhất cho cả hai bên.

Với các sai lầm ở trên, chắc mọi người cũng đã biết trạng thái của dự án như thế nào, rất “chồng chéo” và “mơ hồ” (Có lẽ là tôi dùng từ không được đúng lắm, nhưng dễ hình dung hơn). Khi đã kết thúc giai đoạn làm Design, dự án tiến hành code, thì khách hàng bắt đầu hiểu ra rất nhiều vấn đề về requirement (mà họ đã thực hiện nghiên cứu cùng thời điểm với offshore). Họ đưa thêm rất nhiều yêu cầu, họ push yêu cầu liên tục, liên tục (Đây chính là cách làm việc gọi là “Old style” mà chính một bác khách hàng người Nhật khác, đã định nghĩa khi nghe tôi chia sẻ về cách làm này). Có những request mà mình cần sửa, nhưng cũng có những request họ đòi mình làm thêm. Là khách hàng mới, và cũng một phần là vì team đánh giá không tốt (có phần hơi chủ quan) về những yêu cầu nhỏ của khách hàng là mình sẽ làm rất nhanh, do đó đã dẫn đến sai lầm tiếp theo là “Chiều khách”. Tích tiểu thành đại, nhiều request nhỏ đã thành vấn đề lớn. Effort của team hầu hết là để chạy theo yêu cầu của khách hàng, tính chủ động dần mất đi và thay vào đó là “đuổi” và “đuổi”. Hệ quả tất yếu là “sức khỏe” dự án yếu đi, tinh thần đội dự án giảm sút và productivity ngày càng xuống. Bài học rút ra là: Không được nhân nhượng với bất kỳ thay đổi yêu cầu (CR) nào của khách hàng.

Với những vấn đề đã xảy ra đối với dự án, đương nhiên hiện tại dự án của tôi đang chạy trong tình trạng “sáng lấp lánh”. Những thay đổi và cố gắng của dự án đã có kết quả song những nỗ lực này đã khiến tất cả members mệt mỏi vô cùng. Những bài học mà tôi rút ra từ dự án này là những bài học rất “kinh điển”. Có nhiều người sẽ đặt câu hỏi: “có cái gì lạ đâu, toàn những điều đã biết trước rồi mà vẫn vấp phải”. Tôi cũng xin nói rằng, trước khi làm dự án này, tất cả những điều trên, tôi cũng đều biết. Và vì rất nhiều lí do gặp phải, những điều đáng tiếc vẫn xảy ra.

Case study có loại “tốt” và loại “xấu”. Case của dự án này, tôi có thể nói là rất “xấu”. Nhưng tôi vẫn muốn chia sẻ đến tất cả mọi người những ai làm dự án phần mềm, đặc biệt là làm việc với khách hàng "Old style". Để khi làm dự án, không ai còn mắc phải những cái sai “kinh điển” mà dự án tôi đã mắc phải. Để dù cho là khách hàng “Old style”, hay là khách hàng “New style”, chúng ta đều có thể làm được!