솔직하기

작게   크게

꽤 오랜기간이 걸렸던 일이 있다.

새삼 실제 선수들이랑 했다면 3개월정도 걸릴일이지만,

클라이언트의 담당자의 업무 과중. 유사필드의 경험은 존재하지만 새롭게 만들고 있는 영역의 경험의 전무함.

등 등의 이유로 한두달 미뤄지던 일정이 되어버렸고, 결국에는 전문가가 붙었다면 2주 정도면 가이드가 나와야할 디자인이 2달정도가 걸렸다.


이런 저런 일이 있어도. 일단 우리쪽에서 바짝 달려 약속한 마감일은 지켜야겠다는 생각에 요즘 꽤 열코딩을 하고 있는 중이었다.

개발자 3명이 올인하여 겨우 일단 일정은 맞춰가고 있긴한데, 하다보니 좀 느끼는게 있었다.

이걸 또 글까지 쓰게 된 것은 친구녀석의 회사고민을 듣다보니 하나로 귀결되기 때문이다.


솔직하기. 그리고 자기를 잘 알기.

상대도 그렇고 팀내에도 솔직해야 모든게 계획대로 된다. 이게 최근 나의 경우, 그리고 내 친구의 고민의 답인것 같다.


업무에 대한 자기역량에 따른 기간 산정.이게 명확하게 나오지 않는다면 일정은 딜레이될수밖에 없다.

3개월짜리 프로젝트가 어느덧 반년이상을 끌게 된 것도 이런 것 때문이었다.


클라이언트가 자신들의 다른 업무들로 인해 딜레이가 걸리는 부분은 양해를 구했기에,

다른 프로젝트들을 하며 그 시간을 죽이진 않을 수 있었다.


하지만 실제 업무에 돌입하고, 역할별 업무들을 구성하여 진행했는데 2주의 기간이 걸릴 일이 2.5달이 걸렸다.

중간에 회의로 업무 일정을 맞추기론 했지만.. 그 기간 또한 2주이상의 딜레이.


이번 일의 경우 딜레이가 걸리는 요소는 복합적이기 때문에 잘잘못을 따지긴 애매할 수도 있지만.


이번 사례를 잘 분석하면, 분명 다음번 리스트는 줄일 수 있을 것 같다.


1. 해놀게요. 를 믿지말자. 정확한 마감일을 설계하자.

디자인. 기본 컨셉이 나오고 한달 정도의 공백이 있었다. 그러다가 이제 본격적으로 담당 디자이너가 일을 할 수 있다고 해서 회의를 가졌고, 메인과 서브페이지 기본 시안이 나온 상태이기 때문에 2주의 시간이면 충분히 마감을 칠 수 있을 것이라 생각했지만. 2주가 지날 시점 넘어온 자료는 전체 분량의 40%도 안되는 수준이였다. 대학원생인데 시험기간이 걸렸다는 것과 다른 급히 쳐야하는 디자인이 있었다는 이유 때문이었다. 2주후로 스텐바이 하고 있던 개발팀은 또다시 시간적 공백을 가질 수밖에 없는 상황이 된 것이다. 일단 이에 대한 긴급대안으로 서브디자이너가 추가되었고, 또 한달 후 종료를 얼마 나두지 않은시점에 다른 디자이너가 일을 받아 처리하면서 개발자가 하나끝내고 또 조금 공백이 생기고 하는 일이 반복해서 발생을 했다. 개발자는 정해진 기능을 개발하는 데 시간을 계산해서 그 시간만큼의 비용을 받는 데, 이렇게 대기 시간이 길어지게 되면 그만큼 실제 수익에 손해를 보게 된다. 이뿐만 아니라 개발 중간의 공백이 생기게 되면 최초 기획이나 회의에서 나왔던 내용들을 공백의 시간동안 계속 기억을 하고 있지 않고 다른 업무를 처리하기 때문에 분명 실수를 유발하게 되는 요인이 되기도 하는 것 같다. (이건 내가 경험해보니..) 프로와 아마추어를 구분하는 것은 시간관념이다. 전체 프레임에서 내가 맡은 역할이 언제 끝나야 팀에 시간적 누수를 없앨 수 있는지를 계산하여 작업물의 완성도가 결정되어야 한다. 자신의 만족도를 위해서만 잡고 있는 것은 개인의 이기심일 뿐이다. 그렇기에 시간이 1순위이고 그로 인해 나온 결과물의 퀄리티는 2순위인것이고.. 시간을 지키기 시작하면 그때부터 노력해서 퀄리티를 높여야지 성장할 수 있는 것이다.  그런데 이걸 신입 디자이너들은 종종 놓치는 것 같다.


