From c56cce7eb03f0dcbc3d8aa544e5a35fc6a531231 Mon Sep 17 00:00:00 2001
From: hyesungoh <haesungoh414@gmail.com>
Date: Thu, 29 Aug 2024 22:31:30 +0900
Subject: [PATCH] =?UTF-8?q?7=EC=9E=A5=20=EC=98=A4=ED=98=9C=EC=84=B1?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\230\244\355\230\234\354\204\261.md"  | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 "7\354\236\245/\354\230\244\355\230\234\354\204\261.md"

diff --git "a/7\354\236\245/\354\230\244\355\230\234\354\204\261.md" "b/7\354\236\245/\354\230\244\355\230\234\354\204\261.md"
new file mode 100644
index 0000000..fcc69fa
--- /dev/null
+++ "b/7\354\236\245/\354\230\244\355\230\234\354\204\261.md"
@@ -0,0 +1,86 @@
+# 프로젝트 전에
+
+## 요구사항의 구렁텅이
+
+- 완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 빼낼 것이 없을 때 얻게 되는 것이다.
+
+- 정책은 수시로 바뀐다
+  - 요구사항 속에 정책을 고정하지 말자 ~
+
+- 사용자들이 어떤 작업을 현재 어떻게 하느냐는 것을 알아내는 것보다. 왜 그걸 하는지 그 내재적 이유를 알아내는 것이 더 중요하다
+  - 개발을 통해 그들의 실질적 비즈니스 문제를 해결해야하기 때문에
+
+- 개밥먹어라
+
+- 남을 위해 만들어 주는 도구는 필히 적응력이 있어야 한다
+> 이전에 같이 일했던 동료분께서 기존 사용자들의 익숙함을 존중하기 위해 많이 노력하셨던 모습이 기억남
+
+- 표기법의 노예가 되지 말자
+  - 단 의사소통에 도움이 된다면 무엇이든 사용하자
+
+- 사용자와 개발자가 동일한 것을 다른 이름으로 가리키는 프로젝트는 성공하기 힘들다
+  - 같은 이름으로 다른 것을 지칭하는 경우에는 더더욱
+
+
+## 불가능한 퍼즐 풀기
+
+- 어떤 퍼즐이든 그것을 해결하는 열쇠는
+  - 제약을 인식하는 것
+  - 주어진 자유의 정도가 얼마나 되는지 깨닫는 것
+
+- 우리에게 필요한 것은 진짜 제약과 우리를 오도하는 제약 그리고 그 차이를 구별하기 위한 지혜다
+
+- 스스로 질문해봐라
+  - 더 쉬운 방법이 존재?
+  - 진짜 문제를 풀려고 하고 있나?
+  - 왜 이것이 문제인가?
+  - 문제를 이렇게 풀기 어렵게 만드는 것은 무엇?
+  - **반드시 이 방법으로 해야 하는가?**
+  - 반드시 해야 하는 일이긴 한가?
+
+> 기존 구조를 유지하는 것이 편해보여서, 방법을 유지하려던 ... 경험이 종종 있었던 것 같아요
+
+## 준비가 되어야만
+
+- 어떤 일을 뛰어나게 수행하는 사람들은 공통점이 하나 있는데
+  - 언제 시작해야 하고 언제 기다려야 하는지 아는 것
+
+- 프로토타입을 만들다 지루함을 느끼는 것은 처음의 머뭇거림이 단지 시작하는 최초의 행위를 미루고 싶은 바람일 뿐이었다는 것을 나타내는 좋은 징표
+
+- 그냥 "시작해도 되겠다는 느낌이 안들어"라고 선언해버리고 솔리테어를 실행하는 것보다 프로토타입이라도 시작하는 것이 정치적으로 더욱 용인되는 행동이긴 함
+
+> 솔리테어가 무슨 용어인 줄 알았는데 윈도우에 기본으로 있는 게임이였네용
+
+## 명세의 함정
+
+- 어떤 일들은 설명하기보다 실제로 하는 것이 쉽다
+  - 신발끈을 묶는 법?
+
+- 명세라는 담요를 너무 덮고 있지 마라 ~ 언젠가는 코드를 작성해야한다. 지금 해라
+
+## 동기라미와 화살표
+
+- 형식적 방법에 노예가 되지마라
+
+- 새로운 도구와 방법론을 채택하는 데 들어가는 비용을 과소평가하지 말라
+  - 새로운 기법을 사용하는 최초의 프로젝트를 학습 경험으로 여길 마음의 준비를 하라
+
+- 형식적 방법을 사용해야 할까?
+  - 물론
+  - 형식적 방법도 단지 상자 속의 도구 중 하나
+  - 그렇지만 누가 주인인지 기억하라
+
+
+- 어떤 형식적 방법이 팀에 이익을 가져다주고 있다는 사실을 어떻게 알 수 있을까?
+  - 어떤 것을 측정?
+  - 팀 구성원들의 경험 증가와 도구가 준 이점 사이를 구별할 수 있는가?
+
+> 어렵다
+
+- 새로운 방법론을 팀에 도입할 때 손해와 이익이 만나는 지점은 어디인가?
+  - 도구가 새로 도입되면서 잃는 생산성과 미래에 얻을 이점들 사이의 트레이드오프를 어떻게 평가함?
+
+> 어렵다
+> > 근데 새로운 도구가 도입되면서 얻을 생산성과 이전의 것들과의 일관성을 주로 고민하곤 했어요
+
+