블로그 이미지
Max.

calendar

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Notice

2008.11.29 10:28 이전글(~2009)
Spring in Action SE는 Spring Framework 2.0을 기준으로 쓰여진 책이다. 그동안 몇몇 한글로된 Spring 관련 책들이 나왔고 각각의 특색이 있어 좋지만, 개인적인 기대감을 다 담을수 있는 책을 찾기 힘들었다. 따라서 힘들더라도 원서를 읽을수 밖에 없었는데, 이 번역서가 기대감을 담을수 있을지 기대된다.(번역이 힘든건 알지만 글의 매끄러운 흐름만 유지해도 그것으로 충분하다.) 스프링인액션 1판은 원서도 번역서도 그리 신통치 않았는데, 2판은 상당히 평이 좋고, 내 스스로도 좋은책이라 생각하고 있다.
사용자 삽입 이미지


사실 현재 Spring은 2.5.x로 기존의 2.0과는 많은 변화가 있었다. 또한 앞으로 3.0을 바라보고 있다. 그러나 기본 사상이 변한건 아니다. 그래서 일부 Spring 고전은 아직도 인기가 있지 않은가. 원서내용에 충실했다면 Spring 처음 입문자는 물론, 경험자도 옆에 두고 볼만한 좋은 한글 책이 나옴을 기쁘게 생각한다. (역자의 블로그에서 고민의 흔적을 느낄수 있는 것을 보면 기대를 하게 만든다.)

고맙게도 해당출판사(ITC)에서 2권을 보내준다고 한다.
모두 Spring Study Club에 스터디 회원 중 가장 열성적인 사람에게 주는 것이 좋을것 같다.
현재 Yes24에서 예약 판매하고 있으니 급하신 분은 미리 예약하는 것도 좋을듯 하다. 사실 많이 팔려서 더 많은 분들이 번역서를 내놓으면 좋겠다.

앞으로도 저번과 이번처럼 한글로된 Spring책이 나오면 꼭 블로그에 남길 생각이다.
한국의 모든 개발자에게 꽃피는 봄날을 맞이할때까지....
신고
posted by Max.
2008.11.27 09:40 이전글(~2009)
전쟁에 준하는 사건이다. 이렇게 해서 그들이 얻는게 있다고 생각하는거지.... 어떤 철학자의 말처럼 인간은 본래 이기적인게 맞을지도 모른다.....

관련기사 : 뭄바이 '테러의 밤'…최소 80명 사망 한국인 전원 무사대피

공격이 시작된 것은 이날 밤 10시 30분(현지시각) 경. 여러 명의 괴한들이 뭄바이 남부에 위치한 차하트라파티 시바지 철도역 대합실 등에 난입해 AK-47 소총을 난사하고 수류탄을 던지면서 시작됐다.

다행히 한국사람은 모두 피신했다지만, 세상에 참... 정글스러운 일이 많이 벌어진다.


▲ 전경 투입 장면 ⓒ로이터=뉴시스
신고
posted by Max.
2008.11.26 16:51 이전글(~2009)
통계를 산출하기 위한 과정이나, 방법이 어떻고를 떠나서 결과가 믿을만하다고 가정하자.
그런 통계자료는 특히 높으신분들이 좋아하고, 고객들도 좋아한다. 어떤 설득력있는 작업에서 근거자료로 요긴하게 쓰이기에 많은 논문이나 이론에서도 자주 등장한다. 더러는 통계를 기반으로 어떤 이론이나, 통찰력을 이끌어 내는데 가끔 찜찜할때가 있다.

가령 오늘자 이기사를 보자. "한국, 세계 최악의 부동산 거품덩어리" 기사의 요점은 제목 그대로이다. 사실 우리나라 부동산이 얼마나 거품이 있는지를 이번에 통계청이 발표한 자료(해당 자료를 다운받을수도 있다.)를 기반으로 그와 같은 기사를 썼다.

사용자 삽입 이미지


그런데 비교 대상국가의 목록이 좀 수상해 보이지 않는가? 혹시 인구 단위당 밀집도나, 국가당 산업의 다양성이 주는 가중치, 또는 비교대상 국가의 형평성 등이 영향을 미치는 요소가 아닐까? 예를 들면, 홍콩이나, 싱가포르 처럼 도시국가에 해당하는 국가와 비교되었으면 어때었을까?

