/bemaru/dev/log

책에 대한 간략한 소개

• 책 표지에서 알 수 있듯이, 이 책에선 41가지 리더십 기술에 대해 설명하고 있다.
• 본인은 책을 빨리 읽는 스타일이 아님에도, 책 내용에 군더더기가 없어서 그런지 술술 읽혔다.
• 팀장을 1년이라도 해본 경험이 있는 사람이라면 읽으면서 고개를 끄덕일 내용들이 많다.
• 미래에 팀장이 될 수도 있는, 혹은 팀원으로서 팀장 관점에서 생각하며 일잘러가 되고 싶은 이에게도 좋은 책이다.
• 경력이 많은 팀장이라도, 한번쯤 잘하고 있는지 되돌아보는 체크리스트로 활용해도 좋아 보인다.

이 글에선

• 아래부턴 책을 읽고 기억에 남는 몇 부분에 대해 곱씹으며
  관련된 개인적인 경험과 생각을 덧붙이며 글을 채워나가려 한다.

리더십을 배우는 것도 '맥락'이 필요합니다.

• 책 머리말에 있는 문장이다.
• 이 책은 우리에게 필요한 리더십에 대한 '맥락'에 대해 어떤 테크닉이 필요한지 짚어주고 있다.

실무에 지나치게 빠지는 태도를 경계해야 합니다.

• 사실 개인업무 하기도 바쁘다는 생각을 정말 자주 한다.
• 하지만, 리더로서의 역할에 대해 다시 생각하고 무엇을 우선시 해야할지를 책에선 설명하고 있다.

목표가 실행에 영향을 미친다!

• 조직 목표를 세우고 열심히는 하는 것에 비해 성과가 안 나온다면 SMART 기법을 적용해보는 것도 좋다.
• 구체적이고 측정 가능하며 달성 가능한, 그리고 조직의 장기적은 비전과 부합하며 기한이 있는 목표
• 기존에 이미 세워진 목표도 좋다. SMART 방식으로 재구성해 보는 건 어떨까?
• 특히 Measurable 하게 정성적인 부분을 정량적인 지표로 만들면, 작업자의 진척도 달성 및 객관적인 평가에 도움이 될 수 있다.
• 책에서 말했듯, 목표를 어떻게 세우느냐에 따라 성과가 바뀌는 경우를 종종 목격한 적이 있다.
• 비단 팀원뿐만 아니라, 개인 목표에 있어서도 마찬가지다. 
• 어떤 도구와 방법론을 선택하느냐는 정말 중요한 부분이다.

직무와 직책을 기준으로 먼저 정의해 놓자

• 최근에 우리 팀 프로젝트에 대한 R&R 문서에 사람을 기준으로 작성한 부분이 있는데
  이 글을 보고 반성했다.
• 해당 직무에 대해 퇴사나 조직 구조 변경 등에 의해 언제나 사람은 바뀔 수 있다.
• 사람이 아닌 직무를 기준으로 R&R을 작성하는 것이 옳다!
• 사람이 아닌 직무를 기준으로 해야, 맡은 role 에 대해 객관적으로 바라보게 되는 부분도 있는 것 같다.

정답은 없다. 
...
감정적인 문제의 해결은 언제나 '공감'에서부터 시작해야 한다는 것을 기억하세요.

• 팀원일 때, 맡은 업무가 답이 보이지 않아 답답하고 어려웠던 적이 있다.
• 방향을 알고 있다면, 시간이 오래 걸리더라도 해낼 수 있다.
• 하지만 앞이 보이지 않는, 어디로 가야 할지 갈피를 못 잡을 때면 정말 지칠 때가 있다.
• 그런 상황을 팀장과 이야기했을 때, 팀장이 공감을 해주는 것만으로도 상황이 좋아지는 경우도 있다.
• 팀장이 해결책을 주지 못하더라도 말이다.
• 어찌 보면 리더십에 있어서 가장 어려우면서도 가장 선행되어야 하는 부분인 것 같다.

회사가 중요하게 생각하는 가치와 연결되어 있어야 한다.

