Hello anh em. Mấy nay hơi kẹt nên mình cũng lười lên bài quá. Hôm nay mình muốn chia sẻ với anh em về dự án “sắp đóng” của mình 🙂 Và một trong những điều hay ho mình rút ra được tự dự án này đó là: Khi Go-live, mọi thứ mới chỉ bắt đầu 😀

Hồi làm dự án, anh em ai cũng mong chờ tới ngày Go-live. Go-live là cột mốc quan trọng của dự án. Nó đánh dấu mình đã bàn giao đúng dự án như những gì đã cam kết với khách hàng hay chưa. Hay nói đúng hơn, Go-live đánh dấu sự thành công của dự án. Và là bước đệm để đóng thành công dự án.

Nhưng khoan, để Go-live được là 1 vấn đề, nhưng Go-live xong lại là một vấn đề khác. Đâu phải cứ chạy tới Go-live là xong dự án :3

1. Vì sao 1?

Nhớ lại dự án hồi đó làm cũng chết lên chết xuống. Nhiều cái ngay cả chính bản thân mình cũng không kiểm soát và quản lý nổi nên đâm ra nó cứ rối nùi lên hết. Thực tế thì khi dự án bước vào giai đoạn nước rút sắp Go-live, thì ai cũng vắc giò lên cổ chạy hết. Hồi đó làm team mình có đúng 1 anh dev, 2 BA và 1 anh PM. Công việc mỗi người mỗi khác nhau. Ai cũng lo mà chạy hết.

Cái đáng nói ở đây là tới giai đoạn này thì lại phát sinh quá nhiều vấn đề. Xuất phát từ cả phía team triển khai lẫn từ phía khách hàng.

Khách hàng thì ông nào cũng như ông nào. Họ luôn bận các bạn à. Có những task đâu phải chỉ mình làm xong là done. Mà còn chờ confirm từ phía khách hàng. Họ phải test, phải chạy thử rồi confirm này nọ thì mới đóng task đó được. 2-3 cái thì ít. Chứ dính nguyên 1 list danh sách dài thì thôi, xác định luôn.

Thường thì trước thời điểm đưa dự án lên dĩa, team triển khai sẽ chuẩn bị 1 cái gọi là Go-live checklist. Đây là danh sách những việc team triển khai cần làm để chuẩn bị go-live hệ thống. Danh sách này sẽ bao gồm các đầu mục công việc, ai làm, trạng thái ra sao, ảnh hưởng như thế nào đến hệ thống.

Khách hàng sẽ dựa vào danh sách này để quyết định có nên Go-live hệ thống hay không. Hay phải chờ fix xong tính năng này, hoàn thành tính năng kia, abc, xyz, rồi mới cho Go-live.

Đó là phía khách hàng. Còn ở phía team triển khai mình, những gì làm ẩu, làm sai, làm tào lao là giai đoạn sau Go-live lộ diện sạch sành sanh ra hết 😂

Trước Go-live sẽ là giai đoạn UAT (User Acceptance Test). Giai đoạn này bên phía team triển khai mình sẽ cung cấp cho khách hàng các kịch bản test hệ thống. Gọi là các Test Case. Khách hàng sẽ dựa vào Test Case này để test xem thử hệ thống có chạy đúng theo requirement hay không. Yêu cầu kết quả ra quả trứng mà thực tế chạy ra cái ốp-la là thấy sai sai rồi :))

Kết quả UAT cũng là một điểm quan trọng để khách hàng cân nhắc có Go-live luôn hay không. Ví dụ requirement có 10 tính năng đi. Trong đó đâu đó khoảng 4-5 tính năng là “must have”. Thì chắc chắn sẽ nằm trong Test Case. Nhưng thường thì lúc nào cũng có 2-3 tính năng phụ, tính năng “nice to have”. Hoặc là tính năng cơ bản của hệ thống mà team triển khai lơ là bỏ qua, không care kỹ đến phần này. Và thường thì các tính năng này cũng sẽ… bị bỏ lơ trong Test Case, không xuất hiện trong Test Case. Do đó khách hàng cũng không test tính năng này được luôn.

Như mình nói phía trên thì khách hàng thường họ rất bận. Nhưng cơ bản thì khách hàng vẫn sẽ phụ thuộc vào đường đi nước bước của team triển khai. Và dường như chỉ cần một vài tính năng “must have” hoạt động trơn tru, thì họ đã có thể chấp nhận Go-live dự án rồi.

Khách hàng ai cũng muốn kỹ hết, ai cũng muốn có một service tốt hết. Đặc biệt khách hàng Việt Nam rất hay kéo dài dự án. Nếu làm không kỹ thì sẽ rất khó đóng dự án đối với khách hàng Việt Nam. Sign-off cho đóng dự án có nghĩa là hết được support, hết được fix/ bổ sung tính năng. Sign-off xong thì chỉ còn 1 giai đoạn ngắn support sau Go-live. Ký xong mà nếu có vấn đề gì khác thì rất dễ bị charge thêm tiền. Cho nên…

Và thường thì khách hàng khó mà có thể follow với mình xuyên suốt dự án được. Và kịch bản hay xảy ra nhất là… nước tới háng mới nhảy. Gần tới những cột mốc như UAT, hay Go-Live thì mới bắt đầu ngồi test, chạy thử. Lúc này mà có bug thì lại là quá gấp cho team triển khai.

