2017년 소개된 아마존 Jeff Bezos의 추천도서 12권.

대부분 번역서가 나왔을텐데 아마도 절판된 책이 많을 듯하다. 분야의 고전을 통해 why?를 제대로 이해하는 것이 필요하지 않을까 한다. 그것이 빨리 가는 길이라는 생각이다. 변하는 시늉이 아니고 진짜로 변할려면 제대로 알아야 하니까?

여기에 있는 책 중에 SW공학 관점에서 개인적으로 더 빨리 읽고 이해했더라면 좋았을 텐데, 그래도 늦게라도 읽어서 좋았고 많은 생각을 하게 한 책은 Lean Thinking(절판), The Mythical Man Month(인사이트), The Goal 3권.

https://www.cnbc.com/…/the-12-books-that-helped-form-billio…

빌 게이츠의 제품 개발 관리 원칙

MIT가 마이크로소프트의 협조하에 연구하여 1995년 출판하고, 삼성경제연구소에서 1997년 번역한 "마이크로소프트의 비밀(Microsoft Secrets)에서 발췌한 빌 게이츠의 제품 개발 관리 원칙입니다.

*. 사족하나 --- 애자일, DevOps에 대하여 자세히 살펴보다 보니 고전이된 책들이 있는데, 찾아 보면 아마존에서는 팔리고 있으나 국내 번역본은 대부분 절판. 그래도 SW관련 많은 고전은 인사이트라는 출판사에서 꽤 많이 내놓고 있다. 수익성이 별로일 텐데 그나마 고마움과 함께 다행이라는 생각을 ....

• 우수한 조직원과 작은 팀들 : “우리는 대단히 우수한 인력으로 작은 규모의 팀들을 조직했습니다….. 그리고 우수한 개발자일수록 우수한 개발자들과 같이 일하기를 좋아한다는 점을 잘 이용했습니다.”
• 대규모의 팀이 마치 작은 팀처럼 일하도록 되어 있는 개발 과정 : “그런 다음 점차 인원 수를 증가시켜 작업을 구체화 합니다. 단계적인 목표를 향해 전체적으로 접근하여 결점을 없애갑니다. 이것이 프로젝트팀 규모에 대한 전반적인 내용입니다.”
• 팀들 사이에 상호의존도를 감소시키는 제품 설계 : “설계가 좋으면 하나의 개발팀 내에서도 상호의존도를 줄일 수 있습니다.”
• 한 장소에서 대부분의 개발이 이루어짐 : “우리 모두는 특별한 경우를 제외하고는 여기 한 장소에서 작업하죠. 그 결과 무슨 문제가 생기면 얼굴을 맞대고 협의할 수 있는 장점이 있습니다.”
• 개발하려는 시스템과 같은 시스템을 사용해서 작업하는 조직원들 : “우리의 개발 시스템과 목표로 하는 시스템은 같습니다. 혹 그렇지 않은 사람도 있더군요.”
• 단일한 개발 언어 : “가장 좋은 개발언어가 무엇인지 토론할 필요없이 우리는 단일한 언어를 쓰고 있습니다."
• 인력지원에 과감한 투자 : “조직원에게 필요한 도구를 기꺼이 지원할 뿐 아니라 조직원 각자에게 개인 사무실을 제공하고 있습니다.”
• 자사의 개발도구를 사용 : “우리 회사의 제품을 직접 사용하고 있기 때문에 제품을 관리할 수 있을 뿐 아니라 이로써 얻는 이점이 큽니다.
• 여러 명의 조직원이 제품의 세부사항을 이해하고 있음 : "대용량의 프로그램 코드를 한 사람이 전담하게 하지 않습니다. 가령, ‘프리마돈나만이 이 코드를 바꿀 수 있다니' 같은 상황은 만들지 않죠.”
• 제품개발과 기술적 결정을 함께 하는 관리자 : “기술분야에 대한 지식이 없는 관리자를 채용하지 않습니다."
• 기술과 사업능력을 적재적소에 발휘하여 신속한 결정을 내림: 우리는 기술과 사업 두 가지를 동시에 생각합니다. 만약 결정이 어려울 경우 경영진이 판단하거나 저에게 전자우편을 보냅니다. 물론 빠른 결정을 내리지요."
• 고객으로부터의 많은 피드백 : “대부분의 회사들은 자기 회사 소프트웨어 제품에 관한 소비자의 의견에 무관심하죠. 그러나 우리는 미국에서도 2천명 이상의 직원들이 고객이 주는 피드백을 전화를 통해 접수합니다.”
• 과거 프로젝트를 통한 학습 : “프로젝트가 끝나면 그것에 대해 해부를 한 후 오류의 출처를 밝히고 대처방안을 찾습니다.”

