서비스의 구조와 팀의 구조가 닮는다

• 리더

  • 내가 아는 모든 맥락을 공유를 먼저 해야한다
  • 말하고자 하는바가 백프로 전달되는 경우는 잘 없다
  • 맥락을 최대한 전달하고 많이 반복해서 전달하겠다 나에게도 그래주면 좋겠다
  • 성장하는 방법을 같이 고민하겠다

• 리더

  • 고객만족과 팀원의 성장 사이에서 적절한 기간이 무엇일지 생각하는게 주요한 일이다
  • 일을 할당할 때 나의 경험으로 해당 업무에서 팀원이 어떤 성장을 할 수 있을지도 고려해서 시간버퍼를 더 줄 수 있는 것도 나의 고려사항
  • 팀원은 우선순위가 바뀌는 것을 경험하지 않고 내가 처리하는게 맞는 것 같다
  • 팀원이 해당 태스크를 자신의 성장과 함께 자신의 능력을 끌어내서 할 수 있도록 해주는 것이 리더의 일
  • 그렇다고 정보를 원하는 것만 주입하는 것이 아니다. 작업에 필요한 주변 정보를 최대한 공유하고 함께 비전을 바라봐야한다 내가 처리할 고민을 떠넘기지만 않으면 된다
  • 그렇지만 고객경험도 중요하기 때문에 기간을 잘 고려해야한다
  • 하지만 나의 저울은 팀원이 좋은 결과물을 내길 바라는 것에 조금 쏠려있을 것이다
  • 시간, 리소스, 비용

같은 영역에 있는 개발자들끼리 한 동영상으로 같이 스터디

리더가 되면

여러분의 조직에서는 실패를 공유하고 있습니까. 만약 리더가 “나는 수치로 나타난 성과만 보고 직원들을 평가하겠다”고 선언한다면, 어떤 부하가 자신의 실수와 실패를 동료와 공유하겠습니까.

• 퇴근할때는 인사없이 퇴근하도록
• 공개된 자리에서 잘못을 목격하면 그 자리에서 뭐라하기 보다는 나중에 그것을 지적해주고 주변에 아무도 없으면 그 자리에서 얘기해준다
• 니가 이걸 해줘서 참 다행이야, 당신이 이 일을 맡아줘서 다행입니다. 라고 말해주자
• 리더가 되면 기능 개발이 잘 됐는지 확인할 때 말로만 확인하지말고 확인한 부분을 체크하고 새로 추가된게 있으면 그 부분이 잘 확인이 됐는지 판단해서 빠진 부분을 같이 채워나가도록 해주면 좋겠다고 배웠다
• 사장이 모든 결정 권한을 갖지 않고 역할별로 권한을 갖게 될 경우에 각 역할에서 했던 결과가 좋지 못할 경우 그것을 제지하는 것은 결국 사장(또는 인사)이 아닌가?
• 리더가 구체적인 만들 목표를 제시하는 것보다 (무엇을 만들자) 가야하는 길을 알려주는게 팀이 더 잘 동작한다

피자 2판 팀

서비스 당 10개 정도의 라이브러리 사용

• 아마존 팀은 피자 2판 팀으로 유명한데 팀이 일하는 방식과 팀간의 일하는 방식이 실제로 어떻게 이루어지고 있는지 알고싶다

기능 단위로 팀이 분리가 되면 다른 기능에 대해 아이디어가 생겨도 개발하기 힘들다 직접하기 보다는 기존 팀이 하는 것이 더 좋을 것이다 그렇다면 아이디어를 기존 팀에 잘 전파하고 공유할 수 있어야 한다 이 소통창구는 라이브러리 공유에도 쓰일 수 있겠다

직종별로 팀이 나눠져있다가

프로젝트가 시작되면 직종마다 사람이 와서 합쳐져서 뭉치도록 하면 되겠다

모두 프로젝트를 진행중이라면 전체 프로젝트 확인이 되는 것이고, 프로젝트가 끝나면 다음 프로젝트로 넘어갈 수도 있고.

이미 이렇게 일하고 있겠다.

