읽어 보기 (5)
-
어느 기획자의 체크리스트
업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라 특히, 모바일을 중심 서비스가 증가하는 만큼 모바일에서 서비스를 이용하는 경우가 많다. 작은 화면에서 여러가지 기능을 수행하면, - 사용자가 사용하기 힘들뿐더러 컨트롤(사용)도 힘들기 마련이다. - 코치형 가이드가 마구마구 추가되어 복잡하게 될 수도 있다. - 복합한 UI이나 기능은 사이드 오류를 양산하기도 한다. 특히 우리는 ..
-
어느 기획자의 개발 이해하기
기획하는데 개발을 왜 알아야 하죠?? 라고 생각하는 사람이 아직도 있는지 모르겠지만, 혹시 모르는 마음에 기획자도 알아두면 좋은 지식에 대해 다루어 본다. 개발은 SW가 만들어지는 모든 과정을 통칭하는 용어로, 기획자는 개발을 알아야 한다. 단, 코딩을 알 필요는 없다. 이런 것들이 기획자가 범하는 가장 많은 오류이다. 이런 것들 => 용어의 잘 못된 이해 1. 개발 (Software Development) SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 운영까지의 모든 단계를 일컫는다. 즉, 요구사항 > 설계 > 구현 > 검증 > 운영 의 모든 프로세스를 포함하고 있다. 그럼 기획자는 각 단계별 어떤 업무를 수행하는지 확인하고 왜 개발을 알아야 하는가를 이해하면 된다. 첫 번째로 기획자..
-
어느 기획자의 PM 업무
SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다. 물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다. 나는 내부 SW 개발 프로젝트를 참여하면서 그 누구도 그것을 하는 사람을 보지 못했다. 다들 운영을 하고 있던 프로젝트라 신경을 쓰지 않았던 부분이 컸을 것이라 생각한다. "프로젝트 헌장" 이것에 대해 말하고자 한다. 프로젝트 헌장은 어떠한 프로젝트를 진행할 것이며 그에 따른 책임과 권한 등 모든 내용이 수록되어 있고 고객과 스폰서로부터 승인받아야 프로젝트를 시작할 수 있는 거창한 문서이다. (PMBOK 통합관리 부분에 언급되었을 것이다.) 하지만 필자는 이론 기반의 이상적인 프로젝트나 한국형 SI 프로젝트를 말하고 싶지 않다. ( 기..
-
어느 기획자의 글로벌화 - 사업준비
소프트웨어 개발회사가 글로벌 진출을 하기 위한 기본 전략을 알아야 한다. 자세한 내용은 Kotra 에서 출간하는 해외 진출을 위한 자료들을 찾아보면 이해하기 쉽다. 해외 진출 전략 로드맵 Partner Strategy - 현지의 우수한 파트너를 찾아내야 한다. - 제품이 좋고 우수하면 알아서 찾아온다고 한다. - 파트너와 협력할 수 있고 신뢰를 쌓는 것이 중요하다. Sales Stragegy - Teaming Agreement : 약식 계약으로 기간을 짧게 가져감, 간 보기 용도(법적 효력 X) - Partner Agreement : 간보기가 완료되면 정식 파트너 계약을 체결한다. Marketing Strategy - 파트너와 협력하여 현지화 마케팅을 진행한다. - 롱런을 위해서는 파트너 프로그램을 운영..
-
어느 기획자의 순서도
어떤 일을 하던지 익숙해지면 문제가 발생하기 쉽다. 고로, 기획자가 업무나 맡은 제품에 대해 익숙해지면서 문제가 발생할 확률이 높아진다. 내가 본 기획자들이 가장 많이 놓치는 부분이 기획(작업) 하는 부분에 대한 순서도 작성을 하지 않는다였다. 이유는 "다 아는 거 아니야?" 잘 안다고 생각할 때 사람의 뇌는 망각이라는 것을 실행하여 중간에 빼먹을 것을 당연히 했다고 여길 수 있다. 그래서 순서도 작성을 강하게 강조한다. Biseuness flowchart : 서비스나 상위 수준(시나리오) 업무 플로우 Function flowchart : 기능 및 사용자 액션 대한 플로우 비즈니스 플로우 최초의 시작은 요구 사항 기반으로 상세 기능이 정의 된 이후 시작할 수 있다. 사용자 요구 사항, 시스템 요구 사항,..
최근 글 읽기 (10) 
-
어느 기획자의 One Page Report
업무 특성상 기획이나 관리 업무를 진행하다 보면 의사결정을 받기 위해 보고서 작성을 자주 하게 된다. 보고서 작성도 습관화가 되어 있지 않으면 업무 생산성을 하락시키는 주요 버틀넥이 되기도 한다. 그래서 보고 받는 위치(의사결정권자 입장)에서 생각하며 문서를 작성하는 것이 중요하다. 간단하게 OPP 또는 OPR 작성에 대한 팁을 다루어 본다. OPR (One Page Report) : 한 장 짜리 보고서 OPP (One Page Proposal) : 한 장 짜리 제안서 보고를 받는 의사결정권자는 시간이 가장 중요하다. 따라서 보고 받는 업무가 한눈에 명확히 파악되어 바로 의사 결정이 가능해야 한다. 핵심 1. 입장을 바꿔서, 의사결정권자 중심으로 작성한다. 2. 가능한 짧게, 핵심을 요약해서 가능한 짧게..
-
어느 기획자의 도서 픽, 실리콘밸리 리더십
애플 테크 리더가 들려주는 30가지 비법, 실리콘밸리 리더십 (The Art of Leadership) 초판 1쇄 발행 2021년 8월 1일 지은이 소개 마이클 롭 (Michael Lopp) 실리콘밸리에서 잔뼈가 굵은 엔지니어링 리더. 슬랙, 볼랜드, 넷스케이프, 팔란티어, 핀터레스트, 애플 등 굴지의 IT 기업에서 인재를 육성하고 제품을 탄생시켰다. 개인 시간이 생길 때면 그는 자신의 블로그(https://randsinrepose.com)에 배낭여행과 디러십에 관한 글을 쓴다. 현재 애플에 몸담고 있는 그에게 엔지니어링 리더로서의 여정은 현재진행형이다. 롭에게는 "실리콘밸리 리더십" 외에도 2개의 저서가 있다. 그의 첫 책인 "IT개발자가 쓴 통쾌한 인간관리 이야기"는 엔지니어링 분야의 리더십 기술에 ..
-
어느 기획자의 소프트웨어 품질 활동 이해
"품질 경쟁력" SW개발 회사에서 볼 수있는 문구이다. 그러나 대기업, 중견기업을 제외하고 중소기업에서 품질조직을 갖추는 경우는 흔치 않다. 당장 개발에 집중할 인력도 부족하기 때문에 비용 낭비라 생각하는 경향이 있을 수 있다. 그러다보니 개발자들이 직접 개발도 하고 테스트까지 하는 것을 흔히 볼 수 있다. 소프트웨어 품질 활동 현실에서는 QC와 QA의 개념이 혼재되어 있다. QA 조직이라고 하지만 사실은 QC를 수행하는 조직이 대부분이다. 극소수의 조직에서만 QC와 QA에 차이를 두고 있는 것이 현실이다. QC는 제품을 평가하지만 QA는 제품을 만드는 프로세스를 평가한다. 처음에는 QC활동을 중심으로 수행하지만 조직의 소프트웨어 개발 역량이 성숙할수록 QA활동으로 나아가야 한다. QA는 프로세스와 밀접..
-
어느 기획자의 소프트웨어 품질에 대한 이해
소프트웨어 품질 정의 목적에 적합 : Fitness for use 요구사항과 일치 : 품질 문제는 요구와의 불일치로 발생, 지속적 모니터링 명확한 요구사항과 잠재된 기대치를 만족시킬 수 있는 능력에 관계되는 제품과 서비스의 특징 및 특성의 총체 소프트웨어가 지닌 바람직한 속성의 정도 저렴하고 시장에 적합하며, 예측할 수 있는 정도의 균질성과 신뢰성을 가지고 있는 것 소프트웨어 품질 분류 1 작은 품질 (Little Quality) 개발자가 주로 생각하는 품질의 개념으로 소프트웨어가 요구사항 명세를 만족하느냐 못하는냐 여부 즉, 결함이 없는 소프트웨어 큰 품질 (Big Quality) 고객의 관점으로 고객 만족 여부가 품질의 기준 고객이 원하는 것을 정확하게 구현하여 고객 만족을 제공하는 것. 두 가지 품..
-
어느 기획자의 PMP, 의사소통 편
Project Management Professional 의사소통 유형 6가지 의사소통자의 위치에 따른 구분 내부적(Internal) - 프로젝트 내부 대상과의 의사소통 - 예> 프로젝트 관리자와 프로젝트 팀원간의 의사소통 외부적(External) - 프로젝트 외부 대상과의 의사소통 - 예> 고객, 공급자, 다른 프로젝트 및 조직, 일반 대중 표준 규약 준수 여부에 따른 구분 정형적(Formal) - 사전에 정의한 형식, 절차, 시간을 준수함. - 예> 보고서, 공문, 회의록, 브리핑 비정형적(Informal) - 표준 규약을 따르지 않는 의사소통 - 예> 이메일, 메모, 즉흥적 토의 표준 채널 사용 여부에 따른 구분 공식적(Official) - 집단이나 조직의 표준 매체 또는 채널을 통한 의사소통 - ..
-
어느 기획자의 PMP, 프로젝트 관리 프로세스
Project Management Professional 프로젝트 관리 프로세스 지식영역 프로세스 그룹 착수 기획 실행 감시 및 통제 종료 통합 -프로젝트 헌장개발 -프로젝트 관리 계획서 개발 -프로젝트 작업 지시 및 관리 -프로젝트 작업 감시 및 통제 -통합 변경 통제 수행 -프로젝트 또는 단계 종료 범위 -범위 관리 계획 -요구사항 수집 -범위 정의 -WBS 생성 -범위 확인 -범위 통제 시간 -일정관리 계획 -활동 정의 -활동 순서 배열 -활동 자원 산정 -활동 기간 산정 -일정 개발 -일정 통제 원가 -원가관리 계획 -원가 산정 -예산 결정 -원가 통제 품질 -품질관리 계획 -품질 보증 수행 -품질 통제 인적자원 -인적자원관리 계획 -프로젝트 팀 확보 -프로젝트 팀 개발 -프로젝트 팀 관리 의사소..
-
어느 기획자의 SCRUM, V-model
스크럼과 V 모델 스크럼팀에서 품질 담당자 또는 테스트 엔지니어는 단계별로 무엇을 해야 하는가? 일반적인 스크럼 프레임워크에서 테스트에 대해 직접적으로 명시하고 있지 않다. 개발 단위를 잘게 쪼개어 개발을 수행하는 특성을 생각하면 예측할 수 있는 이유는 몇 가지 있다. 개발 완료 조건을 통해 원하는 품질을 달성할 수 있다. 테스트 엔지니어도 개발팀에 소속되어 프로세스 내에서 품질 활동을 해야 한다. 데일리 미팅을 통해 개발 중 발견된 이슈를 해결해야 한다. 스프린트 리뷰를 통해 제대로 개발되었는지 확인해야 한다. 하지만, 하나의 제품에 여러 스크럼팀이 함께 개발을 할 수도 있다. 스프린트가 완료되면 개발된 항목은 마스터 소스에 머지되어야 하며 이때 사이드 이슈가 발생할 가능성이 있다. 보통 CI/CD 에..
-
어느 기획자의 노션 템플릿 창고
노션 기초 사용법 노션 기초 사용법 마크다운 문법 www.notion.so 마크다운 문법 단축키 문서 작성 단축키 텍스트 선택 단축키 노션은 소규모 팀부터 대규모 팀까지 활용할 수 있으며 어떠한 형태로든 활용이 가능하다. 문서 : 위키, 워드, 엑셀, 데이터베이스 일정 : 캘린더, 태스크(칸반) 보드 협업 : 워크스페이스 기타 : 홈페이지, 포트폴리오, 개인 공간 노션 템플릿 노션 템플릿은 페이지를 복제(Duplicate)하여 사용하면 된다. 설명 페이지 : https://www.notion.so/Duplicate-public-pages-d8a461baeeb54d91b156ff5559192321 1. 노션 공식 템플릿 Notion Template Gallery For HR & People Ops, stu..
-
어느 기획자의 좋은 말하기 방법 (맥락과 6하원칙)
기획자의 중요한 업무 스킬 중 커뮤니케이션에 관한 이야기다. 대부분이 커뮤니케이션에 대해 이야기를 할 때, 남의 말을 경청한다는 말을 자주 한다. 너무다 당연한 말이다. 하지만 기획자는 듣기만 하는 직무가 아니라 자신의 주장을 타인에게 명확하게 전달하고 설득시킬 수 있어야 한다. 듣기도 중요하지만 말하기도 중요하다는 것이다. 직장 생활을 하면서 컨텍스트(Context)라는 단어를 많이 쓰고 들었을 것이다. Context : 문맥, 맥락 사전적 의미 - 문맥 : 서로 이어져 있는 문장의 앞뒤 관계. 글발. - 맥락 : 어떤 사물이나 대상 등이 서로 연결되어 있는 관계. 커뮤니케이션을 잘하기 위해서는 컨텍스트가 있는 말하기가 중요하다. 끝. 맥락 없이 끝나버렸다. (뭐라는거야? 라고 생각한 사람들이 있을 것..
-
어느 기획자의 제품 관리자, 백로그
제품 관리자(PO/PM)는 mini CEO로 불리며 담당한 제품의 전반적인 오너십을 가진다. 제품 관리자의 주요 업무 중 하나는 로드맵에 따라 아니면 상황에 따라 앞으로 우리가 해야 할 일을 정하는 것이다. 그중 백로그 생성과 관련된 내용을 정리해 보았다. 백로그는 로드맵에 의해 미리 예견된 항목과 시장의 급변, VOC를 통해 예측 불가능 항목으로 나눌 수 있다. SW의 가장 큰 장점이자 단점은 쉽게 변경할(될) 수 있다는 것이다. 백로그의 우선순위는 항상 바뀔 수 있고 변경될 수 있음을 인지해야 한다. 그러므로 제품 관리자의 방향 설정은 제품의 성공 실패에 큰 영향을 미출 수 있어 매우 신중을 기해야 한다. 성공으로 이끄는 것은 아이디어가 아니라 훌륭한 기회이다. Problem / Opportunity..
-
어느 기획자의 업무 이야기
개발파트에서 기획이란? 필자가 말하고자 하는 부분은 소프트웨어를 개발하는 파트의 구성원으로써의 기획 업무를 정의한다. 모든 학문에는 공학(工學, Engineering)이 있듯이 소프트웨어 개발에는 소프트웨어 공학이 존재한다. 따라서 소프트웨어 공학에서 필요로하는 기획 업무가 개발파트에서 기획에 대한 정의가 된다. 소프트웨어 개발을 위해 사전에 사업 기획서가 만들어지고 사업 진행이 결정되면 개발해야할 대략적인 모습이 보이기 시작한다. 아래 개발 프로세스 바탕으로 주요 업무에 대해 다루어 본다. (프로젝트 셋업은 PM의 주 업무로 다루지 않음) 주요 업무를 언급할 뿐, 상세 업무는 연결된 다른 글에서 확인할 수 있다. 1. 요구사항 분석 및 정의 업무 그러면 구체적으로 무엇을 개발해야하는지를 정의하는 것이 ..
-
어느 기획자의 공부, OO테크
4차 산업혁명은 기술의 발전이 아닌 융합을 통해 새로운 가치를 창출해낸다. 이를 바탕으로 다양한 산업 도메인에 IT 기술(technology)을 접목한 서비스들이 다양하게 두각 되고 있다. 그래서 기존의 틀을 깨고 새로운 시장을 창출해내는 창조적(Creative) 파괴자(Disruptor) 또는 파괴적 혁신이라는 수식어를 붙이기도 한다. 4차 산업혁명은 우리가 살아가는데 필수 3요소 의식주에 많이 관여된 것을 알 수 있다. OO테크 또한 의식주와 연관된 기술이 많이 나온다. 바로 우리의 일상을 변화시키는 기술이라 생각하면 된다. 각각의 테크는 독립적이기도 하지만 서로 교차되는 분야가 존재하며 함께 성장을 진행하고 있다. 스타일테크 (Styletech) 패션, 뷰티 등 스타일 분야에서 AI, IoT, AR..
-
어느 기획자의 정보 수집
데이터는 내부뿐 아니라 외부에서도 다양하게 얻을 수 있어야 한다. 물론 유용한 정보는 유료가 많지만 발품을 팔면 무료 정보도 훌륭하게 사용할 수 있다. 우선 생태계를 알아볼 수 있는 서비스 지표에 대한 정보를 수집할 수 있다. 그리고 필요에 따라 학술 정보를 조회할 수 도 있다. 그리고 자주 변화는 트렌드의 경우 구독 형태로 수집하는 것도 좋다. 1. 서비스 지표 확인하기 온라인, 모바일 서비스를 하기 위해 우리는 항시 지표를 확인해야 될 필요가 있다. 지표 변동이 있을 경우 어떤 이벤트가 있을 수 있고 우리는 그것을 캐치하여 서비스의 방향을 변경해야 할 수도 있기 때문이다. 이런 지표 정보는 대부분 유료 사이트로 운영된다. 스태티스타 (www.statista.com/) 닐슨코리아 (www.nielsen..
-
어느 기획자의 목업 이미지 만들기
문서를 만들 때 가끔 필요한 목업들이 있다. 웹에서 간단하게 찾아서 쓰기 좋은 몇 가지를 소개한다. 직접 디바이스 목업 커스텀하기 Threed.io Generate custom 3D Device Mockups in your Browser. threed.io 아이폰을 바탕으로 앵글을 변경해가면서 직접 목업을 제작할 수 있다. [Upload] 버튼을 이용하여 폰 안에 들어갈 이미지도 해상도에 맞춰 업로드하면 완벽하게 커스텀할 수 있다. 스탠다드한 목업 가져쓰기 Devices from Facebook Design Download images and Sketch files of popular devices. design.facebook.com 페이스북에서 제공하는 목업이다. 디바이스별로 카테고리가 나누어져 있으..
-
어느 기획자의 공부, 마이데이터
마이데이터 사업이 본격화되고 있다. 그럼 사용자 입장에서 마이데이터는 내 정보에 대한 불안감 말고 어떤 기대감을 줄 수 있을까. 모르면 나만 손해! 공공 마이데이터 완전정복 문화체육관광부 국민소통실 운영, 정책뉴스, 정부 보도자료, 설명자료, 국정과제, 대한민명 정부 소개 등 제공 www.korea.kr 개요, 데이터 3법 2020년 데이터3법이 본회의를 통과하여 잠깐 둘러본 적이 있다. 데이터 3 법은 개인정보보호법, 신용정보법, 정보통신망법 3개 법률에 대한 개정을 다루고 있다. 우리 개인의 정보를 기업들이 이용할 수 있게 하여 신산업을 육성시키겠다는 취지이다. 단, 가명을 이용해서만 이용이 가능하다. 잠깐, 가명을 쓴다고 과연 그 정보가 개인정보 아닐 수 있는 것인가? 몇 가지 정보만 조합해도 추정..
-
어느 기획자의 영감 찾기 (UI/UX)
Designerslist. Useful tools & resources, top designers from all around the globe and interesting reads. Made for designers, by designers www.designerslist.info 전 세계의 유용한 도구 및 리소스 와 최고의 디자이너 Made for designers, by designers https://www.designerslist.info 디자이너에 의한 디자이너를 위한 사이트이지만 둘러보며 영감 얻기 좋다. 홈페이지는 3개의 메뉴를 제공한다. - Designers. : 디자이너 목록과 간단한 소개 - Websites. : 디자인 툴과 이미지 소스 관련 정보 - Instargram. : UI ..
-
웹 사이트 1초 이내 렌더링하기
개요, 구글은 모바일 네트워크에서 1초 내에 페이지를 렌더링하도록 권장하고 있다. 렌더링 시간이 1초 이상 지연되면 사용자의 흐름이 끊겨 사용환경이 저하된다고 한다. 그래서 우리는 전체 페이지를 로딩하지 않고 사용자가 인지할 수 있는 영역을 최대한 빠르게 로딩하여 상호작용이 가능하도록하고 스크롤 아랫부분을 백그라운드에서 로딩하도록 한다. 여전히 ATF(Above the fold) 를 사용해야하는 이유다. 여전히 ATF(Above the fold) 를 사용해야하는 이유 "Blasting the Myth of the Fold « Boxes and Arrows - Milissa Tarquini (2007-07-24).". Boxesandarrows.com 4524.tistory.com 웹 사이트 로딩 시간 분..
-
어느 기획자의 페이지 속도 개선
웹 사이트를 이용하는 사용자들이 가장 원하는 것은 사이트가 오류없이 빠르게 로딩되어 원하는 정보를 확인하는 것이다. 오류가 없기 위해서는 개발 품질의 향상과 다양한 사용자 환경에 대한 이해가 필요하다. 빠른 로딩을 위해서는 무거운 컨텐츠에 대하여 네트워크가 불안정한 사용자에게도 원활하게 로딩될 수 있도록 조치가 필요하다. Google 권장 지침은 모바일 네트워크에서 1초 내에 페이이지 로딩이다. 1초는 네트워크 오버헤드(DNS Lookup & TCP handshake, TLS connection 등) 300ms를 제외하면 700ms가 우리에게 주어진 시간이다. 700ms 내에 서버의 응답을 렌더링하고 클라이언트 코드를 실행하고 브라우저에 UI를 렌더링해야 한다. 여전히 ATF(Above the fold)..
-
어느 기획자의 리스크 관리
간혹 위험(리스크)와 이슈를 구분하지 않고 사용하는 경우가 많다. 불확실성이 있는 곳에는 언제나 리스크가 있고 현실화되어 이슈가 된다. SW 관리 측면에서 살펴보면, 위험(리스크, risk) - 원치 않는 결과를 초래하게 될 발생 가능한 불확실한 미래의 사건 - 아직 발생하지 않은 문제 (추측, 추정) 이슈(issue) - 현실화된 문제 (현재, 사실) 관리(management or control) - 지속적으로 돌보지 않으면 잘못될 대상을 보살펴 돌보는 활동 위험 관리 필요성 - 프로젝트의 성공 가능성을 높일 수 있다. SW 프로젝트는 불확실성을 가지고 있다. 프로젝트 진행 중 예상치 못한 이슈가 발생하여 프로젝트가 흔들리거나 중단될 수 있는 상황을 미연에 찾아서 관리함으로서 프로젝트의 성공 가능성을 ..
-
둘러볼만한 웹, 모바일 UI/UX
트렌드는 하룻밤 사이에 변하지 않는다. 서서히 스며들어 눈치채지 못할 수도 있으니 일정 주기를 갖고 관심 있게 보길 바란다. 한 달에 한 번은 둘러보고 감을 잊지 말아야 한다. 웹 사이트 둘러보기 굿디자인웹 국내 최우수 웹디자인 선정, 웹사이트. 굿디자인웹 www.gdweb.co.kr 모바일 UI/UX 둘러보기 Mobile Patterns - UI UX Inspirational Gallery for iOS and Android www.mobile-patterns.com pttrns pttrns, 뉴욕. 좋아하는 사람 5.3천명. Finest collection of design patterns, resources and inspiration. www.facebook.com UXArchive - Made ..
-
어느 기획자의 글로벌화 체크리스트
소프트웨어의 글로벌화를 위한 점검 항목은 아래와 같이 구분하고 있다. (출처 : NIPA) 체크리스트 아래 상세 점검 항목을 기반으로 현재 글로벌 서비스로 준비 중인 소프트웨어를 점검하고 보완할 수 있다. NIPA 점검 항목에 내용이 더 추가되었다. 기본 점검 항목 코드 점검 항목 BASE-01 서비스 범위(지역), 지원 언어를 식별한다. BASE-02 글로벌화 요구사항을 수집하고 명세화하여 명확히 분석 한다. - 단순번역, UI 적용, 비기능 (성능, 가용성 등), 기능 (지역별 활성, 비활성), 법규 적용, 라이센스 BASE-03 기업, 제품, 적용 기술 등에 대한 주요 용어들을 모두 식별하고 그에 대한 언어별 용어사전을 작성한다. BASE-04 글로벌하게 사용될 수 있는 디자인 스타일과 배치에 대한..
-
어느 기획자의 글로벌화 - 사업준비
소프트웨어 개발회사가 글로벌 진출을 하기 위한 기본 전략을 알아야 한다. 자세한 내용은 Kotra 에서 출간하는 해외 진출을 위한 자료들을 찾아보면 이해하기 쉽다. 해외 진출 전략 로드맵 Partner Strategy - 현지의 우수한 파트너를 찾아내야 한다. - 제품이 좋고 우수하면 알아서 찾아온다고 한다. - 파트너와 협력할 수 있고 신뢰를 쌓는 것이 중요하다. Sales Stragegy - Teaming Agreement : 약식 계약으로 기간을 짧게 가져감, 간 보기 용도(법적 효력 X) - Partner Agreement : 간보기가 완료되면 정식 파트너 계약을 체결한다. Marketing Strategy - 파트너와 협력하여 현지화 마케팅을 진행한다. - 롱런을 위해서는 파트너 프로그램을 운영..
-
어느 기획자의 글로벌화 - 개발준비
소프트웨어 개발을 하면서 글로벌 론칭이라는 목표 아래 무작정 영어만 추가하여 개발을 시작하는 팀이 있다. 영문으로만 만들어지면 글로벌화된 것인가? 에 대한 질문에 그렇다 아니다 라고 단정 지어 대답하기는 어려운 것 같다. 제품의 방향과 도메인 특성에 따라 글로벌화 준비 항목들이 차이가 있을 수 있다. 글로벌화 관련하여 기본 내용을 확인하여 활용하는 것이 좋다. 개요 글로벌화의 개발 목적은 다양한 언어나 문화권의 사용자들이 제품을 이용하는 데 있어 발생할 수 있는 문제를 최소화하기 위함이다. 용어 정의 현지화 (Localization, L10n) - 제품을 특정 언어나 문화권에 적합하도록 커스터마이징 하는 작업. - 현지의 제품과 비교하여 차이가 나지 않도록 특색을 반영하는 것이 중요함. 국제화 (Inte..
-
어느 기획자의 글로벌화 - 언어준비
소프트웨어의 글로벌화를 생각하면 가장 먼저 떠오르는 것이 번역일 것이다. 언어 준비 글로벌 서비스 준비에서 번역은 글자에 대한 번역이 아닌 문맥에 대한 번역을 고려해야 한다. 동일한 의미의 단어라도 문맥에서 다른 의미를 제공할 수 있기 때문에 신중하게 언어 리소스를 작성해야 한다. 명확하고 간단한 언어로 모호함을 줄인다. 번역회사는 전문가에게 번역 검수를 받는다. 현지화, 국제화된 컨텐츠를 제작한다. 1. 목적에 맞게 짧게 작성한다. 왼쪽, 간결한 목적만 전달하면 번역이 수월해진다. 오른쪽, 부연설명이 추가되어 번역시 텍스트가 넘어가거나 내용에 의문을 남길 수 있다. 2. 한 문장은 하나의 내용(목적, 생각)만 다룬다. 문장이 길어질 수록 번역된 글은 의도한 내용과 다르게 전달될 확률이 높다. 전달하고자..
-
어느 기획자의 사용성 평가 정리
사용성 평가란? 제품 또는 서비스의 사용성 문제를 찾아내서 개선하는 조사 방법이다. 사용성 평가의 활용 실제 사용자의 행동을 관찰하기 때문에 단계별 시나리오에 따라 수행하는 모습에서 각 단계에서 문제점을 발견할 수 있다. 또한 같은 시나리오를 경쟁 제품이나 기존 제품에서도 수행하여 개선 방안도 모색할 수 있다. 사용성 평가 중 확인된 시스템이나 서비스의 문제점은 개발팀에 이슈로 등록될 수 있고, 이슈 등급에 따라 다음 업데이트에 바로 반영되어야 할지 나중에 해결할지 우선순위를 결정할 수 있다. 사용성 평가 항목 항목 측정 지표와 설명 수행 시간 (Execution Time) - 완료 시간 : 사용자가 시나리오를 수행하는데 걸린 시간 - 인지 시간 : 사용자가 시나리오 수행에 대해 이해하는 걸린 시간 - ..
-
어느 기획자의 A/B테스트 (Firebase)
Firebase 의 A/B 테스트 기능을 이용하여 고객과 소통해보기 A/B테스트 개요 Firebase 에서 제공한는 A/B Testing 아래와 같이 3가지 형태를 제공한다. 알림 : Cloud Messaging 원격 구성 : Remote Config 인앱 메시지 : In-App Messaging 실험 만들기 버튼을 통해 3가지 형태의 실험을 만들수 있다. AB 테스트 측정 항목 참고 참고 : firebase.google.com/docs/ab-testing?authuser=0 Firebase A/B 테스팅 Firebase A/B 테스팅plat_iosplat_android Google 최적화 도구에서 제공하는 Firebase A/B 테스팅을 사용하면 제품 및 마케팅 실험을 쉽게 실행, 분석, 확장하여 앱 ..
-
Product Owner Framework
©Copyright 2015 - Daisy Pilbrow, Javier Ubillos, and Viktor Cessan. productownerframework.wordpress.com 공유된 프레임워크에 대한 이용은 유료로 사용이 가능하다. 2015년도 PO Framework 를 Beta 로 오픈하고 더 이상의 업데이트는 없다. 망했거나..... 아직도 유용하거나.... (전자겠지..) 전반적인 내용은 좋은 시도라고 보인다. (뻔한 내용임) 4개의 범주와 8개의 영역으로 PO 에 대한 평가가 가능하도록 구성되었다. - 실제 항목에 대한 자세한 설명과 함께 체크를 하여 점수를 매길 수 있도록 구성됨. 그리고 평가 결과로 무엇을 더 발전시켜야 할지 알 수 있을 것이다. 하지만 평가에 대한 코치를 해줄 사람..
-
어느 기획자의 앱스토어 리젝 - In App Purchase
In App Purchase Apple AppStore 는 결제와 관련하여 매우 엄격한 가이드라인을 제공하고 있다. 물론 최근 Google 도 Google play 내부에서만 결제를 하도록 가이드하고 있기는 하다. 이러한 제약을 회피하기 결제 관련 서비스를 웹으로 구현하고 앱 내부에서 호출하는 형태로 제공을 한다. 제공하던 앱은 5년 넘게 서비스를 해왔던 앱이고 갑자기 리젝되어 약간 황당한 케이스였다. 리젝사유는 무료 사용을 하라고 권하면서 외부 사이트로 유도를 했고, 해당 사이트에서 가격 정책이 확인되어 가이드 위반이라는 내용이었다. 친절하게 첨부된 이미지를 확인해보니, 친절하게 타임라인 순으로 첨부되어 있었다. 서비스 이용 완료 > 무료 이용버튼 > 웹 사이트로 이동 > 열심히 탐험.... > 가격 ..
-
어느 기획자의 앱스토어 리젝 - CallKit
CallKit CallKit 은 iOS 10 부터 제공하던 개발툴로 통화기능을 이용하여 VoIP(Voice over Internet Protocol)를 이용하는 앱에서 주로 이용된다. 하지만 중국 정부의 요청으로 중국에서는 CallKit 을 이용할 수 없게 되었다. (2018년) VoIP 를 이용한 서비스를 제공하다보니 글로벌 고객들이 이용할 수 있어야 했고, 배포 국가를 전 세계로 확대를 했다. 최초 앱이 출시하고 전 세계에 동기화하는데 10시간 정도의 시간이 소요되었다. 그리고 8시간 4시간.. 점점 동기화 시간은 줄어들었다. 어느 날 갑자기 앱스토어에서 출시가 거부당하는 사태가 발생했다. 거부 사유 Guideline 5.0 - Legal Recently, the Chinese Ministry of ..
-
어느 기획자의 앱스토어 리젝 - Sign in with Apple
Sign in with Apple 2019년 9월 Apple ID 간편 로그인 서비스가 제공되면서 2020년 4월부터 소셜 로그인 서비스를 제공하는 서비스에 대하여 심사를 강화하고 있다. 이에 따라 소셜 로그인을 제공하던 서비스들이 Apple 로그인을 추가하지 않을 경우 간혹 심사에서 리젝 당하는 케이스들이 나온다. 이는 심사하는 사람에 따라 랜덤으로 걸리는 사항이기 때문에 당황하지 않고 제공하는 서비스 취지에 맞게 사유서 작성 또는 Apple 로그인을 추가하면 통과된다. 개요 2019년 9월 12일 Apple 개발자 사이트에 게시된 Apple로 로그인에 대한 신규 가이드라인 사용자의 Apple ID로 앱과 웹사이트에 로그인하도록 하여 로그인 과정을 간소화할 수 있습니다. 개인정보 보호 및 보안 기능을 ..
-
어느 기획자의 커뮤니케이션
퍼실리테이션은 회의와 같은 여러 사람이 의견을 내고 합의를 도출해야 하는 상황에서 원활하게 진행될 수 있도록 촉진제 역할을 한다고 생각하면 된다. 회의 종류에 따라 필요한 퍼실리테이터의 역할과 스킬이 다양하다. 여기서 말하고자 하는 내용은 내외부 커뮤니케이션이 많은 기획자에게 원활한 회의와 의사결정에 도움이 될 만한 부분을 갈무리하여 소개한다. 회의 중 발생할 수 있는 문제에 대한 진단 예. 행동 사례(증상) 문제 상황 진단 문제의 원인 1 “시간 낭비 하지 맙시다. 이곳에서 그런 일은 절대 일어나지 않을 겁니다”와 같은 발언이 나온다. 냉소주의 집단의 미래에 대한 비전이 없다. 2 ‘내가 맞고 당신은 틀렸다’는 식으로 의견을 제시하며, 대화가 지나치게 감정적으로 흐른다. 논쟁을 좋아하는 참가자들이 있음..
-
어느 기획자의 카피라이팅
세상에 없는 무언가를 찾지 마세요. 창의적인 사고를 억지로 해봤자 우리의 뇌 속 세포 어딘가에 기록되어 있던 정보들이 조합되어 우리 뇌의 망각에 의해 새롭다고 느껴지는 것입니다. 너도 할 수 있어. 준비 운동부터 하고 1. 뇌 속 세포에 최대한 많은 카피 문구들을 저장해 놓는다. 2. 지금 써야 할 주제 또는 키워드를 추출해서 준비해둔다. 3. 기억에서 끄집어낸 카피 문구를 준비해둔다. "드신 날과 안드신 날의 차이를 경험해보세요." "니들이 게 맛을 알어?" "여보, 아버님댁에 보일러 놓아 드려야겠어요" "피부가 장난이 아닌데", "로션하나 바꿨을 뿐인데" "올 겨울도 스타일리쉬하게" "나는 노담, 전자담배도 안피움" "야! 너두 할수있어" "세상을 연결하는 창" (링크 : https://www.you..
-
어느 기획자의 요구공학
요구 공학은 소프트웨어 공학에서 요구사항 부분이 파생된 학문으로 Wiki 에서 확인할 수 있다. 위키 백과 바로가기 요구사항은 사용자 요구사항과 시스템 요구사항으로 구분할 수 있으며 비 개발 직군인 기획자의 경우 사용자 요구사항을 담당하고 개발직군은 시스템 요구사항을 담당해야 한다. 하지만 요구사항 분석가나 아키텍트나 그에 준하는 직무가 없는 경우 자신의 업무가 아니라는 식으로 작성하지 않는 경우가 태반이다. 비 개발직군은 아래 링크만 확인하고 어느 기획자의 요구사항 작성 소프트웨어 공학의 입구에 서서 문을 열면 가장 먼저 반기는 것이 요구사항이다. 그리고 이렇게 시작한다. "고객은 자신이 무엇을 원하는지 모른다." 실제 모르는 것이 아니라 머릿속에 있는 것 4524.tistory.com 개발직군은 위 ..
-
어느 기획자의 요구사항 작성
소프트웨어 공학의 입구에 서서 문을 열면 가장 먼저 반기는 것이 요구사항이다. 그리고 이렇게 시작한다. "고객은 자신이 무엇을 원하는지 모른다." 실제 모르는 것이 아니라 머릿속에 있는 것을 표현을 못한다는 말이다. 이것을 구체화하는 작업이 요구사항 정의이다. 에이전시나 SI 프로젝트를 경험하신 분들은 친근하게 느껴질 수 있을 것이다. 하지만 인하우스나 자체 솔루션을 오래부터 가져온 회사 직원은 필요성을 못 느낄 수 있을 것이다. 요구사항의 중요성은 구글에서 검색하면 나무에 그네를 만드는 이미지로 확인할 수 있다. 서론을 시작으로, 요구사항 수집 > 분석 > 정의 > 관리 4단계를 확인한다. 서론, 요구사항 접하기 요구사항 문서에 대해 처음 접하다. 필자가 요구사항을 처음 접한 것은 외국(계) 회사에서 ..
-
어느 기획자의 품질 이야기
테스트 분야 공부를 하게 되면 반드시 만나는 V-Model 에 대한 생각이다. ISTQB 공부를 하면서 실라버스에 나온 내용과 테스트 실무 등.. 프로세스 및 정책은 언제나 웅장한 느낌을 받는다. 그럼 실무에서는 어떻게 적용해야 할 것인가? 여태 다녀본 회사에 품질, 테스트 조직이 있다한들 테스트 정책을 명문화하여 지키는 것을 본 적이 없었다. 그리고 앞으로도 없을 것 같다. 그만큼 실무와 거리가 생기는 내용이라 생각한다. 개발 프로세스를 개선하면서 늘 품질 파트를 어떻게 접목해야 하는가라는 고민이 생겼다. 일전에 스크럼을 공유하면서 고민했던 내용을 끄적여 본다. Scrum 프레임워크를 통해 개발자들은 어떻게 개발을 해야되는지 알게 된다. 하지만 품질 담당자에 대한 언급은 없었던 것 같다. 개발을 잘하면..
-
어느 기획자의 스크럼 직무 분담
Agile 조직을 구성하기 위해 스쿼트, 사일로 등 해외의 성공 사례를 가져온다. 그럼 Scrum Framework를 도입하고자 할 때 또는 셋업 하려고 할 때 가장 먼저 무엇을 신경 쓸 것인가? 나는 당연히 업무 분장이라고 생각한다. (Role and Responsibilities) 스크럼의 구성원은 보통 3가지로 구분된다. PO (Product Owner) SM (Scrum Master) SD (Scrum Developer / Scrum Team) 그럼 조직에서는 현재 구성원을 어떻게 배치할지에 대해 고민을 해야 한다. 보통의 조직은 이렇지 않을까.. - PO : 기획자 or PM - SM : PM - SD : 개발, 디자인, 기획, 테스터 이제부터 개인적인 배치에 들어갑니다. PO : 기획자가 적합..
-
어느 기획자의 공부, INVEST user-story
좋은 유저 스토리란 아래 6가지 특성을 만족한다라고 한다. INVEST in Good Stories, and SMART Tasks - XP123 (French) XP teams have to manage stories and tasks. The INVEST and SMART acronyms can remind teams of the good characteristics of each. Are you a Product Owner or a writer of user stories? I’d love to hear about your challenges and successes at william.w xp123.com 좋은 유저 스토리를 위한 6가지 특성 좋은 유저 스토리를 작성하기 위해서는 좋은 유저 스토리의..
-
어느 기획자의 유저 스토리
기획자가 Agile 을 공부한다는 건 유저 스토리에 대한 접근이 아닐까라고 생각해본다. 도서를 보더라고 Agile 의 한 부분으로 유저 스토리만을 다룬 책들이 많이 있다. 프로젝트의 단추인 만큼 중요하지만 다루는 것은 그다지 쉽지 않은 부분이다. 유저 스토리를 이해하기 위해 사전 지식으로 Agile 원칙에 대한 이해가 필요하다. 서론의 시작 대충... 빠르게 개발해서 고객에게 전달하는 개발 방식이다. 그럼 어떻게 빠르게 개발을 할 수 있는가? 1. 개발할 내용을 작고 작은 조각으로 쪼갤 수 있어야 하고. 2. 작게 쪼갠 조각은 독립적으로 동작할 수 있어야 한다. 여기서 포인트! - 두 개의 문장을 작성했을 뿐인데... 막연하다. 어떻게 작성하라고?? - 유저 스토리를 작성하는 방법들이 나온 이유일 것이다..
-
어느 기획자의 SRS (Software Requirements Specification)
요구사항 문서에 대한 템플릿은 IEEE 표준 문서가 있지만 실무에서 사용하기는 번거롭고 가독성이 떨어진다. 그래서 회사별, 사람별로 다양한 요구사항 정의서를 가지고 있다. 우리가 흔히 보는 비즈니스 측면이 강조된 요구사항 문서는 대부분 PM 이나 기획자들이 작성을 할 것이다. 실제 개발에서 사용하는 요구사항 정의서는 선임 개발자나 아키텍트가 작성하여 BDD 에 유용하게 사용한다. 기획자도 SRS 쓸 수 있다. 1. 표지 작성 [OOO] 요구사항 명세서, 작성(배포)일, 작성자 소속 2. 문서 확인 고객사와 개발사, 이해관계자들의 협의를 위한 공간 3. 문서 이력 문서의 변경 이력을 작성한다. 4. 서비스 개요 목적, 범위, 용어, 사양(성능), 설계, 참고 문헌 정의 5. 상위 수준 요구 사항 6. 기능..
-
어느 기획자의 디자인 가이드 훔쳐보기
기획자도 각 플랫폼별 디자인 가이드를 알고는 있어야 합니다. (옵션 사항) 디자인 가이드는 각 플랫폼의 아이덴티티와 특색을 잘 표현하고 있어서 개발자 사이트를 통해 얻는 것보다 빠르고 쉽게 정보를 습득할 수 있습니다. Microsoft Design 사이트에서는 각 플랫폼의 디자인 가이드로 링크가 연결되어 있어 편하다. www.microsoft.com/design/fluent/#/ Web, Windows, 모바일 등 주요 플랫폼에 대한 디자인 가이드를 확인할 수 있다. 아래 이미지를 보면 좌측에 각 플랫폼을 선택하여 동일 컴포넌트에 대하여 확인할 수 있다. developer.microsoft.com/en-us/fluentui#/controls/mac/date-picker Microsoft 의 Fluent ..
-
어느 기획자의 PM 업무
SW 공학, 품질 관리 등 책을 보면 프로젝트 시작을 위해 가장 먼저 해야 될 업무에 대해 정의가 되어 있다. 물론 책마다, 글쓴이마다, 도메인 특성에 따라 다를 것이다. 나는 내부 SW 개발 프로젝트를 참여하면서 그 누구도 그것을 하는 사람을 보지 못했다. 다들 운영을 하고 있던 프로젝트라 신경을 쓰지 않았던 부분이 컸을 것이라 생각한다. "프로젝트 헌장" 이것에 대해 말하고자 한다. 프로젝트 헌장은 어떠한 프로젝트를 진행할 것이며 그에 따른 책임과 권한 등 모든 내용이 수록되어 있고 고객과 스폰서로부터 승인받아야 프로젝트를 시작할 수 있는 거창한 문서이다. (PMBOK 통합관리 부분에 언급되었을 것이다.) 하지만 필자는 이론 기반의 이상적인 프로젝트나 한국형 SI 프로젝트를 말하고 싶지 않다. ( 기..
-
어느 기획자의 PM 이야기
SW 관리자를 우리는 보통 PM 이라 부른다. 필자는 명확하게 PM 이 지칭하는 역할이 Project Manager 인지 Proudct Manager 인지를 확인해보고 싶다. 두 직무는 명확히 다른 목적을 가진 업무로 헷갈리지 않기를 바란다. 설명은 애자일 환경에서의 직무에 대해 설명한다. Product Manager (Owner) 제품 관리자는 개발파트가 아닌 비즈니스, 사업과 관련된 영역에 치중한다. "개발은 모르겠고.. 이렇게 만들어줘야 상품 가치가 있고 고객이 사용할 수 있다." 라고 말할 수 있는 사람이다. 애자일 개발 프로세스가 널리 퍼지면서 PO (Product Owner) 라는 명칭으로 더 통용된다고 생각한다. 애자일에서 조직은 점점 더 작은 단위로 쪼개지고 애자일팀에서 스쿼드라는 팀 단위..
-
어느 기획자의 UX 전략
UX 전략 기반의 모듈화를 실천해라. 보통 UX = UI + Interaction 이라는 공식에 공감한다. 사용자에게, 우리가 제공하는 가치에 대하여 UI로 낚시를 하여 서비스 들어오도록 하고 사용자에게, 우리가 자신을 목적 달성을 위해 일을 하고 있음을 알려주고 사용자에게, 우리가 제공하는 가치가 사용자에게 만족이라는 피드백을 주어야 한다. 화면설계서 작성 단계에 도달했다는 것은 이미 UX전략을 세웠을 것이다. 화면설계서는 말 그대로 화면(UI)을 포함하고 있다. 규모가 큰 제품이나 서비스의 경우는 여러 명이 같이 작업할 수도 있다. 이미 UX 전략 또는 아이데이션에서 대략적인 화면이나 UI컴포넌트가 정의되었을 것이다. 어디선가 주워들은 내용, 어떤 UX에이전시에서는 UI컴포넌트만 작업해서 배포하는 사..
-
어느 기획자의 문서 작성
모든 문서를 작성하기 전에 형식을 갖추는 작업을 먼저 할 것이다. 화면 설계서 문서도 예외는 아니다. 하지만 후배들 작업하는 것을 보면, 자신만 알아볼 수 있게 작업하는 경우가 종종 발견된다. 주어진 템플릿을 그대로 이용하는 케이스 우선 내용부터 채우는 케이스 명확한 기준을 세우지 않고 작업하는 경우, 중구난방으로 문서 작성이 시작되어 헤매기 십상이다. 또한 완성된 결과물은 자신을 위한 문서가 될 뿐, 리뷰자들이 보기 어려워진다. 모든 문서는 문서를 보는 사람에 맞게 작성해야 되는 원칙을 지켜야 한다. 그래서, 틀을 갖추는 이야기를 하고자 한다. 첫 번째, 표지에 "제목"과 "부 제목", "작성자"를 기입해라. 내가 다니던 회사의 공식 형태는 아래와 같다. 주 제목과 부 제목의 가중치를 고려해보면, - ..
-
어느 기획자의 순서도
어떤 일을 하던지 익숙해지면 문제가 발생하기 쉽다. 고로, 기획자가 업무나 맡은 제품에 대해 익숙해지면서 문제가 발생할 확률이 높아진다. 내가 본 기획자들이 가장 많이 놓치는 부분이 기획(작업) 하는 부분에 대한 순서도 작성을 하지 않는다였다. 이유는 "다 아는 거 아니야?" 잘 안다고 생각할 때 사람의 뇌는 망각이라는 것을 실행하여 중간에 빼먹을 것을 당연히 했다고 여길 수 있다. 그래서 순서도 작성을 강하게 강조한다. Biseuness flowchart : 서비스나 상위 수준(시나리오) 업무 플로우 Function flowchart : 기능 및 사용자 액션 대한 플로우 비즈니스 플로우 최초의 시작은 요구 사항 기반으로 상세 기능이 정의 된 이후 시작할 수 있다. 사용자 요구 사항, 시스템 요구 사항,..
-
어느 기획자의 개발 이해하기
기획하는데 개발을 왜 알아야 하죠?? 라고 생각하는 사람이 아직도 있는지 모르겠지만, 혹시 모르는 마음에 기획자도 알아두면 좋은 지식에 대해 다루어 본다. 개발은 SW가 만들어지는 모든 과정을 통칭하는 용어로, 기획자는 개발을 알아야 한다. 단, 코딩을 알 필요는 없다. 이런 것들이 기획자가 범하는 가장 많은 오류이다. 이런 것들 => 용어의 잘 못된 이해 1. 개발 (Software Development) SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 운영까지의 모든 단계를 일컫는다. 즉, 요구사항 > 설계 > 구현 > 검증 > 운영 의 모든 프로세스를 포함하고 있다. 그럼 기획자는 각 단계별 어떤 업무를 수행하는지 확인하고 왜 개발을 알아야 하는가를 이해하면 된다. 첫 번째로 기획자..
-
어느 기획자의 체크리스트
업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라 특히, 모바일을 중심 서비스가 증가하는 만큼 모바일에서 서비스를 이용하는 경우가 많다. 작은 화면에서 여러가지 기능을 수행하면, - 사용자가 사용하기 힘들뿐더러 컨트롤(사용)도 힘들기 마련이다. - 코치형 가이드가 마구마구 추가되어 복잡하게 될 수도 있다. - 복합한 UI이나 기능은 사이드 오류를 양산하기도 한다. 특히 우리는 ..
