Clean Code that Works.

예전부터 UX에도 관심이 있던 터라..
읽는 중 @_@.
아래 반문은 기억해 뒀다가 나중에 말도 안되는 일정을 요구할 경우에 써먹어야겠다.
디자인 단계 뿐만 아니라 개발 단계에서도 적용할 수 있으니...

개발하다보면 일단 개발 부터 진행 할려고 하는데.. 나도 그렇고..
이를 지양 하고 디자인 프로세스를 잘 마무리 하고, 그 기간에 개발을 하고 싶으면 다양한 프로토타이핑으로 개발 단계를 준비하는 것으로 대체해야지.

start.

실무에서 프로젝트를 진행할 때 자주 접할 수 있는 상황이 있다. 이런 상황에서 오가는 말을 살펴보는 것으로 이 장을 마무리 할려고 한다.

이 제안은 무척 훌륭합니다. 이상적인 세계에서는 아주 좋은 방법이에요. 하지만 현실에서는 그렇지 않죠. 마감일도 맞춰야 하고 비용도 제한돼 있으니까요. 이런 프로세스를 일일이 거치기에는 일단 시간과 비용이 허락하질 않아요. 현실에서는 이상적인 것만 추구하는 건 불가능 합니다. '적당히 good enouth' 괜찮은 방법을 차용할 수밖에 없어요.


이 말을 들으면 나는 거의 항상 아래와 같은 두 가지 반문으로 응답한다.

제대로 된 기획과 디자인 방법을 적용할 만한 비용이 없다는 건 이해할 수 없어요. 제품 출시가 늦어지는 데 들어가는 비용은 항상 충당하고 있잖아요? 엉터리 기획과 디자인, 점검 방법 덕분에 쏟아지는 수많은 오류를 수정하는 데 들어가는 비용은 어디서 나오는 거죠?
제대로 된 기획과 디자인 프로세스를 적용하는데 필요한 비용은 오류가 가득한 엉터리 제품을 시장에 늦게 출시하는 데 들어가는 비용에 비하면 아무것도 아니에요. 그런데 어째서 비용이 허락하지 않는다는 거죠?


프로젝트 초기에는 디자인하려는 제품이 어떤 것인지 확실히 알 수 없다. 이런 사실을 인정하고 프로젝트를 관리해 나가기란 무척 어렵다. 따라서 프로젝트의 초기부터 제품을 결정해 버리고 개발 단계로 곧장 넘어가려는 경우가 많다. 하지만 현실은 그렇지 않다. 행운이 따르는 아주 극 소수의 경우를 제외하면 제대로 된 디자인 단계를 거치는 쪽이 훨씬 효과적이다. 시간과 비용을 절약하면서 훌륭한 제품을 제작하는 지름길이다.

바로 결련으로 넘어가버리는 지금의 방식보다는 명확한 디자인 단계를 프로세스에 도입하는 것이 훨씬 바람직 하다.