🎯 Ask Less, Ask Better — Framework Đọc Task Sâu & Hỏi Khách Hàng Hiệu Quả
🎯 Mục Tiêu Bài Viết
Một trong những điểm phân biệt senior engineer / tech lead với developer thông thường là khả năng tự điều tra context trước khi hỏi khách hàng.
Bài này xây dựng framework thực chiến giúp bạn:
- Đọc task sâu hơn
- Liên kết với backlog / history trước khi hỏi
- Hỏi ít hơn nhưng chất lượng hơn
- Thể hiện được tư duy của một tech lead trước mặt khách hàng
1. Vấn Đề Gốc
Bạn đang gặp tình huống này:
Nhận task mới
↓
Đọc requirement
↓
Thấy điểm chưa rõ
↓
Hỏi khách hàng ngay
↓
Sau đó mới nhận ra:
"Câu trả lời đã nằm trong task cũ / behavior cũ / backlog liên quan"
↓
Mất thời gian của mình + khách hàng
Vấn đề không phải là bạn hỏi sai.
Vấn đề là bạn đang hỏi trước khi hoàn thành bước “context linking”.
Requirement Reading ≠ Requirement Understanding
Hiểu task không chỉ là đọc task hiện tại,
mà là hiểu task đó nằm ở đâu trong toàn bộ business flow.
2. Task Analysis Framework — Tổng Quan
┌──────────────────────────────┐
│ NEW TASK RECEIVED │
│ Nhận task mới từ backlog │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ STEP 1: READ CURRENT TASK │
│ Đọc task hiện tại │
│ │
│ - Goal là gì? │
│ - Screen nào? │
│ - User action nào? │
│ - Expected behavior là gì? │
│ - Acceptance criteria là gì? │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ STEP 2: CONTEXT LINKING │
│ Liên kết với context cũ │
│ │
│ Check: │
│ - Task trước đó │
│ - Bug liên quan │
│ - Backlog cùng feature │
│ - Business flow liên quan │
│ - Existing behavior │
│ - Similar screen / module │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ STEP 3: SELF-ANSWER FIRST │
│ Tự trả lời trước │
│ │
│ Với mỗi câu hỏi: │
│ - Có answer trong task cũ? │
│ - Có behavior hiện tại? │
│ - Có pattern tương tự? │
│ - Có thể suy luận logic? │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ STEP 4: CLASSIFY QUESTIONS │
│ Phân loại câu hỏi │
│ │
│ A. Already answered │
│ B. Can infer safely │
│ C. Need confirmation │
│ D. True blocker │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ STEP 5: ASK FOCUSED QUESTION │
│ Chỉ hỏi câu cần hỏi │
│ │
│ Format: │
│ - My understanding is... │
│ - Based on previous task... │
│ - I assume that... │
│ - Could you confirm...? │
└──────────────────────────────┘
3. Framework 5 Bước Chi Tiết
Step 1 — Đọc Task Theo 5 Điểm Chính
Khi nhận task, đừng đọc kiểu “đọc chữ”. Hãy đọc theo cấu trúc:
┌────────────────────────────┐
│ CURRENT TASK ANALYSIS │
└────────────────────────────┘
1. Business Goal
→ Task này giải quyết vấn đề business gì?
2. User Flow
→ User đang ở màn hình nào?
→ User click / input / submit gì?
3. Expected Behavior
→ Hệ thống phải phản ứng thế nào?
4. Data / API / State
→ Data nào bị ảnh hưởng?
→ API nào liên quan?
→ State nào thay đổi?
5. Edge Cases
→ Nếu data rỗng thì sao?
→ Nếu lỗi API thì sao?
→ Nếu user không có permission thì sao?
Ví dụ tư duy:
Task nói: "Update validation for Order form"
Không nên chỉ hỏi:
"Validation cụ thể là gì?"
Nên phân tích:
- Form này thuộc flow nào?
- Trước đây validation cũ là gì?
- Có task nào từng update Order form không?
- Có bug nào liên quan đến validation không?
- Màn hình khác có validation tương tự không?
Step 2 — Context Linking: Liên Kết Task Mới Với Task Cũ
Đây là bước quan trọng nhất. Trước khi hỏi khách hàng, bạn check 6 nguồn context:
┌────────────────────────────────────┐
│ CONTEXT LINKING │
└────────────────────────────────────┘
New Task
│
┌───────────┼───────────┐
↓ ↓ ↓
Previous Related Similar
Tasks Bugs Features
↓ ↓ ↓
Existing Business UI/API
Behavior Rules Pattern
1. Previous Tasks
→ Có task nào cùng feature không?
→ Có task nào làm cùng screen không?
2. Related Bugs
→ Bug cũ có mô tả behavior không?
→ Bug cũ có comment của khách hàng không?
3. Similar Features
→ Feature khác có logic tương tự không?
→ Có thể reuse behavior không?
4. Existing Behavior
→ App hiện tại đang chạy thế nào?
→ DEV / QA / PROD behavior có khác nhau không?
5. Business Rules
→ Rule này có từng được khách hàng giải thích chưa?
→ Có rule ngầm nào không?
6. API / Data Contract
→ API response có thể hiện rule không?
→ Backend đã support chưa?
Step 3 — Self-Answer First: Tự Trả Lời Trước
Với mỗi điểm chưa rõ, hãy tự hỏi:
- Câu trả lời có trong task cũ không?
- Có behavior hiện tại làm reference không?
- Có pattern tương tự ở module khác không?
- Có thể suy luận an toàn từ business logic không?
Step 4 — Phân Loại Câu Hỏi
Không phải câu hỏi nào cũng cần hỏi khách hàng:
┌───────────────────────┬──────────────────────────────┬──────────────────────┐
│ Loại câu hỏi │ Ý nghĩa │ Cách xử lý │
├───────────────────────┼──────────────────────────────┼──────────────────────┤
│ A. Already Answered │ Đã có câu trả lời ở task cũ │ Không hỏi │
│ B. Can Infer Safely │ Có thể suy luận an toàn │ Ghi assumption │
│ C. Need Confirmation │ Suy luận được nhưng cần xác nhận│ Hỏi ngắn gọn │
│ D. True Blocker │ Không có context, không tự xử │ Hỏi ngay, rõ impact │
└───────────────────────┴──────────────────────────────┴──────────────────────┘
A. Already Answered:
Question: "Button Save should be disabled when form invalid?"
→ Ở task ABC-123 khách hàng đã confirm:
"Save button should be disabled until all required fields are valid."
Action: Không hỏi lại. Áp dụng theo behavior cũ.
B. Can Infer Safely:
Question: "Should this validation apply to Edit mode too?"
→ Create mode và Edit mode dùng chung form.
→ Validation hiện tại đang apply cho cả hai.
→ Task mới chỉ update rule validation.
Assumption: Validation should apply to both Create and Edit mode.
Action: Không nhất thiết hỏi. Ghi trong technical note.
C. Need Confirmation:
Question: "Should this new rule apply to historical records?"
→ Tìm được logic tương tự nhưng chưa rõ với historical data.
Action: Hỏi kèm context:
"Based on ABC-123, I understand validation applies to new records only.
Could you confirm whether we should keep the same behavior?"
D. True Blocker:
Question: "Which calculation formula should be used for this field?"
→ Không có task cũ, không có existing behavior, không có API rule.
Action: Hỏi ngay vì đây là blocker thực sự.
Step 5 — Ask Focused: Công Thức Đặt Câu Hỏi Chuyên Nghiệp
Format chuẩn:
Context → My Understanding → Assumption → Question → Impact
┌─────────────┐
│ Context │ Dựa trên task / behavior nào?
└──────┬──────┘
↓
┌─────────────┐
│Understanding│ Tôi đang hiểu như thế nào?
└──────┬──────┘
↓
┌─────────────┐
│ Assumption │ Tôi giả định điều gì?
└──────┬──────┘
↓
┌─────────────┐
│ Question │ Cần khách hàng confirm gì?
└──────┬──────┘
↓
┌─────────────┐
│ Impact │ Nếu không confirm thì ảnh hưởng gì?
└─────────────┘
4. Decision Tree — Khi Nào Nên Hỏi?
┌──────────────────────────────┐
│ I HAVE A QUESTION ABOUT TASK │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ 1. Did I check current task? │
└───────────────┬──────────────┘
No │ Yes
↓ ↓
Read again ┌──────────────────────────────┐
│ 2. Did I check related tasks?│
└───────────────┬──────────────┘
No │ Yes
↓ ↓
Search backlog ┌──────────────────────────────┐
│ 3. Is there existing behavior?│
└───────────────┬──────────────┘
No │ Yes
↓ ↓
Need question? Compare behavior
with new task
│
↓
┌──────────────────────────────┐
│ 4. Can I infer safely? │
└───────────────┬──────────────┘
Yes │ No
↓ ↓
Document assumption Ask customer
+ maybe confirm with context
Nguyên tắc: Không hỏi ngay khi “không hiểu”. Chỉ hỏi sau khi đã đọc task hiện tại, check task liên quan, check behavior hiện tại, và tự đưa ra assumption.
5. Chiến Lược Search Backlog Hiệu Quả
Khi nhận task mới, search theo nhiều layer:
New Task
↓
Search Backlog by:
├── Feature name (Order, Invoice, User Management)
├── Screen name (Order Detail, Create Order, Edit Order)
├── Field name (Status, Due Date, Amount)
├── Behavior keyword (validation, readonly, disable, permission)
├── Bug keyword (cannot save, incorrect status, missing data)
└── API / data field (orderStatus, customerType, effectiveDate)
6. Framework “3 Tầng Hiểu Task”
Một tech lead không nên chỉ hiểu task ở tầng UI:
┌────────────────────────────────────┐
│ LEVEL 3: BUSINESS RULE │
│ Vì sao behavior này tồn tại? │
│ Rule business đằng sau là gì? │
└────────────────────────────────────┘
↑
┌────────────────────────────────────┐
│ LEVEL 2: USER FLOW │
│ User đi qua flow nào? │
│ Trạng thái trước/sau là gì? │
└────────────────────────────────────┘
↑
┌────────────────────────────────────┐
│ LEVEL 1: UI REQUIREMENT │
│ Button, field, popup, validation │
│ hiển thị hoặc hoạt động thế nào? │
└────────────────────────────────────┘
Ví dụ:
Level 1 - UI:
Disable Save button.
Level 2 - User Flow:
User cannot save when required information is missing.
Level 3 - Business Rule:
The system must prevent incomplete order submission
because downstream processing requires complete data.
Nếu bạn chỉ hiểu Level 1 → bạn sẽ hỏi nhiều. Nếu bạn hiểu đến Level 3 → bạn sẽ tự suy luận được nhiều behavior liên quan.
7. Cách Hỏi Trong Daily Meeting
Chưa tốt:
I have a question about this ticket.
What should happen when the user edits this field?
Tốt hơn:
I reviewed the ticket and compared it with the existing behavior in the previous Order flow.
Currently, the same field is editable in Create mode but read-only in Edit mode.
For this new ticket, my assumption is that we should keep the same behavior.
Could you confirm if we should apply the change only to Create mode, or both?
Tốt hơn vì:
- Bạn đã chứng minh mình có check context
- Không hỏi chung chung
- Đưa ra assumption trước
- Khách hàng chỉ cần confirm A hoặc B
- Giảm thời gian trao đổi
8. Template Hỏi Khách Hàng Chuyên Nghiệp
Template 1: Confirm behavior
Hi [Name], I reviewed this ticket and compared it with the existing behavior in [module/screen].
My understanding is that we should follow the same behavior as [previous ticket/flow].
Could you please confirm if this is correct?
Template 2: Confirm scope
Hi [Name], I checked the related tickets and found that this behavior currently applies to [A].
For this new ticket, should we apply the same logic to [B] as well,
or keep it limited to [A] only?
Template 3: Confirm assumption with risk
Hi [Name], based on the previous implementation, I assume this change should only apply to [specific case].
Could you confirm?
If we apply it to all cases, it may affect [related flow/existing behavior].
Template 4: Khi chưa tìm thấy context
Hi [Name], I checked the current ticket, related backlog items, and existing behavior,
but I could not find a clear reference for this rule.
Could you please clarify the expected behavior for [specific case]?
Template 4 rất chuyên nghiệp vì bạn nói rõ bạn đã check rồi — bạn không hỏi lười.
9. Task Context Note — Mẫu Ghi Chú Cho Mỗi Task
Trước khi hỏi, tạo một note nhỏ như sau:
Task: GA-1234 - Update validation for Order form
1. Current Understanding
- This task updates validation logic for the Order form.
- It seems related to the previous Create Order behavior.
2. Related Tickets
- GA-980: Create Order validation
- GA-1045: Edit Order readonly behavior
- GA-1102: Bug fix for invalid amount
3. Existing Behavior
- Create mode: field is editable.
- Edit mode: field is readonly after status = Submitted.
4. Assumption
- New validation should apply only when the field is editable.
- For readonly mode, no new validation is needed.
5. Questions
- Confirm whether the validation applies to Edit mode when status = Draft.
6. Risk
- If we apply validation to all modes, users may be blocked
when editing historical records.
Note này giúp bạn:
- Nhớ context tốt hơn
- Hỏi khách hàng có căn cứ
- Dễ explain estimate
- Dễ handover cho team member
- Tránh hỏi lại câu đã có answer
10. Checklist Trước Khi Hỏi Khách Hàng
┌─────────────────────────────────────────────┐
│ BEFORE ASKING CUSTOMER CHECKLIST │
└─────────────────────────────────────────────┘
[ ] Tôi đã đọc kỹ acceptance criteria chưa?
[ ] Tôi đã check task liên quan trong backlog chưa?
[ ] Tôi đã search keyword theo screen / module / field name chưa?
[ ] Tôi đã check behavior hiện tại trên app chưa?
[ ] Tôi đã check bug cũ hoặc comment cũ chưa?
[ ] Tôi đã so sánh với flow tương tự chưa?
[ ] Tôi đã tự đưa ra assumption chưa?
[ ] Câu hỏi này có thật sự cần khách hàng trả lời không?
[ ] Nếu không hỏi, risk là gì?
[ ] Nếu hỏi, tôi có thể hỏi theo dạng confirm A/B không?
11. Daily Routine Áp Dụng Mỗi Ngày
┌────────────────────────────────────────────┐
│ DAILY TASK ANALYSIS ROUTINE │
└────────────────────────────────────────────┘
Morning / Before Daily
↓
1. Review assigned tasks
↓
2. Identify unclear points
↓
3. Search related tickets / bugs / comments
↓
4. Check existing app behavior
↓
5. Write assumptions
↓
6. Classify questions:
- Already answered
- Can infer
- Need confirm
- Blocker
↓
7. Ask only focused questions in daily/chat
12. Mini Framework: Ask Less, Ask Better
┌──────────────────────────────┐
│ ASK LESS │
│ Không hỏi lại những thứ │
│ đã có trong backlog/history │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ THINK MORE │
│ Liên kết task mới với │
│ business flow cũ │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ ASSUME CLEARLY │
│ Đưa ra assumption dựa trên │
│ evidence │
└───────────────┬──────────────┘
↓
┌──────────────────────────────┐
│ CONFIRM ONLY │
│ Chỉ hỏi khách hàng để │
│ confirm điểm có risk │
└──────────────────────────────┘
13. Câu Thần Chú
Don't ask because you don't know.
Ask after you have investigated and formed a reasonable assumption.
Đừng hỏi chỉ vì mình chưa biết. Hãy hỏi sau khi mình đã kiểm tra context và có một giả định hợp lý.
14. Tóm Tắt
Nhận task
↓
Đọc requirement
↓
Search task cũ / bug cũ / behavior cũ
↓
Liên kết với business flow
↓
Tự đưa ra assumption
↓
Phân loại câu hỏi
↓
Chỉ hỏi điểm có risk hoặc cần decision từ khách hàng
Vai trò của tech lead không phải là hỏi thật nhiều.
Vai trò của tech lead là giảm noise cho khách hàng bằng cách:
- tự điều tra context,
- suy luận dựa trên evidence,
- chỉ escalate những điểm cần business decision.