이걸 자료 검색에도 이용할 수 있겠다 카테고리별로 분류 되있다가 어떤 다른 검색이 들어오면 그대로도 검색이 되도록 쿠팡이 첫페이지에서 카테고리를 보여주고 있는 것도 이런 생각이 이미 거친 것이겠다

프로젝트별로 각 부서에서 모여서 작업하는 방식이 TF를 구성해서 긴급사안에 대비하는 것과 비슷해보이는데 TF는 대게 겉만 파다가 끝나는 경우가 있다

어떻게 하면 효과적으로 TF팀이 일을 할까? 사례를 찾아보면 도움이 되겠다

기능별로 팀을 나눈다

하나의 플랫폼이 있고, 그 안에 기능을 분리하여 팀도 기능에 맞춰서 분리하는 구조 기능의 고도화, 유지 및 관리에 유리할 것 같다. 소프트웨어의 사이즈도 적당히 제한될 수 있을 것 같다. 예를 들어 전자결제 플랫폼이라면,

마이크로서비스는 한 기능의 크기를 작게 하는 대신 기능별로 연결 시 오버헤드가 증가하고, 각 기능별로 상태를 확인하는 것도 오버헤드다

전체를 보는 방법

전체를 보는 역할을 하는 사람을 따로 두어 관리하게 한다. ex 풍훤

타이거팀 https://bcho.tistory.com/992

문서를 효과적으로 관리하려면, 한 곳에 모으고, 계속해서 업데이트하고, 커뮤니케이션을 위한 문서만 만들도록 하면 효과적일 수 있겠다.

회사에서 리더가 일을 다 끌어안으면 안되고 잘 나눠야하는 것처럼 일상생활에서도 이런 방식으로 만들어나가야 할 것 같다

분업

• 전체를 직접 관리 - 피드백은 빨라진다. 그러나 분업의 장점도 있다. 설계, 고객대응, 개발을 모두 하면 좋은 제품이 나온다?
• 고객과 개발자가 분리되있어서 동상이몽을 하는 것이 문제되어 연결하고자 하는 것 같은데, 기획과 개발을 합치려는 것인가
• 시작할 때 큰 설계
• 시작할 때 목표를 설정
• 큰 틀 잡는 것 없이 짧게 짧게 설계
• 설계 후 구현 시 짧은 주기로 구현 확인

적절하게 선택된 개체들에게

한정된 자원을 두고 경쟁하게 하면 통제자가 없어도 집단이 잘 동작한다고 한다는 연구가 있다

• 복잡하지만 단순하게

리멤버 회사 서버/웹 팀이 일하는 방식

• https://blog.dramancompany.com/2020/12/리멤버-서버-웹-팀은-어떻게-일을-하는가/

테크 스택, 코드 퀄리티(리뷰, 테스트), 오버 커뮤니케이션, 문서화

테크 스택

• AWS, EC2, Auto scaling, Fargate
  • Code Build를 이용하여 테스트 분산처리
  • ELB prewarm으로 트래픽 대응
• Ruby on Rails
• React

코드 퀄리티

• 코드 리뷰
• 테스트 코드

업무구조

• 기능조직(서버, 웹, 디자인 등)
• 목적조직(광고, 커리어 등)
  • crew와 이를 도와주는 베이스캠프로 이루어짐

업무의 만족도에 영향을 미치는 요소

• 물질적인 보상과 기회
• 일 자체가 불러일으키는 의욕과 흥미
• 복지, 근무환경, 조직들 사이의 위치
• 관리자와 리더의 능력

팀 전체가 참여하여 설정한 목표를 추구한다면, 결과물을 더 쉽게 얻을 수 있다.

재택 근무가 가능한 업무와 아닌 업무가 있겠다

티켓별로 각자 일하면 되지 않을까 생각했는데, 연관된 사람들과 같이 해야하는 일이 있고, 생산직 같은 경우는 노동 시간이 곧 생산량이 되기도 한다.

매니저가 되면 구성원들의 상태를 확인하고 필요한 것들을 잘 연결 시켜 줘야 한다.

일을 진행할 때

