일, 일 잘하는 법

일

• 업무 퀄리티를 위한 업무 플랜, 진행, 마무리 - 가설을 세우고 검증한다.
• 플랜
  • 큰 문제를 잘게 쪼갠다
  • 큰 그림을 그린다
• 진행
  • 레퍼런스를 모은다
  • 테스트 케이스를 생각한다
• 예측하고 측정하고 개선한다
  • 일정이 얼마나 걸릴지 먼저 잡아놓고 실제로 걸린 시간을 확인하고 어디서 차이가 났는지 정리한 후 다음 업무에 반영한다

업무 퀄리티 높이기

• 우선순위 외의 업무는 중간중간 하려고 하지 않는다
• 우선순위 업무 3개를 선정해서 그것에만 최대한 집중한다
• 하나의 업무를 3가지 시선으로 다시본다.
  • 일단 빠르게 개발자의 시선에서 구현
  • 고객의 시선에서 검증
  • 사용자의 시선에서 검증
• 반례를 잘 체크한다
  • 반대편이 되어서 생각해본다
• 히스토리를 잘 남겨놓고, 잘 활용할 수 있도록 정리해놓는다.
• 손흥민이 토트넘만을 위해 열심히 성과를 내는 것이 아니라 자신의 커리어를 위해 하다보니 토트넘도 같이 이득을 본다
• 일을 할 때는 아래를 봐서는 안된다. 못했던 것을 생각하며 현재를 무마하지 말고 잘된 것을 생각하여 더욱 정진해야 한다
• 안보이니까 괜찮겠지 보다 안보이는곳까지 최선을 다해야 한다. 하지만 코드를 짤때에는 모든 곳을 잘 보이게 해야 한다
• 어디에서 일을 하냐가 중요하다. 아무리 많은 경험과 기술이 있어도 회사마다 다르기 때문에 어떤 기술을 할줄 아느냐보다 어떻게, 어떤 방식으로 해왔느냐가 더 중요한 것이다
• 문제 해결을 위해 탐구하고 고민했던 부분이 도움이 될 것이다
• 내가 더 발전할 수 있는 곳에서 나보다 뛰어난 사람들과 일을 하면서 나 자신의 삶을 살아가고 싶다
  • 나 또한 나중에 나같은 사람과 일하면서 가르쳐 줄 수 있으면 좋겠다
• 직원들에게 자유로운 문화를 누리게 해주려고 생긴 문화가 아니라 성과를 만들어내는 사람이 일을 가장 잘 할 수 있는 방법을 찾다보니 만들어진 것
• 1차원 높은 생각
  • 아이유는 그저 노래만 부르는게 아니라 연예계 시스템을 이해하고 자신의 사단을 꾸려서 동반자로 이끌어가고 노래에 대해서도 다양하게 접근한다. 80년대 노래를 리메이크하면서 과거를 학습하고
• 실세계의 문제를 인식하고 이를 구체화하고, 정확한 목표를 설정해서 문제를 해결해 나가는 부분
• 크리티컬 싱킹
  • 같이 일하는 사람들에게 듣는 이야기
• 하나의 일을 할 때 시작점과 끝점을 잘 정의해놓고 마무리를 퀄리티 있게 짓고 다음 태스크로 넘어가면 좋겠다.
  • 팔로우업 단계도 고려
• 각 태스크는 나의 한 끗이 들어가야 한다

업무시간

• 4시간의 업무 몰입시간을 확보하기 위해
• 11시반 전에 4시간동안 일하려면
• 7시반부터 시작하게 된다
• 4시반까지
• 오전 업무 전에 내 삶이 있어야하지만 너무 많은걸 하지는 말자
• 산책 독서 식사 이렇게만 해도 많은데 이것도 줄이는게 맞다
• 빵 먹고 음료수 먹고 모닝페이지 쓰기로 끝 씻어야하는데 머리감기 양치하기
• 내가 시간을 이끌어가야 한다

