미신 / 고정관념 깨기#

이 사람이 정말 뛰어난 교육자인지 따져볼 필요가 있다. 통상적으로 선생이 학생에게 가르칠 때 30%만 전달된다는 것을 알아둘 필요가 있다. ==> 인지적 작업 분석을 통하여 극복 가능

뛰어난 선생은 존재하지 않는다.#

뛰어난 선생은 존재하지 않는다는 역설.

선생-학생 간의 쌍방향 피드백이 더 중요하다는 의미.

선생: 문제해결에 어떤 과정을 거치는지 자주 점검(선생 자체의 메타인지)
학생: 직접 선생의 말을 관찰하고 질문을 던지고 분석 (학생도 메타인지 )
???

'나홀로 전문가'에 대한 미신#

전문가라고 한다면 누구를 생각하시나요? ==> 혼자서 다 하려고 하는, 혼자서 완벽한 코드를 짜려고 하는 사람. ==> Nonono!

지식의 양보다는 신뢰와 관성에 신경써야 한다. 내가 짠 코드를 누가 수정할 때에 '이게 합리적이야?'라는 의심을 하게 되고 악의적으로 보일 수도 있다. 내 방법론이나 내 코드를 강요하는 경우에도 마찬가지. 경력을 우선시하여 거의 신봉자처럼 행동한다면 팀웍이 깨질 수 있다는거.

음의 생산성을 가지고 있는 잘못된 전문가가 존재한다. "앞으로 이 분과 프로젝트를 진행하고 싶나요?"라는 설문을 주기적으로 받게 될 것이다...................................................

사회적인 측면에서, 인터랙션이 좋은 사람을 전문가라고 부른다. => 사회적 자본 & 사회적 기술을 매우 중요하게 여겨야

마이크로인터랙션(스몰토크)을 복기하는 일을 해봐라. 간략한 대화를 셀프 회고해보고, '그랬을 때 기분이 어땠나'를 동료에게 물어보는 것도 좋고. 타산지석의 마인드로 해볼 수도 있고. - - 영향력 찐며들기. - 피드백 주고받기 - 가르고 배우치기 - 위임하기 - 새로운 방식을 도입하는 데엔 언제나 사회적 비용이 든다. 수많은 사람들의 일하는 방식, 습관, 툴 사용방식 등이 모두 다 변한다는 것이다. 전문가가 변화를 주도하는 데 있어서 책임감을 가지고 토론을 해야 한다.

따라서, 전문가는 경력/직급/지식보다 사회적 기술을 중요시 하는 사람.

혹시 내가..?#

내 만다라트가 개발만 잘 하면 되지 식으로 가득 차 있다면??? 사회적 기술이 받쳐져 있지 않는다면??? ==> 소셜 스킬에 대하여 밸런스를 두어야 한다.

[MY THOUGHTS]
대학교 내에서 진행하는 모든 프로젝트들을 되돌아보면 나는 항상 특정 임무를 선택한 뒤에 회의나 여러 의사소통을 배제한 채 나만의 구현에 몰두하는 경우가 다반사였다. 그래서 동료들도 내 편의 봐주기 위해서 회의 참석도 몇 번은 빼주기도 하고, 심지어는 예상보다 늦어지자 기다려주기까지 했다. 그렇게 결과물을 만들어내면 그제서야 다른 컴포넌트들과 연결하고 그랬는데... 🤔

린스타트업과 분업#

린스타트업을 조사해오랬더니 한 사람은 '린'을 조사하고, 다른 한 사람은 '스타트업'을 조사해왔다. => NO

우리는 자꾸 분업하려고만 한다. 아이러니 하게도 프로젝트 초기에는 대상에 대한 지식이 없기 때문에 일을 나눌 수 없다.

뇌에 과부화가 걸려 종결욕구가 작용하기 때문에 자꾸 마무리/정리하고 싶어한다. 초반에 일을 빨리 나누려고 하지만 사실, 협력과 협업을 중요시 하지만 일단 나눠서 고민해보고 돌아와서 합쳐보자. 라는 식으로 프로젝트 초기부터 말아먹는 경우가 발생한다.

초반일수록 설계에 굉장히 많은 에너지를 써야 한다. 초반일수록 인터랙션에 더욱 많은 시간을 쓰고 세부적으로 정의하여야 한다.

동상이몽인 상태에서 구현하면 당연히 동상이몽 프로젝트가 나오겠지?

