jongfeel / BookReview

Reviews the IT or any books slowly and steady.
MIT License
4 stars 0 forks source link

7. Getting things done #1021

Closed jongfeel closed 7 hours ago

jongfeel commented 1 day ago

7 업무를 완수하는 개발자Getting Things Done

일을 잘 처리한다는 평판은 여러 가지 면에서 도움이 된다.

더 영향력 있고 도전적인 프로젝트가 주어지므로 학습 속도가 빨라진다. 매니저가 신뢰할 수 있고 ‘알아서 잘하는’ 사람으로 여기기 때문에 더 많은 자율성을 얻는 일이 많다.

7.1 가장 중요한 업무에 집중하기

지금 가장 중요한 업무는 무엇인가? 이번 주에 단 한 가지 일만 할 수 있다면 뭘 할 건가? 이 질문에 답하자.

답을 정했다면 그 일을 최우선순위로 삼아 정해진 시간 내에 반드시 해내야 한다.

항상 최우선 과제를 완료하는 습관 만들기

거절하는 법 배우기

경험이 많을수록 더 쉽게 거절할 수 있다. 거절하는 법은 빨리 배울수록 더 큰 도움이 되는 진정한 기술이다.

요청을 거절하는 가장 쉬운 방법은 ‘네, 저도 도와드리고 싶지만...’으로 시작하는 것이다.

모든 일을 거절할 필요는 없지만, 급한 일이 생겨 최우선 과제를 완료하지 못할 위험이 있다면 거절하자.

7.2 막힌 부분 풀기

막힌 상태 인식하기

생산성 높은 엔지니어는 스스로 벽에 부딪혔다는 사실을 깨닫고 인정한다.

경험상, 30분 이상(길어야 1시간)이 지나도 의미 있는 진전이 없다면 스스로 막힌 상태임을 인정해야 한다.

막힌 상태를 뚫는 방법

지원을 받아 문제 해결하기

어떤 상황이든 도움을 줄 개발자에게 자신의 문제를 공유하고 도움을 청하자. 막힌 문제를 해결하는 가장 쉬운 방법은 팀에 상황을 알리는 것이다.

제가 이 문제에 막혀 있어요. 제가 해결할 수 있게 도와주실 수 있나요?’라고 요청하자.

원만하게 상대의 상급자에게 보고하는 법

여기서 상급자란 요청에 응답하지 않는 사람의 매니저나 그 위의 직급자를 의미한다. 이런 보고는 업무 처리 속도를 높이지만, 부주의하게 사용하면 관계를 해칠 수도 있다.

상대의 상급자에게 보고해 문제를 해결할 때는 개인적인 관계를 해치지 말자. 장기적으로는 일을 조금 더 빨리 끝내는 것보다는 좋은 인간관계가 더 중요하다.

상급자를 통한 소통이 필요한 상황에 이렇게 접근한다.

  1. 설명하기: 먼저 도움이 필요한 이유를 설명하고 그 중요성을 이해할 정보를 제시한다.
  2. 물어보기: 아무런 변동이 없다면 이유를 확인하자.
  3. 경고하기: 그래도 아무 일도 일어나지 않으면 상급자에게 보고할 가능성을 언급한다.
  4. 상급자에게 보고하기: 그래도 아무 일도 일어나지 않으면 내 매니저나 상대방의 매니저, 혹은 둘 모두에게 작업 진행을 요청한다.

이런 상황에서 서로 윈윈할 결과를 만드는 것을 목표로 하자.

상대방이 요청한 작업을 수행하면 반드시 감사의 뜻을 전하고 관련자들에게 알리는 것이 좋다.

막힌 일의 해결과 다른 팀 동료와의 관계 유지 사이에 균형을 잘 유지해야 한다.

막혔을 때 실전 대응법

계획 단계

구현 단계

테스팅

코드 리뷰

배포

운영 시스템 및 유지 관리

7.3 작은 단위로 작업 쪼개기

스토리, 작업, 하위 작업에 대해 생각하기

작업을 세분화하다 보면 헤매기 쉽다. 프로젝트에서 시작해 가장 큰 부분을 하나 잡아, 작은 컴포넌트들의 작동 방식을 코드 수준에서 정의하게 되기 때문이다. 좀 더 전략적으로 접근해 이러한 함정을 피할 수 있다.

  1. 상위 레벨부터 시작하자. 주요 작업은 무엇인가? 규모가 크다면 여러 부분으로 나눈다.
  2. 스토리가 완성되면 이를 다시 간단한 작업으로 세분화하자.
  3. 필요한 경우 스토리 수준의 복잡한 작업을 다시 하위 작업으로 나눈다.

해야 할 일이 이해하기 쉬울수록 소요 시간을 예측하기 더 쉽다. 작업을 작은 부분으로 세분화한 다음, 더 세분화하는 데 시간을 쓰자!

출시를 더 빠르게 하는 작업 우선순위 지정

일단 동작하는 기능을 더 빨리 만들도록 작업 순서를 정하는 것이 좋다. 엔드투엔드 테스트를 빨리 진행할수록 올바른 방향으로 가고 있는지 피드백을 더 빨리 얻을 수 있다.