• 평가 기준을 전달하고 이해시키고 소통하는 것은 매우 중요하고 기본적인 부분이다.
• 조직의 목표와 달성 방식에 직접적으로 영향을 주는 부분이기도 하다.
• 참고로, 이렇게 이 책의 장점 중에 하나는 팀장 업무 셀프 점검하기가 있다는 것이다.
• 셀프 점검 하기를 읽다 보면 반성을 많이 하게 된다.

시간을 낭비하지 않는 회의 진행해 보기

• 책에선 이렇게 오늘의 목표를 제안하기도 한다.
• 별거 아닌 것 같지만, 의지를 가지고 업무에 활용해 보면 좋을 것 같다는 생각이 든다.
• 실제로 회의 종류나 방식에 따라 비효율적으로 회의가 진행되는 경우도 종종 있다.
• 책에선 확실한 진행 계획 준비, 같은 말이 반복되지 않게 하기, 주제를 벗어나지 않게 하기 등을 이야기하고 있다.
• 실제로 회의하면 느끼는 부분들인데, 생각보다 잘 안 고쳐지는 것 같다.
• 이번 참에 책 내용을 정리해서, 회의 때 체크리스트로 활용해 봐야겠다는 생각이 든다.

마무리

• 이 글에서 다 쓰진 못했지만, 업무에 도움이 되는 내용들이 정말 많다.
• 두꺼운 책은 아니라서, 처음부터 끝까지 읽어가며 하나하나 셀프 리뷰를 해보는 것도 좋을 것 같다.
• 또는 부분부분씩 읽더라도, 하나라도 업무에 직접 활용해 본다면 프로 일잘러가 되는데 큰 도움이 될 거라 본다.
• 기본적인 팀원과의 소통 외에도 성과 평가와 면접, 채용 등 팀장이 해야 하는 업무 전반에 대해 도움이 되는 '맥락'들을 짚어주고 있다.
• 책을 전체적으로 다 읽어보니, 꼭 팀장만을 위한 책은 아니라고 본다. 
• 팀원이 팀장을 이해하는 데 도움이 될 수도 있고, 개인적인 업무 역량을 높이는데도 도움되는 내용들이 많이 수록되어있다.
• 41가지 리더십 기술, 오늘부터 하루에 1개씩 업무에 적용하며 셀프 리뷰를 실행해봐야겠다.                                          

  

* 이 글은 《일 잘하는 팀장》 서평단으로 선정되어 작성된 글입니다.

우선순위와 심각도의 차이점

높은 우선순위 x 낮은 심각도 : 결함을 즉시 수정해야하지만, 애플리케이션에 영향을 주지 않음.

낮은 우선순위 x 높은 심각도 : 결함을 수정해야하지만, 즉시 수정이 필요하진 않음.

Severity x Priority Matrix

우선순위 유형(Priority Type) 예시

• 높음: 버그가 시스템에 부정적인 영향을 미치고 해결될 때까지 사용할 수 없게 만드는 즉시 버그를 해결해야 합니다.
• 중간: 버그는 일반적인 개발 및 테스트 과정에서 수정될 수 있습니다.
• 낮음: 버그는 나중에 수정될 수 있습니다. 기타 더 심각한 버그가 우선적으로 적용됩니다.

심각도 유형(Severity Type) 예시

• 심각(Critical): 시스템 전체 종료를 유발할 수 있는 버그
• 주요(Major): 시스템의 많은 부분을 붕괴시킬 수 있는 버그
• 경미(Minor): 예상치 못한 또는 원치 않는 동작이 발생하지만 시스템 기능을 방해할 만큼 충분하지는 않습니다.
• 낮음(Low): 버그로 인해 눈에 띄는 시스템 고장이 발생하지 않습니다.

구글 이슈 트래커의 우선순위 예시

출처 : https://developers.google.com/issue-tracker/concepts/issues?hl=ko 

정리

• 우선순위는 비즈니스 가치 관점에서 개발자가 버그를 수정해야하는 순서
• 심각도는 기술적 관점에서 버그가 소프트웨어 기능에 미치는 영향도
• 우선순위 유형과 심각도 유형은 어느 정도 기준은 있지만 회사, 프로젝트, 팀 마다 기준을 정의해야한다.

참조 

