DHistory

[회고] 사하라 사막을 횡단할 때 직선으로 가지 않습니다. 지그재그로 가게됩니다. 왜 그럴까요? 본문

회고

[회고] 사하라 사막을 횡단할 때 직선으로 가지 않습니다. 지그재그로 가게됩니다. 왜 그럴까요?

ddu0422 2023. 7. 21. 12:17

평가 시작

회사는 상반기/하반기가 아닌 2Q~3Q / 4Q~1Q 결과로 평가를 진행한다.

이번에는 22년 4Q와 23년 1Q의 결과로 평가를 진행했다.

 

새로 오신 Engineer Manager 분이 23년 1Q가 마무리될 시점에 오셨기 때문에 어떤 방식으로 평가를 진행할지 궁금했다.

기존 평가 방식은 피어 리뷰를 기반으로 진행했다.

이번 평가 방식은 피어 리뷰와 Jira Ticket 개수로 진행했다.

 

 

평가 내용

에픽 1개, 스토리 12개, task 42개, subtask 74개, Service request 5개 등 총 135개의 이슈를 처리하였으며 
하루(월 working day 20일 기준)에 1개 정도의 이슈를 처리하는 performance를 보여줬습니다.
그러나 3개월 간 인프라팀 파견을 갔었기 때문에 이를 고려하여 다시 산정한다면 하루에 2개의 이슈를 처리하였습니다.

(이후 생략)

 

일은 분명 다른 팀원들보다 임팩트 있고 더 많은 업무를 진행했지만 하루에 2개의 이슈를 처리한 결과로 나타났다.

충격을 받을 수 밖에 없었다.

 

피드백

매니저님이 질문을 하나 던졌다. (C: 매니저, M: 나)

 

C: 사하라 사막을 횡단할 때 직선으로 가지 않습니다. 지그재그로 가게 됩니다. 왜 그럴까요?

M: ...

 

C: 지그재그로 가는 이유 중 하나입니다. 물을 공급할 수 있는 경로이기 때문이에요.

    직선으로 가게 되면 빠르게 갈 수 있지만 살아서 갈 확률이 적습니다.

    지그재그로 이동하며 물을 공급하고 진행해야 안전하게 갈 확률이 높습니다.

    이처럼 하나의 태스크를 완료할 때 여러 서브 태스크로 나누어야 보다 안전하게 태스크를 완료할 수 있습니다.

    안전하게 태스크를 완료해야 버그를 줄이고 장애를 줄일 수 있습니다.

   

    또한 스프린트 진행 시 진행도를 확인할 수 있어요.

    만약 서브 태스크가 이동하지 않았다면 문제가 있는 거고 이를 찾아서 해결을 해야 하죠.

 

    미르(내 닉네임)도 태스크를 잘게 분할하여 업무를 진행해 보세요.

    대시보드를 만들어서 결과를 확인한다면 한눈에 볼 수 있습니다.

M: 감사합니다 :) 피드백 내용을 기반으로 업무를 진행해 볼게요.

    (Scrum Master Role을 수행해 봤기에 충분히 공감할 수 있는 내용이었고 현재 팀의 문제라고 생각하는 부분이었다.)

 

피드백 반영

피드백을 받은 이후 어떤 방식으로 진행해야 하는지 고민했다.

안전하게 완료하고 장애물이 없는지 확인을 해야 하는 게 포인트다.

고민 끝에 A 태스크를 완료하기 위해 필요한 모든 업무를 Sub-task로 나누자는 결론을 내렸다.

배포, 모니터링 등 아주 기본적인 내용들까지 Sub-task로 만들었다.

 

심지로 조사와 구현까지 나누어 문제를 나누도 일을 진행했다.

(Research를 주로 하는 팀이기 때문)

 

단순히 태스크 개수를 나눈 게 끝이 아닌 나중에 다시 봤을 때 어떤 태스크인지 한눈에 파악하기 쉽도록 태스크의 배경, 목적, 목적이 아닌 것, 임팩트 등 주요 내용을 채웠다.

 

피드백을 받은 후 약 2개월(5월~6월에 진행한 업무)이 지난 시점이다.

 

 

결과 피드백 전에는 1 Task 당 1.7 Sub-task를 수행했지만 피드백 이후에는 5.5 Sub-task를 수행했다.

기존과 비슷한 업무를 진행했음에도 대략 3배 정도 일 처리량이 늘어난 것처럼 보인다.

아니 그 이상이다. 피드백 전은 6개월 동안 일한 결과물이고 현시점은 약 2개월 동안 일한 결과물이다.

 

 

심지어 매니저님이 관리하는 팀(2팀, 총 18명) 내에서 태스크 개수 1등을 차지했다.

(양보단 질이 중요하지만 대부분의 동료들은 동일한 질의 업무를 할당받는다.)

 

느낀 점

1. 기억을 조금 덜 해도 된다.

 

기존에는 모든 업무를 기억하며 진행했는데 Sub-task를 믿고 이전에 진행했던 업무를 다시 돌이켜보지 않고 다음 업무를 진행할 수 있었다.

(물론 티켓의 내용을 잘 작성해야 한다.)

 

나중에 다시 봤을 때 티켓 내용이 아닌 Sub-task 명만 보고도 일을 진행할 수 있게 되었다.

 

2. 멀티 태스킹에 유용하다.

 

한 스프린트(2주 단위)에서 성향이 다른 업무 3가지를 동시에 진행하게 되었다.

배포 파이프라인 구축, 미 사용 DB Column 제거, Microservice로 서비스 분리였다.

개인 업무뿐만 아니라 Design Document Review, Code Review도 진행했다.

 

context switching 비용을 최소화하여 모든 업무를 컨트롤할 수 있었다.

 

매니저분께 이야기를 들었을 때 새로운 insight를 얻을 수 있다고 하셨다.

오랜 시간 동안 공부를 하셨고 매니징을 해오신 경력이 있는 분에게 의미 있는 일을 전달한 것 같아 뿌듯하다.

 

앞으로는?

업무 방식은 회사마다 다르니 회사에 맞게 따르려고 한다.

다만 자유롭다면 위와 같은 방식으로 진행하려고 한다.

 

또한 이 방식으로 인생도 컨트롤해보려고 한다.

나는 언제나 큰 목표를 잡고 달성하지 못했다고 좌절했다.

큰 목표를 잡되 큰 목표를 이루기 위해 여러 작은 목표로 나누고 달성해 나갈 예정이다.

작은 목표 중 하나는 기초 재건축이다.

 

'회고' 카테고리의 다른 글

[회고] 개략적인 Back-End Road Map  (0) 2023.11.07
[회고] Programmers Level 1 완료  (0) 2023.08.11