⭐ 인사이트

🔔 킥-오프와 회고하기

프로젝트를 망치지 않기 위한 ‘시작과 정리의 기준’

구분	PM 관점 핵심
킥오프	목표·범위·일정·역할을 초기 기준선으로 고정하는 의사결정 장치
왜 필요한가	이해관계자 간 해석 차이·속도 차이를 초반에 줄이기 위함
실무 포인트	“무엇을 할지”보다 “왜 지금 이 범위인가”를 합의
리스크	일정 압박 상황일수록 구두 합의 → 누락 → 재작업 발생
PM 역할	방향 제시자 + 결정사항 기록자

킥오프는 회의 이벤트가 아니라, 이후 모든 판단의 기준점을 만드는 행위다.
초기 합의가 흐릿할수록, 프로젝트 중후반에 커뮤니케이션 비용이 기하급수적으로 증가한다.

회고는 잘잘못을 가리는 시간이 아니라, 다음 프로젝트의 의사결정 정확도를 높이는 장치다.
Keep / Problem / Try 구조는 감정 배출보다 행동 단위의 개선안 도출에 초점을 둔다.
중요한 것은 “누가”가 아니라, 어떤 조건에서 문제가 반복되었는가

💡 질문 : 킥오프에서 ‘일정’보다 먼저 합의되어야 할 것은?

• 프로젝트의 목표와 배경, 설계 이유, 배경, 근거 등에 대한 팀원 모두의 인지
• 이유 : 목적에 필요한 개념들이 들어가야합니다. 팀원 모두의 동의는 어렵지만, 동기부여는 될 수 있도록 !
• 프로젝트에 따라 추가 요소 : 목적, 기대 효과, 타깃 정보, 실행 방향(전략), 예산

🔔 공유는 어디까지가 적절한가

현업에서의 ‘공유 범위’와 ‘의사결정 기준’이 사용자 경험에 미치는 영향

구분	핵심 요지
공유의 출발점	여러 팀이 하나의 결과를 만들지만, 판단 기준은 서로 다름
충돌 지점	성과 중심 조직 vs 구현 안정성 조직
결정 구조	기술 선택 이전에 “누가, 무엇을 기준으로 결정하는가”가 불명확
결과	설정값 하나가 전 플랫폼 UX 이슈로 확대
본질	기능 문제가 아닌 공유·판단 구조의 문제

💡 질문: 사용자 경험에 직접적 영향 요소는 어디까지를 ‘전사 공유’ 대상으로 삼아야 하는가?

• 개인일정도 공유하는 것을 보아서, 오히려 사용자 경험에 직접 영향을 주는 것은 사소한 것이라도 유관부서의 공유가 필요해보입니다. 나중에 회의를 하여 개선점이 생기거나, 혹은 개선이 완료한 경우에도 히스토리로 남겨두면 더 좋을 것 같습니다.

🔻
프로젝트 실패의 원인은 실행이 아니라, 초기에 무엇을 기준으로 결정하고 어디까지 공유할지 합의하지 않은 구조에서 발생한다.