여론조사도 일종의 통계다. 여론조사가 설문내용의 미묘한 늬앙스에 따라 결과치가 다르게 나오듯 어떠한 통계자료도 그 비교대상이나 샘플링에 따라 기대하는 결과가 다를수 있다. 좀더 설득력있는 통계자료를 제시하기 위해서는 이런 여러가지 변수를 고려해야함이 어려움을 가중시키는것 같다.
신고
posted by Max.
2008.11.26 13:50 이전글(~2009)


귀찮이즘의 극치인가, 구글러의 예술인가....


keyboardr.com from Julius Eckert on Vimeo.
신고
posted by Max.
2008.11.24 16:14 이전글(~2009)

SIPOC 모델은 어떤 프로세스를 한눈에 개괄적으로 보기 위한 다이어그램이다.
어떤 프로세스를 정의하고, 그 프로세스가 되어가는 과정을 일련의 단계로 구성함으로써 고객의 결정적인 요구사항만 만족하게 프로세스를 상위수준에서 정의한 것이다.(자세한 프로세스를 명기한 프로세스 명세서 같은것은 아니다.)

사용자 삽입 이미지

Supplier – 프로세스 작업 대상이 되는 사람이나 조직
Input – 공급자가 제공하는 정보/자료
Process – Input의 정보/자료의 변형이 이루어지는 일련의 단계
Output - 고객이 사용하게 되는 제품이나 서비스
Customer – Output을 받는 사람 또는 프로세스


각각의 단계별로 상위수준에서 정의하되, 특정 프로세스에서 근원이 모호한것은 상세한 프로세스 맵을 추가적으로 만들수 있다.(마치 모델링에서 특정 유스케이스에 대한 상세 유스케이스를 작성하듯이)
SIPOC 또는 반대로 COPIS로 표현하기도 한다.

신고

'이전글(~2009)' 카테고리의 다른 글

통계에 대한 해석이 올바른가?  (0) 2008.11.26
keyboardr.com  (0) 2008.11.26
SIPOC 모델  (0) 2008.11.24
전략에 대한 오해  (0) 2008.11.24
요구사항 분석툴 - 카노분석(Kano Analysis)  (0) 2008.11.24
한정된 자원와 머리카락수  (0) 2008.11.20
posted by Max.
TAG COPIS, SIPOC
2008.11.24 15:56 이전글(~2009)
프로젝트에서 '전략'이란 단어는 사막의 모래알처럼 남발하는 경향이 있다. 거의 모든 기획문서나 계획따위 문서에서는 전략이란 단어가 필수적으로 들어가기 마련이다. 심지여 계획 대신에 전략이란 단어를 선택하고 좀더 폼나길 바라는 의도일 것이다.

전략의 어원은 전쟁에서 나온듯 하지만, 일반 비지니스 세계에서는 일반적인 계획보다 상위개념으로 쓰인다. 그래서 비지니스 또는 프로젝트에서 전략의 개념을 나름대로 정리해보면 다음과 같다.

전략은 여러가지 방법중에 하나를 선택하고 집중하는 것이다.
여기서 선택한다는 말은 여러가지 방법을 모두 한다는 뜻이 아니라 그중 가능성 있는 또는 추구하는 목표 달성에 가까운것을 선택한다는 뜻이다. 선택한것에 대해서는 모든 역량을 집중하여 목표를 이루는 행위일 것이다.

전략은 모든것을 다 잘하자는 것이 아니다.
선택과 집중은 할수 있는 모든 방법에 대해서 다 잘할수 없을때 전략을 세우는것이며, 이는 곧 선택된 방법 이외엔 포기할줄 아는 것을 말한다. A,B,C 세가지 방법을 통해서 목표를 당성할수 있다고 했을때, 그중 A를 선택하고 실행하는것이 전략에 속한다. B,C는 포기해야 한다.

물론 A,B,C 모두 잘할수 있다면 전략이 필요없다.(자원이 한정적이지 않으면 경제 개념이 필요없듯이...)

