기획 실무 칼럼 30편
발주 준비
-
오픈 날짜부터 정하면 기획이 무너지는 이유
오픈 날짜를 먼저 박아 두면 기획은 그 날짜에 맞춰 잘려 나갑니다. 날짜보다 범위를 먼저 정하고, 거꾸로 일정을 세우는 순서를 정리했습니다.
읽기
-
개발사 견적을 같은 기준으로 비교하는 법
개발사 견적은 금액만 놓고 비교하면 틀리기 쉽습니다. 같은 화면설계를 주고 받아야 금액 차이가 비교할 수 있는 차이가 됩니다.
읽기
-
견적 받기 전에 화면 목록부터 정하는 이유
같은 서비스를 물었는데 견적이 크게 갈라지는 건 개발사가 서로 다른 화면을 상상했기 때문입니다. 견적 전에 화면 목록부터 정하는 방법을 정리했습니다.
읽기
-
납품받을 때 화면설계로 확인하는 법
납품 검수는 앱을 둘러보는 일이 아니라 화면설계와 한 장씩 대조하는 일입니다. 화면 목록을 체크리스트로 바꿔 확인하면 빠진 화면과 다르게 만든 부분이 보입니다.
읽기
-
개발 중에 바꾸고 싶을 때 지켜야 할 순서
개발 중 변경은 막을 수 없습니다. 바꿀 내용을 화면설계에 먼저 고치고, 영향 범위와 일정을 확인한 뒤 개발사에 넘기는 순서를 지키면 비용과 일정이 덜 흔들립니다.
읽기
-
계약서에 개발 범위를 적어 두는 법
계약서의 개발 범위는 기능 이름 몇 줄이 아니라 화면 목록과 화면설계를 붙여 정하는 것이 안전합니다. 무엇을 만들고, 무엇을 만들지 않는지가 문서로 남아야 다툼이 줄어듭니다.
읽기
-
개발사 첫 미팅에서 꼭 물어볼 것
개발사 첫 미팅에서는 금액보다 일하는 방식을 물어야 합니다. 누가 기획을 보는지, 바꾸고 싶을 때 어떻게 하는지, 무엇을 넘겨받는지를 확인하면 맞는 곳을 고르기 쉽습니다.
읽기
-
정부 지원사업 일정에 맞춰 기획 문서 준비하기
정부 지원사업은 신청서, 협약, 개발, 결과 보고까지 일정이 정해져 있습니다. 기획 문서를 그 일정에 거꾸로 맞춰 준비해야 개발 기간이 모자라지 않습니다.
읽기
-
예산이 정해져 있을 때 범위를 맞추는 법
예산이 정해져 있다면 기능을 깎기 전에 화면 목록부터 만들고, 화면마다 꼭 필요한 정도를 낮추는 순서로 맞춥니다. 금액보다 범위를 먼저 고정해야 품질이 덜 흔들립니다.
읽기
-
1차 오픈 범위를 줄이는 기준
1차 오픈에는 사용자가 처음 와서 목적을 한 번 이루는 흐름만 남기면 됩니다. 그 흐름에 없는 기능은 아무리 좋아도 다음 차례로 미룹니다.
읽기
-
개발사에 처음 보낼 요청서 한 장 쓰는 법
처음 보내는 요청서는 길 필요가 없습니다. 누가 쓰는지, 무엇을 하는지, 이번에 어디까지 만드는지를 한 장에 적으면 개발사가 같은 그림을 보고 답을 줍니다.
읽기