인트로
개발자, 특히 나같은 주니어들은 어떻게 질문하고, 말해야 하는지에 대해 정리해봤다. 말하기라는게 쉽지만, 회사에서 돈받으면서 "잘 말하는 사람"이 되기는 정말 어렵고, 의식적인 노력이 필요하기 때문
어렵게 질문하자
- 질문하는 사람이 편하게 질문을 던지면, 답변하는사람이 어렵고
- 질문하는 사람이 어렵게 고민해서 질문하면, 답변하는사람이 쉽다
- 질문의 범위를 좁히고, 주제는 명확하게 해서 답변하는 사람이 편하도록 질문하자
말하기는 두괄식으로
- 청자가 궁금해하고 원하는바를 먼저 이야기하고, 나서 구체적인 설명은 뒤에다가 덧붙이기
- 이렇게 하지 않고, 서론이 길어서 결론이 늦게나오면
- 듣는사람도 무슨 말 하는 지 모르겠고, 생각하는데 피곤함(목요일 5시 정도라면 짜증도 남)
- 말하는 사람도 무슨 말 하는 지 모를수 있음
- 그래서 결론먼저, 구체적인설명은 뒤로
질문이 아닐수도 있다
- 너무 기본이지만 구글에 검색하면 나오는거, 똑같은 질문을 세번이상 물어본다면 질문이 아니라 일을 해달라는의미다. "해줘!"
- 이게 꼭 나쁜것만은 아니고, 스마트폰 사용법이나, 노트북 기능 관련, 장비셋팅같은건 너무 과하지만 않으면 그냥 효도한다 셈 치고 내가 해드리는게 편하다..
- 오후 네시쯤 되면 스몰톡 겸 가벼운 질문으로 시작하는 경우도 많은듯. 잡답은 경쟁력이니까
메타인지
- 모르는건 물어보는데, 어디까지 알고 / 모르는부분은 어디인지 명확히 한 상태에서, 질문의 요점을 구체화한 후 질문하기
- 질문이 clear 할 수록 답변도 clear하다
- 내가 답변자의 입장이던, 질문자의 입장이든, 항상 clear 한게 좋다
모른다고 말할 수 있는 용기
- 대화도중 대전제나, 이야기의 흐름을 놓쳐 진짜 모르는 말을 듣고있을때, 화자의 예상이나 전제를 확인하거나 다시 물어볼수 있는 용기
짧은 피드백
- 알아서 독립적으로 결정을 내리고 업무를 진행할수 없는 일이라면 매 진행 과정에서 아래 3가지 정도를 정리하면서 중간중간 짧은 주기로 의사소통 하는게 좋다
- think : 의도나 설계
- do/input : 내가 한 행동
- return/result : 그 결과
- 의도가 엉뚱한건 아닌지, 과정 중에 이상이 없는지, 결과는 합리적인지 확인하는게 이상적임. 근데 매번 짧게 피드백을 요청하면 더 싫어하는 사람도 있는데, 이런경우 혼자 log 를 남기다가 모아서, 약간의 Buffering을 사용해서 수요일한번, 금요일한번 가볍게 보고하는것도 나쁘지 않음
- 최종 결과물만을 가져가면 나중에 문제가 생겼을 때 다시 0으로 돌아가야 함. 개별 과정에 대한 컨펌이 있었다면, 문제되는 부분만 수정하면 됨. 의사소통과 개발과정에서도 git commit을 일상화하자
- 그리고 나에 대한 신뢰가 없는, 나보다 높은 사람과 일할때는 윗분이 궁금해할수도 있다. 그들이 원하는것을 먼저 주어야 한다
조언을 구하고 싶을때
- 주제에 대해 상대방에게 미리 생각 할 시간을 주는 방식으로 접근하는게 좋음
- 예를들어서 저녁메뉴에 대해서 조언을 구하고싶은데, 상대방은 저녁메뉴에 대해 생각해본적이 없을수도 있고, 저녁을 안먹을 계획일수도 있다.
- 의미있는 조언을 위해서, 혹은 유익한 토론을 위해서는 사전작업이 필요하다. 토론 전에 어젠다를 전달하고 >> 디스커션을 위한 무슨 내용들을 확인해주십사 요청한 뒤 >> 적당한 시기에 일정을 잡아서 진행하면 같은 문제에 대해 보다 심도깊고 유의미한 논의를 진행할 수 있다
Sorbet is good...!