- 마이크로소프트의 비밀, 1997, 삼성경제연구소 (Microsoft Secrets, Michael A. Cusumano & Richard W. Selby, 1995)

Design Thinking

https://www.ideou.com/…/inspiration/what-is-design-thinking…

IDEOU.COM

What is Design Thinking?

Design thinking has a human-centered core. It encourages organizations to focus on the people they're creating for, which leads to better products, services, and internal processes. When you sit down to create a solution for a business need, the first question should always be what's the human need....

미국 DOD Defense Innovation Board 보고서

Agile이 일상화되었고, h/w 조차도 s/w처럼 변경가능해야 하고, F35 개발에 DevOps(DevSecOps)를 적용해 성공한 사례가 있으며, 모든 s/w 외주 sw 는 반드시 source codes를 납품 받아야하고, 반드시 DOD 정규직이 외주 개발 소스를 직접 수정하거나 API 를 통하여 수정 가능해야 한다.

목표는 적보다 빨리 무기체계를 바꿔야 한다는 거. 기존 제조 패러다임으로는 불가능하니 민간 BP인 Agile/DevOps를 적용할 수 밖에 없다는 결론.

우리는 어이하고 있을까? 국방비 투자로 보면 여력은 충분한데 성숙도가 될까? 단편적인 지식이 아닌 전체를 조화롭게 아우를 전문가 집단이 있을까?

근래에 정적 분석과 동적 분석이 신뢰성 테스팅이라하고, 정적 분석 도구가 인스펙션 도구이고 이 도구를 돌리면 인스펙션이라던 그 분야 담당자(전문가?)의 언급이 귓가를 맴돈다.

Agile/DevOps가 또 다른 유행이 아니고 각 조직의 근본적인 변화의 출발점이 되기를 바래본다. 성공한 조직이 경쟁에 앞서 가겠지만. Design Thinking, Lean Thinking과 함께.

국방이 아닌 민간에서도 dib 보고서를 숙독하기를 권한다.

https://innovation.defense.gov/

양재 가는 길에 지하철에서

INNOVATION.DEFENSE.GOV

The Defense Innovation Board Holds Quarterly Public Meeting at Silicon Valley

The Defense Innovation Board -- an independent federal committee advising the defense secretary on various issues that focus on people and culture,…

Agile, DevOps, Design Thinking & Lean Thinking

TPS, 린씽킹, Agile, DevOps 등을 더 살펴보고 내친김에 구글, 아마존, 마이크로소프트의 문화를 이해하니 본질은 동일하다는 생각이다. 이러한 기본, 일부 애자일론자는 마인드세트라고하는데, 동의한다.

이러한 문화없이 요즘 핫한 AI, IOT, DevOps에 성공적으로 안착할 수 있을까? 물론 이제까지 그래왔듯이 한국은 또 다시 해내리라고 본다. 축적없이 개인의 희생을 바탕으로. 투자 대비 효과를 보면 피할 수 있는 시행착오가 너무 많겠지만.

1년 전

내 추억 보기chevron-right

김영온

2018년 11월 7일 · 

로저 마틴이 디자인적 사고(디자인 씽킹)은 분석적(과학적) 사고와 직관적(통밥, 짬밥, 경험/륜)의 균형이라고 한다. 레오나르도 다빈치, 에디슨, 스티브 잡스 등을 디자인 씽킹 분야에서 대표적인 인물로 소개한다.

"The Mythical Man-Month"라는 SW공학 고전의 저자인 Brooks는 좋은 아키텍처(설계)는 합리성(과학, 이론)과 경험(짬밥)의 균형을 통해 얻는다고 한다.

