Trả lời ngắn: Research intake là bước ghi rõ yêu cầu thành decision question, scope, evidence cần và điểm dừng trước khi tìm câu trả lời. Nó giúp research không bị headline kéo đi, không nhét sẵn conclusion, và không phình thành một task không có người chịu trách nhiệm hay deadline.

Đọc xong, bạn sẽ hiểu:

  • Cách đổi request mơ hồ thành decision question.
  • Cách khóa scope, owner và evidence cần tìm.
  • Cách nhận ra scope creep trước khi task phình to.
  • Cách làm intake card 15 phút bằng Google Sheets.

Lưu ý giáo dục: Mây Foods, đơn giao trưa, voucher và mọi outcome trong bài đều là dữ liệu giả để học process. Đây không phải dự báo, khuyến nghị mua bán hay cam kết lợi nhuận.

1. Intake là làm rõ câu hỏi, không nhận luôn kết luận

Research intake là ghi rõ task trước khi đi tìm câu trả lời. Nó không phải form cho có, cũng không phải đoạn mở đầu để khẳng định thesis. Decision question là câu xác định điều cần kiểm. Request “Mây Foods có đang tăng không?” là mơ hồ: tăng cái gì, với ai, thời gian nào, để quyết định điều gì?

Hãy đổi nó thành: “Trong hai tuần demo, đơn giao bữa trưa của Mây Foods có thay đổi ở nhóm văn phòng xác định không, và evidence nào phân biệt voucher với nhu cầu lặp lại?” Câu này chưa kết luận Mây Foods tốt/xấu. Nó chỉ xác định nghiên cứu phải nhìn gì.

Nó giống chuẩn bị bữa ăn cho một nhóm. “Có đồ ăn là được” chưa đủ để lên danh sách. Cần biết món gì, bao nhiêu người, giờ nào, ai mang về và món nào không cần. Intake giúp research có cùng mức rõ ràng đó.

Hình 1 — Intake giữ yêu cầu ở dạng câu hỏi có ranh giới.

2. Từ request mơ hồ đến decision question và owner

Một intake tốt mở bằng request nguyên văn, rồi viết decision question nhỏ hơn. Tiếp theo là owner, người chịu trách nhiệm tìm hoặc xác minh một evidence. Owner không nhất thiết là “người quyết định”; họ là người biết phần nào phải quay lại khi source thiếu hoặc định nghĩa metric không rõ.

Với Mây Foods, owner A có thể kiểm record đơn trong phạm vi demo; owner B kiểm điều kiện voucher; owner C đọc complaint/đơn lặp lại. Không chia owner, một người dễ ôm cả data, narrative và conclusion. Khi đó không ai biết phần nào đã được kiểm thật.

Đừng biến decision question thành câu hỏi dài vô tận. “Tại sao ngành giao đồ ăn thay đổi, Mây Foods có lợi thế gì và tài sản nào hưởng lợi?” là ba task khác nhau. Intake đầu tiên có thể chỉ làm rõ đơn giao trưa. Câu hỏi sau chỉ được mở khi evidence của task đầu cho lý do hợp lệ.

Hình 2 — Scope được đặt trước khi mở nhiều source.

3. Scope: population, time, metric và out-of-scope

Scope là ranh giới về nhóm, thời gian, nơi chốn và metric. Population là nhóm đối tượng đang xem; trong case là văn phòng demo, không phải mọi khách Mây Foods. Metric là thước đo cụ thể: đơn giao, đơn lặp lại hay complaint. Đừng để “tăng” chạy qua lại giữa ba metric.

Time cũng là scope. Hai tuần demo không đại diện cả năm. Geography cũng vậy: một cụm văn phòng khác toàn thành phố. Ghi rõ phần out-of-scope, tức phần không xử lý trong task: market share toàn ngành, định giá công ty, hoặc tác động tới giá tài sản. Out-of-scope không phải vấn đề bị quên; nó là việc được cố ý để ở card khác.

