Hóa giải những hiểu nhầm về các dự án trong giai đoạn "operation"

Nhiều Sunner vẫn thường nhầm giữa giai đoạn "operation" với giai đoạn "maintain", và luôn cảm thấy dự án trong giai đoạn này mang đến nhiều thử thách cho các lập trình viên mới vào nghề, bởi đây là giai đoạn đòi hỏi tính chủ động tìm tòi, học hỏi cao để nắm bắt được nghiệp vụ, cũng như nghiên cứu document hay spec cũ của dự án.

Hãy cùng Sun* News "hóa giải" một số hiểu nhầm, cũng như nhìn nhận lại một cách toàn diện về những dự án trong giai đoạn operation dưới góc nhìn của những tiền bối tại Sun*, để nhận ra rằng làm dự án operation không hề khó như chúng ta nghĩ mà ngược lại, còn tặng cho các developer mới vào nghề rất nhiều điều quý giá, bổ ích và chẳng kém phần thú vị.

Operation - Một khâu cực kỳ quan trọng

Tuy nhiều Sunner thường hiểu nhầm giữa hai cụm từ "operation""maintain", nhưng thực chất bản thân các dự án không có khái niệm "maintain", tức là chúng ta không chủ yếu duy trì dịch vụ chạy ổn định nữa, mà phải liên tục cải thiện, cải tiến sản phẩm nhằm đáp ứng nhu cầu tốt hơn nữa cho khách hàng. Do đó, operation chính là giai đoạn cuối cùng của chu trình với những đầu việc quan trọng như: sửa lỗi, cải thiện hệ thống, nâng cấp, mở rộng chức năng mới để đáp ứng nhu cầu của người dùng, v.v. Bàn về khâu này, anh Huy Tuấn (CEV07) - một developer lão luyện đã có kinh nghiệm làm 5 dự án operation tại Sun* cho biết: “Nhiều thống kê cho thấy operation chiếm đến khoảng 70% toàn bộ công sức bỏ ra cho 1 dự án phần mềm. Do vậy có thể nói đây là một hoạt động vô cùng cần thiết trong chu trình sống của sản phẩm, để đảm bảo sản phẩm luôn phù hợp với người sử dụng.” 

Có thể nói, thành bại của sản phẩm phụ thuộc rất lớn vào giai đoạn operation có thể sẽ kéo dài cực kỳ lâu này. Những sản phẩm thành công sẽ luôn là những sản phẩm có thể “chạy đường dài”, và operation chính là thứ cung cấp “nhiên liệu” cho chặng đường đó.

Thuận lợi so với các dự án ở giai đoạn khác?

So với các dự án ở các khâu khác, khi làm một dự án ở khâu operation, các developer thường than thở vì gặp phải một số chuyện như tài liệu không đầy đủ, rõ ràng khiến người mới mất rất nhiều thời gian tự mày mò tìm hiểu, nghiệp vụ khó nắm bắt nếu không có người chỉ dẫn, document sơ sài, thiếu thông tin, hay công nghệ sử dụng đã cũ, chưa được cập nhật... 

Tuy có rất nhiều thử thách là thế, nhưng cũng chỉ ở giai đoạn này, chúng ta lại học được rất nhiều thứ hay ho mà các khâu khác có thể sẽ không có được.

“Làm dự án operation giúp mình học hỏi các công nghệ, tích các các keyword, các mẫu thiết kế, giải pháp và quy trình làm việc, nó sẽ rất có lợi cho các bạn mới vào nghề.” 

(bạn Đào Phạm, CEV04)

“Tuy tâm lý chung của nhiều người là hơi “ngại" dự án operation, nhưng với mình, dự án ở giai đoạn này cũng cho mình rất nhiều điều hay ho như:

1. Học từ những người đi trước: 