[?] 안녕하세요! 2023-05-22 회고특강에서 분업에 대한 내용을 이해하던 중 의문점이 드는 게 있어서 질문 올립니다. 책 "클린 아키텍처"에서는 컴포넌트 간의 분리를 매우 중요시하고 팀 사이에 간섭을 최소화 하는 것을 목표로 삼는다고 합니다. 저는 이것을 '분업의 효율화'라고 이해했는데, 지난주 수업시간과 배운 내용과 충돌이 있는 것 같습니다. 예를 들어 UI팀과 DB팀이 한 자리에 모이는 것보다 경계를 사이에 두어 각자 맡은 몫에 최선을 다하는 방식이 바람직할 거라고 생각이 듭니다. 선생님의 의견이 궁금합니다! 물론 어느 방법론이 최고인지를 따지는 광신도적 질문이 아님을 알립니다. ^l0ieut
20230522 김충환 회고강사특강 질문
안녕하세요! 2023-05-22 회고특강에서 분업에 대한 내용을 이해하던 중 의문점이 드는 게 있어서 질문 올립니다. 책 "클린 아키텍처"에서는 컴포넌트 간의 분리를 매우 중요시하고 팀 사이에 간섭을 최소화 하는 것을 목표로 삼는다고 합니다. 저는 이것을 '분업의 효율화'라고 이해했는데, 수업시간과 배운 내용과 충돌이 있는 것 같습니다. 예를 들어 UI팀과 DB팀이 한 자리에 모이는 것보다 경계를 사이에 두어 각자 맡은 몫에 최선을 다하는 방식이 바람직할 거라고 생각이 듭니다. 선생님의 의견이 궁금합니다! 물론 어느 방법론이 최고인지를 따지는 광신도적 질문이 아님을 알립니다. 메시지를 작성하다보니 문득 프로젝트가 설계 전 후로 나뉘어 양상이 바뀐다는 것을 알게 된 것 같습니다. 현재까지 제가 이해한 바로는
프로젝트 초반부, 사람들이 부서 구분없이 한데모여 문제해결을 위한 설계도를 작성한다. 이때 요구사항을 컴포넌트, 유스케이스 단위로 적절하게 분할한다. ==> 협업
설계초안이 완성되면, 그에 따라 구성원들이 팀을 꾸리게 되어 흩어진다. 팀 간에 의사소통은 이제부터 문서로 진행되며, 중대한 변경사항이 아닌 이상 서로 독립적인 속도로 발전한다. ==> 분업
요구사항이 변경되어 핵심 비즈니스 로직에 수정이 가해질 경우, 밀접한 관련이 있는 컴포넌트(eg, DB스키마)에는 영향이 가겠지만, 구체적인 세부사항(eg, UI/UX, REST api)은 영향을 아예 받지 않거나 느리게 전파된다. ==> 독립

두서없이 작성한 것 같은데 잘 전달이 되었기를 바랍니다... 선생님의 현업 경험에 기반한 현실적인 조언과 피드백 부탁드립니다.

조엘 온 소프트웨어 -- 프로젝트 성공실패에 가장 큰 영향을 미치는 것은?#

조엘 테스트: 우리 회사의 개발조직이 몇 점 짜리 조직인가?

소프트웨어 개발 비용 1. 도구 1. 컴퓨터, 모니터 => HW 2. 디버거, 버그트래커, IDE => SW 3. 하향/구조적 개발 기법 => METHOD 2. 사람 1. 사람들의 능력과 경험 3. 시스템 1. 제품의 복잡도, 신뢰성, DB크기, 타겟 4. 관리 1. 사람을 배정하고 작업분배를 조정하고 위임. 작업조건이나 환경을 개선, 리소스 마련, 리스크 캐치하여 적절한 조치 취하는 것, 설계가 컨펌이 되도록 만드는 프로세스.

프로젝트 성공 실패에 가장 큰 영향을 미치는 것은 무엇일까? 1. 도구 => 3배 영향 2. 사람 ====> 11배 영향 3. 시스템 ===========> 26배 영향 4. 관리 ======================================> 64배 영향

아하! 관리자의 역할이 가장 중요하구나! 하지만 우리는 측정하기 쉬운 것에 치중하려고 한다. 소셜스킬같은 것은 측정하기가 쉽지 않죠. 주관적이기도 하고. 정작 관리자는 본인관리를 안하는 경우가 많다!

