구현 및 go-live 예외
구현이 늦은 요청, dependency 또는 go-live risk를 만나면 예외는 email, ticket, call 사이로 흩어집니다. Threada는 각각을 owner, evidence, approval, audit trail을 가진 governed WorkItem으로 바꿉니다.
무엇인가
구현 또는 go-live 예외는 계획된 launch를 위협하고 happy-path checklist에 맞지 않는 모든 것입니다. 늦은 customer request, customer-side 또는 vendor-side dependency, integration blocker, 날짜가 가까워져 제기된 compliance 또는 security ask, 발견된 go-live risk, scope change가 여기에 포함됩니다. 각각은 deadline, owner, consequence가 있는 작은 decision이며, 누군가 쫓아가기 전까지 서로 다른 inbox, ticket, call에 살아 있는 경우가 많습니다. work는 실제이지만, 그 record는 보통 그렇지 않습니다.
왜 막히는가
- 01 Evidence가 email thread, support ticket, call note에 나뉘어 있어 누구도 전체 예외를 한곳에서 볼 수 없습니다.
- 02 Ownership이 불명확합니다. 절반은 customer task이고 절반은 internal task라 implementation lead, product, engineering 사이에 떨어집니다.
- 03 Product와 engineering은 요청을 committed roadmap work와 비교해 우선순위화해야 하고, 그 decision은 별도 tool에서 일어납니다.
- 04 Customer-side IT 또는 vendor dependency가 진행을 막지만, 날짜가 밀릴 때까지 기다림은 보이지 않습니다.
- 05 Decision trail이 없습니다. launch를 review할 때 누가 어떤 evidence로 언제 예외를 승인했는지 보여줄 수 없습니다.
좋은 상태란
하나의 예외를 기록 위에. 모든 필드를 설명할 수 있게.
Threada가 돕는 방식
각 움직임은 실제 플랫폼 기능에 매핑됩니다.
- 01 각 예외는 누군가의 inbox에 사는 thread가 아니라 lifecycle-managed unit of work인 하나의 governed WorkItem이 됩니다. email, form, messaging에서 들어온 intake는 typed schema가 있는 structured item으로 normalized됩니다. WorkItem
- 02 Customer request, dependency note, security ask는 item의 evidence로 attached and cited되므로, decision 뒤의 reasoning은 memory에서 재구성되는 것이 아니라 grounded하고 reviewable합니다. EvidenceBundle
- 03 한 명의 owner가 item에 assigned되고 visible해져, 예외가 implementation lead, product, engineering 사이에 떨어지지 않습니다. WorkItem ownership
- 04 Approve, defer, descope는 explicit decision step, 즉 human-review 또는 approval gate를 통과하므로, 적절한 reviewer가 sign-off하기 전에는 예외가 닫히지 않습니다. DecisionStep
- 05 합의된 next step은 connected system에서 governed action으로 실행될 수 있습니다. issue 생성 또는 업데이트, channel notification처럼 idempotency와 auditable execution record를 가진 실행이며 manual hand-off가 아닙니다. Action
- 06 모든 state change, comment, approval은 timestamp event로 capture되므로 launch review는 누가 무엇을, 어떤 evidence로, 언제 결정했는지 보여줄 수 있습니다. TelemetryEvent / audit trail
작동 예시
Illustrative scenario (not a customer story)
한 은행이 새 workflow go-live를 며칠 앞두고 있는데, security team이 original scope에 없던 추가 control을 요청합니다. 오늘날 그 요청은 email로 도착해 engineering에 forward되고, call에서 논의된 뒤, 날짜가 다가오는 동안 owner 없이 남을 수 있습니다. Threada WorkItem으로는 같은 요청이 한 번 capture됩니다. security ask는 evidence로 attached되고, implementation lead가 owner가 되며, 영향을 받는 go-live milestone과 deadline이 record 위에 놓이고, approve-or-defer decision은 explicit approval step을 통과합니다. 나중에 launch review는 예외가 어떻게 처리되었는지 정확히 볼 수 있습니다. 이름, 날짜, reasoning이 모두 record 위에 있습니다. 이것은 work의 형태를 보여주기 위한 illustrative example이며, 실제 customer가 아니고 metric도 주장하지 않습니다.