열정, 치열함과 집요함

피터 슈라이어가 기아에 오게된 것은 이사진의 열정을 봤기 때문. 그저 그런 목표로 그저 그런 노력을 하는 회사에 와서 능력을 보여줄 필요는 없었을 사람이 오게 된 것은 비전을 봤기 때문일 것 같다

일 하다가 중간에 다른 일 하는 경우가 왕왕 있다.

이거하다가 막히면 다른걸 하면서 생각을 다시 하는 방식으로 일하고 있다. 막히지 않을 때도 갑자기 생각난 걸 하러 가려고 할 때가 있다. 한 포모도로에 하나의 업무를 지키려는 방식을 취해봐야겠다.

요구사항에 대해 깊게 생각한다

• 리스트에 있는 것을 꼼꼼하게 챙기는 시간이 필요하다
• 나중에 챙겨야지 생각했다가 늦어버렸다
• 내가 애매하게 생각하면 풀고 가는게 좋다
  • 문구 하나도 중요할 수 있다. 신경을 좀 더 써야한다
• 업무를 받으면서 요구사항을 구체화한 후에 그것에서 내가 살을 더 붙여서 진행하기
  • 의도한 요구사항과 다른 이야기를 하는 경우가 있다. - 개선 필요
• 확실하지 않은 것은 한번 더 확인한다
• 걱정되는 부분이 있으면 그걸 확실히 테스트하고 넘어가야한다

KPI기반의 목표

• https://blog.shiren.dev/2022-03-07/
• KPI기반의 목표가 내려온다
  • "유저의 A 화면에서 B 화면으로 전환하는 클릭률을 20% 높인다"
  • 처음 이 목표를 봤을 때는 우리 상황과 안맞다고 생각했는데 다시 생각해보니 저렇게 내려오면 내가 무엇을 해야할지 스스로 고민해볼 수 있어서 더 넓은 관점에서 일을 할 수 있을 것 같다
  • 세부적으로 내려오는 태스크는 그냥 받아치더라도 저런 식의 목표를 고민해서 일을 만들어내도 될 것 같다.
• 할 업무를 그리게 되면 그것을 참여할 사람도 직접 구한다
• 성과를 많이 내고 임팩트가 있는 일에 사람이 몰리게 된다
• 첫 업무는 성과를 어떻게 측정할 것인가, 어떻게 검증할 것인가에 대한 문서작업
  • A/B 테스트를 통해서 최종적으로 적용할지 말지 정한다는데
  • 이건 A가 이미 있다는 전제 하에 이루어지는 거
• 성과 지표
  • 프로젝트 영향력
  • 엔지니어링, 서비스 전반
  • 피플
  • 리더쉽

KPI와 다른 OKR은 어떤게 다를까

예외 상황을 잘 다뤄야 실력이고 프로의 자세

• 기능구현을 넘어 예외상황 고려를 하는 것이 일
• 일반적인 상황에서는 필요없는 것들이 특수한 상황에서 항상 뭔가를 만들어낸다. 하지만 시간은 한정적이라 욕심내지말고 범위와 한계를 정하고 하는게 좋겠다
• 어려운 문제일수록 작게, 점진적으로 풀어가야하는데 알고리즘 문제를 이렇게 풀어보고 싶다

프로페셔널

• 전문가는 결과로 아마추어는 노력으로 말한다
• 몸이 재산
• 일에 투자를 아끼지 않는다
• 개인적 감정 < 돈?
• 프로페셔널한 사람
  • 이병헌
  • 레반도프스키
  • 강호동

Feedback#프로페셔널과 선순환

프로는 마지막 한 끗이 좋아야 한다

섬세한 마무리가 필요하겠다

아마추어처럼 굴다

약속한 시간을 철저하게 지키는 것으로 프로의 가치를 입증

