서비스기획자 후디의 기록

문제 상황을 분석할 때,상황이 복잡하다 싶으면 [ 요청 / 응답 / 처리 ] 관계 플로우를 그리는 것이 좋다.*시퀀스 다이어그램이라 하더라. 문제가 어디에서 발생되고,그 문제를 어떻게 해결하면 좋을지,각 데이터를 처리하는 액터와 그 관계를 한 눈에 파악할 수 있다. [ 문제 : 예약 성공 후 타임아웃 오류 발생 시, 오류 상황을 사용자와 상품 공급사 시스템은 인지할 수 없음 ] [ 개선안 : 타임아웃 오류 발생 시, 상품 공급사 시스템에 취소 요청하고, 사용자에게 오류상황을 정확하게 안내 ] 1. 문제 원인 : 타임아웃 오류2. 타임아웃 오류를 막을 수 있는가?-. 100% 막을 수 없음. 사용자 또는 자사 네트워크 환경으로 인해 발생하는 이슈.3. 대안-. ( to. 상품 공급사 시스템 ) 타임아..

잘 돌아가던 시스템에서 오류가 발견되면,꼭 문제 발생 지점까지의 플로우를 그려본다. 어딘가 정상적이지 못한 부분이 있기에 문제가 발생한 것이니각 단계마다 수행되어야 일들을 체크한다. 컴퓨터가 어떠한 목표를 수행하기까지각 단계들은 명료하게 나눠져 있다. 그리고 그 단계들은 거의 " 주고 받는 " 일을 수행한다.흔히 알고 있는 "요청( Request )과 응답 ( Response )이다." [ A ] --- ▲▲ 해줘 ---> [ B ][ B ] ▲▲ 처리[ B ] --- ▲▲ 처리했어 ---> [ A ] 이렇게 일이 수행된다면,단계는 아래와 같이 잘게 쪼개진다.그리고 어느 단계에서 문제가 생겼는지 파악하기 쉽다. 1. A가 무엇을 요청했는가 : ▲▲2. A가 어디로 요청했는가 : B3. B가 A의 요청을..

온라인/IT/개발의 세계에서 문제가 발생하면,아래와 같은 과정이 이뤄진다. *핵심 : 코딩보다 문제 원인 찾기가 매우 오래 걸리고 힘들다. 1. 문제 발생 - 버그(문제)가 발생했다. 위이이잉~ - 야생의 개발자가 문제해결에 나선다. 2. 원인 짐작 및 분석 : Why - 왜 문제가 발생했나... - 원인으로 짐작되는 모든 가능성을 추측해본다. 3. 어디를 고쳐야 하나 : Where - 프론트엔드? 서버? 프론트엔드의 어디? 서버의 어디? - 이 수 많은 코드 중에 어디? 4. 어떻게 수정해야 하나 : How / 코딩 - 'abc' 코드를 'ab zc' 코드로 수정했다. 5. 부작용(Side Effect)이 발생했다! - 다시 1번으로 돌아가 원인을 찾아본다. 생각보다 3번 ..

기획은 문제해결의 연속이다. 문제가 발생하고,이를 해결하기 위한 방안을 열심히 찾는다. 더 나은 방안이 무엇인지 비교하고, 숙고한다.이때 각 방안의 "장단점"이 무엇인지 체크해야한다. 세상 어떤 일이든 장점만 있거나 단점만 있지 않다. 1. A안이 왜 좋은데? -> ~해서 진행하면 좋을거 같아요. 2. B안은? -> ~해서 안 좋아요 3. A안 단점은 없어? B보다 오래 걸리거나, 비용이 더 든다거나. -> ...!*회사 입장에선 시간적/금전적 비용 모두 단점으로 적용된다. 기막힌 솔루션을 가져와도그게 정말 BEST라 해도단점은 꼭 파악해보자.그 단점이 미비하다면, 그것을 상쇄하는 장점을 이야기하고진행하면 된다.

B2C몰을 더 편리하게 고치자고 한다. 기능도 추가하고, UI도 개선하고 너무 좋다.그런데 이렇게 멋지게 편리하게 만든 상품을 사람들이 어떻게 알고 구매할까? 우리 회사는 네이버 검색 광고, 구글/메타/카카오 광고, 인스타그램, 네이버 블로그를 운영한다.챗GPT, 제미나이에게 물어봤다. "OO 예매 어디서 하면 좋을지 추천해줘"타 경쟁사 사이트를 보여준다. 출처를 보아하니 OO 예매 관련 최신 글이 많다. "@@ 사이트는 어때?" 우리 회사 몰에 대해 고맙게 장점을 나열해준다.출처를 보아하니 1년 전 네이버 블로그 글, 5년 전 기사 본문이 나온다. 상품을 알리는 여러 방법이 있지만,요즘 AI 추천으로 돌아가는 추세를 보면, 양질의 대량 컨텐츠가 중요하다는 것을 느낀다.인스타그램/유튜브가 어렵다면자사 사..

