내용에 문제가 있는 경우 삭제, 수정조치 하겠습니다.
점점 시간이 빨리 간다. 3주차가 지나갔다.
돌아보기
쪼갠 문제를 푸는 시간
이 기능을, 이 코드를 여기에 두는게 맞는가? 고민하는 시간을 줄이고자 했는데, 관련해서 직접 물어보고 한번 정리를 해서 시간을 조금 단축 시킬 수 있지 않았나 싶다. 사실, 이번 주에는 새롭게 컴포넌트를 짤 일이 거의 없었어서 그렇게 느끼는 것일 수도 있다.
아마 이 목표는 다음 UI작업을 하게될 때 한번 더 되돌아볼 필요가 있다.
그래도 하다보니 5번 중에 한번은 맞게 예측하는 경우도 생기는 것 같다.
사실 예측이라는게 기존 데이터가 있어야 가능한건데, 이전에 본격적으로 측정한 경험이 없어서 어려운 것도 있는 것 같다.
우선 이건 한 주만에 해결되는 문제는 아니다. 우선은 측정을 꾸준히 잘 해볼 필요가 있다.
보다 꼼꼼하게
필요한 것들, 체크해봐야 할 것들을 노션이나 PR에 쓰면서 이해하고 체크하니 확실히 효율성이 올라갔다.
역시 뇌에 두기보다는 밖으로 내놓을 때 효율성이 올라간다.
또한 만들어야 하는 기능 Figma가 있다면 그 부분을 정확하게 캡처하고, 개발한 내용을 캡처해서 표로 비교해보는게 직방이라는 것을 알게 됐다. 간편하되, 꼼꼼함도 챙길 수 있는 방법이다.
또 개발하면서 드는 생각들도 챙기면 더욱 꼼꼼함을 챙길 수 있다!
도움을 빨리 구하기
이전 주보다 물어보기까지 걸리는 시간 낭비가 많이 줄었다. 혼자 할 수 있는 것들과, 판단할 수 없는 context가 필요한 것들을 어느 정도 구분할 수 있게 됐다. 또, history를 따라가야하는 경우, 관련 용어 등을 미리 물어보고, 확인해서 commit이나 PR을 확인하면 좋다.
잘한 점
뽀모도로 타이머 도입
시간 측정을 위해서 25-5 뽀모도로를 도입했다.
다만, 5분 쉬는게 아니라(화장실은 가기도하지만), 5분간 다음 뭐할지를 생각하고 작성한다.
물론 완벽하게 지키지는 못했지만, 그래도 하루가 끝나고 일주일이 지났을 때 내가 무엇에 얼마만큼의 시간을 투자했는지 확인할 수 있게 됐다. 이게 시간 예측의 첫 발판이 아닐까 싶다.
꾸준히 이어가자.
그림그리기
이전 주보다 그림을 그리는 시간이 늘었는데, 이건 두 가지 측면에서 굉장히 좋았다.
1. 내 의견을 전달하기 위해서
그냥 말로 설명하는 것보다 그림을 그려서 설명하면 훨씬 직관적이고 의사소통이 간결해진단 걸 느꼈다.
그림을 그려서 설명하면 시간이 더 걸리는 것 같지만, 사실은 소통 문제를 해결해주기 때문에 시간을 훨씬 아껴주는 방법이다.
2. 빠른 이해를 위해서
역시 머릿속에서 하는 것보다는 손으로 그리고 써야 효율이 좋아진다. 보통 복잡한 기능을 만들 때, 먼저 그림을 그리고 만들고는 한다.
이미 작성되어 있는 코드도, 이전에 누군가 고민해서 작성한 코드다. 그러므로, 코드란건 이미 누군가 그린 그림이다.
따라서 기능을 유지보수하거나 고칠때는 그 고민을 따라가며 그림으로 시각화하다보면 거의 3배는 빨리 이해할 수 있게 된다.
빠른 이해는 추가적인 고민을 할 수 있게 만들고, 더 다양한 조건을 체크할 수 있게한다. 결국은 프로덕트의 완성도를 올릴 수 있게 된다.
개선이 필요한 것들
문제가 안풀릴 땐, 차분하게 돌아보기
보통 문제를 풀때 좁히면서 풀게된다. 마치 깔데기처럼.
깔데기식으로 접근하면 점차 좁혀가면서 시간을 줄일 수 있지만, 좁힌 상태에서 다음 스텝으로 나아가지 못하고 있는 경우 정말 많은 시간을 허비하게 된다는걸 느꼈다.
이런 상황은 크게 두 가지가 있었다.
1. 윗단계에서 잘못 분류한 경우
물론, 정확하게 분류해서 좁혔다면 그럴 일은 없겠지만, 사람인지라 윗 단계에서 고려하지 못한 것들이 있을 수 있다는 것을 항상 생각해야한다.
좁힌 상태에서 생각하는 것은 다른 것을 생각하지 못하게 만든다.
너무 많은 시간을 썼다 싶다면, 가설을 폐기하고 다시 구조를 잡고 다른 조건은 없는지 재접근해볼 필요가 있다.
빠르게 전환해서 확인해야 효율성을 높힐 수 있다.
2. 새로운 상황이 추가된 경우
기존 상태에서 새로운 것이 추가되었다면, 기존 뷰를 위에서부터 다시 바라봐야한다.
좁힌 상태에서 고쳐나가려고 하다보면 하나를 고치면 다른 문제가 생긴다.
예를들어 유틸 함수를 위한 타입 설계를 할때 사용하는 곳에 맞춰서 타입을 좁혀 놓았는데, 사용하는 곳이 더 넓은 타입을 요구하는 경우, 파일마다 대응하려고 하면 아래와 같은 상황을 맞이할 수 있게 될 것이다.
이건 위에서부터 바라보지 않으면 절대로 풀 수 없는 문제다. 그림과 마찬가지로 시간이 더 오래걸릴 것 같아도, 좁혀진 뷰를 버리고 다시 넓은 뷰를 바라봐야 할 때 다.
느낀점
이번 주에 AI관련해서 팀원분들이나 다른 분들이 어떻게 사용하고 계시는지를 어깨너머로 알 수 있었는데 AI툴을 좀 더 잘 써봐야겠다는 생각이 들었다.
얼마나 쓰느냐가 아니라 어떻게 쓰느냐가 중요하다. (우선 gpt를 유로로 전환했다...)
나는 거의 리서치나 코드 품질, 공식문서 대신읽히기로 쓰고있는데
외에도 시간 측정이나, 업무 테스크 분류/체크에 AI를 도입할 수도 있을 것 같다.
이건 이번주에 좀 더 고민해봐야겠다.
마무리
저번주에 굉장히 바보같이 일했다면, 이번주는 점점 줄어들고 있는 것 같긴 하다.
물론 이건 환경에 적응해가면서 개선되는 것도 있어서, 위의 문제 해결 과정처럼 좀더 본질적인 것들을 고쳐나가면서 효율적으로 일할 필요가 있다.
그래서 생산성을 향상시키기 위한 이번주 목표를 정리하자면...
1. 뽀모도로 유지 및 좀 더 잘 작성하기 (예측의 시작이 될 수 있는 부분이다.)
2. 문제가 안풀릴 땐 다시 상단부터 다시 좁혀나가기
3. 문제에 새로운 상황이 더해졌을 때 확인해보고 기존 뷰를 빠르게 버리고 새로 시작하기
4. 코드/맥락 파악시 그림을 적극 이용하기
5. AI를 활용해서 생산성을 높히기 위한 방법이나 툴 도입하기 -> 테스크 쪼개기/시간 관리 쪽으로
