generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
39 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
# 📑 내용 정리 | ||
### 관리자가 가져야 할 자세 | ||
|
||
- 업무를 단순히 **인원수대로 나누는 것**은 **협업에 최악**이다. | ||
- 각자 일하는 것이 아니라 **한 공간에서 소음을 만들며 일하는 것**은 **생산성 향상에 도움이 된다**. | ||
- 제럴드 와인버그는 **복잡한 상황을 이해, 관찰 그리고 행동하는 것**이 개발을 '**잘**'하는 능력이라 말한다. | ||
- 보통 **도구에 대한 개선 시도**가 가장 많지만, "**관리, 시스템, 사람, 도구**" 순으로 개선 효과를 누릴 수 있다. | ||
|
||
### 조직에서의 협력 | ||
|
||
- 아무리 뛰어난 개인이라도 **협력하는 것**이 더 나은 결과물을 만든다. | ||
- **시각화 없이**(전화, 텍스트만) 협력하는 것보다 **중간 매개**(화이트보드, 종이)를 두고 협력하는 것이 도움이 된다. | ||
- 분리된 팀들이 깔끔한 탑 다운으로 **바통터치하듯이 협력**하는 것은 좋은 결과물을 만들기 힘들다. | ||
- 모든 팀들이 일의 많은 부분에 관심을 가지고 '**삼투압적 의사소통**'을 통해 빈번한 바통터치를 하는 협력이 큰 성과를 거둔다. | ||
- 내 생각이나 의견에서 실수가 드러났을 때 **처벌받거나 놀림받지 않을 거라는 믿음**인 '**심리적 안전감**'을 팀원 모두가 가질 수 있도록 해야 한다. | ||
- 자신의 일로 한정짓지 않고 **도움을 주고받는 협력**에서는 **학습 속도를 높이는 데**도 큰 도움이 된다. | ||
|
||
### 신뢰와 공감 | ||
|
||
- **무조건적인 공유**가 신뢰를 쌓지는 않는다. | ||
- **하나 공유, 최고 공유**보다 '**복수 공유**'를 통해 불안감을 낮추고 신뢰를 쌓자. | ||
- 실수에 대한 비난을 하는 것이 아니라 **대화를 통해 공감하고 분석하면서 성장으로 이끌 수 있는 행동**을 유도하는 것이 중요하다. 이러한 과정에서 **신뢰는 쌓인다**. | ||
|
||
### 객관성의 주관성 | ||
|
||
- 모든 결정은 결국 **사람이 하게 되고**, 이 부분에서 **감정이 배제될 수는 없다**. | ||
- 즉, **누군가를 설득하기 위해서는 그 사람에 대한 이해가 선행되어야 하고 그 사람의 성향에 맞는 대화**가 필요하다. | ||
|
||
# 🤔 느낀점 | ||
- 프로젝트를 진행할 때, 내가 많이 알고 잘하는 것이 가장 중요하다는 생각이 강했는데, 나 자신의 성장을 위해서라도 활발한 의사소통을 하는 협력이 중요하다는 생각을 다시 한 번 해본다. | ||
- 평소 프로젝트를 진행하는 과정에서 업무를 혼자 끝내버려야 겠다는 생각, 실수가 두려워 질문과 의견 제시를 적극적으로 하지 않는 태도는 뜯어고쳐야겠다... | ||
- 협력 부분에서 중간매개 직접 대면으로 화이트보드를 활용해 이야기할 때 해결되는게 많았다고 무의식적으로 느끼고 있었는데 연구 결과가 있었다는 점에서 앞으로 더 많이 활용해보겠다고 생각했다. | ||
- 누군가를 설득하는 과정에서 논리적인 부분에서 결함이 없다면 누구나 설득시킬 수 있을 거라는 생각을 가지고 있었는데 결국 그 사람이 결정하는 부분이라는 점에서 사람에 대한 파악이 선행되는 것이 중요하다고 생각이 바뀌었다. | ||
- 플젝을 진행할 때, 그냥 파트를 나눠서 각자 할 거 하는 식으로 많이 진행했었고, 내 파트만 열심히 만들면 되겠지라는 생각으로 임했었는데 협력에 대한 이로운 효과를 제대로 경험해 본 적이 없어서 그랬던 것 같다. 앞으로 협력에 초점을 두어서 플젝을 해야겠다는 생각이 강하게 들었다. | ||
- pm을 맡았던 적이 있었는데 팀원들이 모르는 부분에 있어서 추가적인 학습은 각자 알아서 라는 생각을 가지고 있었다. 왜냐면 학습은 스스로 하는 것이 가장 높은 효율을 낼 수 있을 것이라 믿고 있었기 때문이다. 하지만 이번 2장에서 코칭에 대한 파트를 읽으면서 팀원이 어떤 상황인지 파악하고 신뢰를 쌓으면서 학습을 했더라면 더 좋은 성과를 만들어 낼 수 있지 않았을까 하는 후회와 아쉬움이 있다. | ||
|
||
# ✅ 궁금한 점 | ||
- 팀원의 코드 리뷰를 진행할 때, 어떤 부분에 대해서 피드백을 남기시는 편인가요? (예를 들어, 코드 형식이나 로직) | ||
- 팀원이 나의 코드에 대해 이런 식으로 피드백을 주었으면 좋겠다고 생각하는 게 있는지 궁금합니다. |