Golive – Bắt đầu của sự kết thúc

Nếu làm về lĩnh vực phần mềm, nếu bạn làm dự án đủ lâu chắc bạn sẽ trải qua một trong nhưng quá trình quan trọng được gọi là Golive.

Vậy Golive là gì? Và những vấn đề nảy sinh trong giai đoạn này sẽ như thế nào? Hãy cùng mình hiểu thêm nó thông qua câu chuyện cá nhân của bản thân nhé!

Có thể bạn đã nghe hay đọc ở đâu đó về những giai đoạn phát triển phần mềm. Từ khi sale kéo dự án về rồi đấu thầu dự án, lên kế hoạch chiến lược cho dự án; hay tham gia quá trình phát triển phần mềm như lấy yêu cầu, thiết kế, xây dựng, kiểm thử phần mềm; cuối cùng là đến nghiệm thu bàn giao sản phẩm. 

Có lẽ bạn sẽ nhận thấy rằng phần mềm chỉ dừng ở đó. Nhưng không! phần mềm không phải tạo ra để vứt xó, nó sẽ chỉ là sự kết thúc của giai đoạn xây dựng phần mềm.

Rồi đâu đó bạn lại nghe được giai đoạn UAT (User Acceptance Test) chăng. Bạn có thể hiểu là một sản phẩm bất kỳ được làm ra thì cần quá trình nghiệm thu, bảo trì bảo dưỡng thì giai đoạn UAT này chính là bản nghiệm thu mà bạn sẽ phải làm việc với khách hàng để bàn giao sản phẩm của bạn. Nó đạt chất lượng hay không hay phải bảo trì thêm. 

Golive chính là giai đoạn ngay sau giai đoạn UAT. Một giai đoạn cực kỳ quan trọng để đưa sản phẩm vào chạy thực tế. Hay nói đúng hơn, Golive đánh dấu sự thành công của dự án. 

Nhưng! Không phải cứ Golive là kết thúc và đóng được dự án nhé! Đây chính là bắt đầu của sự kết thúc!

Vì sao ư? Dưới đây sẽ là một số lý do chính mà mình nói là như vậy.

– Rời vào thế tiến thoái lưỡng nan

Trước Golive sẽ là giai đoạn UAT như mình đã nói ở trên. Giai đoạn này bên phía team phát triển sẽ cung cấp cho khách hàng các kịch bản test hệ thống. Vấn đề nằm ở chỗ khách hàng cũng chẳng quan tâm lắm đến bộ test case này và họ tin rằng chính team phát triển đã chắc chắn nó được kiểm thử rất kỹ. 

Bên cạnh đó họ sẽ tập trung vào những tính năng bổ sung. Và nó lại có 2 nguyên nhân chính mà khách hàng chỉ tập trung vào nó. 

Thứ nhất là giai đoạn bàn giao đồng nghĩa với việc sẽ tất toán chi phí, kiểu gì thì kiểu cũng kỳ kèo thêm một hai tính năng khuyến mại với số tiền tính ra phải trả định từ trước. 

Thứ hai là, khi chuẩn bị đưa vào thực tế sẽ có một tập khách hàng dùng thử vào sử dụng trước khi chạy trên diện rộng, quá trình này nhận được rất nhiều phản hồi và sửa đổi để đáp ứng được nhu cầu thực tế, trong khi quá trình này diễn ra rất nhanh và gấp vì cận kề thời gian nghiệm thu rồi.

Vậy là team phát triển lại è cổ đắp thêm tính năng mới trong thời gian ngắn (Đây sẽ là nguyên nhân tiềm ẩn thứ nhất), còn nếu từ chối thì lại không bàn giao được đồng nghĩa với việc không có thanh toán được tiền.

Chiều khách, phải chiều khách thôi, bạn là nhất!

– Giọt nước tràn ly

Lại tiếp tục câu chuyện chiều khách nhận đắp thêm những tính năng mới (sửa cho chị thêm chỗ này, thay cho anh cái kia, tiền vẫn vậy nha em), và thế là bạn hì hục đắp thêm, vá vào và vẫn phải đảm bảo những tính năng cũ chạy mượt.

Nếu bạn kiến trúc phần mềm đủ tốt, việc thêm bớt sẽ nhẹ nhàng hơn, nhưng nếu chỉ cần có quá nhiều sự phụ thuộc trong các thành phần của sản phẩm. Khi thay thế sửa chữa nó sẽ kéo theo cả một chuỗi sửa theo. 

Đây chính là domino, phải thật sự cẩn thận ở nhưng bước như thế này vì rất có thể bạn sẽ phá hoại cả một tòa nhà khi chỉ thay một viên gạch. Nó cũng là sự bắt nguồn của câu nói “Cái này có từ lâu rồi, đừng chạm vào!” của các senior dặn dò kỹ lưỡng các fresher như dâu con mới về ý.

Tuy rằng mô hình Agile khắc phục được điều này nhưng mà quá trình UAT và Golive rất ngắn để kịp có thể đưa vào chạy thực tế ngay nên thời gian kiểm thử lại rất ngắn mà vừa phải kiểm tra tính năng mới vừa phải đảm bảo không ảnh hưởng đến tính năng cũ.

