​

Cách Tự Học

​

Học Đúng Cách Để Đi Hết 8 Tuần

Trang này dành cho học viên muốn học chắc, nộp bài có chất lượng và không bị cuốn vào kiểu học thuộc để đối phó. Trong chương trình QC hệ thống, bạn không được đo bằng việc nhớ bao nhiêu định nghĩa, mà bằng việc tạo ra được artifact có thể review, có thể dùng, và cải thiện được sau feedback. Nếu học đúng nhịp ngay từ đầu, bạn sẽ thấy từng tuần nối logic với nhau. Nếu học sai cách, bạn sẽ rất dễ có nhiều file nhưng vẫn không chứng minh được năng lực thật.

Nguyên tắc cốt lõi: luôn học để tạo ra output usable, không học để lấp đầy template.

​

Cách Học Chương Trình Này

Chương trình này không nên được học theo kiểu đọc hết lý thuyết rồi mới làm bài. Cách học đúng là đọc page tuần, hiểu tuần đó đang rèn năng lực gì, sau đó đi vào từng ngày và tạo output ngay. Mỗi tuần, bạn nên bám đúng thứ tự ở Lộ Trình 8 Tuần:

1. Đọc Mục Tiêu để biết tuần này cần đạt năng lực gì.
2. Đọc Kế Hoạch Theo Ngày để biết hôm nay cần học và nộp gì.
3. Đọc Deliverables Cần Nộp để hình dung đầu ra cuối tuần.
4. Đọc KPI & Focus để hiểu mentor sẽ soi điểm nào.
5. Đọc Mapping Review để biết nên dùng template nào và tự soi bằng tài liệu nào.

Nếu cần nhìn toàn bộ cấu trúc chương trình, naming và các mốc nộp bài, xem thêm tại Cách Dùng Chương Trình.

​

Quy Trình Tự Học Mỗi Ngày

Đừng để mỗi ngày học thành một chuỗi đọc tài liệu rời rạc. Hãy dùng một vòng lặp cố định.

​

Bước 1. Chốt mục tiêu của ngày

Trước khi làm, hãy tự trả lời:

• Hôm nay mình đang rèn năng lực gì?
• Output hôm nay là gì?
• Mentor sẽ review output này theo tiêu chí nào?

Nếu chưa trả lời được ba câu này, bạn đang học mơ hồ.

​

Bước 2. Làm nháp trước khi quay lại lý thuyết

Với các ngày có bài thực hành, hãy thử tự làm trước ở mức nháp. Ví dụ:

• Tuần 2: thử viết scenario trước khi đọc lại test design notes.
• Tuần 3: thử log bug nháp trước khi xem lại bug template.
• Tuần 5: thử viết query verify record trước khi đi ôn lại cú pháp.

Cách này giúp bạn phát hiện đúng chỗ mình chưa hiểu, thay vì tưởng là đã hiểu vì vừa đọc xong.

​

Bước 3. Tạo output đầu tiên thật sớm

Đừng chờ “hiểu hết” mới bắt đầu file nộp. Hãy tạo file ngay khi bắt đầu làm bài. Một output thô nhưng có cấu trúc còn tốt hơn việc nghĩ trong đầu quá lâu.

​

Bước 4. Đối chiếu lại template và expectation review

Sau khi có bản nháp, quay lại template hoặc page tuần để kiểm:

• Đúng format chưa?
• Đủ cột hoặc đủ mục chưa?
• File này có để người khác review độc lập được chưa?

Nên dùng thêm:

• Tự Phản Biện (Self Assessment)
• Đánh Giá Tuần Của Mentor

để tự soi trước khi gửi.

​

Bước 5. Tự review trước khi nộp

Đừng nộp ngay sau khi làm xong. Hãy xem lại như một mentor khó tính:

• File này có rõ ràng không?
• Có phần nào đang nói chung chung không?
• Có bằng chứng nào để chứng minh nhận định của mình không?
• Nếu người khác cầm file này, họ có hiểu mình đang verify cái gì không?

Nếu cần một quy trình tự soi chi tiết hơn theo từng loại output, xem Cách Tự Review Trước Khi Nộp.

​

Bước 6. Chốt blocker và câu hỏi còn kẹt

Nếu vẫn còn vướng, hãy ghi rõ:

• Mình đang kẹt ở đoạn nào.
• Mình đã thử cách gì rồi.
• Mình cần mentor xác nhận điều gì.

