미팅 사전 준비

-미팅의 아젠다가 무엇인지, 목적이 무엇인지, 참가자는 누구인지 알아두고 참가할 것
-자신의 발화가 미팅에 포함되어 있을 경우, 청자를 고려하여 무엇을 언급할지 준비할 것
-외부 미팅의 경우, 내부미팅을 우선 진행하여 무엇에 대해 이야기를 나누고, 어떤식으로 대응할지 미리 정할 것

미팅시

기지록의 종류

Full기지록

Full 기지록은 말한토시 틀리지 않고 있는 그대로 모두 기재하는 것임. 보통은 이러한 기지록을 기재할 필요는 없지만, 계약 교섭과 같이 누가 언급했는지, 무엇을 언급했는지가 중요한 회의에서는 Full기지록을 써야함

  • 기지록은 rawdata라고 되도록 있는 그대로 적음
  • 기지록은 가능한 누가 언급했는지, 무엇을 언급했는지 세부적으로 적을 것

요약 기지록

요약기지록은 요점을 중심으로 그 앞뒤 배경을 파악할 수 있도록 어느 정도 요약해서 기재하는 것. Full 기지록처럼 다적을 필요는 없고, 흐름에 맞추어 정리가 필요하다고 판단되는 부분을 중심으로 적어나가면 됨.

  • 누가 언급했는지는 되도록 적는 것이 좋다.
  • 회의는 화제를 중심으로 이야기가 왔다 갔다 하는 것이므로, 화제 중심으로 기재할 것
  • 참가자가 말한 문장을 그대로 적을 필요없고, 자신이 이해한대로 요약해서 적으면 됨(요약기지록에서)

요점 기지록

회의의 고수들만이 활용할 수 있는 기지록으로, 결정사항TODO만 적는 것. 장기적으로 프로젝트에 어사인 되어 앞뒤배경을 모두 아는 상황에서는 요점 기지록을 활용해도 문제 없다. 보통 파트너급의 높은 이해능력과 전반적인 상황을 알고 있는 레벨에서 사용하는 방법.

기지록 작성시 유의점

  • 기지록을 적고 있을 때, 다른 사람이 real time으로 언급하는 부분을 놓치는 경향이 있으므로 기지록을 적는 와중에도 청중의 발언에 집중할 것
  • 주요 항목에 대해서는 회의 시간 중 실시간으로 빠르게 적고, 이후에 양식에 맞춰 정리할 것
  • 시계열로 기록할 것
  • 복잡한 복문이 아닌, 단문으로 적을 것
  • TODO 항목에 대해서는 #으로 표시, 이해 못한 항목에 대해서는 * 로 표시, 결정사항에 대해서는 ※로 표시하여 기지록 작성후 한눈에 알아볼 수 있도록 할 것

미팅 후

기지록 정리

  • 회의시 작성한 rawdata를 근거로, 아래의 템플릿을 채워나감
【Agenda】 
【참가자】 
【요약】
【TODO】 
【결정사항】
【미해결사항】
【議事】-> rawdata, 내부 증거용으로만 남기고 공유는 하지 않을 수도 있음 
  • TODO 작성법
  1. Role And Responsibility
    키워드 담당자 액션내용을 명확하고 심플하게 적을 것
  2. Due Date를 명시할 것
  3. 상대방의 입장에서 읽어보기
    TODO를 받은 담당자가 TODO만 읽고 자신의 일을 바로 커밑해나갈 수 있을지를 기준으로 TODO내용 자가레뷰하기
- 1차사업 견적서 수정 후 발송: 담당자A(~2/5)
- 경쟁사 벤치마킹 자료 작성: 담당자B(~2/7)
- 기존 사업 차별성 정리자료 작성: 담당자C(~2/4)
  • 회의록 공유는 가급적 빠른 시간 안에!

회의록은 회의가 끝나고 가능한 빠른 시간 내에 작성하고 공유하는 것이 좋습니다. 이를 통해 회의 참석자는 물론 참석하지 않은 업무 관련자들이 회의를 통해 도출된 내용을 이해할 수 있게 해야 합니다. 또한 빠른 시간 내에 공유가 이뤄져야 혹시라도 잘못된 사항이 있을 경우 누락되거나 수정해야 할 사항에 대해 확인할 수 있습니다.

  • 참석하지 않은 업무 관련자에게도 공유할 것

다른 일정으로 참석하지 못한 업무 관련자에게도 회의록을 빠짐없이 공유하는 것이 좋습니다. 그래야 회의를 통해 어떤 내용이 논의되었고 결론이 도출되었는지를 확인하고 관련 프로젝트를 완수할 때 혼선이 빚어지지 않습니다.

  • 회의 내용은 회의 시간 중 실시간으로 작성할 것

많은 내용이 오가는 회의 시간이 끝난 다음 회의록을 처음부터 작성하는 것은 거의 불가능에 가깝습니다.

  • 분량은 1매 이내로

지나치게 방대하게 회의록을 작성하면 읽는 사람들로 하여금 피곤함을 불러일으키고 명확성이 떨어지는 단점이 있습니다. 빠지는 내용이 없도록 꼼꼼하게 작성하되 잘 요약해 1매 이내로 작성하는 것이 좋습니다.

  • 회의록 작성이 처음이라면 전체 공유 전 1차 검토 받기

회의록을 공유하기 전, 회의에 참석한 동료 또는 상사를 통해 1차로 회의록을 검토 받는 것도 좋습니다. 특히 처음 회의록을 작성할 경우 회의의 핵심 사안이 무엇인지 파악하기 어려울 수 있고 누락된 사항이 생기기 쉽기 때문에 사전 검토가 필요할 수 있습니다.

