Constraints

Không có project thật nào tồn tại trong điều kiện hoàn hảo.

Bạn luôn phải làm việc với deadline, legacy system, nguồn lực hạn chế, policy, stakeholder, technical debt hoặc data không đầy đủ.

Một mistake phổ biến là dùng constraint để biện minh: “vì deadline gấp nên...”, “vì team thiếu người nên...”.

Constraint tốt không dùng để đổ lỗi. Nó dùng để giải thích decision space.

Constraint — giới hạn là gì?

Tension — giới hạn đó tạo xung đột gì?

Options — bạn thực sự có những lựa chọn nào?

Trade-off — phải hy sinh điều gì?

Decision — cuối cùng bạn chọn gì và vì sao?

Nếu người xem không biết bạn chỉ có 2 tuần, họ sẽ đánh giá solution như thể bạn có 2 tháng.

Nếu họ không biết legacy system không thể thay đổi, họ sẽ không hiểu vì sao bạn tối ưu quanh nó thay vì rebuild.

Constraint một mình chưa đủ. Điều quan trọng là conflict mà nó tạo ra.

Speed vs quality. Consistency vs flexibility. Short-term delivery vs long-term maintainability. User need vs compliance.

Người ít kinh nghiệm thường kể solution như thể đó là lựa chọn hiển nhiên.

Người có judgment tốt cho thấy họ đã thấy nhiều option, hiểu cost của từng option và chủ động chấp nhận một trade-off.

Đừng liệt kê mọi giới hạn nhỏ.

Chỉ giữ những constraint thực sự ảnh hưởng đến problem framing, decision, execution hoặc result.

Đôi khi contribution mạnh nằm ở việc không build thêm feature, không redesign toàn hệ thống, không automate quá sớm hoặc không chạy campaign ở mọi kênh.

Constraint giúp người xem hiểu restraint cũng có thể là judgment.

Mỗi Project có thể có một Constraints block ngắn: giới hạn chính, tension tạo ra, options được cân nhắc, trade-off đã chấp nhận và decision cuối cùng.

Nhờ vậy AI và người xem đọc project ở đúng decision context.

Đừng giấu constraints để project trông “sạch” hơn.

Hãy cho thấy bạn đã làm việc tốt trong điều kiện không hoàn hảo như thế nào.

Constraint → Tension → Options → Trade-off → Decision.