Hello anh em. Mấy nay hơi kẹt nên 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 muốn nói đó 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
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.
Tới giai đoạn này thì lại quá nhiều vấn đề phát sinh. 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” anh em ạ. 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 dài thì thôi rồi, xác định luôn.
Thường thì trước thời điểm dự án lên dĩa, team triển khai sẽ chuẩn bị 1 danh sách 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ờ xong cái này, xong cái kia 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. Hoặc chính khách hàng họ sẽ tự chuẩn bị Test Case.
Khách hàng sẽ dựa vào các 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ó 19 tính năng. Trong đó có khoảng 4-5 tính năng must have thì chắc chắn những tính năng này phải nằm trong Test Case.
Nhưng thường thì dự án lúc nào cũng có râu ria vài tính năng phụ bổ trợ, những 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ì họ vẫn 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 họ.
Sign-off cho đóng dự án 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 khách hàng họ sẽ không hoặc 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 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.
Do đó, nói đi nói lại thì quan trọng nhất vẫn là do cách mình làm việc, 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ẽ những điều trên sẽ rất ít khi xảy ra.
Nói zậy thôi chứ điều này cũng bình thường đối với các dự án software ở Việt Nam. Ẩ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 dự án phía mình thì cách làm việc trong nội bộ 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 rõ ràng thì việc bỏ sót thông tin chỉ là chuyện một sớm một chiề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 vẫn còn chưa phù hợp. Hay nói đúng từ chuyên ngành hơn là: “độ trưởng thành chưa cao”.
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ì.
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ếu lúc đầu anh em làm kỹ, ok, quản lý mọi thứ chặt chẽ, đâu ra đó thì sau này sẽ đỡ cực rất-rất-rất-nhiều. Khổ trước sướng sau mà, hehe. Âu cũng có nguyên nhân của nó đú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ò của contact point bên phía họ.
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.
Tuy nhiên 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. Nhiều khi Gâu-lai thành gâu-gâu cũng hổng chừng :))
Anh em cần thảo luận gì thêm cứ comment phía dưới cho mình nhé! Bái bai anh em!