참고

'지혜 > ' 카테고리의 다른 글

결정하는 감  (0) 2019.10.02
글의 구조를 파악하는 감  (0) 2019.09.01
질문하는 감  (0) 2019.08.29
자가 검진의 감  (0) 2019.08.29
정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
  1. 배경

【AIPSCM】LIVING_SYSTEM画面討議_20200622_議事メモ.txt
0.00MB
【AIPSCM】画面討議_20200617_議事メモ.txt
0.00MB
【AIPSCM】画面討議_20200612議事メモ.txt
0.00MB

  1. 좋은 질문을 해야하는 이유
    • 상대와 나의 시간 코스트 절감
    • 내가 원하는 질문을 얻을 수 있음
  1. 좋은 질문
    • 먼저 자신이 모르는 것이 무엇인지 정확히 파악할 것
    • 알고 싶은 것이 무엇인지 정확히 파악할 것
    • 어떠한 답이 나올지 예상하고 질문할 것
    • 상대의 답에 따라 어떠한 질문을 이어갈지 예상할 것
    • 어디까지는 알고 어디부터 모르는지 상대가 이해할 수 있도록 배경 을 설명할 것
    • 최대한 구체적으로 질문할 것
    • 예를 들어 가며 상대가 이해하기 쉽게 질문할 것

'지혜 > ' 카테고리의 다른 글

글의 구조를 파악하는 감  (0) 2019.09.01
미팅하는 감/회의록 작성하는 감  (0) 2019.08.29
자가 검진의 감  (0) 2019.08.29
정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
  1. 자가 검사란?
    컴퓨터가 스스로를 분석해서, 하드웨어인 cpu, 메인보드, 메모리, 소프트웨어의 문제점을 검진하는 것처럼, 인간도 스스로의 상태를 파악하고 문제점을 집어내는 것이다.

    컴퓨터가 cpu, 메인보드, 메모리 등의 하드웨어 + 각종 소프트 웨어로 구성되어 있기에 한 요소 한 요소의 문제점을 검진해 볼 수 있는 것처럼, 인간도 인간을 구성하는 요소를 알고 있어야 자가 검진이 가능하다. (인간이라는 존재를 분할 알고리즘으로 분석: 인간 = 신체+이성+감정+욕구)

    인간의 하드웨어에 해당하는 것은 신체이다. 인간의 소프트웨어에 해당하는 구성물들은 다소 복잡한다. 첫째, 논리적인 옳고 그름을 밝혀내는 이성의 흐름안에 있는 생각이다. 둘째, 긍/부정과 각성의 흐름 안에 있는 감정이다. 셋째, 어떤 것을 원하는 생각도 감정도 아닌 욕구이다. 정리하면, 인간의 구성요소는 신체, 생각, 감정, 욕구이다.

    우리는 스스로의 신체, 생각, 감정, 욕구의 상태를 들여다보고 어떤 상태에 있는지, 무엇이 문제인지 스스로 검진할 수 있다.

감정 감성 이성

감성(pathos)은 이성(logos)의 상대어로 '자극에 대하여 느낌이 일어나는 능력. 감수성(感受性)' 또는 '대상으로부터 감각되고 지각되어 표상(表象)을 얻게 되는 수동적인 능력'을 뜻하는 철학적인 용어입니다.  
감정(emotion)은 '느끼어 일어나는 심정. 마음. 기분' 또는 '슬픔·기쁨·좋음· 싫음 따위의 심리 상태나 직감' 즉 '희노애락애오욕'과 같은 것을 말하는데 심리학적인 용어라고 볼 수 있습니다.  
따라서 감성은 '느낌을 받아 들이는 능력'이라고 할 수 있고, 감정은 느낌에 대한 심정, 심리 상태'라고 할 수 있습니다.  
직감은 곧바로 느껴 아는 것으로 설명·증명 등을 거치지 않고 곧 사물의 진상을 마음으로 느껴 알거나 그 감각을 말합니다. 직감은 감성의 일부라고 볼 수 있습니다.
  1. 자가검사의 방법
    • step1
      • 신체,생각,감정,욕구의 상태를 스스로 검진해본다.
      • 신체 : 목이 조금 당긴다. 발가락이 간지럽다. 위가 쓰리다. 배가고프다. 눈이 뻑벅하다. 머리가 상쾌하다. 몸이 가볍다
      • 생각 : 내가 지금 무엇을 해야할지 생각. 점심은 무엇을 먹어야할지 생각. 여자친구는 잘 있는지 생각. 부모님은 잘 계신지 생각. 다른 친구들은 뭘 하고 있을지 생각.
      • 감정 : 불안한 감정. 초조한 감정.
      • 욕구 : 자위를 하고 싶은 욕구. 게임을 하고 싶은 욕구. 맛있는 걸 먹고 싶은 욕구. 여자친구를 보고싶은 욕구. 아무것도 안하고 싶은 욕구

*감정의 분류법 ; 각성과 긍부정

'지혜 > ' 카테고리의 다른 글

