갑작스런 협업에 약간의 불편함(?)도 있는건 사실이다. 전에는 그냥 하다가 옆에놈한테 이렇게 하자 하면 이렇게 하면 되고 저렇게 하자 하면 저렇게 하면 됐는데 이제는 얘기해야 될 사람이 많아졌다. 물론 전의 체계가 없는 거였기 때문에 체계만 잡히면 일하기는 훨씬 수월해 질꺼라고 생각하고 있다. 정책적인 부분때문에 개발하면서 많은 고민은 하지 않아도 되고...
기획자와의 협업
본부의 사정때문에 프로젝트 일정이 좀 엉켰기 때문에 개발과 스토리보드가 같이 올라가고 있다. 그리고 개발쪽이 기획단계에서 전혀 참가하지 않았기 때문에 개발하면서 변경이 필요한 부분도 있었기 때문에 계속적인 회의를 통해서 스토리보드가 수정되고 있다. 지금은 상황이 그러니까 감안하고 하더라도 다음 프로젝트의 스토리 보드를 고민중이다. 스토리보드가 어떻게 나와야 개발할때 편할까 하는 생각...
나는 문서는 잘 모르고 어떻게 하면 개발이 더 편할까 하는 부분에 관심이 있기 때문에 다른건 잘 모르겠고 스토리보드가 어떻게 되야 개발할 때 편할까 하는 고민중이다. 그냥 스토리보드를 볼때는 자세하게 나와있구나 생각하고 있었지만 개발을 하다보니 빠진 부분들이 발견되었다. 그런 부분에 있어서 다시 기획팀에 전달하고 다시 수정된 스토리 보드를 받고 하다보니 "효율적인가?"하는 생각....
그리고 각 상황별 모든 케이스를 다 고려해서 스토리보드가 작성되면(예를 들어 같은 페이지도 로그인 한경우, 안한경우,.... 각 특징에 따라 케이스는 수도없이 나올수도 있다.) 거의 책 수준으로 나오겠는데 하는 생각... 정확히는 개발할 수 있을 정도로만 어떤 정책으로 진행이 되는지만 전달되면 상관없긴 한데 각 부분별로 틀에 맞추어서 페이지가 작성되어야 하니까 왠지 효율적이지 않은 느낌? 좀더 공수를 줄이면서도 전달해야 될 내용을 다 담을 수 있지 않을까 하는 생각..(물론 이런 부분은 내가 개발하는데 필요한 스토리보드에만 초첨을 맞춘 것이고 산출물로써의 스토리보드 같은 경우에 대한 고려를 한 것은 아니다. 솔직히 그런 부분은 잘 모르고...)
각 기획자가 다 고민중인 걸로 알고 있는데 전통적인 이 스토리보드 형식으로는 확실히 인터랙티브한 페이지 디자인은 표현하기가 쉽지 않다는 느낌.... 앞으로 Ajax나 그런 부분도 많이 도입되고 할텐데 그런 부분에 대한 좀 더 심층적인 고민을 해봐야 될 것 같다.
디자이너와의 협업
솔직히 더 큰 고민은 디자이너와의 협업에 있다. RIA쪽 세미나에 가면 항상 나오는 것이 개발자와 디자이너의 협업에 대한 부분인데 그만큼 쉽지 않기 때문에 그런 얘기가 나오겠지..(물론 RIA에서 이부분이 더 크게 부각됐지만...)
경험부족으로 대처가 부족했던 점이 있다. 사전에 필요한 사항들에 대해서 논의가 좀 오가고 개발쪽 요구사항을 전달했어야 했는데 그러지 못했다. 물론 그러지 못했던 것은 처음 해보는 디자이너와의 협업이라 어떤걸 요구해야하는질 몰랐고 생각난 것들도 그 요구들이 정당한 건지를 잘 몰랐다.
그러다 보니 받은 HTML이 맘에 들지 않았다.(경력을 비교해봤을때 내가 맘에들지 않는다고 말하는건 좀 그렇긴 하지만....) Doctype도 선언되지 않는 부분이라던지 당연히 DIV로 갈줄 알았는데 table방식으로 HTML이 나왔고 table도 HTML 4.01 Tranditional에 맞지 않는 속성들이 마구 들어간 HTML이 나왔다. div방식으로 할수 있을지를 고민중이긴 하지만 이걸 사전에 확실히 협의했어야 했는데 하는 아쉬움이 남는다.
그리고 이게 가장 큰 고민인데 디자인이 어떻게 나와야 편하게 개발을 할까 하는 고민이 있다. 다른 사람들은 어떻게 하는지 궁금하기도 하고.... 전에도 좀 느낀거지만 디자인이 스토리보드를 기반으로 나와버리니까 개발에서는 어려움이 많다. 디자이너가 보는 파일과 개발이 보는 파일은 아무래도 좀 다르니까....
JSP에서 템플릿을 쓰다보니 디자인된 페이지를 계속 찢어서 만들 수 밖에 없고 그러다 보니 파일명 매트릭스같은 부분이 깨져버리니까 이걸 어떻게 대처해야 될지 잘 모르겠다. 눈에 보이는 한 페이지가 개발쪽에서는 템플릿을 써서 여러페에지가 조합되서 한페이지가 나와버리니까.. ㅡ..ㅡ
그리고 같은 맥락으로 게시판 같은 경우 여러개의 게시판을 다 따로 만든는 것이 아니라 한개의 게시판 소스가 약간은 다른 타입의 게시판들이 동작하도록 만들고 있는데 이러다 보니까 디자인이 빠진 부분이 생긴다. 나는 모든 기능이 다 있는 전체게시판이 하나 필요하고 거기에 상황별로 넣었다 빼야 하는데 디자인은 그렇게 나오지도 않았을 뿐더러 딱 스토리보드에만 있는 페이지만 나왔기 때문에 나중에(아직 디자인이 다 안나온 관계로) 다른 메뉴부분에 들어가는 게시판에 있는 기능에 있는 부분에 대한 디자인은 아직 없다는 것이지. 난 지금 게시판을 통째로 만들어야 하는데.. ㅡ..ㅡ
꽤 생각했는데도 답이 잘 안나온다. 앞에 얘기한 요구사항이야 다음번에는 잘 협의하면 되기는 하는데 이런 부분은 내가 어떻게 디자인을 받아야 편할까하면 답이 딱 떨어지지 않는다.
확실히 개발과 디자인의 경계는 애매한 것 같다. 예를 들어 왼쪽의 메뉴가 접고 펼치기가 되어야 하는데 안되게 나왔다. 이걸 전달해서 접고 펼치기 되게 해서 받아야 하는건지 아니면 그냥 내가 알아서 하면 되는건지...(솔직히 별 소스도 아닌데...) 그냥 귀찮아서 내가 해버리고 말았지만.... 간단한 자바스크립트 영역에서 좀 애매하긴 한것 같다. 아니면 메뉴가 10개인데 7만 붙어서 나왔는데 이미지는 있다. 그냥 tr태그추가해서 파일명망 적어주면 되는건데 이걸 그냥 해야되는건지 아니면 요청하고 새로 받아야 되는건지... 쩝... 어렵다 어려워...
이건 사담이지만 그나저나 잘라내기는 table이 편하긴 한데 확실히 다루기는 영 불편해 융통성도 별로 없어서 개발쪽에서 이것저것 하기도 좀 어렵고 약간 변형 하려고 해도 골치고... 역시 퍼블리셔가 필요해.... 퍼블리셔가....
흠.. 이 글을 보니 과거랑 지금이 비교가 되긴 하네용.. BCCard 에는.. 개발자.. 기획자.. 퍼블리셔.. DBA.. 이렇게 나뉘어 있어용.. 그중에 저는 웹 개발자라고 하겠죵.. ㅎㅎ.. 근데 보면, 확실히 기획자는 개발을 모르기 때문에.. 문서쟁이라고 하는 현업들에게서 설명 받은 그대로만 스케치를 하더라구요.. 그러다보면 자연스럽게 저한테 왔을 때는 문제가 있는 상황인거고, 그래서 재소집해서 다시금 회의를 하지만.. 그래도 문제는 생기네요.. 이유는 머리로 그리면서 생각을 한 개발과 실제 코딩하면서 생기는 문제는 엄연히 차이가 있기 때문인듯요.. 저도 햄같은 고민 때문에 약간의 과거에 많은 협의를 해봤지만, BC 내에서 혹은 여러 사람이 다 같이 하는 협업의 내에서는 최대한 이슈를 줄이는게 중요하지.. 완변에 가깝게 맞춰나가기란.. 참으로 어려운 문제인듯요.. 이 부분은 항상 고민이면서 해결이 완벽하게는 되기 어려운.. 문제 같아용..
어려운 문제긴 하지. 서로간에 보통 부서나 입장이 다르니까 벽이 생기면 더 그렇고. 난 기획자나 디자이너도 해당 시스템이나 제약 요건에 대해서 알아야 한다고 하는 편이고 경험상은 기획자가 이를 모르면 꽤 큰 문제가 생기는듯. ㅠㅠ