​

Personal Learning Log / Mistake Log

​

Biến Lỗi Lặp Thành Tài Sản Học Tập

Học nhanh không chỉ đến từ việc làm nhiều bài hơn. Nó đến từ việc nhận ra mình hay sai ở đâu, vì sao sai, và làm sao để lần sau không lặp lại cùng một lỗi. Trong chương trình QC nội bộ, rất nhiều feedback có giá trị bị “chết” sau một lần sửa bài vì học viên không ghi lại, không dùng lại, và không biến nó thành nguyên tắc cá nhân. Learning Log và Mistake Log là cách để giữ những bài học đó sống đủ lâu để giúp bài sau tốt hơn.

Đừng để mỗi feedback chỉ sống trong một lần sửa bài. Hãy biến nó thành tài sản giúp các tuần sau đi nhanh và chắc hơn.

​

Learning Log Là Gì, Mistake Log Là Gì

Hai loại log này liên quan chặt với nhau, nhưng không hoàn toàn giống nhau.

​

Learning Log

Learning Log là nơi bạn ghi lại:

• điều mình đã hiểu rõ hơn;
• insight quan trọng;
• pattern bắt đầu nhận ra;
• nguyên tắc muốn mang sang tuần sau;
• điểm còn mơ hồ cần quay lại.

Nó giúp bạn không học từng tuần như những mảnh rời nhau.

​

Mistake Log

Mistake Log là nơi bạn ghi lại:

• lỗi lặp;
• feedback mentor đáng nhớ;
• lỗi gốc đằng sau biểu hiện bề mặt;
• cách sửa;
• dấu hiệu để nhận ra lần sau;
• cách tránh lặp lại.

Nó giúp bạn không sửa cùng một lỗi hết tuần này sang tuần khác. Bạn có thể dùng riêng hai log, hoặc gộp thành một hệ thống cá nhân. Điều quan trọng không phải là đặt tên thế nào, mà là log đó có giúp bạn học thông minh hơn không.

​

Vì Sao Học Viên QC Nên Có Log Cá Nhân

Học viên QC rất dễ rơi vào cảm giác “tuần nào cũng bận” nhưng vẫn không chắc mình tiến bộ thật ở đâu. Một log cá nhân tốt giúp giải quyết đúng vấn đề này.

​

1. Tránh lặp cùng một lỗi qua nhiều tuần

Nhiều lỗi không khó, nhưng rất dai:

• expected result mơ hồ;
• case trùng logic;
• bug report thiếu precondition;
• summary có số liệu nhưng không có risk statement.

Nếu bạn không ghi lại, khả năng cao mentor sẽ phải nhắc lại y nguyên ở bài sau.

​

2. Giúp nhớ feedback quan trọng

Feedback tốt thường không chỉ sửa một dòng. Nó chỉ ra một pattern yếu trong cách làm của bạn. Log cá nhân là nơi để giữ lại những feedback như vậy, thay vì để chúng trôi mất sau lần nộp kế tiếp.

​

3. Giúp chuẩn bị tốt hơn trước khi nộp bài

Khi có log lỗi lặp, bạn có thể đọc lại trước khi:

• bắt đầu bài mới;
• tự review;
• gửi mentor review.

Điều này khiến self-review có chiều sâu hơn rất nhiều.

​

4. Giúp thấy mình tiến bộ ở đâu, chậm ở đâu

Không phải tuần nào cũng cần học nhanh hơn. Có những giai đoạn bạn cần học rõ hơn, sâu hơn, ít lặp lỗi hơn. Log cá nhân giúp bạn nhìn thấy điều đó thay vì chỉ đếm số file đã nộp.

​

5. Giúp hỏi mentor tốt hơn

Khi bạn biết pattern yếu của mình là gì, câu hỏi gửi mentor sẽ cụ thể hơn:

• “Em hay viết expected result mơ hồ.”
• “Em hay thiếu permission cases.”
• “Em đang lặp lỗi assumption không explicit.”