미팅하는 감/회의록 작성하는 감  (0) 2019.08.29
질문하는 감  (0) 2019.08.29
정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
어플리케이션을 개발하는 감  (0) 2019.07.28
  1. 머리속에 생각나는 모든 키워드들을 우선 적어내기
    마인드맵 그리기는 머리를 복잡하게 했던 키워드들을 종이 위에 하나하나 적어봄으로써 머리 속을 정리할 수 있는 효과를 지닌다. 이는 글을 쓰는 프로세스를 포함하여 모든 작업에 적용할 수 있는 일의 처리 프로세스이다.
  1. 각 키워드를 분류화하기
    • 키워드들을 粒度(level)에 맞게 정리해 나가기
    • 가지를 쳐 나가면서 MESE에 따라 누락되는 부분이 없는지 주의
    • 분할 알고리즘을 적용해 더욱 구체화 될 수 없는지 확인하기
    • 일정한 인과관계를 갖도록 한다.
  1. 우선 처리해야할 것이 무엇인지 일의 순서 매기기

    • 인과관계에 따라 분류된 키워드에 일의 순서를 매긴다.
    • 일의 순서를 매기는 기준 : 1. 다른 태스크에 영향을 미치는 일 2. 데드라인이 긴박한 일 3. 금새끝내버릴 수 있는 일
  2. 마인드 맵과 순서 매기기에 따라 ;하나하나 차분하게' 진행하기

'지혜 > ' 카테고리의 다른 글

질문하는 감  (0) 2019.08.29
자가 검진의 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
어플리케이션을 개발하는 감  (0) 2019.07.28
노래부르는 감  (0) 2019.06.24

글이 중요한 이유

글 외에도 유투브니 영화니 드라마니 소설이니 웹툰이니 PPT장표니 미친 듯이 다양한 컨텐츠와 미디어가 공존하는 와중에도 글이 중요한 이유는 모든 컨텐츠는 간단한 줄글로부터 시작하기 때문이다. 유투브, 영화, 드라마, 소설, 웹툰, PPT장표는 줄글을 보기 좋게 시각화하고 흥미를 더한 것에 불과하다.

글 설계하기

학생 때 지겹게 듣던 논리적 글쓰기니 뭔 복잡한 개소리 다 집어치우고, 논리적인 글은 주장 + 근거 간단하게 딱 이 2개로 이루어진 글이다. 필요하다면 근거 + Sub근거 + Sub근거 + ... 구조로 더욱 논리성을 더할 수 있다. 이게 논리적 글쓰기의 모든 방법이다.

주장
    > 주장에 대한 근거(why) 
        > 근거에 대한 Sub근거(why)  + what how so

주장: 가장 하고 싶은 말을 한마디로 하면?

논맂거 글을 쓰기 위해선 먼저 주장하고자 하는바 (글 전체에서 말하고자 하는바)가 단 한 줄로 간단명료하게 나와야한다. 주장은 가설적일 것이다. 가설적이지 않은 주장은 당연해서 주장이라고 받아들여지지 않을 것이기 때문이다. 시내 한복판에가서 사람은 죽는다! 라고 외쳐봐야 어느 누구도 주목하지 않을 것이다. 그러나 사람은 결국 신이 만든 장난감이다! 라고 외친다면 증명되지 않은 가설에 대해 이유라도 들어보려고 누군가는 주목할 것이다.

근거Why: 왜 주장이 합당하다고 생각되는가?

근거는 주장에 대해 그 이유를 제시하는 것이다. 근거는 Fact일 수도 있고 가설적일 수도 있다. 단, 가설적 근거는 데이터로 Back-up되어야 한다. 어떠한 객관적, 정량적 데이터로 가설에 머물고 있는 근거를 Fact로 만들 수 있는지 고민하고, 그러한 데이터를 활용하자.

What How So로 근거를 명확히 하기

근거를 제시하는 것만으로는 글이 명확하지 않을 수 있다. 이럴 때는 What How So 가 부족하지 않은지 생각해봐야 한다.

주장: 한국 반도체 시장은 앞으로 매우 힘들어 질 것이다

근거1: 일본, 대만, 미국이 한국 왕따시키고 지네끼리만 짝짝쿵하고 있다.(이하는 What에 대한 세부 설명)
   - 대만 TSMC가 일본 쿠마모토에 대규모 Fab을 세우고, 일본은 엄청난 정부적 혜택을 주고 있다.
      > 일본 정부의 세혜택에 관한 Data로 주장 Back-up
   - 미국 애플이 TSMC에게 발주하는 물량을 크게 늘이고 있다.
      > 애플의 TSMC向 발주 액 추이 데이터로 Back-up

근거2: 한국 반도체 시장 인력이 부족하다.

주장 - WHY의 구조로 설계된 글을 객관적으로 바라보면서 반론해보기

글의 기본적 설계가 완성되면 논리적 결함이 없는지 제3자의 입장에서 바라보면서 반론해보자. 반론을 무마시킬 수 있는 논리 구조를 만들 수록 글은 더 탄탄해진다.

논리적 글쓰기 설계 예

주장: 부동산 가격은 떨어질 것

이유1: 수요는 이미 하방인 상태로 관망할 것이고 ...
   - 수요 하방이라는 근거: 서울 매매 건수가 역대 최저. 공급 곡선이 그대로 였다고 했을때 수요곡선 하락 외 설명 불가
      - 수요 곡선 하락한 이유: 높은 대출 금리 및 갭 투자 불가
   -  관망할 것이라는 근거: 1억 버는 사람이 서울에 최대로 살수 있는 집값 7억. 또 부동산 시장 하락이 뻔한 상황에서 갭투자 불가. 이에 수요는 자기 소득으로 부동산 구매 가능한 7억선까지 내려오지 않는 이상 수요자체가 불가
      - 1억벌면 7억집살수 잇다는 근거: DSR LTV 모델링 결과 그러함

