Dev / 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 độ.
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.
Khóa học liên quan đang được cập nhật.
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.