2018년 11월 21일 수요일

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

디자인 씽킹을 정리하면서 알게된 아인슈타인의 한 마디!
" 문제 푸는데 1시간이 있다면, 55분동안 문제를 이해하고 5분에 문제을 풀겠다"는 ~~~
매우 상식적인 것 같지만 일상 생활에서는 잘 지켜지지 못하는 것. 문제(근본 원인)을 이해하기 전에 답(해결책, 솔루션)을 먼저 찾는 대부분 인간의 속성을 잘 나타내고 있다.


작성자: 시간: 댓글 없음:

행복의 조건 - 좋은 관계

오래전의 읽은 "행복의 조건"의 저자의 강의가 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"
작성자: 시간: 댓글 없음:

2018년 11월 7일 수요일

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

로저 마틴이 디자인적 사고(디자인 씽킹)은 분석적(과학적) 사고와 직관적(통밥, 짬밥, 경험/륜)의 균형이라고 한다. 레오나르도 다빈치, 에디슨, 스티브 잡스 등을 디자인 씽킹 분야에서 대표적인 인물로 소개한다.
"The Mythical Man-Month"라는 SW공학 고전의 저자인 Brooks는 좋은 아키텍처(설계)는 합리성(과학, 이론)과 경험(짬밥)의 균형을 통해 얻는다고 한다.
하나 더, 품질의 대가 데밍도 "이론없는 경험에서는 아무것도 배우지 못한다." 다시 말하면 이론적인 뒷받침없는 경험은 별도움이 되지 못한다는 것이다.
놀랍게도 한 분야에서 일가를 이룬 사람들이 다른 분야에서 같은 이야기를 하였다. 결론은 이론과 직관의 균형을 말하는데, 이론없는 경험 그리고 경험없는 이론의 한계를 말하는 것이다.
상이탑으로 이론(학문)의 대표기관인 서울대 공대 교수들이 공저한 축적의 시간/기간 2권의 책은 학문(이론)과 경험의 축적에 게을리 한 우리 사회에 주는 메시지를 잘 담고 있다. 학문의 축적, 경험의 축적 어느 분야가 더 문제일까? 개인적인 의견은 産學硏 3분야 모두 동일한 문제를 가지고 있다고 본다. 각 분야에 종사하는 당사자는 인정하기 어렵겠지만, 요즘 말하는 학문의 융합 이전에 産學硏의 융합이 먼저가 아닐까? 자기 분야에서의 융합에 문제가 있다면 학제간 융합이 가능할까? 해야 하지만. 국내에는 미국의 Stanford 대학교의 d.school과 MIT Media Lab와 같은 시도를 하는 대학교가 있는가? 없다면 그 원인은 무엇일까?
SW산업계에 종사하면서 자주 들었던, 개인적으로 동의할 수 없었던 이야기 "그건 이론적이야." "그건 한국 문화 때문이야." "정부의 정책 때문이야." 등등. 과연 이론을 제대로 이해하고 말하고 있는 것일까/ 과연 한국 문화가 외국이랑 그렇게 다른 것일까? 유독 SW산업에서만. 정부의 정책은 누가 제안한 것인가? 다시 한번 되돌아 보아야 하지 않을까?
" 내 탓이요! 내 탓이요!"
작성자: 시간: 댓글 없음:
라벨: ,

2018년 11월 6일 화요일

건축을 통해 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산업에 종사한 회사와 전문가가 고객 둘과 함께 만들었다고 보아야 하지 않을까? 현재의 구성원이 아닐순 있지만.

오래전에 타개한 김수환 추기경께서 추진하신 "내 탓이오" 운동이 귓가에 맵돈다.
작성자: 시간: 댓글 없음:
피드 구독하기: 글 (Atom)