이유2: 공급은 늘어날 것
   - 집주인들이 버티고 있으면 모르겟지만, 어쩔 수 없이 집을 내놓을 수밖에 없는 상황이 존재
   - 어쩔 수 없이 집을 내놓을 수밖에 없는 이유: 갭투자, 갭투자자들은 전세값이 내려가면 그만큼이 자기 손해분이 되기 때문에 손절하기 위해 어쩔 수 없이 부동산 매매
   - 전세값이 내려가는 이유: 전세 시장에서 전세 수요는 낮고, 전세 공급은 높음
      - 전세 수요 낮은 이유: 높은 금리
      - 전세 공급 높은 이유: 전세로 집을 내놓는 사람들 중 대부분은 갭투자가이기 때문에 세입자가 없는 상태로 가만히 집비워두고 버틸재간 있는 사람 없음
         > (반론) 진짜 갭투자자 많은가요? 실제 갭투자 데이터 or 갭투자 없이 대출로 살수 잇는 서울 집값이 마지노선 데이타

그외 글 설계 할때의 Tip

  • 글쓰기 주제에 대해 생각나는 것 생각나는대로 모조리 적어 마인드맵 완성하기
  • 마인드 맵을 통해 얻은 정보를 바탕으로, 因果関係에 따라 논리 구조를 짜맞추기
    • 꼭 필요한 핵심단어들을 의식하며 논증과 전체 셀계에 녹여내기
  • 글의 큰 흐름을 어떻게 적어 나갈 것인지, 또 각 단락별로 말하고 싶은 바와 어떤 내용을 집어넣을 것인지 세세한 구조를 잡기★
    • 각 단락별로 주제를 잡고 그대로 글을 구성해 나가기

글 쓰기 중

  • 연구배경
  • 문제 제기(주제 정하기)
  • 가설 기술(주장 정하기)
  • 검증 방법 기술
  • 증거 제시(주장에 대한 이유를 제시하기)
  • 증거에 대한 논리적 해석(이유에 대한 증거를 제시하기)
  • 가능한 반대 주장에 대한 재반박
  • 결론과 제언

글 쓰기 후

  • 최소 세번이상 글의 성격 독자의 입장을 고려하여 글을 읽고 다듬는다.
  • 읽었을 때 이해하기 쉬운 글이 좋은 글이다 : 소리내어 읽어봄으로써 못난글을 알아보는 것은 단순한 원리에 바탕을 두고 있다. 언어는 말과 글이다.언어에 한정해서 보면 글이 아니라 말이 먼저고, 말보다 생각이 감정이 먼저다. 말과 글중에는 말이 먼저도. 말로해서 좋아야 잘 쓴 글이다. 글을 쓸때는 이 원리를 잊지 말아야한다.

글쓰기의 어드바이스

글쓰기의 테크닉에 대해

  • 글은 단문으로 쓴다.
    • 단문이 좋다. 문학작품도 그렇지만 논리글도 마찬가지다. 단문은 그냥 짧은 문장을 가르키는 것이 아니다. 길어도 주어와 술어가 하나씩만 있으면 단문이다. 문장에 하나의 뜻을 하나만 담으면 자연스레 단문이 된다.
    • 단문은 주술관계가 하나뿐이여서 문장이 꼬일 위험이 없다. 복문을 쓰는 사람 대부분은 멋지다고 생각해서 그렇게 쓴다.
    • 글을 압축하려면 단문을 기본으로하고 특별한 경우에 복문을 쓴다는 원칙을 견지해야한다. 뜻과 느낌을 강하고 확실하고 깊게 전하려면 복문을 서야 한다는 판단이 들때만 복문을 쓰는 것이다
  • 글의 군더더기를 없앤다 : 문법적인 군더더기 삭제 + 전체 문장에서 굳이 없어도 흐름이 이어지는 문장 삭제
    • 다음은 군더더기를 없애는 것이다. 문장의 군더더기란 무엇일까? 간단하다. 없애버려도 뜻을 전하는데 큰 지장이 없으면 군더더기다. 문장의 군더더기는 크게 세 가지다. 첫째는 접속사, 둘째는 형용사와 부사, 셋째는 여러 단어로 이루어져있지만 형용사나 부사와 비슷한 역할을 하는 문장 요소다.
    • 굳이 없어도 좋은 접속사는 과감하게 없애야한다. 단문으로 글을 이어나갈 때 문장 사이에 매번 '그러나' '그리고' '그러므로' '그런데' 같은 접속사를 넣는 것은 나쁜 습관이다. 문장은 뜻을 담고 있다. 그 뜻이 자연스럽게 이어지면 접속사가 없어도 된다. 단문을 기본으로 쓰고 불필요한 접속사를 생략하기만 해도 글을 압축할 수 있다.
  • 읽었을 때 이해하기 쉬운 글이 좋은 글이다 : 소리내어 읽어봄으로써 못난글을 알아보는 것은 단순한 원리에 바탕을 두고 있다. 언어는 말과 글이다.언어에 한정해서 보면 글이 아니라 말이 먼저고, 말보다 생각이 감정이 먼저다. 말과 글중에는 말이 먼저도. 말로해서 좋아야 잘 쓴 글이다. 글을 쓸때는 이 원리를 잊지 말아야한다.
  • 한자어는 대체될 우리말이 있는지 따져보아야 한다. 사용한다 -> 쓴다. 삭제한다 -> 없앤다. 인식한다 -> 안다.
  • 피동형 문장도 심각한 문제를 일으킨다. 우리말에는 피동문이 드물다. 반드시 피동문을 써야 의미가 전달될때만 예외로 사용한다. 그런데도 일본말이나 영어같이 피동문을 표준문장처럼 쓰거나 뜬금없이 피동형 동사를 가져다 붙이는 사람이 많다. 보여지다 되어지도 키워지도 디뤄지도 모여지도 두어지다 보아지다 와 같은 것을 글뿐만아니라 방송에서도 출몰한다. 타동사를 피동형으로 쓰는 것만으로 모자라는지 자동사까지 억지로 피동형으로 만든다.
  • 서양말의 완료시제와 복수형 어미의 오남용도 심각하다. 우리말은 완료시제가 없다. '어제 어머니를 만났었다'는 틀린말이다. '어제 어머니를 만났다'가 올바른 우리말이다. 서양말은 복수와 단수에 따라 동사의 형태가 바뀌므로 복단수를 인식하는 것이 중요하다. 그러나 우리말은 명사 그자체를 복수라고 분명하게 드러내야할 때가 아니면 복수형을 스지 않는다. 그런데도 '방법들을 찾아야 한다'는 식으로 추상명사에까지 복수형인 '들'을 붙여 사용하곤 한다.
  • 하나의 문단을 쓸 때, 처음으로 오는 문장은 가능한 문단 전체를 대표하는 주제로 한다. 이것은 독자에게 친절한 글이다.

