U E D R , A S I H C RSS

프로그래밍잔치/정리

프로그래밍잔치 시작과 끝. 준비하는 사람 입장에서 생각해본 정리.

잘된점, 좋았던 점 이라 생각되는 것

  • 3일동안 그리 큰 돌발사태가 발생하지 않았다는 점. 하고자 기획한 주제들을 끝까지 진행할 수 있었다는 점.
  • 아는 사람들 위주의 행사여서, 부담감이 전보다 좀 적었다는점.
  • 뭘 해야 할지 망설일때 기댈 사람(하하..고문;)이 있었던 점.
  • 행사에 대해 '어떠어떠한 것이 필요하다' 에 대해 길을 해매지 않고 잘 진행되었다 생각.
  • 내용 자체 선정 - 나중에 다시 시도해봐도 좋은 주제들이 나온것 같다.

잘못되었다고 생각되는 점 & 대안의 생각

  • 기획단계에서 01, 02 등 다른 학번들이나 다른 사람 참여를 제대로 못시킨점. 이는 추후 재현가능성이 줄어든다.
  • 토론을 시키는중, 토론의 방향을 제대로 제시하지 못한점.
    -> Opening Question 의 중요. 토론을 시키기 전, 그 주제를 명확하게 표현해주는 '질문' 문장을 미리 3-4개정도 작성해온다.
  • 자칫, Facilitator 가 주제를 이끌고 나가버리는 경향.
    -> Opening Question 이 있다면 어느정도 해결가능하리라 생각. Facilitator 가 답을 유도하지 않되, 너무 다른 길로 걸어가지 않도록 하는 기준이 될 수 있으리라 생각.
  • 중간에 진행중 간간히 리듬이 끊어짐. 또는, Facilitator 가 질문만 던지고 답을 받은뒤에 제대로 정리를 하지 못함. 그래서 단발성 질/답으로 끝나는 경우 발생.
  • 중간중간 고문인 JuNe 에게 진행을 의존하는 모습을 보임.
    -> 준비한 리허설에 대해서. 리허설의 정도를 좀 더 많이 준비한다던지. 해당 주제에 대해 미리 공부해둠으로서 자신이 해당 주제를 접했을때의 소감 등에 대해서 이야기할 수 있도록.
  • 사람들의 지각 문제 -_-
    -> 스케줄 조정상 역시 완충시간이 필요. 길게는 40분 이상도 필요.
  • 행사의 길이 - 6시간 3일은 아무래도 사람들이 지쳐한다는 느낌을 많이 받았다.
    -> 일주일 1일 또는 2일 행사 식은 어떨까. 단, Now or Never! 에 대해서는 고려해야 할 사항인듯. 일주일중 2일 정도가 적당할듯. 아마 하지만.. 학기중엔 웬지 힘들것이라 생각.
  • Pair Programming 중 실천적인 구체적 방법을 미리 제시해주지 않음. - Pair 가 잘 이루어지지 않는 팀을 빨리 파악하고 빠른 대처/처방안을 주었더라면 하는 아쉬움이 든다.
    그랬다면 사람들이 Pair 를 더 적극적으로 실천해보지 않았을까.
    -> 진행 스케줄 중에 '5분 Pair Time', 'CRC Session Time' 등을 도입해주면, 사람들이 디자인이나 Pair 시 실천방법으로 도움을 받을 수 있으리라 생각한다.

--1002

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2009-05-27 07:09:19
Processing time 0.0977 sec