협력1 - 역지사지#

협력을 통한 추상화#

모든 팀원의 역량의 정도는 다르다. 기대하는 역량의 총합은 음의 상성 때문에 그에 못 미치는 경우도 있고, 전체의 합보다 더 높은 퍼포먼스를 내기도 한다. 여기에서 중요한 것은 시각적인 추상화.

동상이몽 줄이기
복잡한 문제를 풀기 위한 시각적 추상화.

소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특징지을 수 있다.

컨센서스 (동질화)를 일어내고, 추진력을 얻어내고 시각화 하기 위한 노력. 사실 1일차에 했던 미션, 비전, 골도 업무 우선순위를 정하기 위한 추상화라는것.

대화의 질을 높이기 위해 우리는 어떤 일을 해야 하는가?

짝 프로그래밍: 대화를 많이 함. 코드리뷰와 구체화, 검증. 추(직접적인 경험)측(간접적인 사고)을 빈번하게 다룬다. 내가 짠 코딩을 과정을 동영상으로 촬영하기도 한다. 우리는 생각하는 사고의 과정을 보여준다면, "이 친구가 왜 이렇게 생각하는지"도 생각할 수 있게, 질적인 추상화가 가능해진다.
익스트림 프로그래밍. 프로그래밍 각 단계에 대하여 구조화 시킬 수 있다는거.
위키, 스택오버플로. => 기술이 만들어낼 사회 구조의 변화와 기술이 이끌어낼 사람들 간의 모든 대화가 퇴적되어 있다.

실습할 때 소모임 열어서 화면을 다 띄워! 이러면 얼마나 고민이 다 저시기 될까

신뢰를 깎는 공유, 신뢰를 쌓는 공유#

신뢰자산이 높은 그룹은 커뮤니케이션 효율이나 생산성이 높다. 점수화도 가능하고 이유도 설명 가능하다.

투명성과 공유, 인터랙션
1. 상대가 자신이 가진 생각을 솔직히 말해줄 거라는 신뢰도. 공감대.
앞으로 이 동료와 얼마나 같이 일하고 싶으신가요? (Peer to Peer 평가)
1. 신뢰가 떨어지는 경우
  1. 하나의 디자인을 만들고 하나를 공유
  2. 여러개의 디자인을 만들고 베스트를 공유
2. 신뢰가 증가하는 경우
  1. 여러개의 디자인을 만들고 모두를 공유 (복수공유)

복수공유?

여러개의 시안을 가지고 이야기하기 좋다. 듣느 사람도 상대적으로 좋다 나쁘다를 생각하기 편하다.
상호대화빈도가 유의미하게 증가한다. 질적으로 다르다는 거임. 일방적인 대화보다는 동료와의 상호성으로 밸런스가 적절하게 섞인다는거.
복수공유를 한 그룹이 개선에 적극적으로 참여한다. 실제로 출시까지 했을 때에 전문가 평가나 노출당 클릭률도 더 좋아진다.
복수의 프로토타이핑으로, 팀의 결속감이 높아짐.
[?] 상대가 공유를 했을때 피드백은 어떤식으로 주어야 한는지 궁금합니다!
- 왜 그렇게 생각했는지, 감정과 함께 피드백하는 것이 중요합니다. 뒤에 시간에 제대로 피드백하는 방법에 대한 설명도 있을거야.

객관성의 주관성, 객관성도 미신이다#

what is quality?

누군가에겐 가치가 되는것.
누군가에겐 결함이 된다.

결국 결정하는 사람 마음이기 때문에 제품 품질은 객관적일 수가 없다. 마음에 안 들면 어떤 객관적 자료를 가져다 주어도 설득할 수 없음. 그 반대도 마찬가지.

따라서, 직관, 감정적인 부분이 배제될 수 없다는 것이다, 의사결정에. 설득의 심리학을 읽은사람이 있겠지만,

내가 설득하고 싶은 사람을 자주 만나서 신뢰를 쌓아야 한다. 어떤 가치를 중요하게 생각하는지, 어떤 사고방식을 선호하는지를 알아야 한다.

자료에서 출발하는 것이 아니다. 상대방의 주관에서 출발하는 것이다.

상대방의 성향과 기질을 아는것이 진짜로 필요할지도?#