글쓰기의 마인드에 대해

  • 독자의 입장을 고려해서 이해가 안되는 부분 풀어쓰기(친절한 글쓰기) : 다른 정보가 없어도 이해할 수 있도록 독자를 존중해야 한다. 사람들이 잘 모르는 전문용어나 이론을 끌어올 때는 문맥에 비추어 이해할 수 있도록 적당한 방법으로 설명을 붙여야한다. 이렇게 핮 ㅣ않고 무작정 하고 싶은 이야기를 우겨 넣으면 텍스트 밀도가 너무 높아진다. 틀린게 쓴 것도 흉하게 쓴 것도 아니지만 그런 글은 독자를 괴롭힌다. 읽기가 힘들고 이해하기 어려우면 아무리 좋은 책이라 해도 독자가 공감할 수 없다.
  • 글 쓰는 사람의 작업실에 대해 환상을 가진 사람이 있을 것이다. 고즈넉한 실내, 은은하게 흐르는 클래식, 커피향, 원고 청탁전화. 그 저도 환상이 나쁠건 없다. 하지만 그런 분위기를 만든 다음에 글을 쓰려고 한다면 좋지않다. 그런 작업실은 베스트셀러를 내는 전업작가라야 가질 수 있다. 전업작가라 해서 누구나 다 그런 작업실에서 글을 쓰는 것도 아니다.
  • 취향 고백과 주장을 구분하여, 주장이라면 반드시 논증하기
  • 주장을 논증하기 위한 근거는 주장이 아닌 사실을 언급하기 : 공리만이 타당한 주장의 근거가 될 수 있다. 논증의 근거로 주장이 오게 되면, 또 그 논증에 대한 논등을 해야하는 논증지옥에 빠진다.
  • 허영심은 위선의 감정에 에워쌓여 난해한 글을 쓰게 한다
  • 객관적인 글 쓰기 : 감정을 억제하고 최대한 객관적으로. 판단은 독자에게
  • 모든 논증은, 1차적, 2차적, 3차적.... 이유를 생각해보고 설명해야 하는 차원의 이유만 글을 통해 전달한다. 너무 심오한 이유는 당연한 것을 반복하는 실수를 범하고, 이는 글이 쓸데 없이 길어지고 지루해지며, 요점을 흐린다.★
  • 개인적인 경험이나 유머의 사용을 겁내지마라(개인적 경험의 언급은, 독자에게 하여금 일반적인 내용도 더욱 설득력 있게 만든다)
  • 스스로에게 굉장히 엄격한 비판가가 되라. 자기 스스로보다 자신의 글을 더 잘 평가할 수 있는 사람은 없다.

1-160429031445.pdf
1.04MB

어플리케이션 개발의 흐름

요건파악

  1. 요건파악이란
  • 어플리케이션의 존재 이유는 유저의 고통점(니즈)를 해결하는 것에 있습니다. 어플리케이션이 어떤 니즈를 충족해 줄 수 있는지 요건을 파악하고 그 요건에 맞는 어플리케이션 개발은 개발 시 가장 먼저 이루어지는 액션이자 가장 중요한 액션입니다.
  1. 요건파악에서 주의할점
  • 유저의 요건 충족은 보통 프론트를 통해서 시각적으로 이루어질 시에 효과적입니다. 때문에 유저의 요건을 만족하는 프론트를 먼저 구상하여 요건을 만족하고, 그 프론트를 베이스로 큰 단위의 설계를 시행해 나갑니다.

요건에 맞는 설계

  1. 설계란
  • _기본 설계가 중요한 이유는 세부적인 알고리즘은 몇 번이고 리팩토링을 통해 수정해 나갈 수 있지만, 전체를 구성하는 설계는 변경하기가 쉽지 않기 때문입니다. _나무는 평생 몇 번이고 잎을 떨궈내고, 잔가지를 키워내며(리팩토링) 성장해 나가지만, 그 기둥이나 뿌리의 위치를 바꾸거나 모양새를 바꾸지는 않습니다. 어플리케이션도 이와 마찬가지 입니다.

  • 설계란 요건을 실제 시스템에 녹이는 작업입니다. 설계에는 기본설계, 세부설계, 알고리즘설계로 이루어지는데, 하는 일은 같습니다. 다만 粒度(레벨감)가 다를 뿐입니다.
    설계를 하는 방법자체는 기본설계든, 구체설계든, 알고리즘설계든 모두 동일합니다. 중요한 것은, 기본->구체->알고리즘으로 粒度을 점점 좁혀나가며 세부적인 설계의 모양세를 갖추어나가는 것입니다.

