Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[문희상] 2장: 함께 #12

Merged
merged 2 commits into from
Sep 30, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions 2장/문희상.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
# 📑 내용 정리
### 관리자가 가져야 할 자세

- 업무를 단순히 **인원수대로 나누는 것**은 **협업에 최악**이다.
- 각자 일하는 것이 아니라 **한 공간에서 소음을 만들며 일하는 것**은 **생산성 향상에 도움이 된다**.
- 제럴드 와인버그는 **복잡한 상황을 이해, 관찰 그리고 행동하는 것**이 개발을 '**잘**'하는 능력이라 말한다.
- 보통 **도구에 대한 개선 시도**가 가장 많지만, "**관리, 시스템, 사람, 도구**" 순으로 개선 효과를 누릴 수 있다.

### 조직에서의 협력

- 아무리 뛰어난 개인이라도 **협력하는 것**이 더 나은 결과물을 만든다.
- **시각화 없이**(전화, 텍스트만) 협력하는 것보다 **중간 매개**(화이트보드, 종이)를 두고 협력하는 것이 도움이 된다.
- 분리된 팀들이 깔끔한 탑 다운으로 **바통터치하듯이 협력**하는 것은 좋은 결과물을 만들기 힘들다.
- 모든 팀들이 일의 많은 부분에 관심을 가지고 '**삼투압적 의사소통**'을 통해 빈번한 바통터치를 하는 협력이 큰 성과를 거둔다.
- 내 생각이나 의견에서 실수가 드러났을 때 **처벌받거나 놀림받지 않을 거라는 믿음**인 '**심리적 안전감**'을 팀원 모두가 가질 수 있도록 해야 한다.
- 자신의 일로 한정짓지 않고 **도움을 주고받는 협력**에서는 **학습 속도를 높이는 데**도 큰 도움이 된다.

### 신뢰와 공감

- **무조건적인 공유**가 신뢰를 쌓지는 않는다.
- **하나 공유, 최고 공유**보다 '**복수 공유**'를 통해 불안감을 낮추고 신뢰를 쌓자.
- 실수에 대한 비난을 하는 것이 아니라 **대화를 통해 공감하고 분석하면서 성장으로 이끌 수 있는 행동**을 유도하는 것이 중요하다. 이러한 과정에서 **신뢰는 쌓인다**.

### 객관성의 주관성

- 모든 결정은 결국 **사람이 하게 되고**, 이 부분에서 **감정이 배제될 수는 없다**.
- 즉, **누군가를 설득하기 위해서는 그 사람에 대한 이해가 선행되어야 하고 그 사람의 성향에 맞는 대화**가 필요하다.

# 🤔 느낀점
- 프로젝트를 진행할 때, 내가 많이 알고 잘하는 것이 가장 중요하다는 생각이 강했는데, 나 자신의 성장을 위해서라도 활발한 의사소통을 하는 협력이 중요하다는 생각을 다시 한 번 해본다.
- 평소 프로젝트를 진행하는 과정에서 업무를 혼자 끝내버려야 겠다는 생각, 실수가 두려워 질문과 의견 제시를 적극적으로 하지 않는 태도는 뜯어고쳐야겠다...
Comment on lines +29 to +31
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

많이들 느끼는 생각일 거 같아요. 문제를 (문제라고 할 수 있는지는 몰겠지만) 자각한 것만으로도 박수를 드리고 싶어요 👏

- 협력 부분에서 중간매개 직접 대면으로 화이트보드를 활용해 이야기할 때 해결되는게 많았다고 무의식적으로 느끼고 있었는데 연구 결과가 있었다는 점에서 앞으로 더 많이 활용해보겠다고 생각했다.
- 누군가를 설득하는 과정에서 논리적인 부분에서 결함이 없다면 누구나 설득시킬 수 있을 거라는 생각을 가지고 있었는데 결국 그 사람이 결정하는 부분이라는 점에서 사람에 대한 파악이 선행되는 것이 중요하다고 생각이 바뀌었다.
- 플젝을 진행할 때, 그냥 파트를 나눠서 각자 할 거 하는 식으로 많이 진행했었고, 내 파트만 열심히 만들면 되겠지라는 생각으로 임했었는데 협력에 대한 이로운 효과를 제대로 경험해 본 적이 없어서 그랬던 것 같다. 앞으로 협력에 초점을 두어서 플젝을 해야겠다는 생각이 강하게 들었다.
- pm을 맡았던 적이 있었는데 팀원들이 모르는 부분에 있어서 추가적인 학습은 각자 알아서 라는 생각을 가지고 있었다. 왜냐면 학습은 스스로 하는 것이 가장 높은 효율을 낼 수 있을 것이라 믿고 있었기 때문이다. 하지만 이번 2장에서 코칭에 대한 파트를 읽으면서 팀원이 어떤 상황인지 파악하고 신뢰를 쌓으면서 학습을 했더라면 더 좋은 성과를 만들어 낼 수 있지 않았을까 하는 후회와 아쉬움이 있다.

