기획93 개발 과정에서의 중간 산출물 요구사항 정의서 기획 초반에 요구사항 정의서를 분명히 남겨서, 도메인 전문가의 요구사항을 반영할 수 있도록 한다. 워터폴 방식으로 진행할 때에도도메인 전문가의 의견이나, 상호 소통 부족에 따라 요구사항은 새롭게 정의될 수 있다. 이는 요구사항에 대한 추적표를 통해 별도 관리하여 최신화될 수 있도록 한다. 요구사항 추적표도메인 전문가 또는 프로젝트 참여자의 착오로 기존 요구사항이 변경될 수 있다.혹은 프로젝트 진행 과정에서 터지는 현실적인 문제들도 원인일 수 있다. 필요하면 다음 기회로 해당 요구사항을 넘겨야 할 수도 있고,아예 개발요건에서 삭제도 가능하다. 화면설계서도메인 전문가와 업무를 진행할 때,실제로 커뮤니케이션 가능한 시점은 바로 이 시점부터라고 생각이 든다. 요구사항에 화면설계가 대응될 .. 2025. 1. 25. 랜턴의 서비스 기획 이야기 11 늦어진 개발 환경 구성 22년도 연말부터 인프라에 대한 결정 요구가 개발파트로부터 있었다당시 나는 그게 무얼 의미하는지 몰랐고, 당장 눈 앞에서 기획 의사결정하기에 바빴으므로, 의사결정 요청의 중요성에 대해 크게 인식하지 못했다. 하지만 새해에는 달랐다. 기본적인 요건 정의도 얼추 끝나는 단계였으므로,개발파트에서 더 강도 높게 인프라 결정에 대한 요구를 해왔다.인프라는 웹보다도 나에게는 완전 생소한 영역이었으므로 공부가 필요했다. 클라우드 서비스가 무엇인지 클라우드 서비스 프로바이더는 어떤 업체들이 있는지 등 등 정말 기본적인 시장 조사부터 빠르게 마쳤다. 하지만, 현 단계에서 어떤 스텝을 밟아야 할지는 경험과 가이드가 없는 나로서는 여전히 당황스러웠다. 내가 의사결정할 수 있는 것은 무엇인가? 어디까.. 2025. 1. 3. 랜턴의 서비스 기획 이야기 10 운이 좋게 시작한 프런트 엔드 공부 11월에 사내에서 Udemy 계정을 준다고 하여, 좋은 기회다 싶어서 잽싸게 신청했다.욕심은 기획하는 동안 필요할 수 있는 모든 강의를 듣고 싶었다. 백엔드, 데이터, 프런트엔드 ,디자인 .. 등 등.계정이 당해 12월까지 만료였기 때문에, 수강에 대한 전략을 세워야 했다. 당장 하고 있는 방식의 전문성을 높이는 게 필요하다 싶었다.이에, 프런트 엔드 강의를 듣기로 하였다. 나는 수학에 대해서 욕심을 좀 많이 내는 편이라,실습 포함 600강 정도 분량이 되는 강의를 선택했었다.기간이 45일 정도 되었으므로, 주말 제외 30일 정도로 잡고하루 평균 20강 정도 들으면 어림 잡아 완강 가능하다고 계산했던 것이었다.강의를 2배속으로 들으면 실질 수강 시간은 10강 남짓에 .. 2024. 12. 29. 랜턴의 서비스 기획 야이기 9 분석단계에서의 기획에 대한 무지 -> 소통이라도.. 나는 당초부터 기존의 개발 업체를 유지하는 방향으로 업무를 추진했다. 사유는 아래와 같았다, - 이 웹이 달성하고자 하는 비즈니스 목적을 설명하고 이해시키는 것이 가장 어렵고 - 컨센서스를 만드는 데 소요되는 시간 비용이 적지 않을 것이라는 생각이 있었으며 - 기존 매터리얼을 참조하여 구조를 유지하는 데도 이 편이 편했기 때문이었다 사용자 분석과 비즈니스 분석을 명징하게 하지는 않았지만,이전의 기획서와 비슷한 몇 가지 아이템들로 감각적인 컨센서는 확보할 수 있었다.그럼에도 불구하고, 나의 개선에 대한 의지 + 대대적인 디자인 개편이 있었기 때문에개발 그룹은 어디서부터 요건을 정리해 나갈지 감을 잘 못잡는 편이었다이는 당시 지식적 경험적으로 불완전.. 2024. 12. 22. 랜턴의 서비스 기획 야이기 8 첫번째 컨셉 디자인 그리고 나의 문제점 : 디자인에 대한 무지 8월말에 우리는 크게 3가지의 컨셉 디자인을 뽑을 수 있었다- 마케팅 커뮤니케이션 가이드에 의존한 디자인- 업체가 평소에 자주 하던 디자인- 3D 콘텐츠를 보여주는 시스템이라는 점을 최대한 UI적으로 부각한 디자인 차라리 어떤 것이 미학적으로 촌스러움이 확 부각되었다면 문제가 쉽게 풀렸을 터였다.하지만, 디자인을 하시던 분이 디자인 했으므로 기본적인 미학성은 보장되었다.그러니까, 나는 시안까지 제작을 시켰음에도 여전히 결정할 수 없었다. '무엇이 좋은가?' 선택하기도 중요했지만, 나는 그것보다 근원적인 문제가 있음을 알았다. '바로 왜 나는 결정할 수 없는가? '라는 문제였다. (쓰면서 느끼는 건데, 나는 확실히 스스로에게 어려운 질문을 .. 2024. 12. 18. 랜턴의 서비스 기획 야이기 7 돌아보았을 때 아쉬웠던 점 내가 IT 기술 조직이 있지 않았기 때문에,또 협력업체 역시 전문 PM 인력 구비가 안되었었기 때문에,산출물과 프로젝트 매니지먼트가 제대로 이뤄지지 않았다.가령, 이 단계에서 우리는 기획에 대한 보다 면밀한 조사 단계와RFP를 작성했어야 했다. 우리가 가진 것은, 본부장님 상대의 보고 자료와 그 보고자료를 만들기 사전에 나 홀로 파워포인트로 만든PPT에 가까운 요건 기획서가 있었다. 그것으로는 수개월 동안 지속해서 참조할 자료로는 역부족이었던 것이다. 당시에는 하지만 어떻게 해야 할 지 몰랐다. 내가 업무를 추진하는 방식과 스킬에 부족한 점이 있다는 것은 경험적 / 감각적으로 알고 있었다.다만, 팀 내에 나와 같은 생각과 시선을 공유할 사람이 없었다.그래서 어쩔 수 없이 나.. 2024. 12. 10. 랜턴의 서비스 기획 이야기 6 공식적인 기획 보고 결국 웹 개발하는 것으로 큰 가닥을 잡고, 웹 리런칭을 추진하기로 하였다. 프로젝트 기획 보고를 해야했는데, 보고서를 쓰는 데만 1달이 걸렸다.그 때는 보고서가 무언지도 모르고, 작성해서 좌충우돌이 많았다. (한편, 내가 속한 부서가 IT부서가 아닌 것도 한 몫 했는데, 내 관점에서 유능하고 유의미함을 어필할 이야기들은 대개 기술적인 부분들이었기 때문이다.읽는 사람의 IT 지식 수준에 맞추어 작성해야 했고,아마 대부분의 PM이 작성하는 것과는 완전히 다른 구성과 내용이 되어야 했다.)나중에야 이전 실장님한테 이야기를 들었는데,내 보고서의 내용에 대한 추가 질문을 한참 답변하느라 진땀 좀 빼셨다고 들었다. 지금 생각해보면(그 때는 내 생각이 매우 옳았기 때문에, 모든 것이 괜찮다고만 .. 2024. 11. 30. 랜턴의 서비스 기획 이야기 5 모바일 앱 통합에 대한 나의 직관 22년 상반기,단순하게 메뉴 추가를 통해서외관상 통합을 한다는 리더들의 의견을 제고시키고새롭게 서비스를 만들어서 통합하는 쪽으로 방향을 잡았다.B를 완벽하게 포용하기 위해서 A를 새롭게 런칭하자는 계획이었다 그리고 이윽고 두번째 문제가 덮쳤다.어떤 플랫폼으로 통합할 것인가? A웹은 사실 모바일 앱도 있었다.따라서, 웹으로 통합할지, 앱으로 통합할지가 문제였던 것이다. 나는 21년부터 앱 컨텐츠 기획/개발/운영을 이미 담당하고 있었다.따라서, 22년 상반기 시점에,나는 앱의 좋은 점과 웹의 한계를 꽤나 잘 알고 있는 편이었다. 웹 서비스 장점- 퍼블릭 네트워크를 통한 글로벌 런칭과 배포가 쉽다 - 컨텐츠별 URL을 달리하는 방법으로, 엔드컨텐츠 전달/배포가 쉽다- UR.. 2024. 11. 21. UX 라이팅 13 좋은 한 줄 문장 UX 라이팅 마지막 글이다. 이것 또한 실증 예시를 나중에 더 담아내어 시리즈의 완성도를 높이는 날이 오길 바란다 1 문맥을 담아낸다포괄적이거나 도입을 위한 문장은 쓰지 않는다대신에, 바로 핵심에 접근한다 UX 라이팅이 필요한 환경은, 지적 허영심을 채우기 위한 느긋한 독서나 독해의 과정이 아니다바로 사용자가 해야할 일을 지시하고 알려줘라.이를 위해서는 불필요한 단어를 제거해야 한다.과한 수식어도 필요 없다사용자에게 전달하고 싶은 바만 명료하고 짧게 전달하여인지부하 없이 있는 그대로 사용자가 읽고 받아들이게 하자 2 유용함을 제공해라 기능은 개발자가 제공하는 것이다 기능을 소개할 때, 기능 자체를 소개하지 말자. 사실 대부분의 기능이란, 기술적으로 대단한 것들도 아니지 않은가?이를 표현하려 하면, .. 2024. 10. 13. 이전 1 2 3 4 5 ··· 11 다음 반응형