기본설계

  • 시스템의 가장 기본적인 흐름을 만들어 나가는 과정입니다. 가령, 「 DB - 어플 - UI 」와 같은 형태가 되겠군요. 이를 조금 더 구체화할 수도 있는데, 이는 플로우차트를 통해 구현할 수 있습니다. DB여도 여러개의 DB가 있다면, 혹은 클라우드내에서 여러 서비스를 거치게 된다면 복잡할 수 있으므로, 플로우차트를 통해 구현하면 이해하기 쉽습니다.
  • 어플리케이션을 개발할 때는 요건과 사용언어 환경에 맞는 다양한 가이드라인이 필요합니다. 가이드라인은 결정하면 되는 문제지만, 한번 정한 가이드라인은 설계상 쉽게 바꾸기가 어려움으로 경험이 축적된 가이드라인은 중요합니다. 예를 들어 API를 개발 한다고 할때, API의 URI설계는 어떻게 할지, GET/POST의 메소드 활용은 어떻게 할지, request/response 포맷은 어떻게 할지 모두 일일이 정해야 합니다.
     이때, 기존의 가이드라인을 사용하면 매우 유용합니다. 위에서 예로든 API의 경우에는 [api guideline]이라는 키워드로 검색하면 많은 경험이 축적된 가이드라인들을 조사할 수 있습니다.

구체설계

  • 파일단위의 설계 혹은 시스템보다는 조금더 구체적인 粒度를 통한 설계를 의미합니다. 시켄스도를 통해 구현할 수 있습니다.

알고리즘설계

  • 알고리즘 설계는 매우 구체적인 행단위의 설계입니다. 알고리즘의 불완전성, 알고리즘의 성능・속도(bigO를 고려)하는 것이 알고리즘 설계에 해당하게 되겠네요.
  1. 설계시 주의점
  • 설계시에는 시스템단위(디비, 어플, 인터페이스와 같은 큰단위의 기본설계: 플로우차트) -> 파일단위(세부설계 : 시켄스도) 레벨로 점점 좁혀나가며, 각 시스템과 파일의 인풋 아웃풋 정도로만 고려합니다. 행단위의 매우 세부적인 알고리즘의 설계는 일단 고려하지 않고, 파일단위의 세부설계가 끝난 후 탑다운으로 粒度를 구체화시켜가며 고려합니다.
  • 설계의 흐름을 보며 각 부분에서의 리스크를 미리 판단 후, 그 부분에 주의를 기울입니다.

프로토타입 개발

  1. 프로토타입개발
  • 프로토타입이란 완전체가 아닌 1. 데이터가 일단 흐르기는 하는, 2. 유저의 최저한의 요건을 만족한 매우 초기 형태를 의미합니다. 무엇이든 처음부터 완전할 수 없습니다. 특히 어플과 같은 경우는 모든 경우의 수를 고려하기가 사실상 불가능하기 때문에 더더욱 그렇습니다. 처음에는 프로토타입으로 일단은 움직이는 것을 만들어내고, 피드백을 통해 점점 진화시켜 나갑니다.
  1. 프로토타입 개발 시 주의점
  • 요건은 보통 프론트에서 나오기때문에 설계를 그릴때는 프론트에서 역으로 시작하고 , 실제 개발 시에는 디비부터 실장합니다. DB는 어플리케이션 전체에 영향을 미치는 가장 안쪽의 요소이니까요.
  • 처음부터 완전한 어플을 만들지 않습니다. 아니 그렇게 못합니다 절대. 프로토타입이란 최소한의 요건을 만족한 최저로 움직일수 있는 것입니다. 처음에는 볼품없게라도 라도 움직이는 실체를 만들고 이후에 점점 피드백을 통해 고도화합니다.

V설계에 맞는 도큐먼트의 준비

요건정의

  • 요건시나리오
    • 정상 패턴
    • 비정상패턴
  • 비기능요건 : 성능, 레이턴시 등

기본설계

  • wireframe
  • mock(bootstrap studio)
  • 시스템 구성도
  • 네트워크 구성도
  • 기능일람서
  • 화면 사양서
  • DB정의서
  • swagger
  • Redis KVS
  • API일람
  • 시켄스도
  • ER도

세부설계

  • 세부설계서
    • 함수의 인풋, 아웃풋

単体테스트

  • jest같은 프레임워크를 이용한 자동화스크립트

結合테스트

  • 결합테스트시나리오
  • 성능테스트
  • 세큐리티테스트
  • 리리즈 판정서
  • 유저빌리티 UX

'지혜 > ' 카테고리의 다른 글

정리되지 않는 복잡한 마음을 정리하는 감  (0) 2019.08.29
글을 쓰는 감  (0) 2019.08.29
노래부르는 감  (0) 2019.06.24
What 트리 그리기, 분할정복 알고리즘과 인수분해  (0) 2019.06.18
차액거래 메뉴얼  (0) 2019.05.14

노래부르는 감



1. 자세를 곧추세우기



2. 턱을 당기기



3. 배에 힘줘서 공기를 내밀기



4. 턱밑에 힘이들어가면 오래못부름. 턱밑에 힘이들어가면 안됨

- 소리를 내기위해 턱을 내리면 턱밑에 힘이 들어가므로, 턱을 내리는 대신 입 윗부분인 광대를 들어올려 입을 벌린다.


'지혜 > ' 카테고리의 다른 글

