From 70b914adf72fa30eb3c6f914a9e95fbc4acadd96 Mon Sep 17 00:00:00 2001
From: yeyounging <133792082+yeyounging@users.noreply.github.com>
Date: Wed, 2 Oct 2024 15:03:25 +0900
Subject: [PATCH] =?UTF-8?q?[=EA=B3=B5=EC=98=88=EC=98=81]=202=EC=9E=A5:=20?=
 =?UTF-8?q?=ED=95=A8=EA=BB=98=20(#14)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* Create 공예영.md

* Update 공예영.md
---
 .../\352\263\265\354\230\210\354\230\201.md"  | 117 ++++++++++++++++++
 1 file changed, 117 insertions(+)
 create mode 100644 "2\354\236\245/\352\263\265\354\230\210\354\230\201.md"

diff --git "a/2\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/2\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..2a4c98d
--- /dev/null
+++ "b/2\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,117 @@
+# 팀 전체가 공유하는 ‘시끄러운 공간’
+
+> 협력에서 면대면 의사소통의 중요성은 이미 입증되어있음.
+조용한 작업환경을 강조하다보면, 면대면 의사소통을 귀찮아하는 사람들에게 좋은 핑곗거리가 될 수 있다.
+> 
+- 혼자 하는 작업 환경을 선호하는 팀원도 있었기에 이걸 조율하는 데에 고민이 많았음
+- 면대면 의사소통이 확실히 효율적이었음
+- 각자의 작업 스타일을 넘어서, 협업 측면에서 면대면 작업은 어느정도 필수적이라는 생각이 들었음
+
+# 소프트웨어 개발 비용을 결정하는 요소
+
+> 도구
+사람
+시스템 : 제품의 복잡도
+관리 : 사람을 배정하고 작업 분배를 조정, 동기 고취 등
+> 
+
+# 추상화를 높이는 방법
+
+> 시각이 다른 두 사람이 협력하기 - 서로 다른 시각을 연결하려면 추상화가 필요하다.
+> 
+- 개발 관점에서의 추상화는 대략적으로 알겠지만
+- 협업 관점에서의 추상화란 모호하게 느껴짐
+- 자신의 지식/분야에서만 갇히지 않고 해결하고자하는 문제를 큰 그림으로 생각하게 되는 것을 말하나?
+
+# 복수 공유
+
+> 팀 내 신뢰를 위해서 널리 사용되는 방법 - 투명성, 공유, 인터랙션
+공유하는 방법에 따라 신뢰도에 영향이 있다.
+최고 공유 / 하나 공유 등 하나의 작업물만 공유하는 경우엔 더 소극적인 피드백과 방어적인 태도를 보이는 경향
+여러가지 작업물을 동시에 공유했을 때 더 자유로운 인터랙션
+> 
+
+# 품질이란 누군가에게 가치가 되는 것이다.
+
+> 품질도 결함도 상대적으로 정의된다. 누군가에겐 기능인 것이 다른 사람에겐 결함이 되기도 한다.
+> 
+- 사용자가 필요로 하는 서비스를 만들고 싶다는 것이 나의 가치관이어서 공감이 되었음
+- 개발에만 집중하다보면 단순히 최신기술, 빠른 속도에만 치중하게 되는 편향적 사고가 생기기 쉬운 것 같음
+
+# 부하직원에게도 설득이 필요하다
+
+> 설득을 잘 하려면? 객관적 수치도 필요하지만, 상대방에 대한 이해,대화도 그만큼 중요하다
+> 
+
+# 객관의 개념도 주관적이며, 논리와 감정적 판단을 분리할 수 없다.
+
+> 마음에 안들면 어떤 객관적 자료로도 설득할 수 없다.
+> 
+
+> 설득이란, 자료에서 출발하는 것이 아니라 그 대상에서 출발하는 것이다.
+> 
+
+> 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 한다.
+> 
+
+# 효과적으로 알려주기
+
+> 알려주기 전에, 그 사람의 사고 과정과 전략을 이해하기
+> 
+
+> 비난이 아니라, 함께 동기와 의지를 북돋아주고 같이 고민해주는 것이 중요하다.
+> 
+- 알려주는 것이 어렵게 느껴졌었다. 나의 지식의 한계가 드러날까봐, 잘 못 알려줄까봐 부담스러웠던 것 같음
+- 기술된 방법을 쓴다면 훨씬 부담이 적고 서로 성장할 수 있을 것 같다.
+- 알려주는 것만큼 잘 물어보는 것도 중요하다는 생각이 들었다.
+- 나름의 논리를 가지고, 이해안가는 부분에 대해 잘 정리해두는 것
+- 질문하는 것도 연습이 필요한 것 같다!
+
+# 상호 참조 전략
+
+> 프로그램을 연구 → 도메인 어휘로 번역 → 프로그램상의 어휘로 바꿔서 검증
+> 
+
+> 추상과 구상의 차원을 자주 오가기
+> 
+
+- 삼투압적 의사소통
+    - 서로 간에 정보가 스며들도록
+    - 실시간, 자주 적은 양의 일을 → 지속적 흐름
+
+# 좋은 팀 문화
+
+> 1.  팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 중요
+2. 심리적 안전감 ? 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음
+> 
+- 잘 질문할 수 있는 환경을 어떻게 만들 수 있을까?
+- 당장 잘 질문하지 못하는 동료를 어떻게 대하면 좋을까?
+- 질문할수있는 용기를 키우는 방법?
+
+# 학습 환경
+
+> 학습과 일을 분리하지 않고 동체로 만들기
+
+
+# 분업이 아닌, 협업
+
+> 프로젝트를 잘 모르는 상태로 업무를 분담하면 엉뚱한 결과가 나오기도 하고, 그 안에서 협력이 아닌 분업을 하게 된다.
+> 
+- 이전까지의 작업이 분업에 가까웠던 것 같다. 각자 업무를 분담하고 각자의 작업 진행 상황을 공유하는 방식이었다.
+- 나중에 알고 보니 같은 오류와 같은 고민을 했었다는 것을 알게 되었다.
+- 일단 자신의 고민에 대해 자유롭게 말할 수 있는 문화가 중요한 것 같다.
+
+# 🔥 애자일
+
+> 좋은 일은 그리고 확률 → 또는 확률
+> 
+> - 정보는 공유
+
+> 나쁜 일은 또는 확률 → 그리고 확률
+> 
+> - 버그는 중복 검토
+- jira를 쓸 땐 의무적으로 팀문서를 작성하면서 트러블슈팅을 공유
+- 새로운 기술, 쿠버네티스를 적용했을때 특히나 유용했다.
+- 덕분에 헤매는 팀원도 잘 따라올 수 있었음
+- 하지만 대부분의 경우 빠듯한 일정때문에 트러블슈팅을 잘 정리하는 것이 쉽지 않았음
+- 효율적으로 정보를 실시간으로 잘 공유하는 방법?