한달의 휴식을 갖고 그 뒤에 뭔가를 하려고 하면 정작 한달 뒤에는 또 다른 생각이 들 수 있다. 계획을 세우는 것은 미래를 예측하는 것만큼 틀릴 수 있다. 그렇기에 프로는 약속한 시간을 철저하게 지키는 것으로 가치를 입증할 수 있겠다

영향력이 있는 인물일수록 원인과 결과를 고려해 말하는 이들이 존경받는 듯하다 자신을 프로라고 생각하고 프로답게 행동하자.

• 종립님 블로그 참고

체계적 업무 진행

• 팔로우업 단계를 태스크단계에 추가한다. 현재 안하고 있지만 나중에 진행해야 할 것
• 스니펫 적극 활용
• 내가 해야하는건 기획과 관리, 그리고 기획하기 위한 수양
• 효울적으로 기획하기 위해선 워크플로우를 그려놓아야 하고 프롬프트를 만들어놓아야 한다
• 프롬프트 결과에 html은 빼고 정형화 시키고 그걸 검증하는 ai를 한번 더 돌려서 이상한 결과를 걸러야 할거같다 쿰스개발할 때 api 명세를 먼저 만들고 개발한게 아주 효율적이었다

일잘러가 되고 싶다

• 신입사원의 코드든 시니어의 코드든 운영 중인 소프트웨어에 들어가는 것은 똑같다 안정되게 돌고 퀄리티도 비슷해야 한다.
• 시스템이 완벽한 회사는 없다. 시스템에 맡기기보다 잘 진행되도록 잘 이끌어가야 한다.
• 일 처리를 확실하게 하는 사람들을 보면 어떻게 하는지 알아보자. 상황에 대한 고려를 많이 한다. 나중에 문제가 생기지 않도록 확인한다.
• 완급조절
• 업무 능력 향상을 위해 애쓰면 내 성장이 된다
• 일을 믿고 맡길 수 있는 사람이 되고 싶다
• 업무에 탁월함을 더하고 싶다

정해진 요구사항을 빠르게 구현하는 것도 프로그래머의 능력 중 하나겠다

고객의 어렴풋하고 추상적인 계획을 구체화 시킬 수 있어야 한다

• 요구사항
• 다이어그램
• 테스트코드
• 동작하는 함수

일을 하면서

내가 시니어라고 남이 생각하게 만들면 좋겠다. 한번씩 피드백을 받는 기회를 잡고, 일을 해온 것에 대해 구체적으로 검증을 받으면 좋겠다.

능력 향상을 위한 투자

오타니가 실력향상을 위해 최신기술을 도입하면서 투자를 아끼지 않는 것처럼 나도 뭔가 투자를 아끼지 않아야하지 않을까 싶다. 강의를 듣는다든지, 환경을 더 좋게 만든다든지

업무 처리 능력 상승을 위한 스킬 하나 익히기

• 이런 것들을 익히고 나서 계속 확인할 수 있을 방법은?
• 믿을 만한 사람이 되고 싶다
• 같이 일하고 싶은 사람이 되고 싶다.

왜 일을 더 열심히 해야 하는가

• 글로벌 기준으로 실력이 평균 이상이면 좋겠다
• 앞으로 맡게 될 업무에 퍼포먼스를 내야한다
• AI 시대에 퍼포먼스가 증가하면서 실제로 일을 더 잘하게 됐는가?

일하면서 느낀 부분

업무에서 아쉬운 부분을 생각하고 지금 생각했을 때 어떻게 하면 그 아쉬운 부분을 채울 수 있었을지 생각하면 다음에 같은 상황에서 같은 아쉬움이 없을 수 있을

업무 능률 끌어올리기

8시간의 업무 시간. 그 외에는 개인 시간 투잡을 뛴다고 하면 업무 시간에 효율을 못낼거 같다고 생각해서 투잡을 안해야겠다고 생각하면서 그렇다면 업무 시간에 효율을 잘 내려면 어떻게 해야 하나 생각하니 업무 시간을 지금은 그저 흘러가는 시간으로 쓰고 있는데 그러면 안되고 시간 내에 아웃풋을 더 잘내도록 계속 만들어야 하는 것이고 그러기 위해서는 아웃풋이 어떻게 퀄리티를 높일 수 있는지를 봐야 한다.

