이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 4명 팀의 졸업 프로젝트에서 짧은 주기로 나눠 일하는 방식을 써본 경험이 있습니다. 그때의 실패를 말씀드리겠습니다.
저는 2주 단위로 쪼개 진행하기로 했지만, 처음엔 제가 "이번 주기에 다 못 끝냈으니 다음에 몰아서"라며 점검을 건너뛴 적이 있었습니다. 그러자 미룬 일이 막판에 한꺼번에 쌓여 무너졌습니다.
그 실패에서 저는 짧은 주기 방식은 "매 주기 끝에 결과를 꼭 확인하는 것"이 핵심이라는 점을 배웠습니다. 주기를 정해두고 점검을 미루면, 그건 그냥 막판 몰아치기와 같았습니다. 그 뒤로 저는 주기 끝마다 작더라도 결과를 확인하고 넘어갑니다. 애자일이든 어떤 방식이든, 형식만 따르는 게 아니라 주기적 점검이라는 본질을 지켜야 효과가 난다는 걸 그 실패에서 익혔습니다.
제가 팀 프로젝트에서 요구사항이 자주 바뀌는 방식으로 일해본 경험이 있습니다. 그때의 실패를 말씀드리겠습니다.
짧은 주기로 진행하니 요구가 3주 동안 세 번 바뀌었습니다. 처음엔 제가 바뀐 내용을 말로만 전했습니다. 그러자 한 팀원이 옛 요구대로 작업해, 며칠치가 헛수고가 됐습니다.
그 실패에서 저는 변화가 잦은 방식일수록 "무엇이 어떻게 바뀌었는지"를 글로 남겨야 한다는 점을 배웠습니다. 빠르게 바꾸는 것과, 바꾼 걸 흐릿하게 두는 건 다른 일이었습니다. 그 뒤로 저는 변경 사항을 날짜·내용과 함께 한 문서에 적어 모두에게 공유합니다. 유연하게 바꾸려면 기록이 더 촘촘해야 한다는 걸, 그 실패에서 익혔습니다.
제가 5명 팀의 졸업 프로젝트를 짧은 주기로 진행하며 겪은 실패를 말씀드리겠습니다.
한 주기에 제가 맡은 부분에서 문제가 막혔습니다. 짧은 주기라 시간이 빠듯했는데, 처음엔 제가 "내가 맡았으니 내가 풀어야 한다"며 혼자 끌어안았습니다. 그러다 그 주기 전체가 밀렸습니다.
그 실패에서 저는 짧은 주기 협업의 핵심은 "막히면 빨리 드러내는 것"이라는 점을 배웠습니다. 주기가 짧을수록 한 사람이 막히면 전체가 흔들리기 때문입니다. 그 뒤로 저는 막히면 다음 짧은 회의에서 바로 공유합니다. 알고 보니 다른 팀원이 비슷한 문제를 겪어본 적이 있어 금세 풀렸습니다. 협업에서 혼자 버티는 게 책임감이 아니라, 빨리 알리는 게 책임감이라는 걸 그 실패에서 익혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 그래비티랩스 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.