KAI: 성향분석법: Innovation형, Adaption형 사람과 커뮤니케이션 하는것이 아주 다르다.
MBTI: 이성적 판단 + 큰그림을 그리는 NT형, 사람들과의 관계에 관심이 많은 NF형, 구체적이며 체계적인 SJ형, 모험을 좋아하고 닥친 문제를 좋아하는 SP형

평상시에 스몰토크하는 것이 되게 좋은 방법이라고 생각함.

설득을 위해 객관적 자료를 모으는 시간도 필요하지만 그거 이상으로 상대를 이해하는데 많은 노력을 할애할 필요가 있다.

개발자가 코칭을 익혀야 할 이유?#

내가 사수가 되어 의사소통, 멘토링을 해야하는 상황을 가정해보자.

동료가 질문을 덜 한다면? 실수를 감추려 한다면?
- 내 커뮤니케이션 능력에 문제가 있는지, 신뢰자산을 깎아먹는 분위기가 있는지 파악필요
공감하고 이해하려는 대화를 한다면?
- 저는 모든 사람이 좋은 면에서 정치적이라고 생각하거든요
- 전문가는 상황파악을 먼저 하지만 초보자는 뭘 할지부터 정하려고 한다는 차이 (아 저거 저렇게 하면 안되는데 보다는 저 사람이 왜 저렇게 시도했지)
행동을 유도하는 대화를 한다면?
- 상대가 자기주도적으로 공부하고 스스로 책임을 지고 내가 더 잘해야 되겠네, 사적인 대화 증가, 관계가 더 좋아짐.

신입때부터 어떻게 코칭해야할지 알아야만 한다. 코치는 감독도, 선수도 아니다. 동료의 에너지를 높여주고 상태를 확인해주고 지지해주고 다독여주는 사람.

찐며들기#

혼자 잘하는 건 NONO

SOFT SKILL에 대하여 이야기 나누었고

시각적 추상화가 인간의 능력이라는거. 최소 두 사람이 자주 대화하는것. 다양한 케이스를 복수공유하고.

신뢰할 수 있는 조직으로 가는 문화를 가는 과정에 대하여 이야기 나누었다.

상대가 받아들일 수 없는게 많은 것을 차지하기 때문에 상대입장을 이해하는것이 중요.

상대의 주관적인 직관/감정을 이해하기 위한 성향파악

신입도 코칭능력을 키워야 한다는것도 이야기 나누었다.

잘 정의된/되지 않은 문제#

우리가 업무에서 만나는 대다수의 문제는 잘 정의되지 않은 문제.

잘 정의된 문제는 일반적으로 계약직/아르바이트를 선호하는 것 같더라.
잘 정의되지 않은 문제는 문제가 뭔지 모르는게 문제. 설계를 직접 해야만 하는 경우.
- 문제를 맞닥뜨리는 것이 먼저가 아니라 사례(현상)를 먼저 맞닥뜨린다. EX) 코로나 환자수가 늘고있어!
- 가장 중요한 현상이 무엇인지 정의해야한다.
탑다운과 버텀업도 사실 미신이다. => 전문가일수록 두개를 능동적으로 선택하거나 변경
- 상호보완적이지, 택일이 아니다.
- 비전문가일수록 기존의 일정, 계획에 집착한다. 이 틀을 깨고 싶어하지 않는다.
- 문제가 정의되어있지 않은데 문제를 정의를 해버려 우선순위나 스펙이 바뀌는 것에 대하여 스트레스를 받는다. 왜냐면 그 앞전에 개발해 둔 것이 많은데 유연성을 확보해놓지 못했기 때문.
- 전문가일수록 늘 전체적으로 손을 대고 바꿔나간다. (HOW?) 오지랖을 좀 떨어야 한다.
  - 도메인 어휘(사업개발쪽이라면 금전적인 부분/사용자 규모라던가, 기획쪽에서는 사용자피드백/이탈율이라던가)를 사용하여 코드를 설명할 수 있어야 한다. 추상과 구체(구상)의 차원을 자주 오가는 상호참조전략...을 취한다.

단계가 아니라 삼투압#

문제와 해결책이 모두 불확실한 경우 => 단계적으로 문제를 해결하는 것이 오히려 더 낮은 품질로 갈 수 있다는 것을 알아야 한다.

전략을 세우고 -> 범위를 산정하고 -> 구조를 짠 다음 -> 뼈대를 만들어 -> 표면까지 만드는 단계로 만들게 된다면... 너무 이상적이다. 끊임없이 요구사항이 변경되고 기술적 사항이 변경외는데 마지막 단계까지 왔다손 치면 다시 처음부터 돌아가야 하는 대참사가 일어난다.

