# Tự Động Hóa Đúng Cần Thiết
Mỗi lập trình viên đều phải đối mặt với cùng một câu hỏi hàng chục lần: “Tôi có nên tự động hóa công việc này không?” Câu trả lời hiếm khi rõ ràng. Tự động hóa quá ít, bạn sẽ chìm ngập trong công việc lặp đi lặp lại. Tự động hóa quá nhiều, bạn sẽ xây dựng những hệ thống phức tạp cho những vấn đề không tồn tại.
Trong các dự án mà tôi đã làm việc, tôi không thể tránh khỏi việc phải cân nhắc quyết định này, và câu trả lời luôn là “Có thể?”. Nhưng “có thể” không hữu ích khi bạn cần đưa ra lựa chọn.
Yếu tố nào nên được xem xét cho quyết định này? Ngưỡng nào giữa tự động hóa có giá trị và lãng phí thời gian? Những yếu tố vô hình nào chúng ta đang cố gắng tối ưu hóa?
## Phân Tích Giá Trị
Hãy thử định lượng điều này. Giá Trị Cung Cấp = Giá Trị của Công việc – Nỗ Lực Thực Hiện Công việc
Đơn giản đủ nếu tôi thấy một đồng xu trên mái nhà để xe bên cạnh, liệu có đáng xuống cầu thang, đi qua nhà để xe và nhặt đồng xu đó không? Có thể không, nhưng tồn tại một đống xu mà rắc rối chắc chắn đáng giá.
Vì vậy, đối với những công việc chúng ta sẽ không bao giờ làm lại, chúng ta nên tối ưu hóa nỗ lực để hoàn thành công việc và không gì khác. Hãy mở rộng phương trình của chúng ta để phù hợp với nỗ lực liên tục: Giá Trị Cung Cấp = Giá Trị của Công việc * Số Lần Lặp lại cho Công việc – Nỗ Lực Thực Hiện Công việc
Vì vậy, nếu công việc được thực hiện nhiều lần, hoặc có thể nỗ lực để tự động hóa công việc đặc biệt thấp, đó có thể là lợi tức tốt nhất cho thời gian của chúng ta.
## Chi Phí Ẩn
Bất cứ ai đã quyết định rửa tay một món đĩa thay vì cho vào máy rửa chén đều đã tính toán điều này trong tâm trí. Tuy nhiên, hãy dành một chút thời gian để nói về những hậu quả không rõ ràng của tự động hóa.
### Bảo Trì
Cho dù bạn đang tự thực hiện công việc hay tự động hóa, vẫn sẽ có một số việc cần bảo trì:
– Nếu bạn không có mặt ở văn phòng, làm thế nào để đảm bảo công việc vẫn được thực hiện và ai đó biết cách làm nó?
– Nếu bạn viết kịch bản (luồng làm việc, chương trình, quy trình), ai sẽ cập nhật nó khi công việc thay đổi và đảm bảo nó vẫn đang làm những gì nó supposed to?
Giá Trị Cung Cấp = Giá Trị của Công việc * Số Lần Lặp lại cho Công việc – Nỗ Lực Thực Hiện Công việc – Chi Phí Bảo Trì
### Tài Liệu
Nếu bạn đang làm công việc có bất kỳ tác động nào ngoài bản thân, bạn sẽ cần tài liệu hóa nó. Đây chính là ghi chú dán trên tủ lạnh để mua sữa. Cũng có chi phí thỉnh thoảng hết sữa khi chúng ta không bother để lại ghi chú. Hãy thêm điều đó vào:
Giá Trị Cung Cấp = Giá Trị của Công việc * Số Lần Lặp lại cho Công việc – Nỗ Lực Thực Hiện Công việc – Chi Phí Bảo Trì – Chi Phí Tài Liệu
### Sai Lầm
Bất kể bạn thực hiện công việc như thế nào, yếu tố con người sẽ thể hiện. Đó có thể là lỗi chính tả trong kịch bản của bạn hoặc để lại tiền tip 1.000 đô la thay vì 10,00 đô la. Điều gì sẽ xảy ra với đề xuất giá trị khi bạn phát hiện ra sai lầm của mình?
Giá Trị Cung Cấp = Giá Trị của Công việc * Số Lần Lặp lại cho Công việc – Nỗ Lực Thực Hiện Công việc – Chi Phí Bảo Trì – Chi Phí Tài Liệu – Chi Phí Sai Lầm
### Tác Dụng Dài Hạn
Cuộc sống là tổng hợp của tất cả lựa chọn của bạn
– Albert Camus
Những lựa chọn bạn đưa ra trên các vật phẩm nhỏ có hiệu ứng cộng dài hạn. Tập luyện hôm nay sẽ không khiến bạn mồ hôi hơn nhiều, nhưng tập luyện trong thập kỷ tới có thể thay đổi cuộc đời bạn.
Nguyên tắc tương tự áp dụng cho các quyết định tự động hóa. Mỗi lựa chọn tự động hóa hoặc thực hiện công việc thủ công xây dựng kỹ năng của bạn và định hình cách tiếp cận của bạn cho các quyết định trong tương lai. Thực hiện công việc thủ công có thể cải thiện sự hiểu biết của bạn về quá trình, trong khi tự động hóa nó có thể phát triển kỹ năng kỹ thuật của bạn. Chìa khóa là nhận ra rằng những tác động dài hạn này cộng dồn theo thời gian, có thể vượt qua tính toán chi phí-lợi tức ngay lập tức.
Hãy xem xét lập trình viên luôn tự động hóa quy trình triển khai so với người triển khai thủ công mỗi lần. Sau một năm, lập trình viên đầu tiên đã xây dựng kỹ năng tự động hóa mạnh mẽ và hệ thống triển khai đáng tin cậy, trong khi lập trình viên thứ hai đã có trực giác sâu sắc về những sắc thái triển khai. Cả hai kết quả đều có giá trị, nhưng chúng là những loại giá trị khác nhau ảnh hưởng đến các quyết định trong tương lai.
Giá Trị Dài Hạn = Giá Trị của Công việc * Số Lần Lặp lại cho Công việc – Nỗ Lực Thực Hiện Công việc – Chi Phí Bảo Trì – Chi Phí Tài Liệu – Chi Phí Sai Lầm ± Tác Dụng Dài Hạn
## Kết Luận
Tự động hóa là một công cụ, không phải là mục tiêu. Chúng ta không bao giờ nên tự động hóa điều gì chỉ vì sake của tự động hóa. Cuộc sống chuyên nghiệp của chúng ta đầy các nghi thức:
Một nghi thức là một chuỗi hành động hoặc hành vi được lặp lại, có cấu trúc thay đổi trạng thái nội tại hoặc ngoại tại của một cá nhân, nhóm hoặc môi trường, bất kể hiểu thức có ý thức, ngữ cảnh cảm xúc hoặc ý nghĩa tượng trưng.[^1]
Về cơ bản, thực hiện một hành động bất kể hiệu quả của nó phù hợp với bất kỳ mục đích cụ thể nào (ví dụ: Standups đầy trò chuyện nhàn rỗi, các cuộc họp không nêu hoặc hoàn thành mục tiêu, tạo ra các bảng điều khiển sẽ không bao giờ được sử dụng).
Tôi nghĩ tự động hóa có thể là một công cụ tự tài liệu hóa tuyệt vời, hoặc một phương tiện để chống lại lỗi con người, nhưng nó nên được sử dụng với mục đích.
## Tài Liệu Tham Khảo
[^1] https://en.wikipedia.org/wiki/Ritual
## Ứng Dụng Thực Tế
Khi áp dụng nguyên tắc “tự động hóa đủ cần thiết” vào môi trường làm việc thực tế, chúng ta có thể thấy nhiều lợi ích cụ thể. Trong môi trường phát triển phần mềm, các đội nhóm thường mắc sai lầm khi tự động hóa quá sớm hoặc quá muộn.
### Tự Động Hóa Quá Sớm
Tự động hóa quá sớm có thể dẫn đến:
1. Tốn kém tài nguyên khi xây dựng hệ thống tự động cho các tính năng chưa ổn định
2. Phức tạp hóa mã nguồn không cần thiết
3. Tạo ra các kịch bản bảo trì cho các quy trình sắp thay đổi
Ví dụ: Một đội ngũ tự động hóa quy trình tích hợp liên tục cho một module cốt lõi đang trong giai đoạn phát triển ban đầu có thể phải viết lại toàn bộ hệ thống tự động khi yêu cầu thay đổi.
### Tự Động Hóa Quá Muộn
Mặt khác, tự động hóa quá muộn có thể dẫn đến:
1. Lãng phí thời gian cho các công việc lặp đi lặp lại
2. Tăng nguy suất lỗi do thao tác thủ công
3. Giảm hiệu suất tổng thể của nhóm
Ví dụ: Một đội ngũ triển khai ứng dụng thủ công trong nhiều tháng trước khi quyết định tự động hóa quy trình đã mất hàng trăm giờ làm việc có thể được tiết kiệm.
### Chiến Lược Cân Bằng
Để đạt được sự cân bằng, các đội ngũ nên áp dụng chiến lược sau:
1. **Đánh giá tần suất thực hiện**: Theo dõi số lần một công việc được thực hiện. Nếu vượt quá 5-10 lần, nên xem xét tự động hóa.
2. **Đo lường thời gian tiết kiệm được**: Tính toán thời gian tiết kiệm được từ tự động hóa so với thời gian thực hiện thủ công.
3. **Đánh giá tính ổn định**: Nếu công việc có khả năng thay đổi cao, trì hoãn tự động hóa cho đến khi quy trình ổn định.
4. **Xem xét kỹ năng nhóm**: Đánh giá xem nhóm có đủ kỹ năng để duy trì hệ thống tự động hóa.
### Trường Hợp Thành Công
Một ví dụ điển hình về tự động hóa đúng mức là công ty khởi nghiệp X. Ban đầu, đội ngũ triển khai thủ code thủ công trong môi trường staging. Sau 6 tháng, khi quy trình triển khai trở nên ổn định và tốn trung bình 2 giờ/lần, họ quyết định tự động hóa. Kết quả là hệ thống tự động hóa được xây dựng trong 1 ngày làm việc và tiết kiệm được khoảng 10 giờ/tuần cho đội ngũ.
Ngược lại, công ty Y đã tự động hóa toàn bộ quy trình CI/CD trong giai đoạn đầu phát sản phẩm. Khi yêu cầu thay đổi, họ đã phải dành 2 tuần để viết lại hệ thống tự động hóa, gây lãng phí nguồn lực đáng kể.
## Kết Luận Cuối Cùng
Tự động hóa đủ cần thiết không phải là một quy tắc cứng nhắc mà là một triết lý cân bằng. Nó đòi hỏi chúng ta phải đánh giá kỹ lưỡng từng tình huống, cân nhắc giữa lợi ích trước mắt và tác động lâu dài. Khi áp dụng đúng cách, tự động hóa có thể giải phóng thời gian cho các công việc sáng tạo và giá trị cao hơn, đồng thời giảm thiểu sai sót do thao tác thủ công.
Hãy nhớ rằng, tự động hóa là một công cụ mạnh mẽ, nhưng như bất kỳ công cụ nào, nó cần được sử dụng một cách thông minh và có mục đích. Nguyên tắc vàng là: tự động hóa khi nó tạo ra giá trị thực sự, không phải vì nó có vẻ “ngầu” hoặc “hiện đại”.