• 하려는 것과 왜 하려는지와 기대하는 것을 같이 전달해야 서로 오해가 줄어든다
• 내가 리더인데 팀원들의 실적을 모른다면 제대로 일을 안하는 것임
  • 가능성을 터트리거나 내가 제안하거나

커뮤니케이션에 대한 불안

너무 바쁜것으로 보이는 리더 일일이 물어보기 죄송 진행상황은 보고 하고 싶은데 진행상황 정리가 잘 안됨

비판 대신 진취적 개선에 에너지를 쏟는다.

개발자와 PO는 오버헤드를 감소시키면서, 속도와 품질을 향상시키기 위해 프로세스가 어떻게 수정되어야 하는지 논의한다. 우리가 한 것을 뒤돌아보고 비판하는 대신, 진취적으로 프로세스를 개선하는데 모든 에너지를 쏟는다. 방어적인 태도는 줄어들고, 협동력은 향상된다.

• https://pitzcarraldo.medium.com/번역-잘-가요-스크럼-반가워요-칸반-e27d1db15699

모험 지향적인 사람 vs 확실성 지향인 사람

• https://maily.so/nenep/posts/mjz65e7vrwk

감독이 없는 팀이 잘 굴러가려면?

자본주의 위에 세워진 사회주의가 기존의 ceo들을 자리에서 물러아게 하면 혁명세력들이 그것을 차지하게 되는데 이들이 공장을 잘 운영할 수 있을까? 혁명가 중 우두머리에 의지하게 될까? 혁명가 중 우두머리를 세워놓되 견제를 쉽게 할 수 있게 하면 될까? 프로그래밍 팀에서 팀장이 없이 될까? 애자일이라는 프로젝트 진행 방법론에서도 이를 운영하는 애자일마스터가 존재하긴 한다 어느곳이든 다수의 의견을 모을 중심점은 있어야 하는가

사회주의를 보면 지나친 중앙통제는 실패한다 적절한 조절을 해야한다

Teamwork

Compare manager role in many field

Football coach

• 프로에서는 개인의 능력을 최대한 끌어내는것이 감독의 역할

물론 자신의 노하우를 알려주면서 더 배울 수 있지만 가르치는 역할은 아니다

• Movie director
• Software team leader
• My previous company pm

이태섭 신부님

믿음을 주면 능력 발휘를 잘 할 수 있다 이태섭 신부의 믿음이 의사가 되는 원동력이 되었다 구체적으로 해답을 주면 한 걸음을 갈 수 있지만 방향을 잡아주면 오래 갈 수 있다. 선문답 같이 느껴질 수 있지만.

바텀업 탑다운

https://occamsrazr.net/view/AboutRuleBasedAi

• 총 사령관이 각각의 병사가 얼마나 유능한지 알 수도 없고 알 필요도 없다?
• 개개의 병사가 전선의 배치를 고민할 필요 없다?
• 실제 전쟁에서 집중할 것은 명확하다
• 하지만 회사는 고객 만족과 주주이익실현을 만족해야하고 이는 고객에 대한 이해를 필요로 하고, 고객에 대한 이해는 사원에게서 나오는 아이디어가 효과적일 수 있다. 사원이어도 가능한게 아니라 다양한 생각을 모두 받아들이는게 필요하다
• 조직이 커지면 전체를 지휘하는 인원이 제한될 수 밖에 없을까
• 구글의 바텀업은 모듈화가 잘 되어있어서 가능한 것인가

리더의 덕목

피엘이 된다면?

커뮤니케이션이 문제 근데 이 회사에는 커뮤니케이션 능력을 키우기 위해 왔 그리고 지금 내가 가장 필요한게 컴ㅍ니케이션 능력 인훈님이 계신 상태에서 인수인계도 열악하지 않은 환경에서 가능할 거 같고 시기적으로도 괜찮다 부드럽게 풀어가는 능력이 부족하다 직책이 행동을 만들수도 있다 많이 보고 배울 수 있다 근데 내가 피엘한다고 했을 때 사람들이 어떤 우려를 할까 외부 일을 쳐낼건 쳐내고 잘해줄건 잘해줘야하는데 업무관리 보고 업무 할당