Đó là dấu hiệu của self-awareness nghề nghiệp.

​

Nên Ghi Những Gì Vào Log

Không cần ghi mọi thứ. Hãy ghi những thứ có thể dùng lại.

​

1. Lỗi lặp

Những lỗi xuất hiện hơn một lần hoặc có nguy cơ lặp cao. Đây là phần cốt lõi của Mistake Log.

​

2. Feedback mentor đáng nhớ

Không phải comment nào cũng cần lưu, nhưng các comment chạm vào cách nghĩ hoặc pattern làm việc thì nên giữ lại.

​

3. Assumption mình từng hiểu sai

Ví dụ:

• hiểu sai business rule là validation rule;
• hiểu sai scope của workflow;
• tưởng 200 OK là đủ để pass API test.

Đây là những lỗi rất đáng log vì chúng thường quay lại ở dạng khác.

​

4. Checklist cá nhân cần nhớ

Những điều bạn luôn cần tự nhắc trước khi nộp:

• expected result phải đo được;
• bug report phải có precondition;
• matrix phải có trường hợp bị cấm;
• summary phải có risk statement.

​

5. Ví dụ tốt / ví dụ yếu

Một ví dụ mạnh thường dễ nhớ hơn một đoạn lý thuyết dài. Ghi lại một ví dụ tốt và một ví dụ yếu giúp bạn tự calibrate nhanh hơn.

​

6. Pattern mình hay bỏ sót

Ví dụ:

• quên edge case;
• quên state bị cấm;
• quên notify/history;
• quên nói rõ out-of-scope.

​

7. Bài học từ từng tuần

Mỗi tuần nên có ít nhất một bài học mang sang tuần sau. Nếu không, bạn rất dễ học rời rạc.

​

8. Điều mình vẫn còn chưa chắc

Log không chỉ để ghi “đã biết”. Nó còn để ghi “chưa chắc” để bạn chủ động học tiếp, hỏi mentor tốt hơn và không tự tin sai.

​

Format Log Gợi Ý

Bạn không cần tool phức tạp. Sheets, Notion hoặc Markdown table đều đủ dùng nếu cấu trúc rõ.

​

Format A - Mistake Log

​

Format B - Learning Log

​

Cách Ghi Log Mà Không Biến Nó Thành Gánh Nặng

Log tốt không phải log dài. Log tốt là log đủ ngắn để bạn duy trì, và đủ rõ để bạn dùng lại. Nguyên tắc nên giữ:

• không ghi mọi thứ;
• không chép nguyên feedback rồi để đó;
• không viết dài chỉ để “trông có vẻ học nhiều”;
• chỉ giữ thứ giúp bài sau tốt hơn.

Ưu tiên ghi:

• lỗi lặp;
• insight mạnh;
• checklist cá nhân;
• assumption từng hiểu sai;
• điều cần nhớ cho bài tiếp theo.

Thời điểm tốt nhất để cập nhật log:

• ngay sau khi nhận feedback;
• ngay sau khi sửa xong một bài lớn;
• cuối tuần, trong 10 phút tổng kết.

​

Mỗi tuần chỉ cần 10 phút cập nhật log có thể tạo khác biệt gì

10 phút đủ để bạn:

• chốt 2 lỗi lặp quan trọng nhất;
• ghi 1 insight muốn mang sang tuần sau;
• thêm 1 checklist cá nhân trước lần nộp kế tiếp.

Nếu làm đều, sau 4-5 tuần bạn sẽ có một hệ thống học riêng rất mạnh.

​

Đừng ghi lại mọi thứ, hãy ghi thứ sẽ giúp bài sau tốt hơn

Nếu một entry không giúp bạn:

• tránh lỗi cũ,
• tự review nhanh hơn,
• hoặc hỏi mentor cụ thể hơn,

thì có thể nó chưa đáng giữ.

​

Cách Biến Feedback Thành Entry Trong Log

Đừng copy feedback nguyên văn vào log rồi để đó. Hãy biến nó thành quy tắc cá nhân.