Hot fix sẽ diễn ra nhiều hơn trong giai đoạn này (Đây sẽ là nguyên nhân tiềm ẩn thứ hai)

– Dữ liệu thực rất lớn và khác so với khi phát triển

Có những nghiệp vụ phần mềm, team phát triển không được biết trước dữ liệu thật do tính chất bảo mật của sản phẩm. Họ chỉ được tiếp cận với những mẫu data test tương tự mà thôi. Mọi thứ phát triển rất ổn cho đến khi Golive.

Sản phẩm được chạy trên dữ liệu thật và phát sinh rất nhiều vấn đề đơn giản chỉ bắt nguồn từ đầu vào quá khác so với môi trường phát triển. Thậm chí dữ liệu còn không được ràng buộc và rác rất nhiều, nếu bạn không có những bước tiền xử lý dữ liệu đầu vào không chặt chẽ, chắc chắn ứng dụng của bạn sẽ gặp lỗi. Mà những lỗi kiểu này rất mất thời gian để truy vết.

Một điều nữa là với dữ liệu thực khi golive rất lớn. Nếu bạn không kiểm thử trước hiệu năng ứng dụng và chuẩn bị các phương án cho dữ liệu lớn thì giai đoạn này bạn sẽ gặp những bài toán như đâm đầu vào tường đó.

– “Một cây làm chẳng nên non, ba cây cụm lại nên cành củi khô”

Thời điểm UAT nhân sự trong dự án chắc chắn giảm do thu hẹp chi phí nhất có thể, UAT thường sẽ không tính tiền khách hàng vì nó là giai đoạn bảo trì sản phẩm nên chi phí phải được thu hẹp nhất có thể. 

Tuy nhiên giai đoạn này các ông lớn, các sếp to lại thường hay nhảy vào để hoàn tất thủ tục chia bánh nhận kẹo. Bao giờ cũng thế, khổ thì chẳng thấy mặt, đến lúc chia quà thì bu lại rất nhiều.

Trơn tru thì không sao, với 2 lý do tiềm ẩn bên trên thì khả năng cao bạn sẽ gặp phải một vài vấn đề xử lý. Thế là mấy ông lớn chẳng cần biết mày xử lý thế nào nhưng cứ trách đầu tiên. Vô vàn câu hỏi tại sao lại để như vậy, làm ăn thế à, khách hàng chửi kia kìa, nhanh lên chứ.

Ôi! Áp lực từ khách hàng đã đủ khổ lại còn bị đổ lỗi, khiển trách, hối deadline các kiểu. Các cuộc họp lúc này thường từ sáng đến tối khuya chỉ để chỉ trích nhau. 

Vậy là những buổi hot fix, một ông sửa, những ông còn lại đứng sau khoanh tay nhìn. Xuyên đêm nha bé!

Vậy nên tin mình đi, sẽ có những anh em làm gần hết dự án đến gần gần UAT xin té vào biên chế cắt giảm nhân sự qua dự án khác. Những đứa ở lại là những đứa gánh sấp mặt. Nợ kỹ thuật thì luôn có, mà có nợ ắt phải trả. Chỉ là những ông ở lại sẽ là những ông trả nợ thay cho những người đã ra đi trong khi tiền cuối dự án rất ít nhưng trách nhiệm cực kỳ cao. Sai một ly là đi một sản phẩm, rồi thằng đi rồi đã không hiểu thì thôi còn quay lại chửi, trước tao code ngon vậy mà qua tay mày cái sập mẹ nó luôn. 

Nói thì nói vậy thôi nhưng đừng tiêu cực quá, giai đoạn UAT và giai đoạn Golive những người được chọn ở lại phải là những người nắm nghiệp vụ nhiều nhất và sâu nhất. Đây cũng là thử thách cũng như là cơ hội cho những ai muốn thăng tiến. Vì một khi xử lý Golive thành công, bạn sẽ được liệt vào danh sách phòng thần bảng vậy. Bạn sẽ được coi trọng hơn, được thấy sự trách nhiệm và khả năng xử lý vấn đề trong công việc, và chắn chắn bạn sẽ được đề bạt nếu thành công. 

Bên cạnh đó, đây là giai đoạn bạn học được nhiều nhất trong quá trình xử lý tất tần tật mọi khâu, mọi bước, mọi thứ, cân cả thế giới. Chính quá trình xử lý này đã dạy bạn rất nhiều thứ mà giai đoạn thường ngày không bao giờ xảy ra và gặp phải. Nếu bạn là người nhanh nhạy, bạn sẽ thu lượm được rất nhiều. Tự tin lên nhé!

Trên đây là những điều mà mình đã và đang trải qua với một tâm thế một là lên hương, hai là bỏ việc để có được những trải nghiệm như thế này không phải là dễ dàng. Và đây cũng không phải là câu chuyện kể về một dự án cụ thể nào cả, mà là tổng hợp nhiều dự án Golive mà mình đã trải qua. Mình biết có những anh chị không thích mình viết điều này. Nhưng nó là thực tế, nên để cho các em hay các bạn mới vào ngành được nhìn nhận một cách khách quan hơn. 

Thử thách luôn đi liền với cơ hội!

Cố lên nhé!
#ntechdevelopers