하나 더, 품질의 대가 데밍도 "이론없는 경험에서는 아무것도 배우지 못한다." 다시 말하면 이론적인 뒷받침없는 경험은 별도움이 되지 못한다는 것이다.

놀랍게도 한 분야에서 일가를 이룬 사람들이 다른 분야에서 같은 이야기를 하였다. 결론은 이론과 직관의 균형을 말하는데, 이론없는 경험 그리고 경험없는 이론의 한계를 말하는 것이다.

상이탑으로 이론(학문)의 대표기관인 서울대 공대 교수들이 공저한 축적의 시간/기간 2권의 책은 학문(이론)과 경험의 축적에 게을리 한 우리 사회에 주는 메시지를 잘 담고 있다. 학문의 축적, 경험의 축적 어느 분야가 더 문제일까? 개인적인 의견은 産學硏 3분야 모두 동일한 문제를 가지고 있다고 본다. 각 분야에 종사하는 당사자는 인정하기 어렵겠지만, 요즘 말하는 학문의 융합 이전에 産學硏의 융합이 먼저가 아닐까? 자기 분야에서의 융합에 문제가 있다면 학제간 융합이 가능할까? 해야 하지만. 국내에는 미국의 Stanford 대학교의 d.school과 MIT Media Lab와 같은 시도를 하는 대학교가 있는가? 없다면 그 원인은 무엇일까?

SW산업계에 종사하면서 자주 들었던, 개인적으로 동의할 수 없었던 이야기 "그건 이론적이야." "그건 한국 문화 때문이야." "정부의 정책 때문이야." 등등. 과연 이론을 제대로 이해하고 말하고 있는 것일까/ 과연 한국 문화가 외국이랑 그렇게 다른 것일까? 유독 SW산업에서만. 정부의 정책은 누가 제안한 것인가? 다시 한번 되돌아 보아야 하지 않을까?

" 내 탓이요! 내 탓이요!"

12가지 애자일 리더쉽

https://www.linkedin.com/…/12-dimensions-agile-leadership-…/

이 웹사이트 정보

LINKEDIN.COM

The 12 Dimensions of Agile Leadership

Based on several years spent supporting and coaching leadership, at all levels of an organisation, I have come to value twelve dimensions in the way leaders think and act that will sustain an Agile transformation and Agile delivery. This article introduces those twelve dimensions and goes into a lit

아웃소싱이 기업을 망친다 - GM 사례

한 때 EDS의 모 회사였던 GM이 아웃소싱 업체 의존을 3% 이하로 낮추고 In-sourcing하였다는 기사입니다.

"..... GM은 IT 정규직 1,400명과 계약직 2만 명을 채용했다. 이후 IT 모델을 전면 개편해 아웃소싱 업체에 대한 의존도를 크게 낮췄다. 현재는 약 3%에 불과하다. 동시에 18만 명의 글로벌 직원을 지원하는 9,500명의 IT 노동자로 구성된 팀을 구축했다."

GM CIO 모트가 생각하는 이상적인 IT 운영 모델은

"실제 혁신은 IT 전문가가 기업의 전략을 엄격히 따를 때 이루어진다. 같은 배에 탄 모든 사람이 선장인 CIO의 지휘하에 같은 방향으로 나아가야 한다. ......외부 계약자와 아웃소싱 기업은 성공을 방해한다. 기업은 비즈니스 전략을 실행하고 발전시키기 위해 훌륭한 내부 IT 인력이 필요하다...... IT는 전략적인 기업 자산이며 혁신과 정보의 속도가 성공의 핵심 요소다. 다시 말하지만 아웃소싱을 거부해야 한다."

전적으로 동감하며, 국내에서도 공공 및 민간에서 근본적인 재검토를 해야하지 않을까 생각합니다. 성공적인 Digital Transformation (IoT, 4차 산업혁명, AI, Smart Factory, Connected World....)을 통한 도약을 위해서는.

2018/08/30 CIO 매거진

원문보기:
http://www.ciokorea.com/news/39420…

CIOKOREA.COM

"아웃소싱이 기업을 망친다"··· GM CIO의 IT 운영 원칙 7가지 - CIO Korea

