2018의 게시물 표시

성과 있는 기술 회의를 위해 의견을 제시할 때 유의할 점

기술 회의를 하는 건 일반적인 회의와 약간 다른 특성이 있는데 그건 아마도 상당 부분 물리적으로 혹은 논리적으로 검증 가능하기 때문일 것이다. 주장을 확인할 방법이 항상 있다고 생각할 수 있다. 회의에서 발언하는 사람들은 발언의 범주를 잘 구분할 필요가 있는데 흔히 자기 질문의 성격을 구분하지 않고 얘기하는 경우가 있다. 발언의 유형을 단순하게 나눠보자면 ‘질문(몰라서 묻는)’ ‘즉흥적 가설(문맥의 상황을 설명하거나 해결하기 위한)’ ‘제안(의사결정이나 부분 기술에 대한 의견 제시)’ ‘의사결정(잠정적 결론에 대한 기술)’ 그외 회의 진행을 돕기 위한 보완 설명 등으로 나눌 수 있겠다. 단순 질문은 명쾌해야 하며 진행을 돕는 보조 설명은 너무 늘어지면 안된다. 흔히 발생하는 문제는 질문과 가설, 제안을 혼돈하는 것과 가설, 제안과 의사결정을 혼돈하는 것이다. 몰라서 질문을 하면서 마치 의견 제안을 하는 듯이 토론을 요구하는 듯한 경우도 있고, 의견을 내면서 무조건 자기 의견을 결정하기 위한 의사결정의 안인 듯이 윽박지르기도 한다. 심지어 회의에 참석하는 것은 자기 의견을 관철하기 위한 수단으로 생각하는 경우도 있다. 토론할 때 잘못된 방식의 의견들로 다음 현상들을 볼 수 있다. 반복된 변명식 주장 단답형 답변 말 끊기 추임새식 내용없는 랩업 반복 타인의 권위를 근거로 한 주장 모두 깊이있는 개념적, 다면적 이해와 아이디어 공유를 방해하는 행위들이다. 많은 오류는 마음 속에 의견이 아니라 의사결정을 들고 있기 때문이다. 시작부터 Open-ended 원칙을 추구하지 않는 셈이다. 의견과 의사결정은 큰 차이가 있다. 권한의 문제이기도 하겠지만 그보다는 의견의 수준에 있다. 의견의 수준이 충분히 의사 결정할 만큼 풍부하고 해결책을 포함해야 의사결정의 단계에 이를 수 있다. 조급함이나 압박감은 더욱 문제를 악화시킨다. 좋은 의사결정 수준에 이른 의견

좋은 기술적 결론에 대한 판단 방법

오랜 SW 연구개발 경험 상 나름 이런 감(symptom)의 원칙 이 있다. 원래 시스템 소프트웨어란 건 wicked problem이어서 완벽한 정답이란 건 없고 enough한 시점에서 결론을 내려야 한다. 하지만, 좋은 답이란 것은 약간의 징후가 있다. '계속 고민하던 기술 문제의 직접적인 연장선에서 내려진 결론이라면 창의적인 결론이거나 멋진 결론이 되기는 어렵다. 계속 고민하던 논리의 옆쪽에서 툭 튀어나와 와르르 내려지는 결론이 언제나 아름다운 결론이다' 왜냐하면 직접적으로 추론되는 논리는 아무리 기술적이라 하더라도 누구나 쉽게 추론할 수 있는 것이며 새로운 혁신이 들어가기 어렵다. straightforward한 건 어려운 기술이라 하더라도 가치가 크지 않다. 그래서 마치 깊이 반복해서 고민하다 옆의 둑이 작은 바늘구멍에서 물이 새어 터지듯 나오는 아이디어가 훨씬 더 나은 답인 경우가 많다. 빅데이터 기술을 처음으로 본격적으로 다루다 보니 근 15년 정도 걸쳐 발전한 기술들을 3주만에 압축적으로 이해하려다 보니 어려움이 많았다. 이 기술들을 들여다보면 놀라운 경우가 많은데 상위 계층으로 갈수록 hype이 섞인 경우가 많다. 새로운 기술을 받아들일 때 나름 스스로 이해의 수준을 판단하는 잣대가 있는데 이것도 일종의 enough와 감이라고 할 수 있다. '새로운 기술은 그 장점의 이유 뿐만아니라 그 단점까지 볼 수 있을 때 비로소 이해했다고 할 수 있다. 장점만 보이면 그것은 이해한 게 아니라 그냥 시키는 대로 공부한 것이다.' 이것은 critical thinking의 문제이다. 엄밀한 사고란 critical point를 인지할 수 있어야 하고 이 문제를 해결할 때 다른 critical point를 생각할 수 있어야 한다. 이때 system thinking이 중요한데 system이란 layer 간의 혹은 전체와 부분 간의 관계를 유기적으로 파악하는 것이다. 예를 들어 소프트웨어를 시스템적으로 이해