이런 전략에 오해하는 분들의 예를 들어보면, 전략이 기존의 방법을 모두 실행하면서, 새로운 어떤 무언가를 추가적으로 하는 행위라고 인식하는것에 있다. 전략은 기존에 A,B,C업무를 하고 있다고 하면, 그중 장기적인 회사 비전과 전략에 따라 A를 강화하는 전략이라면, 상대적으로 B,C는 없어지거나, 약화되어야 한다. 그것이 전략이다.

좀더 쉬운 예를 들어보자.
마케팅에서는 블루오션전략이란 고전이 인기이다. 지금도 이 방법은 마케팅에서 중요한 자리를 차지하고 있다. 블루오션은 지금까지의 레드오션과 같은 Key 요소 중 전략적으로 특정 요소를 강화함으로써 새로운 대양(비지니스영역)을 창출해 내는 전략적인 방법론이다. 여기서 강조하는것은 바로 그 Key요소를 레드오션의 회사들과 반대로 가져감으로써(보통은 낮은 요소를 높이고, 높은요소를 낮추는 전략) 기회를 만들어 낸다. 바로 이런 행위가 전략이다.

전략은 지금하는것도 잘하고, 또 새로운 것도 잘하자는 것이 아니라, 지금 있는것 중에 일부를 포기하고, 전략적인 요소를 강화하자는 것으로 새로운 업무가 더 많아짐으로써 부담을 더하고자 하는것이 아님을 알아야 한다.

신고

'이전글(~2009)' 카테고리의 다른 글

keyboardr.com  (0) 2008.11.26
SIPOC 모델  (0) 2008.11.24
전략에 대한 오해  (0) 2008.11.24
요구사항 분석툴 - 카노분석(Kano Analysis)  (0) 2008.11.24
한정된 자원와 머리카락수  (0) 2008.11.20
인성이 중요한 이유  (0) 2008.11.20
posted by Max.
TAG 오해, 전략
2008.11.24 11:54 이전글(~2009)

고객의 요구사항은 여러가지 유형으로 나뉘지만, 보통은 분류없이 책임자에 의해서 우선순위화 되어 문서로 제출되거나, 혹은 인터뷰를 통해서 우선순위 없이 생각나는대로 받아올때도 있다. 어쨌든 담당자의 생각을 정리하여 나열하고 그것을 분석하여 요구사항 항목에 잘 정리되어야 한다.

요구사항을 잘 정리하고, 우선순위화 하거나, 특성별로 분류하는 일은 쉬운일이 아니다. 고객의 요구사항은 그 자체에 문제가 있을수도 있고, 자기논박적인 부분도 상당할때가 있다.

이러한 분석에 도움이 될만한 것이 카노박사의 카노모델이다. 그는 요구사항을 3가지 범주로 나누고 다음과 같이 설명한다.

1. 불만족 요인 혹은 기본적인 요구사항 – 당연히 있을 거라고 생각하는 특성, 최소한의 기대치를 말한다.
2. 만족 요인 혹은 가변적 요구 사항 – 고객의 평가등급을 결정하는 요소로 다다익선의 범주에 속한다.
3. 감동 요인 혹은 잠재적 요구 사항 – 고객이 기대하는 것 이상의 특성이나 요인 즉, 기대치 않은 추가적인 서비스를 제공하는 것을 말한다.

그의 그래프를 보면 더 쉽게 이해할수 있다.

사용자 삽입 이미지

이 그래프에는 Time(시간)이 표현되지 않았는데 시간은 좌상향에서 우하향으로 진행된다.

요구사항 분석이 중요한 이유는 대부분의 고객이 요구사항을 알기 힘들며, 안다고 해도 우선순위를 분별할 능력이 낮다는 것이다. 사실 대부분의 프로젝트가 어려워지는건 프로젝트 말미에 '이산이 아닌개벼~!' 라는 말일 것이다. 이것은 정확한 요구사항 분석이 그만큼 힘들고, 요구사항이 끊임없이 변함을 함축적으로 말해준다.

그래서 요구사항 분석을 좀더 합리적으로 할 필요가 있다.

신고

'이전글(~2009)' 카테고리의 다른 글