랜달 모트는 2012년에 CIO로서 GM(General Motors)에 합류했다. CEO 다니엘 애커슨으로부터 지난 수십 년간의 아웃소싱 대신 자체 IT 부서를 수립해 경쟁 우위를 확보하라는 직접적인 지시를 받았다.쉽지 않은 IT 전략이지만 모트에게는 ....

애자일이라고 헛소리하는지 체크하는 법

미국 국방혁신위원회(DIB - Defense Innovation Board)에서 아래 6가지 중 하나라도 "No"면 애자일이라고 헛소리(Agile BS) 하는 것이라는데 동의하시나요?

1. 팀이 첫 반복을 포함하여 모든 반복에서 적어도 실 사용자의 일부에게라도 실핻되는 SW를 제공하고 있는가?

2. 미션과 전략적 목표를 포함한 프로젝트 헌장이 있는가? 모든 팀원이 미션과 전략적 목표를 이해하고, 그들의 작업이 미션과 목표에 어떻게 기여하는지 보여줄 수 있는가?

3. 사용자 피드백이 한달이내에 스프린트 팀의 구체적인 작업 항목에 반영되는가?

4. 팀이 사용자 피드백에 따라 요구사항을 바꿀 권한이 있는가?

5. 팀이 배운바에 따라 프로세스를 변경할 권한이 있는가?

6. 프로젝트의 전체 에코시스템이 애자일한가?

https://media.defense.gov/…/DIB_DETECTING_AGILE_BS_2018.10.…

조직 학습(The Fifth Disciplines) - Peter M. Senge

1. 5가지 원칙
   - 개인적 숙련(Personal Mastery) - 동기부여된 편견없는 전문성
   - 정신적 모델(Mental Models) - 내면의 믿음
   - 비전 공유(Building Shared Vision)
   - 팀 학습(Team Learning) - 대화 dialogue
   - 시스템 사고(Systems Thinking) - 위 4가지를 통합

2. 학습 장애
   - 내일 만 한다(I am my position)
   - 남탓 한다(The enemy is out there)
   - 상황을 주도한다는 착각(The illusion of taking charge)
   - 제 주장만 한다(The Fixation on events)
   - 냄비 속 개구리 우화(The parable of boiling frog)
   - 경험으로 부터 배운다는 착각(The illusion of learning from experience)
   - 경영진의 환상(The myth of management team)

3. 시스템 사고의 법칙
   - 어제의 해결책이 오늘의 문제의 원인이다.
   - 강하게 밀수록, 시스템은 더 많이 되돌아 온다.
   - 상황은 나빠지기 전에 좋아진다.
   - 쉬운 방법은 원점으로 되돌아 온다.
   - 치료 결과가 병보다 더 나쁠 수도 있다.
   - 빠를 수록 더 늦어진다.
   - 원인과 결과는 시간과 공간에 밀접하게 연결되지 않는다.
   - 작은 변화가 큰 결과를 가져올 수 있으나, 가장 강한 영향을 미치는 영역은 종종 분명하지 않다.
   - 과자를 소유하고 먹을 수 있으나, 동시에 2가지를 할 수는 없다.
   - 코끼리를 2개로 나눈다고 작은 코끼리 2마리가 되지는 않는다.
   - 남탓할 수 없다.

4. 조직 학습 전략
   - 학습과 업무의 통합
   - 현 상황에서 옆 사람과 시작하기
   - 양쪽 문화(변화, 유지) 아우르기
   - 실습 공간 만들기
   - 조직 핵심과 연결하기
   - 학습 공동체 건설하기
   - 남과 더불어 일하기
   - 학습 인프라 발전시키기

5. 지배적 관리 시스템 (데밍의 용어, 센게의 정의)
   - 평가 중심 관리
   - 순종 강조 문화
   - 성과 관리
   - 정답 대 오답
   - 획일성
   - 예측과 통제 가능성
   - 과도한 경쟁과 불신
   - 전체 관점의 상실

6. 시스템 원형(systems archetype)
   - 지연으로 인한 균형 프로세스
   - 성장의 한계
   - 부담 떠넘기기
   - 목표 침식
   - 단계적 확대
   - 성공한 사람에게 몰아주기
   - 공유지의 비극
   - 실패한 대책
   - 성장과 저투자
 