- Cách thiết kế hệ thống, cách tổ chức code, cách viết tài liệu, ... đó đều là những bài học mà những người đi trước phải đánh đổi bằng rất nhiều công sức. Bạn có thể chọn lọc cái hay, tránh cái dở, dần tích cóp thành vốn liếng riêng cho mình. 

2. Giúp bản thân cẩn trọng hơn:

- Ở dự án operation, mỗi thay đổi đều có impact lớn tới hệ thống. Vì vậy, ngoài việc task hoạt động được, ta cũng cần chứng minh rằng nó hoạt động ổn định. -> Dân dần việc này sẽ tạo cho mình thói quen diễn giải vấn đề có dẫn chứng đầy đủ, lời nói có sức thuyết phục 

3. Tự do sáng tạo:

- Mọi người thường nghĩ rằng: Ở dự án mới toanh, ta mới có nhiều cơ hội để sáng tạo, để làm những ý tưởng mới. Nhưng trên thực tế, giai đoạn operation mới là lúc những ý tưởng mới được hiện thực hóa. Trong giai đoạn phát triển mới, gần như ta phải tập trung toàn bộ thời gian để deliver những chức năng mà KH mong muốn. Những ý tưởng, tính năng mới thường sẽ có xu hướng pending lại hoặc bị chen ngang bởi những công việc khác. Nên giai đoạn operation chính là lúc anh chị em ta được trả nợ đời, được thoải mái đưa ra các đề xuất và cải tiến.”

(Bạn Tấn Đức - CEV09)

“”Làm operation” giúp mình tăng khả năng kiên nhẫn, tìm hiểu, có thể học hỏi thêm kiến thức về hệ thống, operations và sẽ gặp được những vấn đề phát sinh, những tình huống ít xảy ra ở dự án mới, nhờ đó rút ra được rất nhiều kinh nghiệm hay.” 

(Bạn Công Tú - CEV05)

“Nếu có tài liệu đầy đủ, mọi người sẽ dễ dàng tìm hiểu nghiệp vụ hệ thống. Dự án đang chạy, code base đã có sẵn rồi, dev chỉ cần dựa theo các chức năng có sẵn và triển khai. Làm dự án operation chúng ta cũng ít khi phải chạy theo deadline so với dự án được làm mới.” 

(anh Huy Tuấn - CEV07)

Chinh phục thử thách operation

Tuy có rất nhiều điểm thuận lợi như trên, nhưng những thử thách mà một developer trẻ phải đối mặt khi tham gia dự án operationvẫn là khá lớn. Làm dự án operation đòi hỏi developer phải luôn chủ động, tìm tòi, học hỏi. Mặc dù vậy, nhiều bạn trẻ vẫn hoang mang với câu hỏi phải chủ động ra sao, tìm hiểu những gì, hay làm cách nào để nắm bắt được nghiệp vụ một cách nhanh nhất để có thể thay thế những người cũ làm dự án.

Thật may là các tiền bối nhà Sun* cũng có rất nhiều lời khuyên bổ ích cho các Sunner đây:

"Theo mình, các bạn trẻ nên dành thời gian tìm hiểu tổng quát về hệ thống để có cái nhìn tổng thể. Sau đó thì sẽ đi sâu vào các tính năng. Bên cạnh đó, việc đọc tài liệu, đọc code và tự tạo cho mình 1 document riêng cho mỗi dự án cũng đóng vai trò cực kỳ quan trọng.

Hơn thế nữa, hãy giữ cho mình tâm thế vững vàng, dũng cảm. Bởi làm dự án operation chưa bao giờ nhàm chán cả."

(Bạn Công Tú - CEV05)

Hãy luôn hỏi người đi trước, vì có những thông tin dự án không được ghi đầy đủ vào tài liệu, mà nằm trong đầu developer. Thế nên các bạn đừng bao giờ ngại hỏi, cứ "túm đầu" ông team lead, bê máy sang pair programing luôn. Bạn sẽ nắm được quy trình làm việc, cách build hệ thống, convention rất nhanh. 