SIPOC 모델  (0) 2008.11.24
전략에 대한 오해  (0) 2008.11.24
요구사항 분석툴 - 카노분석(Kano Analysis)  (0) 2008.11.24
한정된 자원와 머리카락수  (0) 2008.11.20
인성이 중요한 이유  (0) 2008.11.20
전사적인 개발 표준화의 중요성  (0) 2008.11.19
posted by Max.
2008.11.20 15:59 이전글(~2009)

언제나 프로젝트에서 자원은 한정적이였다.
그리도 또 언제나 프로젝트에서 기대치는 투입된 자원이상의 것이였다.
언제나 이 사이에서 고민하다 머리빠지는건 팀리더다.

그래서 자원활용에 대한 극대화를 팀리더는 고민한다.... ing이다. 언제나 처럼...
그거 아는가?
SK SUPEX란 방법론의 이름의 유래가
인간이 도달할수 있는 극한(?)의 경영상태에서 따론 말이란 것을...

그렇다. 이미 기업은 극한까지 가고 있다.
도대체 이렇게 까지 사람 등꼴을 뽑을 이유가 있는가?

신고

'이전글(~2009)' 카테고리의 다른 글

전략에 대한 오해  (0) 2008.11.24
요구사항 분석툴 - 카노분석(Kano Analysis)  (0) 2008.11.24
한정된 자원와 머리카락수  (0) 2008.11.20
인성이 중요한 이유  (0) 2008.11.20
전사적인 개발 표준화의 중요성  (0) 2008.11.19
전략에 대한 명언  (2) 2008.11.18
posted by Max.
TAG 극한, 자원
2008.11.20 09:22 이전글(~2009)
인성이 사회생활하는데 중요한 이유는 여러가지 이다. 최근에 대기업이나, 심지여 대학입학에서도 인성을 중요시한다는 뉴스를 봤다. 인성이 기업에서 중요한 이유는 업무를 원활하게 처리하기 위해서 서로간의 협력이나 커뮤니케이션을 위해서 일것이다. 이것은 아주 중요한 덕목중에 하나다.

특히 관리자급 이상의 직급이나 직위에서는 더욱 그렇다. 부서간 협력이 전사적인 전략에서 얼마나 중요하던가. 그런데 이런 중요한 덕목을 가르치거나, 조언해주는 중소기업은 드물다(물론 내 경험치에 일반화된 사실로 제한되지만). 그러니, 관리자들중에는 협력과 거리가 멀거나, 관리자임에도 불구하고 자기자신만 생각하는 사람이 있다. 이런류의 관리자는 결국 시장의 힘으로 사라지게 되지만, 같이 하는 순간까지는 주변사람을 힘들게 한다.

그러나 자기자신만 아는 관리자라고 해도 협력을 이끌어 낼수가 있는데, 그것은 그관리자에게 도움이 될만한 정보를 제공함으로써 단기간의 협력을 이룰수 있다. 그러나 그 관리자는 정보제공자를 단순히 이용하는 것이외엔 어떤 의미도 없을것이다.

이런 관리자를 변화시킬수 있을까? 나는 오랜(?) 경험에 의해 사람이 사람을 변화시킬수 없다는걸 안다. 변화를 스스로 이루어지며, 그런 환경에 잠시나마 노출시켜주는 것이 최선이다. 사실 어쩔때는 그런류의 사람들과 담을 쌓고 무시로 일관하고 싶을때가 많다.

무지하거나, 실수하거나, 의지가 약한 것은 얼마든지 협력에 의해서 변화할수 있지만, 자기자신만 아는 사고방식(또는 독선)을 바꾸는것은 정말 힘든 일인것 같다.대부분 이런사람들 도리(예의)도 없을 뿐더러, 자기 세계관에 빠져 진실을 똑바로 보지 못한다.

사람을 상대로 하는게 어렵다기 보다, 지겨울때, 프로그래머란 직업이 좋은 직업이란 생각을 하곤한다. 프로그램이 좋은건, 내자신을 프로그램을 통해서 볼수 있기 때문에 스스로 반성하고, 스스로 부족함을 항상 느끼기며 자기성찰을할수 있는 기회가 많기 때문일 것이다.

