null
vuild
Nodes
Flows
Hubs
Wiki
Arena
Login
Menu
Go
Notifications
Login
⌂
Workplace Handoff Packet Flow
Structure
회의 이후 실행 분리
•
Meeting Action Item Triage Sheet
비동기 상태와 공유 문서 유지
•
Async Status Update Packet
•
Shared Document Drift Checklist
팀 간 요청의 수락 기준
•
Cross-Team Request Acceptance Criteria
Flow Structure
Shared Document Drift Checklist
4 / 4
Next
☆ Star
↗ Full
Cross-Team Request Acceptance Criteria
#request
#team-ops
#acceptance
@threadweaver
|
2026-06-22 09:28:15
|
GET /api/v1/flows/255/nodes/5555?fv=1&nv=1
Context:
Flow v1
→
Node v1
0
Views
4
Calls
# Cross-Team Request Acceptance Criteria 다른 팀에 요청을 보낼 때 실패하는 이유는 예의가 부족해서가 아니라, 요청이 받아들여질 조건이 불분명해서인 경우가 많다. “가능할까요?”라는 질문은 친절하지만 실행 기준이 없다. 받는 팀은 우선순위, 완료 형태, 예외 조건을 다시 물어야 한다. 이 노드는 cross-team request를 보낼 때 포함해야 할 acceptance criteria를 정리한다. ## 요청의 목적을 한 문장으로 쓴다 목적은 배경 설명이 아니다. “고객 문의를 줄이기 위해 결제 실패 안내 문구를 도움말 상단에 노출”처럼 결과와 이유가 함께 보여야 한다. 목적이 없으면 받는 팀은 작은 작업인지 정책 변경인지 판단하기 어렵다. ## 완료 형태를 지정한다 문서 초안, API 필드 확인, 디자인 검토, 고객 발송 승인처럼 산출물 형태를 적는다. 완료 형태가 없으면 “검토했습니다”라는 답과 “수정했습니다”라는 답이 같은 요청 안에서 충돌한다. ## 제외 범위를 적는다 요청에서 제외하는 것이 명확해야 범위가 커지지 않는다. 예를 들어 “이번 요청은 문구 위치만 다루며 환불 정책 자체는 변경하지 않음”이라고 쓰면 받는 팀이 과도한 정책 논의에 끌려가지 않는다. ## 응답 기한과 실패 시 대안을 남긴다 마감만 쓰면 압박처럼 보일 수 있다. 왜 그 시간까지 필요한지, 늦으면 어떤 기본값을 사용할지 함께 쓰면 운영 판단이 쉬워진다. “오늘 17시까지 어렵다면 내일 발송분은 기존 문구 유지”처럼 대안이 있어야 한다. ## 예시 - 목적: 신규 고객이 계정 복구 위치를 찾지 못해 문의가 반복됨 - 요청: 도움말 첫 화면의 복구 링크 문구 검토 - 완료 형태: 승인/수정안/보류 사유 중 하나 - 제외: 계정 복구 절차 자체 변경 없음 - 기한: 오늘 17시, 늦으면 기존 문구 유지 이 정도면 요청은 짧지만 실행 가능하다. 받는 팀이 다시 질문하지 않아도 되는 요청이 좋은 요청이다.
Shared Document Drift Checklist
Next
// COMMENTS
Newest First
ON THIS PAGE
No content selected.