Team Code Zero to One

GROUND RULE

우리는 같은 목표를 가진 원 팀이며, 시행착오와 개선을 통해 합리적인 팀 문화가 꽃핀다는 것을 늘 인지한다.

팀에서 어떤 서비스나 기능을 만든다면 기대가 되고 참여하고 싶은 마음이 들도록

[ 회의 규칙 ]

회의 종류 4가지
1. **‘전체 회의’**는 스크럼 회의로 변경사항 혹은 전달 공유사항만 30분 이내로 빠르게 (토요일 오후 1시)
2. 스프린트 시작 시 스프린트 플래닝 회의 통해 성과와 목표에 근거한 다음 스프린트 개발 목록과 일정을 설정 (4주에 1번)
  - (그로스팀) 통합 PRD가 스프린트 개발 목록 결정의 근거가 됨
3. 새로운 기획이 나왔을 때 킥오프 미팅 통해 모두가 의견을 주고받으며 요구사항에 대한 이해도를 맞춤 (4주에 1번)
  - 이 때가 각 기능명세서의 초안 지점임
  - 기획 → 킥오프 미팅 → BE, 디자인 → FE 개발
4. 변경 사항, 합의 사항 등 팀 간 소통이 필요할 경우 Ad-hoc 미팅 을 적극 활용해 그때 그때 피드백을 하며 진행
  - 각 기능명세서가 지속적으로 디벨롭됨
  - 팀 별로 요청할 수도 있고 개인 별로 요청할 수도 있음
회의는 논의가 아닌 결정의 장소. 미리 슬랙에서 충분히 대화를 나누기
- 모든 회의는 슬랙에 안건 공유(하루 전) → 회의하며 회의록 작성 → 슬랙에 회의 요약(하루 이내)으로 전체에게 공유
- WHY?
  1. 회의 당사자들이 일정을 숙지하며 안건에 대해 미리 생각하고 참여해 효율성을 높인다.
  2. 타 팀에서도 회의 안건과 결과를 인지하며 각자 일정과 진행 방향성 설정에 참고할 수 있다.
  3. 회의록은 기존 멤버들도 지속 점검하며 리마인드할 뿐 아니라 온보딩하는 멤버들도 빠르게 히스토리를 파악할 수 있는 자산이 된다.

전체 스크럼 회의

격주마다 온라인 오전 11시, 오프라인 오후 12시
변경사항 / 전달 사항 공유 및 의견, 제안
팀 간 소통이 필요한 경우 전체 회의 이후 잡기

[ 팀 문화 ]

ZERO-ONE Core Rules

Mission / Vision / Core Values / Strategy (MVCS)

ZERO-ONE MVC + Strategy Pyramid (2).png
ZERO-ONE 10계명

✔ 이 기능은 내 것이다. (❌ 문서에 있어서 그렇게 개발했다 ⭕ 현재 문서에는 이렇게 되어있지만 유저 경험을 생각해보면~ )

✔ 단, 누가 새로 와도 내 기능을 완성할 수 있도록 문서화 (ex. 기획 설계 문서/기술 기록/코드 만 보고도 바로 바톤을 넘겨 받아 개발에 착수할 수 있도록)

✔ 학습 과정도 개발의 일부! 스터디한 것은 팀에게 기술 전파하며 함께 성장합니다. (기술적 의사 결정, 기술 기록 적극 활용)

✔ 의견은 선 존중 후 제안 (일리가 있습니다만~ 저는 생각이 다른 부분이~)

✔ 토론은 집요하게 (의견 대립은 좋은 서비스라는 공통 목표를 향한 열정. “아까 너무 세게 말한거같아요ㅠㅠ” 마음 표현하기)

✔ 잡담을 많이 나누는 것이 경쟁력이다.

✔ 일의 목적, 기간, 결과, 공유자를 고민하며 일한다.

✔ 모든 일의 궁극적인 목적은 ‘고객 창출’과 ‘고객 만족’이다.

✔ 이끌던가, 따르던가, 떠나던가 (모든 상황이 배움과 성장 기회이며 레퍼런스이자 자산이 된다. 아닌 것 같다면 제안하고, 이견이 없다면 따르고, 다 맘에 안 들면…. 음… 슬퍼요🥲)

✔ 작업 완료 시 슬랙에 공유하여 모두에게 동기화하기 (확인 시 ✅)

프로젝트 진행 프로세스 4.0 (Outdated)

회의 종류 4가지
1. 전체 회의는 스크럼 회의로 변경사항 혹은 전달 공유사항만 30분 이내로 빠르게 (토요일 오후 1시)
2. 스프린트 시작 시 스프린트 플래닝 회의 통해 성과와 목표에 근거한 다음 스프린트 개발 목록과 일정을 설정 (4주에 1번)
  - (그로스팀) 통합 PRD가 스프린트 개발 목록 결정의 근거가 됨
3. 새로운 기획이 나왔을 때 킥오프 미팅 통해 모두가 의견을 주고받으며 요구사항에 대한 이해도를 맞춤 (4주에 1번)
  - 이 때가 각 기능명세서의 초안 지점임
  - 기획 → 킥오프 미팅 → BE, 디자인 → FE 개발
4. 변경 사항, 합의 사항 등 팀 간 소통이 필요할 경우 Ad-hoc 미팅 을 적극 활용해 그때 그때 피드백을 하며 진행
  - 각 기능명세서가 지속적으로 디벨롭됨
  - 팀 별로 요청할 수도 있고 개인 별로 요청할 수도 있음
문서 종류 3가지
- 통합 PRD
  - 현재 서비스의 핵심 가치, 유저 저니맵, 유저 페르소나, IA, 팀의 MVC, 각 스프린트별 OKR과 성과 등을 한 눈에 알 수 있음