검토 검토 또 검토

• 시간과 꼼꼼함 중 하나를 확실히 택한다. 지금은 느리면서 놓치는것도 많은 것이 고민..
  • 속도를 높여서 피드백을 빨리 받던지 천천히 하더라도 나에게 만족할 수 있을만큼 하던지
• 일을 세분화하고 완료를 확인한다. 더 세분화할 수 없을만큼 세분화해서 관리해보자
• 내가 작성한 부분을 돌아보고 이것이 미치는 영향을 고려하고 이것이 바뀌면 같이 바뀌어야하는게 없는지 확인하고
• 계속 전자쪽이 낫다고 생각했지만 계속 빼먹는 모습을 보이는 것도 힘들고, 방해를 자주하는 것 같다. 전자쪽으로 가려면 실수를 공개하고 다음에 그 실수를 안하기 위한 방법을 메뉴얼화하여 누적된 데이터를 만들 수 있으면 좋겠다. 아마존이었나? 실수할거리를 찾아내서 그 실수를 다른 사람이 안하게 될 것이라 생각해서 보상을 해주는 회사가 있었다. 내가 지금까지 한 실수들을 잘 정리해서 공유하고 나도 같은 실수를 반복하지 않도록 하면 좋겠다.
• 일을 세세하게 나누고 일 한 것을 다시 돌아본다는 것을 해야겠다고 생각했었지만 막상 하기 쉽지 않다
• 놓친 부분이 있는지 확인하려면 어떻게 하면 좋을까

꼼꼼함과 빠른 처리

• 꼼꼼해지고 싶다. 꼼꼼해져야 하나? 적어도 허술해서는 안된다.
• 근데 린 스타트업은 일단 만들고 보자는 취지다. 완벽한 것은 없기 때문이고, 한번에 할 수 있는 것에는 한계가 있고, 사용자 반응을 확인하기 위함인데, 그러고보니 빠르게 초기버전을 만들어내더라도 그 초기버전 자체의 완성도는 갖추어야 한다. 린 스타트업에서 완성도는 어떻게 관리할까
• 복잡성을 염두에 두고 미리 뼈대를 만들어 놓는 것보다, 작게 분리하는 것이 복잡성을 컨트롤 할 더 나은 방법 같다.
• 자바의 폴더구조는 처음부터 중첩된 폴더를 미리 만들어 놓는데, 이런 부분이 거슬린다. 폴더 안에 폴더가 들어가 깊어지면 컨트롤이 어려워질 것 같다.
• 근데 안드로이드 프로젝트는 분리된 아키텍처가 가능한가? 한 패키지 안에 있어야 패키징을 해서 앱을 만드는 거 아닌가?
• 안드로이드 앱도 서버를 마이크로 서비스로 하고, 앱 자체는 웹앱으로 가볍게 만드는 구조이려나?

반복

• 같은 것을 여러 번 볼 때 안다고 생각하고 대충 보고 지나가게 되는데 같은 것을 반복해서 보는 좋은 방법이 있을까
  • 시간의 텀을 둔다? 그래도 안다고 생각하고 넘어가는데..

보고

• 안심 첫 문장
  • 어떤 건으로 어떤 내용을 얘기하려고 한다고 첫 문장을 꺼낸다
• 상대가 원하는 것을 주려고 해야한다
  • 근데 상대가 원하는게 뭔지 알 수 없다. 그래서 처음에 원하는 것을 알아가도록 해야한다

막히는 문제가 있을 때 도움 요청하는 방법

• 문제를 정확하게 설명
• 어떤 방법을 써서 어디에서 막히는지 설명
• 시도했던 방법들을 설명
• 정확하게 어떤 부분에 도움이 필요한지

일 못하는 사람

