- Một tổ chức kỹ sư khoảng 45 người mỗi quý dành ra một tuần để tạm dừng roadmap, thiết kế và họp, vận hành “tuần Fixit” nhằm tập trung giải quyết các lỗi nhỏ và vấn đề ảnh hưởng tới năng suất
- Trong đợt Fixit này, 189 lỗi đã được sửa, có 40 người tham gia; trung vị mỗi người đóng 4 lỗi, cao nhất là 12 lỗi
- Các cơ chế như quy tắc giải quyết trong vòng 2 ngày, hệ thống điểm và bảng xếp hạng, thưởng áo thun giúp tạo động lực và nâng cao tinh thần đội ngũ
- Việc sử dụng công cụ AI giúp tăng tốc độ khám phá mã nguồn và đề xuất chỉnh sửa, giảm gánh nặng chuyển đổi ngữ cảnh
- Fixit được đánh giá là góp phần nâng cao độ hoàn thiện của sản phẩm và tăng cường sự gắn kết trong nhóm, đồng thời khơi lại niềm vui của việc giải quyết những vấn đề nhỏ
Khái niệm và cách vận hành của Fixit
- Fixit là tuần sửa lỗi tập trung, diễn ra một tuần mỗi quý, trong đó toàn bộ công việc roadmap, thiết kế và các cuộc họp thường lệ đều tạm dừng
- Các kỹ sư tập trung xử lý những lỗi nhỏ hoặc yếu tố làm giảm năng suất vốn gây bất tiện cho người dùng và nhà phát triển
- Ví dụ: thông báo lỗi mơ hồ tồn tại suốt 2 năm, glitch xuất hiện khi vừa cuộn vừa zoom, độ trễ CI do test chạy chậm
- Có hai quy tắc
- Không lỗi nào được mất quá 2 ngày để xử lý
- Công việc phải tập trung vào cải thiện cho người dùng cuối hoặc nâng cao năng suất của nhà phát triển
- Hệ thống điểm và bảng xếp hạng được dùng để trực quan hóa mức độ tham gia; đồng thời có thưởng áo thun cho nhiều hạng mục như “sửa lỗi đầu tiên”, “sửa lỗi khó chịu nhất”
Kết quả của Fixit
- Kết quả của đợt Fixit này
- Sửa 189 lỗi, 40 người tham gia, trung vị 4 lỗi/người, cao nhất 12 lỗi
- Một số ví dụ tiêu biểu
Tác động của Fixit
-
Ở góc độ sản phẩm: sự chỉn chu và độ hoàn thiện
- Một sản phẩm tốt được đặc trưng bởi sự chú ý tới chi tiết và tính nhất quán
- Fixit là cơ hội để loại bỏ những bất tiện nhỏ mà người dùng có thể không trực tiếp nhận ra, qua đó nâng chất lượng sản phẩm lên thêm một bậc
-
Ở góc độ cá nhân: cảm giác thỏa mãn khi tập trung vào thực thi
- Đây là trải nghiệm lấy lại cảm giác thành tựu tức thì kiểu “phát hiện vấn đề → sửa → triển khai” từng có ở giai đoạn đầu sự nghiệp
- Trong thời gian Fixit, trọng tâm là “cải thiện như thế nào” hơn là “xây cái gì”, nhờ đó thành tựu được tích lũy theo chu kỳ ngắn
-
Ở góc độ đội ngũ: tăng tinh thần và hợp tác
- 40 người ở hai múi giờ cùng sửa lỗi đồng thời, tạo ra mức năng lượng tăng lên trên toàn tổ chức
- Trong phòng chat diễn ra nhiều tương tác sôi nổi như chia sẻ bản sửa theo thời gian thực, đăng ảnh chụp màn hình, trình diễn demo
- Mỗi sáng, nhóm chia sẻ số lỗi đã sửa, số người tham gia và thứ hạng trên bảng xếp hạng để tăng thêm động lực
Điều kiện để vận hành Fixit thành công
-
Chuẩn bị trước
- Trong năm, các lỗi được gắn nhãn “good fixit candidate”; vào tuần trước Fixit, chúng được phân loại thành nhỏ, vừa, lớn (0,5 / 1 / 2 ngày)
- Tùy theo kích thước, mỗi lỗi được gán 1 / 2 / 4 điểm và lập danh sách lỗi ưu tiên
- Quá trình chuẩn bị này là yếu tố then chốt để tránh hỗn loạn trong ngày đầu tiên
-
Quy tắc giới hạn 2 ngày
- Trước đây từng có trường hợp một lỗi phức tạp hơn dự kiến và tiêu tốn trọn cả tuần Fixit
- Sau đó, nhóm áp dụng nguyên tắc quá 2 ngày thì dừng lại và đưa về backlog, nhằm duy trì cảm giác thành tựu liên tục
-
Quy mô người tham gia
- Ở giai đoạn đầu với 7 người, dù vẫn có kết quả nhưng chưa tạo được sự đồng cảm trên toàn tổ chức
- Khi đạt khoảng 40 người, nhóm hình thành khối lượng tới hạn, tối đa hóa năng lượng tập thể và độ nhập tâm
-
Gamification
- Điểm số được thiết kế ưu tiên niềm vui hơn độ chính xác tuyệt đối (1/2/4 điểm)
- Ghi nhận thành quả trên diện rộng: từ bản sửa đầu tiên đến lỗi khó chịu nhất
- Tách biệt với đánh giá hiệu suất, để giữ động lực tham gia một cách thuần túy
- Nhờ chuẩn mực xã hội và quy mô nhóm, gần như không có trường hợp lạm dụng hệ thống
Vai trò của công cụ AI
- AI giúp giảm gánh nặng chuyển đổi ngữ cảnh, vốn là thách thức cốt lõi của Fixit
- Nó nhanh chóng tìm kiếm và tóm tắt các tệp liên quan, từ đó giảm tải nhận thức
- Ví dụ
- Kết quả là tăng tốc độ chạm tới điểm khởi đầu, và trong một số trường hợp có thể sửa ngay lập tức
Phê bình về Fixit và cách phản hồi
-
“Chẳng phải điều đó có nghĩa là bình thường các bạn phớt lờ bug sao?”
- Ở một mức độ nào đó thì đúng, nhưng Fixit giúp bù đắp thực tế rằng những lỗi nhỏ gây khó chịu (papercut bugs) thường bị đẩy xuống thấp trong ưu tiên
- Fixit là cách dành ra một khoảng thời gian rõ ràng để xử lý những vấn đề “nhỏ nhưng quan trọng”
-
“Dừng công việc roadmap có phải là lãng phí không?”
- Việc dành 1 tuần của 40 người là khoản đầu tư lớn, nhưng được bù lại bằng độ hoàn thiện của sản phẩm tăng lên và mức hài lòng của người dùng cao hơn
- Những cải thiện về tốc độ test, độ rõ ràng của thông báo lỗi, rút ngắn quy trình làm việc tạo ra hiệu quả năng suất kéo dài trong dài hạn
-
“Cách này chỉ phù hợp với công ty lớn thôi sao?”
- Các nhóm nhỏ vẫn có thể biến thể thành “Fixit Friday” hoặc mini Fixit 2 ngày
- Cốt lõi là dành ra thời gian tập trung, được bảo vệ và cùng nhau thực hiện hoạt động cải thiện
Giá trị cốt lõi của Fixit
- Mục tiêu chính thức là nâng cao chất lượng sản phẩm và năng suất của lập trình viên
- Lý do không chính thức là “niềm vui của việc sửa chữa một thứ gì đó”
- Nó được xem là yếu tố thiết yếu để khơi lại cảm giác thỏa mãn của thời kỳ đơn giản hơn, đồng thời duy trì văn hóa làm sản phẩm một cách chỉn chu
2 bình luận
Điều này làm tôi nhớ đến văn hóa pit stop của Baemin. Tôi nghe nói bây giờ nó không còn nữa.
Ý kiến trên Hacker News
Tôi thích ý tưởng này, nhưng câu “một bug không nên mất quá 2 ngày” nghe khá lạ
Trên thực tế, trước khi sửa bug thì gần như không thể dự đoán nó sẽ mất bao lâu
Tuy vậy, nếu không cần một đợt refactor lớn thì tôi nghĩ hiếm khi nó mất quá một ngày
Tôi thường xử lý bug theo mức độ nghiêm trọng hoặc độ ưu tiên. Bug càng nghiêm trọng thì đôi khi lại càng dễ tìm
Khi tìm ra nguyên nhân rồi thì việc sửa thường rất nhanh
Chúng tôi phân tích log suốt nhiều năm mà không tìm ra nguyên nhân, rồi cuối cùng phát hiện nó có thể được tái hiện 100% với một cơ sở dữ liệu ở trạng thái cụ thể và một tổ hợp commit nhất định
Chúng tôi ký NDA, tạo một binary tái hiện tối thiểu và tự động hóa bằng script PowerShell, rồi một tháng sau Microsoft đã sửa xong
Nội bộ thì nó trông giống buffer overflow, nhưng tôi không chắc
Nếu tôi dành cả tuần chỉ để sửa bug và không cộng thêm được story point nào trên Jira, sẽ có nhiều quản lý kéo tới hỏi tại sao tiến độ lại chậm
Thế nên bài học tôi rút ra là tốt hơn hết hãy né các bug khó, và sớm từ bỏ những việc không ra điểm
Bạn không biết vấn đề nằm ở code, compiler hay phần cứng, và những bug phức hợp do nhiều yếu tố rối vào nhau thậm chí còn không thể tái hiện riêng lẻ
Trong trường hợp như vậy, các giải pháp chắp vá nhanh tích tụ dần, rồi về sau một lần sửa bug cho ra hồn sẽ kéo theo đợt làm lại quy mô lớn
Ngoài ra, trong môi trường thiếu tin cậy, đôi khi ngay cả bug nhỏ cũng không thể sửa ngay vì quy trình Jira
Khi làm ở Meta, chúng tôi có Fix-it Week mỗi quý
Ban đầu tôi nghĩ ban lãnh đạo thật sự quan tâm đến chất lượng, nhưng thực tế đó lại là thời gian được cấp phép để tích nợ kỹ thuật
Chúng tôi cố sửa bug trong một tuần, nhưng vì nợ kỹ thuật đã chất đống nên rốt cuộc gần như không giải quyết được gì
Nếu không, code mới sẽ chồng lên bug và tạo thành một nền móng bất ổn
Video bài nói chuyện của John Romero cũng nhấn mạnh triết lý đó
Các lập trình viên xử lý những TODO để lại từ trước và tăng LOC, thậm chí có người còn cố tình viết code sai để sau này “sửa” nhằm tăng số lượng diff như một mẹo lách
Tức là khoảng thời gian để xử lý những vấn đề không khẩn cấp nhưng gây khó chịu
Quan trọng hơn là ban lãnh đạo giải thích thẳng thắn ưu tiên kinh doanh, và cho thấy rõ tác động của bug tới người dùng
Tôi từng trải qua vòng luẩn quẩn trong lúc phát triển tính năng, nơi ứng phó khẩn cấp và đổi ưu tiên lặp đi lặp lại
Cuối cùng hệ thống trở thành một mớ đầy workaround, còn cả khách hàng lẫn lập trình viên đều không hài lòng
Trong tình huống như vậy, tôi cảm thấy đáng lẽ nên dừng lại ngay từ đầu để sửa bug tận gốc
Giao tiếp đứt gãy, lãnh đạo cuống cuồng như gà mắc tóc và chỉ biết ra lệnh
Lập trình viên bị biến thành lính cứu hỏa cho mọi vấn đề, và cuối cùng cách giải quyết duy nhất là rời đi
Tiến độ càng chậm thì lãnh đạo càng hoảng loạn, tái sắp xếp dự án một cách bừa bãi và khiến sự hỗn loạn cùng văn hóa độc hại ngày càng nặng hơn
Tôi luôn làm việc với triết lý “sửa bug là ưu tiên số một”
Nếu tính năng hiện có chưa hoạt động đúng thì tôi không xây thêm tính năng mới
Làm vậy có thể duy trì một codebase không bug và tăng năng suất của cả nhóm
Đặc biệt ở frontend, vì vấn đề môi trường rất đa dạng nên trạng thái hoàn toàn không bug gần như là bất khả thi
Ngoài ra, định nghĩa “bug” cũng mơ hồ, nên đôi khi tính năng mà quản lý muốn lại bị phân loại thành bug
Ví dụ, lỗi ở một trang API hầu như không ai dùng có thể kém quan trọng hơn một tính năng mới
Phần lớn là vấn đề nhỏ, nên ban lãnh đạo sẽ thích tính năng mới hơn
Tôi vận hành một sản phẩm SaaS nhỏ và giữ nguyên nguyên tắc “ưu tiên sửa bug”
Tôi luôn giải quyết bug do khách hàng báo trước khi làm tính năng mới
Làm như vậy thì số bug mới phát hiện sẽ dần ít đi và việc sửa cũng dễ hơn
Xét về mặt kinh doanh thì có thể không hiệu quả, nhưng về chất lượng và niềm tin của khách hàng thì đây là chiến lược tốt nhất
Khách hàng thực sự rất thích khi bug họ báo được sửa chỉ sau vài giờ
Những cơ chế như Fix-it Week ngược lại còn khuyến khích trì hoãn sửa bug
Nó tạo ra cái cớ “để sau đến Fix-it Week hẵng làm”
Thay vào đó, tôi nghĩ nên đưa thời gian bảo trì vào kế hoạch quý hoặc sprint một cách rõ ràng
Làm vậy thì lập trình viên có cơ sở để sửa bug ngay, và văn hóa cải tiến liên tục cũng sẽ bén rễ
Tốt hơn hết là vận hành Fix-it Week giống một mini hackathon có cả cải tiến nhỏ hoặc POC
Công ty cũ của tôi luôn lặp lại cùng một chu kỳ
Mẫu này là dấu hiệu cho thấy văn hóa tổ chức có vấn đề. Nếu không dành thời gian sửa bug trong trạng thái bình thường thì sẽ chẳng bao giờ thay đổi được
Nó làm tôi nhớ đến Joel Test mà Joel Spolsky từng đưa ra
Trong đó câu hỏi thứ năm là “Bạn có sửa bug trước khi viết code mới không?”
Sau 25 năm, đây vẫn là một tiêu chí còn nguyên giá trị
Liên kết bài gốc
Tôi thuộc phe cho rằng đừng gán điểm số hay ước lượng kích thước cho bug
Nếu nhất định phải có điểm, cứ để tất cả là 2 thì trung bình cũng sẽ đúng
Việc sửa bug nên theo cách làm Kanban, xử lý theo thứ tự quan trọng và hoàn thành trong thời gian cho phép là được
Tôi là tác giả. Tôi rất vui vì đã có một cuộc thảo luận sôi nổi
Nó không phải biện pháp thay thế cho vệ sinh kỹ thuật hay giải quyết các vấn đề lớn