[ ⏰ Task estimation 을 3개월 | 커리어리

[ ⏰ Task estimation 을 3개월간 하면서 느낀점 ] 퍼블리에서는 Task estimation 한 뒤, 실제 일 하는 시간을 타이머로 기록하고 모여서 회고하는 시간을 가지고 있다. 3개월간 하면서 느낀점은 1. 거의.. 아니 반드시.. 내 생각보다 오래걸린다. 예측할 때는 이건 간단하겠네~ 이렇게 하면 되겠네~ 하고 얼마 안 걸릴 것 같지만 실제 타이머로 시간을 측정해보면... 내가 고려하지 못했던 시나리오, 예상치 못한 버그, 테스트 등으로 인해 예상했던 시간보다 오래 걸린다. 개발하다 보면 시간이 정말 빨리간다. 2. 작업당 나의 생산력을 구체적 시간으로 확인 가능. 작업 당 실제 걸린 시간을 놓고 보면 나의 생산력을 숫자로 확인할 수 있다. 확인에서 끝나면 안되고 회고하면서 특히 시간이 오래 걸렸던 부분을 다음에는 어떻게 개선 할 수 있을지를 생각해 봐야 한다. 비효율적으로 일 했던 부분이나 스터디가 필요한 부분을 알 수 있다. 3. 어떻게 하면 실제 개발 시간과 가깝게 estimation 할 수 있을지 고민하게 된다. 처음에는 estimation 에 못 맞춘 나의 실력을 탓했다. 하지만 그건 estimation에 실패한거지 실력이 부족한 것으로 생각하면 안된다. estimation의 목표는 현재 나의 실력을 객관적으로 보고 이를 반영하는 것이다. 4. 시간을 소중히 쓰게 된다. 작업에 온전히 집중해서 시간을 쓰게 된다. 시간을 기록하기 시작하면서 일하다가 슬랙 알람이나 핸드폰 알람이 오면 딴길로 새는 경우가 많다는 것을 알게 되었다. 그 뒤로 정해진 시간 안에 집중해서 마치는 것을 최우선으로 하기 위해 작업 시간에는 알람을 꺼 두거나 리마인더를 설정한다.(퍼블리는 비동기 커뮤니케이션이 우선이기에 가능!) [ 시행착오를 겪으면서 얻은 팁 ] 1. 개발에 들어가기 전 태스크를 하위 작업으로 나눈 뒤 각각 estimation 한다. 태스크를 자알 나누는 것은 경험으로 얻어지는 것 같다. 처음에는 frontend, backend 둘 로만 나뉘었다가 실패했었다. 그렇다고 하위 작업을 너무 작게 설정하는 것보다는 내가 집중할수 있는 덩어리 시간(나의 경우에는 2시간)단위로 끊는 것이 좋은 것 같다. 2. 개발 전에 어떻게 구현할 것인지 간단하게라도 문서로 작성하여 매니저에게 피드백을 받는다. 내가 미처 생각 못했던 부분을 개발 전에 알아야 시간을 절약할 수 있다. 개발에 빨리 들어간다고 빨리 끝나지 않는다. 필요한 라이브러리나 현재 코드에서 고려해야 할 부분들을 미리 파악하면 삽질하는데 쓸 시간을 줄여준다. 3. 내가 평균적으로 어떤 작업에 얼만큼 시간을 쓰는지 체크하고 다음에 반영하고... 새로운 서드파티 리서치 할때, REST API 작성하는데, fontend page 하나 새로 만들 때, 코드 polishing 할때, 테스트 할때 등 각 작업 별로 평균 개발 시간을 알아가는 것이 중요하다. (그리고 점점 줄어드는 것을 보면 뿌듯하다) ———- 무조건 오래 일하는 것이 일을 잘하는 것일까? 아침 10시에 출근해서 밤 11시에 퇴근하면 열심히 일 했고 잘 하고 있는 것이라 생각했다. Task estimation 을 하면서 시간의 양 보다는 어떻게 하면 시간을 밀도 높게 쓸수 있을지를 생각해보게 된다.

2021년 3월 20일 오후 4:41

댓글 0

주간 인기 TOP 10

지난주 커리어리에서 인기 있던 게시물이에요!

현직자들의 '진짜 인사이트'가 담긴 업계 주요 소식을 받아보세요.

커리어리 | 일잘러들의 커리어 SNS