이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프로그램 차터를 작성할 때 가장 중요하게 생각하는 것은 '이 프로그램이 무엇을 달성하는 것인지'와 '어디까지 다루는지'를 처음에 명확히 합의하는 것입니다. 나중에 범위가 늘어나면 로드맵 전체가 흔들리기 때문입니다.
팀 프로젝트에서 앱 기능 개선 프로그램의 차터를 작성했는데, 처음에 목표를 너무 넓게 적었더니 어느 기능이 포함되고 어느 기능이 이후 단계인지가 불명확해졌습니다. 팀원마다 다른 범위를 생각하고 있었습니다. 목표를 OKR 형식으로 다듬고, 포함·비포함 항목을 명시적으로 구분한 뒤에야 방향이 맞아떨어졌습니다. 실패는 차터 초안을 혼자 쓰고 공유했다가 이해관계자 의견을 반영하는 데 시간이 더 걸린 것이었습니다.
차터는 작성자의 계획서가 아니라, 팀이 합의한 기준서입니다. 그 차이가 실행 단계에서 얼마나 중요한지를 직접 경험하였습니다.
로드맵을 작성할 때 제가 가장 신경 쓰는 건 타임라인 자체보다 왜 이 순서로 진행하는지를 함께 담는 것입니다. 타임라인만 있으면 우선순위가 바뀔 때 기준이 없어지거든요.
팀 프로젝트에서 기능 개발 로드맵을 작성할 때 처음엔 날짜와 기능 목록만 나열했습니다. 중간에 팀원이 '왜 B보다 A를 먼저 하냐'는 질문을 했는데 명확히 설명하기 어려웠어요. 이후 '사용자 영향도'와 '구현 복잡성' 두 축으로 우선순위 기준을 문서화하고, 각 기능 옆에 이 기준 기반 점수를 붙였습니다. 실패는 처음부터 기준을 붙이지 않아서 중간에 방향 논쟁이 생긴 것이었어요.
좋은 로드맵은 계획을 보여주는 게 아니라, 왜 그 계획인지를 설명해주는 기준을 담는 것이라고 생각합니다.
차터와 로드맵을 작성할 때 모두 중요하게 생각하는 건 '이 문서를 보는 사람이 같은 이해를 가져갈 수 있느냐'입니다. 문서는 작성자가 아니라 읽는 사람을 위한 것이거든요.
졸업 프로젝트에서 팀의 개발 로드맵을 지도교수님께 공유했는데, 교수님이 '이 단계에서 검증이 어떻게 되는지 모르겠다'는 피드백을 주셨습니다. 팀 내에서는 당연한 걸 외부 이해관계자가 보면 다르게 보인다는 걸 알게 됐어요. 검증 체크포인트를 로드맵에 명시적으로 추가했고, 이후 피드백이 내용보다 방향 수준으로 바뀌었습니다. 실패는 처음에 팀원들한테 익숙한 용어와 구조로 작성해서 외부 독자를 고려 안 한 것이었어요.
차터와 로드맵은 작성 이후가 아니라 작성 과정에서 이해관계자를 참여시켜야 나중에 정렬 비용이 줄어듭니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SCM·공급망 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.