Đây là nền để hỏi mentor hiệu quả, thay vì hỏi theo kiểu “em chưa hiểu”.

​

Cách Làm Bài Để Không Học Vẹt

Một output nhìn đầy đủ chưa chắc là output có chất lượng. Dấu hiệu học vẹt thường là:

• chép lại lý thuyết nhưng không áp được vào artifact;
• điền đủ cột nhưng logic test mỏng;
• viết rất dài nhưng không nói rõ đang kiểm cái gì;
• chỉ làm theo ví dụ cũ mà không hiểu vì sao ví dụ đó đúng.

Để tránh điều này, trước mỗi deliverable, hãy tự trả lời ba câu:

1. Tôi đang test hoặc phân tích cái gì?
2. Vì sao phần này đáng test?
3. Mentor sẽ dùng output này để review năng lực nào của tôi?

Ví dụ:

• Nếu bạn viết test case, mục tiêu không phải là “điền đủ template”, mà là tạo hướng dẫn kiểm thử có thể chạy lại.
• Nếu bạn log bug, mục tiêu không phải là “ghi nhận có lỗi”, mà là mô tả đủ để team tái hiện và xử lý.
• Nếu bạn viết SQL verify note, mục tiêu không phải là thể hiện cú pháp, mà là chứng minh record hoặc field đã đúng hoặc sai.

Khi làm bài, hãy ưu tiên trả lời được logic trước, hình thức sau. Hình thức vẫn quan trọng, nhưng hình thức không cứu được một deliverable rỗng logic.

​

Cách Tự Review Trước Khi Nộp

Trước khi gửi mentor, hãy tự soi output theo 5 tiêu chí tối thiểu:

​

1. Accuracy

• Tôi có hiểu đúng bài toán không?
• Tôi có đang test đúng scope không?
• Kết luận của tôi có bám requirement hoặc behavior thực tế không?

​

2. Completeness

• Tôi có bỏ sót phần quan trọng nào không?
• Có đủ positive, negative, edge case chưa?
• Có thiếu state, role, field, record hay context nào không?

​

3. Clarity

• Người khác có đọc là hiểu không?
• Title, steps, expected result, query note có rõ không?
• Có chỗ nào đang viết mơ hồ kiểu “đúng”, “ổn”, “bị lỗi” không?

​

4. Practicality

• Output này có dùng được trong review hoặc vận hành thật không?
• Người khác có thể chạy lại theo output này không?
• Có minh họa đúng thứ cần chứng minh không?

​

5. Naming Và Submission Discipline

• Tên file có đúng theo page tuần không?
• Format file có đúng loại deliverable không?
• Có thiếu README, comment, note hoặc evidence cần thiết không?

Nếu một output chỉ đạt hình thức nhưng không qua được Accuracy hoặc Clarity, đừng nộp vội.

​

Khi Nào Nên Hỏi Mentor

Mentor không phải là nơi thay bạn nghĩ từ đầu, nhưng mentor là điểm gỡ nút khi bạn đã tự làm nghiêm túc.

​

Nên hỏi khi

• Bạn kẹt ở logic cốt lõi của bài, không phải ở một chi tiết nhỏ.
• Bạn không hiểu feedback cũ nên có nguy cơ sửa sai hướng.
• Requirement, flow hoặc rule đang có dấu hiệu mâu thuẫn.

​

Chưa nên hỏi khi

• Bạn chưa đọc kỹ page tuần.
• Bạn chưa thử ít nhất một hướng giải quyết.
• Bạn chưa gom đủ context để mô tả mình đang kẹt ở đâu.
• Bạn đang muốn mentor chỉ luôn đáp án thay vì xác nhận hướng nghĩ.

​

Cách hỏi mentor hiệu quả

Hãy hỏi theo format ngắn này: Context -> Em đã thử gì -> Em đang kẹt ở đâu -> Em cần mentor xác nhận gì Ví dụ:

Context: Em đang viết state transition matrix cho flow Leave Request. Em đã map được Draft -> Submitted -> Approved/Rejected. Em đang kẹt ở case Rejected có được edit rồi submit lại hay không vì page flow và UI chưa nói rõ. Em cần mentor xác nhận đây là out of scope hay nên đưa vào assumption.

Cách hỏi này giúp mentor trả lời nhanh và chính xác hơn rất nhiều. Nếu bạn muốn dùng một khung hỏi rõ hơn, xem Cách Hỏi Mentor & Nhận Feedback.