Theo CFA Institute Standard V(A), analysis cần basis hợp lý. Trong intake, basis bắt đầu từ scope khớp với câu hỏi. Data rất nhiều nhưng sai population hoặc sai time vẫn không trả lời được claim.

Hình 3 — Cùng một câu hỏi đổi nghĩa khi scope đổi.

4. Sai lầm scope creep, metric mơ hồ và deadline giả

Scope creep là task phình ra sau khi bắt đầu. Nó thường xuất hiện khi source mới thú vị: đang kiểm đơn trưa thì chuyển sang phân tích tất cả đối thủ. Nếu source mở câu hỏi mới, ghi nó vào danh sách chờ xử lý (backlog) để ưu tiên sau; không kéo nó vào intake hiện tại trừ khi scope được cập nhật công khai.

Sai lầm hai là metric mơ hồ. “Đơn tăng” có thể là số order, khách duy nhất, giá trị đơn hay đơn sau voucher. Sai lầm ba là deadline giả: ghi “xong sớm” nhưng không có điểm review. Deadline là lúc review hoặc đóng task, không phải lời hứa evidence sẽ cho outcome đẹp.

Một ví dụ đời thường là đi chợ theo danh sách. Bạn thấy món giảm giá không có nghĩa phải lấy mọi thứ. Danh sách giúp bữa ăn không thiếu món chính và tiền không trôi hết vào đồ ngẫu hứng. Scope cũng bảo vệ thời gian research như vậy.

Scope còn giúp tách hai câu hỏi nghe giống nhau nhưng evidence khác hẳn. “Đơn giao có đổi không?” cần record đơn. “Khách có hài lòng hơn không?” cần complaint, phản hồi hoặc hành vi quay lại. Nếu gộp hai câu thành một task, bạn có thể có rất nhiều record đơn mà vẫn không trả lời được trải nghiệm khách. Intake tốt cho phép ghi: task hiện tại chỉ trả lời câu một; câu hai là backlog có owner và deadline riêng.

Đừng nhầm deadline với áp lực phải tìm ra kết luận. Deadline chỉ nói khi nào team dừng thu thập, kiểm phần đã có và chọn một trong ba trạng thái: answer được trong scope, chưa answer được vì data gap, hoặc cần intake mới vì scope đổi. Ba trạng thái này đều có ích. “Chưa answer được” thường an toàn hơn một câu trả lời đi nhanh hơn source.

Khi evidence tới, đối chiếu nó với intake thay vì để evidence tự dẫn đường. Nếu một file cho toàn thành phố trong khi scope chỉ là văn phòng demo, file đó có thể là context, không phải answer trực tiếp. Nếu file không có time stamp, hãy ghi data gap. Nếu source dùng định nghĩa “đơn hoàn tất” khác metric của card, owner cần làm rõ trước khi cộng vào evidence. Các bước nhỏ này giữ card có thể được người khác audit.

Một intake cũng cần tiêu chí đóng. Ví dụ, task đóng khi có record đơn đủ definition/time, điều kiện voucher và một note scope; hoặc đóng sớm nếu record không tồn tại. Đóng sớm không là bỏ cuộc. Nó ngăn bạn lặp tìm kiếm cùng một dữ liệu không có, đồng thời tạo tín hiệu rõ cho người yêu cầu rằng câu hỏi cần được viết lại hoặc thu hẹp.

Bạn cũng nên lưu phiên bản intake lúc bắt đầu. Nếu đến ngày review team đổi metric từ số đơn sang giá trị đơn, đừng sửa card cũ rồi giả vờ hai cách đo là một. Tạo bản cập nhật, ghi lý do đổi và quyết định phần evidence cũ còn dùng được hay không. Việc này giống sửa danh sách đi chợ sau khi biết có thêm khách: danh sách mới hợp lệ, nhưng mọi người vẫn nhìn được vì sao món và số lượng đã đổi. Nhờ vậy, người đọc sau không nhầm một kết luận được tạo từ scope mới là kết quả của câu hỏi ban đầu.