누군가 질문하면 모두가 피드백을 하여 가치있는 정보를 공유해야 한다.
서로서로가 스며들어 있어 정보의 갭을 최소화 해야 한다. ====> 스크럼
- 어제 했던 일에 대하여 이야기를 하는 행위.
- 또는 내부테스팅, 알파/베타 테스트를 거침으로써 진짜 중요한 문제점 (커스토머 밸류 프로피전시) (핵심가치)가 명문화가 되기 전까지는 반드시 빠르게 갈아엎을 수 있게 유연하게 구조를 마련하여야 한다.

전문가 팀이 실패하는 이유#

전문가/비전문가, 협력 개입과 비개입으로 4사분면을 나눈 팀에게 문제를 부여해주었다. 각자 잘 하는게 무엇인지, 골이 무엇인지 컨센서스를 만드는 것을 협력개입이라고 부른다. - 비전문가 비협력 => -10 - 비전문가 협력개입 => 10 - 전문가 비협력 => -70 !!!!!!!!!!!!!! - 방안이 중구남방으로 나오기 때문에 최악의 결론이 도출되었다. - 전문가 협력개입 => 95

결론: 전문가팀이 협업하지 않고 분업하면 오히려 성과가 떨어질 수도 있다.

소셜 스킬이 뛰어난 코치가 있으면 시너지가 높아질 수도 있다.

다시 삼투압, 쾌속 학습팀#

모든 전문가는 자기네 추상화 단계를 가지고 있다. 그런데 추상화 단계가 동질성이 없으면 동상이몽으로 프로젝트가 진행되는 것임.

결국, 다시 돌아와서, 프로젝트 개발비용의 최고 가성비는 협업환경과 관리에 있다는 것이다.

리더의 학습환경 조성

팀원을 뽑을 때, 상호 협동적인지, 협업을 잘 하는지, 새롭고 애매한 상황을 즐기는지 (디자이너, 개발자, 기획자 한꺼번에 놓고 다같이 면접을 한다.), 상사에게 의견을 자신있게 제안하는지
새로운 상황이 주어졌을 때, 개인적 도전이 아니라, 조직적 도전으로 받아들이는지 (함께 일하는 방법을 도입)
심리적 안정감은 100번 강조해도 지나치지 않는다.
- 실패에 관대, 인정하는 데에 부담을 느끼지 않음.
- 새로운 제안과 시도에 열려있어야 하고,
- 팀 퍼포먼스를 높이기 위해 새로운 방식으로 일해볼까 (작은것부터, 익스텐션을 만든다거나)
- 그것을 모두가 다같이 공유한다.
- 학습과 실행이 동시에 이루어진다. 이렇게 해봐야지 한 것을 공유하고 학습 자체가 중대한 목표로 받아들인다.
- 리더는 큰 변화가 왜 중요한지, 미션과 비전에 빗대어 변화의 중요성이나 도파민, 즐거움 등을 강조.
- 전략 범위 구조 뼈대 표면 이 다섯가지 페이즈를 빠르게 넘나들 수 있어야 한다.

쾌속 학습팀의 시작

자신의 학습환경 만들기가 시작
1. 브라우저/IDE/OS 커스터마이징
개별 기술 이상으로 일하는 방식에 대하여 실험. 그대로 굳어지는 일 없게 이렇게도 실험해보고, 동료가 일하는 방식에 관심을 가지고 따라해보고. 중요한 건, 실험에 실패는 없다
학습과 일을 분리하지 말고 동체로 만들자.
1. 진정한 실행은 학습을 수반하기 때문! 그래서 너무 자신있는 부분은 빠르게 끝내거나 난이도를 높이거나. 야생학습을 계속 하시라는거죠.
지금 당장 하지 않는다면 실행확률이 50% 이하로 떨어진다.
1. 30분만 업무개선에 시간을 써 봅시다.

작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다.

하루하루 돌아가는 작은 프로그램들을 통해 학습해 나가는 느낌을 받아가라.

나와 마음에 맞는 공동체를 구축하시오. 동지를 찾아보아라. 역시 나부터 바뀌지 않으면 아무도 바뀌지 않습니다.

다음주에는...#

만다라트를 또다시 업데이트 해주세요. 지금 당장 하지 않는다면 안한다.