2019년 6월 - 26살. 취업이 하고 싶었다.신문방송학과를 졸업하고 언론은 제 길이 아니라 생각하여, 문과가 주로 간다는 영업을 기웃거렸다.그렇게 B2B 영업으로 들어갔다. 한 회사에서 B2B영업과 영업지원으로 4년을 일했다.작은 이커머스 회사라 영업 뿐만 아니라 상품 주문-제조-배송-CS를 경험하고,제휴사와의 계약-주문관리-정산 등을 담당했다.영업으로서의 성장을 기대했지만,주 업무는 영업지원이 되어 진로 고민을 했다. 그때 마침 서비그 기획이라는 업을 알게 됐다.기업제휴 사이트 홈페이지를 기획하고,계약/주문 정보 데이터를 관리하는 시트를 기획하고,그동안 해왔던 업무들이 알게 모르게 서비스 기획과 연결되어 있었다.아 지금까지 내가 해왔던 일 중 일부가 서비스 기획이었구나.그렇게 새로운 진로를 살펴보았..

1. 개발 인력이 이렇게 많은데,왜 우리 프로젝트 결과물은 빨리 안 나오는지윗선들은 항상 궁금하다. 3명의 인력이 6명이 됐으면, 2개월 걸린다는 프로젝트는1개월 만에 나와야하는 것 아닌가? 2. 이건 IT업계와 소프트웨어 개발 구조를 모른다면충분히 할 수 있는 말이다. 보통 사람들은소프트웨어 개발 구조보다과거부터 오랫동안 봐온농사, 건축, 토목 등에 익숙해져이에 빗대어 IT 기술을 바라본다. 농사, 건축, 제품 제조업은인력이 많으면 시간을 줄어드는 사업이다.돈으로 시간을 사는 개념이다. 컨베이어벨트 마냥생산하고, 넘기고, 조립하고, 넘기면제품 하나가 뚝딱 나온다. 한 섹션에서 너무 느리다 싶으면사람을 투입해서빨리 빨리 다음 단계로 넘기면 된다. 스타크래프트에서 미네랄(자원)을 많이 얻고 싶으면일..

들어가며 서비스 기획의 첫걸음은 단순히 화면을 그리는 것이 아니다. 서비스 기획자는 먼저 정책을 수립해야 한다. 이 정책은 구체적인 정의에서부터 시작된다. 예를 들어, 서비스의 백오피스를 구축한다고 가정했을 때, 먼저 "백오피스란 무엇인가?", "백오피스를 사용하는 주체는 누구인가?","그들이 어떤 역할을 하고 어떤 요구사항을 갖고 있는가?"를 명확히 정의해야 한다. 이렇게 정의된 사용자와 그들이 필요한 기능들을 바탕으로 백오피스 시스템을 설계할 수 있다. 백오피스 내에 '회원 관리'라는 페이지를 만든다고 할 때, 단순히 페이지를 만드는 것이 아니라, 왜 그 페이지가 필요한지, 페이지에서 어떤 기능을 제공할 것인지, 이 페이지를 주로 사용할 사용자는 누구인지 명확하게 정의해야 한다. 이러한 정의..

현재 내 나이 32살!돈을 차곡차곡 모으고 불려서5년 뒤 37살 "내 집 마련"을 목표로 한다. 내 집마련을 위해 부동산과 임장 등을 검색하니너무너무너무 좋은 정보들이 많더라. 북마크 대신 모아놔야지. 기본 개념​- 부동산 매매가 고점 보는 법- 보통 집주인이 실거주하는 경우에는 근저당이 있는데, 근저당+계약금+중도금이 집 매매가격을 넘어가면 절대 안됨. 임장- 임장 가기 전 준비 - 임장 체크리스트 부동산 방문- 부동산 방문해서 꼭 보는 것- 부동산 계약 협상의 기술- 부동산 계약 쓰는 법​- 여름 휴가철, 태풍 오는 날, 연말 연시 등 사람들이 집 보러 안 다닐때 부동산 가기.

서비스 기획을 할 때 자주 하는 실수 서비스를 기획하다 보면, 본래의 목적이나 방향성은 분명히 존재했음에도 불구하고, 어느 순간부터 이것저것 좋아 보이는 기능들을 덕지덕지 붙이게 되는 경우가 많다. 처음에는 명확한 목표와 방향을 가지고 시작했지만, 기획이 진행될수록 "이 기능도 있으면 좋을 것 같은데", "저것도 넣으면 사용자가 좋아하지 않을까?" 하는 생각이 하나씩 스며든다.특히 특정 부서의 요구사항을 반영하다 보면 이런 현상은 더 심해질 수 있다.원래 하려던 핵심 기능이나 서비스 목적은 분명 존재했지만, 중간중간 다양한 아이디어와 요청이 들어오면서 하나씩 기능이 추가되는 것이다.사용자 편의성을 위한 것일 수도 있고, 단순히 보기 좋거나 멋져 보여서일 수도 있다. 문제는 이렇게 기능을 하나둘 더하다 보..