Hầu hết dự án nghiên cứu không thất bại vì phân tích sai. Chúng thất bại sớm hơn nhiều — ngay thời điểm thiết kế nghiên cứu được chọn.
Đó là trong năm thứ hai nội trú, khi chúng mình phải trình bày đề cương nghiên cứu trước hội đồng. Có sáu người trong buổi đó. Đến cuối buổi, một nửa đề cương bị reject — không phải vì chủ đề tầm thường, mà vì thiết kế nghiên cứu không thể hỗ trợ câu hỏi được đặt ra.
Trải nghiệm đó đọng lại với mình. Nó dạy mình rằng thất bại thiết kế hiếm khi tự bộc lộ sớm. Nó chỉ trở nên rõ ràng khi lập luận được trình bày tường minh — và lúc đó, nhiều dự án đã đi quá xa để thay đổi hướng.
Câu hỏi nghiên cứu trông hợp lý. Tổng quan y văn kỹ lưỡng. Phần methods nghe phức tạp. Reviewer thậm chí có thể khen chủ đề.
Rồi, nhiều tháng sau, dự án chạm phải một nhận thức lặng lẽ nhưng chí mạng: nghiên cứu chưa bao giờ có khả năng trả lời câu hỏi nó đặt ra. Đây không phải lỗi kỹ thuật. Đây là lỗi quy trình.
Ảo tưởng về câu hỏi nghiên cứu "tốt"
Nhà nghiên cứu giai đoạn đầu thường được bảo hãy bắt đầu bằng một câu hỏi nghiên cứu tốt. (Nghe quen phải không?)
Điều họ hiếm khi được bảo là một câu hỏi tốt tự nó chẳng có nhiều ý nghĩa. Câu hỏi chỉ trở nên có ý nghĩa khi nó gặp một thiết kế có thể mang nó đi.
Một số pattern lặp đi lặp lại:
- câu hỏi hỏi về nhân quả, nhưng ghép với thiết kế thuần mô tả
- câu hỏi phụ thuộc vào kết cục dài hạn, nhưng chỉ có dữ liệu ngắn hạn
- câu hỏi giả định đo lường chính xác trong khi chỉ có proxy thô
- câu hỏi nghe sáng tạo, cho đến khi ràng buộc đạo đức khiến nó không thể thực hiện
Không câu hỏi nào trong số này bản chất là xấu. Chúng chỉ đơn giản không thể sống sót trong điều kiện thực tế của nghiên cứu. Sai lầm không phải hỏi sai câu hỏi. Mà là không hỏi liệu câu hỏi có sống sót khi tiếp xúc với thực tế không.
Nhìn thấy giới hạn từ sớm
Khi mình làm luận văn, mình đọc nhiều bài báo trông rất giống những gì mình muốn làm. Bề ngoài, điều đó khá an tâm — người khác đã làm điều tương tự, nên của mình cũng nên ổn.
Nhưng đặt ý tưởng vào bối cảnh nơi làm việc của mình thì mọi thứ thay đổi.
Ngay cả trước khi thu thập bất kỳ dữ liệu nào, mình đã thấy vấn đề sẽ xuất hiện ở đâu: sai lệch chọn mẫu từ cách bệnh nhân được chuyển tuyến, sai số thông tin từ hồ sơ không đầy đủ, và những hạn chế thông thường khi làm việc với dữ liệu lâm sàng thực tế. (Lúc đó là thử nghiệm lâm sàng đầu tiên của mình)
Quan trọng hơn, mình có thể đoán trước reviewer sẽ chỉ ra điều gì — và những hiệu chỉnh thống kê nào mình cần ít nhất thừa nhận, dù không thể sửa hoàn toàn.
Điều này không phải vì mình đặc biệt sáng suốt. Đơn giản là vì mình dành thời gian suy nghĩ xem thiết kế có thể và không thể xử lý gì trước khi cam kết với nó.
Chỉ riêng bước đó đã cứu mình khỏi việc theo đuổi những câu hỏi mà nghiên cứu chưa bao giờ đủ sức trả lời.
Thiết kế là giải quyết ràng buộc, không phải tối ưu hóa
Nhiều nhà nghiên cứu tiếp cận thiết kế nghiên cứu như bài toán tối ưu: Thiết kế tốt nhất cho câu hỏi này là gì?
Trên thực tế, cách đóng khung đó gây hiểu lầm. Câu hỏi hữu ích hơn là:
Thiết kế nào có thể trả lời hợp lý câu hỏi này trong điều kiện ràng buộc thực tế của mình?
Mỗi nghiên cứu nằm ở giao điểm của năm lực lượng:
- bản thân câu hỏi
- dữ liệu sẵn có
- thời gian
- giới hạn đạo đức
- nguồn lực — con người, kinh phí, quyền truy cập
Thiết kế không phải về bỏ qua những ràng buộc này để theo đuổi lý tưởng. Mà là về thương lượng trung thực với chúng. Và tin mình đi, bạn nên truyền tải thông điệp này qua luận văn. Kết quả xấu không phải là xấu, kết quả xấu với diễn giải tốt và trung thực mới là khoa học thực sự.
Đây là lý do hai nhà nghiên cứu có thể hỏi câu hỏi tương tự và chọn thiết kế khác nhau — cả hai đều phù hợp. Thiết kế không sai vì nó không lý tưởng. Nó chỉ sai khi giả vờ ràng buộc không tồn tại.
Căn chỉnh câu hỏi với thiết kế (mà không tôn sùng phương pháp)
Ở cấp độ quy trình, bạn không cần danh sách phương pháp đầy đủ.
Bạn cần sự căn chỉnh sơ bộ giữa những gì bạn đang hỏi và những gì thiết kế có thể hỗ trợ.
- Câu hỏi mô tả — Quần thể này trông như thế nào? → chuỗi ca bệnh, nghiên cứu cắt ngang
- Câu hỏi liên quan — X và Y có liên quan không? → thiết kế cohort, case-control, hoặc cắt ngang
- Câu hỏi nhân quả — X có gây ra Y không? → thử nghiệm ngẫu nhiên hoặc thiết kế bán thực nghiệm
- Câu hỏi dự đoán — Có thể dự đoán Y từ X không? → nghiên cứu mô hình và xác thực
Thiết kế là giải quyết ràng buộc, không phải tối ưu hóa
Vấn đề phát sinh khi sự căn chỉnh này bị bỏ qua — không phải vì thiếu hiểu biết, mà vì tham vọng.
Nhà nghiên cứu thường chọn thiết kế dựa trên uy tín tạp chí, sự nghiêm ngặt cảm nhận được, hoặc những gì trông tiên tiến. Nhưng thiết kế không phù hợp không trở nên hợp lệ nhờ sự phức tạp thống kê.
Nơi dự án lặng lẽ gãy
Một số điểm thất bại nhất định lặp đi lặp lại qua các lĩnh vực:
- Thiết kế được chọn khi câu hỏi còn chưa ổn định
- Kết cục được định nghĩa sau thiết kế, biến đo lường thành việc phụ
- Bias được xử lý muộn, như mục checklist thay vì vấn đề cấu trúc
- Diễn giải không bao giờ được lường trước — kết quả được tạo ra mà không hỏi claim nào thực sự bảo vệ được
Những thất bại này không ngẫu nhiên.
Chúng phản ánh quy trình coi thiết kế như thủ tục, thay vì quyết định định hình mọi thứ theo sau.
Thiết kế là cam kết
Chọn thiết kế không chỉ là bước kỹ thuật. Nó là cam kết.
Khi thiết kế được cố định, bạn ngầm đồng ý với:
- những gì bạn có thể claim chính đáng
- những gì bạn phải im lặng về
- loại reviewer nào bạn sẽ gặp
- phê bình nào bạn có thể gặp phải
Đây là lý do nhà nghiên cứu có kinh nghiệm có xu hướng dừng lại lâu hơn ở giai đoạn này. Họ hiểu rằng thiết kế khóa cả sức mạnh lẫn hạn chế. Quy trình tốt làm cho cam kết này trở nên tường minh — sớm, có chủ đích, và mở mắt.
Tiếp theo là gì
Khi thiết kế đã được chọn, câu hỏi trung tâm thay đổi:
Chính xác mình đang đo gì — và mình mù gì vì lựa chọn đó?
Đây là nơi nhiều nghiên cứu trông chắc chắn trên giấy bắt đầu yếu đi trong thực tế.
Và đó là nơi chúng ta chuyển sang tiếp theo.
Nếu bạn đang soạn bản thảo, bạn có thể thấy Checklist: Idea to Submission của mình hữu ích.