저는 평생 한두곳의 회사만 다니고 싶어요.
그렇게 오랫동안 일할 수 있게 해주는 회사가 있다면 저는 그 회사를 위해서 최선을 다해서 일할 것 입니다.
그런데 그런회사는 어떤 회사일까요?
우선 저는 근무 시간중에 일정 시간동안 자기가 원하는 일을 하도록 해주는 구글이 마음에 들어요. 직장 내에서 혁신을 조장하는
정말로 멋진 방법이죠. 그러기 위해서는 분명 조건이 있어야 할 겁니다. 제가 골랐고 열정적으로 느끼는 일반적인 일 외에도 뭔가에
몰두할 수 있는 능력이 있어야 하겠죠. 원격 통신 능력이 있으면 아주 좋을 겁니다. 아무도 하루종일 흰색 벽 속에 갇혀있고
싶어하지 않을 테니까요. 그렇게 일하는 건 신체적으로나 감정적으로 너무 힘들죠. 근로 시간을 유연하게 조정해서 일하는 것도
좋겠지요. 그렇지만 제가 집에서 일항 경우 그런게 별로 의미는 없겠죠. 스톡옵션은 좋아요. 저와 제 아들까지 수혜 대상이 되는
복지 혜택도 있으면 좋구요. 출장 기회도 많고, 제가 제 분야에서 발전할 수 있는 훈련도 받을 수 있다면 금상첨화겠죠. 어디서나
데이터 연결이 가능하고, 연간 비품 비용을 청구할 수 있고, 마사지까지 받으면 더 좋구요.
그러나 그 어느 것보다 제가 일을 구할 때 가장 중시하는 건 그 일이 '도전적'인지 여부입니다.
저는 보고서나 작성하고, 육체노동이나 하고, 머리를 쓸 필요가 없는 일을 하면서 제 시간을 보내고 싶지는 않아요. 저는 직장
내에서 제가 가치를 인정받는다는 느낌을 받고 싶은데, 그런 느낌은 도전적인 일을 해결할 때 느낄 수 있죠. 예를 들어 "우리는 저
직원은 힘든 일도 잘 처리할 수 있다고 생각합니다. 재능이 있는 친구입니다."라는 말을 듣고 싶은 거죠. 그러면 저는 제능력을
증명해 보이고 싶을 것이고, 제가 그렇게 하면 저를 고용한 회사의 고용주들 에게도 좋은 일이겠죠. 그러면 모든 사람이 승리하는
거구요. - 디지털 네이티브(돈 탭스콧 저)
좋은 품질을 원할때 팀원에게 해주어야 하는 노력들..
책에서 발췌도 했고, 제생각도 적었고, 물어보기도 했습니다. ㅎㅎ
(추가해주시면 생각해보겠습니다. )
이 글은 한글깨짐을 해결하기 위해서라기 보다는 문제를 해결하는 방식에 대한 정리를 위해서 입니다.
기술적인 내용은 링크한 내용들을 참고하시면 보다 많은 정보를 얻을 수 있습니다.
저는 업무에서 기술적인 문제해결을 위해서 "환경분석-> 계획수립-> 테스트 케이스 생성-> 테스트 및 문제해결-> 검증" 의 순서로 진행합니다.
누구나 빠른 문제해결을 원하지만 실제로는 "바로 해결하기"를 하는 경우가 많습니다.
다행스럽게도 운이 좋아서 빠른시간에 해결이 된다면 좋겠지만, 여러가지 포인트에서 문제발생의 여지가 있는 경우가 대부분 이므로, 빠른 문제해결을 위해서는 절차를 따르는 것이 좋습니다.
실제 많이 경험하시게 되는 웹페이지의 한글이 깨어지고 있는 상황을 가정하고, 문제를 추적해 보겠습니다.
1. 환경분석
장애가 일어난 시스템의 구조는 Apache, Proxy_ajp, Tomcat, MySQL로 구성되어 있습니다.
그런 경우 euc-kr 또는 UTF-8로 인해서 문제가 일어날 수 있는 WeakPoint 는 아래와 같은 곳입니다.
2. 계획수립 사소한 일이라면 그냥 머리속으로 계획을 세우면 되겠죠.
하지만 좀 시간이 걸리는 일이라면, WBS를 구성해서 제대로된 일정계획이 있는 것이 업무를 현명하게 하는 방법입니다. 이 문제는 그렇게 오래 걸리는 문제가 아닐꺼라고 판단하고, 즉시 수행하기로 했습니다.
3. 테스트케이스생성 해당 문제를 해결하기 위한 테스트에 필요한 케이스를 우선 구상합니다.
머리속으로 하셔도 되고, 메모하셔도 좋습니다. 전 그냥 머리속으로 했습니다 :-)
WEB
- 캐릭셋을 설정하지 않고 한글을 제대로 표현하는지 테스트합니다.
- 캐릭셋을 원하는 설정으로 변경하고 한글표현을 테스트합니다.
Connector
- get으로 한글을 전달해서 제대로 나오는지 확인합니다.
WAS
- 캐릭셋을 설정하지 않은 상태에서 한글이 제대로 나오는지 확인합니다.
- 캐릭셋을 변경해서 변환이 정상적으로 되는지 확인합니다.
DB - 콘솔에서 직접 한글을 조회해서 확인합니다. - collection을 확인하고 원하는 설정으로 변경해서 한글을 입력하고 조회해 봅니다.
4. 테스트 및 문제해결 생각한 테스트 케이스를 수행하면서, 문제를 해결하는 단계입니다.
기술수준이나 경험에 따라서 차이가 좀 있겠지만, 차근차근 한가지씩 해결해나가는 방법이 가장 빠른방법입니다.
WEB
이 시스템은 웹서버로 Apache를 사용하는 경우 입니다.
아파치의 경우 html문서의 상단에 아래와 같은 방식의 정의가 없다면 기본적으로 사용할 캐릭셋을 설정가능합니다. <meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
httpd.conf 파일에서 AddDefaultcharset을 원하는 캐릭셋으로 변경한 후 한글의 출력상태를 확인합니다.
Connector
웹서버의 요청을 WAS로 넘겨주는 역할을 합니다.
이 부분에서 POST, GET으로 넘기는 변수를 WAS로 전달할 때 캐릭셋을 변경할 수 있기때문에 확인해야 합니다.
이 시스템의 경우 tomcat 의 server.xml 파일에서 URIEncoding을 설정해 주거나, useBodyEncodingForURI="true" 를 설정하여 캐릭셋을 설정할 수 있습니다. useBodyEncodingForURI 설정은 이전페이지에 설정된 캐릭셋을 그대로 따른다는 설정이다.
JAVA Tomcat이 구동될 때 별도의 설정이 없다면 JVM은 ISO-8859-1로 동작합니다.
따라서 한글의 사용을 위해서 tomcat 구동을 시키는 계정의 .bash_profile을 수정해서CATALINA_OPTIONS=-Dfile.encoding=euc-kr 을 추가해서 동작하도록 설정해야 합니다.
캐릭셋이 지정되어 있지 않은 경우의 기본 캐릭셋 설정은 web.xml파일에 아래처럼
기본적으로 사용할 캐릭셋을 지정할 수 있습니다.
성공적으로 문제를 해결하는데 있어 사고의 다양성은 대단히 중요하다. 따라서 사람의 사고 선호도와 창의성 스타일에서의 다양성을 측정할 수 있다면 이는 매우 유용할 것이다.
사람마다의 사고 선호도와 창의성 스타일을 진단할 수 있는 대표적인 프로그램으로 HBDI와 KAI가 있다. 이들 방법은 전략적
계획 수립, 팀 구성, 프로그램 제작, 상담, 교수 및 학습 능력의 개선 등 많은 실용적인 분야에 다양하게 적용되어 그 효과를
나타내고 있다. 가령, 새롭고 독창적인 아이디어 개발을 위해 한시적인 팀을 구성하고자 하는데, 그 구성원이 창의적이기 보다는
기존의 체계에 안주하려는 성향이 강한 사람들로만 구성된다면 그 결과는 새롭고 독창적일 수 없다. 즉, 팀 구성원 전체가 창의적인
사람, 분석적이고 논리적인 사람, 감정이 풍부한 사람, 절차나 계획에 능한 사람을 골고루 갖춰서 팀 전체로 보았을 때 전체 두뇌
사고가 가능해야 그 결과도 기대할만하다.
좌우뇌 선호도 평가
1. 좌우뇌 사고 선호도 평가 방법: HBDI 1) HBDI의 목적
HBDI(Herrmann Brain Dominance Instrument)는 인간의 사고 선호도를 측정하는 가장 강력하고
유연한 도구이다. HBDI를 사용하여 사람들의 사고 선호도를 측정하고 효과적으로 사고하도록 하는데 HBDI 정보를 이용할 수
있다. Ned Herrmann에 의해 만들어진 HBDI는 두뇌가 4개의 영역으로 구성되고 각각이 다른 사고 선호도를 보인다는
사실에 기초한다. 4개의 영역이 합쳐져 인간 사고와 행동을 지배하는 전체 두뇌를 구성한다.
그림에서 A 영역은 수리에 뛰어나고 이성과 논리에 의해 문제를 해결하고자 하는 반면 D 영역은 규범에서 벗어나고 새로운
아이디어를 만들거나 감정과 추측을 기초로 문제해결을 시도한다. B 영역에서는 구조화 되고 순차적이며, 조직화 된 정신 활동이
이루어지고, D 영역에서는 감정적이고 인간 상호간의 정신 활동이 주로 이루어진다. A, B, C와 D 영역이 서로 다른 네 가지
사고 모드를 구성하며, 대개의 경우 네 가지 모드가 결합해서 작용하지만 하나 또는 두개의 사고 모드가 우세하게 작용한다.
2) HBDI의 측정
HBDI는 개인적인 사고 선호도 식별과 그 행동의 예측을 돕기 위한 설문지로 100개의 질문으로 구성된다. 설문지 파일을
다운 받아 오프 라인으로 작성하거나 유로 사이트에서 온라인으로 작성하여 자신의 HBDI를 측정해 볼 수 있다. 설문지 내용을 보고
각 항목 마다 답을 해가면 자신의 사고 스타일이 우뇌 사고(창의적 사고)에 가까운지 좌뇌 사고(논리적 사고)에 가까운지 느낄 수
있다.
전체 두뇌 사고는 문제해결과 어려운 도전에 직면할 때 특히 중요하다. 병원에서 의사는 A 영역에서, 간호사는 C 영역에서,
병원 운영진은 B 영역에서, 정신과 의사는 D 영역에서 높은 점수를 받으며 일반적으로 자신들의 집단별로 독특한 특성을 보이지만
긴급한 상황에서는 이들 각각의 사고 선호도가 전체 두뇌를 갖는 팀으로써 효과적으로 동작한다. 문제해결, 전략적 사업 계획 수립 및
인간 상호 관계 형성을 포함해서 HBDI의 실용적인 적용 사례는 많다.
문제해결의 경우를 살펴보자. 다른 사고 모드에서 문제를 관찰함으로써 새로운 문제해결 관점이 얻어질 수 있다. 프로젝트나
문제해결을 위한 팀 구성원이 어떤 두뇌 선호 프로파일을 갖고 있느냐에 따라 그 결과는 달라질 수 있다. 팀 구성원이 A, B,
C와 D 사고 선호도를 골고루 가지고 있어서 팀 전체가 전체 두뇌 사고를 할 수 있는 것은 매우 중요하다. 창의적인 문제해결에서는
D 사고를, 실행 절차나 계획을 수립하는 데는 B 사고를, 현재 환경에 적응 가능한 문제해결은 A 사고를, 팀 구성원간의
의사소통을 개선하는 문제는 C 사고를 선호할 것이다.
그러나 하나의 새로운 아이디어가 실현 가능하기 위해서는 전체 두뇌 사고에 의해 지원되어야 한다. 가령, 새로운 아이디어의
도출은 D 사고를, 도출된 아이디어를 보다 실용적으로 만드는 데는 A 사고를, 아이디어를 구현하기 위한 실천 계획을 세우는 데는 B
사고를, 고객 입장에서 아이디어의 평가나 팀 구성원간의 의사 조정은 C 사고를 선호하는 사람들이 기여할 수 있을 것이다.
2. 좌우뇌 사고 선호도 측정 방법: KAI
1) KAI의 목적
KAI(Kirton Adaption-Innovation Inventory)는 Michael Kirton에 의해 만들어진 것으로, 사람의 창의성과 문제해결 스타일을 측정하는 도구이다. 이 이론은 다음과 같은 가정을 전제로 한다.
첫째, 모든 사람은 창의적이며 새로운 아이디어를 만들고 문제를 해결한다.
둘째, 두뇌 활동에 관한한 창의성과 문제해결은 구별이 불가능해 보이며, 그 차이가 있다 해도 언어적 차이 이상은 아니다.
셋째, 모든 사람은 변화를 주관한다.
넷째, 적응-혁신 이론은 스타일과 레벨을 명확히 구분한다. 이 둘은 서로 상관이 없으며 모든 사람이 '내가 어떻게 창조할 수 있을까?' 또는 '내가 얼마나 창의적일까?'에 대해서 평가될 수 있다.
다섯째, 레벨은 기술, 지능과 경쟁력과 관련 있으며, 이들 대부분은 학습에 의해 개선될 수 있다.
여섯째, 스타일은 일생을 통해 변하지 안는다. 대처(coping) 행동을 통해 개인이 선호하는
스타일에서 벗어나 행동할 수 있다. 스타일 적응성에서 혁신성에 이르는 연속적인 스타일에서 어떤 사람은 적응성이 높고 다른 이는
혁신성이 높게 문제해결을 시도한다.
적응성이 큰 사람: 기존의 시스템을 개선하는 것을 선호. 기존의 패러다임내에서 문제해결. 구조화 된 접근을 선호. 정확하고 신뢰성이 높으며 새로움 속에서 질서와 안정성을 추구.
혁신성이 큰 사람: 기존의 시스템을 변경하기를 선호. 기존의 패러다임과는 상관없이 문제해결. 구조화 되지 않은 접근을 선호. 독특하고 공상적임. 팔기 어려운 해결책 제시.
스타일: 성공한 조직은 다양한 범위의 적응성 및 혁신성을 갖는 사람들을 갖는다. 이 둘의
스타일이 새로움을 만들어 낼 수 있다. 기존 시스템에서 후자는 현재의 정책, 습관, 패러다임에 구애 받지 않고 새로움을 추구한다.
자신이 적응성과 혁신성의 범주 어디에 위치하건 새로운 제품을 만들어낼 수 있다. 전자는 기존 모델을 개량하고자 할 것이고 후자는
급격하게 변화를 시도할 것이다. 그러나 이 둘이 서로를 필요로 한다. 혁신적인 것은 보다 실용적이기 위해 적응성이 큰 사람의
도움이 필요할 것이다. 대부분의 사람들이 혁신성과 적응성 양 극단에 위치하지는 않지만 이 둘 가운데 하나의 사고를 선호한다.
인간의 창의적 사고 스타일은 안정적이며 자신의 인격과 관련이 있지만 행동에는 유연성이 있다. 스타일의 변경이 필요한 특정한
상황에서 스타일을 변경할 능력을 대처(coping) 능력이란 부른다. 대처 능력이 뛰어난 사람들이 있다.
2) KAI 측정
KAI는 적응성과 혁신성을 점수로써 구분해주는 도구이다. KAI가 효과적인 점수 범위는 100점을
약간 상회한다. 서로 잘 알고 있는 사람은 서로간에 약 10점 정도의 차이를 보인다. 즉, 비교 대상인 사람이 나 보다 약간 더
혁신적이거나 적응성이 크다. 20점 차이는 다툼과 불편을 초래할 수 있는 정도이고 그 보다 더 큰 차이는 심각한 의사소통 문제를
야기할 수 있다. 사람 간에 중간 점수를 받는 사람은 약 쪽을 중재 할 수 있다. 공식적인 KAI 측정을 위한 사이트가 있으며
인증은 유료이다.
3) KAI의 적용
전략적인 팀 구성, 위원회 구성, 인사 채용, 문제해결, 고객과의 관계 개선 등 다양한 분야에
적용되고 있다. 조직 구성원의 스타일은 대개 조직이 수행하고 있는 업무의 성격에 부합한다. 가령, 혁신적인 벤처 기업인 경우 직원
가운데 혁신성이 큰 사람이 많을 것이다. 그러나 사고의 다양성이 가치가 있음을 인정한다면, 비록 사업 성격에 따라 적합한
스타일의 사람이 더 많겠지만, 다양한 스타일의 사람으로 조직을 구성하는 것이 좋을 것이다.
QR Code는 일본의 Denso Wave에 의해서 개발된 2차원 구조의 기호이며 대중적인 사용을 위해 특허권을 행사하지 않겠다고 선언하고 1994년에 배포 되었다. QR은 Quick Response의 약자이고 특징으로는 빠른 디코딩이 가능하고 기존 사용되어지는 바코드에 비해 대용량, 많은기록, 고밀도, 오류정정 기능 등이 있다.
일본에서는 책의 커버에 책에 대한 정보를 찾아 볼수 있도록 기록되기도 하고, 회전 초밥집의 접시에 붙여져 있거나 거리에서도 쉽게 찾아 볼수 있고 생활전반에 필요한 정보인 즉 명함, 전화번호, 문자, 홈페이지URL등 활용할수 있다.
좀 오래된 책이긴 하지만, 여전히 매우 유용한 스티브 맥코넬의 RAPID Development이란
책에 나오는 RAD 적용 사례입니다.
열심히 하는 코딩만으로는 부족함을 느낄 때 반드시 읽어봐야 하는 내용이죠.
예전에 한번 봤던 책인데 이번에 다시보게되는 기회가 있어서
적용사례 한페이지를 타이핑했습니다. 도움이 되시기 바랍니다.
제품2.0을 만드는 프로젝트의 기술수석 사라의 이야기
첫 회의에서 그녀는 팀원을 소개한 후 바로 본론으로 들어갔다.
"회사 프로젝트 전체의 사후 분석을 검토했습니다. 이제까지 다른 프로젝트에서 저지른 실수 목록이 1킬로미터는 족히 되더군요. 이 목록을 회의실에 붙여놓겠습니다. 우리가 이들 중 어떤 실수라도 저지르는 기미가 보이면 경고해줄것을 부탁합니다. 또한 여러분이 이미 알고 있거나 앞으로 부딪히게 될 가능성이 있는 실수를 추가해 주십시오. 이미 겪은 일을 이유없이 반복할 필요는 없다고 봅니다."
"저는 여러분 각자가 개발 기본에 충실하기 때문에 이 팀 구성원으로 뽑았습니다. 나중에 불필요한 수정따위에 시간을 낭비하지 않을 수 있도록 제대로 요구사항을 분석하고 설계하는 활동이 얼마나 중요한지 여러분은 잘 알 것입니다. 저는 여러분이 그저 열심히 일하기 보다는 현명하게 일했으면 합니다. 무작정 열심히 일하면 그만큼 많은 실수를 저지르게 됩니다. 우리에게는 그럴 시간이 없습니다."
"위험 관리 계획도 세웠습니다. 일정이 너무 꽉 짜여 있기 때문에 미리 막을 수 있는 위험에 발목을 잡힐 수는 없습니다. 이 목록에서 가장 큰 위험은 일정을 맞출 수 없을지도 모른다는 점입니다. 그래서 이번주는 일정을 재평가했으면 합니다. 만약 달성할 수 없다면, 좀더 현실적인 계획을 세우도록 합시다."
팀원 모두가 고개를 끄덕였다. '죽음의 행군'식 프로젝트를 해왔던 사람들은 사라의 이야기에 매우 동감했다.
그 주 후반, 사라는 상사 에디와 회의를 했다. "개발팀과 프로젝트 일정을 진지하게 검토한 결과, 현재 일정으로 현재 요구기능을 완료할 확률이 약 5% 정도라고 결론을 내렸습니다. 아무것도 변하지 않는다는 가정에서입니다. 물론, 항상 뭔가가 변하게 마련이지요."
"그건 안됩니다." 에디가 말했다. "정시 출시 가능성이 적어도 50/50은 되야 합니다. 게다가 출시 후 12개월 동안은 시장의 변화에 대응할 수 있어야 합니다. 어떻게 했으면 좋겠습니까?"
"아직 제품을 완전히 구체화하지 않은 상태라서, 융통성은 약간 있습니다." 사라는 대답했다. "그렇지만 현재 요구기능을 완성하려면, 10개월에서 30개월 정도 걸린다고 봅니다. 너무 범위가 큰 줄은 알지만 우리가 만드는 제품에 대해 더 알기 전에는 이것이 최선의 추측입니다. 제품을 12개월만에 출시해야 하지요? 그 점을 고려한다면 개발자를 더 추가해야 합니다. 그리고 8개월 째에 첫 출시를 한 후 두달마다 출시용 버전을 만드는, 점진적인 출시계획을 세워야 한다고 봅니다."
"괜찮군요" 에디가 말했다. "게다가 이번 프로젝트에서는 기능이 일정보다 더 중요하다고 생각됩니다. 회사와 좀 더 논의한 후에 다시 이야기합시다."
에디는 사라에게 돌아와, 회사가 필요한 기능 완료를 위해 일정을 14개월까지 늘일 용의가 있다고 전했다. 또한 안전을 위해, 점진적인 개발법을 그대로 사용하도록 지시했다. 사라는 안심하며, 그것이 좀더 현실적인 목표라고 생각한다고 대답했다.
첫 몇 주 동안에 팀은 구체적인 사용자 인터페이스 프로토타입을 작성했다. '실수 목록'에서 프로토타입에 들이는 지나친 노력을 경고하였으므로, 프로토타입 치장을 피하기 위해 기간확정 방법을 사용하기로 했다. 팀은 구현할 기능을 결정하기 위해 고객들을 면담하는 데 프로토타입을 이용하고 사용자 피드백에 따라 이를 여러 차례 수정했다.
사라는 계속 위험 목록을 관리했다. 그녀는 프로젝트에서 가장 큰 위험은 '엄청난 수정을 요구하며 일정을 늘이는 낮은 품질', '무리한 일정', '경쟁력을 위해 도중에 추가하는 기능', 이 세 가지로 결정했다. 사라는 점진적인 출시 계획으로 '품질 위험'에 대응한다고 보았다. 팀은 8개월째에 첫 버전을 품질관리부에 넘길 예정이고, 품질관리부는 이에 맞춰 테스트 스크립트를 개발할 것이다.
팀은 기능 우선순위 목록을 만들어 일정 위험을 다루었다. 14개월안에 무조건 많은 기능을 개발하는 방법도 있겠지만, 제품을 두 달마다 출시가능한 상태로 만듦으로써 어느 시점이든 출시할 수 있는 제품을 확보할 것이다. 팀은 또한 몇가지 기능에 대해 구현시간을 줄이는 방식으로 설계를 했다. 시간을 덜 들여 구현할 기능은 별로 매끄럽지는 않겠지만 쓸만한 것이며, 이런 결정으로 일정 위험을 상당히 줄일 수 있었다.
팀은 '경쟁력 향상용 기능 위험'을 두 가지 방법으로 대응했다. 그들은 5개월정도 시간을 들여, 프로토타입한 모든 기능과 3.0에 포함할 기능을 지원할 수 있는 기반구조를 설계하였다. 이 기반구조로 변화를 큰 어려움 없이 수용하기 위함이다. 또한 팀은 12개월 째 시간을 할당하여, 경쟁사의 제품을 분석하고, 프로토타입을 재검토하기로 했다. 그 후 마지막 두달 동안, 경쟁력향상을 위해 필요한 기능을 구현하기로 했다.
6개월 시점에서 설계를 완성함과 동시에, 팀은 8개월째에 품질관리부에 넘길 첫 출시용 버전을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 첫 버전은 별로 많은 기능을 포함하지는 않았다. 그러나 품질이 우수했고, 그 후 개발에 좋은 바탕이 되었다. 8개월째에 다시 10개월 지점을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 12개월 지점을 위해서도 같은 방법을 사용했다.
12개월째 팀은 계획대로 경쟁회사제품을 분석했다. 경쟁사 하나가 10개월 무렵에 좋은 제품을 출시했고, 그 제품에는 우수한 기능이 들어 있었다. 제품2.0이 경쟁력을 가지려면 꼭 추가해야 하는 기능이었다. 팀은 새 기능들을 우선순위 목록에 추가하고 우선순위를 재조정하여 마지막 두달을 위한 상세계획을 세웠다.
그 즈음에 연구원들 중 호세가 좀더 나은 대화창 구성을 생각해내고, 팀회의에서 안건으로 제시했다. 선임 연구원 조지가 대답했다. "아이디어는 좋아. 바꾸는 편이 낫다고 생각하지만, 지금은 안되네. 호세 자네는 하루정도면 고칠수 있겠지만, 문서화 일정에 일주일 혹은 그이상 영향을 미치네. 버전 3.0 목록에 넣으면 어떨까?"
"문서화 일정에 미치는 영향을 미처 생각하지 못했습니다." 조는 말했다. "좋은 지적이군요. '나중에 할일' 목록에 추가하도록 요청하겠습니다.
14개월째 팀은 계획대로 최종 소프트웨어를 출시했다. 제품2.0의 품질은 8개월째부터 테스트를 해왔으므로 우수했다. 문서부는 소프트웨어가 완성되기를 기다리는 대신 상세한 인터페이스 프로토타입을 바탕으로 일할 수 있었기 때문에, 사용자 매뉴얼 역시 최종 소프트웨어와 같은 시기에 끝낼 수 있었다. 개발팀은 우선순위가 낮은 기능까지 구현할 시간은 없었지만 중요한 기능은 모두 구현했다. 제품2.0은 성공적이었다.
이미 많은 유수의 글로벌 회사들은 소셜미디어의 특성을 간파하여 이를 다양한 기업 활동,
즉 인재를 선발하고, 기업 생산성을 높이고, 기업의 혁신과 협업을 유도하며,
기업에대한 평판을 높이는 데 효과적으로 활용하고 있다
를 제공한다(델은 트위터를 통해 수백만 달러어치의 제품을 판매했을 뿐만 아니라 트위터 가입자
를 델 홈페이지로 유도하여 트위터 전용 상품을 판매하고 있다)
둘째, 기업이 대화를 주도할 수 있는 에코 시스템 구축을 통해서 전사적 발언이 가능하다
현재 국내 기업들은 트위터 계정을 만들고 홍보팀 내 담당자를 지정하여 소셜미디어를 활용하고 있다.
앞으로는 소셜미디어를 홍보의 일환이 아닌 기업 경영의 전체적 흐름에서 바라보아야 하며,
기업 커뮤니케이션 전체를 총괄하여 하나의 목소리를 낼 수 있도록 하는것이 필요하다.
셋째, 기업의 구성원간 쌍방향 의사소통의 도구로 활용하면 문제의 빠른해결이 가능하다.
소셜미디어는 사용자의 상호 작용과 관계에 의해 컨텐츠가 생산되고 확산되는 메커니즘을 가지고 있다.
주변의 네트워크를 통해 부여된 신뢰성을 기반으로 한 정보가 급속도로 퍼져나가는 특징을 지니고 있다.
홈페이지를 거쳐 블로그, 페이스북, 트위터로 이어지는 소셜미디어의 큰 흐름에 정치권 및 많은 기업들이 주목하는 것도 이 때문이다.
이는 과거의 통제 패러다임을 근간으로한 기업 내 관리는 더 이상 통용되기 힘든 시대가 도래했음을 의미한다.
대기업이든 중소기업이든 기업은 앞으로 더 이상 내부 임직원의 대내외 활동을 일일이 통제할 수 없다는 점을 인식해야 한다.
넷째, 기업경영 투명성 높이기
소셜미디어는 모든 것을 투명하게 보여준다.
과거에는 기업이 정보의 비대칭성을 이용, 기업에 유리한 일방적, 선별적 정보만을 소비자에게 전달함으로써
자사 제품을 홍보하는 것이 가능했다. 그러나 지금은 투명성이 경영의 기본으로 여겨지는 시대다