• 인훈님
  • 자료를 모아서 분석하는 단계를 잘 하심
  • 운영 레벨로 마무리하는 작업에 필요한 사항을 잘 정리해주심
  • 프레젠테이션
  • 소프트한 리딩
  • 팀원은 외부 상황을 전혀 모르도 되게 다 컷트해준다. 타부서 협력을 다 처리해준다

커리어 발전

• 리더로서의 마음가짐
• 기술적 깊이

리더로서의 마음가짐

• 비전 제시
• 같이 고민
• 이해관계자와의 소통
• 업무 할당
• 진행 상황 체크

제대로 가고 있다고 생각할 수 있게 해주는 것

팀장의 마음과 사업가의 마음, 프로덕트 매니저의 마음이 다른가

• 사업가는 팀장의 리더인가

퇴사를 말리는건 그 사람을 위한 것인가 나를 위한 것인가 목표가 다르다

팀의 구성원 모두의 성과, 생산성, 행복을 책임져야 한다 사업적 요구도 충족해야 한다 같은 일을 하는 사람에게 고차원적인 멘토링과 지원을 받아야 하는게 보통이다. 구글은 이 주제로 다양한 수업을 제공하며 성장하는 과정을 정기적으로 조언해줄 선임 멘토를 찾으라고 권합니다

내가 팀장이 되면 팀원들이 성과표를 낼 때 어떻게 하면 더 어필이 될지 조언을 해주고 싶다 근데 나는 아직 모르고 못받고 있다고 생각한다

아사나 태스크를 다 가져와서 어떤일을 했고 어떤 특징이 있었는지 지피티가 뽑아줄 수 있을까

다른 팀 레포를 접근할 수 있을까 공통적인 부분을 보고 다같이 쓸 수 있는 걸 만들수도 있잖아 Wms 레포를 하나 알고있는데 이건 kop-deploy에 있는걸까? 없다면 배포를 어떻게 하고 있지

회사의 전략적 요구를 파악하고 그 요구가 회사의 사명과 우선순위와 어떻게 연관되는지 알기

팀원들이 안전하다고 느끼게 해주기

판 깔아주기 시작 트리거 만들어주기 (다른팀이랑 이런거 한번 해볼래?)

조언을 구하는 사람이 자기 힘으로 문제를 해결하도록 도와주려 노력해야 한다. 문제를 다시 정의하고 탐구하도록 보조

촉매자가 된다고 생각하면 관리자라는 이름보다 와닿는거 같다

뭐 필요한거 없어요? 라고 면담 마지막에 질문하는거 좋은거 같다

Tech

Convention

회사별 룰

• 코딩 컨벤션
• 빌드룰
• 커밋룰
  • versionning
• 이슈관리룰
• 문서작성룰
• 핫픽스룰

Commit

with semantic versioning and changelog

툴을 이용해서 커밋을 하면 컨벤션 지키기도 쉽고 관리도 쉬워지겠다

• standard-version - versioning, changelog, commit
  • 커밋을 인터랙티브하게 했으면 좋겠는데 그냥 설정파일 기반으로 한다
• semantic-release - standard-version + publishing(release)
• git cz
  • need package.json file
  • echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc'
  • -a option 넣으니 된다
  • 이건 커밋만 해주고 체인지로그는 안바꿔준다
    • 체인지로그와 버저닝은 github actions에서 해주는게 좋겠다
• git-chglog
  • need config file
• release-it - versioning, changelog, publishing(release)

Conventional commits

feat() fix docs refactor style test chore

feat(lang): add korean language

BREAKING CHANGE: new release (options)

feat은 minor, fix는 patch, BREAKING CHANGE는 major를 변경하는 식이다.

https://www.conventionalcommits.org/ko/v1.0.0/

keep a changelog (change log convention)

Added Changed Deprecated Removed Fixed Security

https://keepachangelog.com/en/1.0.0/

semantic versioning

javascript 에서는 편의를 위한 라이브러리가 많이 있는데 golang에서도 각각 따로 구현되어있다 changelog를 자동 생성해주고 versioning을 도와주고 lint 해주고

• 푸시를 할 때 태그를 이용해서 버전을 직접 입력해줘야 하나?
  • default는 마지막 patch로 한다
  • CI로 설정해놓으면 commit 메시지를 읽고 자동 변경
  • 처음에 v0.0.0 태그와 latest 태그만 생성해준다
