본문 바로가기

Lemon on Software

이터레이션의 중요성 되새기기

사실 어제 포스팅을 하고 나서
이터레이션에 대해서 이런저런 자료를 좀더 찾아보고 있었습니다.

일단 어제 사진조차 보여드리지 못한
'소멸 그래프'에 대한 내용은
퇴근 후 집에서 한번 적어보려구 하구요.

한 이터레이션이 끝나면 회고를 통해서 고객 의도에 대한 왜곡을 줄이는 것이 좋다



UX관련 글을 쓰시는 진영규님의 UXlog
재밌는 내용이 있더군요
개발에 해당하는 내용은 아니지만 
PIXAR의 애니메이션 디자인에 관한 이야기 입니다.

Pixar의 ‘스토리작가-아티스트-디벨로퍼’의 관계와 우리 회사의 ‘기획자-디자이너-엔지나어’와의 관계를 비교해 보는 것도 흥미로웠지만 가장 인상에 남는 것은 Iteration 디자인과 관련된 교훈이었습니다.
스토리작가가 머리를 쥐어짜 콘티를 완성해가면 스토리를 검토하는 과정에서 이 사람 저 사람이 마구 뜯어고쳐 결국 기존의 줄거리는 완전히 뒤집혀 버리고 다시 처음부터 이야기를 꾸려가야 한다면서 이런 말을 했습니다.

Remember, Storyboarding is actually Stor-re-boarding.

PIXAR의 스토리작가들과 기획자의 고충은 별반 다를바가 없나보군요 :)
해당 포스팅에서 가장 인상 깊은 구절은 마지막에 있습니다.

I want to fail as quickly as possible 
- Andrew Stanton (토이스토리, 벅스라이프, 니모를찾아서, Wall-E의 Director)
저는 딱 이 속담이 떠오르더군요
매도 먼저 맞는게 낫다
이터레이션을 통해서 빠른 실패를 경험하면
올바른 방향을 잡는데 더 적은 시간과 비용이 들어간다는 것을 
우리는 잊지 말아야 합니다. 

기껏 완성한 프로젝트가 고객의 요구와 전혀 딴판이라면...


사실 이터레이션 없이 최초 요구사항 도출 후
일방적으로 설계 및 개발을 진행하는 것이 한국 SI의 기본적인
절차라고 할 수도 있을 것 같습니다.
(적어도 제가 경험해본 범위에서는 그러합니다)
(제 짧은 경험을 일반화해서 기분 나쁘신 분이 있다면 죄송합니다만)
이런 경우 문제점은
잘못 분석된 요구사항으로 부터 도출된 태스크 덕분에
그 뒤 작업들까지 왜곡되고 일정의 지연을 피할 수 없게 된다는 점
이죠.

고객의 요구사항이 구불구불 변해도 그 길을 쫓아갈 수 있어야 합니다


하지만 체계적인 이터레이션을 통해서
지속적으로 왜곡 가능성을 줄여주면
고객의 의도에 따라서 물 흐르듯이 갈 수 있을껍니다.



[[이미지 출처]]
Yes24 , http://aviary.com/blog/posts/famous-works-of-art-simpsonized ,
http://kies.egloos.com/2964729