"Không chốt việc lớn chiều thứ Sáu" là một luật bất thành văn ở nhiều đội kỹ thuật và vận hành: không đưa phiên bản phần mềm mới lên hệ thống thật, không đổi cấu hình mạng, không chuyển kho, không tung chiến dịch lớn vào cuối tuần làm việc. Lý do rất thực tế: nếu có trục trặc, nó sẽ lộ ra đúng lúc ít người nhất, mệt nhất và khó gọi nhau nhất. Luật này có người ủng hộ, có người phản biện, nhưng hiểu được lý lẽ của cả hai phía thì ai cũng sắp tuần làm việc tốt hơn.
Thói quen này đến từ đâu
Trong giới phần mềm, câu đùa "không triển khai vào thứ Sáu" đã thành gần như một khẩu hiệu. Một số nơi gọi thứ Sáu là "ngày chỉ đọc" (read-only Friday): vẫn làm việc, vẫn viết mã, kiểm thử, viết tài liệu, nhưng không thay đổi gì trên hệ thống đang phục vụ khách. Các đội quản trị mạng, hạ tầng, ngân hàng cũng có khái niệm "đóng băng thay đổi" (change freeze) vào những thời điểm nhạy cảm như cuối tuần, cuối năm, mùa cao điểm.
Không có văn bản hay ngày ra đời cụ thể nào cho luật này. Nó lớn lên từ kinh nghiệm chung: ai làm vận hành lâu năm đều có ít nhất một lần thức trắng tối thứ Sáu vì một thay đổi "nhỏ thôi" lúc bốn giờ chiều.
Vì sao chiều thứ Sáu là thời điểm rủi ro
| Yếu tố | Chiều thứ Sáu | Sáng thứ Ba, thứ Tư |
|---|---|---|
| Người có mặt để xử lý | Ít dần, nhiều người đã về hoặc đã nghỉ phép | Đủ người, đủ các bộ phận liên quan |
| Đối tác, nhà cung cấp | Nhiều nơi đã nghỉ, khó liên lạc tới thứ Hai | Liên lạc được trong giờ |
| Thời gian quan sát sau thay đổi | Vài giờ, rồi cả cuối tuần không ai nhìn | Cả ngày làm việc và những ngày tiếp theo |
| Độ tỉnh táo | Cuối tuần làm việc, dễ chủ quan | Đầu óc còn tươi |
| Áp lực "làm cho xong" | Cao, vì muốn khép việc trước khi nghỉ | Thấp hơn, còn thời gian lùi lại |
Điểm cuối cùng mới là cái bẫy chính. Chiều thứ Sáu, người ta có xu hướng muốn "đẩy cho xong" để cuối tuần nhẹ đầu. Chính tâm lý ấy làm giảm độ cẩn thận: bỏ qua một bước kiểm tra, không chờ thêm một người xem lại. Một lỗi nhỏ lúc đó có thể biến thành cả cuối tuần mất ngủ cho nhiều người.
Không chỉ phần mềm: những "việc lớn" ở ngành khác
Luật này sinh ra trong giới kỹ thuật, nhưng lý lẽ của nó áp dụng được rộng hơn nhiều. Bất cứ việc nào có thể gây hậu quả mà lại cần nhiều người cùng xử lý đều nên cân nhắc trước khi đặt vào chiều thứ Sáu:
- Gửi thông báo tới hàng loạt khách hàng. Nếu thông báo có sai sót, câu hỏi và phàn nàn sẽ đổ về trong lúc bộ phận chăm sóc khách đang thiếu người.
- Tung chương trình khuyến mãi, chiến dịch quảng bá. Lượng truy cập, đơn hàng tăng đột ngột mà kho, giao hàng, hệ thống thanh toán không có người theo dõi.
- Chuyển kho, đổi nhà cung cấp, đổi quy trình. Lỗi trong vận hành thực tế thường chỉ lộ ra khi hàng đã đi, khách đã chờ.
- Đổi cấu hình thiết bị, hệ thống điện, mạng trong toà nhà. Một sự cố mất mạng cuối tuần có thể không ai phát hiện cho tới sáng thứ Hai.
- Thông báo tin nặng nề cho nhân viên. Đây là chủ đề còn bàn cãi: có ý kiến cho rằng báo vào thứ Sáu để người ta có cuối tuần bình tâm, có ý kiến cho rằng như vậy là để người nhận ôm nỗi lo hai ngày mà không có ai để hỏi. Dù chọn thế nào, cần có người sẵn sàng trả lời câu hỏi ngay sau đó.
Phía phản biện: sợ thứ Sáu là dấu hiệu quy trình yếu
Không phải ai cũng đồng tình với luật này. Trong giới kỹ thuật có một phía lập luận khá thuyết phục: nếu đội của bạn sợ triển khai vào thứ Sáu, vấn đề không nằm ở thứ Sáu mà ở quy trình. Một quy trình tốt thì thay đổi nhỏ, kiểm thử tự động, theo dõi tốt và rút lại được trong vài phút. Khi đó ngày nào cũng an toàn như nhau.
Phía này còn chỉ ra một mặt trái: cấm triển khai thứ Sáu khiến các thay đổi dồn lại, đến thứ Hai tung một lúc nhiều thứ, rủi ro còn cao hơn. Tức là luật đặt ra để giảm rủi ro lại có thể sinh rủi ro theo kiểu khác.
Cách nhìn cân bằng: "không chốt việc lớn chiều thứ Sáu" là một biện pháp tạm hợp lý cho đội chưa có quy trình đủ chắc. Mục tiêu dài hạn vẫn là làm cho mỗi thay đổi đủ nhỏ và đủ an toàn để không cần né ngày nào cả.
Nếu buộc phải làm vào thứ Sáu
Có những việc không chờ được: bản vá lỗ hổng bảo mật, sửa một lỗi đang làm khách mất tiền, yêu cầu theo hạn của cơ quan chức năng. Khi đó, vài nguyên tắc giúp giảm rủi ro:
- Làm vào buổi sáng, không làm vào cuối chiều. Thêm vài giờ quan sát trong giờ làm là thêm rất nhiều cơ hội phát hiện lỗi.
- Có sẵn kế hoạch rút lui. Viết ra trước: nếu hỏng thì quay về trạng thái cũ thế nào, mất bao lâu, ai làm.
- Chỉ định người trực cụ thể. Không phải "ai rảnh thì xem", mà một hoặc hai người có tên, có số liên lạc, có quyền xử lý.
- Báo trước cho các bên. Bộ phận chăm sóc khách, đối tác liên quan nên biết có thay đổi để nhận diện vấn đề nếu có.
- Thu nhỏ phạm vi. Chỉ làm đúng phần cần gấp, phần còn lại để tuần sau.
- Có người thứ hai xem lại. Chiều thứ Sáu là lúc dễ tự tin quá mức; một cặp mắt khác đỡ được nhiều lỗi ngớ ngẩn.
Thứ Sáu thì làm gì cho đáng
Không chốt việc lớn không có nghĩa thứ Sáu là ngày bỏ đi. Nhiều đội dùng thứ Sáu cho những việc ít rủi ro nhưng hay bị đẩy lùi:
- Viết và cập nhật tài liệu, hướng dẫn nội bộ.
- Dọn dẹp, sắp xếp lại thư mục, danh sách việc tồn.
- Rà lỗi nhỏ, chuẩn bị cho các thay đổi sẽ làm đầu tuần sau.
- Học một công cụ mới, đọc tài liệu chuyên môn, chia sẻ kinh nghiệm trong nhóm.
- Bàn giao kỹ cho người trực cuối tuần.
Như vậy, thứ Sáu vẫn có ích, chỉ là theo kiểu chuẩn bị chứ không theo kiểu phát động.
Góc nhìn hôm nay: một luật nhỏ giữ cuối tuần cho nhiều người
Điều đáng học ở luật này không phải là né một ngày cụ thể, mà là ý thức về hệ quả: việc mình chốt có thể làm người khác mất cuối tuần. Người chốt việc lúc bốn giờ chiều có khi về nhà yên ổn, còn người trực hệ thống, người chăm sóc khách hàng, người giao hàng mới là người phải gánh.
Với người mới đi làm, thói quen đơn giản nhất là trước khi bấm gửi hay bấm chạy vào chiều thứ Sáu, tự hỏi một câu: nếu cái này hỏng, ai sẽ phải xử lý, và họ có đang ở đó không? Nếu câu trả lời là "không chắc", thường thì việc đó đợi được tới thứ Hai.
Câu hỏi thường gặp
Vì sao không nên triển khai phần mềm vào thứ Sáu?
Vì nếu có lỗi, nó thường lộ ra khi nhiều người đã nghỉ, đối tác khó liên lạc và cả cuối tuần ít người theo dõi hệ thống. Sửa lỗi lúc đó chậm hơn, tốn sức hơn và làm nhiều người mất ngày nghỉ.
Read-only Friday là gì?
Là cách gọi thứ Sáu như một "ngày chỉ đọc" ở nhiều đội kỹ thuật: vẫn làm việc bình thường nhưng không thay đổi gì trên hệ thống đang phục vụ khách. Thời gian đó dùng cho tài liệu, dọn dẹp, chuẩn bị cho tuần sau.
Change freeze là gì?
Change freeze là giai đoạn đóng băng thay đổi, khi đội kỹ thuật tạm ngừng mọi thay đổi không khẩn cấp lên hệ thống. Nó thường áp dụng vào cuối tuần, kỳ nghỉ lễ, mùa cao điểm bán hàng hoặc trước sự kiện quan trọng.
Có phải ai cũng đồng ý không triển khai vào thứ Sáu?
Không. Một số kỹ sư cho rằng sợ thứ Sáu là dấu hiệu quy trình yếu; nếu thay đổi nhỏ, kiểm thử tự động và rút lại được nhanh thì ngày nào cũng an toàn. Nhiều đội coi luật này là biện pháp tạm trong lúc cải thiện quy trình.
Nếu bắt buộc phải làm việc lớn vào thứ Sáu thì sao?
Nên làm vào buổi sáng, có kế hoạch rút lui viết sẵn, chỉ định người trực cụ thể và báo trước cho các bộ phận liên quan. Thu nhỏ phạm vi, chỉ làm phần thật sự gấp, phần còn lại để tuần sau.