1. 세상일 혼자 다하는것같이 힘들어함
2. 일 순서 엉망임
3. 효율은 버리고 시간만 녹여서 일함
4. 일에 고집이 셈
5. 업무 공유 없음

• 맨날 혼자 억울해함
• 본인이 일 제일 많이 하는줄 알고있음
• 업무시간에 딴짓하고 야근함
• 기억도 못하면서 메모도 안함

전문가

국과수에 다니는 사람은 어떻게 전문가가 되었을까

• 쌓아온 경험(전공지식)
• 선임의 경험
• 연구
• 관련 분야 논문 꾸준히 읽기
• 실무 경험

외부인도 지식은 쌓을 수 있지만 전문가와의 차이는 경험인가보다.

전문가는 암묵지를 고객에게 잘 건드려줌으로써 신뢰감을 얻게 된다

그동안 잘못된 실험 이후에 전문가들이 그 실험결과에 대한 원인을 끼워맞추는 것을 보고 불신이 쌓였었다. 미디어에 자주 나오는 전문가들이 나중에 비과학적인 이야기를 많이 했다는 사례들을 보고 불신이 쌓였었다. 하지만 그럼에도 참고할만한 내용이 있으면 잘 걸러내서 써야한다. 결국 현재의 모든 연구는 과거의 연구를 토대로 이루어지고, 모든 것을 의심해야 하고, 그래서 스스로 내용을 검증하고 확인해야 하는 것도 연구의 일부분이므로

덕후, 딜레탕트, ㅈ문가, 아마추어,

체계적으로 공부하고 한 주제에 대한 정보를 쌓은게 아니라서 내가 IT 업계의 전문가라고 할 수 있을지에 대한 의문이 많이 든다. 그 일을 몇년이나 했으면 누구나 전문가라고 할 수 있는 것일까? 글쎄...

덕후질

깊게 파고드는 것은 즐거워야 할 수 있다

베텐을 남에게 알려주고 같이 재미를 느끼려면 겉으로 나와있는 정보 말고 여태 있었던 에피소드에 따른 그들 사이에 이루어지고 있는 대화주제나 분위기를 알아야 한다. 진입장벽은 없지만 숨겨진 재미가 있다. 이것이 이스터 에그인가

경력

경력이라는게 '이걸 이렇게 해도 되나?' 싶을 때 그걸 대답해주는 경험을 쌓는 것 같다 신입 때는 애매할 때가 많은데 그럴때 항상 선임에게 물어봐야 한다. 그리고 경력이 쌓일수록 그런 애매한 부분에 대한 결정에 괜찮은 대답을 해줄 수 있는 능력이 발달되는 것 같다.

• 능력이 발달된다기 보다 그런 상황에 대한 경험을 통해 알게 되는 것인 것 같다.
• 경력이 오래되었다는 것 자체는 장점이 아니고 어떤 일을 할 수 있는지를 어필

경험이 중요한 이유

직접 경험하기 전엔 와닿지 않는다 세부적인 부분을 알 수 있다 암묵지로 구성된 부분이라 공유가 되지 않은 정보가 있다

일하는 방법

• 불가피한 선택 보다는 의도한대로 구성하고, 불가피한 선택들은 기록해뒀다가 반드시 처리한다
• 단순함이 완벽한 동작보다 우선하기 때문에 이런 식으로 우선순위에 따라 결정한다. 복잡성을 줄이기 위해
• 이미 보내진 것을 지우는 것은 고려하지 않고, 변경 이후에 가는 알림이 정확한 동작을 하도록 하게 한다.

종립님께 배우는 일 잘하는 법

• 원인과 결과를 고려해 말한다
• 다른 사람들이 자신의 똑똑함을 나에게 드러내게 하자
• 새로운 도구를 이해하는 것보다 매일 사용하는 도구를 이해하는게 중요하다
• 종립님 블로그에서 인상깊었던 내용들
  • 주니어일 때 엄청 즐겁게 봤었고 다른 주니어들에게도 도움이 많이 되겠다

