지난, 9월 28일 회의과정에서는 앱의 초기 기획안으로부터 Use-case 및 핵심 개념을 도출하게 되는 계기가 되었습니다.

이후, Rom(다른 팀원)님이 이슈관리 시스템에 올려주신 기획내용에 대한 추가 정리가 있었고, S님(기획자)께서는 액슈어라는 기획툴을 이용하여 스토리보드를 작성해주시고 계십니다.

어느정도 마무리가 되어가는 중, 고민거리가 생겼습니다.

그것은 바로 "디자인" 입니다.

현재, 저희 팀원 중에 디자이너는 없으며 또한 포토샵을 다룰 줄 아는 분이 없습니다.

(다룰 줄 모르면, 지금부터 배우면 되는 것이 아닌가? ㅡㅡ^)

이 사실은 추 후 앱 개발에 있어서, 아이콘 하나하나를 모두 구글링해서 찾아야함을 의미합니다.

구글링을 하더라도 배경이나 색감이 안맞으면 그림의 떡입니다. ㅜㅡㅜ

오늘 살펴 볼 주제는 무려, "포알못(포토샵을 알지 못하는 사람)이 아이콘 만드는 법" 입니다. 

제 개인적인 기준에서는 포토샵은 사실 디자이너나 퍼블리셔의 전유물이라는 편견이 조금 있습니다.

물론 다재다능한 분들은 잘 사용할 것이고, 시간만 충분하다면 저희들 중 누구라도 포토샵을 조금만 공부해서 할 수는 있겠지만 귀찮고 개발시간도 부족할 것 같습니다.

이럴 때 우리는 많은 직군들이 다룰 줄 아는 국민 툴인 PPT(파워포인트)로 아이콘을 만들 수 없을 까라는 고민을 하게 되었고, 이를 통해 아이콘을 제작할 수 있음을 깨달았습니다.

PPT 의 장점은 아래와 같이 많은 도형들을 제공해준다는 것입니다.

대부분 저희가 보는 아이콘들은 이 도형들로 제작이 가능할 것이란 생각이 듭니다.

또한 한가지 더 살펴볼 것은 구글의 디자인 색 가이드입니다.

구글 색 - 디자인 가이드

이 두 가지를 이용하여, 우리는 멋진 아이콘들을 제작할 수 있을 것 같습니다.

이번 포스팅에서 샘플로 만들어 볼 것은 게시판을 나타는 햄버거 목록 아이콘을 제작해 보려 합니다.

일단, PPT 에서 제공하는 도형들을 이용하여 아래와 같이 배치를 해줍니다.

요즘 좋아진 PPT 는 정말 좋아져서, 간격까지도 다 재줍니다.

아이콘의 배치가 다 끝났다면, 구글 색 가이드에서 원하는 색을 스크린 샷으로 찍습니다.

꼭 구글 색 가이드가 아니더라도, 원하는 색이 있다면 캡처를 시도합니다.

이렇게 찍은 스크린샷을 PPT 에 붙여넣고, 도형의 색을 우리가 원하는 색으로 맞춰줍시다.

PPT 의 색 피커를 이용하면, 쉽게 색을 맞춰 줄 수 있습니다.

이렇게 색을 맞춰줬다면, 모든 도형을 선택하고 그룹핑을 시켜줍니다.

이제 그룹핑된 아이콘을 [선택 -> 마우스 오른쪽버튼]을 누르고, 그림으로 저장을 눌러 줍시다.

그럼, 짜잔!

배경이 없는 우리가 원하는 PNG 아이콘이 생성되었습니다. 

사실, 전문적인 간격, 크기, 해상도에 따른 아이콘 배치 등의 모든 가이드가 맞춰지면 가장 베스트하겠지만, 열악한 환경이고 당장 급하다면 이 방법이 도움이 될 것이란 생각이 드네요. ㅎㅎ

이상, 오늘의 기획일지도 마무리입니다. ^^

2017년 9월 28일 기획일지 

지난, 9월 26일 회의[아이디어 재점검]에서는 앱에 필요한 아이디어들은 대부분 확정이 되었습니다.

이 날의 회의가 궁금하다면, 아래 포스팅을 참고 :-)

이와같이 아이디어 재점검이 마무리될 때 쯤 새로운 동료가 생겼습니다.

Developer 로만 구성되었던 팀에 전문적으로 기획을 해주시는 분이 참여를 하게 되었습니다.

