팀 구성
(토스)
목적조직 : 이체화면 팀, 대출팀, 자산관리팀 등으로 쪼개져 각 파트의 업무에만 매진. 결과물을 빨리 낼 수 있음
근데 토스가 거의 변화가 없던거 같은데 이 조직 구성이 효율적인거 맞을까?
적산을 할 때에도 파이프, 공기조화덕트, 유독가스관을 담당자를 나눠 산출했었다.
근데 그건 업무양이 너무나 많아 그랬던건데, 토스같은 서비스는 왜 많은 수의 개발자와 기획자가 필요한걸까? 사실 나는 20명 정도면 토스정도는 만들 수 있다고 생각하는 사람이다.
애자일과 스프린트 적용하기
애자일한 개발은 스프린트를 여러번 거치며 각 스크럼에서 개선사항과 실제 유저들의 니즈를 점진적으로 파아가는 갓이다.
근데, 이러한 방식이 먹힌다는 마인드는 다음의 전제를 기본으로 한다. 세상은 빨리 변하고, 빠르게 만들어 조각내사 검증을 하는게 유리하다.
세상이 그렇게 빨리 변하지 않는다면? 한번에 좋은 제품을 낼 수 있다면?
이제까지 모든 의문은 프로세스 중시 문화를 가진 디자인과 개발에 대한 나의 의문이었다. 내 결론은, 그 자리에 누굴 앉히든, 균일한 품질의 결과물을 시간 내에 내기 위한 방법이라고 생각한다. 잡스가 더이상 세상에 없어도 애플은 디자인적 탁월함을 놓지 않은 것처럼.
또 그런 생각도 든다. 애플이 새로운 디자인 가이드라인을 어떻게 수립한걸까? 이건 이런 애자일 프로세스를 쓰지 않았을것 같은데.
Uxui 디자인 프로세스
디자이너는 무슨 일에 참여할까?
기획:
문제정의,
아이데이션(솔루션 선택, 솔루션 스케치),
프로덕트 스펙 문서 작성(디자인은 디자인대로 작성하고, 개발자는 이 문서를 보고 먼저 구조를 구상할 수 있다. 디자이너가 이 문서를 적어보며 스스로 점검을 할 기회를 얻는다.)
디자인:
초안 디자인 : 디테일 보단 사용자 여정, ux(??)에 집중
피드백 : 프로토타이핑까지 해서 팀원들에게 공유
디자인 확정 및 핸드오프 : 피드백을 초안에 반영하여 최종 디자인 확정. 핸드로프는 엔지니어에게 디자인을 전달하는 과정을 말함. 디자인만 공유하면 안되고, 유저플로우, 유즈케이스(상황에 따른 화면 정의), 반응형 레이아웃 가이드라인
프로덕트 스펙문서
제품 요구사항 정의사라고도 한다. 크아악 이거 적느라 2주동안 머리를 싸멨다.
기획배경, 솔루션, 기능 요구사항, 실험 계획
기획배경 : 문제 발견과정, 문제 선정 이유, 문제의 원인
솔루션 : (디자이너의 역할 매우 중요)
페르소나
사용자 시나리오(페르소나랑 뭐가 달라..)
기능별 주요특징 & 요구사항
예외 상황 및 edge case 정의
최종 시안
실험
문제 해결안의 적용 결과, 이 성과를 측정하는 방법에 관해 기준을 수립
위 프로덕트 스펙 문서는 계속해서 업데이트 되어야 함.
중요
좋은 피드백을 받는 방법?
디자인 업무는 사실 피드백을 받고 수정하고를 반복한다. 디자인과 필요한 정보를 함께 전달하는게 좋다. (배경, 솔루션 의도, 내 요구를 듣는 사람을 지정, 영향을 받을 사람들에게도 알리기, 피드백 기한)
강사님 예시를 보고, 회사 내에서 의사소통 방법으로 노션을 쓰는 것에 대한 이해
솔직히 좀 파편화 되어있다고 생각한다.
협업
"협업의 질은 제품의 질을 결정한다."
너무나 공감하는 말이다. 리소스 낭비없이 핵심을 지목해서 좋은 결과물을 내는 것이 팀플레이의 핵심이라고 생각한다.
각 구성원의 역할을 알면, 협업 시 말을 걸고, 무슨 일을 하는지 물어보지 않아도 어느정도 알 수 있다. 당연히 알아야 란다는 말이다.
PM
제품 개발 전략을 수립하고, 우선순위를 정해서 실행하는(?)사람이다. 실무자.
PO
관리자다. 미니ceo라는 별명이 있다. PM보다 더 많은 책임이 주어진다.
제품팀을 이끌고, 관리하며, 환경에도 설정을 맡는다. 이해관계자와도 이야기를 나누게된다.
But, 회사 by 회사
엔지니어
프론트엔지니어
화면 내 컴포넌트와 ui를 구현
동적 웹(인터렉션) 구현
Ux의 질 결정
백엔드엔지니어
정보의 저장과 전송, 서버 엔지니어
QA엔지니어
QA 테스트를 수행
데이터애널리스트
BX디자이너
브랜드 경험과 관련된 전반적인 디자인을 하는 사람. 브랜드를 나타내는 모든 부분을 담당. 내가 좋아하는 것...
Ux writer
제품 내 문구를 작성하는 사람. 문구 라이터. 규모가 작으면! 당연히 디자이너가..
실험문화
각 팀의 구성원을 알아봤으니, 어떻게 일하는지도 바라보자.
애자일은 각 스프틴트동안 스크럼을 수행한다고 배웠다. 쉽게말해, "번갯불에 콩볶아 검증해봐" 라는 거다.
개인의 주관이 이 빠른 주기 내에도 반영이 당연히 된다. 그런데 시장이 원하지 않는다면? 헛짓거리가 될테니 실험해서 나쁠거 하나 없고, 혹시나 미스매치를 적발하면 그거로 제 역할을 충분히 해낸거다.
실험방법
A/B 테스트
A조에는 원안, B조에는 개선안 주고 성과가 났는지 실험. 지표를 측정.
변수는 1개! 행동의 긍정 부정을 관찰. 사용자에게 공감하고 이해도를 높이는게 궁극적인 지향점이다.
제품 분석도구
와.. 참 많이 배운다.
이건 사이트 툴이다. 앰플리튜드와 구글 애널리틱스가 있다.
QA
어... 아까 실험정신에 관해 논했는데. 왜 또 QA냐.
QA와 실험은 다르다. QA는 '품질'검수다.
문서 작성 형식
체크리스트
동작에 대한, 조건에 대한 P/F
테스트 시나리오
사용자 입장에서 관리자, 사용자등의 여정을 검수
테스트 케이스
말그대로 시험이다.
조건, 테스트 케이스, 기대값, 결과물. 채점!
참고로 QA에는 기능QA와 디자인QA가 있다.
디자인 원안과 다른걸 잡는게 디자인 QA인데, 잘못된게 있으면 원래 의도와 함께 전달하며 빠르게 수정을 적용할수록 조직 전체에 효율적인건 체감이 확 올 것이다.
업무를 전달할때는 trello나 jira 상에서 업무 티켓을 보내곤 한다.