Không gì học nhanh bằng cách bắt tay vào làm: Hãy hỏi xin team lead những task đơn giản để thử trước. Từ những task nhỏ này, các bạn sẽ dần nắm được work flow dự án, clear spec hơn. Quan trọng nhất là nó giúp đem lại sự tự tin, thoải mái để làm công việc sau này. Ở dự án operation, cái đáng sợ nhất là xác định mức độ ảnh hưởng. Vì vậy, các bạn hãy luôn trả lời câu hỏi: Tính năng này có ảnh hưởng tới user cũ không?

(Bạn Tấn Đức - CEV09)

Spec là thứ cực kỳ quan trọng, trước khi những người cũ "ra đi", nếu có thể bạn hãy yêu cầu họ chỉ dẫn hoặc cung cấp spec cho mình kèm theo là cấu trúc cơ sở hạ tầng của hệ thống, hay quy trình làm việc.

(bạn Đào Phạm, CEV04)

Thông thường khi bạn mới vào dự án, bạn sẽ có thời gian training, nghiên cứu và tìm hiểu hệ thống và tìm hiểu về Công ty khách hàng, các services, sản phẩm của họ, để có cái nhìn tổng quan về dự án. Hãy hiểu về cách hoạt động của các màn hình chức năng đã có trong hệ thống, để hiểu luồng hoạt động của nó. Hãy chịu khó đọc tài liệu mà những người đi trước để lại (nếu có), nếu là dev có thể kết hợp với việc đọc code, đọc những comment code có trong source dự án. Ngoài ra, hãy bổ sung các kiến thức liên quan trong nghiệp vụ dự án sử dụng, các công nghệ sử dụng trong dự án mà mình chưa biết, chưa làm tới bao giờ, và mạnh dạn đặt câu hỏi và trao đổi với các đồng nghiệp như Brse, QA, Dev những vấn đề đang mắc phải. 
 

Mình cũng chia sẻ thêm mốt số kinh nghiệm "đánh án" operation cá nhân như sau:

- Khi bắt đầu nhận 1 ticket nào đó, các bạn cũng không nên lao đầu vào code ngay lập tức. Cần phải hiểu rõ yêu cầu khách hàng là gì, chỗ nào chưa rõ cần phải được confirm rõ ràng, trao đổi vs QA xem 2 bên có hiểu yêu cầu như nhau không, tránh trường hợp mạnh ai người đó làm, không trao đổi, mỗi người 1 ý. 

- Điều tra mức độ ảnh hưởng của chức năng cần sửa chữa, tránh trường hợp sửa chỗ này lại hỏng chỗ khác. Note lại vào trong ticket để QA biết và confirm lại hoạt động các màn hình ảnh hưởng. + Estimate và triển khai 

- Sau khi dev xong thì nên self-test lại cẩn thận (viết UT nếu có). 

- Đối với các chức năng cải thiện performance, phân tích và tối ưu SQL query, khi code xong hãy so sánh kết quả trước và sau khi sửa code. 

- Trau dồi thêm kỹ năng phân tích logs, phán đoán & điều tra bugs, báo cáo chi tiết rõ ràng. 

- Source code là tài sản của Khách Hàng, nên muốn chỉnh sửa gì cũng nên được sự cho phép của KH (giả sử nếu thấy chức năng A, đoạn code B này không ổn, chưa tối ưu, bạn cũng không nên tự ý refactor lại, hãy thông báo & suggest khách hàng, khi được sự cho phép ta mới tiến hành sửa chữa) 

(anh Huy Tuấn - CEV07)

Hy vọng rằng những kinh nghiệm vô giá từ các tiền bối nhà Sun* đã phần nào giúp các "tân binh" hào hứng trên con đường học hỏi những điều thú vị mới từ những dự án operation, để dù làm dự án ở giai đoạn nào các Sunner của chúng ta cũng đều tự tin và chiến thắng nhé!

 

#TTTH