Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...