시작하기 전에 멈춘 파스토 밀크런 프로젝트의 예로 살펴보는 기획

2022년 1월 진행하였던 파스토 밀크런 프로젝트 기획 관련 작업 내용을 소개드리려 합니다. 기획자로 1회 파스토와 미팅을 하였고 이때 나온 내용을 토대로 요구사항 정의서 초안, 밀크런 프로세스 가안, 기능 정의서 초안 등을 작성하였으나 중간에 엎어진 프로젝트입니다.

 

 

만남 그리고 요구사항 정의서

 

꼭 기획자라서 요구사항 정의서 초안을 작성한 것은 아닙니다. 이 프로젝트는 사전 PM으로 투입되는 것으로 진행되다 시작 전에 다른 이유로 기획자로만 투입되게 된 이유도 있지만, 일단 초안이라도 요구사항을 정리해야 그다음을 진행할 수 있기 때문이기도 합니다.

 

물론 아무도 안 하고 있기 때문도 이유 중 하나이고 일단 고객 미팅을 함께 했다는 이유도 있습니다.

 

파스토-밀크런-요구사항 정리

 

요구사항 정의서는 사정 상 전체 내용을 올릴 수는 없고 일부 내용을 모자이크 하여 올리겠습니다.

 

요구사항 정의는 모든 SI, 외주 프로젝트의 시작입니다. 돈을 받고 개발을 진행하는 것이므로 개발자나 기획자가 원하는 것이 고객이 원하는 것을 개발해야 하는 당연한 이유도 있지만 고객의 원하는 시스템을 파악한다는 의미도 있다는 점을 간과하면 안 됩니다.

 

종종 요구사항 정의와 상세화를 형식적으로 진행하거나 하지 않는 프로젝트도 있습니다. 이런 프로젝트는 개발이 진행되면 될수록 확실히 문제가 발생할 가능성이 커지는 것 같습니다.

 

반드시 명심해야 할 사항은 요구사항은 반드시 고객 관점에서 작성되어야 합니다. 자회사인 개발사나 하청에 하청으로 개발되는 국내 SI 사정 상 같은 계열사이므로 네 맘이 내 맘이라는 식으로 작성하거나, PM이 개발 관리보다는 사업 관리나 영업 측면에서 투입되는 경우도 많아 요구사항 파악 역량이 부족한 경우도 많이 있습니다.  

 

 

요구사항 정의와 고객 이야기를 토대로 메인 프로세스 정의

 

비록 미팅은 한 번 뿐이었지만 여기서 나온 이야기들과 정리한 요구사항을 토대로 파스토 밀크런의 메인 프로세스를 정리하였습니다. 

 

이 메인 프로세스를 기반으로 하위 프로세스와 기능을 정리하였습니다.

 

여기서는 가설 수준이지만 파스토 밀크런 메인 프로세스의 일부만을 보여드리도록 하겠습니다. 사정상 자료는 일부 모자이크 후 올리는 점을 양해하여 주십시오. 

 

밀크런-메인-프로세스-일부

 

많은 경우 기획자의 주 업무가 스토리보드 작업이라고 생각합니다. 그러나 이는 잘못된 것입니다. 기획자의 주 업무는 개발 대상을 분명히 정의하고 이를 어떻게 달성할지를 계획하는 것입니다. 이 과정의 마지막 산출물이 스토리보드이고, 여기에 앞선 기획 자료들이 포함되어 있기 때문에 스토리보드를 주 업무로 느끼는 것입니다.

 

이는 다르게 보면 프로세스 등 업무가 선행되어 있지 않은 스토리보드는 단지 화면 디자인에 그치게 되므로 디자인 기획에 그치게 됩니다. 이 경우 디자이너가 있는 프로젝트의 경우 기획자의 역할이 모호해집니다.

 

위의 그림에서 빨간 타원은 기능을, 빨간 네모는 파생되는 하위 프로세스를 의미합니다. 위 밀크런 프로세스가 완벽하다고 할 수는 없습니다. 단지 한 번의 미팅 후 작성된 것이기 때문입니다.

 

보통의 경우 기능 정의도 그렇게 프로세스 작업도 수 차례의 고객 심층 인터뷰 후에나 작성될 수 있습니다.

 

 

프로세스 기반 개발 기능 도출 

 

개발하여야 하는 기능은 요구사항과 프로세스를 기반해야 합니다. 때때로 해당 최신 기술이라서, 유명 기업이 사용하는 것이어서 개발하기도 하는데 이는 잘못된 것입니다. 이런 경우가 있을까 의문이겠지만 실제 개발 현장에서 심심치 않게 일어납니다.

 

파스토 미팅 후 정리한 요구사항과 이를 토대로 설계한 프로세스를 바탕으로 기능 정의서를 작성한 것을 예시로 보여드리겠습니다. 여기도 일부이고 또 모자이크 처리된 점 양해 부탁드립니다.

 

밀크런-기능정의-가안

 

위의 기능 정의는 요구사항 정의와 밀크런 메인 프로세스가 그러하듯 가안입니다. 

 

기능은 앞으로 개발할 대상이 됩니다. 이런 기능은 프로젝트의 목적을 달성하기 위한 것이어야 하고 이는 요구사항과 프로세스에 설명되어 있기 때문에 기능 정의는 요구사항과 프로세스에 종속되어야 합니다.

 

 

기획의 종류와 연습법

 

보통 기획을 시간 관점에서 보면 과정 또는 흐름, 산출물 관점에서 보면 설계라 할 수 있습니다. 이런 기획 시스템을 잘 이해하지 못하는 경우 기획을 스토리보드로 생각하게 됩니다.

 

하나의 그림이 많은 시간 수많은 스케치와 붓질로 만들어지고, 음악이 많은 음표들의 상호 관계와 흐름의 조화 속에서 아름답게 들리 듯, 서비스 기획이나 SI 기획 또한 서로 다른 설계 문서들의 상호작용으로 완성되는 것입니다.

 

단지 화면을 그린 그림이 기획서라는 인식은 지엽적이고 초보적 기획관이라 할 수 있습니다.

 

보통 기획을 화면을 나타내는 기획, 화면에 기능이 설명된 기획, 사용자 프로세스가 포함된 기획, 사용 프로세스에 작동하는 기능과 데이터의 관계가 표현된 기획으로 구분할 수 있습니다.

 

화면을 나타내는 기획은 디자이너가, 기능을 설계하는 기획은 개발자가 잘합니다. 기획이라는 용어가 기획자라 불리는 직종의 전유물은 아닙니다. 기획의 단어의 의미가 그러합니다.

 

그러므로 특정 서비스 개발을 위해 투입된 기획자는 기획 작업물을 작성하는 것이 아닌 개발의 목적 달성을 위한 기획적 사고를 유연하고 효과적으로 나타낼 수 있어야 합니다.

 

이를 위한 기본 과정이 요구사항 정의와 프로세스, 기능 정의의 흐름을 연습하는 것이라 생각합니다.