일과 코딩

• 업무 기획 시나리오가 코드에 잘 녹여져 있으면 좋겠다
• 이전에 고려했던 것이 시간이 지나서 다른 변경사항에 영향을 받을 수 있는데 이걸 잘 확인할 수 있으면 좋겠다
• 비즈니스 로직과 테크니컬 로직이 구분되면 좋겠다
• 서버의 정상 상태를 측정해서 스케일 아웃이 잘 되도록 확인
• 개발자가 개발에만 집중하도록 업무 프로세스 파악 후 개선
• 테스트 코드는 이미 짜여진 코드의 안정성을 높여준다
• 기능별로 커밋을 잘 나눈다
• 커밋 시 동작 가능한 단위로 한다
  • 한 동작마다? 한 단위마다?
  • 처음 틀 만들 때는 빠른 개발을 위해 되는대로 작성해놓고 커밋만 따로 쪼개서 하고 싶은데 가능한가?
• 커밋 단위 관리 필요
  • 최대한 잘게 커밋해도 될 듯
• 기능에 문제 없는 것이 확인 된 단위로 커밋을 하고 싶다
  • 기능에 문제가 있는지 없는지는 어떻게 확인할까
  • 검사하기 좋은 아키텍처를 가지는 것도 중요하겠다
  • 정적 테스트가 완료되면 문제 없다고 할 수 있게끔 해야겠다
  • CI를 커밋할 때 하는 것보다 PR을 할 때 하면 PR에 결과 표시해주면 한 곳에서 확인할 수 있어서 좋겠다
  • 커밋할 때는 짧게 확인 가능한 위주로 테스트하고, PR에서 좀 더 진행하면 좋겠다

일

• 우선순위와 업무 범위 설정이 좋은 퍼포먼스를 만든다
  • 스탭으로 신경쓸걸 제한하고 달성하고 넘어간다?
  • 프로덕트 라이프사이클
• 완성본을 계속 보면 개선할 게 보인다 -> 퇴고
• 아웃풋에 대한 판단만 한다
  • 인풋이 가설로 바뀌는건 자동이다
  • 가설이 아웃풋에 어떻게 영향을 미칠지는 내가 판단
  • 가설이 생각나면 그건 바로 반영가능
  • 아웃풋 지표가 인풋에 잘 연결되어있는지 체크 🔽
  • 대시보드 마무리
  • 에이전트를 매니저로.아침 오후 2번만 알림
• 사례 1
  • 30분 동안만 시스템설계한다
  • 30분동안 할 수 있을것같은 일을 시작한다
  • 30분이 지난 후 안끝났으면 원인을 찾는다
  • 다음에는 그걸 개선한 업무선택을 하거나 퍼포먼스를 늘린다
• 판단해야할게 계속 쌓여봤자 못처리한다
  • 5개의 판단요구가 나오면 4개는 폐기하고 1개만 처리한다
  • 또는 위임한다
• 하루에 4시간만 일해야한다고 제한하면 뭘 없애고 뭐에 집중하고 싶을까
  • 4시간만 일한다
  • 30분은 시스템 개선
  • 1시간은 리서치와 노트정리
  • 2시간 30분만에 아웃풋에 대한 판단을 해야한다
• 가설수립 실행 측정
  • 월요일엔 가설수립
  • 화요일엔 실행
  • 수요일엔 측정
  • 나머지는 관찰. 다시 월요일에 가설수립 후 개선
  • 이것도 에이전트가 흐름을 만들도록
• OKR
  • 목표 (무엇)
  • 키 리절트 (어떻게)
  • 목표를 점수화하고 그 점수가 잘 측정됐는지 검증하는 2단계 지표화
  • 1점이 가장 높지만 그 점수가 유효한지도 검증
• 일할때 중요한게 내 업무 공유다 리더에게 내 업무 가시성이 높아지게 하는게 일 잘하는거
  • 나는 일 잘 못함
  • 최근 뉴스도 쫙 받아서 잘 팔로우 해야한다
