: 0으로 끝나는 디데이는 항상 막연함과 설레임을 함께 준다.
질문: 내 팀장 운영서에 어떤 점이 문제였을까?
1. 잘한 지점
A. 협업을 역할이 아니라 의사결정 구조로 설계함
B. 프로젝트 목적을 경험 설계까지 확장함
C. 팀장 권한을 줄이고 PM 권한을 분산함
D. QA를 후반이 아닌 초기 검증 설계로 포함함
E. 기록을 회의록이 아니라 지식 자산 축적으로 정의함
2. 못한 지점
A. “정의/철학/프레임”이 먼저 나온다
B. 규칙 문장에 ‘고정’ 느낌이 많다
: 같은 내용도 “관리자가 시스템을 깔았다” 인상
C. ‘지금 당장 우리가 해야 할 행동’이 늦게 나온다
: “왜”를 충분히 설명한 뒤 “어떻게”가 나왔음
3. 다른 팀원을 보며 배운 것
A. ‘사람이 먼저’ 들어온다.
: 같은 규칙을 말해도 “관리”가 아니라 “운영”으로 들림
B. 의사결정이 아니라 ‘운영 루틴’으로 제시한다
: 전형적인 “이대로 하면 오늘부터 굴러감” 패키지라서 즉시성이 큼
C. 문서가 “선언”이 아니라 “가이드” 톤
: 강한 규정이 아니라 여지를 둔 문장이 많음
D. 디테일은 많은데, ‘읽는 순서’가 단순함
: 일정 → 내 스타일 → 규칙 → 역할 → 예시 일정 → 양식
4. 다음에 시도할 가치
A. 맨 위에 “나의 스타일” 같은 완충 문장 2줄만 추가
: 팀 운영은 통제가 아니라 ‘작업이 편해지게 만드는 가이드’로만 두겠습니다.
B. 발표 순서를 “왜”가 아니라 “오늘 어떻게 굴릴지”부터 설계
: 무엇을, 언제, 어떻게, 누가 할지
C. 단어 바꾸기
“원칙/규칙/기준” → “가이드/약속/제안”
“유지합니다” → “가급적 유지해요(필요하면 조정해요)”
“개입” → “정리/중재”
D. “같은 내용을” 더 가볍게 들리게 하는 한 줄 트릭
: “제가 정한 룰이라기보다, 이번 주에 우리 팀이 덜 지치려고
임시로 잡아본 초안이에요.”
[Chapter.5-2] MVP 프로젝트
최소한의 기능을 갖춘 제품을 만들어 가설을 실제 검증해보는 경험
Keep
Problem
Try