(나름, 팀의 밸런스가 맞춰지는 느낌이 듭니다. @.@)

이에따라, S님(편의 상, 계속 기획자님이라고 하기가... ^^; 이 분의 이니셜을 인용...)에게 현재의 기획 상태 및 정리 상황을 브리핑하게 되었습니다. 

"이미 확정이 되었으니, 이렇게 갑시다." 보다는 우리의 요구사항과 현재 프로젝트의 진행도는 이 정도임을 알리고, 전문적인 S님의 의견을 듣고 싶었습니다.

이에 따른 피드백은 간단하지만 묵직했습니다.

이에 따라 업무시간을 마치고, 리소스에 대한 정리 및 스토리 보드를 작성하는 회의를 가지게 되었습니다.

이 날 회의에서는 앱 개발을 위한 리소스의 정리와 개념 정의 및 앱 사용 시나리오를 구상했습니다. 

1. 리소스 정리와 개념 정의

S님의 피드백 내용에 따라 가장 먼저 해야할 것은 기획의 정리였고, 앱의 목표를 먼저 다시 그려보는 계기를 가지게 되었습니다.

기존 기획안에는 개발목표라는 항목이 존재했고, 이를 정리해보았습니다.

기존의 개발목표는 아래와 같았으며, 

이에 대한 구체적인 세부기능들을 회의 전까지 아래와 같이 준비를 했었습니다.

이 안에서, S님의 주도하에 리소스들을 특정 카데고리로 나눠보는 작업을 하였습니다.

앱의 요구사항에 따라 사용자 측면(개인과 관리자)으로 분리하고, 각 사용자 관점에 따라 위에서 도출한 세부기능들을 추가해봤습니다.

이 과정을 통해, 관리자와 개인 사용자라는 개념 도출 및 관점에 따른 기능 명세를 분류에 맞게 정의할 수 있었습니다.

이제는 앱 사용 시나리오를 살펴보면 좋을 것 같네요. ㅎㅎ

2. 앱 사용 시나리오에 따른 스토리보드

다음, 살펴볼 내용은 앱 사용 시나리오에 따른 스토리보드 입니다.

(원래는 S님께서는 혼자해도 된다고 했지만, 블로그 포스팅 및 혼자 끌어가는 것을 방지하고자 같이 참여했습니다. ^^;)

스토리보드 작성은 다같이, 종이 몇장 깔아두고 아래와 같이 진행을 했었습니다.

(빈약한 것 같지만, 원래 이런작업은 아날로그가 최고입니다. ㅋㅋㅋ)

이 과정에서는 개인과 관리자의 앱 사용 시나리오를 구상하였으며, 조금 더 상세 개념을 도출했습니다.

세부적인 기능에 대한 고민 중, 그룹이라는 개념이 한 개 더 생겼으며 그룹에는 마라톤을 진행 이벤트를 등록한다는 유즈케이스(use-case) 를 뽑아냈습니다.

중요한 것은 사용자에 따라 어떤 유즈케이스가 생기는 지를 파악하는게 중요합니다.

이에 따라 마라톤 행사 및 아젠다 등 관리적인 측면에 대하여 관리자가 그룹에 이벤트를 등록을 하며, 사용자가 기록이나 기타 게시물을 이벤트에 따라 기록할 수 있다는 시나리오와 함께 아래와 같은 스토리보드를 작성하게 되었습니다.

큰 뼈대는 제작이 되었고, 그에 따라 공지 사항 앨범 공유 등 부가적인 기능을 넣기가 더 쉬워진 듯합니다.

이 때 주의할 점은 부가기능을 넣기가 쉽다고 하더라도, 너무 많이 넣으면 프로젝트가 비대화가 될 수 있다는 점입니다.

오늘 회의에서는 요구사항에 대한 정리와 구체적인 기능 명세가 나온 듯 합니다.

일정과 자원 등 현실적인 면에서 기능과 우선순위를 고려해보았고, 이에 따라 S님께서는 플로우 차트를 먼저 작성해주시기로 하였습니다.

플로우 차트는 아래 주소에서 확인이 가능합니다.