Còn đối với team triển khai thì dự án càng kéo dài thì càng khó đóng. Càng kéo dài thì càng tốn resource cho dự án. Trên tâm lý chung như vậy, nên cả team triển khai và phía khách hàng sẽ có thể bỏ sót khá nhiều tính năng trong giai đoạn UAT, để đi ngay đến Go-live. Mặc dù đó chỉ là những tính năng “nice to have” hay “should have”.

Hệ quả dẫn tới những tính năng này không ai đảm bảo được nó hoạt động ổn cả. Và một khi nó chạy không ổn. Giai đoạn sau Go-live sẽ thấy rõ nhất. Chính end-user sẽ là người gặp và trực tiếp report lỗi này. Làm càng ẩu, UAT càng không kỹ thì giai đoạn support sau Go-live sẽ là mệt nhất.

Nhưng nói đi thì cũng nói lại. Quan trọng vẫn do cách làm việc của mình, cách mình guide khách hàng, cách mình tương tác day-by-day với họ như thế nào. Chắc chắn một điều là nếu làm tốt, be Agile tốt, thì sẽ không bao giờ xả ra những điều trên 🙂

2. Vì sao 2?

Nói thì nói vậy nhưng mình thấy vấn đề cũng là điều bình thường đối với các dự án software ở Việt Nam mình thôi. Ẩu, làm không kỹ, nguyên nhân chủ quan là một phần. Phần khác là do năng lực và thói quen của người Việt mình nữa.

Nói về team thì cách làm việc trong nội bộ team cũng là một nguyên nhân sâu sa. Anh em làm không kỹ, giao tiếp, trao đổi tài liệu không có 1 phương pháp khoa học thì việc bỏ sót thông tin, tài liệu chỉ là chuyện ít hay nhiều mà thôi. Rồi cách quản lý tài liệu, team site như thế nào cho hiệu quả cũng chưa.

Nói áp dụng công nghệ cho khách hàng để giúp công việc họ hiệu quả hơn. Mà ngay bản thân team mình cũng chưa làm được thì có vẻ không ổn lắm. Thiệt ra qua dự án này mình mới thấy được tầm quan trọng của việc “quản lý sự thay đổi”. Làm Agile mà không làm kỹ cái này thì rất dễ chết. Từ Agile thành “Mì-ăn-liền” trong vòng 1 nốt nhạc.

Thứ hai là cách làm việc và mindset của khách hàng Việt Nam mình còn chưa phù hợp. Họ chưa suy nghĩ thấu đáo được rằng làm cái này để làm cái gì, giúp ích được cái gì. Chưa có một sự cụ thể nào ở đây cả. Hay nói cách khác là họ chưa biết mình muốn gì. Và còn nhiều vấn đề khác nữa. Nói chung cũng đều đến từ 2 phía mà ra.

Do đó, một cái do đó rất bự, là thường thì sau Go-live, mọi thứ mới chỉ… bắt đầu 🙂 Dù có cực nhọc, lăn lê bò trường, nước mắt đầm đìa, lên bờ xuống ruộng bao nhiêu thì sau Go-live, mọi thứ vẫn mới chỉ… bắt đầu :v

Nói vậy thôi chứ nếu lúc đầu làm kỹ, ok, quản lý mọi thứ chặt chẽ, đâu ra đó thì sau này đỡ cực thôi :3 Khổ trước sướng sau mà. Âu cũng có nguyên nhân của nó mà đúng không anh em. Rút kinh nghiệm từ từ thôi.

Mà sẵn tiện nói về khách hàng thì mình nói luôn về vai trò contact point bên phía khách hàng.

Nếu được làm với một người contact point chịu thương, chịu khó 😂 thì đúng là trời thương mình. Cái ông contact point này ổng sẽ chịu trách nhiệm giao tiếp và phân bổ các đầu mối công việc giữa các bộ phận từ phía khách hàng với team triển khai. Ông này kiểu như “trung tâm vũ trụ” bên phía khách hàng vậy.

Mà thường dự án kéo dài, quá nhiều tính năng không được quản lý tốt. Thì chính cái ông contact point này – người có vẻ như nắm nhiều nhất và rành dự án nhất bên phía khách hàng, thường cũng sẽ… quên luôn tính năng nào cần-test và đã-được-test.

Có một số dự án người contact point rất kỹ. Họ muốn đảm bảo từng tính năng phải được giải quyết gọn, lẹ, trước khi chuyển sang tính năng khác. Những người như vậy lúc đầu thường thì khó để có cảm tình. Vì những người này thường tạo cho mình ấn tượng ban đầu hơi khó khăn. Nhưng khi đã quen cách làm việc rồi thì mọi thứ sẽ mượt hơn rất nhiều. Vì mình luôn có 1 người kỹ lưỡng bên cạnh mình. Điều này giúp cho dự án không bị sót tính năng nào hết. Dù cho tính năng must have hay nice to have.

OKayyy, trên là những chia sẻ của mình cho anh em về dự án ở giai đoạn Go-live. Đã ráng thì ráng cố gắng ngay từ đầu đến cuối dự án. 30 chưa phải là tết. Dự án chỉ đóng, khi nó đã được sign-off đóng dự án. Chứ Go-live xong cũng chưa nói được gì hết. Anh em cần thảo luận gì cứ comment phía dưới nhé!

Nguyen Hoang Phu Thinh

Hello anh em! Mình là Thịnh, hiện tại mình đang làm Business Analyst tại RBVH. Mình đang tập viết, tập đọc sách và góp nhặt những trải nghiệm trong nghề BA trên blog này. Hi vọng những chia sẻ của mình sẽ giúp ích được anh em 🙂 Read more about me