앞으로 프로젝트 방향성

[jminkkk]

탐색 vs 관리 vs 새 문제 찾기

2차 데모데이 마감 이후 우리 서비스의 방향성에 대해 논의합니다.

우리 서비스가 중점적으로 해결할 유저의 문제점는 무엇일까요

[HoeSeong123]

관리 방향으로 가고, '코드 잽(zap)' 이라는 명성에 걸맞게 정말 편하게 작성할 수 있고 정말 편하게 관리할 수 있게 하는 방향으로 잡으면 좋을 것 같음
여러 가지 방면에서 '편하다' 라는 점은 지스트와의 차별점이 될 수 있을 거라고 생각함

ex) 마이페이지 에서 검색 기능, 카테고리 등 필터링 기능

[zangsu]

관리

관리 기능에서 사용자 편의를 적극적으로 개선하자.

Gist 를 써 봤을 때 충분히 귀찮은 점 / 불편한 점 들이 있었고, 이 것을 개선해 "귀찮지 않은 서비스" 가 되는 것 만으로도 우리 서비스의 매력이 생긴다.

ex)

• 카테고리 필터링
• 코드 소스 폴딩 기능
• 모든 언어에 대한 하이라이팅
• 빠른 복사
• drag & drop
• 썸네일 스니펫의 시작 위치 조정 기능
• description 추가
• 단축키
• 버전 / 의존성 표시 기능 (SpringBoot 몇 버전 / 어떤 라이브러리 를 사용했는지)
• ...

+) 이 외로 코치들이 말해줬던 "친절함" 을 제공해 주는 방향을 같이 고민해 보는 것 만으로도 우리 서비스의 정체성이 잘 세워질듯!

[Jaymyong66]

마위의 의견

피봇을 하자..

코드 기반의 SNS 피드 or 단톡방 느낌

사용자 시나리오 :

• 취업준비생: 개발자취업 공부 인증스터디를 하는데 그냥 시계 사진을 찍어 인증하지 말고, 오늘 내가 짠 코드 중 제일 멋있는 코드를 올리고 스터디원들은 응원이나 코드 관련 코멘트를 남기자~
• 알고리즘 스터디원: 알고리즘 스터디를 하는데 문제풀이 인증 글 캡쳐를 찍어서 단톡에 올리지 말고 코드를 올리자. 개선점을 피드백해줄수도 있고

기존 서비스와 다른점 :

• 카톡방과 달리 코드 하이라이팅, 에디터를 넣을 수 있고 언어로 검색등도 가능
• 글, 사진이 아닌 코드로 보여줄 수 있어서 SNS 진입 장벽이 낮음

이점 : 다른 도메인보다는 코드 템플릿, 스니펫 관련 도메인이나 프론트 컴포넌트는 가지고 피봇할 수 있지 않을까...

사실 지금까지 인프라쪽이나 개발->배포 위주의 작은 사이클을 한 것 같아, 디자인이나 개발해야하는건 지금부터 본격적이라 작업량은 피봇하건 말건 비슷할 것이라 판단함. 굳이 초심을 지키자고 피봇을 안할 이유는 없어보임

code-zap을 그대로 쓸 수 있다 ㅋㅋ

ps) 관리 vs 탐색이면 관리쪽에 가깝긴 함.
다만 프론트개발자 3명이서, 전문 디자이너가 아닌 이상 UX적으로 얼마나 이점을 가져가서 지스트를 이길 수 있을 지는 미지수.

[Hain-tain]

1. 관리를 더 잘 할 수 있게 도와주는 쪽으로 가는 것이 우리의 첫 출발선을 잘 지킬 수 있는 방법이라고 생각한다.

• 그렇다고 검색을 아예 하지 말자는건 아니고, 그냥 키워드 검색 있으면 좋을 것 같다! 내가 썼던 걸 검색을 통해 빠르게 잘 찾을 수 있게 하는 것도 관리에서 중요한 역할이라고 생각하기 때문이다.

2. 탐색으로 갈 경우, 계속 양질의 코드를 우리가 올려야 한다는 것이 부담스럽고 아쉽다.