[마이톤 기획노트 : http://xbu1aq.axshare.com/#g=1&p=4gram_기획노트]

아직까지는 프로젝트가 잘 진행이 되는 것 같습니다. 느낌상... ㅎㅎ

꼭 성공적으로 마무리가 되었으면 좋겠네요. @.@

다 같이 파이팅 합니닷!!

2017년 9월 26일 기획 일지

제품을 출시하기 위해 해야할 가장 첫 번째는 역시 아이디어 검토인 듯 합니다.

잘 팔릴 제품이나 사용성에 좋은 제품을 찾아내야, 실제로 소프트웨어를 제작 후 "상처뿐인 영광"이 되는 상황을 방지할 수 있겠죠..

위의 취지에 맞춰, 4-GRAM(팀 이름)에서는 한달동안 진행할 프로젝트로 마라톤과 SNS 를 융합시킨 어플리케이션을 제작하려 하고 있습니다.

사내에서 진행하는 대회이기 때문에 사내에 도움이 되는 프로젝트가 좋지 않을지에 대한 생각이 들었고, "나눔" 활동을 지향하는 귀사에서 매년 2회 진행하는 마라톤 행사가 저희의 타겟이 되었습니다.

마라톤 행사에 대해 많은 것을 생각해보니 대회 전 연습 행사부터 본 행사까지 "익숙해진 불편함" 들이 많이 있었으며, 꽤 많은 기능을 제공해 줄 수 있을 것이란 생각이 들었습니다.

아이디어의 실효성에 대한 많은 토의가 있었으며, PPT 를 아래와 같이 브레인 스토밍에서 나온 모든 것을 정리하고 있습니다. 

하지만 이를 아무렇게나 정리하기 보다는 정해진 양식에 따라 한 번 작성을 해보자는 생각이 들었습니다.

특정하게 정해진 목차를 기술하고, 그에 따라 살을 붙이면 정리가 낙서가 되는 것을 방지할 수 있지 않을까 에 대한 생각이 들더군요.

이를 위해 아이디어 실효성에 대한 면이 부각, 기술적인 스택, 어필할 수 있는 요소를 찾아보며, 우리가 개발해야할 최종 꼴이 무엇인지를 정리할 필요가 있다는 생각이 들었습니다.

이렇게 정해진 목차는 다음과 같았습니다.

각 목차는 기획 단계에서 꽤 괜찮은 정리를 할 수 있었습니다.

1-2. 선정배경 & 개발목적

앞써, 언급한 이 어플리케이션 의 당위성, 실효성을 검증하기 위한 여러 생각을 할 수 있게 생각했습니다.

선정배경이 제대로 작성 되야 "상처뿐인 영광"이 되지 않을 것 같네요...

3. 기술 동향

벤치마킹 단계였습니다. 

마라톤 앱을 많이 안써봤기 때문에 여러 어플에 대한 조사를 많이 해봤으며, 특히 디자인면에서 많은 참고가 되었습니다.

이 단계에서는 아마 경험없는 저희같은 스타트업의 많은 교보재가 될 것으로 예상 됩니다.

(마라톤 앱이 보통 지도를 많이 사용하는데, 지도를 사용하는 어플도 이쁜 UI 를 작성할 수 있다는 것을 깨닫게 되었네요. ㅎㅎ)

4. 개발 목표

저희가 제작할 어플리케이션의 꼴입니다.

꼴이 있는 것과 없는 것은 소프트웨어 제작에서 정말 큰 차이를 둔다고 생각하고 있으며, 1순위로 제작해야 하는 필수적인 기능 들을 정리해볼 수 있는 기회였습니다.

5. 프로젝트 어필 홍보

전략적인 사고로 어떻게 하면, 상을 받을 수 있을지에 대한 고민입니다.

사실상 저희에게 가장 중요한 면인데, 실무라고 한다면 어떻게 물건을 팔지에 대한 고민이 되겠군요.

7. 피드백

여러 사람이 회의를 하기 때문에, 각 사람들이 생각지 못한 결론은 많이 등장 하는 것 같습니다.

특히, 기존 목차에서는 "기능 소개" 라는 부분이 없었는데, 이에 대한 지적이 매우 적절 했었습니다.

언제나 마지막 목차에는 각 회의록에 대한 피드백이 있어야 할 것 같습니다. ^^;

1회 차 회의의 정리 내용은 이와 같았습니다.

정리해준 모든 자료들에 대한 내용인 [ESC 개발기획서 - 가칭 마이톤 (버전 0.2)] 를 이 곳에 첨부합니다.

첨부 : [ESC 개발기획서 - 가칭 마이톤 (버전 0.2)]