​

Quy trình gợi ý

1. Đọc feedback.
2. Gom nhóm feedback.
3. Xác định lỗi gốc.
4. Viết lại bằng ngôn ngữ của mình.
5. Thêm dấu hiệu nhận biết.
6. Thêm cách tránh ở bài sau.

Ví dụ:

• Feedback gốc: Expected Result còn mơ hồ, chưa nói rõ hành vi chặn submit.
• Entry log tốt hơn:
  • Lỗi: Expected result chỉ tả UI, không tả hành vi chặn/cho phép.
  • Dấu hiệu: Nếu expected result không nói rõ submit bị chặn hay được phép, case còn yếu.
  • Cách tránh: Trước khi nộp, rà riêng cột Expected Result và check xem đã có state + message + action outcome chưa.

​

“Lỗi gốc” quan trọng hơn “biểu hiện lỗi” vì sao

Biểu hiện lỗi là thứ mentor comment thấy ngay. Lỗi gốc là thứ khiến lỗi đó lặp lại. Ví dụ:

• Biểu hiện: Case 07 expected result mơ hồ
• Lỗi gốc: Em chưa có công thức viết expected result theo thứ có thể verify

Nếu chỉ sửa biểu hiện, bạn sẽ lại lặp lỗi ở case 08, 09, 10. Nếu sửa lỗi gốc, cả file sẽ tốt lên.

​

Cách Dùng Log Trước Khi Làm Bài Mới

Đây là phần quan trọng nhất. Log chỉ có giá trị nếu bạn dùng nó.

​

Trước khi bắt đầu bài mới

Đọc lại 3-5 lỗi mình hay lặp nhất. Mục tiêu không phải để tự dọa mình, mà để tránh bước vào bài mới với quán tính cũ.

​

Trước khi nộp bài

Đối chiếu output với log lỗi cá nhân:

• mình có đang lặp lỗi expected result mơ hồ không;
• có đang bỏ sót state bị cấm không;
• summary đã có risk statement chưa;
• assumption có đang bị ngầm không.

​

Khi mentor review

Bạn có thể chủ động nói:

Em đã tự check lại các lỗi cũ A, B, C trước khi gửi bài này. Em muốn mentor tập trung xem giúp em phần D vì em chưa chắc.

Đó là dấu hiệu của một learner biết dùng log như công cụ sống.

​

Một log tốt là log có thể dùng trước khi nộp bài

Nếu log của bạn chỉ nằm đó để “đã có ghi chép”, nó chưa đủ giá trị. Một log mạnh là log mở ra trước lúc:

• bắt đầu bài;
• tự review;
• gửi mentor review;
• tổng kết cuối tuần.

​

Dấu Hiệu Log Của Bạn Đang Có Ích Vs Vô Ích

​

Dấu Hiệu Log Đang Có Ích

• Bạn ít lặp lại lỗi cũ hơn.
• Bạn biết rõ mình yếu chỗ nào.
• Bạn hỏi mentor cụ thể hơn.
• Bạn tự review tốt hơn.
• Output các tuần sau rõ ràng hơn.

​

Dấu Hiệu Log Đang Vô Ích

• Bạn ghi quá nhiều nhưng không bao giờ xem lại.
• Log toàn câu chung chung.
• Không có mục cách tránh lần sau.
• Lỗi cũ vẫn lặp lại y nguyên.
• Log không gắn với hành động cụ thể.

​

Ví Dụ Entry Tốt Vs Entry Yếu

​

Ví dụ 1 - Test Case

• Yếu: Em cần viết test case rõ hơn.
• Tốt: Week 2 / Test case: Expected Result của em thường viết kiểu chung chung như “hệ thống hiển thị đúng”. Mentor góp ý phải mô tả rõ thông báo, trạng thái bản ghi và hành vi chặn/cho phép. Lần sau, trước khi nộp test case, em sẽ rà riêng cột Expected Result để xem có đang dùng từ mơ hồ không.

​

Ví dụ 2 - Bug Report