- 스프린트 플래닝 회의록
  - 이전 스프린트 성과가 무엇이었고 이번 스프린트에서 무엇을 개발할 지 정리하는 문서
- 기능명세서
  - 각 기능에 대해서 모든 팀원이 참고할 만한 명세서. 기획 의도부터 개발 요구사항까지 담음

* NEW PROCESS

0. 그로스팀에서 통합 PRD를 관리하며 프로젝트 전체 현황판으로 현재위치 얼라인
       ↓
1. 스프린트 전 **스프린트 플래닝 회의**에서 성과와 목표, 개발사항을 정의
       ↓
2. 모든 팀원이 기획 **킥오프 미팅**시 참여해 피드백을 주고 받으며 **기획에 대한 이해**를 맞춤 (기능명세 start)
       ↓
3. Jira Story(신규)스프린트 작업 트래킹
       ↓
5. Story 하위 업무로 백엔드 API 개발, 디자인 진행 (모두 완료시 Story는 In Review 상태)
       ↓
6. 디자인 이후에는 **전체 디자인 피드백** 진행
       ↓
7. Story 하위 업무로 프론트엔드 개발 진행 (모두 완료시 Story는 In Review 상태)
       ↓
8. 고민 지점 혹은 변경 사항 발생시 슬랙 @멘션 혹은 **Ad-hoc 미팅**을 요청해 피드백 및 합의를 진행하며 함께 해결 (기능명세 update) / (보류) Jira에 논의내용을 comment로 관리해 왜 이걸 하는지 모두가 이해
       ↓
9. QA가 인수조건을 확인하고 Story를 Done 상태로 바꾸면 완료
       ↓
10. QA는 이를 참고해 TC 로도 등록하기 (향후 코드 품질관리)
       ↓
11. 운영 환경 배포
       ↓
12. 버그 발생시 Report(에러) 작성
       ↓
13. Jira 이슈별 담당자 관리

* 베타테스트 이전 - 1차 2차 MVP (사실상 워터폴)

1. 아이디어 제안 (Slack - `아이디어-잡답-소통방` 제안 취합하여 **IA 및 Flowchart** 작성)
       ↓
2. 기획 설계 (**Jira - Story 를 통해 요구사항정의서 작성**)
       ↓
3. 기획 고도화 **(figma 화면정의서 + userflow**)
       ↓
4. 기술 문서화 (기획자가 fimga에 description 으로 기능명세, 필요할 경우 노션에 정책 문서 추가)
       ↓
5. 기술 설계 (BE: ERD/swaggerAPI/fimga / FE: API명세)
       ↓
6. 개발 (Github, PR → 코드리뷰)
       ↓
7. 배포 및 테스트, 회고

역할	주요 작업 흐름
Core	각 Sprint 내) 핵심 기능 개선 및 구현, 코드 품질 유지보수
DE	Figma UI 디자인
BE	ERD, API 설계 → GitHub 개발
FE	화면정의서, 기능명세서 컨펌 → GitHub 개발
QA	인수기준 관리, TC 작성 및 관리, Jira Story & Report 티켓 관리
Growth	각 Sprint와 별개) 가설 설정 → 기획·디자인 → 개발 리소스 분배 → QA(Test Charter) → 배포 → 유저 데이터 수집 → 인사이트 도출
기획	IA, Flow Chart, Wireframe, 화면설계서, 기능명세서 작성 → Jira Story 티켓 + 인수기준 작성
전체 팀	Discord 회의 / Slack 커뮤니케이션 / JIRA 관리 / Notion 문서화 ⭐팀 내 기술, 아티클 전파⭐

[ 팀 History ]

📚 팀 프로세스 발전 히스토리

[프로세스 4.0] - 현재
- 스프린트 플래닝 회의, 킥오프 회의, Ad hoc 회의 등으로 기획에 대한 이해를 맞추고 피드백 루프 형성
- 기능명세서 도입으로 최신 기획 사항 추적, 각 팀 피드백 루프 형성
- 그로스팀 통합 PRD 운영으로 가설 검증 지표 실시간 모니터링 (추후 PPT화해 피치덱, IR자료로 활용)
- JIRA comment 활용도 높여 개선사항에 대한 모두의 공감대 형성 및 기획 이해도 향상
[프로세스 3.0] - 베타테스트 성공 후
- Story 중심의 스프린트 단위로 개발
- 디자이너, 개발자가 완료 시 Done 처리를 하며 슬랙에 완료 공유
- Sub task가 모두 완료되면 Story는 In review 상태로 전환되며 QA가 확인 후 Story를 Done 처리를 하면 모든 스프린트가 완료
- 회의록 및 작업 전후로 슬랙 통해 공유하는 것을 강조
- 모각코 활성화
[프로세스 2.0] - 베타테스트 실패 후
- Cam, Mic ON 으로 비언어적인 소통도 함께합니다.
- 모든 팀원은 작업에 데드라인을 정하고 팀장님이 이를 관리합니다.
- JIRA 의 활용도를 높여 에자일(1.5차)과 워터폴(1.5차)을 동시에 대응합니다.
- QA 담당자가 매주 문서를 업데이트하며 코드 품질을 관리합니다.
[프로세스 1.0] - 초기
- 전체회의는 의논이 아닌 결정을 하는 자리. 논의는 슬랙 등으로 충분히 진행합니다.
📕 팀 연혁

2025.09 - 1차 런칭 (1:1스터디)

2025.11 - 2차 런칭 (그룹스터디)

2025.12 - 3차 런칭 (프리미엄 멘토링)

2026 - 정식런칭 (외주)

팀원 (이쁘게 꾸며주시면 ➕)

원본 DB 👉

성 가나다순

제목 없음