• (2010-03-11)  https://angel927.tistory.com/82
• (2013-04-09) https://reqtest.com/en/knowledgebase/priority-and-severity-what-is-the-difference-and-when-should-you-use-which/
• (2023-04-21) https://www.browserstack.com/guide/bug-severity-vs-priority
• (2024-03-19) https://www.guru99.com/ko/defect-severity-in-software-testing.html
• https://developers.google.com/issue-tracker/concepts/issues?hl=ko

개요

• 최근 python 코드를 리팩토링하는 일이 많은데, 그 이유는 분석을 잘하기 위해서다.
• 기존 시스템 코드 대부분이 남이 만든 코드가 90% 이상인데, 읽기 좋은 코드는 아니다. 
• 물론, 리팩토링을 하지 않아도 분석 할 수는 있다.
• 하지만, 나는 리팩토링을 했다. 왜?
• 기존 코드를 그대로 분석 vs 리팩토링 + 가독성 개선 후 분석 에 들어가는 리소스(시간)만 봤을때
  후자가 더 효율적이기 때문이다. (이 이야기는 여기서 길게 할 필요는 없으므로 생략한다..)
• 여튼, 리팩토링을 계속 하면서 반복되는 패턴이 생겨, 이 글에서 규칙을 정리하려 한다.
• 보편적인 python 코딩 컨벤션의 기본적인 내용도 일부 포함된다.

규칙

1. import 문 정리
   • import 문을 알파벳 순서로 정렬한다.
   • IDE를 통해 없는 package 를 자동으로 import 하면, 알아서 적절한 곳에 배치할 수 있다.
   • isort 를 사용하는 방법도 있다.
   • import 문 순서가 안맞더라도 사실 코드 분석에 크게 영향이 있진 않지만, 안맞으면 거슬린다..
2. 네이밍 스타일
   • https://peps.python.org/pep-0008/#naming-conventions
   • PEP8에 네이밍 스타일에 대한 설명을 읽어보면 도움이된다.
   • 변수, 함수이름은 snake_case
   • 함수는 PascalCase
   • Pylint 나 IDE의 intellisense 에서도 PEP 에 맞지 않는 스타일에 대해 경고 알림을 얻을 수 있다.
   • 레거시 코드에서 이런 기본적인 네이밍 스타일이 안지켜지면 너무 속상하다.
3. 클래스
   • 클래스 없이 많은 함수가 나열된 py 파일을 보면 한숨나온다.
   • 기본적으로 모듈(.py 파일)과 클래스는 1:1 대응을 선호한다. ( 그렇게 안되는 경우도 당연히 있다.)
   • 클래스 멤버 함수 네이밍
     • python에서 공식적인 private 함수는 없지만, 관례상 _로 시작하곤 한다.
       • ex> def _my_private_method(self):
     • 멤버 변수, 함수의 정의 순서도 가독성에 많은 영향을 끼친다.
     • writer는 reader 에게 중요한 정보가 먼저 보이도록 고려하며 작성해야한다.
     • 멤버 정의 순서
       • 클래스 상수: _MY_CONSTANT
       • __init__ 함수
       • 오버라이딩 함수: @override
       • public 함수: my_public()
       • private 함수: _my_private()
       • 호출 계층 깊이가 얕은 함수
       • 호출 계층 깊이가 깊은 함수
4. 데코레이터 표기하기
   • @override
   • @deprecated
   • @property
   • 기타 등등 알맞은 데코레이터 표기로 가독성을 개선하면 코드가 읽기 수월하다.
5.  기타
   • IDE 가 알려주는 경고는 웬만하면 모두 해결하기.
     • for key in my_dict -> for key, value in my_dict.items()
   • early return
   • 함수 호출 계층 참고하기. (vscode F12)
     • 어디서 호출되고 사용되는지 참고하여, 리팩토링 후 영향도를 고려한다.

https://support.google.com/adsense/answer/7402253?hl=ko 

1. https://adsense.google.com/start/로 이동합니다.
2. 시작하기를 클릭합니다.
3. Google 계정에 로그인합니다.
4. 광고를 게재할 사이트의 URL을 입력합니다. URL을 입력하는 방법을 자세히 알아보세요.나중에 사이트를 추가하려면 이 입력란을 비워두고 아직 사이트가 없습니다를 선택합니다.

과연 승인이 될까요?

--

검토 결과 내용 추가하도록 하겠습니다.