• changelog는 직접 입력하는건가?
  • commit message로 template을 정해서 적는다

keepachangelog template bumper

Code review

코드리뷰 어려운점

어떤 이슈를 해결하기 위한것인지 파악해야함 바뀐 파일들이 많으면 순서가 있으면 좋겠음 너무 많은 PR을 만들면 머지를 해야할게 많아져서 귀찮아져서 하나의 PR로 만드는데 이렇게 되면 변경사항이 너무 많아져서 놓치는 부분이 생길 수 밖에 없다

• 배포가 브랜치 단위라서 PR이 묶인다?

API document

Document

그 기술을 도입하기 위해 회의한 회의록이나 고려사항들을 볼 수 있을까

코드 파악하기

특정 부분을 돌려보고 디버깅 해보기 특정 부분을 수정하려면 어떻게해야할지 생각해보기

업무 할당 받으면

1. 일단 그림 그려보고 실행 목록 세워보기
   • 1-1. 레퍼런스 확인하기
2. 구현하기
   • 2-2. 문서화 확인
3. 커밋으로 작업 내용 공유

코드 파악 시 힘든 점

아키텍처가 일관성을 가지는게 제일 중요할 것 같다.

• 분기를 어디서 할지 결정하는게 시간이 걸린다.
• 기존 작업하던 대로 진행하고 싶은데, 그 참고할 데이터를 바로 못찾겠다

작업 흐름

• 최소의 실행 가능한 것만 있는 뼈대를 찾아서 가져온다
  • create-react-app이 그런 것을 한다.
  • 나는 node-react-docker-compose를 이용한다
  • cookiecutter라는 파이썬 툴도 있다.
• 필요한 기능과 리소스를 가져온다
• 배포하면서 확인한다

oss 메인테이너를 생각하면

다른 기여자들에게 응대하는 일이 많은 시간을 차지한다. 회사에서 다른 팀과 커뮤니케이션하는 것 이상으로 많은 메시지가 들어온다. 커뮤니케이션도 개발의 일부지만, 기존의 정보를 잘 활용해서 같은 질문에 계속 대답해야 하는 것은 줄이도록 하는 방법이 필요하다. Feedback Open_Source

gitlab communication Top Tips

1. 모든 소통은 영어로 한다. 1:1 일때도, 대화내용을 누군가에게 전달해야 할 때가 있다
2. 웬만하면 비동기로 대화를 한다(채팅, 이메일, PR, 이슈, 슬랙 알림). 채팅으로 인한 인터럽트 없이 일 할 수 있어야 한다.
3. 이슈에 대해 토의하거나, PR은 다른 무엇보다 중요하다. 만약 급한 응답이 필요하다면 이슈나 PR의 링크와 함께 챗을 보내고, 거기에 질문을 남겨라. 하지만 바로 응답하지는 않을 수도 있다. 슬랙에 대한 자세한 내용은 따로 정리돼있다.
4. 채팅 대신 이메일 쓰고 싶으면 써도 된다. 근데 내부용 이메일로 짧은 메시지만 작성해서 써라. 채팅할 때처럼
5. 너도 항상 일하고 있지는 않을거다. 근무 시간 외에 응답이 올거라는 기대도 없다.
6. 동기적 소통도 좋을 때가 있다. 하지만 동기적인 상황을 기본으로 놓지는 말자. 화상 통화를 하는게 바로 문제가 해결될 때가 있지만, 화상통화에 대한 가이드를 참조해라
7. 질문 많이 하는건 너무 좋다. 계속 질문해줘라. 그리고 많은 사람들이 볼 수 있게 이슈나 전체 대화방에 올려줘라. 1:1 챗이나 이메일 말고. 뭔가를 핸드북에서 찾다가 못찾겠으면 핸드북 링크와 함께 어떤 것을 못찾겠다는 것을 공유해줘라.
8. 누군가가 너에게 핸드북 링크를 주면 이는 답변이 이미 문서화 되어있었다는 것이다. 니가 답을 찾거나 완벽한 답변일 필요없다. 명확해지기 위해 편하게 질문해라.
9. 답변이 아직 문서화되지 않았으면, 즉시 PR 만들어서 핸드북에 올려줘라. 이건 질문에 답변해 준 사람이 그 대답 한 번으로 다른 비슷한 질문들에 대한 예가 될 수 있어서 좋다. PR은 도와줘서 고맙다고 말하기에 가장 좋은 수단이다.
10. 뭔가에 언급한게 있다면 링크도 같이 넣어줘라.
11. 모든 회사의 데이터는 공유 가능한 것이 기본이다. 개인 파일 만들어 쓰지 말고 이슈에 댓글 달아주는게 낫다.
12. 누군가 질문을 하면 마감시간을 알려주거나 답변을 해라. 'OK', '할게', '나중에 할게'는 아무런 도움이 안된다. 작은 일이면 2분 정도 들여서 해버려라. 다른 사람이 빨리 그걸 잊어버리게. 큰 일이라면 다시 알려주고 다른 방식을 찾아보게 해라.
13. 이슈에 참조로 누군가를 거는건 좋은데, 참조만으로는 누군가가 그걸 보지 않을 수 있다. 참조된 사람이 읽고 뭔가 더 액션을 안 취할 수 있다. 명확하게 @누구누구로 불러서 뭐가 필요한지 얘기해라
14. 내부적인 얘기라고 개별적인 그룹 만들어서 얘기하는걸 피해라.
    • 방해되고 (새 그룹에 새 메시지가 가니까)
    • 찾을 수 없고
    • 공유되지 않고 (사람을 추가할 수 없다)
    • 각 그룹마다 주제가 달라서 주제를 까먹는다.
    • 기록이 사라진다.