​

Cách Nhận Feedback

Feedback chỉ có giá trị khi bạn biến nó thành thay đổi cụ thể trên artifact.

​

Bước 1. Đọc đúng ý feedback

Phân biệt rõ mentor đang nói về:

• lỗi hiểu sai logic;
• lỗi thiếu coverage;
• lỗi trình bày chưa rõ;
• lỗi kỷ luật nộp bài hoặc naming.

​

Bước 2. Tìm lỗi gốc

Đừng chỉ sửa đúng dòng bị comment. Hãy hỏi:

• Mình sai ở một chỗ hay sai cả cách nghĩ?
• Lỗi này có lặp lại ở các file khác không?

​

Bước 3. Sửa trên đúng deliverable cũ

Không nên tạo một file mới chỉ để né feedback. Hãy sửa ngay trên deliverable cũ để mentor nhìn được quá trình cải thiện.

​

Bước 4. Ghi rõ phần đã thay đổi

Khi nộp lại, nên nói ngắn:

• Em đã sửa phần nào.
• Em sửa theo logic gì.
• Chỗ nào em vẫn còn chưa chắc.

Nếu cần hiểu rõ style feedback mentor đang dùng, xem thêm Nguyên Tắc Feedback Học Viên. Để không quên các lỗi lặp và insight quan trọng sau mỗi lần sửa, giữ song song một Personal Learning Log / Mistake Log.

​

Cách Giữ Tiến Độ Nếu Bị Chậm

Bị chậm không đáng ngại bằng việc chậm nhưng không kiểm soát được nguyên nhân. Khi tiến độ bắt đầu lệch, hãy làm theo thứ tự này:

1. Chốt phần bắt buộc của tuần trước, đừng ôm thêm phần mở rộng.
2. Tách bài đang kẹt thành từng output nhỏ theo ngày.
3. Báo mentor sớm nếu blocker ảnh hưởng tới gate của tuần.
4. Dùng self-assessment để chỉ rõ mình chậm ở kỹ năng nào, không chỉ nói “em chưa kịp”.
5. Không dồn tất cả deliverable vào cuối tuần vì như vậy bạn mất luôn thời gian sửa sau feedback.

Nếu tuần bị trễ, ưu tiên cứu deliverable usable trước, rồi mới tối ưu độ đẹp hoặc phần mở rộng.

​

Dấu Hiệu Học Đúng Vs Sai Hướng

​

Self-Check Checklist

Trước khi kết thúc mỗi tuần, hãy tự tick các câu sau:

• Tôi đã đọc kỹ page tuần và hiểu tuần này đang rèn năng lực gì.
• Tôi làm bài theo từng ngày thay vì dồn đến cuối tuần.
• Mỗi deliverable tôi nộp đều có mục tiêu rõ và có thể review độc lập.
• Tôi đã tự review theo Accuracy, Completeness, Clarity, Practicality và Naming.
• Tôi có thể giải thích vì sao mình chọn cách test hoặc cách phân tích hiện tại.
• Khi kẹt, tôi đã tự thử ít nhất một hướng trước khi hỏi mentor.
• Khi hỏi mentor, tôi cung cấp đủ context, hướng đã thử và câu hỏi cụ thể.
• Tôi tiếp nhận feedback bằng cách sửa đúng artifact, không chỉ phản hồi bằng lời.
• Nếu bị chậm, tôi đã ưu tiên phần bắt buộc và báo blocker đủ sớm.
• Tôi biết rõ output nào của mình còn yếu và tuần tới cần cải thiện gì.

​

Kết Thúc Trang

Đi hết chương trình này không cần bạn phải “biết tuốt” ngay từ đầu. Điều cần nhất là kỷ luật học theo đúng nhịp, tự phản biện được chất lượng bài làm, hỏi đúng lúc, và sửa tới nơi sau feedback. Nếu bạn giữ được bốn điều đó trong suốt 8 tuần, bạn không chỉ hoàn thành khóa học, mà còn xây được cách làm việc đủ gần với môi trường dự án thật. Khi cần xem lại cách dùng lộ trình hoặc chuẩn đóng gói bài cuối khóa, quay lại Cách Dùng Chương Trình và Hướng Dẫn Portfolio Cuối Khóa. Nếu muốn siết chất lượng bài trước khi nộp, đi tiếp sang Cách Tự Review Trước Khi Nộp.