본문 바로가기

개발 안하는 공대생/SW 기획  ٩(*•̀ᴗ•́*)و

Firebase 를 이용한 고객과 소통하기 (A/B테스트 : In-App Messaging) Firebase 를 이용한 고객과 소통하기 (Cloud Messaging) 편 Firebase 를 이용한 고객과 소통하기 (Cloud Messaging) Firebase 의 [참여] 카테고리의 메시징 기능을 이용하여 사용자에게 Direct Message 를 전송하고 참여율을 확인할 수 있다. 아래 두 개의 메시징 기능 A/B 테스팅의 알림과 인앱 메시지 부분을 담당한다. 6987.tistory.com 기본 사용법은 위 포스트에서 확인하고 주요 포인트만 확인합니다. In-App Messaging 인앱 메시지의 캠페인을 이용하여 상황에 따른 사용자의 참여를 유도하는데 유용하게 사용할 수 있다. 장점은 메시지의 유형을 다양하게 제공하는데 있다. 메시지 유형 : 카드, 모달, 이미지 only, 배너(현수막) 카.. 더보기
Firebase 를 이용한 고객과 소통하기 (A/B테스트 : Cloud Messaging) Firebase 의 [참여] 카테고리의 메시징 기능을 이용하여 사용자에게 Direct Message 를 전송하고 참여율을 확인할 수 있다. 아래 두 개의 메시징 기능 A/B 테스팅의 알림과 인앱 메시지 부분을 담당한다. Cloud Messaging In-App Messaging Cloud Messageing 클라우드 메시지는 앱이 설치된 모바일 기기로 (FCM)메시지를 전송하는 기능을 제공하며 2가지 형태로 구분하여 활용할 수 있다. 하나는 A/B 테스트를 위한 메시지와 두 번째는 그냥 일반적인 메시지를 전송하는 것이다. 클라우드 메시지는 2가지 탭 메뉴를 제공한다. - 알림 : 새로운 실험이나 알림을 작성한다. - 보고서 : 발송된 알림에 대한 통계를 제공한다. 우선 알림 탭에서 새로운 메시지를 작성해.. 더보기
앱스토어 리젝 (In App Purchase) Apple AppStore 는 결제와 관련하여 매우 엄격한 가이드라인을 제공하고 있다. 물론 최근 Google 도 Google play 내부에서만 결제를 하도록 가이드하고 있기는 하다. 이러한 제약을 회피하기 결제 관련 서비스를 웹으로 구현하고 앱 내부에서 호출하는 형태로 제공을 한다. 제공하던 앱은 5년 넘게 서비스를 해왔던 앱이고 갑자기 리젝되어 약간 황당한 케이스였다. 리젝사유는 무료 사용을 하라고 권하면서 외부 사이트로 유도를 했고, 해당 사이트에서 가격 정책이 확인되어 가이드 위반이라는 내용이었다. 친절하게 첨부된 이미지를 확인해보니, 친절하게 타임라인 순으로 첨부되어 있었다. 서비스 이용 완료 > 무료 이용버튼 > 웹 사이트로 이동 > 열심히 탐험.... > 가격 정책. 역시나 심사하는 사람에.. 더보기
앱스토어 리젝 (CallKit) CallKit 은 iOS 10 부터 제공하던 개발툴로 통화기능을 이용하여 VoIP(Voice over Internet Protocol)를 이용하는 앱에서 주로 이용된다. 하지만 중국 정부의 요청으로 중국에서는 CallKit 을 이용할 수 없게 되었다. (2018년) VoIP 를 이용한 서비스를 제공하다보니 글로벌 고객들이 이용할 수 있어야 했고, 배포 국가를 전 세계로 확대를 했다. 최초 앱이 출시하고 전 세계에 동기화하는데 10시간 정도의 시간이 소요되었다. 그리고 8시간 4시간.. 점점 동기화 시간은 줄어들었다. 어느 날 갑자기 앱스토어에서 출시가 거부당하는 사태가 발생했다. 거부 사유 Guideline 5.0 - Legal Recently, the Chinese Ministry of Industry.. 더보기
앱스토어 리젝 (Sign in with Apple) 2019년 9월 Apple ID 간편 로그인 서비스가 제공되면서 2020년 4월부터 소셜 로그인 서비스를 제공하는 서비스에 대하여 심사를 강화하고 있다. 이에 따라 소셜 로그인을 제공하던 서비스들이 Apple 로그인을 추가하지 않을 경우 간혹 심사에서 리젝 당하는 케이스들이 나온다. 이는 심사하는 사람에 따라 랜덤으로 걸리는 사항이기 때문에 당황하지 않고 제공하는 서비스 취지에 맞게 사유서 작성 또는 Apple 로그인을 추가하면 통과된다. 개요 2019년 9월 12일 Apple 개발자 사이트에 게시된 Apple로 로그인에 대한 신규 가이드라인 사용자의 Apple ID로 앱과 웹사이트에 로그인하도록 하여 로그인 과정을 간소화할 수 있습니다. 개인정보 보호 및 보안 기능을 갖춘 Apple로 로그인을 활용하여.. 더보기
요구 사항_수집?분석?정의?명세? 우선 펼쳐보자 소프트웨어 공학의 입구에 서서 문을 열면 가장 먼저 반기는 것이 요구사항이다. 그리고 이렇게 시작한다. "고객은 자신이 무엇을 원하는지 모른다." 실제 모르는 것이 아니라 머릿속에 있는 것을 표현을 못한다는 말이다. 이것을 구체화하는 작업이 요구사항 정의이다. 웹 에이전시나 SI 프로젝트를 경험하신 분들은 친근하게 느껴질 수 있을 것이다. 하지만 인하우스나 자체 솔루션을 오래부터 가져온 회사 직원은 필요성을 못 느낄 수 있을 것이다. 요구사항의 중요성은 구글에서 검색하면 나무에 그네를 만드는 이미지로 확인할 수 있다. 서론을 시작으로, 요구사항 수집 > 분석 > 정의 > 관리 4단계를 확인한다. (원문 보기) [SW Requirements] 요구사항 수집, 분석, 정의 기본편 소프트웨어 공학의 입구에 서.. 더보기
요구사항_Given When Then 이 어쨌다고?? 기획자가 Agile 을 공부한다는 건 유저 스토리에 대한 접근이 아닐까라고 생각해본다. 도서를 보더라고 Agile 의 한 부분으로 유저 스토리만을 다룬 책들이 많이 있다. 프로젝트의 단추인 만큼 중요하지만 다루는 것은 그다지 쉽지 않은 부분이다. 사전 지식으로 Agile 에 대한 이해가 필요하다. 서론의 시작 대충... 빠르게 개발해서 고객에게 전달하는 개발 방식이다. 그럼 어떻게 빠르게 개발을 할 수 있는가? 1. 개발할 내용을 작고 작은 조각으로 쪼갤 수 있어야 하고. 2. 작게 쪼갠 조각은 독립적으로 동작할 수 있어야 한다. 여기서 포인트! - 두 개의 문장을 작성했을 뿐인데... 막연하다. 어떻게 작성하라고?? - 유저 스토리를 작성하는 방법들이 나온 이유일 것이다. - As a, I want, .. 더보기
요구사항_기획자 몸에 맞는 SRS 사전학습 ->> [SW요구사항] 요구 사항 작성이 어려울때 하나씩 파헤치기 (경험기반) 기획자도 작성할 수 있는 수준의 SRS 를 제안해 본다. >> 템플릿 확인하러 가기 1. 표지 작성 [OOO] 요구사항 명세서, 작성(배포)일, 작성자 소속 2. 문서 확인 고객사와 개발사, 이해관계자들의 협의를 위한 공간 3. 문서 이력 문서의 변경 이력을 작성한다. 4. 서비스 개요 목적, 범위, 용어, 사양(성능), 설계, 참고 문헌 정의 5. 상위 수준 요구 사항 6. 기능 요구 사항 7. 비 기능 요구 사항 8. 이슈 리스트 (optional) 아래 링크에서 위 목차의 템플릿을 확인할 수 있다. >> 템플릿 확인하러 가기 SRS 작성 템플릿 SRS (Software Requirements Specificati.. 더보기
기획도 모듈화다! UX 전략 수립 UX 전략 기반의 모듈화를 실천해라. 화면설계서 작성 단계에 도달했다는 것은 이미 UX전략을 세웠을 것이다. 더보기 "욘나빠른피셜" UX란? 보통 UX = UI + Interaction 이라는 공식에 공감한다. 사용자에게, 우리가 제공하는 가치에 대하여 UI로 낚시를 하여 서비스 들어오도록 하고 사용자에게, 우리가 자신을 목적 달성을 위해 일을 하고 있음을 알려주고 사용자에게, 우리가 제공하는 가치가 사용자에게 만족이라는 피드백을 주어야 한다. 화면설계서는 말 그대로 화면(UI)을 포함하고 있다. 규모가 큰 제품이나 서비스의 경우는 여러 명이 같이 작업할 수도 있다. 이미 UX 전략 또는 아이데이션에서 대략적인 화면이나 UI컴포넌트가 정의되었을 것이다. 어디선가 주워들은 내용, 어떤 UX에이전시에서는 U.. 더보기
문서의 시작, 틀을 갖추자 (Document layout) 문서의 틀을 먼저 갖추자. 화면설계서 기반으로 기획서를 작성, 욘나빠른 Tip 모든 문서를 작성하기 전에 형식을 갖추는 작업을 먼저 할 것이다. 화면 설계서 문서도 예외는 아니다. 하지만 후배들 작업하는 것을 보면, 자신만 알아볼 수 있게 작업하는 경우가 종종 발견된다. 주어진 템플릿을 그대로 이용하는 케이스 우선 내용부터 채우는 케이스 명확한 기준을 세우지 않고 작업하는 경우, 중구난방으로 문서 작성이 시작되어 헤매기 십상이다. 또한 완성된 결과물은 자신을 위한 문서가 될 뿐, 리뷰자들이 보기 어려워진다. 모든 문서는 문서를 보는 사람에 맞게 작성해야 되는 원칙을 지켜야 한다. 그래서, 틀을 갖추는 이야기를 하고자 한다. 첫 번째, 표지에 "제목"과 "부 제목", "작성자"를 기입해라. 내가 다니고 있.. 더보기
지극히 개인적인 기획자의 체크리스트 (6~8) 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 6. 화면 설계시 기준 해상도를 설정해라. 화면을 설계할 때 기준 크기와 반응형에 대한 고민을 해야한다. 최소한 Min/Max 의 크기 기준으라도 정의해야 실제 개발된 산출물이 사용자 환경에 따라 원치 않는 모습으로 보여지는 것을 피할 수 있다. - Windows OS는 괜찮지만, Mac OS의 해상도는 작게, 보통, 크게 등..변태 해상도가 많으니 유의해야 한다. - SPA(Single.. 더보기
지극히 개인적인 기획자의 체크리스트 (4~5) 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 4. Backoffice (Admin) 사이트 구성 시, CRUD 를 지켜라 Backoffice 와 같이 관리자 웹 사이트나 서비스의 경우 Database를 기준으로 화면을 구성하게 된다. 이 경우, 비지니스 로직보다는 단순 조회, 수정, 삭제 기능이 메인이다. 기본 기능은 CRUD C (create) : 신규 생성 (new) R (read) : 조회 (search) U (update) .. 더보기
지극히 개인적인 기획자의 체크리스트 (1~3) 업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다. 그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다. 아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다. 작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다. 1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라 특히, 모바일을 중심 서비스가 증가하는 만큼 모바일에서 서비스를 이용하는 경우가 많다. 작은 화면에서 여러가지 기능을 수행하면, - 사용자가 사용하기 힘들뿐더러 컨트롤(사용)도 힘들기 마련이다. - 코치형 가이드가 마구마구 추가되어 복잡하게 될 수도 있다. - 복합한 UI이나 기능은 사이드 오류를 양산하기도 한다. 특히 우리는 .. 더보기
플랫폼 별 Design Guide 한 눈에 보기 (Fluent Design System) 기획자도 각 플랫폼별 디자인 가이드를 알고는 있어야 합니다. (옵션 사항) 디자인 가이드는 각 플랫폼의 아이덴티티와 특색을 잘 표현하고 있어서 개발자 사이트를 통해 얻는 것보다 빠르고 쉽게 정보를 습득할 수 있습니다. Microsoft Design 사이트에서는 각 플랫폼의 디자인 가이드로 링크가 연결되어 있어 편하다. www.microsoft.com/design/fluent/#/ Web, Windows, 모바일 등 주요 플랫폼에 대한 디자인 가이드를 확인할 수 있다. 아래 이미지를 보면 좌측에 각 플랫폼을 선택하여 동일 컴포넌트에 대하여 확인할 수 있다. developer.microsoft.com/en-us/fluentui#/controls/mac/date-picker Microsoft 의 Fluent .. 더보기
기획자가 알아야할 잡학다식 (기획자도 개발팀원이다.) 기획하는데 개발을 왜 알아야 하죠?? 라고 생각하는 사람이 아직도 있는지 모르겠지만, 혹시 모르는 마음에 기획자도 알아두면 좋은 지식에 대해 다루어 본다. 개발은 SW가 만들어지는 모든 과정을 통칭하는 용어로, 기획자는 개발을 알아야 한다. 단, 코딩을 알 필요는 없다. 이런 것들이 기획자가 범하는 가장 많은 오류이다. 이런 것들 => 용어의 잘 못된 이해 기획자의 개발 용어 알아가기 SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 운영까지의 모든 단계를 일컫는다.즉, 요구사항 > 설계 > 구현 > 검증 > 운영 의 모든 프로세스를 포함하고 있다. 나 때는 말이야, 기획? 1. 개발 (Software Development) SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 .. 더보기
의사결정을 위한 스킬 (consensus building) 본 글은 필자의 경험과 교육, 세미나를 통해 얻은 지식을 바탕으로 공유하는 내용입니다. 아래는 HRD 에 실린 퍼실리테이션 파트에 언급된 내용을 소개합니다. 퍼실리테이션은 회의와 같은 여러 사람이 의견을 내고 합의를 도출해야 하는 상황에서 원활하게 진행될 수 있도록 촉진제 역할을 한다고 생각하면 된다. 회의 종류에 따라 필요한 퍼실리테이터의 역할과 스킬이 다양하다. 여기서 말하고자하는 내용은 내외부 커뮤니케이션이 많은 기획자에게 원활한 회의와 의사결정에 도움이 될 만한 부분을 갈무리하여 소개한다. 회의 중 발생할 수 있는 문제에 대한 진단 예. 행동 사례(증상) 문제 상황 진단 문제의 원인 1 “시간 낭비 하지 맙시다. 이곳에서 그런 일은 절대 일어나지 않을 겁니다”와 같은 발언이 나온다. 냉소주의 집단.. 더보기