'CEO 사관학교' 된 아마존..전 임원들이 '버린' 한 가지 문화는?

경쟁보다는 협업, 이것 빼고는 아마존 리더쉽 원칙 모두를 적용한다고 합니다.

고객 만족(중심, 집중), 애자일, 디지털 트랜스포메이션, IOT, AI, 4차 산업혁명, Design Thinking하지 말로만 하지 말고 시간이 걸리더라도 원칙에 충실한 조직을 만드어가는게 지름길이 아닐까 합니다.

근래 아마존, 구글, 마이크로 소프트 3회사 자료를 살펴보면서 드는 생각입니다. 개인적으로 순간 순간 드는 생각은 새로운건 없고 결국 본질에 대한 정확한 이해 그리고 실행력의 차이라는 것입니다. 결국 내공의 차이 아닐까 합니다.

NEWS.V.DAUM.NET

'CEO 사관학교' 된 아마존..전 임원들이 '버린' 한 가지 문화는?

(서울=뉴스1) 김서연 기자 = 세계 최대 전자상거래 기업 아마존이 미국 최대의 '최고경영자(CEO) 사관학교'로 떠올랐다. 23일 월스트리트저널(WSJ)에 따르면 아마존을 담당하는 다나 마티올리 기자는 많은 아마존 출신들이 자신의 .....

지도카 Jidoka(自働化, autonomation)

지도카 Jidoka(自働化, autonomation) - Automation with human touch. 인간을 위한(중심/주도의) 자동화로 번역을 해야 할까요?

도요다의 자동화 원칙을 잘 설명해주고 있는데, 도요다 창업자가 1930년대에 직기(loom)을 자동화한 것에 뿌리를 두고 있습니다. 당시에 포드자동차에서 대량생산을 위해 사람을 부품화하는 자동화의 한계를 보완한 것이다.

자동화(自動化 - automation)의 동(動)자가 움직일 동(動) 옆에 사람 인(人)자를 붙인 동(働)을 사용한 Jidoka(自働化, autonomation)입니다. 개인적으로는 오랫동안 신기술과 도구의 평가, 도입, 확산을 담당하면서 그 기술을 사용할 전문가의 수준보다는 내 입장만을 고려하여 주객이 전도된 행동을 하지 않았나 반성해 본다.

인간의 일자리를 뺏어가는 自動化가 아닌, 더불어 살기 위해 인간이 주도하는 지도카(自働化)에서 해답을 찾아야 하지 않을까 생각해 봅니다. AI, IoT 등 새로운 차원의 자동화를 추구하면서.

https://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html?fbclid=IwAR2vD1YtuiMXbvF8O4l3V20MR05dfnChDNkv1Yxn0O6xSQxVYXuKuCLBZlc

아인슈타인 - 문제 해결을 위해서는

디자인 씽킹을 정리하면서 알게된 아인슈타인의 한 마디!

" 문제 푸는데 1시간이 있다면, 55분동안 문제를 이해하고 5분에 문제을 풀겠다"는 ~~~

매우 상식적인 것 같지만 일상 생활에서는 잘 지켜지지 못하는 것. 문제(근본 원인)을 이해하기 전에 답(해결책, 솔루션)을 먼저 찾는 대부분 인간의 속성을 잘 나타내고 있다.

https://www.google.co.kr/search?q=%EC%95%84%EC%9D%B8%EC%8A%88%ED%83%80%EC%9D%B8+problems&rlz=1C1SQJL_koKR796KR796&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj86Pu71NfeAhVUAogKHegOAh4Q_AUIDigB&biw=1440&bih=758&fbclid=IwAR1AvQJrsRayLIydhre9fwpo0u0NGcVhH0MrNGY9YVx5X12D16MmkNXWKgg#imgrc=3VXpaUBxMb9E8M:

행복의 조건 - 좋은 관계

오래전의 읽은 "행복의 조건"의 저자의 강의가 TED의 10대 인기 강의 동영상 중 하나이네요.

https://www.ted.com/talks/robert_waldinger_what_makes_a_good_life_lessons_from_the_longest_study_on_happiness?referrer=playlist-the_10_most_popular_tedx_talks&fbclid=IwAR3Kw7G06WRh4rtySOeH3Lw-r4Q_W0i1vOmFVIDmRNLANtVt1jLQ7KYXKTY#t-125211

