詩, 논문, 코드, 기타 무엇이건 개선하는 "저자 워크숍"
IBM 디벨로퍼웍스 기사를 썼습니다. 저자 워크숍입니다.

시나 코드, 논문을 쓰는 것은 매우 개인적인 작업으로 생각되기 마련입니다만, "저자 워크숍"은 이 작업을 공동의 노력을 통해 개선하는 방법을 보여줍니다.

저자 워크숍은 정말 적용 범위가 넓습니다.

제가 쓴 소개 글이 IT 분야 사람들에게만 읽힌다면 너무 아까운 일이라고 생각합니다. IT랑 전혀 관련이 없는 분들도 한번 들어가서 읽어보시기를 꼭 권합니다. 어떤 저작물을 어떻게든 개선하는 것에 관심이 있다면 말이죠. (특히 선생님들은 꼬옥!)

--김창준
by 애자일컨설팅 | 2008/12/30 12:50 | 트랙백(2) | 덧글(4)
트랙백 주소 : http://agile.egloos.com/tb/4778730
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from ironyjk's me.. at 2008/12/31 22:31

제목 : iron의 느낌
“詩, 논문, 코드, 기타 무엇이건 개선하는 ”저자 워크숍 http://agile.egloos.com/4778730 ...more

Tracked from ironyjk's me.. at 2008/12/31 22:31

제목 : iron의 생각
詩, 논문, 코드, 기타 무엇이건 개선하는 '저자 워크숍'...more

Commented by djccuri at 2008/12/30 15:41
잘 읽었습니다. 학교 다닐때 시창작 학회를 몇년간 운영했는데(전공이 좀 그런쪽이여서) 소개해주신 내용과 비슷한 방식으로 합평회를 진행했었습니다. 그때 좀더 체계화했었다면 더 좋은 성과가 있었을 것 같다는 후회가 조금 드는 군요. 뭐 오래된 얘기긴 하지만요. 하지만 문제는 긍정적 피드백을 한다는 것이 생각보다 매우 어려웠습니다. 치기어린 시절이라 그럴지는 몰라도 잘못된 것을 지적하고 비판하는 것에는 매우 능숙했으나 장점을 찾아내는 것은 어쩐지 미숙하고 불편하다는 생각이 들었었습니다.
소개해주신 저자 워크숍의 긍정정 피드백을 우선시하는 방식 등을 보니 많은 생각이 들게 되었습니다. 단점을 보완하는 것 보다 장점을 극대화 하는 것이 아무래도 창조적이라는 생각도 들었구요.
늘 좋은 글 감사드립니다. 많이 배우고 있어요^^


Commented by 니오 at 2008/12/31 10:57
2008년 잘 마무리 하시고 새해 福 많이 받으세요. ^^
Commented by 최승준 at 2009/01/06 18:48
큰 도움 받았습니다. 요즘 유치원에서 정말 잘 활용하고 교사들로부터도 저자워크샵에 대한 긍정적인 피드백을 받고 있습니다. 스스로 그리고 함께 성장하는 느낌을 받는 다는 이야기가 많았고, 스테레오타입적인 유치원 업무에서 정말 한 걸음 더 나아가서 뿌듯해 하는 모습을 보면서 저도 굉장히 행복해 하고 있습니다. 이 방법을 사용해서 겨울방학 업무도 억지로 해야하는 일이 아니라 즐겁게 일하고 함께 학습공동체를 만들어가는 경험을 하고 있습니다. 다시 한번 감사드려요~
Commented by orchistro at 2009/06/03 00:30
참으로 잘 읽었습니다.

근무하는 회사에서 저는 개발자로 일하고 있습니다. 회사의 개발 프로세스 중에 "리뷰"라는 것이 있습니다. 개발 담당자가 개발 진행 단계별로 산출물을 내어서 시니어와 팀원들과 함께 리뷰를 하는 과정입니다.

그런데 저는 그 "리뷰"가 왜인지 개발자가 일한 결과물을 다른 팀원의 "검사"를 받는 과정같다는 느낌을 떨쳐버릴 수 없었습니다. 제가 생각하는 이상적인 리뷰하는 자리는 그 결과물을 가지고 팀원들과 함께 토의하고 문제점이 발견되지 않는지 검증해 보고, 개선책을 마련하는 매우 건설적인 자리여야 하는데, 그렇지 못한 경우가 더 많았기 때문입니다.

제가 관찰하고 느낀 바로는 사내에서 리뷰가 진행되는 양상은 크게 몇가지 유형으로 나뉘는 것 같았습니다.
먼저, 리뷰어들이 자신의 업무로 인해 바빠서 리뷰하는 내용에 집중하지 못한 경우. 둘째, 리뷰(발표)하는 내용이 모두의 마음에 든 경우. 셋째, 발표자(reviewee)와 리뷰어들간에 이견이 발생한 경우의 세가지 정도로 분류할 수 있겠네요. 그 중 첫번째 리뷰는 시간낭비이기 때문에, 두번째 리뷰도 리뷰 대상이 되는 결과물이 모두에게 만족스럽다는 것을 확인한 것 이외에는 수확이 없고 큰 문제도 없어 보이므로 이야기에서 제외하겠습니다.

제가 문제라고 느꼈던 것은 바로 세번째 케이스입니다. 발표자와 리뷰어들간에 의견이 다를 경우 때때로 격렬한 의견충돌부터 시작해서 난상토론으로 발전해 나가다가 결국에는 아무런 결론도 없이 끝나는 과정이 반복되는 것을 관찰할 수 있었습니다. 게다가 참석자들간에는 그로 인해 서로 감정이 상할 때가 많았고, 이같은 결과가 팀 전체의 사기 저하로 이어진 경우도 종종 있었습니다.

때마침 오늘도 리뷰를 하나 했었는데요, 결과적으로는 처음 리뷰 대상이 되었던 "저작물"보다 나은 저작물로 가는 아이디어들을 많이 얻을 수 있었고, 합리적인 개선안이 나온 자리였지만, 그 과정에서 리뷰어와 개발자간에 언성이 높아지기도 하는 상황이 있었고, 개발자는 겉으로 표현은 안했지만 속으로 상한 기분을 삭이고, 리뷰어도 결론은 좋은 방향으로 나왔지만 뭔가 석연찮은 기분이 된 리뷰였던 것 같았습니다.
그래서 일전에 RSS로 보았던 김창준님의 Writer's workshop과 관련한 글이 생각나서 다시 한번 찾아와서 읽었습니다. (저자의 홈페이지에서 pdf 도 받을 수 있군요 :-) final typset version 이지만요 ^^)

그 글에서 제안한 방법을 회사의 리뷰 과정에 도입하기 위해서는 여러가지 일이 필요하겠더군요. 먼저, 개발자가 자신의 산출물을 보다 친절한 언어로 자세히 기술하는 일이 선행되어야 할 것 같고요, 리뷰어로 지정된 사람들은 또한 리뷰할 문서를 회의를 하기 전에(리뷰를 갖기 전에) 미리 정독해 보는 수고가 필요하겠네요. 물론, 당연(^^)히 해야 하는 일이지만 다들 각자의 일정에 바쁘다 보니 시간을 내기 힘든 일이죠. 아무튼, 여력이 된다면 꼭 팀내에 이와 같은 문화(라고 할 만한가요? ^^)를 시험삼이 도입해 보아야 할 것 같다는 생각이 듭니다. 그래야 "리뷰"가 정말로 건설적인 진짜 "리뷰"가 될 것 같으니까요. ^^

좋은 정보 감사합니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >


Site Meter