SW 개발쪽에서 자신이 만든 제품을 자기가 직접 써보는 것을 ‘개밥을 먹는다’라고 표현한다고 한다. 보기에는 그럴싸 하지만 먹어보면 맛이 없는 음식 – 즉, 내가 만든 SW니까 멋지고 좋아보일 수는 있어도 실제로 사용자 입장에서 써보면 영 아닌 경우가 많으니 주의하라는 의미다.

출처: Geek And Poke: Simply Explained

대개 먹어보면 맛이 없는 경우가 태반이기에 개밥 먹기를 주저하는 개발자/기획자가 많다. 막상 맛이 없어도 ‘뭐 이정도면 먹을만 해’라며 자기위로에 빠지는 경우도 많다.

최근 개발 막바지에 들어선 프로젝트에서 내가 그랬다. 초기 기획에는 발을 담궜지만 개발 막바지서부터 통합 테스트 단계까지 일부러 발을 뺐다. 산출물의 맛이 없어서라기 보다 까다로운 내 입맛에 맞지 않을 것을 우려한 탓이다. 개발자는 아니지만 PM으로서 어떤 맛일지 대충 감이 잡혔고 (그래서는 곤란하지만) 개밥을 먹어본 후 ‘처음부터 다시!’라는 유혹에 시달리기 싫기도 했다.

다행스럽게도 산출물의 맛은 괜찮을 것 같다. 프로젝트에 참여한 개발자, 기획자, 디자이너 등 구성원 모두가 고생한 덕분이다. 그래서 나도 면피도 되고 구성원들도 즐거워질 수는 있겠지만 … 스스로는 영 개운치 못하다. 정확히는 떳떳하지 못하달까?

어쨌든, ‘개밥 먹기에 대한 두려움을 극복할 것’
그게 이번 프로젝트에서 내가 얻는 가장 큰 교훈이다.

* 이미지를 클릭하면 크고 아름다워 짐~

시장조사기관인 atkearney에서 발간한 ‘Internet Value Chain Economics‘ 리포트 7페이지에 나와 있는 인포그래픽. 개인적으로 이해를 돕고자 번역해서 재구성해 봤다. 인터넷 경제를 구성하는 각 산업군과 기업을 중심으로 구성한 그래픽인데 … 자세히 뜯어보면 많은 의미가 튀어 나온다. 국내 기업과 비교해 보는 것도 재미있을 듯.

이메일서비스
1위 Google Apps, 2위 Microsoft Outlook, 3위 Go Daddy, 4위 Rackspace 5위 1-AND-1
: 역시 구글! 여전히 G메일을 대체할 수 있는 웹메일 서비스는 없는 것 같다.

지불처리
1위 PayPal, 2위 Authorize.net, 3위 Wells Fargo, 4위 Square, 5위 Braintree
: 국내에서는 듣보잡이지만(^^;) 글로벌하게는 역시 패이팔의 위력이 독보적이다. 4위로 올라선 스퀘어가 의외다. 일본에서 벌써 보급되고 있는걸까?

웹사이트해석
1위 Google Analytics, 2위 Webtrends, 3위 Omniture, 4위 KISSmetrics, 5위 Mixpanel
: 무료에 다양한 트래픽 정보를 제공해주는 구글 애널리틱스가 예상대로 1위.

CRM툴
1위 Salesforce, 2위 SugarCRM, 3위 Highrise, 4위 Zoho, 5위 SalesLogix
: 국내에서는 SI를 통해 자사 솔루션을 구축한 경우가 많지만 점점 세일즈포스의 활용도가 커지고 있다. 4위로 올라선 Zoho가 의외인데, 아마도 Zoho 제품군 중 Zoho CRM을 말하는 것 같다.

웹사이트디자인
1위 Adobe CS5, 2위 Coda, 3위 Pencil and Paper, 4위 Komodo Edit, 5위 Fireworks
: 어도비 CS5가 일반적이지만, 종이와 연필로 수작업하는 선호하는 경우도 많다는 사실.

저장/백업/가상화
1위 Dropbox, 2위 Amazon, 3위 Carbonite, 4위 MOZU, 5위 Backblaze
: 드롭박스가 갑! 100% 동의한다.

프로젝트관리
1위 Basecamp, 2위 MS Project, 3위 MS Excel, 4위 Salesforce, 5위 Google Docs
: 베이스캠프가 워낙 평이 좋긴한데 … 개인적으로는 조엘 스폴스키의 추천대로 엑셀표를 공유하는 방식으로 프로젝트 관리하는 방식을 선호한다.