5. Checklist intake trước khi tìm source

  1. Request đã đổi thành decision question trung tính chưa?
  2. Population, time, geography và metric có cụ thể không?
  3. Evidence nào thật sự cần, owner nào chịu trách nhiệm?
  4. Điều gì nằm out-of-scope trong task này?
  5. Deadline/review date là khi nào?
  6. Source mới sẽ vào backlog hay có lý do để đổi scope?
  7. Stop gate nào buộc dừng nếu thiếu data/định nghĩa?

Nếu câu 2 trống, đừng tìm source vội. Nếu câu 4 trống, task sẽ hấp thụ mọi câu hỏi mới. Nếu câu 7 trống, người làm dễ tự điền assumption để khỏi phải dừng.

6. Bài tập intake card 15 phút

Mở Google Sheets. Ba phút ghi request/decision question, ba phút khóa population/time/metric, ba phút gán owner/evidence, ba phút ghi out-of-scope/deadline và ba phút đặt stop gate. Mọi row dưới là giả; chưa dùng tiền thật hay biến intake thành quyết định giao dịch.

b. Mẫu đối chiếu đã điền

Request Decision question Scope Evidence/owner Out-of-scope Stop gate
Đơn giao đổi không? Đơn trưa nhóm demo có đổi? Hai tuần/văn phòng demo Record đơn/A Market share Thiếu định nghĩa đơn
Voucher có tác động? Trial khác repeat thế nào? Cohort voucher Điều kiện voucher/B Giá tài sản Thiếu cohort
Khách hài lòng? Complaint có đổi? Ticket demo Log complaint/C Toàn ngành Thiếu time stamp

Kết quả mong đợi là card có ranh giới rõ. Khi đổi topic, giữ sáu cột. Nếu claim mới xuất hiện, tạo intake mới thay vì sửa âm thầm task cũ.

Hình 4 — Card giúp task không phình thành scope creep.

7. Tổng kết

a. Năm ý chính

  • Intake biến request thành decision question, không thành conclusion.
  • Scope khóa population, time, geography và metric trước source hunt.
  • Owner làm evidence có người chịu trách nhiệm rõ.
  • Out-of-scope và backlog chặn scope creep.
  • Deadline, evidence và stop gate giữ task có điểm đóng.

b. Câu hỏi tự kiểm tra

  • Request khác decision question ở đâu?
  • Vì sao population và metric phải viết riêng?
  • Out-of-scope giúp gì cho research?
  • Khi nào phải mở intake mới?

c. Gợi ý đáp án

Xem gợi ý câu 1

Request có thể mơ hồ; decision question trung tính và có thể kiểm trong scope → xem mục 1.

Xem gợi ý câu 2

Nhóm được xem và thứ được đo thay đổi nghĩa của một câu “tăng” → xem mục 3.

Xem gợi ý câu 3

Nó giữ task hiện tại nhỏ, minh bạch và không nuốt các câu hỏi khác → xem mục 3–4.

Xem gợi ý câu 4

Khi câu hỏi/evidence vượt scope đã khóa, hãy ghi backlog rồi mở card riêng nếu cần → xem mục 4–5.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Intake Ghi rõ task trước khi tìm câu trả lời.
Decision question Câu xác định điều cần kiểm.
Owner Người chịu trách nhiệm evidence.
Scope Ranh giới nhóm, thời gian, nơi và metric.
Population Nhóm đối tượng được xem.
Metric Thước đo cụ thể.
Out-of-scope Phần không xử lý trong task.
Scope creep Task phình ra sau khi bắt đầu.
Stop gate Điều kiện phải dừng.

e. Nguồn tham khảo

f. Bài tiếp theo

Bài trước Case Study: Thesis đúng nhưng Timing sai #15 ghi timeline trước outcome. Bài tiếp theo là Source Management và Citation Audit #17, nơi evidence được ghi nguồn, scope và thời điểm để đọc lại được.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Case và dữ liệu đều là giả; mọi thị trường đều có rủi ro mất vốn.