• 좁혀진 유효한 질문이 좋은 결과를 만든다
  • 큐레이션해야하는 컨텐츠를 0부터 시작하는게 아니라 10가지 중에 3가지를 뽑는 것
• 업무에서 작업하고 전달하고 피드백 반영하고 다시 전달하고 하는 과정이 매끄럽지 않다
  • 딱 측정가능하게 포인트를 만들어야 한다
  • 내가 전달드리면 바로 쓸 수 있어야한다
• 업무
  • 쫓기면 안된다
  • 진행할 범위를 정하고 달성하고 다시 확인한다
  • 큰 태스크 안에 작은 태스크 관리할 수 있게 구조를 잡아야한다
• 업무 진척이 너무 느리다
  • 하루 하루 뭐가 진행된게 있어야하는데 밀린다
• 정신적 보상
• 조직지능
• 조직이 커졌을 때 파일로 관리가 될까?
• 업무시간을 줄인다 <-> 업무량이 늘어난다
  • 업무를 3개를 처리하던걸 20개를 처리해야한다? <- 안됨
  • 업무시간이 8시간이던걸 4시간으로 줄인다? <- 안됨
  • 8시간 일 하고 3개를 하지만 생산성이 늘어나려면?
  • 매출 증대에 기여

Work Log

업무가시성

• 내가 하는 일을 내가 보면서 일을 해야 한다. 그걸 남에게도 보여줄 수 있다
• 업무일지노트의 큰 타임라인이 필요할듯
• 업무가 끝나면 회고하는 것도 필요할듯
• 검색 용이하게
• 인박스를 비우는 식으로 처리? 비웠다고 생각했는데 다시 돌아봐야 할 수도 있고 처리하기 애매한 것도 생긴다
  • 인박스보다는 --지우기-- 이걸 더 활용해보자

• 고민의 과정과 실제 한 일을 분리하고 싶다
  • 문제상황과 해결방법을 따로 빼놓고 싶다.

코넬식 필기 작성법처럼 업무일지 적기

• 특정한 작업을 할 때 한쪽에 그 작업에 대해 생각할 거리들을 계속 띄워놓고 작업을 하면 좋을 것 같다. 예를 들어 글쓰기를 한다고 하면 글쓰기할 때 지키면 좋은 것들의 리스트를 한쪽에 띄워놓고 docker 문서 작성을 한다고 하면 docker 요약한 것을 한쪽에 띄워놓고
  • 즉 요약, 총 개괄을 한쪽에 띄워놓으면 한눈에 할 일의 전체를 볼 수 있고, 효과적일 것 같다
  • 요약과 개괄이 그러고 보니 다른 내용이다
• 할 일에 대해서 미리 크게 정해놓고 그것도 띄워놓고, 그 분야에 대한 내용도 띄워놓으면 되겠다
  • 코넬식 필기 작성법을 보고 생각
• 왼쪽에 아사나를 띄워놓고 태스크를 만들면서 일처리하고
  • 오른쪽에 노트를 두고 생각할 거리들을 적어놓는다
  • 일을 세세하게 나누고 일 한 후 돌아본다
  • 놓친부분을 찾기위해 반대편이 되어 생각해본다
• 근데 한 화면에 너무 많은게 띄워져 있으면 정신이 산만해진다. 적절한 배치가 필요할 듯

아사나의 태스크와 깃랩 링크가 연결되어있지만 한 눈에보기 어려움 아사나에는 요구사항이 있고 깃랩에는 그에 해당하는 코드가 있어서 준비물은 준비되어있다 이를 잘 보여주면 리뷰에 좋을 듯 코드 작성 전에 반드시 글을 쓰게된다. 요구사항이라도

정리

• 작업 전
  • 목표 설정 (KPI)
  • 요구사항 확인
  • 기간 산정
  • 계획
• 작업 중
  • 태스크 관리
