온톨 완전개편 프로젝트 회고(기획 단계 회고)

이승훈·2023년 10월 14일
1

시행착오

목록 보기
15/23

0-0. 시작

23년 4월 기존 시중에 배포하였던 POC버전의 온톨을 완전 개편하자는 상부의 지시가 떨어졌다.
바라고 있던 바 지체없이 시작하였다..
그리고 그렇게.. 여름이 순삭되었다.

0-1. 기획

현재 POC버전은 MRI, CT, 초음파, 조직 검사등의 의료 검사 결과지의 해석 기능만 제공하고 있다.
POC버전 또한 결과지 해석에 대해 많은 개선을 거듭해 왔다.

맨처음 업로드한 결과지에 대해 사람이 직접 읽고 수동으로 결과지에 대한 해석을 제공해주던 버전에서
OCR 엔진을 사용하여 텍스트를 뽑은 후 AI를 이용하여 투박한 해석을 제공해주는 버전
이후 유저가 알기 쉽게 핵심요약을 제공하고 어려운 용어에 대한 설명을 제공해주는 버전까지

허나 우리는 단순히 결과지 해석만을 제공해주는 의료계의 파파고가 되고싶은것이 아니다.
환우에게 결과지해석뿐만이 아닌 다양한 서비스를 제공해주고 그들만의 커뮤니티를 형성하게 해주기위해 온톨어플리케이션을 완전히 뒤바꾸기로 결정했다.

0-1-0.기획 시작

개발자이기전에 프로덕트의 작은 주인으로서 회사의 개발팀인원들 중 몇몇은 기획에 직접 참여하였고 나도 그중 하나였다.
총 두달간 매일 점심 14시 기획미팅에 참여하였고 기획결과 새로운 온톨에 추가되는 기능은 아래와 같이 3가지로 결정되었다.

  • 커뮤니티
  • 건강검진 조회 및 요약 제공
  • 보험 상담

기획 참여인원은 디발자1, 개발자2, 의사1 총 4명이었으며(디자인 초안은 외주로 진행) 디발자와 나는 기획회의가 끝난 후 각자 맡은바에 따라 그날의 기획회의내용을 기반으로 문서 및 디자인을 작업하였다.

그렇다.
우리는 기획자가 없다.
그리고 디자이너도 없다...

디발자

개발인원 중 한명은 디자인을 서브로 공부하고 계신분이며 디발자라고 불렸다.
디발자분은 UI/UX에 대한 지식이 풍부하였으며 피그마이용에 능통하여 미팅 결과에 따라 디자이너에게 외주로 받아온 디자인을 기반으로 피그마를 수정 및 보완해주었으며 피그마를 사용하여 userFlow를 제작해주었다.

하기 이미지는 디발자가 작성한 userFlow 일부이다, 화면간의 이동흐름을 보기 쉽게 정리해주었다.

그리고 나

나는 이전 보고서를 위한 보고서를 위한 보고서를 만들던 LG때의 보고서 작성 경력을 살려 기획회의 내용을 기반으로 기능명세서를 작성하였다.

기능명세서는 각 화면에 대한 세부 설명과 기능에 대한 내용을 담고 있으며 각 화면에 대한 기본 내용들은 아래와 같은 포맷으로 작성하였다.

  1. 화면 요약:
  2. 상세 기능 명세
    • 목표:
    • 세부사항
    • 조건:
    • 시나리오:
  3. 관련 정보
  4. 참고 문서

기능 명세서를 작성하며 각 화면의 목표, 시나리오를 고민하는 과정 중 어떻게 하면 유저 친화적으로 어플리케이션을 개발할지 고민할 수 있는 시간이 되었으며 버튼 하나의 기능, 문구하나하나 상세하게 작성된 명세서는 추후 개발을 진행함에 있어 명확한 기준이 되어주었고 불필요한 커뮤니케이션 비용을 대폭 줄여주었다.

0-2.기획 단계 회고

기획 관련 미팅은 약 1.5개월간 진행되었다.
전문 기획자 없이 디발자1, 개발자2, 의사1의 인원들로 진행된 기획치고 꽤나 촘촘하게 기획하였다고 생각한다. 기획 단계의 K,P,T를 정리하자면 아래와 같다.

keep

기획 진행 중 가장 신경을 많이 썻던 부분은 그날그날의 결정사항들을 문서에 촘촘히 기재하려한 점 이다.
작성한 문서들은 살아있는 문서로서 프로덕트의 개발단계뿐 아니라 먼 미래에 유지보수를 진행함에 있어서도 사내 표준으로서 존재하길 바라며 작성하였고 현재까지 그 명맥을 유지해가고 있다.

problem

가장 큰 위기는 본인이 위기인지조차 인지하지 못한것이라 하였다.
맞다.
그것이 지금 바로 나다.
기획은 어떻게 하는건지 진짜 기획자들은 어떻게 프로덕트의 기획을 진행하는지 난 알지 못한다.
왜냐하면 난 기획자랑 일해본적이 없거든.

그럼에도 스스로 문제점이라고 느낀 부분은 아래와 같다.

  • 개발비용을 너무 고려한 점

어떠한 결정을 함에 있어서 이 선택보다 더 쉽게 개발을 하되 유저에게 제공하는 서비스 경험의 질은 그다지 차이가 나지 않는 다른 방법은 없을까? 에 너무 매몰되었다.
더 나은 유저경험을 위해선 다소 어려운 개발을 해야하는 순간이 있음에도 개발 비용을 절약하고 싶다는 욕심에 사로잡혔다.

기획단계에서 선택은 개발자를 위한 선택이 아닌 유저, 고객을 위한 선택을 해야함을 잊었던것이 스스로 가장 고쳐야할 점 이라고 생각한다.

try

개발비용에 매몰되었던건 어쩌면 편하게 일하고 싶다는 욕심에서 비롯된것이 아닐까 싶다.
허나 이번 전면개편 개발을 진행하며 어려운 난관을 마주하고 넘어서고 해결하는 과정에서 느꼇던 짜릿함은 다시 또 스스로를 어려운 난관으로 몰아넣기에 충분한 경험이었다.
이후 다시 기획에 참여할 기회가 생긴다면 개발자로서가 아닌 한명의 프로덕트 주인으로서 기획에 참여할것이다.
또한 어려운 난관을 두려워 하지 않고 진정 유저를 생각한 의견을 낼것이다.






회고 (Retrospective)에 대한 정리 및 설계(JaeYeopHan)
온톨 소개 페이지

profile
Beyond the wall

0개의 댓글