
## DDD(Domain Driven Development)란?

- 비즈니스 Domain은 유사한 업무의 집합이다.

- 어플리케이션은 비즈니스 도메인별로 나누어 설계 및 개발하는 방식

- 목표 : 모듈간의 의존성 최소화, 응집성 최대화

- Ubiquitos Language(유비쿼터스 언어)
    - 개발자, 디자이너, PM 등 참여자들이 동일한 의미로 이해하는 언어
    - 도메인내에 정확한 커뮤니케이션을 위해 공통언어를 정의하고 사용해야 한다.

## Entity, VO, Aggregate, Factory, Repository
- Entity : 객체가 id를 가져서 unique하게 구분되어야 할 경우
- VO(Value Object): 구분될 필요 없는 정보를 담은 객체
- Aggregate : Entity + VO, 논리적 객체
- Factory : 인스턴스 제작 역할
- Repository : Data Layer를 담당

## Layered Architecture
- Presentation : UI Layer
- Service : Domain, Data Layer간의 class 제어 또는 연결
- Domain : Domain Object별로의 비즈니스 로직 처리 담당
- Data Layer : DB에서 정보 가져오기

## 참고

- DDD 핵심만 빠르게 이해하기[https://happycloud-lee.tistory.com/94]
- DDD infrastructure layer 설계[https://jaehoney.tistory.com/221]

DDD(Domain Driven Development) 정리


### 핵심 내용
- 지독한 솔직함 (Radical Candor)
- 팀장이 가져야 할 자세

### 기억에 남는 글
- 밥의 이야기
    - 환상적인 이력서와 추천서
    - 친절하고, 재미있고, 배려심이 깊음. 직원들도 모두 밥을 좋아한다.
    - 완전히 기본적인 서류 작성 조차 제대로 하지 못한다면? or 마감 기한을 지키지 않는다면?
- 내가 팀장이라면?
    - 회사의 업무 방식이 익숙하지 않았던, 집안에 문제가 있었던... 조만간 유능한 직원으로서 면모를 보여주겠지 하면서 본인을 설득한다.
    - 그가 작성하지 못한 서류는 내가 바로 잡으면 된다.
    - 서류 작성법을 가르치는 것 보다 쉽다.
    - 고생했다. 잘 했다. 등의 거짓 칭찬
- 문제점:
    - 상황을 회피함으로써 밥에게 열심히 도전해야 할 동기를 앗아감
    - 처음에는 안타까운 마음이 들다가도, 점점 화가 나고 그 사람이 싫어지게 됨
    - 언젠가부터 차분하게 대화를 나누기 힘들고, 대화를 멀리한다
    - 주변 팀원들이 밥의 부족함을 메꾸기 위해 업무를 보충하고, 처음부터 다시 한다.
    - 다른 팀원들에게 그 모습을 보여줌으로서 팀 전체의 사기가 떨어진다.
- 결론
    - 해고 통보
    - 밥은 왜 진작 말씀 하시지 않으셨냐고, 모두가 날 좋아 하는줄 알았다는 이야기를 듣게 됨
    - 회사는 저조한 성과로 문을 닫았다.

구글
- 구글의 공동 창업자인 래리 페이지와 이야기하는 구글의 직원(맷 커츠)는 래리의 의견에 대해 "엄청난 쓰레기"라는 표현을 섞으며 논의를 한다고 한다.
애플
- 한 면접자가, 스티브잡스에게 애플의 조직을 어떻게 구상했는지, 앞으로 얼마나 더 성장할 수 있는지 묻자
- 글쎄요, 그걸 안다면 당신을 뽑을 필요가 없겠죠 라고 답변.
- 애플은 기본적으로 애플에 지시를 내릴 수 있는 사람을 채용한다.

칭찬과 피드백은 쉽지 않다. 그리고 모두가 두려워한다.
- 칭찬을 할때는 다른 사람에 대해 관심이 필요하고, 자칫하면 조롱하는것처럼 들리지 않게 하기 위해 신경써야한다.
- 피드백을 하는 사람도, 피드백을 받는 사람도 힘들다
- 우리의 고정 관념으로 보아, 상사에 대한 피드백은 권위에 대한 도전으로 여겨질 수 있다.
- 하지만 이런 직접적 피드백들은 우리가 더욱 효율적으로 일할 수 있게 하며, 더욱 성장 시킨다.
- 격의 없이 일할 수 있는 환경을 구성해야 한다.
- 우리는 누군가 궤도를 이탈 했을 때 동료들이 조언을 해주는 조직 문화를 마련 해야 한다.

앞에서 말한, 격의 없는 의사 소통을 하려면,
그냥 본인 머릿속의 이야기들을 필터링 없이 이야기만 하면 되는가? X
구체적으로 어떤 것이 필요한가?
- 격의 없는 의사 소통을 받아 들일 수 있는 구성원들
    - 이미 충족되어 있다
    - 우리는 기본적으로 성장하고 싶은 사람들의 모임
- 완전한 솔직함이 필요하다.

완전한 솔직함(Radical Candor)란?
- 개인적 관심
    - 업무적인 태도를 유지한다는 것 = 정시에 출근해 맡은 일을 처리하고, 목표 달성을 제외한 개인적 감정을 드러내지 말자? = 모두가 소모품이 되는 회사
    - 일이란 결국 사람들이 모여서 이루어 지는 것. 좋은 팀은 그렇게 구성 되지 않는다.
    - 개인적 관심이란, 단순히 업무와 경력에 대한 관심이 아니다. 생일을 기억하거나 치부를 공유하거나, 회식을 하거나 안가도 될 행사에 억지로 가서 하는 잡담이 아니다.
    - 대화를 나누고, 서로의 인간적인 측면을 이해하고, 아침에 일어나 출근하도록 만드는 일은 무엇 인지, 출근하기 싫게 만드는 것은 무엇인지 이야기 하는 것.
    - 자신의 모습을 있는 그대로 드러내는 것에서 부터 시작.
- 직접적 대립
    - 비난, 무례한 표현과는 다르다 : 아무런 이유 없이 이의를 제기하거나, 사람들이 보는 앞에서 비난하지 않는다.
    - 사소한 트집을 잡는 것도 아니다. 함께 수다를 떨며 논쟁을 하는것도 아니다.
    - 기본적으로 겸손한 마음으로 하는 것. 그리고 상대방이 발전하기를 바라는 마음으로 하는 이야기.
    - 셰릴의 이야기 ("음"이라니, 멍청하게 들립니다.)
        - 구글에서 놀라운 경력을 쌓아가고 있군요
        - 오늘 당신이 질문을 다루는 방식에서 나도 많은것을 배웠다.
        - 당신은 언제나 더 잘할 수 있는 부분에 집중하는 경향이 있다. 훌륭한 프레젠테이션이었다.
        - "음"이라는 말을 너무 자주한다. 긴장해서 그런거죠? 발성 전문가를 한 사람 소개해주겠다. 비용은 회사에서 대줄겁니다.
        - 손사래를 치며 말할때 습관인것 같다고 말 하니,
        - 그런 손짓은 상대를 무시한다는 느낌을 줄 수 있다. 당신은 똑똑한 사람이나, '음'을 연발하는건 멍청하게 들린다.
        - 발성 전문가를 소개해 주겠다.
        - 개인의 결함처럼 느끼지 않게 하도록 특별한 주의가 필요하고, (멍청하다 X, 멍청하게 들린다 O)
            - 문제 많은 멍청이라는 것 보다는 투자할 가치가 있는 인재.
            - 음 문제에 대한 해결
            - 다른 사람에게 더 나은 조언을 해줄수 있겠다.
    - 피드백의 사분면 이야기 : 지퍼가 열린 친구에 대한 조언
        - 완전한 솔직함 : 직접적 대립이 높고, 개인적 관심도 높다.
            - 몰래 가서 너 지퍼 열렸어 라고 속삭여주는 것
        - 파괴적 공감 : 직접적 대립은 낮으나, 개인적 관심은 높다.
            - 상대방의 감정을 걱정해 아무런 말도 하지 않는 것
                - 불편한 부분은 피하고자 하는 것.
                - 러시아 속담 : 개의 꼬리를 잘라야 해서, 매일 1cm씩 짜르기
                - 모든 직원과 좋은 관계를 유지 하고자 할 때
                - 본인의 개선 점을 찾지 못한 채 정체 되거나, 해고 당하게 된다.
        - 고의적 거짓 : 직접적 대립은 낮으나, 개인적 관심도 낮다.
            - 내 감정을 걱정해 아무런 말도 하지 않는 것
                - 고의적으로 파티에서 아무런 말도 하지 않은 예시
                - 본인의 이미지를 생각해 아무런 말도 하지 않는 팀장
                - 잘못된 행동으로 곤궁에 처했을 때, 가식적이고 정치적인 모습을 보이는 현상
        - 불쾌한 공격 : 직접적 대립은 높으나, 개인적 관심은 낮음
            - 저사람 지퍼 열렸다 라고 크게 이야기 하는 것
                - 인간의 근본적 예의는 지켜야 한다.
                - 공개적 비판
                - 비난
                - 문제의 개인화 : 그 사람은 탐욕적이고 위선적이다.

완전히 솔직하게 말하는 방법
칭찬
- 의미있는 칭찬은 쉽지 않다.
- 영혼없는 단어의 나열이 아닌, 상대방이 진심이라고 느낄 수 있도록 구체적이고 명확한 칭찬이 필요하다.
- 본인이 왜 중요한지 정확하게 이해할 때 까지 조사
    - 섣부르게 칭찬해서 한 사람의 공으로 돌려버려 곤란을 겪은 이야기
- 칭찬으로 조롱하기의 예시
    - 이메일을 통해 연봉을 공개한 기업의 이야기

부정적 피드백
- 해석의 여지가 없이 투명하고 분명히 자기의견을 전달해야 한다.
- 성과가 좋을때나 나쁠때나 서로 피드백한다.
- 개인적으로 받아들이지 마세요라고 말하지 않는다.
    - 본인의 말이 다른사람에게 상처가 될 수 있다고 인정하기.
    - 상처를 주지 않은 척 하지 말자. 자기 말을 후회하는데서 그치지 말자. 그 이후 개인적인 관심을 더 보여주자.

완전한 솔직함의 효과
- 솔직하게 의견을 제시하면 상대가 화를 낼거라 생각하지만, 오히려 대화를 나눌 기회를 준 것에 대한 고마움을 느낀다. (처음에는 화가 나거나 불쾌할 수도 있다.)
- 완전히 솔직해지면, 중재에 필요한 시간이 줄어든다.
- 본인의 업무뿐 아니라 함께 일하는 동료와 환경을 사랑하게 된다.
- 팀의 성과가 높아진다.


### 느낀점
- 파괴적 침묵(아무말도 하지 않는 것)이 지독한 솔직함보다 훨씬 더 나쁜 것.
- 서로에게 솔직하게 피드백 할 수 있는 환경을 만들어야 한다.



[책 리뷰] 실리콘 밸리의 팀장들


### kmp

```python
def fail():
    f = [0 for _ in range(len(s))]
    j = 0
    for i in range(1, len(s)):
        while j > 0 and s[i] != s[j]:
            j = f[j-1]
        if s[i] == s[j]:
            j += 1
            f[i] = j
    return f


def kmp():
    _fail = fail()
    i, j = 0, 0
    find = False

    while i != len(origin):
        if origin[i] == s[j]:
            i += 1
            j += 1
        else:
            if j-1 < 0:
                i += 1
                j = 0
            else:
                j = _fail[j-1]

        if j == len(s):
            find = True
            j = _fail[j-1]
    return find


result = kmp()
if result:
    print(1)
else:
    print(0)
```

[알고리즘] KMP


### 기억하고 싶은 내용
- 메타에서의 면접
    - 스몰토크
    - 본인이 같이 일하는 파트너라고 생각
    - 그리고 그런 나와 어떻게 일할지

- 팀장으로서의 툴
    - 조직문화
    - 팀 셋업
    - 팀 빌딩

- 팀장은 딱 하나만 집중하면 된다.
  - 최고의 팀을 만드는 것
  - 24시간 팀 빌딩에 집중하기
    - 저성과 관리는 잘하는 팀장도 어렵다.
    - 처음 팀장을 하는 사람에게 최대 3명 정도가 적당하다.
    - 나보다 잘 할수 있는 사람을 뽑고, 그 사람이 최대한 잘 할수 있는 프로세스를 만든다.

- 메타에서는 어려운 피드백일 경우 주말에 생각해볼 수 있도록 금요일 퇴근 직전에 피드백을 준다고 함

### 느낀점
- 모든 답을 알 수 있지 않다고 솔직하게 말하는게 중요하다고 느꼈다.
- 잘 모르니까 자주 물어볼 수 있다.
- 나보다 더 잘 할수 있는 사람을 뽑고, 그 사람이 잘 할수 있도록 도와줘야 한다.
- 프로세스가 중요하다. 정기적인 규칙을 만들고 그걸 시행 할 수 있도록 하자

### 출처
- [처음 리더가 된 사람들을 위한 조언 by 전 메타(META) 수석팀장](https://www.youtube.com/watch?v=UADiwl9SHss&t=11s)
- [저커버그도 따라야 하는 메타의 피드백 원칙](https://www.youtube.com/watch?v=Fn3fGp9s3bY&t=10s)


팀장 관련 아티클 정리 2


### 기억하고 싶은 내용
- 서로의 생각이 얼마나 잘 전달 되고 있는지 끊임 없는 대화를 통해 파악하자. 원온원 미팅도 좋지만, 너무 거창하게 준비해가지 말자.
- 만장 일치는 불가능하다. 팀장이 결정 해야 할 경우 팀장이 결정 하고, 팀원이 결정 하는게 효율적일 경우 팀원이 결정하게 하자.
- 팀원들의 모든 일을 파악 하는 것은 불가능하다.
    - 목적과 가설만 확실히, 구체적인 방식은 팀원이 직접 결정 하게끔 한다.
    - 간헐적인 질문 보다는, 정기적 프로세스가 더 낫다.
- 팀장이 답을 알려 줄 수는 없다.
    - 팀장이라고 모든 업무 경험이 있는 것은 아니다.
    - 좋은 답을 찾을 수 있도록 도와주는 존재다.
    - 팀원이 답을 찾는데 필요한 리소스를 최대한 빨리 제공한다.
- 팀장이 팀원을 이기면 팀에 발전이 없다.
    - 팀원들에게 항상 똑똑해 보일 필요 없다.
    - 내 생각대로 팀원들을 설득하지 말자.
    - 팀원들의 이야기를 먼저 들어보고, 내 의견은 가장 마지막에 말한다.
    - 리스크가 큰 일이 아니라면, 팀원이 많이 고민해봤다고 하면 팀원의 의견을 그냥 믿어준다.
    - 팀장이 팀원의 도움을 받는게 당연하다고 인지시킨다.
- 단점에 집중하면 신뢰 관계 구축이 늦어진다.
    - 모든 사람에게는 단점이 있다는 것을 인정하고, 팀원의 장점을 살릴수 있는 방향으로 업무를 배정한다.
- 헌신이 가장 큰 경쟁력이다
    - 항상 맞는 말만 하고 똑똑한 모습을 보여주려고 하지 말자.
    - 선의를 베풀고, 회사와 동료들을 위해 헌신하자.
- 팀의 비전, 목표, 정체성을 잘 설립하자
    - 팀의 비전 : 팀이 나아가고자 하는 방향
    - 팀의 정체성 : 팀이 외부에 있는 사람들로부터 평가받고 싶은 이미지
    - 팀의 목표 : 우리의 정체성을 달성하고, 비전을 달성하기 위해서 우리가 해야하는 일


### 느낀점
- 나도 경험이 많지 않아서 팀원들에게 답을 알려주지 못하는 상황, 그 상황 속에서 팀원들이 하는 일을 모두 파악하지 못한다는 불안함이 있었다.
하지만 글을 읽고 나서 모든걸 파악하려고 한다기 보다는 팀원들이 하고 있는 일을 더 잘 할 수 있게 해주는게 중요하다는 것을 느꼈다.

- 처음 팀장을 하다보니, 팀원들에게 똑똑해 보이고 싶었다. 그래서 항상 팀원들과의 미팅이 있거나, 팀원들이 의견을 구하면
내 생각을 먼저 말했고, 팀원들이 보통 내 의견에 따라오는 구조였다. 하지만 아티클들을 읽으면서 그런 행동들이 팀의 역량을 내 역량 안에 가두고 있다는 생각이 들었다.
앞으로는 팀원들의 이야기를 먼저 들어보고, 고민하는 팀원들의 의견을 더 많이 듣고 따를 수 있는 팀장이 되어야 겠다는 생각을 했다.

- 전사적 비전이 결정되기 이전에, 일단 먼저 팀 차원에서의 비전, 팀의 목표, 그리고 정체성을 설정해보고 싶다는 생각을 했다.
팀원들과 한번 논의 해야 겠다는 생각이 들었다.


### 출처
- [어느날 팀장이 되었다](https://brunch.co.kr/@zseo/42)
- ['너잘내잘'을 명심하자](https://brunch.co.kr/@zseo/45)
- [미팅으로 가득찬 팀장의 하루](https://brunch.co.kr/@zseo/44)

팀장 관련 아티클 정리 1


### 핵심 내용
- 전통적 방식 vs 제품팀 중심의 새로운 방식에 대한 비교
- 제품 관리자 중심으로 서술한 좋은 제품 관리자가 되는 법
- 제품 관리자의 역할과, 제품 관리자로서 지녀야 할 마인드, 제품 관리자를 둘러싼 관계자들에 대한 역할과 책임을 설명
- 제품 팀은 무슨 일을 해야 하는가?
- 제품 비전, 제품 전략, 제품 원칙
- 제품 발견 기법
- 제품 프로토 타이핑 기법
- 제품 발견 테스트 기법
- 제품팀의 문화

### 기억에 남는 글
- 만들 만한 가치가 있는 제품이 아니라면 엔지니어팀이 얼마나 훌륭한 지는 아무 의미가 없다.
- 실패한 제품의 근본 원인 (= waterfall)
    - 아이디어 -> 로드맵 -> 요구사항 -> 디자인 -> 구현 -> 테스트 -> 배포
    - 왜? 중요한 일을 먼저 수행해 주기를 원하며, 언제 준비될지 예측하고 싶기 때문에.
    - 제품 관리자 : 요구 사항 수립
    - 디자이너 : 요구 사항 디자인
    - 엔지니어 : 구현 시작 (애자일, 스프린트, QA, 배포)
    - 문제점
        - 아이디어의 원천 : 이해 관계자 위주로 제품이 끌려가게 된다.
        - 정말 뛰어난 아이디어를 가져 오지는 못할 것, 아이디어의 최소 2/3은 쓸모 없음
        - 권한 위임이 안됨. 제품팀은 그냥 원하는 바를 구현 해 주는 용병. 주인 의식 X
        - 제품 개발 -> 모르는 것을 알아가는 과정. 현재 시점에서 얼마만큼 돈을 벌수 있고, 얼마나 비용이 드는가 계산 할 수 없음 : 솔루션의 퀄리티에 달려있을 뿐.
        - 실제로 구현을 한다고 해도 현재 해결하고자 하는 미션을 해결할 수 있을지는 알수 없음.
        - 정말 뛰어난 아이디어라고 해도, 수익 창출 과정까지는 몇번의 이터레이션 과정을 반복해야 한다. (TTM)
        - 해당 모델에서의 PM : 요구사항을 수집하고, 문서화만 하는 역할
        - 디자이너, 개발자 : 이렇게 하는것이 바람직하지 않다는걸 알고 있지만, 현재 상황에서 할수 있는 방식으로 그냥 진행 하게 됨.
        - 엔지니어들이 너무 늦게 참여해서, 혁신을 하는데 가장 훌륭한 원천을 놓치고 있는 것
        - 애자일 원칙과 핵심의 장점이 너무 늦게 작동한다. (제품 구현 단계에서만 애자일 적용.)
        - 프로젝트 중심적, 문제 상황을 해결하는데 집중하지 않는다. 프로젝트의 성공과 문제 상황에 대한 해결은 다르다.
- 제품 팀을 만들면 어떤 점이 좋아지는가?
    - 협업에서는 관계가 중요한 역할을 하는데, 제품 팀은 이를 잘 살리는 형태
    - 전문성이 충분히 확보될 만큼 깊이 업무 가능
    - 팀 전체가 주인의식과 성과에 대한 책임감을 느낀다.
    - 기능 구현으로 끝이 아니라, 원하는 미션이 달성될 때 까지 책임감을 느낀다.
- 제품 팀의 권한과 위치
    - 같은 장소에서 근무하면 효율이 더 높다.
    - 업무 범위 : 제품과 관련된 모든 책임
    - 일의 범위 : 회사에서 필요에 따라 설정
    - 팀의 지속성 : 프로젝트를 수행하기 위해 형성된 조직이 아님. 주인 의식을 느끼기 위해서는 충분한 지속성 필요
    - 팀의 자율성 : 팀이 판단 하기에 주어진 문제를 해결 하는데 최고의 방법 시도


- CTO로서의 역할 (104p)
    - 조직 : 직원들의 역량 개발에 대해 신경 쓰고, 좋은 팀 조직을 구성 하는 일
    - 리더십 : 비즈니스 전략 방향, 기술적 조언, 기술 대표
    - 제품 실행 : 신속하고, 믿을 수 있는 품질의 제품을 시장 제공 가능 하도록 관리 하는 책임
    - 아키텍쳐 : 전체를 바라보고, 인프라가 비즈니스 성장 속도에 맞춰지고 있는가?
    - 제품 발견 : 엔지니어들이 제품 발견에 참여 하는 지속성과 범위를 관리
    - 기술 전도사 : 기술 조직의 대변인, 협력사, 고객 커뮤니티에 리더십 발휘

- 제품 팀을 나누는 원칙 (111p)
    - 마법같은 원칙은 없다
    - 투자 전략과 연계하여 : 제 역할을 못하는 팀을 줄이고. 캐시 카우 제품에 투자를 줄이며 새로운 매출과 성장에 집중
    - 상호 의존의 최소화 : 더 빨리, 더 많은 자율성을 느낄 수 있도록
    - 주인 의식과 자율성 : 용병이 아닌 미션팀을 원한다. 충분한 권한을 가지고 제품에서 중요한 부분을 책임지고 있다는 것을 느낄수 있게.
    - 레버리지 극대화 : 공통적인 요청, 공유하는 서비스에 대해 대응하기 위한 새로운 공유 서비스 -> 사내툴
    - 제품 비전과 전략 : 우리 조직이 도달해야 할 곳이 어디인지 설명과 설정, 이걸 잘 실행하기 유리한 형태로 구성
    - 팀의 규모 : 한 팀에 한명의 제품 관리자, 디자이너와 엔지니어 2명이 최소 단위
    - 아키텍쳐와 연계 : 비전을 실행하기 위한 아키텍쳐 구상, 그리고 아키텍쳐를 중심으로 설계. 다른 팀에 공통 서비스를 제공하는 팀 (플랫폼 팀)
    - 사용자 또는 고객과 연계 : 담당하는 고객에 대해 깊이 이해할 수 있기 때문에 유리.
    - 비즈니스와 연계 : 여러개의 사업 영역에 대해 고려. 보통은 여러개의 사업이 공통적, 통합적 기반으로 만들어 졌으므로 대체로 다른 기준을 먼저 반영한 후 고려
    - 구조는 움직이는 목표물이다 : 팀을 구성하는 완벽한 방법은 없음. 시간이 지남이 따라 변해야만 하고, 1년에 한번 정도 변하는게 일반적이다.

- 제품 로드맵의 문제 (134p)
    - 최소 절반 이상의 아이디어는 유효하지 않을 것.
    - 지나치게 복잡해서 쓰임새보단 골칫거리가 많을 것.
    - 제품 생산시 예상보다 더 많은 자원이 필요해 실현 가능성이 없는 것.
    - 법적, 재무적 제약 사항이 출시를 막을 수도 있음.
    - 유효성이 검증되었다고 하더라도, 비즈니스 가치를 만들기까지 최소 몇번의 이터레이션을 반복 해야 함.


- 제품 비전과 제품 전략, 제품 원칙 (145p)
    - 제품 비전 : 2-5년 정도의 기간에 우리가 만드는 미래.
    - 제품 전략 : 비전을 실현하기 위한 과정
    - 제품 원칙 : 만들고자 하는 제품의 특성 (ex, 구매자와 판매자가 원하는 것이 충돌할 경우, 구매자가 필요로 하는것에 우선한다.)
    - 제품 비전을 가진다는건 어느정도 믿음을 가진다는 것.
    - 제품 비전은 영감을 줄 수 있어야 하고, 제품 전략은 분명한 초점이 있어야 한다.

- 어디에 시간을 쓸 것인가 (166p)
    - 엔지니어가 플랫폼을 개선하고, 디자이너는 반응형 디자인으로 전환 하는 데 쓰는 시간은 비즈니스 문제 해결에 비해 우선순위가 높지 않다.
    - 더 큰 상위의 목표를 가지고 있다면, 다른 사업 목표와 연계하여 리더십 팀 레벨에서 먼저 우선순위를 논의하라.
    - 각 개인이 그들의 제품팀의 목표에 주목할 수 있도록 하라.

- 열정을 보여주는 방법을 배워라 (175p)
    - 절대 진실하되, 당신이 정말로 설레고 있음을 사람들이 확인 할 수 있게 해 주어라. 열정은 정말로 전염성이 있다.

<br/>
<br/>

| **차이점** | **좋은팀** | **나쁜팀** |
| -------- | -------- | -------------|
| 제품비전 | 있음 | 없음 |
| 영업과 고객 | 영감과 제품 아이디어를 얻음 | 요구사항을 수집 |
| 이해관계자와 제약사항 | 제약 속 유효한 솔루션 제작 | 이해관계자의 요구사항 수집 |
| 제품 기법 | 능숙함 | 우선순위 로드맵을 만듬 |
| 토론 | 즐긴다 | 방어적 자세를 취함 |
| 협업 | 모여 앉아 함께 이야기 | 문서를 통해 업무 요청, 미팅 떠넘기기 |
| 권한 | 아이디어를 시도하면서 매출과 브랜드를 지키는 방향 고려 | 테스트를 실행할 권한 대기 |
| 능력 | 필요한 팀 능력을 갖추려고 고집 | 서로의 역할을 이해하지 못함 |
| 업무 관리 | 엔지니어가 프로토타입을 만들 수 있는 시간이 있는지 확인 | 엔지니어에게 프로토타입을 보여주고 기한 산정 |
| 고객 미팅 | 고객과 매주 만난다 | 자신들이 고객이라고 생각 |
| 업무 방식 | 본인들이 만드는것이 효과가 없을수도 있다는걸 이해하고 여러번 시도해야 한다는것을 암 | 로드맵애 따라 만들며 일정을 준수하는것에 만족 |
| 속도 | 속도와 이터레이션이 핵심임을 이해하고 있다 | 동료가 최선을 다하지 않는 것이 속도가 느린 원인이라고 생각함 |
| 분석 도구 | 업무에 활용 | 분석과 리포트를 있으면 좋은 정도로 여긴다 |
| 배포 | 연속적 통합과 출시 | 커다란 단위로 출시, 한꺼번에 출시 |
| 관점 | 참조 고객에 집착 | 경쟁사에 집착 |
| 성과 | 유의미한 성과를 만들어냈을 때 서로 축하 | 출시 후 축하 |


### 느낀점

1. 좋은 개발조직에서는 팀 전체의 목표가 `구현 완료`에 맞춰져 있지 않고, `미션 해결`에 맞춰져 있다는 사실을 배웠다.
나는 특정 기능이 필요한 경우에 특정 기능을 구현 하는데만 집중 했었고, 특정 기능을 통해 무엇을 개발 하고자 하는지, 그 방식이 그 문제를 해결하는데 최선일지는 생각해보지 않았다.
앞으로는 스프린트 미팅과 킥오프 미팅에서 정말로 우리가 해결하고자 하는 문제가 무엇인지, 그래서 그 기능 개발을 통해 문제를 해결할 수 있는지 좀 더 적극적으로 파악하려고 해야겠다.

2. 최고의 아이디어는 결국 엔지니어에게서 나오는 경우가 많다고 한다. 엔지니어가 제품 발견, 기획 단계에서 적극적으로 참여 할 수 있도록 `핵데이`와같은 장치들을 많이 마련해야 겠다는 생각을 했다.

3. 좋은 제품팀과 나쁜 제품팀을 비교한 자료를 보니, 현재 우리팀은 좋은 제품팀의 기준에 부합하는 항목도 있지만 나쁜 제품 팀의 기준에 부합하는 내용도 많았다. 해당 내용들을 정리해서
동료들과 공유 해 보고, 지속적으로 전파해 우리 팀이 좋은 제품 팀으로 거듭날 수 있도록 지속적으로 알리는 노력을 해야겠다.

4. 강력한 혁신 문화와 실행 문화를 가지는 기업을 만드는 일은 정말로 쉽지 않다. 그리고 그 중심에는 뛰어난 제품 관리자가 있다.

[책 리뷰] inspired


#### 접근
- 이미 잘못 되어 있는 스도쿠가 주어질 경우에 대한 처리를 모르고있다가, 질문 게시판을 다 뒤져보고 난 뒤 깨달았다.

```python
# 4056
import copy
import sys

sys.setrecursionlimit(10000)
input = sys.stdin.readline

N = int(input().strip())


def is_square_valid(arr, x, y, n):
    x_start = ((x-1) // 3) * 3 + 1
    y_start = ((y-1) // 3) * 3 + 1
    d = {}
    for i in range(x_start, x_start + 3):
        for j in range(y_start, y_start + 3):
            target = arr[i][j]
            if target in d and target != 0:
                return False
            if target == n:
                return False
            d[target] = True
    return True


def is_vertical_valid(arr, x, y, n):
    d = {}
    for i in range(1, 10):
        target = arr[i][y]
        if target in d and target != 0:
            return False
        if target == n:
            return False
        d[target] = True
    return True


def is_horizontal_valid(arr, x, y, n):
    d = {}
    for i in range(1, 10):
        target = arr[x][i]
        if target in d and target != 0:
            return False
        if target == n:
            return False
        d[target] = True
    return True


def find(arr, remains):
    global found
    if found:
        return

    if not remains:
        for i in range(1, 10):
            for j in range(1, 10):
                print(arr[i][j], end="")
            print()
        found = True
        return

    for remain in remains:
        x, y = remain
        for i in range(1, 10):
            if not is_vertical_valid(arr, x, y, i):
                continue
            if not is_horizontal_valid(arr, x, y, i):
                continue
            if not is_square_valid(arr, x, y, i):
                continue
            arr[x][y] = i
            new_remain = copy.deepcopy(remains)
            new_remain.remove(remain)
            find(arr, new_remain)
            arr[x][y] = 0


for _ in range(N):
    boards = [[0 for _ in range(10)] for _ in range(10)]
    zeros = []
    for i in range(9):
        for j, c in enumerate(input().strip()):
            num = int(c)
            if num == 0:
                zeros.append((i+1, j+1))
            boards[i+1][j+1] = num
    found = False
    find(boards, zeros)
    if not found:
        print("Could not complete this grid.")
    print()
```


boj 4056 스스스도쿠


```python
# 17302
import sys
input = sys.stdin.readline

N, M = [int(i) for i in input().strip().split(" ")]
boards = []

for _ in range(N):
    boards.append([i for i in input().strip()])

_dx = [-1, 0, 1, 0]
_dy = [0, 1, 0, -1]


def flip(x, y, arr):
    if arr[y][x] == "W":
        arr[y][x] = "B"
    elif arr[y][x] == "B":
        arr[y][x] = "W"


for i in range(N):
    for j in range(M):
        for idx in range(4):
            dx = _dx[idx] + j
            dy = _dy[idx] + i
            if not ((0 <= dx < M) and (0 <= dy < N)):
                continue
            flip(dx, dy, boards)

for i in range(N):
    for j in range(M):
        if boards[i][j] == "B":
            boards[i][j] = 3
        else:
            boards[i][j] = 2

print(1)
for i in range(N):
    for j in range(M):
        print(boards[i][j], end="")
    print()
```


boj 17302


```python
import sys
from collections import deque
input = sys.stdin.readline

N, K = [int(i) for i in input().split()]
visited = [-1 for _ in range(100001)]


cnt = 0
queue = deque([(N, 0)])
visited[N] = 0
while queue:
    p, t = queue.popleft()
    if p == K:
        cnt += 1
    for i in [p+1, p-1, p*2]:
        if not (0 <= i <= 100000):
            continue
        if visited[i] != -1 and visited[i] <= visited[p]:
            continue
        visited[i] = t+1
        queue.append((i, t+1))
print(visited[K])
print(cnt)

```



boj 12851 숨바꼭질2 python


### 접근
- BFS

### 코드
```python
import sys
from collections import deque
input = sys.stdin.readline

# 5
# RRRBB
# GGBBB
# BBBRR
# BBRRR
# RRRRR

n = int(input().strip())

board = []
_dx = [-1, 1, 0, 0]
_dy = [0, 0, -1, 1]

for _ in range(n):
    board.append([i for i in input().strip()])


def bfs():
    visited = [[False for _ in range(n)] for _ in range(n)]
    count = 0

    for w in range(n):
        for h in range(n):
            if not visited[w][h]:
                count += 1
                queue = deque([(w, h)])
                visited[w][h] = True
                while queue:
                    x, y = queue.popleft()
                    for i in range(4):
                        dx = x + _dx[i]
                        dy = y + _dy[i]
                        if not (0 <= dx < n and 0 <= dy < n):
                            continue
                        if visited[dx][dy]:
                            continue
                        if board[dx][dy] != board[x][y]:
                            continue
                        visited[dx][dy] = True
                        queue.append((dx, dy))
    return count


def rg_bfs():
    visited = [[False for _ in range(n)] for _ in range(n)]
    count = 0

    for w in range(n):
        for h in range(n):
            if not visited[w][h]:
                count += 1
                queue = deque([(w, h)])
                visited[w][h] = True
                while queue:
                    x, y = queue.popleft()
                    for i in range(4):
                        dx = x + _dx[i]
                        dy = y + _dy[i]
                        if not (0 <= dx < n and 0 <= dy < n):
                            continue
                        if visited[dx][dy]:
                            continue
                        if board[dx][dy] in ["R", "G"]:
                            if board[x][y] == "B":
                                continue
                        if board[dx][dy] == "B":
                            if board[x][y] in ["R", "G"]:
                                continue
                        visited[dx][dy] = True
                        queue.append((dx, dy))
    return count


print(bfs(), rg_bfs())
```

Seongwoon Jeong

Recents

2023 Apr 29

DDD(Domain Driven Development) 정리

2023 Mar 28

[책 리뷰] 실리콘 밸리의 팀장들

2023 Mar 27

[알고리즘] KMP

2023 Mar 25

팀장 관련 아티클 정리 2

2023 Mar 24

팀장 관련 아티클 정리 1

2023 Mar 18

[책 리뷰] inspired

2023 Feb 19

boj 4056 스스스도쿠

2023 Feb 6

boj 17302

2023 Jan 1

boj 12851 숨바꼭질2 python

2022 Dec 20

boj 10026 python