창의적인 아이디어가 필요하면

창의적인 아이디어가 필요하면 주제를 정한 후 편하게 걸으면서 기록하라. 고대 소요학파가 그리했다죠.

https://www.youtube.com/watch?v=j4LSwZ05laQ&fbclid=IwAR2pVD8yIJBRHJX26F6b4UfSglvBR5HXHzOKOkHPLaTXyNnjG5VponBbRz0&app=desktop

교육이 창의성을 죽인다.

교육이 창의성을 죽인다. 교육을 받기 전 소시적으로 돌아가면 창의력은 되살아난다. 교육학자의 말 되새겨 볼만하다. 특히 주입식 교육이 강한 우리 나라에서는 ~~~


https://www.youtube.com/watch?v=kjya2tu6DXo

좋은 대화는 미니스커트와 같다.

A good conversation is like a miniskirt; short enough to retain interest, but long enough to cover the subject. - TED "10 ways to have a better conversation"

과학(이론)과 직관(경험) - 디자인 씽킹

로저 마틴이 디자인적 사고(디자인 씽킹)은 분석적(과학적) 사고와 직관적(통밥, 짬밥, 경험/륜)의 균형이라고 한다. 레오나르도 다빈치, 에디슨, 스티브 잡스 등을 디자인 씽킹 분야에서 대표적인 인물로 소개한다.

"The Mythical Man-Month"라는 SW공학 고전의 저자인 Brooks는 좋은 아키텍처(설계)는 합리성(과학, 이론)과 경험(짬밥)의 균형을 통해 얻는다고 한다.

하나 더, 품질의 대가 데밍도 "이론없는 경험에서는 아무것도 배우지 못한다." 다시 말하면 이론적인 뒷받침없는 경험은 별도움이 되지 못한다는 것이다.

놀랍게도 한 분야에서 일가를 이룬 사람들이 다른 분야에서 같은 이야기를 하였다. 결론은 이론과 직관의 균형을 말하는데, 이론없는 경험 그리고 경험없는 이론의 한계를 말하는 것이다.

상이탑으로 이론(학문)의 대표기관인 서울대 공대 교수들이 공저한 축적의 시간/기간 2권의 책은 학문(이론)과 경험의 축적에 게을리 한 우리 사회에 주는 메시지를 잘 담고 있다. 학문의 축적, 경험의 축적 어느 분야가 더 문제일까? 개인적인 의견은 産學硏 3분야 모두 동일한 문제를 가지고 있다고 본다. 각 분야에 종사하는 당사자는 인정하기 어렵겠지만, 요즘 말하는 학문의 융합 이전에 産學硏의 융합이 먼저가 아닐까? 자기 분야에서의 융합에 문제가 있다면 학제간 융합이 가능할까? 해야 하지만. 국내에는 미국의 Stanford 대학교의 d.school과 MIT Media Lab와 같은 시도를 하는 대학교가 있는가? 없다면 그 원인은 무엇일까?

SW산업계에 종사하면서 자주 들었던, 개인적으로 동의할 수 없었던 이야기 "그건 이론적이야." "그건 한국 문화 때문이야." "정부의 정책 때문이야." 등등. 과연 이론을 제대로 이해하고 말하고 있는 것일까/ 과연 한국 문화가 외국이랑 그렇게 다른 것일까? 유독 SW산업에서만. 정부의 정책은 누가 제안한 것인가? 다시 한번 되돌아 보아야 하지 않을까?

" 내 탓이요! 내 탓이요!"

건축을 통해 SW개발을 다시 생각해 보자

본 기사는 SW공학의 고전 중 하나인 "The Mythical Man-Month"의 저자 Frederick P. Brooks. Jr.의 "The Design of Design - Essays from A Computer Scientist, 2010"에서 발췌하고 개인적인 의견을 첨부한다.

"일반적인 건축 설계 프로세스는