• Yếu: Bug report của em chưa ổn.
• Tốt: Week 3 / Bug report: Em hay ghi actual result rõ nhưng quên precondition, nên dev không reproduce được. Dấu hiệu nhận biết là bug chỉ xảy ra trong một state đặc biệt nhưng em không ghi state đó. Lần sau, nếu bug không thể xảy ra ở mọi lúc, em phải thêm precondition riêng trước steps.

​

Ví dụ 3 - Workflow / Permission Matrix

• Yếu: Matrix của em thiếu role.
• Tốt: Week 6 / Matrix: Em thường map được action hợp lệ nhưng bỏ quên action bị cấm hoặc thiếu role trung gian như Manager. Lỗi gốc là em nhìn theo luồng đúng, chưa nhìn theo hành động bị chặn. Lần sau, trước khi nộp matrix, em sẽ luôn hỏi: có role nào không được làm gì ở state này chưa?

​

Ví dụ 4 - Summary Report

• Yếu: Summary cần đầy đủ hơn.
• Tốt: Week 7 / Summary: Báo cáo của em có số liệu pass/fail nhưng thiếu risk statement, nên người đọc không biết có nên release không. Dấu hiệu nhận biết là report chỉ có defect count và không nói hậu quả nếu release. Lần sau, em sẽ ép bản thân viết ít nhất 2 Key Risks trước khi chốt report.

​

Cách đặt tên lỗi để dễ nhớ

Thay vì ghi:

• Lỗi viết chưa rõ

hãy đặt tên lỗi sao cho vừa ngắn vừa đủ gợi nhớ:

• Expected result chung chung
• Bug thiếu precondition
• Matrix thiếu case bị cấm
• Summary thiếu risk
• Scenario trùng logic

Tên lỗi càng rõ, bạn càng dễ dùng lại trước khi nộp bài.

​

Mini Checklist Để Cập Nhật Log Mỗi Tuần

• Tuần này tôi bị góp ý lỗi gì lặp lại?
• Tuần này tôi hiểu rõ hơn điều gì?
• Có nguyên tắc nào tôi muốn mang sang tuần sau?
• Tôi đang còn mơ hồ ở điểm nào?
• Tôi sẽ kiểm gì ở bài sau để tránh lặp lỗi?

​

Kết Hợp Log Với Self-Review Và Mentor Feedback

Ba thứ này nên nối với nhau thành một vòng lặp:

1. Làm bài
2. Tự review
3. Nhận feedback
4. Cập nhật log
5. Dùng log cho bài sau

Đây là vòng lặp cải thiện. Người tiến bộ nhanh thường không phải người ít sai hơn ngay từ đầu, mà là người có vòng lặp học tập rõ hơn.

• Self-review giúp bắt lỗi cơ bản trước khi nộp.
• Mentor feedback giúp nhìn ra lỗi sâu hơn hoặc lỗi mù điểm.
• Learning Log / Mistake Log giúp giữ lại bài học để lần sau không bắt đầu lại từ đầu.

Nếu bạn chưa có quy trình tự soi bài trước khi nộp, hãy xem Cách Tự Review Trước Khi Nộp. Nếu bạn muốn cải thiện chất lượng câu hỏi gửi mentor và cách xử lý feedback, xem Cách Hỏi Mentor & Nhận Feedback.

​

Kết Thúc Trang

Learning Log không phải để viết đẹp. Mistake Log cũng không phải để tự trách mình. Cả hai là công cụ giúp bạn học có hệ thống và biến trải nghiệm từng tuần thành một đường cong tiến bộ nhìn thấy được. Càng ghi đúng, xem lại đúng và áp dụng đúng, bạn càng học nhanh hơn, hỏi mentor tốt hơn và ít lặp lỗi cũ hơn. Nếu muốn dùng log này cho lần nộp tiếp theo, xem thêm Cách Tự Review Bài Trước Khi Nộp và Cách Hỏi Mentor & Nhận Feedback Hiệu Quả.