작업 추가, 제거, 변경을 두려워하지 말자

개별 작업은 업무를 완수하는 도구일 뿐이다. 필요에 따라 작업을 변경 및 추가하고, 중복되는 작업은 과감하게 제거하자. 새로운 업무가 발견되거나 새로운 제약 조건에 부딪히거나, 어떤 이유든 진척이 없으면 원래 계획을 수정해 작업을 전면 재검토하자!

7.4 작업 소요 시간 추정

믿음직한 엔지니어는 모두 정확한 시간 추정을 하며, ‘추정을 빗나가게 할 요소’와 지연 사유를 명확하게 설명하는 견실한 추정가였다.

작업 시간 추정 역량은 키울 수 있다. 업무 유형에 따라 그 어려움은 다르다.

이전에 수행한 작업

이전 작업에 소요된 시간을 기준으로 새 작업의 소요 시간을 현실적으로 추정할 수 있다.

이전에 수행해보지 않았던 작업

일반적으로 마주하는 작업을 7가지 범주로 나누고 작업 시간을 정확하게 추정하는 방법을 살펴보자.

1 동료의 작업과 유사한 작업

비슷한 작업을 경험한 팀원이 있을 수 있다. 이러면 처음부터 만드는 것이 아니다.

비슷한 작업을 했던 개발자는 시간을 예상할 수 있다. 유일한 차이는 콘텍스트에 대한 이해가 필요해 작업을 완료하는 데 시간이 조금 더 걸린다는 점이다.

2 리팩터링

이전에 리팩터링을 수행했다면 현재 리팩터링 유형이 새로워도 그 경험을 기준으로 시간을 예측할 수 있다.

타임박스timebox 작업을 적용할 수도 있다. 타임박싱이란 작업에 기간을 할당하고 그 기간 동안만 작업하고 그 이상은 작업하지 않는 것을 의미한다.

3 잘 아는 기술을 사용하는 작업

가장 큰 문제는 비즈니스 요구사항이 불분명할 때인데 업무만 명확하다면 충분히 잘 맞는 예측치를 낼 수 있다.

4 잘 아는 기술로 잘 모르는 시스템을 통합

프로토타입을 제작하고 다른 시스템이나 API를 테스트하는 간단한 개념 증명proof of concept(PoC)을 한 후에 예상 시간 추정을 하는 것이 좋다.

프로토타이핑이 불가능하면 시스템에 문제가 없다고 가정하는 ‘이상적인 추정치’를 제공할 수 있다. ‘최악의 경우’를 감안한 추정치도 제공하자.

5 잘 모르는 성숙도 높은 기술로 간단한 결과물을 구축

현실적인 예상 시간 추정하는 가장 좋은 방법은 해당 기술을 사용해본 엔지니어에게 문의하는 것이다.

그 기술을 잘 아는 개발자와 같이 작업하면 구현에 걸리는 시간이 단축되고 학습 과정도 빨라진다.

개발자와 같이 작업할 수 없다면 언제든 타임박스로 추정치를 작성해 기술을 익힐 수 있다. 이 타임박스를 매우 크게 잡아 튜토리얼 몇 가지를 살펴보고, 코딩을 해보고, 평소보다 얼마나 더 많은 디버깅이 필요한지 알아보자.

6 잘 모르는 새로운 기술로 간단한 결과물을 구축

새로운 기술로 PoC를 수행한 다음, 그 기술을 사용할 수 있다는 확신이 든 뒤에 작업 예상 시간을 추정하길 권한다.

7 익숙하지 않은 신기술로 복잡한 결과물을 구축하고 잘 모르는 시스템과 통합

우선 알지 못하는 것을 세 종류로 나눠보자.

정확한 추정을 위해서는 미지의 요소를 줄여야 한다. 방법은 두 가지다.

  1. 프로토타이핑: 프로토타입에서 학습한 내용을 바탕으로 예측치를 만들어 낼 수 있다.
  2. 작업의 세분화: 작업을 모르는 요소가 하나씩만 포함되도록 분리한다.

7.5 멘토 찾기

멘토란 나에게 가르침을 줄 여러 명의 그룹으로 생각하자. 온라인 전문가를 포함한 일시적인 멘토링을 통해서도 많은 것을 배울 수 있다.

스택오버플로와 같은 Q&A 웹사이트와 챗GPTChatGPT 및 제미나이Gemini 같은 AI 코딩 도구는 특정 작업에서 막힌 부분을 해소하는 데 도움이 될 수 있다. 다만, AI 도구의 결과를 완전히 신뢰할 수는 없으므로 항상 확인해야 한다는 점을 기억하자!

멘토로 구성된 기술 부족

니엘레 드멜로Nielet D’mello는 데이터독Datadog의 소프트웨어 보안 엔지니어다. 그녀는 ‘멘토의 기술 부족tech tribe’이라는 글에서 사람 한 명에게서만 배우기 보다는 다양한 멘토로 구성된 '부족'에게 배우는 것이 훨씬 좋다고 주장한다.

  1. 전담 멘토

