First Principles trong Công việc

Khi lý thuyết gặp thực tế công việc hằng ngày

Ở hai bài trước, chúng ta đã hiểu bản chất của First Principles Thinking và quy trình 4 bước để áp dụng nó. Nhưng câu hỏi mà rất nhiều người đặt ra là: "Nghe hay đấy, nhưng áp dụng vào công việc thực tế của mình như thế nào?"

Trong bài này, chúng ta sẽ đi qua hai góc nhìn cụ thể: của một Software Engineer và của một Nhà quản lý / người vận hành startup – hai vai trò mà First Principles Thinking có thể tạo ra khác biệt rõ rệt nhất.

Góc nhìn kỹ sư: Đừng sao chép kiến trúc, hãy hiểu bài toán

Một trong những cái bẫy phổ biến nhất với kỹ sư phần mềm là việc chọn công nghệ, kiến trúc hệ thống dựa trên xu hướng, thay vì dựa trên bài toán thực tế.

Ví dụ điển hình: một startup mới có vài trăm người dùng nhưng đã vội vàng thiết kế hệ thống microservices phức tạp, với Kubernetes, message queue, và hàng chục service riêng biệt – chỉ vì "các công ty lớn như Netflix, Uber đều làm vậy".

Nếu áp dụng tư duy lối mòn, câu hỏi sẽ là: "Các công ty công nghệ lớn dùng kiến trúc gì?" Nhưng nếu áp dụng First Principles Thinking, câu hỏi đúng phải là:

Lưu lượng người dùng thực tế hiện tại và dự kiến trong 12 tháng tới là bao nhiêu?
Độ trễ (latency) nào là chấp nhận được với trải nghiệm người dùng của sản phẩm này?
Ngân sách vận hành hạ tầng thực tế của team là bao nhiêu?
Team hiện có bao nhiêu người, và năng lực vận hành hệ thống phức tạp đến đâu?

Khi trả lời trung thực những câu hỏi này, rất nhiều trường hợp câu trả lời sẽ là: một monolith được thiết kế tốt, chạy trên một vài server, hoàn toàn đủ sức phục vụ hàng trăm nghìn request mỗi ngày – rẻ hơn, đơn giản hơn, và dễ bảo trì hơn rất nhiều so với kiến trúc phân tán mà đội ngũ 5 người không đủ nguồn lực vận hành.

Nguyên lý cốt lõi ở đây: kiến trúc hệ thống nên được sinh ra từ ràng buộc và mục tiêu thực tế của bạn, không phải từ danh tiếng của công ty khác đang dùng nó.

Góc nhìn quản lý: Xây dựng tổ chức từ bài toán, không từ "best practice"

Với người quản lý hoặc người vận hành startup, cái bẫy tương tự cũng xuất hiện – nhưng ở quy mô tổ chức.

Rất nhiều startup sao chép nguyên xi cơ cấu tổ chức, quy trình OKR, hay văn hóa họp hành của các công ty lớn như Google hay Amazon – trong khi bối cảnh, quy mô, và giai đoạn phát triển hoàn toàn khác biệt.

Áp dụng First Principles Thinking ở đây nghĩa là quay về câu hỏi gốc: Mục tiêu thực sự của quy trình này là gì? Một quy trình review hiệu suất hàng quý tồn tại để làm gì – để đánh giá công bằng, để giữ chân nhân tài, hay để tuân thủ một "chuẩn mực" mà không ai còn nhớ lý do ban đầu?

Khi bạn hiểu rõ mục tiêu gốc, bạn có thể thiết kế một quy trình tinh gọn hơn nhiều, phù hợp với đúng quy mô và văn hóa của tổ chức mình – thay vì vay mượn một bộ máy được thiết kế cho một tổ chức có hàng chục nghìn nhân sự.

Điểm chung: Hiểu nguyên lý, bạn sẽ tự tạo ra giải pháp

Dù là kỹ sư hay nhà quản lý, nguyên tắc cốt lõi vẫn không đổi:

Khi bạn thực sự hiểu bản chất của vấn đề, bạn không còn cần đi vay mượn giải pháp từ người khác – bạn có đủ dữ kiện để tự thiết kế giải pháp phù hợp nhất với chính hoàn cảnh của mình.

Điều này không có nghĩa là bỏ qua hoàn toàn kinh nghiệm của người đi trước. Học hỏi từ case study, từ best practice vẫn rất giá trị – nhưng nó nên là nguồn tham khảo, không phải khuôn mẫu để sao chép nguyên xi. Sự khác biệt nằm ở chỗ: bạn có hiểu tại sao giải pháp đó hiệu quả với họ hay không, và liệu những điều kiện đó có đúng với bối cảnh của bạn hay không.

Một vài tình huống thực tế khác để bạn liên hệ

Định giá sản phẩm: Thay vì hỏi "đối thủ đang bán giá bao nhiêu", hãy hỏi "giá trị thực sự mà khách hàng nhận được là gì, và họ sẵn sàng trả bao nhiêu cho giá trị đó?".
Tuyển dụng: Thay vì yêu cầu bằng cấp vì "công ty nào cũng yêu cầu vậy", hãy hỏi "kỹ năng cụ thể nào thực sự cần thiết để hoàn thành công việc này?".
Quy trình onboarding: Thay vì copy checklist 30 bước từ công ty khác, hãy hỏi "nhân viên mới thực sự cần biết gì trong tuần đầu tiên để làm việc hiệu quả?".

First Principles Thinking là một công cụ mạnh mẽ để tạo ra những giải pháp thực sự phù hợp và đột phá, thay vì chỉ đi theo lối mòn. Nhưng như bất kỳ công cụ mạnh nào, nó cũng có những giới hạn và cạm bẫy riêng nếu bị lạm dụng sai cách.