2009/06/30 13:06
Dev 노트
쉬운일이 아니다.. 거의 초등학생 학급회의 지도하는 수준으로 보면 된다. 시키는 대로밖에 못하는 컴퓨터와 대화하는 것에 익숙해진 나머지, 자기 생각이나 주장, 선호하는것 등을 가지고 있는 '사람'과는 대화하는 법을 잊어버린 존재들이 '개발자'다.
- 회의 시작 전에 발언권의 이동에 대해 꼭 주지시킨다.
개발자들은 자기가 아는 것에 대해서는 끼어들어 아는것을 이야기 하는 안좋은 습성이 보통 있다. 말하고 있는 사람이 도움이나 상세 발언을 요청할 때가 아니면 발언 하지 말 것과, 말하는 사람은 다른 이의 상세 설명이 필요할때 발언권을 잠시 양도하고 부연설명을 요청할 수 있다는 것을 알려줘야 한다. 단, 회의 진행자는 지금이 메인테마를 얘기하는 중인지, 중간에 끼어든 상세설명을 하고 있는 중인지를 항상 파악하고, 메인테마로 돌아갈수 있도록 계속 주의를 기울여야 한다.
- 회의성격/목적을 확실히 규정해야 한다.
그간 개발한 것을 발표하고 공유하기 위한 자리인지, 어떤 문제점을 해결하기 위한 대책을 수립하기 위한 자리인지, 예기치 못한 생황에 대한 시급한 우회로를 찾아야 하는 자리인지, 구현에 앞서 설계를 위한 자리인지, 구현방법에 대해 아이디어를 나눠보는 자리인지, 구현 방법의 디테일을 결정하기 위한 자리인지, 구현에 착수하기 앞서 결정한 전반적인 것을 리뷰하면서 공유하는 자리인지 등등등 ...
개발자는 이걸 명확히 말해 주지 않으면 항상 디테일의 구현에 집착하게 마련이다. 지금 그 디테일을 얘기하지 않아도 될 때에, 또는 지금 그 구현방법의 디테일을 얘기하고 있으면 안될때조차 그 디테일 밖에 생각해내지 못한다. 게다가 자꾸 잊어버린다. 회의 진행자는 미리 규정해 준 회의 성격을 중간중간 지속적으로 리마인드 시켜줘야 한다.
- '해 놓은 것'을 이야기 할 때에는 그에 대해 경청하고 나서, 질문한다.
진행자는 질문시간을 만들어 내기 위해 의미상 phase를 중간 중간 끊어준다. 이 '끊어줌'이 잦으면 좋지 않고 회의가 산으로 갈 수 있다. 그러나 안끊어주면 질문 타이밍을 놓쳐 질문 자체를 잊어버린다. 결국 청중의 리액션이나 피드백을 기대할 수 없는 한국스런 발표자리가 돼버린다.
- 개발자에게 질문할 때는 단어 선택이 중요하다.
따지거나 다른 방법을 제시하는 식의 느낌을 주면 안되는데.. 개발자끼리의 회의에선 보통 그런 느낌을 주게 되고, 여리고 순진한 우리의 개발자는 그런 느낌을 받으면 그 이면의 진의를 읽지 못하고 방어기제를 작동시킨다. 그러면 회의가 아니라 싸움이 된다. 아무것도 얻지 못하는 회의가 될 수 있다.
개발자가 이야기하고 있는 구현한/할 내용중 의아한 부분은(개발자 회의의 99%는 구현 단계에서 로직이나 솔루션의 선택의 문제에서 싸움이 벌어지는데), 어떤 문제점을 예상/발생했기에 그렇게 결정했는가 등 그 결정이 내려진 배경이나 결정하게된 동기를 묻는게 좋다. 개발자들끼리 회의하면 이게잘 안된다. 개발자는 '지금 내가 떠올리지 못하는 문제점을 예상했는가 본데, 그게 뭔지가 궁금해요. 어떤 동기로 그 방법을 택했어요?'라는 문장을 머릿속에 만들지 못한다. '어? 왜 그렇게 해야돼요?' 라고밖에 말 못한다. 정작 본인은 이 질문을 들었을때 '어? 왜 그딴식으로 밖에 못한겁니까?' 라고 이해하면서 그 사실을 모른다.
그걸 알게된 사람은 우리가 더이상 개발자라 부르지 않는다 - 매니저거나 구루거나..
- 위에 말한 성격이나 목적에서 벗어나는 내용을 위한 다른 회의를 잡는다.
그리고 회의를 취소한다. 안그러면 주제에서 벗어나는 걸 막을 길이 없다.
- 회의를 많이/자주 하지 않는다.
이게 가장 중요하다. 개발자는 회의를 많이 하면 안된다. 개발자 개개인에게 자기가 짠 코드블럭은 프라이버시의 영역이다. 코드 블럭 밖에서 코드 블럭을 블랙박스로 간주하고.. 그 내부를 시시콜콜 알려들면 안된다. 그 블랙박스를 다른 블랙박스에 붙여 조립하기 위한 회의는 필요하지만 그 이상은 절대 하면 안된다. 회의 자주하면 '그래서 원하는게 뭐야?' 라던가 '도대체 왜 이딴걸 만들라는거야?' 라면서 제대로 안짜온다.