15. 고객 한 명을 위해서이더라도 채널 만드는 것은 좋다. 이름 형식을 지키고, 내부적인 룰을 지켜라.
16. 문맥이 많지 않도록 소통해라. 명료하게, gitlab은 전부 재택이고, 전 세계에 흩어져있다. 문맥에 대한 정보를 최대한 제공하고, 혼란을 피하자. 관련해서, 우리는 유비쿼터스 언어를 쓴다.
17. 개념을 이야기 할 때, 가설에 너무 기대는 것을 조심하자.

• 핸드북 부분, MR 부분 더 확인해보자

정보 불균형

3명이 같이 프로젝트를 진행하다가 1명이 없을 때 기능에 대한 얘기가 진행되면 그 한 명은 나머지 2명보다 정보가 차이가 나게 된다. 3명 뿐이라면 1명을 위해 최대한 내용을 전달하자는 노력을 하겠지만, 이게 회사 단위가 되면 정보 비대칭은 더 심해지고. 근데 애초에 회사에서는 전체 내용 중에 일부만 정리해서 전달한다.

라이브러리 찾기

개발자가 새로운 기능 구현 시 프로젝트 구조를 파악하면서 내가 구현해야하는 것에 필요한 라이브러리를 찾아서 쓴다는게 가능한가? X 불가. 해변에서 바늘찾기. 그래서 메타적으로 관리하는 페이지가 있어야 한다. 아니, 그런 관리 페이지가 있어도 찾기가 어려운데!

실수를 기회로

온보딩을 하면 기본적인 흐름을 파악 할 수는 있다. 근데 온보딩에도 빈 곳이 많을 수 밖에 없고, 애매한 부분을 만났을 때 상사에게 질문하는 것이 기본이겠지만, 일단 생각나는대로 해보고 그것을 다음 신입사원은 그런 고민을 안하도록 고치는 것이 더 현실적이고 나은 방법 같다. 넛지를 잘 만들던가, 온보딩을 강화하던가.

github workflow

github issues: ghi 로 확인 git commit - changelog - release: 한번에 가능 github pull request: cli로 가능 github actions: action-cli로 실시간 확인 가능

issue 확인하거나 등록하고, 커밋하고, 풀리퀘스트 올리면 액션 실행되고 액션 모니터링 하면서 확인되면 코드리뷰 신청 가는거 확인 코드리뷰 완료되면 머지까지 한 곳에서 확인