AI로 MVP를 생성한 후 스프린트 전에 작성하는 메모

이전에는 AI로 데모를 만들고, 그럴싸한 화면들을 본 뒤 곧바로 백로그 (backlog)를 생각하곤 했습니다. 그 도약은 너무 빨랐습니다.

이제는 NxCode를 통해 클릭 가능한 MVP를 검토할 수 있게 되면, 팀에게 스프린트 (sprint) 시간을 할당하기 전에 짧은 메모를 작성합니다. 긴 PRD (Product Requirements Document)가 아닙니다. 이 흐름이 정말로 엔지니어링 (engineering) 작업을 할 가치가 있는지 확인하기 위한 테스트입니다.

이것이 그 스키마 (schema)입니다.

1. 사용자 한 명과 실제 트리거 (trigger)

딱 두 줄만 적습니다:

• 주요 사용자
• 흐름을 활성화하는 이벤트

예시:

• 사용자: 소규모 에이전시의 운영 책임자
• 트리거: 초기 통화 후 리드 (lead)가 자격 요건을 갖춤

2. 가치를 증명하는 화면

어떤 화면이 작업이 실제로 해결되고 있음을 증명하는지 스스로에게 묻습니다.

이 경우 메인 화면이 아닙니다. 다음 항목들이 나타나는 대시보드 (dashboard)입니다:

• 담당자
• 다음 작업
• 마감일
• 상태

만약 그 화면이 여전히 장식적으로만 보인다면, 그 MVP는 아직 스프린트 (sprint)를 할 가치가 없습니다.

3. 실패해서는 안 되는 데이터

첫날부터 반드시 제대로 갖춰져 있어야 하는 필드 (field)들만 기록합니다:

• 리드 (lead) 출처
• 우선순위
• 담당자
• 마감일
• 고객의 짧은 메모

이렇게 함으로써 너무 일찍 과도하게 모델링 (modeling)하는 것을 방지합니다.

4. 데모의 허점을 드러내는 엣지 케이스 (edge case)

항상 불편한 질문 하나를 던지려고 노력합니다:

• 담당자가 없다면 어떻게 되는가?
• 날짜가 누락되면 어떻게 되는가?
• 항목이 차단(blocked)되면 어떻게 되는가?

만약 흐름이 이러한 질문 중 하나라도 견디지 못한다면, 그것은 아직 데모 (demo)일 뿐입니다.

5. 첫 번째 스프린트에서 제외할 것

이 부분이 메모가 실제로 시간을 아껴주는 지점입니다:

• 분석 (analytics)
• 알림 (notifications)
• 복잡한 권한 (permissions)
• 결제 (billing)
• 관리자 패널 (admin panel)

스프린트 (sprint) 전에 범위를 축소하는 것이 추가 화면을 만드는 것보다 훨씬 가치 있는 경우가 많습니다.

6. 핸드오프 (handoff)를 위한 마지막 문장

구체적인 한 문장으로 마무리합니다:

인테이크(intake) 보드 구축, 수동 상태 변경 및 다음 작업 구현; 권한 및 보고 기능은 첫 번째 스프린트에서 제외.

이 마무리는 결정을 내리도록 강제합니다.

저는 작업을 생성하기 전에 실제 MVP를 검토할 수 있게 해주는 NxCode를 사용하여 이 워크플로우를 테스트하고 있습니다:

https://www.nxcode.io/

AI는 검토 과정을 가속화합니다. 메모는 해당 MVP가 엔지니어링(Engineering)을 진행할 가치가 있는지 결정합니다.