• 탐색을 하려면 정말 양질의 코드가 많아야 한다. 그만큼 우리가 커버리지를 할 수 있을지가 의문이다. 따라서 언젠가는 사용자가 입력을 많이 하게 해야 한다. 탐색이 잘 된다는 이유 하나만으로는 내 코드를 막 올리고 싶을 것 같지는 않다. 결국 코드를 올리게 해야한다..! + 이럴 경우 양질의 코드를 올리게 해야하는데 그게 더 어려울 것 같다.

3. 다만 관리쪽으로 갔을 때 현실적으로 우리의 2주간의 할일을 정할 때 백엔드 분들이 또다시 페어프로그래밍을 많이 하셔야할 것 같아서 걱정이 된다.

• 사용자를 위해 UX를 개선하는 것은 사실 어떤 기능의 변경이라기 보다는 프론트에서 처리해주어야 하는 일이 많다. 결국 도메인이 추가되거나 기능이 추가되는것이 아니기 때문에 그 부분을 핵심 기능으로 가져가게 된다면 백엔드 입장에서 프로젝트 규모가 많이 작아보일까봐 걱정이 되긴 한다.

[jminkkk]

관리로 가자

1. 비교대상인 Gist 역시 관리에만 문제를 정의하고 있지 않는데, 애초에 이를 비교하는 것이 적절하지 않는 것 같다.

• (instantly share code, notes, and snippets.)
• 탐색과 관리을 모두 문제점으로 가져가는 서비스이다.
• 관리라는 기능이 있어서 비교했지만, 팀원들에게도 관리에 대한 불편함을 많이 느꼈기 때문에 아예 비교하지 않아야 된다고 생각한다.

관리에만 집중하면 우리가 더 좋은 서비스를 만들 수 있을 것 같다는 생각이다.

2. 문제가 명확하다.

따라서 탐색에 대한 부분을 아예 배제하고 관리로만 가는 것이 적절할 것 같다.

다른 부분으로 변경했을 때 우려되는 점

1. 다른 기능의 문제점이 관리와 달리 모두에게 공감될 것이라는 보장이 없다.
2. 우리 서비스의 릴리즈가 더 늦어질 수 있다.

[kyum-q]

의견 - 관리

문제가 명확해야한다고 생각한다

우리가 아이디어의 시작을 생각해보자 아이디어가 문제를 토대로 도출되었다.

• 문제 ) 중복되서 사용되는 코드 스니펫을 찾아 보기 불편하다 (관리가 불편하다)

  • 블로그는 글이 많아서 코드만 보기 힘들고, github는 프로젝트 단위라고 생각

• 프로젝트 개요 ) 코드 스니펫만 저장할 수 있는 서비스를 개발하자

• 하지만 현재 문제를 명확하게 정의하기보다, 문제가 명확하지 않으니 서비스 발전을 위해 탐색 방향으로 가자 라는 의도가 좋지 않다.

• 서비스 개선을 위해 도출된 아이디어는 문제로부터 도출된 아이디어를 이길 수 없다고 생각한다

  • 문제를 느끼고 서비스를 개발해야한다고 생각한다

• 즉, 아이디어를 변경하고 싶다면 명확한 문제가 도출되어야한다고 생각한다.

• 그리고 일부 사람들이 해당 사이트의 이점을 못느끼는 것은 어떤 프로젝트에서든 있을 수 있는 일이다.

  • 필요성을 느끼는 사람만 서비스 고객으로 보면 된다고 생각

지스트와의 차별점

• 지스트와의 비교로 탐색 아이디어까지 나온 것인데, 탐색이 오히려 지스트가 더 완벽하다고 생각한다.
• 변화구는 관리 측면에서 찾아야한다
  • 카테고리 도입
  • 디자인 변경

결론적으로 탐색이 아닌 관리가 중점인 서비스가 나을 것 같다

• 정확한 문제 도출 → 서비스 도출
• 지스트와의 변화구는 관리 측면에서 생각하는게 더 좋다고 생각
  • 카테고리 도입
  • 디자인 변경

[vi-wolhwa]

1. [기능] 코드 설명
   o 문제점 : 블로그 아니야?
   o 블로그 : 글이 많아 코드를 찾기 어렵다.
   o 코드잽 : 초기 트위터 처럼 최대 길이를 두자.
   o ________ : 코드 중심의 블로그 느낌은?
2. [UX] 파일 드래그 앤 드롭
3. [UI] 사용자 친화적인 UI로 개편하자.
   o 지스트를 떼고 생각 하기 어려움