디자인단도 그렇고 우리쪽도 그렇고 기본 규칙을 준수하는 게 조금 서툴었다. 웹디자인이 다른 그래픽 디자인과 가장 구분되는 특징은 그 결과물에 코드가 들어간다는 점이다. 이것은 명확한 규칙하에 설계되어야 하는 건축과도 유사성이 있기에 웹 디자이너라고 하면 외형미와 더불어 구조적 이해를 해야 할 필요가 있다. 그렇지 않으면 코드의 복잡성이 높아지고 이는 결국엔 사이트의 성숙도가 높아질 수록 더욱 관리하기 힘든 사이트가 되어버리기 때문이다. 버튼의 상하 여백은 몇, 버튼간 간격은 몇, 본문은 어떤 타입이고, 글자크기는 몇, 해드라인은 어떤 형태인지. 공통된 스타일 정의를 미리 해놓고 디자인을 하게 되면, 이러한 중복된 영역을 하나의 코드 변수로 설정하여 작업하면 되기 때문에 실제 코드의 양은 줄어들게 되고, 코드는 더욱 명확하게 설계할 수 있게 된다. 그리고 코드가 줄어들게 되면 미세하게나마 사이트의 접근 속도를 향상시켜준다. 그런데 이번의 경우, 작업을 진행하면서 이러한 규칙을 찾기가 힘들었기에 바로 개발자들에게 넘기지 않고, 중간에 최소한의 규칙성을 주는 작업을 하며 개발을 진행했었다. 이는 분명 불필요한 시간이 더욱 개입되는 요인이 된 것도 같다.


2. 기본 규칙을 설계하고 습관화시키자.

개발자들의 경우 하나의 완성품에 여러명이 공동작업을 할 때 종종 발생하는게 기존 다른 사람이 작업하던 코드를 유실시키는 것이다. 보통 서버에서 작업하는 사람이 있기도 하고, 자신이 몇시간 전에 다운받아 작업하던 파일이면, 별다른 의심없이 자신의 백업 파일에 기반하여 작업을 하게 되고 이게 업무량이 많아질수록 최신코드를 동기화하는 시간의 압박에 작업파일을 동기화하지 않고 작업을 하다보면 흔히 발생하게 되는 실수다. 주로 개인이 전담하여 개발하는 경우가 많은 개발자들이 흔히 이런 실수를 하는데, 우리 개발자들들은 이렇게 몰아치듯 개발을 해보진 않았었기에 이번에 이런 실수가 좀 발생했다. 다행히 짓허브라는 백업 툴을 사용하고 있었기에 크레티컬하게 시간을 버리는 일은 없었지만. 이런 부분은 신경써야 할 부분임을 다시 확인할 수 있었다.


일단 이번 주말까지 달린 덕분에.

몇가지 잔업은 남았지만 거의 모든 작업은 마무리를 한 것 같다.


작은 규칙에 성실하기. 솔직히 자신의 상황을 공유하고. 시간을 못지킬 경우는 미리 이야기하자. 그래야 다른 사람들이 손빨면서 시간 버리지 않는다.


한동안 외부일을 처리하다보니 내부 서비스에 반영할 아이디어리스트와 제안리스트가 다시 꽤 많이 쌓여버렸다.

2월. 조금 여유가 되면 최대한 처리를 해봐야지.


그리고 다시금 짬나는데로 기억을 기록해야겠다.

꽤 지난 글 중에 나중에 마무리해야지. 하는 것들도.. 어느덧 시간이 꽤 지나다보니 그때받았던 영감이 무엇인지 기억이 희미해졌다.





http://juroweb.com/xe/2947



46 요상한 것 jurohan 2016.05.11 317
45 도덕적 해이 jurohan 2016.03.23 317
44 가치 있는 것에 집중하기 jurohan 2016.03.19 444
43 업의 본질. jurohan 2016.02.09 34
42 사람 jurohan 2016.02.08 333
» 솔직하기 jurohan 2016.02.01 356
40 새해다짐 jurohan 2016.01.01 388
39 명절 jurohan 2015.09.29 481
38 립마크.비기닝. jurohan 2015.08.27 454
37 아료카. jurohan 2015.07.09 516
36 시간의 상대성 jurohan 2015.05.31 575
35 대화 jurohan 2015.05.26 527
34 jurohan 2015.05.19 523
33 배려의 오해 jurohan 2015.04.10 623
32 참 좋아하는. jurohan 2015.03.29 565
31 곧 뵈요이라는 말. jurohan 2015.03.24 749
30 목욕탕을 갔다. jurohan 2015.02.02 668
29 바람이 되자. jurohan 2015.01.28 689
28 1월 jurohan 2015.01.05 681
27 고마운 사람.들 jurohan 2014.12.19 734

© juroweb 2003-2014. All rights reserved
log in