일일회고 질문남기기(5")

일일회고 피드백(30")

## 회고 질문과 답변

• 업무시 커뮤니케이션 방법에 대한 질문
  • 오시영: 다들 커뮤니케이션 고민이 많은 듯 하다. 기술적 내용을 기술 지식이 있는/없는 사람에게 설명할 때 뭐가 달라질까요? 기술을 아예 모르는 사람(사용자 / 고객), 같은 요구사항을 구현해야하는 사람들-기획자,디자이너, 같은 기술 베이스이지만 지식의 정도가 다른 사람들( 신입개발자에게 설명하는것과 팀장님과 소통하는게) 과 이야기할 때 다른 부분을 어떻게 의식하고 질문하는지
• 사람마다 다른데 디테일한 지식까지 알 필요 없다라고 하면 굳이 알려줄 필요 없고 그냥 본인이 찾아보도록 유도하는건 어떨까?
  • 이 사람이 개발자 지향이다 그러면 검색 키워드를 줘서 찾게끔 유도함. 이게 휘발되는 지식이라도 이 상황을 이해하기 위해서 한 번 설명하면 좋은 내용이 있다. 수학 배울 때 모든 증명을 기억하지 않더라도 한 번 하면 아 그래서~! 하는 게 있듯이. 그런데 강의는 일단 사람들이 이야기를 들으러 올 마음을 품고 있다. 다른 커뮤니케이션에서는 그런게 약하겠지.
• 환석 : 다른 개발자들과 디테일하게 얘기해본게 되게 오랫만이다. 그때 피드백이와서 인터렉션이 와 본적이 오랜만이라서 다 그렇구나 하고 넘어감. 회사에서 코드로만 얘기해서 요즘 잘 모르겠다.
• 시영 : 그럼 설계는 이야기 어떻게하는지?
• 환석 : 이해 안되는 부분은 기획자에게 물어보고 보통은 팀장님이 일감을 할당해서 주는 편이다.
• 시영 : 프론트엔드는 사용성을 많이 고려해야하기 떄문에 사용자가 어떻게 서비스를 사용하면 좋을지 생각한다. 백엔드의 경우엔 사용성과 기술적 구현 둘 중 하나를 꼽는다고 하면 기술적인 아키텍처 구현을 더 많이 고민하게 되는 느낌이 있다. 커뮤니케이션도 task 로 받는다는 이야기도 주위에서 많이 듣고.
• 환석 : 기획이 안 와도 API를 짜본다. 요청왔을 때 예외처리 하고 나중에 도입한다 했을 때 설계적인 태클 걸 사람이 없다보니깐 굳이 구조적으로 예외처리 하는게 맞나요? 라고 하면 팀장님은 편한대로해.
• 시영: 개발자가 개발하면서 커뮤니케이션을 하는 건 세가지 축이 있다고 생각한다. 사용자가 이 서비스를 어떻게 쓸 지(사용자와 커뮤니케이션), 같은 서비스를 구현해야하는 비개발자직군(디자이너, 기획자), 코드리뷰, 아키텍쳐 설계처럼 개발자끼리 이야기해야하는 것. 
• 환석: 받아서 하기 때문에 개발적인거로는 얘기하지 않고 한 시간만 보여주고 끝나야한다면 왜 굳이 한 시간만 보여주고 끝나냐하면 그냥 필요한거 같아서요. 변경 되야하는 이유가 있냐 개발측면에서 
• 시영: 정책이랑 요구사항이 혼동되고 있다. 실용주의 프로그래머 정책/요구사항 같이 읽어봤으면 좋겠다.
• 혜영 : 요즘 늘 커뮤니케이션하면서 느끼는 건, 기획자에게는 요구사항 수정이 온다면, ‘검토해보겠습니다' 라고 이야기하고, 개발자에게는 모르는게 있을 때에는 부끄러움이 느껴지더라도 물어봐야한다. 
• 상도 : 앞에서 시영은 커뮤니케이션의 축을 기준으로 말했는데, 비슷한 예로 차원으로 살펴볼 수 있을 것 같다. 개발자가 1부터 10까지의 단계로 설명하고 그것을 일직선으로 놓고 보면서 10일의 작업소요시간이 걸린다고 생각하는데 다른 관점의 사람(ex, 기획자)이 보기에는 가/부 혹은 여러 선택지 중 단 하나의 선택지인 점으로 보는 경우에 답답한거예요. 상대는 점으로 찍어줬으면 좋겠다라고 생각하는데, 나는 선이나 면으로 표현하려고 하거나 반대인 경우도 마찬가지고... 저사람은 내가 길게 보는걸 점으로 보고 있구나 내가 디자이너와 설명할때 내가 보기엔 단순하게 보이는걸 디자이너  입장에서는 단순하거나 가벼운 문제가 아닐 수 있구나 하는 이해의 폭. 나하고는 다른차원에 있는것 혹은 나의 차원에 머물러 있는 것을 어떻게 전달 할 수 있을까. '타자는 나와 다른 차원에서 보고 있구나'를 인식하고 대화를 시도 함. 아울러, 주제에 공통으로 사용되는 용어에 대한 설명 혹은 정의를 먼저 합의가 되었는지 공유하고 소통하면 쉽다.

•   누군가 코드 질문하며 왜 이렇게 로직을 구현했는지 물어볼 때 대처 방법
  • 주환석  : 구현해놓고 일주일 지났을 때 이거에 대해서 물어보면 갑자기 그 때 당시의 고민했던 영역이 전달을 잘 못해서 고민했던 부분은 기록을 해놔야겠다. 그 때 이후로는 옆에다가 써놓는다. 
• 시영 : 기록을 좋아하는 사람이라 일일 기록을 시간별로 기록을 해놨는데요. 거기에 고민도 적어두기 때문에 로그를 보면 대충 왜 이렇게 짜게 되었는지 알 수 있다.
  • 이번에 다른 분하고 짧게 일하면서 감명받았던 부분이 있다. 그동안 작업 로그는 노션,에버노트처럼 개인적인 공간에 적어두었다. 근데 이 프로젝트에서는 공적인 공간인 위키에 로그들을 적어두더라. 그 방식대로 하니 다른 사람에게도 부가적인 설명을 적게 하고 기존에 있던 로그를 읽어보면서 설명하게 되는 것. 그리고 그 로그보고 일의 진행상황(메뉴얼 같은 게 아니라 history와 현재 상태까지!)를 파악할 수 있었다.
  • 전에 다니던 회사에서 많이 훈련되었던 부분이 다른 사람(비개발자 stackholder들)에게 진행상황을 설명하는 문서를 작성하는 것이었다.  회의록 + 회고 + 로그는 작업하면서 바로 적는 것도 좋았고. 근데 개발자들이 이야기한 내용을 바로 적으면 다른 직군은 못 알아볼 수 있으니 한 번 좀 더 해석해서 문서를 적는 게 필요했다. 주로 스프린트 마지막 날 1/4 정도 시간을 내서 적었다. 
  • 전 회사에서 익힌 것 + 이번에 배운 것 → 작업 로그 & 러프 메모를 공적 공간에 적자!
    • 문서 작업에 대한 부담이 줄어들고, 작성하면서 다른 사람에게 설명하는 걸 무의식적으로 염두에 두니 좀 더 커뮤니케이션하는 방법을 훈련하는 기분이 든다.
    • 무엇보다 TDD 할 때 나중에  테스트 코드 만들어야지 하는 부채감이 줄어드는 것 처럼 나중에 할 일이 줄어서 편하고 나도 못 알아볼 정도의 너무 막 메모를 안 적게 된다는 것!
  • 일단 러프 메모부터 적으면 좋겠다. 러프 메모 기반 -> 설계 문서에 정리 되어서 나중에도 시간을 줄일 수 있다.
• 혜영 : 노션에다 히스토리 남겨둔다. ex) 구현이 왜 기획과 달라졌는지에대한 것  코드에 주석으로도 히스토리를 적어놔야 할 것 같다.
• 시영 : 주석반대파. 주석을 쓰기 시작하면 주석도 관리해야 하기 때문이다. 보통 오픈소스를 보면 문제가 있을 때 이슈로 처리한다. git  blame, issue, commit, PR 프로세스를 이용해서 처리하면 굳이 주석이 필요 없지 않을까? (github blame 같이 봄) issue 에서 추적이 안되고 코드에서 추적이 필요하다면 blame → commit(with issue link) → issue link 로 넘어가면 되지 않나? 주석이 필요한 것들을 이슈 링크, 위키 링크 등으로 빠지면 좋지 않을까 생각함.

라이트닝톡(60")

• 혜영 : [Firebase Robo테스트](https://www.notion.so/rudiamoon/Firebase-Robo-f9385e9cddc44711815275d921e7508c
• 시영 : Git For Everybody

• 위 내용 발전시켜서 git 기본 설명 강의자료를 만들었습니다 (git을 두 세번 사용만 해본 사람용 / 나 혼자 프로젝트할 때 쓰면 좋을 용도)
• 앞으로 아래 내용을 위한 강의자료를 만들고 있습니다.

• 과정 로드맵

  • Git For Me : Git 이 아직 낯선 이를 위한 가이드
  • Git For You & Me : 협업을 위한 git
  • Git For Contribution - Open source Contribution 위해 알아두면 좋을 것들
• 

스터디 마무리 회고 (15")

• 혜영
• Keep : 오늘 스터디 할거예요? 라고 했을때 단호하게 하자고 요청을했고 하다보니 업무에서 문제있었던 점 다시 되돌아 볼 수 있었고 컨트리뷰션에대해서도 생각 하게 되서 좋았어요.
• Problem :  선오가 스터디 2번째차주까지 안 나와서 선오에 대한 질문을 못해서 아쉬워요.
• Try : 선오가 잘 참여하도록 유도할 수 있는 방법은 뭘까? 선오가 가능한 시간에 번개모임을 해야할까? (시영: 서노 죽지마… )
• 시영
• Keep : 라이트닝토크 계속 하기
• Problem :  디스커션하는 시간이 짧아서 아쉬움
• Try : 주제를 하나만 정해서 충분히 디스커션하자
• 주환석
• Keep : 얼굴봐서 좋았어요. 역시 화상보단 실제로 만나서 이야기 하는게 좋네요.
• Problem :  시간의 압박, 라이트닝 톡의 부담
• Try : 시간의 압박에서 조금은 여유롭게 해도 되지 않을까요? 미리 라이트닝 톡 주제를 짜보자...

개선사항 (5")

• 디스커션은 충분히 한 가지 주제로 얘기하자.
• 다음주차는 라이트닝톡만 진행.
• 마지막 주차는 한가지 디스커션 / 최종 스터디 회고