# ✅ 궁금한 점
- 팀원의 코드 리뷰를 진행할 때, 어떤 부분에 대해서 피드백을 남기시는 편인가요? (예를 들어, 코드 형식이나 로직)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 코드에서 이해가 안가거나 궁금한 점, 제가 생각하기에 조금 더 효율적인 코드를 짜는 방법을 중점적으로 작성합니다! 그리고 수정할 내용이 없으면 LGTM을 날려요 :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM~

- 팀원이 나의 코드에 대해 이런 식으로 피드백을 주었으면 좋겠다고 생각하는 게 있는지 궁금합니다.
Comment on lines +37 to +39
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

재미있는 주제네요!!

팀원의 코드 리뷰를 진행할 때, 어떤 부분에 대해서 피드백을 남기시는 편인가요? (예를 들어, 코드 형식이나 로직)

수 많은 것들이 있겠지만, 제가 중요하게 생각하는 것은 컨벤션에 관한 이야기인데요

최대한의 퍼포먼스를 내기 위해서 lint로 잡지 못하는 것을 컨벤션으로 하는 것은 리소스 낭비라고 생각해요

그렇기 때문에 조금 더 빡빡한 lint, 혹은 자유로운 컨벤션을 좋아해요

팀원이 나의 코드에 대해 이런 식으로 피드백을 주었으면 좋겠다고 생각하는 게 있는지 궁금합니다.

궁금하신 피드백이 어떤 류의 대답일 지 궁금해요. '이런 식'은 조금 추상적으로 느껴져서요!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

컨벤션에 대한 부분에 대해서는 별 생각없이 그냥 빡빡하게 잡아야 한다고 생각했었는데, 평소에 느꼈던 불편함에 대해 다시 생각해보게 되네요 ㅎㅎ... 기존에는 lint를 사용하지 않았었는데 돌아오는 프로젝트에서는 한번 써봐야겠습니다!

궁금하신 피드백이 어떤 류의 대답일 지 궁금해요. '이런 식'은 조금 추상적으로 느껴져서요!
이 부분에서는 혜성님하고 다른 분들께서 코드 리뷰를 올리면서 팀원에게 어떤 피드백을 바라면서 올린적이 있는지 궁금하다는 내용이었습니다. 예를 들어, 코드 스타일이나 로직을 다른 방식으로 짤 수는 없었는지와 같은 내용입니다!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

어떤 상황에서의 코드 리뷰이냐에 따라 다를거 같긴 하나

같이 프로젝트를 하는, 더 좋은 소프트웨어를 위해 함께 고민하는 상황이라면

코드 레벨에서의 피드백부터 설계에 대한 피드백 등 모든 방법을 동원해 더 좋은 소프트웨어를 만드는 방법에 대해 바라지 않을까 싶어요

그치만 코드 레벨에서의 피드백은 확인하기 쉽지만, 설계와 같은 높은 수준의 리뷰를 위해서는 리소스가 많이 드는 것이 어쩔 수 없는데요

이 비동기적인 핑퐁에 걸리는 시간을 줄이기 위해 오프라인으로 리뷰하는 시간을 따로 잡기도 해요

이는 단편적인 경험이고 더 자세하고 저도 많이 배운 (물론 희상님도 보셨을 수 있는) 아티클을 공유드려요

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

조금 더 잘 짤 수 있는 방법에 대해 남겨주면 좋을 것 같아요! 코드에는 정답이 없다고 생각하기 때문에 제 코드에 대해 최대한 많은 의견을 받고 싶습니당

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오 저도 같은 생각입니다~ 비록 저희 다른 팀이지만 종종 코드 리뷰 하면 좋을 거 같아요 ㅎㅎ

Loading