노트툴
1위 Evernote, 2위 MS Google Docs, 3위 Pen and Paper, 4위 MS Word, 5위 MS Outlook
: 1위부터 5위까지 모두 좋은 툴이지만, 역시 종이와 연필이 최고! 에버노트의 경우 모바일과 웹을 자유롭게 연동할 수 있다는 점에서 1위에 오를 자격이 충분하다.

콜라보레이션 /Wiki
1위 Google Docs, 2위 Basecamp, 3위 Jira, 4위 Sharepoint, 5위 Galesforce
: 협업의 성격과 종류, 범위에 따라 다르겠지만 구글 닥스가 쓰기 편한 건 사실. 한편으로 e메일이 왜 빠졌을까?라는 생각도 든다.

전화서비스
1위 Google Voice, 2위 RingCentral, 3위 휴대폰 , 4위 Skype ,5위 Grasshopper
: 개인적으로 스카이프를 가끔 쓰는데 … 국내야 워냑 유무선 통신이 발달한 관계로 이 순위가 크게 와닿진 않네.

개발 환경은 건너 뛰고 … 디자인 환경을 보면 …

하드웨어/모니터
1위 Mac 랩탑/모니터, 2위 HP 랩탑 /모니터, 3위 ACER, 4위 Dell, 5위 iPad
: 아이패드를 모니터로 쓰는 경우가 많나?

비쥬얼디자인
1위 Adobe Photoshop、2위 Adobe Illustrator、3위 Adobe Fireworks、4위 OmniGraffle、5위 Pen and Paper
: 역시 포토샵이 1위, 어도비 제품이 휩쓸고 있다. 개인적으론 종이와 연필을 주로 쓰고 다이어그램 작성 시 옴니그래플을 가끔 쓰는 편이다.

와이어프레임작성
1위 OmniGraffle、2위 Adobe CS、3위 Balsamiq、4위 Axure、5위 Fireworks
: PC를 쓸 때는 Axure의 열렬한 팬이었는데, 맥을 메인으로 쓰는 지금 마땅한 게 없다. 발사믹은 도큐멘테이션 기능이 약하고 … 현재는 키노트로 주로 한다.

화상편집
1위 Adobe CS5、2위 Lightroom、3위 Acorn、4위 Fireworks、5위 iPhoto
: 좋은 툴이 많지만, 맥 환경에서 많은 사진을 간단히 편집할 때는 아이포토가 최고인 듯~

p.s> 여러분들은 어떠신지? ^^

그런데 얼마 전, 특이하게도 대결구도(?)가 아닌 자기비판적인 기획자 무용론이 올라와 눈길을 끌었다.

Fredism on iFred 블로그의 ‘기획자가 인정하는 기획자 무용론‘

(사견을 담아) 요약하면 조직 규모나 세력, 기대 수준에 따라 기획자의 비중이 얼마든지 바뀔 수 있으며 그 역할에 대해서도 다시 생각해 봐야 한다는 의미로 해석된다. 극단적으로 보면 IT 기반 스타트업에서는 CEO든 개발자든 디자이너든 모두가 기획에 참여하므로 따로 기획자가 필요없을 수도 있다는 얘기다. ‘실리콘벨리에는 기획자라는 직군이 따로 없다’는 얘기도 있으니 … (실제로 그런지 확인은 못해봤지만) 기획자 무용론을 스스로 제기한 이유에 대해서도 어느정도 수긍이 간다. 본문 못지않게 댓글도 백미이므로 꼭 읽어보시길~

반면, 개발자 출신으로 스타트업에 몸을 담고 있는 미니님은 이러한 기획자 무용론을 우회적으로 비판하고 있다.

미니의 프로그래밍 이야기 ‘기획자에게 힘을 실어주자~‘

스타트업에서 일하면서 오히려 기획자의 필요성을 절실히 깨닫고, 기획자의 위상을 높일 필요가 있다고 고백한 것이다. 해보니 오히려 더 필요하더라~라는 얘기다. 이 역시 수긍이 간다.

