- 출근하자마자 바로 일을 시작하게 되면 일에 매몰되기 쉬움
- 주!기!적!으로 큰그림을 정리하고 시작해야함. 내가 어디에 있는지, 나와 함께하는 사람들은 뭘하고 있는지, 앞으로 뭘 해야하는지 수시로(매일) 정리해야 일에 매몰되지않을 수 있음
- 책의 제목만 뽑아서 마인드 맵처럼 나열하고 그려보면 책의 전체적인 구조를 파악하기 쉬움
1장 상대에게 전달하기
- 얼치기 독심술사 증후군
- 더 중요한 안건이 있어도 일단 과제부터
팀장님이 뭐해라고 얘기하는게 과제가 아닐 수 도 -> 왜해야하는데를 계속 물어야 함
회의인지 뭔지, 그 모든게 과제를 위한 것
기대반응을 확인
-> 얘기할 때 전달만 하는 사람, 반응을 생각하는 사람
내가 기대하는 반ㄴ응이 명확히 있다면 듣는 사람도 뭘 기대하고 있는지에 대해 알 수 있음 -> 효과적 발표
-> 팀장님이랑 얘기하면 항상 할일이 생김
상사일때 검토보고서를 받았는데
-> 조사 1, 조사2, 소비자 동향
--> 그래서 뭐? 생각을 한번 더 해야해
추이를 보면서~~ 이렇게 얘기하면 듣는 사람으로 하여금 힘들게 할 수 있음
-> 전년과 대비할때 90퍼정도아래로? 한 30퍼 아래로? 이런식으로라도 말해야함
감도높은 정보 수신자는 자신에게 어떤 반응을 기대하고 있는지 파악한 후에 읽기
-> 1장 읽으면서 이거에서 얻기 위한 정보는 무엇인지 등
불만을 나누는 것
나는 서비스별, 시설별 이렇게 생각했는데
이런 방법도 있음:
- 돈이 필요없는 것
- 당장 할 수 있는 것
- 시간이 걸리는 것
- 돈이 필요한 것 (상급자의 결정이 필요한 것)
요구사항 분석 === 요구사항 이해 랑 같은말(분류해서, 기능으로 바꾸는 것)
- 용도가 뭔지, 세개의 용도가 다른데 같이 비교해서ㅓ 할 수는 없겠지
분류할 수 있는 프레임워크를 사용해라(4C같은)
개발 docs 쓸 때:
- 요구사항
- architecture(네모가 클래스면)
- 상세설계(architecture design -- 네모가 프로세스면)
- 운영(배포, 재시작 등)
https://hewonjeong.github.io/orthogonality/
MECE하게 하려면 프레임워크를 써야함 -> 4c같은
이야기의 비약 -> 중간에 ㄷ비어있는것. 앞과 뒤가 연결안되는것
비약을 없애기 위해 -> (so what/ why so)
추천 책
1. 대체 뭐가 문제야?
2. 질문의 7가지 힘
의사결정 방법:
필수적으로 만족해야할것, 그 이외의 이점과 단점들
-> 캐스트 아웃
(alert tool 찾은 것 처럼)