신고
posted by Max.
2008.11.19 14:45 이전글(~2009)

회사 규모가 100명 이하이면, 각 개발팀간의 표준화가 없어도 그럭저럭 굴러간다. 심지여 그 이상의 규모를 가진 회사도 팀별로 또는 프로젝트별로 템플릿만 맞다면 이역시 그럭저럭 굴러간다.

그러나 그저그런 그럭저럭 굴러가는 조직을 원하는 회사는 어디에도 없다. 당연히 표준화가 필요한데, 이게 어느정도 규모가 커지기 시작하면, 말처럼 쉽게 되기 힘들다. 각 사업부 또는 개발팀별로 담당하는 도메인 특성 때문에 표준화가 힘들어 진다. 여기에 사업부 이해관계까지 얽히면, 효율성 보다는 정치적인 당위성이 더 강조되고, 영원히 표준화는 꿈으로 남을수 있다.

그럼 왜 표준화를 할려고 하고, 왜 필요한가
표준화는 일관된 목표를 향해 기민하게 움직일수 있게 하는 발판(기틀)을 제공한다. 특정상황에 기민하게 대처하기 위해서는 통일된 행동규칙이 모든 팀에 적용될수 있어야 일사불란하게 움직이고 변화에 강한 모습을 보일수 있다. 각 팀마다 규정이 다르고, 대처방안에 모순이 발생되면 목표를 향해 기민해질수 없다.

개발분야에 있어 표준화는 어떤것이 있을까
표준화는 획일화가 아니다. 표준화는 형식(틀)이 같음을 말하고, 획일화는 내용(영혼)까지 같음을 말한다. (몇몇 AF는 획일화를 조장하기도 한다. RIA? SI 역시 그런 확일화가 존재한다.-다 그런건 아니고-) 개발활동에 있는 모든것을 표준화 할수 있는데 대략 분류를 하면, 업무프로세스, 개발환경(툴), 프로그램구성, 지식, 사람 정도일 것이다. 이중에서 다루기 힘든 요소는 회사차원에서 결정되어 지는것이고, 그나마 개발관리자가 다루기 좋은것은, 업무프로세스, 개발환경, 프로그램구성 정도이다. 지식, 사람은 어떤 표준화 시스템으로 커버하기엔 다소 무리가 있다.

이들 표준화 안건에 대한 각각의 세부적인 핵심요소를 추려내서 표준화 작업을 진행한다면, 100명 이상의 규모에서도 표준화를 이룰수 있을 것이다. 물론 표준화 활동 보다, 개발선임자들의 할려는 의지가 훨씬더 중요하다.

표준화가 어느정도 정립되면 이룰수 있는것은?
변화다. 다른말로 진화할수 있는 기반이 마련된 것이다. 변화의 궁극적인 결과가 무엇인지 몰라도 된다. 변화를 추구할려고 노력하고, 그런 과정에서 많은것을 얻을수 있다. 물론 경제적인 부와 지식 나아가 더 좋은 아빠와 애인이 될수 있다.

이는 개발문화 더 나아가 회사문화를 바꿀수 있는 출발점이다.
개발자 하면 야근에 찌든 사람이 아닌, 일반 회사원 처럼 일하는것을 넘어서, 엘리트 또는 존경은 아니더라도 선망의 대상이 될수 있는 직업군이 될수 있다. 꿈이 아니라 가능하다. 계획을 세우고 실행에 옴기면 된다.

출발한 표준화에서 부터 시작해야 한다.

'개발 전분야에 대해 표준화를 진행할려고 하니, 걸리는것이 한두가지가 아니다.
가장 어려운건 개발자가 개발자를 선득하는것인것 같다.'
신고

'이전글(~2009)' 카테고리의 다른 글

한정된 자원와 머리카락수  (0) 2008.11.20
인성이 중요한 이유  (0) 2008.11.20
전사적인 개발 표준화의 중요성  (0) 2008.11.19
전략에 대한 명언  (2) 2008.11.18
MB 정세변화 못읽거나, 외면하거나  (0) 2008.11.18
BPM의 주요 Step.  (0) 2008.11.17
posted by Max.
TAG 표준화