종합하면 … 갑론을박, 말은 많지만 오히려 그렇기 때문에 기획자는 필요한 직군이 아닐까 싶다. IT개발에 있어 초기 기획은 반드시 필요하고 그 역할을 나누어 수행할 수도 있지만, 제대로 가려면 누군가가 주도해야 한다. 결국 ‘기획자’라는 이름으로 불리는 이가 (임시든 지속적이든) 이를 수행할 수밖에 없는 것이 현실이다. 전 멤버의 기획자화는 사실 이상론에 가깝고 현실은 시궁창이니까. ^^;;;

끝으로, 일전에 한 번 소개했던 슬라이드 ‘기획자는 무엇을 하는 사람일까?‘에 다시 링크를 걸면서 글을 맺는다. 이런 문제 역시 답은 예전부터 나와 있는 것 같다. 그래서 선배들의 경험에 귀를 좀 기울일 필요가 있는 것. 그 양반들은 다(아마도) 해봤다.

일단, 99% 공감한다.
소위 ‘한 문서’한다는 분들을 보면 이런 경험을 다 거쳤을 것으로 믿는다. 문서를 만들다 보면 주객이 전도되어 ‘What’과 ‘How’에 집착한 나머지 ‘Why?’를 잃어버리기 일쑤다. 문서를 만드는 본질은 망각한 채 문서 자체에 집착하게 되고 … 결국 문서를 위한 문서가 되어 버린다.

“글자 크기가 작아”, “맞춤법이 틀렸어”, “이건 표로 만들어야지”, “양식대로 해” … 등등
이렇게 되면, 문서를 만드는 사람이나 읽는 사람이나 피곤해 진다. 시간과 정력 낭비일 뿐.
그렇다고 문서가 필요없느냐?
그건 또 아니다.

박부사장의 트윗에 99% 공감하되 나머지 1% 때문에 그래도 문서화는 필요하다고 생각한다(물론, 박부사장께서 문서가 필요없다고 한 것은 아니다). 이유는 트윗 문구 그 자체에 들어있다.

“문서 공유가 이해를 공유하는 것”이라는 정의를 따를 때, 문제는 사람마다 이해의 정도가 다르다는 데 있다. 협업의 특정 사안에 대한 이해와 정보를 공유할 때 해당 부서장의 이해와 CEO의 이해, 그리고 제3자(타부서나 협력자)의 이해가 모두 다르다. 이렇게 다른 생각과 이해의 정도를 맞추기 위해서는 말이나 간단한 메모로 부족하다. 어느정도 양식에 맞춘 문서를 통해서 이뤄지는 것이 효율적이다. 이론의 여지를 최대한 줄이기 위한 용도다.

결국 다음과 같은 이유 때문에 문서화는 반드시 필요하다고 본다.

첫째, 말보다 글
말을 뒤집을 수 있다. 없던 얘기를 지어낼 수도 있고, 있던 걸 없앨 수도 있다. 그리고 말이 단계를 거치며 전달되면 변형된다. 원래 이해가 정확히 전달되지 않는다. 그걸 보완하기 위해 세종대왕께서 ‘한글’을 발명하신 거다.

둘째, 기록 기록 기록
문서는 쓴 사람과 읽는 사람이 있다. 언제 썼고 누가 읽는지 파악이 가능하다. 결정적으로 책임 소재 파악이 명확하다. 그래서 말 한마디면 해결될 일을 번거롭고 귀찮지만 문서로 만드는 거다. 부가적으로 말만 듣고 ‘그렇구나’라고 이해한 사항을 글로 보면 ‘이럴 수도 있구나’라고 한 번 더 생각할 수 있다. 특히 쓰는 사람은 스스로 자기가 전달하고자 하는 사안을 정리할 수 있는 기회를 갖는다.

셋째, 보기 좋은 떡
같은 말이라도 미운 말, 고운 말이 있듯이 문서도 기왕이면 간결하고 이해하기 좋은 문서가 좋다. 어느정도 스킬이 필요한 부분인데 문서를 읽은 사람의 이해 정도를 고려해서 만든 반 페이지짜리 문서는 몇 시간짜리 연설보다 훨씬 높은 효과를 지닌다.

장광설이 길었는데 … 정리하면, 문서화의 폐단을 인지하고, 주객이 전도되지 않게 문서라는 형식을 적절히 활용하자는 얘기다. 그리고 그게 쉽지 않기 때문에 문서를 만드는 사람이나 읽는 사람이나 각자의 노력이 조금씩 필요하다. 특히 개발자와 기획자. 당신들 말이다. ^^

결론: 문서화는 필요악. 허나 기왕 할거면 제대로 해야, 어설프게 하면 안하느니만 못하다.