• 고객이 빌딩에 대한 명세서가 아닌 프로그램(요구, 요구사항, 희망사항)을 제시한다. 
• 고객은 명세된 제품이 아닌 서비스에 대하여 보통 시간 또는 비율(% - 전체 건축비의 일정 비율)로 아키텍트(분석과 아키텍처 역할 수행)와 계약한다.
• 아키텍트는 엄격하게 계약할 수 있는 제품 명세서가 아니지만 더 정확한 프로그램(요구)를 고객, 사용자, 이해당사자로 부터 수집한다.
• 아키텍트는 프로그램(요구)과 예산, 일정, 코드 제약사항을 고려하여 개념 설계를 진행한다.  이 개념 설계는 이해당사자에 의하여 개념적으로 평가될 첫번째 프로토타입이다.
• 여러 반복 후에, 아키텍트는 설계(개발)를 수행하는데, 이것은 대개 더 상세한 드로윙, 3차원 모델, 모형(mock-ups) 등이다. 이해당사자와 반복 작업을 수행한 후 아키텍트는 건축 설계서(drawings)와 명세서를 작성한다.
• 고객은 이 설계서와 명세서를 사용하여 건축에 대하여 고정 가격으로 계약한다.

이 오래동안 진화하면서 발견해온 모델은 설계에 대한 계약과 건축에 대한 계약을 분리하는 것이다. 비록 동일한 조직이 위 2가지 일을 수행하더라도."

고객의 요구사항의 불확실성, 적용 기술의 불확실성, 개발자의 역량 파악 및 팀웍(특히 구내는 아웃소싱에 따른 외주 의존도와 프로젝트 단위 계약근로자(임시직, 프리랜서) 의존도가 매우 높은데), 고객 조직 문화와 이해당사자와의 친밀도을 고려한다면 위의 방법이 더 타당하지 않을까?

정부와 공공기관에서는 몇년전부터 분할 발주라는 제도를 정착시키려도 시도하여 왔는데 아직 정착되고 있지 못하고 있다. 그 이유는 무엇일까?

SW 요구사항의 정확한 명세가 가능한가? 불가능한데 필요하다는 필요성만 말하고 있는 것은 아닌가? SW 요구사항을 정확히 모르는데 H/W와 시스템 S/W를 결정하고 용량을 선정하는 것이 합리적인가? 업무분석가, SW아키텍트, SW설계자, 프로그래머, 테스터의 역할 분리가 가능하고 합리적인가? 이러한 역할 간 원할한 협업과 문서로 업무 인수인계가 가능한가? 프로젝트에서 동일인의 역할 변화를 분리된 역할로 오인한 것은 아닐까?

글로벌 프랙티스는 분석이라는 용어 대신 SW요구사항을 사용하고, 요구사항의 불확실성에 대한 대안으로 오래전부터 워크샵(JRP, JAD, QAW,...)과 프로토타이핑을 베스트 프랙티스를 기본으로 예측형(waterfall) 생명주기 대신 나선형(spiral) 생명주기인 반복 점진적 개발, 애자일(XP, SCRUM, SAFe,...), DevOps 등으 사용이 일반화 되었다. 고객이 요구하는 것을 제공하는 것에 더해 고객의 불만을 낮추고 고객 만족을 위해 전직원을 대상으로 디자인 씽킹 문화를 내재화하고 있는 글로벌 회사를 벤치마킹 해보는 것이 어떨가? 정부, 고객, 회사 탓하기 전에 스스로를 되돌아 보는 것이 출발점이 아닐까?

"내 탓이요"
"지도 작성자처럼 일하라"
"내가 있은 위치를 모르면, 지도는 아무 도움이 되지 않는다. 그리고 아무 곳으로 가도 된다."
"과거로 부터 배우지 못하면 똑같은 실수를 반복한다."

한국에서 SI 프로젝트는....

"2천명이 밤을 낮 삼아 ‘KEB하나은행 전산통합’ - 하룻밤새 컵라면 2천개 삶은계란 4천개 트럭으로 날라"

2016년 5월 30일 매일경제 기사이다.
"http://news.mk.co.kr/newsRead.php?no=387986&year=2016"

국내에서 차세대 프로젝트를 하면 일상화되어 있는 모습이다. 이 기사를 보며 되새겨 볼 사항은 무엇일까? 점차 개선되고 있는가? 아님 점점 악화되고 있는 것은 아닐까?

