Embed Size (px)
DESCRIPTION
2010년 8월 23일 KT 에코노베이션 강의
Citation preview
강사소개
현 ㈜블링크팩토리 기술이사
㈜넥슨 데브캣 2002년 첫 창업
하나대투, 미래에셋,
법무부, 이투스, 넥슨, 조선호텔, 신세계푸드 등 브랜드앱 개발
강의 난이도
영웅유닛 실무자 입문자
넘사벽
여기쯤
강의 난이도
영웅유닛 실무자 입문자
넘사벽
여기쯤
기획자 – 무언가 만들고 싶다. 프로그래머와 어떻게 이야기를 해야하지? 프로그래머 – 만들줄은 안다. 그러나 어떻게 하면 더 잘 만들 수 있지? 제대로 된 기획자를 만나고 싶다.
기획자가 되고 싶어요
프로그래머가 되고 싶어요
개발의 단계
목표설정
아이디어
범위설정
상세서술
실제구현
목표설정
디렉터의 영역
목표설정
디렉터의 영역
대부분 사장님의 영역,
또는 갑 또는 클라이언트의 영역
소규모 팀이라면 팀장의 영역
아이디어
프로젝트 참여자 또는 모두의 영역
아이디어
프로젝트 참여자 또는 모두의 영역
모두에게 가장 재미있는 시간
자기 아이디어가 받아들여 지길 바라고
어떤 아이디어는 제발 채택 되지 않길 바란다.
범위설정
프로젝트 참여자의 영역
범위설정
프로젝트 참여자의 영역
가장 많이 싸우는 부분, 각자의 이해가 걸려있다. A : 이건 무조건 되야한다.
B :이게 되려면 blah~ blah~ (과연 그럴까요, 중요한것은 프로젝트의 성공적인 런칭)
상세설정
기획자의 영역
상세설정
기획자의 영역
기획자에게 힘든 시간 기획의 범위를 알 수가 없다. 어디까지 문서로 써줘야
하지… 그냥 말로 하면 안될까
실제구현
프로그래머의 영역
실제구현
프로그래머의 영역
이 기획서 누가 썼어!!
초점을 바꾸자
꿈꾸는것은 모두의 영역 각자의 전문성으로 각자의 자리에서 꿈
을 꾼다. 기획자의 전문성은 상세설정 프로그래머의 전문성은 실제구현
기획자가 되고 싶어요
상세설정의 어려움
프로그래머는 로직 없이 일하는게 불가능 어디까지 로직을 짜줘야 할 것인가
회사마다 다름, 하지만 말그대로 최대한 상세하게 내가 기획자인지 프로그래머인지 -> 좋은현상, 같은 결과물
에 다가가고 있다.
기획자가 아무리 상세하게 설계해도 허점은 있다. 그러나 프로그래머도 실제 개발에 들어가서야 허점을 발견
하는 경우도 많음
건축물에서는 수치, IT에서는 로직
기획서는 얼마나 상세해야 하는가
커뮤니케이션 없는 상세한 기획서는 무의미 안읽음
기획서는 프로젝트 참여자가 같은 아웃풋을 상상할수있게 만든다.
중간중간 결정사항과 범위를 기술하여 방향을 잡는다.
기획자는 코딩을 배워야 하는가
간단한 스크립트 정도 짤수있다면 금상첨화
하지만 중요한건 로직과 데이터 정규화 구슬이 서말이어도 꿰어야 보배
doc와 xls가 1테라라도 정규화되어야 보배
그리고 커뮤니케이션 스킬
기획자도 개발자
로직을 모르는 기획자는 망상가가 될 수 있다. 사회는 망상가에게 월급을 지급하지 않는다. 기획은 머리로 하는것이 아니다. 해보지 않으면 알 수
없음 코드만이 결과물을 확인 할 수 있는 것이 아니다. 기획은 실험을 거쳐야 함, 실험 없는 기획은 최종 아웃
풋이 곧 테스트 결과물이 됨
건축에서는 이미 많이 하고 있음
http://www.31v.nl/2009/05/photo-prototyping/
http://www.31v.nl/2009/05/photo-prototyping/
소프트웨어는 이제 시작
(또는 아직도?)
재앙의 정의
만약 건물을 다 지었는데 엘리베이터가 빠졌다면? 화장실을 안만들었다면?
다리를 다 지었는데 마지막 10cm가 안맞는다면? 소프트웨어 개발에서는 비일비재함,
언제라도 되돌아갈수 있다는 미신 다 만들었는데 뒤로가기 버튼이 없다. Flow가 이렇게 됐다가 저렇게 됐다가 저녁은 가족들과 집에서 먹고 싶습니다. 주말엔 여행도 다니고 싶습니다.
실험을 하지 않으면…
재앙이 옵니다. 초,중,고등학교 그리고 살면서 배운 모든것을 동원해서
프로젝트에 참여한 사람들을 이해시키자
글로만 이해시킬수 있는게 아님
기획과 개발
코딩은 기계를 이해시키는 작업
기획은 사람을 이해시키는 작업
기획과 개발
코딩은 기계를 이해시키는 작업 기획과 디자인을 잘 버무려 최종 결과물을 만
들자
기획은 사람을 이해시키는 작업 모두의 아이디어를 현실화 하기 위해 검증하
고 다시 전달한다.
구현여부
대부분 구현 가능합니다. 다만 구현할 시간이 없을뿐 질문을 제대로 -> 앞, 뒤 상황에 맞게(무조건 되야하는건 없
음) 답을 제대로 해야함 -> 앞, 뒤 상황을 설명(무조건 안되는건
없음)
구현하는데 드는 시간이 감이 안잡히면 재앙이 온다. 핵심 피쳐를 정하고 개발자도 프로토타입을 만들어둬야 재
앙을 막을수있다.
실제 있었던 일…
케이크를 만들자.app
아이폰의 UX를 활용하여 케이크를 만들자 케이크 베이스도 정하고 토핑도 마음대로 올리고~ 초도 마음대로 꽂을수있게 하자. 초에 아름답게 불을 붙이고 후~ 하고 불면 꺼지고 편
지가 나오게 하자. 다만든 케이크는 다른 핸드폰에도 보내게 하자.
재앙 아이폰의 UX를 활용하여 케이크를 만들자
케이크 베이스도 정하고 토핑도 마음대로 올리고~
초도 마음대로 꽂을수있게 하자.
초에 아름답게 불을 붙이고 후~ 하고 불면 꺼지고 편지가 나오게 하자.
다만든 케이크는 다른 핸드폰에도 보내게 하자.
재앙을 방지하자
개발자의 생각 마음대로 -> 마음은 누구 기준인가.
아름답게 -> 아름다움은 누구 기준인가.
다른 핸드폰 -> 핸드폰의 범위는? 설마 기존 피쳐폰에도 보내져야 하는건 아니겠지?
토핑도 '마음대로' 올리고...
기획자 토핑은 사과랑 포도랑 인형이랑 초콜렛이랑 이곳저곳
에 놓을 수 있게...
개발자 케이크 베이스 크기가 지름 --px의 원이면 그 안에 토
핑을 올릴 수 있는건가? 레이어는 몇 겹까지 허용해야 하나? 하나의 오브젝트를 여러개 쓸 수 있는건가?
초에 아름답게 불을 붙이고 불면 꺼지고...
기획자 성냥이 나와서 치익 하면 화면이 환하게 밝아지면서 불이 켜
지는...
개발자 성냥은 어디서 꺼내나? 화면은 초 근처만 원 형태로 밝아지면
되나? 불이 켜진 후에도 계속 애니메이션이 되어야 하나? 불이 켜진 다음에는 초의 길이가 줄어들어야 하나?
코더와 기획자의 사고 차이
기획자
추가하면 좋은것 부터 상상
프로그래머
추가하려면 해야 하는것 부터 상상
실제로 찾아온 재앙 1
아름답게 초 꽂기가 쉽지 않다. 각종 토핑의 종류가 정의되지 않은 상태에
서 초의 위치 잡는것이 쉽지 않음 토핑의 종류가 확정되어도 모든 경우의 수
를 파악하여 토핑을 피해서 초를 꼽기가 쉽지 않다.
실제로 찾아온 재앙 2
초를 후~ 하고 불어서 끄기 안드로이드는 어려움
A하고 B하고 Z하면 가능할수도 있어요
흔들기로 해결 대안을 제시하자
실제 케이크의 완성
결론
로직과 정규화
실험과 커뮤니케이션
전체를 감독하는 기획자가 되자
아이디어와 창의력은 갑자기 생겨나는게 아님, 아는 만큼 나오는것
그냥 스토리보드만 찍어낸다면 연봉이 오르지 않는다. 축구감독은 축구선수 출신이어야함, 전문영역을 키우
자 프로그래밍이던 디자인이던 배우세요
좋은축구선수 ≠ 좋은축구감독
커뮤니케이션에 능한 코더가 되자
기획서를 꼼꼼히 읽자 본인은 당연하다고 생각하지만 다른 사람에겐
안 당연함 무조건 안된다고 하지 말고 기획자가 판단 할
수 있는 근거를 제공하자 그래도 안되면 대안을 제시하자
![NDC 2014 [48시간 만에 게임 만들기: '수줍은 메두사' 포스트모템과 게임 개발의 왕도]](https://img.pdfslide.tips/doc/110x75/55d55635bb61eb0b1a8b463f/ndc-2014-48-.jpg)
