jongfeel
commented
3 years ago 프로젝트가 서쪽으로 간 까닭은
3월 부터 시작한 독서토론회에서 세번째 책으로 토론 진행 중인 <프로젝트가 서쪽으로 간 까닭은> 31 ~ 40 챕터 읽고 내용 정리하기
- 리듬
- 야근 예보
- 포커 게임
- 그릇된 품질 관문
- 테스트 전에 하는 테스트
- 사이다 하우스 규칙
- 말한 다음 써라
- 프로젝트 매춘부
- 대들보
- 옷 입는 이유
모임 내에서 사용하는 엑셀 스프레드 시트 비공개 페이지가 있지만 내용을 공개해서 적을 예정
-
리듬 애자일 스크럼의 정석을 얘기해 주는 것 같다. 사실 모든 팀원들이 이런 리듬에 맞춰서 작업을 해 준다면 좋은 일이겠지만, 중간 중간 틀어지는 일들이 있을 것이다.기술력이 뒤쳐진 팀원이나, 일정을 못맞추고 변명을 늘어놓는 팀원 등. 여기서 관리자가 리듬을 마음대로 정하고픈 유혹에 빠지면 안된다고 하는데 이런 일이 일어나면 어느 정도 개입은 필요하다고 본다.
-
야근 예보 조직문화의 공포가 이 내용의 핵심이라고 본다. 지금은 거의 없겠지만, 이 역시도 내가 경험했던 군대식 회사 문화에 기반한 눈치보기식 업무와 야근이라면 생산성은 불보듯 뻔하다. 보여주기식 야근이라면 당연히 감지해야할 부분인데도, 겉에서 보기에는 팀원들이 야근하니까 열심히 하고 있다는 판단은 2021년 IT와 소프트웨어 중심으로 돌아가는 세상에서는 어울리지 않는다고 본다.
-
포커 게임 외국의 사례라서 포커 게임인거고, 우리나라로 치면 워크샵에서 하는 팀별 활동 정도가 거의 최선이지 않을까 싶다. 물론 친한 사람들 끼리 커피 마시는 문화는 자연스럽지만 항상 친한 사람들끼리의 유대감 정도라, 전사적으로 친밀감을 갖기 위한 활동은 없어 보인다. 전체 회식?? 이런 유대감을 가져보는건 한국만의 문화인거 같기도 하다.어쨌든 평소에 대할일이 없는 회사 직원과의 유대감을 가지는 건, 책의 사례에서도 나오듯이 채용 과정에서 나중에 언젠가 좋은 협업의 기회로 발전할 수 있고, 나도 경험했기 때문에 좋은 방법이라고 본다.
-
그릇된 품질 관문 형식적인 QA에 대한 이야기, 수 많은 SI 프로젝트에서 경험했던 보여주기식 문서 작성도 여기에 포함되는 내용이 아닌가 싶다.일례로 설계 문서에 인터페이스 목록, 시퀀스 다이어그램 목록을 요구하는 결과 보고서 문서가 있는데 담당자는 IT 지식에 대해 없는 사람이다 보니 문서에 내용이 채워졌는지 아닌지에 대한 판단만 하지 그 내용이 올바른지에 대한 내용은 봐도 모르니까 하지 않는다. 그래서 정말 웃기게도 디자이너 출신 프로젝트 멤버가 이런 설계 문서를 대충 만들고 그려넣고 해도 통과되는 프로젝트가 있었다!!!
-
테스트 전에 하는 테스트 처음에 TDD 얘기인가? 하고 봤더니 소프트웨어 단위 테스트 얘기가 나온다. 그럼 아니구나 싶었는데, 테스트의 범위가 광범위해서 설계나 요구사항 분석 문서도 테스트를 한다는 내용이었다. 프로젝트 관리 방법 PMBOK에 얼핏 본거 같은데 요구사항 추가에 대한 변경 요청 검토 후 변경 프로세스는 있었어도 요구사항 테스트가 있었나? 한번 찾아보고 싶다.어쨌든 초반에 테스트(검증) 단계를 조금 거쳐본다면 숨어있는 문제를 조기에 발견할 수 있지 않나 싶다.
-
사이다 하우스 규칙 우리 회사에도 PMO라는 타이틀을 가진 분이 있다. 그리고 책에 언급한 것 처럼 애자일, 스크럼, 프로세스 변경 요청 검토 등 여러 가지 규칙을 만들고 하라고 얘기하고 문서도 꼼꼼하게 만들어 뒀다. 하지만 실무자들은 형식적으로 따르고 각자 팀마다, 그리고 개인마다 자신만의 방식으로 진행한다. 무시하는 건 아니지만, 그런 형식적인 프로젝트 수행 방식이 불필요하다고 느끼는 것이다. 위에서 부터 내려오는 지시가 아닌, 밑에서 부터 만들어져 나가는 문화라면 이런 일은 일어나지 않을 것이다. 너무 좋은 말이어서 인용해 본다. "하지만 규칙을 만드는 사람이 그리는 세상과 규칙을 따를 사람들이 사는 세상이 어느 정도 비슷해야 한다"
-
말한 다음 써라 기록을 하는 것은 중요하다. 하지만 쉽게 결정을 내릴 수 있는 일도 이메일 주고 받기로 시간이 걸리는 건 비효율적이다. 큰 규모의 분산 팀에서 문서로 기록하고 공유하는 것과 작은 팀에서 말로 해서 결정해서 움직이는 것이 각각 장단점이 있는데어느 정도 접점을 찾는 것이 중요한 것 같다.
-
프로젝트 매춘부 급박한 프로젝트 진행 상황에서, 지속적인 요청이 들어온다면 "아니오"라고 말할 용기, 얼마나 있을까? 수용하되, 현실을 보여주고 다시 우선순위 검토를 하는 방법이 최선인것 같은데 시키는 사람은 그걸 알려줘도 자기 일이 아니라고 생각하는게 문제일 것 같다. 책에서도 나오듯이 "잠시만 멈추고 쌀에서 왕겨를 가려낸다면 느려지는 원인이 왕겨가 너무 많아서라는 사실을 깨달으리라"를 업무 요청을 한 윗분에게 강하게 인지시켜 줘야 할까?
-
대들보 너무 유능한 사람과 함께 일하면 좋은데, 나중에 팀원도 그런 유능한 사람이 되려면 유능한 사람에게 배우려는 의지와 노력이 있어야 하고 그 사람이 다음 유능한 사람의 후보여야 한다. 유능한 사람이 그런 팀원들을 키울 기회를 주지 않고 자신의 유능함으로 업무를 모두 처리한다면 나중에 유능한 사람의 부재로 인해 큰 화를 당하게 된다는 좋은 깨달음을 주는 챕터!
-
옷 입는 이유 너무 개방적이거나 너무 폐쇄적이지 않은 그 어느 중간 정도의 팀 문화가 필요 자신의 그릇이 어느 정도 되는지 파악하고 정보를 수용하는 자세를 가져야 함
wjrmffldrhrl
Joseph-Cha
hi-hyein
https://meet.google.com/jyx-mxnq-kpk
참여 방법:
Assignees에 자신의 github 계정을 self로 추가 2시간 분량의 할 내용에 대해 댓글 작성 (최소 모임 시작 전까지) 빛의 속도 혹은 (주말, 휴일 포함) 최소 3일 내에 구글 캘린더 등록 메일 확인 모임 시간에 각자 개발 관련된 공부 진행
모임 끝난 후 공부한 내용 정리 & 링크 추가 => 최소 다음 모각코 전까지 확인 가능해야 함.
주의: 회사일 혹은 마감 기한 임박한 일 처리의 경우는 최대한 자제해 주세요. 주말 아침에 일하면 우울하니까요. ㅜㅜ
Youtube 음악 재생목록:
음악 취향
강요공유를 위해 재생목록을 공유합니다. 자유롭게 추가해 주세요. https://www.youtube.com/playlist?list=PLBFc2T4S7JnvZrV92zSlOfqeYHj7-qJfB&jct=hkFSXgrr2X-4yldTm5iMtpqnGcjKRQ강요공유를 위해 노력해 주세요