전담 멘토와의 주기적인 상호작용을 통해 명확한 목표를 설정하고 지속적으로 개선할 수 있는 훌륭한 동기부여가 됩니다. 전담 멘토를 찾으려면 이전에 교류한 적이 있는 사람이나 자신이 존경하고 자신의 목표와 일치하는 일을 하는 사람에게 연락하는 것이 가장 좋습니다.

  1. 일시적 멘토

때로는 긴밀하게 협력하지는 않지만 업무가 서로 겹치는 사람들과 1:1 미팅을 잡는 것도 좋습니다.

  1. 인터넷 멘토

블로그, 책, 팟캐스트 등을 통해 자신의 커리어 여정과 배움을 공유하는 개인/리더를 말합니다.

7.6 선의 통장

나와 다른 사람 사이의 선의에 대한 잠재적 함의를 생각해보자.

모든 사람에게는 선의 통장이 있다

다른 사람을 도우면 선의 통장의 잔고가 늘어난다. 도움을 청하면 그 잔고는 줄어든다.

동료에게 도움을 요청할 때는 사전 준비가 필요하다. 문제를 명확하게 설명하고, 지금까지 시도한 방법과 그 방법이 도움이 되지 않았다면 다음 단계는 무엇인지 요약하자. 동료가 다른 우선순위 높은 일로 바쁠 수 있으므로 그들의 시간을 존중하자.

선의 통장 잔고를 정기적으로 채워 넣자

팀 적응 기간 동안에는 선의 통장에 잔고가 많다. 하지만 그 기간이 지난 후에는 이를 당연하게 여기지 말고 다른 사람을 도와 균형을 유지하자.

가능하면 혼자 작업하지 않기

혼자 일하는 상황을 바꾸자. 팀 내 엔지니어에게 프로젝트 버디가 되어 달라고 요청해 매일 함께 체크인하고, 계획을 검토하고, 코드 리뷰를 하는 등의 작업을 함께 할 수 있다.

팀 내의 선의 통장 잔고도 높이자. 다른 사람이 여러분에게 호의적일수록 프로젝트 버디가 되어 줄 가능성도 높다.

7.7 솔선수범하라

생산적인 엔지니어 중에는 누가 시키지 않아도 크고 작은 일을 꾸준히 해내는 사람이 있었다. 솔선수범하는 것이다.

신뢰가 가고 생산적이라고 인식되는 엔지니어는 의무를 뛰어넘어 더 많은 일을 한다. 자율적인 근무 문화가 정착되어 있을수록 이러한 특성은 더욱 중요하다.

빠르게 성장하는 기술 기업에서는 자신의 업무가 아닌 일에 솔선수범하는 것이 경력에 큰 도움이 된다.

솔선수범하는 법

뭔가 새로운 일을 맡겠다고 나서기 전에 ‘내가 처리해야 하는’ 업무를 먼저 완료해야 한다는 점이다. 가장 중요하고 할당된 업무를 먼저 끝낸다는 전제하에 새로운 일을 맡아야 다른 사람이 여러분을 생산적인 사람으로 본다.

jongfeel commented 1 day ago

막혔을 때 실전 대응법, 코드 리뷰에서 병합 충돌을 언급하며 피할 수 없다고 하고 그 다음에 하는 얘기가 중요하다.

병합 충돌 문제를 줄이고 더 빠르게 반복하려면 풀 리퀘스트를 작은 단위로 진행해야 한다.

이건 경험적으로 터득할 수 있기도 하고 아주 좋은 실천 원칙인데 잘 못하거나 모르는 사람이 너무 많다. 그리고 그렇다고 하기엔 나도 나끔 20번 정도에 한번 꼴로 큰 pull request를 만들곤 하는데 이런 일이 생기지 않도록 작업을 분할에서 작은 단위의 pull request를 만들 수 있다면 개발을 잘 하는 능력이 있다고 볼 수 있다.

jongfeel commented 21 hours ago

멘토 기술 부족 설명에서

멘토는 다방면에 걸쳐 많은 경험을 쌓았지만 한 사람이 모든 것을 전문적으로 다룰 수는 없습니다. 게다가 모든 사람의 경험은 서로 다르고 다양합니다. 이를 활용하는 것은 커리어에서 배우고 성장할 수 있는 좋은 방법입니다.

여러 명의 멘토를 통해 통찰력을 얻는 방식은 매우 좋다고 생각한다. 특히 한 가지 사실에 대해 다양한 시각을 가지고 자신만의 경험과 능력을 만드는 건 좋다고 본다.

예) 객체지향이 얼마나 꼭 필요한가?,코드 주석은 없어도 되는가 달아야 하는 가 등

jongfeel commented 20 hours ago

멘토 찾기에서 AI의 도움을 받으면 좋다는 부분에서

AI 도구의 결과를 완전히 신뢰할 수는 없으므로 항상 확인해야 한다는 점을 기억하자!

이 부분은 아주 중요하다고 본다. CharGPT의 결과를 믿고 코드가 동작하지 않는다고 힘들어하는 개발자를 실제 봤기 때문에 도움을 받고 확인하는 용도로 써야지 믿고 활용하는 용도 혹은 이게 생산성 향상의 무기로 생각해서는 안될 것이다.