분석, 설계, 코딩 단계를 정상적으로 수행했는데, 왜 테스팅 단계가 가장 바쁘고 야근과 휴일 근무 아니면 프로젝트를 제대로 마칠 수 없는 것인가?

국내 SW산업은 글로벌 프랙티스를 적절히 받아들이고 있는가? 아니면 불껴진 보일러 위 냄비 속의 개구리처럼 펄펄 끓을 수온을 예상 못하고, 당장 따뜻한 수온에 만족해 온게 아닐까?

오래전부터 선진 SW기업에서 일반화된 반복/점진, 애자일(XP, SCRUM), DevOps를 포함한 적응형 생명주기 대신 여전히 폭포수(예측형) 생명주기에 집착하는 이유는 무엇일까?

정부 제도, 고객 갑질, 한국 문화, 고객의 무지(요구사항을 모른다)가 문제인가? 그러면 프로젝트를 수행하는 SW전문가와 SW회사는 프로젝트를 수행할 자질을 갗추고 있는 것일까? 정부 제도는 산업계의 누군가가 필요하다고 공론화하여 만들어 진게 아닐까? 그리고 고객 문제는 오랜 기간동안 SW 프로젝트를 수행하면서 SW산업에 종사한 회사와 전문가가 고객 둘과 함께 만들었다고 보아야 하지 않을까? 현재의 구성원이 아닐순 있지만.

오래전에 타개한 김수환 추기경께서 추진하신 "내 탓이오" 운동이 귓가에 맵돈다.

Design Thinking in global systems integrators (SI)

2000년 초중반 이후 국내에 디자인에 대한 활동이 제조업체를 중심으로 매스컴에 소개되었고, 특히 애플의 혁신적인 제품이 나올 때마다 걸출한 혁신가인 고 Steve Jobs와 함께 디자인이 언급되어 왔다.

디자인 씽킹은 한마디로 설명하면 공학을 꽃피우기 위해 예술과 공예의 활용 극대화하여 공학과 예술의 균형을 추구하는 것이라고 말할 수 있겠다.

Design Thinking을 접한 계기는 2015년 CMU SEI SW아키텍트 컨퍼런스인 SATURN의 Design Thinking 소개 자료를 처음 접하였는데, 요구공학/업무 분석의 지향점이 Design Thinking의 설계였다. 구글링을 해보니 IBM의 Design Thinking, Stanford Univisity d'school 그리고 인도의 IIT에서 2008년 경부터 Design Thinking을 최고 경영자 과정 형태로 운영하고 있다는 것을 알았다.

2017년 상반기에 인도 SI회사인 Infosys의 2016년 경영실적 소개를 위한 주주 설명 자료에 Infosys CEO가 전체 직원 18만명 중 13만 5천명에게 Design Thinking 교육을 이미 실시하였단다. 나머지 인원에 대하여서도 Design Thinking 교육을 실시하겠다고 하였고,  Accenture도 10만명 정도 임직원에게 교육하였다고 한다. 이러한 이유로 인하여 다시 Design Thinking에 대하여 주목하게 되었다.

그래서 구글링을 통하여 확보한 아래 자료를 통하여 Design Thinking이 global SIs에 어떻게 전략적으로 활용되고 있는지를 알게 되었다.  요지는 Global SI사들이 ISO9001, CMM/CMMI --> Lean Six Sigma 등을 거쳐 역량을 갖추게 되자 고객사들이 더 나은 서비스를 요구하게되어 이에 대한 해결책으로 Design Thinking에 주목하게 되어 체계적인 도입 및 확산을 전략적으로 하게 되었다는 것이다.

국내 상황을 살펴보니 산업계는 삼성전자, 현대 카드 등 몇몇 회사가 도입하여 활용하였다는 것, 그리고 주요한 서적은 대부분 번역되었으나 별로 인기가 없어 왔다는 것 정도....

SW개발, 유지보수, 사업 개발에 Global SI회사가 어떻게 Design Thinking을 활용하고 있는지에 관심이 있으면 아래 URL의 HfS Research의 보고서를 참고하시기 바랍니다.

https://www.accenture.com/t20170112T015051__w__/us-en/_acnmedia/PDF-40/HfS-BP-Design-Thinking-2017_Excerpt%20for%20Accenture_MAR17.pdf