1
Quiz
Kiểm tra bài 1: Vì sao giao diện cứ rối dần — chi phí của những màn hình làm một lần
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài nàyDev / QA / Design Collaboration
CollaborationLàm việc hiệu quả với Dev, QA và Design: working agreements, input/output, trust, bug triage, release readiness và cross-functional handoffs.
Đăng nhập để đánh dấu kỹ năng và theo dõi tiến độ.
Bạn đang ở đâu với kỹ năng này?
Làm bài Đánh giá Kỹ năng Delivery cho PM/PO — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Collaboration, không chỉ kỹ năng này.
Làm bài đánh giáRoadmap — Cách học và đạt kỹ năng
Học cách làm việc với Dev/QA/Design
Đây là skill nền tảng cho BA/PM mới: hiểu mỗi function cần input gì, ra quyết định thế nào, và risk nào họ nhìn thấy trước bạn. Làm việc tốt với Dev/QA/Design không phải là “nhờ họ làm giúp”; đó là tạo clarity đủ sớm để họ thiết kế, build, test và release an toàn.
Function needs table
| Partner | Họ cần gì từ BA/PM? | Signal bạn làm tốt | Anti-pattern |
|---|---|---|---|
| Design | Problem, user context, constraints, edge cases, success metric. | Design explores options before UI is locked. | Hand off “make it pretty” after scope fixed. |
| Engineering | Goal, AC, data/API needs, non-goals, tradeoffs. | Engineering can explain approach and risks early. | Ask for estimate before requirement is clear. |
| QA | Acceptance criteria, test data, edge cases, release risk. | QA writes test cases without guessing behavior. | Involve QA only after development is “done”. |
Giữ quan hệ tốt với QA và Engineering
Trust đến từ stability và honesty: scope rõ, priority không đổi bất ngờ, edge cases được nói sớm, bug triage công bằng, và PM/BA không đổ lỗi khi discovery thiếu.
| Situation | Good behavior | Template sentence |
|---|---|---|
| Requirement unclear | Own ambiguity and set follow-up. | “This AC is ambiguous. I will confirm expected behavior with Ops by Thursday.” |
| Bug severity debate | Use impact, frequency, workaround, release risk. | “This affects 4 enterprise customers and no workaround exists, so I recommend P1.” |
| Scope pressure | Present tradeoffs, do not hide risk. | “We can keep date if we defer analytics; otherwise launch moves one week.” |
Build trust với Engineering Lead và Design Lead
- Bring them into problem framing, not only solution review.
- Share customer evidence and business priority before asking for estimate.
- Maintain a decision log so past tradeoffs are not re-litigated.
- Clarify decision rights: PM owns why/what, Design owns experience quality, Engineering owns technical approach, QA owns release confidence.
Thiết kế working model với Engineering/Design/Sales
| Interface | Cadence | Input | Output |
|---|---|---|---|
| PM + Design discovery | Weekly | Problems, research, constraints. | Options, prototype risks. |
| PM + Engineering refinement | Weekly | Stories, AC, dependencies. | Ready/not-ready decisions. |
| PM + Sales/CS feedback | Biweekly | Customer signals, revenue impact. | Validated requests, rejected requests, follow-ups. |
Case study: late QA involvement
A checkout feature passed development but failed UAT because refund and timeout cases were not specified. The fix was not “QA should test better”; the system fix was to add QA to refinement, require negative-path AC, and run release-risk review before code freeze.
Definition of done
- Design, Engineering and QA know the problem and non-goals.
- AC covers happy path, validation, permission, empty/error states.
- Risks and tradeoffs are visible before sprint commitment.
- Working model defines cadence, inputs, outputs and decision rights.
Ba nghề, ba định nghĩa "xong" khác nhau
| Vai trò | "Xong" nghĩa là | Xung đột sinh ra từ đâu |
|---|---|---|
| Designer | Trải nghiệm đúng như thiết kế | Engineer đổi chi tiết vì lý do kỹ thuật mà không báo |
| Engineer | Chạy đúng, không lỗi, bảo trì được | Designer yêu cầu thứ tốn gấp mười mà không biết |
| QA | Không còn ca lỗi nào chưa xử lý | Hai bên coi việc trả lại là chỉ trích cá nhân |
Phần lớn xung đột giữa ba nghề này không phải xung đột về năng lực hay thái độ. Nó đến từ việc mỗi bên tối ưu cho một định nghĩa "xong" khác nhau, và không ai nói ra định nghĩa của mình.
Ba điểm giao — làm đúng thì hết phần lớn xung đột
- Trước khi thiết kế: engineer nói cái gì rẻ, cái gì đắt. Mười lăm phút ở bước này tiết kiệm nhiều vòng sửa. Designer không đọc được chi phí kỹ thuật từ bản vẽ, và không nên phải đoán.
- Trước khi lập trình: ba bên đi qua bản thiết kế cùng nhau, tìm ca ngoại lệ. QA thường là người hỏi "nếu danh sách rỗng thì sao" — câu hỏi mà bản thiết kế hay bỏ sót.
- Trước khi trả lại: QA mô tả bằng hành vi, không bằng phán xét. "Khi nhập 51 ký tự thì nút lưu không phản hồi" thay vì "chức năng lưu bị lỗi".
Điểm thứ hai là điểm tiết kiệm nhiều nhất và hay bị bỏ nhất, vì nó trông như một cuộc họp thừa. Ba mươi phút ở đó thường tiết kiệm vài ngày làm lại.
Khi có bất đồng — cách phân xử
| Bất đồng về | Ai quyết | Nguyên tắc |
|---|---|---|
| Trải nghiệm người dùng | Designer, với dữ liệu | Nếu có dữ liệu người dùng thì dữ liệu thắng |
| Cách hiện thực kỹ thuật | Engineer | Designer nêu kết quả mong muốn, không chỉ định cách làm |
| Mức độ nghiêm trọng của lỗi | PO | QA nêu tác động, PO quyết chặn hay không |
| Đánh đổi phạm vi | PO | Cả ba nêu chi phí, PO quyết |
Quy tắc bao trùm: nêu chi phí và tác động, đừng nêu ý kiến. "Cái này tốn thêm 3 ngày" là thông tin; "cái này không hợp lý" là ý kiến — và ý kiến không phân xử được.
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Designer | Hỏi chi phí kỹ thuật sớm để thiết kế trong ràng buộc thật |
| Engineer | Nêu chi phí bằng số thay vì nói "không làm được" |
| QA | Mô tả bằng hành vi để việc trả lại không bị đọc thành chỉ trích |
| Product Owner | Bạn phân xử đánh đổi; ba bên cung cấp chi phí, bạn quyết |
| Team Lead | Bạn tổ chức ba điểm giao và bảo vệ buổi đi qua thiết kế cùng nhau |
Ví dụ — một vòng trả lại lẽ ra tránh được
Điều đã xảy ra: designer thiết kế màn hình danh sách đơn hàng với bộ lọc theo nhiều tiêu chí cùng lúc. Engineer làm xong. QA trả lại vì khi lọc 4 tiêu chí trên dữ liệu thật, trang mất 14 giây để tải.
| Bên | Phản ứng đầu tiên | Điều đang thật sự xảy ra |
|---|---|---|
| Designer | "Thiết kế có vấn đề gì đâu" | Đúng — bản vẽ không sai |
| Engineer | "Dữ liệu thật quá lớn, không làm nhanh được" | Đúng — với cách truy vấn hiện tại |
| QA | "Không đạt, trả lại" | Đúng — 14 giây là không dùng được |
Cả ba đều đúng, và vòng lặp này sẽ lặp lại. Vấn đề nằm ở chỗ không ai hỏi "bộ lọc này chạy trên bao nhiêu bản ghi" trước khi lập trình.
Ba mươi phút đi qua thiết kế cùng nhau sẽ bắt được nó: QA hỏi về dữ liệu thật, engineer nói bốn tiêu chí cùng lúc là đắt, designer đề xuất lọc theo bước thay vì cùng lúc. Kết quả: cùng một mục tiêu người dùng, chi phí kỹ thuật thấp hơn nhiều, và không có vòng trả lại nào.
Điều đáng chú ý: lời giải đến từ designer, sau khi họ biết được ràng buộc. Người thiết kế không cố tình đòi thứ đắt — họ chỉ không có cách nào biết cái gì đắt nếu không ai nói.
Definition of done
- Engineer được hỏi về chi phí trước khi thiết kế được chốt.
- Ba bên đi qua bản thiết kế cùng nhau trước khi lập trình, tìm ca ngoại lệ.
- QA mô tả lỗi bằng hành vi quan sát được, không bằng phán xét.
- Mỗi loại bất đồng có người quyết được xác định trước.
- Mọi bên nêu chi phí và tác động bằng số, không nêu ý kiến.
Tự kiểm 3 câu
Đọc xong rồi thì thử xem — đúng cả ba là đạt.Khóa học liên quan (1)
Sử dụng trong vai trò
Kiểm tra kỹ năng này
Bài kiểm tra của các khóa dạy kỹ năng này
2
Quiz
Đánh giá cuối khóa: Atomic Design và design system
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài này
3
Quiz
Kiểm tra bài 7: Quản trị design system — ai thêm, ai duyệt, phiên bản và khai tử
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài này
4
Quiz
Kiểm tra bài 5: Từ thiết kế sang code — component, thư viện và một nguồn sự thật
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài này
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.