글을 쓰는 감  (0) 2019.08.29
어플리케이션을 개발하는 감  (0) 2019.07.28
What 트리 그리기, 분할정복 알고리즘과 인수분해  (0) 2019.06.18
차액거래 메뉴얼  (0) 2019.05.14
디자인 씽킹이란?  (0) 2019.04.22

분할정복 알고리즘

한번에 정복하기 힘든 문제가 있을때, 이를 세부적인 부분까지 나누어서 분할한뒤 각 문제를 해결후, 분할된 요소를 합병하는 것

인수분해

의미있는 축을 기준으로 대상을 나누어 각 부분에서 해결 방법을 찾는것.
예] 맥도날드의 매출 증가를 찾기 위해, 연령대/시간대로 나누어 특정 시간대의 연령 대릉 공략하는 전략을 세운다

분할 정복 알고리즘 == 인수분해

파이를 한입에 먹을 수 없다면, 먹을만한 크기로 나누어 먹어라!

각개격파!

분할 정복 알고리즘은 컴퓨터 공학과 수학에서 주로 쓰이는 개념이고, 인수분해는 비즈니스에서 주로 쓰이는 개념이다. 하지만 본질은 결국 같다.

분할 정복 알고리즘,인수분해와 What 트리의 관계

What 트리는 하나의 대상을 분해해 나가는 과정을 트리로써 나타낸 것이다. 분해해 나가는 과정자체는 위에서 언급하는 분할정복 알고리즘, 인수분해와 동일하다. 즉, What 트리에서 대상을 분해하기 위해서 사용하는 방법이 분할정복 알고리즘, 인수분해이다.

분할정복 알고리즘과 인수분해의 공통점과 차이점

  • 공통점 : 양쪽 모두 덩어리째 생각하기 어려운 과제에 대해, 그것을 구성하는 구성요소로 잘게 나누어 생각하는 것이다. 이때 구성요소를 나누는 기준으로는 축이 사용될 수 있는데, 의미 있는 축으로 분할하여 그 분할된 부분에서 해결책을 마련한 후 합병하는 것이다.

  • 차이점 : 프로그래밍 경우 시스템을 구성하는 구성요소를 물리적/논리적 기준으로 명확하게 구분할 수 있지만, 비즈니스의 경우 축의 기준에 따라 인수분해의 결과가 달라지기 때문에, 의미 있는 축(기준)을 잘 선정하여 그 기준에 맞는 구성요소를 분해해야 한다는 차이점이 있다.

\*프로그래밍의 예: 네트워크의 구성-> ec2, elb, subnet, vpc...  
\*비즈니스의 예: 회사의 구성-> (부서를 기준으로) 인사부, 법무부, 개발부, 영업부.. (자본을 기준으로) 부채, 누적 자본...

인수분해는 문제해결프로세스에서 어떻게 활용될 수 있는가?

탐색형 문제/발생형 문제의 정의를 명확히 한다.(구글 도큐먼트에선 paraphrasing이라고 표현함.. 정말 적절한 표현 같음)

  • 정의의 구체적인 방법
    • 문제란 목표와 현상의 GAP이므로, 목표와 현상을 명확히 할 것
    • 문제를 명확히 하기 위해 주어진 과제를 목적형으로 바꾸어 목적을 명확히 할것
      • 특히 실전에서는 다듬어지지 않은 워딩이 등장하여 문제를 해결하는데에 혼란을 주므로 목적을 명확히 한 후 목적을 띈 워딩으로 수정한다.
    • why 트리를 통해 상위의 배경을 고려
    • 구체화(5 W1 H)
      • 명확하게 정의되지 않아 이후 혼선이 발생할 수 있는 키워드들을 명확하게 정의한다. 예를 들어, 「볼빅의 매출을 높이기 위해서는」이라는 문제가 주어진다면, 볼빅들 중에서 몇 ml의 볼빅을 의미하는지 명확히 할 수 있겠다.
    • (optional)탐색형 문제를 발생형 문제로 바꾸어 생각해 볼 것
      • 가령, 「영어를 말할 수 있기 위해서는」이라는 문제는 「영어를 말할 수 없는 이유는」이라고 생각해서 그 원인을 해결하는 해결책을 입안하는 것이 어프로치하기 쉽다.

