간만에 이런 시간을 같는군. 흠.
1. 매뉴얼을 만들기 보다 매뉴얼이 필요없는 소프트웨어를 만들자. : http://venturesquare.net/1946
: 맞는 말이다. 간략하게 정리해 보면
>> 메뉴얼의 문제
- 매뉴얼 만드는데 상당한 자원이 들어간다.
- 만들어도 잘 안본다. 정작 시스템 사용시 어려움을 겪으면 사람을 찾는다.
- 시스템의 변경시 매뉴얼이 같이 변경되지 않아 시스템 따로 매뉴얼 따로가 허다했다.
- 하지만 막상 매뉴얼을 만들지 않자니 뭔가 개운하지 않다. <= 요게 핵심이죠.
>> 뭐가 좋은지.?
- 아이폰이 메뉴얼이 필요없는 직관적인 UI라고 했지만, 맞는말이기도 하지만, 정작 관리를 잘하려면 iTunes를 써야 하는것 부터는 전공공부로 들어간다. 사용상의 UI는 애덜도 쓸수 있을정도.. 맞다.
>> 그럼 어떻게.?
- 음.. 음.. 우리가 만드는 소프트웨어를 직관적이고 쓰기 쉽게, 소프트웨어 자체에 매뉴얼이 담겨 있으면 된다. 아~ 물론 맞는 말이고 나도 동감을 하는바이나, 이건 마치 법보다 주먹이 가깝다는 식으로 실제로는 이렇게 해야 한다고 생각하지만, 이걸 하려면 한줄 한줄의 코드부터 잘 만들어야 하고, 이걸 이해 못하는 성과,산출물 위주의 조직문화를 넘어서야 하기에, 오늘도 쓰지 않을걸 알지만 메뉴얼을 만든다. 최대한 시간과 노력이 들어가지 않는선에서... 으흥흥
2. 달인의 함정 : http://venturesquare.net/1941
즐겨보는 신승환 님( http://www.talk-with-hani.com/ )의 글 중 하나인데, 많은 것을 생각하게 하는 글이다.
결국은 달인은 그만 두었다 ! 가 핵심인데, 이게 공감되는 이유는 내가 있는곳만 하더라도 겉으로는 모든것을 다~~~ 잘 할수 있는 사람을 원하고 있고, 사실 그건 불가능 하기에 다덜 하는척은 하는데 그 모양이 깊이는 얇고 넓게 아는것쪽으로 흘러간다. 그래야 발언을 할수 있고, 다들 깊이 있게는 모르는데 모든것을 다~~ 잘 할수 있는것처럼 보이기라도 할수 있지 않는가.?
개인적인 딜레마는 문제의 해결은 근본적인 것을 해결하는데 있다고 생각한다.
즉 위의 매뉴얼 이야기나 안전장치를 더 많이 둘수록 사고의 위험은 더 커진다.( http://venturesquare.net/1911 )의 글을 보면 결국은 본질적인 근본적인 것이 해결되어야 하고 그러기 위해서는 사회전체의 구조나 전체적인 문제해결이 필요하다는 결론으로 가서 우리 한번 해봅시다.. 라는 그냥 좋은 얘기로 마무리가 된다.
최근에 갑에의해 주도되는 IT시스템 개발의 문제점을 근본적으로 해결해 보고자, 갑이 대충아는채로 주문만 하는게 아니라 코드의 시작부터 같이해야 한다는 생각으로 시스템을 구축했고, 뭐 얼마간은 잘 운영해 왔었다. 사실 결과도 무척 만족스러웠으나, 문제는 이런 문제의식을 가지고 접근한 나야 그렇지만, 그렇지 않은 다른 많은 사람들, 그리고 조직의 문화는 이와는 전혀 다른 즉, 문제가 있으면 돈과 사람을 많이 투입해서 빨리 해결하지 않고 뭐 하느냐~~ 라는 부분때문에, 근본적인 문제를 해결하고자 했던게 오히려 다른사람들이 보기엔 발목을 잡고 있는 형국이 되어 버린 상황이 됬다.
핵심은 내가 생각했던 근본적인 문제의 해결의 핵심은 갑에도 달인이 피료하다는 것이었는데, 갑의 조직문화에서는 달인이 피료치 않은것 같다. 여기에 신승환님의 달인의 함정이란 글을 보더라도 현 사회의 흐름에 맞춘 달인이 피료한. 하지만 그것은 마치 기초과학은 현 사회의 흐름에 맞지 않으니 다른 과학을 발전시키야 한다는 논리와 비슷한 그런 형국이 되는것 같다.
쓰면서 정리가 되었는데, 올바르게 되려면 달인이 필요하고 달인은 기초과학처럼 현 분위기 뭐 그런것과 상관없이 항상 피료한 그런게 있어야 하지 않는가 한다.
3. 지금과 같이 불퀘한 자리에 손님이 앉도록 할 수는 없습니다.
http://venturesquare.net/1943 오호 오호... 멋진 글이다.
1. 매뉴얼을 만들기 보다 매뉴얼이 필요없는 소프트웨어를 만들자. : http://venturesquare.net/1946
: 맞는 말이다. 간략하게 정리해 보면
>> 메뉴얼의 문제
- 매뉴얼 만드는데 상당한 자원이 들어간다.
- 만들어도 잘 안본다. 정작 시스템 사용시 어려움을 겪으면 사람을 찾는다.
- 시스템의 변경시 매뉴얼이 같이 변경되지 않아 시스템 따로 매뉴얼 따로가 허다했다.
- 하지만 막상 매뉴얼을 만들지 않자니 뭔가 개운하지 않다. <= 요게 핵심이죠.
>> 뭐가 좋은지.?
- 아이폰이 메뉴얼이 필요없는 직관적인 UI라고 했지만, 맞는말이기도 하지만, 정작 관리를 잘하려면 iTunes를 써야 하는것 부터는 전공공부로 들어간다. 사용상의 UI는 애덜도 쓸수 있을정도.. 맞다.
>> 그럼 어떻게.?
- 음.. 음.. 우리가 만드는 소프트웨어를 직관적이고 쓰기 쉽게, 소프트웨어 자체에 매뉴얼이 담겨 있으면 된다. 아~ 물론 맞는 말이고 나도 동감을 하는바이나, 이건 마치 법보다 주먹이 가깝다는 식으로 실제로는 이렇게 해야 한다고 생각하지만, 이걸 하려면 한줄 한줄의 코드부터 잘 만들어야 하고, 이걸 이해 못하는 성과,산출물 위주의 조직문화를 넘어서야 하기에, 오늘도 쓰지 않을걸 알지만 메뉴얼을 만든다. 최대한 시간과 노력이 들어가지 않는선에서... 으흥흥
2. 달인의 함정 : http://venturesquare.net/1941
즐겨보는 신승환 님( http://www.talk-with-hani.com/ )의 글 중 하나인데, 많은 것을 생각하게 하는 글이다.
결국은 달인은 그만 두었다 ! 가 핵심인데, 이게 공감되는 이유는 내가 있는곳만 하더라도 겉으로는 모든것을 다~~~ 잘 할수 있는 사람을 원하고 있고, 사실 그건 불가능 하기에 다덜 하는척은 하는데 그 모양이 깊이는 얇고 넓게 아는것쪽으로 흘러간다. 그래야 발언을 할수 있고, 다들 깊이 있게는 모르는데 모든것을 다~~ 잘 할수 있는것처럼 보이기라도 할수 있지 않는가.?
개인적인 딜레마는 문제의 해결은 근본적인 것을 해결하는데 있다고 생각한다.
즉 위의 매뉴얼 이야기나 안전장치를 더 많이 둘수록 사고의 위험은 더 커진다.( http://venturesquare.net/1911 )의 글을 보면 결국은 본질적인 근본적인 것이 해결되어야 하고 그러기 위해서는 사회전체의 구조나 전체적인 문제해결이 필요하다는 결론으로 가서 우리 한번 해봅시다.. 라는 그냥 좋은 얘기로 마무리가 된다.
최근에 갑에의해 주도되는 IT시스템 개발의 문제점을 근본적으로 해결해 보고자, 갑이 대충아는채로 주문만 하는게 아니라 코드의 시작부터 같이해야 한다는 생각으로 시스템을 구축했고, 뭐 얼마간은 잘 운영해 왔었다. 사실 결과도 무척 만족스러웠으나, 문제는 이런 문제의식을 가지고 접근한 나야 그렇지만, 그렇지 않은 다른 많은 사람들, 그리고 조직의 문화는 이와는 전혀 다른 즉, 문제가 있으면 돈과 사람을 많이 투입해서 빨리 해결하지 않고 뭐 하느냐~~ 라는 부분때문에, 근본적인 문제를 해결하고자 했던게 오히려 다른사람들이 보기엔 발목을 잡고 있는 형국이 되어 버린 상황이 됬다.
핵심은 내가 생각했던 근본적인 문제의 해결의 핵심은 갑에도 달인이 피료하다는 것이었는데, 갑의 조직문화에서는 달인이 피료치 않은것 같다. 여기에 신승환님의 달인의 함정이란 글을 보더라도 현 사회의 흐름에 맞춘 달인이 피료한. 하지만 그것은 마치 기초과학은 현 사회의 흐름에 맞지 않으니 다른 과학을 발전시키야 한다는 논리와 비슷한 그런 형국이 되는것 같다.
쓰면서 정리가 되었는데, 올바르게 되려면 달인이 필요하고 달인은 기초과학처럼 현 분위기 뭐 그런것과 상관없이 항상 피료한 그런게 있어야 하지 않는가 한다.
3. 지금과 같이 불퀘한 자리에 손님이 앉도록 할 수는 없습니다.
http://venturesquare.net/1943 오호 오호... 멋진 글이다.