• 작업 후
  • 복기
  • 후기
  • 문서화
  • 피드백

작업 전 확인

• 업무 시간의 퀄리티를 높여서 업무의 퀄리티를 높인다
• 하루에 처리해야하는 업무를 정의해놓고 업무가 종료되면 업무를 마감한다
  • 그걸 점점 빠르게 해결해나가서 업무 시간을 줄이기 위해 열심히 하는 동기를 만든다
  • 업무를 빠르게 해결하기 위해 어떻게 해야할지 계속 연구할 수 있게 한다
  • 결과적으로 업무를 퀄리티있게 빠르게 처리하는 상태가 된다
• 기간을 기준으로
  • 끝내야하는 지점을 정해놓고 퀄리티 있게 마무리 짓고 걸린 기간을 확인하고 다음엔 더 빨리 할 수 있도록 최적화한다
• 업무 기간 산정
  1. 파악하는 시간
  2. 실행하는 시간
  3. 정리하는 시간

작업 중

• 업무일지는 업데이트 단위로 한 페이지를 작성하고 업데이트 이후 한 페이지의 내용을 재검토해야 한다
• 실제로 사용해보면서 테스트해야 한다
• 하지만 업데이트 후 기존동작도 이상없는지 확인해야 한다 사이드이펙트가 없도록 설계하는 것이 좋겠다. 관계있는 부분을 바로 알 수 있으면 좋겠다
  • 업데이트 후 체크리스트를 잘 관리하면 일이 수월해 질 것이다
  • 커밋할 때 빔으로 켜서 Todo에서 메모하던걸 붙여넣으면 좋겠다
• 업무 노트
  • 위 아래로 분리해서 위에는 큰 리스트만 적어놓고 밑에 새 문서 만들어서 상세한 업무 내용 쓰기
• 개발 - 검토 - 반영의 흐름을 태스크에 표시하기

작업 후 회고

• 예상 시간을 생각해보고 오늘 마감 상황을 정의한다
• 업무 종료 후 상황을 확인한다
• 어떻게 개선할지, 유지할지 재정의한다
• 회고가 중요한데~ 업무 정리하고 시작해보자

데일리 레코드

• 그냥 그날의 컨텐츠를 읽어서 녹화한다
• 돈을 어디에 썼는지
• 일과 중 다른 뭔가를 한게 있는지
• 적극성을 발휘한게 있는지

LLM과 함께 일하며 업무일지 정리

• 인풋은 여러개 -> 아웃풋은 하나
• 컨플루언스 문서로 마감처리
• 다시 문서를 읽어서 인풋으로 집어넣기
• 와우 피드백 루프
• 사용하는 툴들을 다 mcp로 연결해놓고 관리
• 찾아본것, 코드 결과물, 요구사항 다 정리, google 문서까지도
• 연결할 툴
  • gitlab
  • google drive
  • asana
  • confluence
  • slack
  • 대화내용
  • 노트

업무일지에 들어갈 내용

gpt

• 주요 업무 내용
• 성과 및 산출물
• 문제, 이슈 사항
• 다음 계획
• 향후 참고될 정보

claude

• 주요 작업

• 완료사항

• 진행사항

• 이슈/도전

• 사용 도구 - 오늘 사용한 도구, 접속한 웹사이트, 검색한 내용들 (오호라)

• 배운점

• 정보를 한페이지에 요약하고 싶다 (입력은 오픈클로가 해줌)

  • 유료툴을 써서라도 한 눈에 보고 하나로 출력되는 시스템을 만들어야겠다
  • 보는 채널도 하나로 만들고 들어오는 채널도 하나로 -> 오픈클로가 입력 처리를 하나로 만들어주었다.

회고에 들어갈 내용

• 내일 핵심 목표
• 예상 측정 판단 회고
• 의사결정
• 페인포인트 찾은 것
• 오늘의 질문 / 내일의 대답
• 헤드라인
• 업무 건별 한줄 회고