탐색형 문제/발생형 문제의 정의를 근거로, 과제형 문제/발생형 문제에서 주어진 키워드가 어떠한 구성요소로 이루어져 있는지 파악한다.

  • 과제형 문제

    • 위에서 언급한대로 비즈니스 사이드는 인수분해가 축의 설정에 따라 달라지므로, 축설정이 중요하다. 그런데 문제를 접하고 어떤 축으로 나누면 의미있을지 곧바로 생각해내는 것은 그 문제에 대한 배경지식의 풀이 있지 않는한 쉽지 않다. 이를 돕기 위한 것이 축설정의 프레임워크이다.

      프레임워크는 MESE의 논리를 이미 가지고 있는 검증된 축이므로 문제의 인수분해에 있어 큰 도움이 된다. ppt자료를 만들때 레퍼런스가 있고 없고의 차이를 크게 경험해봤을 것이다. 레퍼런스는 요건에 따라 완벽하지는 않지만 사고에 큰 도움이 된다. 축의 프레임워크는 이러한 레퍼런스와 같다.  
      예를 들어, 긍정적/부정적, 내부/외부, 온/오프, 개인/환경, 물리적/정신적, 의식적/무의식적, 공급/수요/, 사람/물건/돈/정보, 연령/성별, 사회인/학생, 시각/청각/미각/촉각/후각, 개인/법인, 신규/기존, 프로덕트/서비스, 가상/실제, 사적/공적, 질/양, 4p(product, price,place,promotion).
  • 발생형 문제

    • 발생형 문제 해결의 핵심은 원인 분석이다. 피상적인 원인 분석부터 시작하여 근본적인 원인 분석으로 이어나간다. 근본적인 원인의 분석은 원인에 대한 원인의 규명을 반복하여 접근한다. 이렇게 나뉘어진 원인의 계층에서 각 층의 원인은 피상적이든 근본적이든 해결책 마련의 근거가 된다. 이때 원인 분석은 MESE의 의해서 종류가 나뉘어지면 좋지만(생각이 누출을 막기위해), 이러한 구분보다 중요한 것은 근본적 원인을 밝혀내는 것이라는 방향성을 유지하는 것이다.

    • 발생형 문제의 원인을 파악해 나갈 때, 인과관계의 粒度가 충분히 구체적인지 고려해야한다. 예를 들어, 「꽃가루 알레르기 환자를 줄이기 위해서는」이라는 문제에서, 「꽃가루 -> 알레르기 발생」 이라는 인과관계는 중간의 세부적 인과관계가 생략되어 수많은 정보를 놓치고 있다. 이를 더욱 구체적인 인과관계로 분석하면 다음과같다. 「꽃가루 -> 꽃가루가 공기로 전달 -> 공기를 흡입 -> 기관지에 쌓임 -> 기관지에서의 방위작용 -> 기침,눈물 등의 알레르기 발생」 어떠한가? 이처럼 인과관계를 세부적으로 나타내면 그만큼 더욱 세부적인 원인을 분석할 수 있고, 세부적으로 발전한 원인에 대해 더 많은 해결책을 마련할 수 도 있다.

    • 공통

      • 축의 설정에 어려움을 겪는 문제라면, 귀납적 인수분해를 사용한다. 귀납적 인수분해란, 개별적 해결책을 생각하기는 비교적 쉬우므로 개별적 해결책을 우선적으로 생각한 후 각 해결책에 맞추어 역으로 축을 재구성해 나가는 것이다. -> 개별적
      • 인수분해를 시행할 시 그 구성요소는 stock혹은 flow(시간적 flow, ... )로 나뉘게 된다.
        stock적 구성요소 : 어플리케이션(DB- 클라우드 -어플 - 인터페이스), 신체(머리-팔-다리-몸통)
        flow적 구성요소 : 승진(퍼포먼스 - 평가 - 승진결정)

생각하기 좋게 나뉜 각 구성요소에서 해결책을 마련한다.

우선순위에 따라 해결책의 순서를 구체적으로 정한다.

-   우선순위를 메기는 기준은 다음과 같다 : 1. 해당 작업은 다른 작업에 영향을 미치는가? 2. 데드라인이 존재하는가?

bottom up/top down의 방법으로 검증한다.

  • 과제 : 면접을 잘 보기 위해서는 어떻게 해야 할까?
  1. 과제/문제

    과제형 문제/발생형 문제의 정의를 명확히 한다.

    • 면접이란 무엇일까? 면접은 무엇을 위한 것일까?(why so/so how로 상위의 배경을 고려)
    • 면접이란 「회사, 회사 사람들, 직무와 어울리는 지원자를 판단하는 것」이라고 정의(구체화)
    • 판단이란 객관적 기준과 주관적 기준에 의해 나뉜다.
    • 객관적 기준 :「명시된 기준을 통해서 in/out을 결정하는 것」
    • 주관적 기준 :「함께 일하고 싶은 사람인가?같이 맥주한잔 마시면 재밌을까?」*여기에선 객관적 기준만 생각하도록 한다.
  2. 과제/문제

    과제형 문제/발생형 문제의 정의를 근거로,

    대상의 정의가

    과제/문제~

    과제형 문제/발생형 문제에서 주어진 키워드가 어떠한 구성요소로 이루어져 있는지 파악한다.

    • 면접의 정의 : 회사,회사 사람들,직무와 어울리는 지원자를 명시된 기준을 통해서 in/out을 결정하는 것
    • 키워드 : 회사, 회사사람들, 직무, 지원자, 기준
    • 회사가 요구하는 기준, 직무가 요구하는 기준
    • 지원자의 구성요소 : 경력, 성품
    • 지원자의 경력,성품이 회사가 요구하는 기준, 직무가 요구하는 기준과 맞는지?
  3. 생각하기 좋게 나뉘어진 각 구성요소에서 해결책을 마련한다.

    • 회사가 요구하는 기준 조사
    • 직무가 요구하는 기준 조사 : 무엇을 하는지를 통해
    • 지원자의 경력 중 회사가 요구하는 기준과 직무가 요구하는 기준을 매칭시키면서 준비하기
  4. 해결책의 순서를 구체적으로 정한다.

    1. input조사

      • 이메일, 면담할때 이야기해준 정보들,공유석
      • 회사가 요구하는 것, 직무가 요구하는 것을 나누어서
    2. input에서 기준을 추출

    3. 나의 경력사항 중 기준에 맞는 것들을 찾아서 스토리 만들기

      • 스토리를 만들때의 주의사항도 input에 나와있음
      • 예를 들어, try fail finally의 구조로 말하기
  5. bottom up/top down의 방법으로 검증한다.

'지혜 > ' 카테고리의 다른 글

어플리케이션을 개발하는 감  (0) 2019.07.28
노래부르는 감  (0) 2019.06.24
차액거래 메뉴얼  (0) 2019.05.14
디자인 씽킹이란?  (0) 2019.04.22
스캐치하는 감  (0) 2019.04.10

+ Recent posts