:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
21/02/22 10:01
이거레알이죠
전 직장에 신입으로 첫 출근하던 날 팀장님 왈 페이퍼 쓸 때 1. A4용지 한 장 넘으면 다 찢어버린다^^? 2. 불필요한 거 적으면 다 빠꾸시킨다^^? (말씀은 독하게 하셔도 츤데레타입이시라 오다 주웠다 가져라 몇 번 당했습니다 크크) 줄이고 빼는 게 얼마나 중요한 스킬이었는지 나중에 가서야 알겠더군요
21/02/22 09:48
의외로 오픈소스나 ... 훌룡한 개발자들이 만든것들중에선 메뉴얼이 형편없는 경우가 왕왕있더군요.. "자 이건 기본으로 알고있을테니까 생락하자고!" 하는 느낌이랄까
21/02/22 20:39
너무 많이 알아도 세세한 설명은 생략하고 시작하죠.
본문 아이폰 예처럼 많이 안다고 이것저것 두서 없이 말해도 사람 미치고요. 하하
21/02/22 09:53
스포츠 천재들이 지도자 되었을 때 느낌이군요.
'난 이렇게저렇게 하면 다 됐는데 니들은 왜 못 하냐??' 시전이 되어버리는 그런 것...?
21/02/22 10:03
천재들이 설명을 못한다는데 솔직히 동의 못 할 때가 많습니다. 정말로 그걸 잘 안다면 열살짜리가 들어도 이해 가능하게 설명해야 하고, 실제로 정말 뛰어나단 사람들은 그런 경우가 많거든요.
오히려 더 많은 경우 그런 사람의 설명을 들었을 때 하나도 이해를 못했다면 설명한 사람의 잘못일 가능성이 훨씬 높다고 봅니다
21/02/22 10:39
그걸 쉽게 풀어서 설명했을때 원래의 깊이와 문제의 어려움과 동떨어진 결과가 나올 수 있어서 안그러는 경우도 있으니까요.
쉽게 이해하면 그걸로 다 알았다로 착각할까봐. 이런쪽 이야기 할때 프린키피아 이야기가 꼭 나오는 이유죠. 일반인들에게 필요한건 사과는 지구중력때문에 사과나무에서 떨어진다. 면 끝이겠지요.
21/02/22 10:44
잘 아는 사람이 설명도 잘하는 건 맞지만,
상대 얼굴만 보고 유치원 수준인지 박사급 수준인지 알 수 없는 경우가 많아서 어려운 점도 있는 것 같아요. 이런 질문을 하는 사람들이 정말로 뭘 궁금해하는지, 사전 지식은 얼마나 되는지에 대한 경험도 중요하더군요.
21/02/22 10:13
왜 이렇게 해야하는지를 알 필요 있는 업무인가 아닌가에 따라 다를 것 같습니다. 다른 말로 하면 매뉴얼을 읽는 사람이 응용력을 발휘할 일인지, 걍 시킨대로 하는게 나은 일인지에 따라 다르겠네요.
글쓴 분께서 말씀하신 현장에서라면, 명료한 매뉴얼은 반드시 필요하고, 이해를 위한 익힘책은 시간과 여유가 있다면 추가되면 좋은 정도일 것 같습니다.
21/02/22 20:44
고도의 기술이 필요한 분야는 의외로 많지 않아서 일반적인 현장에서는 기능을 극대화 하는 것이 효율이 좋을거라 생각합니다.
그러나 말씀하신대로 분야에 따라서는 분명히 응용력과 고도의 스킬이 필요한 경우도 있을 것이고 이런 경우는 반드시 개념을 익힐 수 있는 교재가 필요할 것입니다.
21/02/22 20:45
그나마 그 마법을 걷어낼 수단이 극도로 명려성을 높여 단숨에 읽히게 하고 순서표의 기능을 대신해서 들고 일할 수 있도록 만드는 것이죠.
21/02/22 10:21
이해와 원리 좋죠
하지만 공정에서는 이해와 원리 다 배워가면서 작업할만한 여지도 없고 사람마다 케바케인지라.. 작업자는 딱 메뉴얼대로 했을때 양품이 만들어지도록 이해와 원리는 양산 준비하는 단계에서 생산기술에서 확인하고 공정 간소화해야죠
21/02/22 10:41
제가 요즘 회사에서
업무 시퀀스를 정리하고 있는데 항상 생각하는 것이 "원숭이도 보고 할수 있을 정도의 절차서가 최고의 절차서다" 라는 생각으로 문서를 편집하고 있습니다. 제가 이해한것과 그것을 보고 업무를 진행하는 사람의 이해도가 천지차이 이기 때문에 이런 생각을 하다보니 제 문서의 단점도 찾을수 있더라구요.
21/02/22 11:48
둘 다 필요하단 생각입니다.
현장 매뉴얼은 현장 상황을 해결하는 데 최우선을 둬서 말씀하신대로 작성하고, 그것을 설명하는 매뉴얼을 또 하나 작성해서 이해를 깊게. 의사들 진료매뉴얼도 그렇게 이루어져 있습니다. 일단 눈앞의 상황은 신속하고, 정확하게 해결해야 하니 간편매뉴얼, 이후에 어떻게 할지/왜 이런 치료를 했는지 등은 심화매뉴얼을 보고 이해를 하면서 지식과 경험을 쌓습니다.
21/02/22 20:48
대부분 현장이 긴박하기 때문에 매뉴얼 하나 가지고 쉽게 대응 할 수 있는게 필요하죠.
심화도 반드시 필요하며 성장을 위한 심화 과정은 따로 다른 시간으로 분리해서 생각하는게 피로도 부분에서도 이점이 있다고 생각합니다.
21/02/22 12:53
어디서 미군 교본에 지시사항만 들어가면 상황이 바뀌는 경우 전혀 적응 하지 못하는 단점 때문에, 지시사항에 이유와 맥락을 적는것으로 업데이트 되었다는 글을 본 적이 있습니다. 상황에 따라 장/단점이 있는거죠. 상황이 계속 변하기 때문에 이 메뉴얼 항목은 왜 들어있는지 이해시키는 부분도 경우에 따라 중요합니다.
21/02/23 04:54
미국의 장점이 그 flexibility 라고 들엇습니다. 전쟁사 미군이 이긴거 보면 일선장교가 독단적 판단으로 내린 전술이 좋은 결과를 가져온 경우가 많이 있죠.
21/02/22 13:55
오퍼레이션 매뉴얼은 컴퓨터 프로그래밍 코드같아야죠. 설명은 있으면 좋지만 없어도 돌아가기만 하면 됩니다. 에러 예외처리는 컴퓨터(오퍼레이터)가 아니라 코드 짜는 사람이 하는 것이고요.
21/02/22 20:50
현장에서는 쉽게 익혀 어떻게든 돌아가게 하는게 생명입니다. 예외조항은 따로 고급 관리자들 몫인데 사실 분리하는게 관리자들에게 좋은 일은 아니니 어떻게든 상급 과정을 우겨넣고 싶어하죠.
21/02/22 20:51
움베르트 에코 소설 푸코의 추는 읽어봤는데 뭔 내용인지 잘 모르겠더라구요. 하도 오래 전에 읽어서 살인 방법만 조금 기억이 납니다.
21/02/22 16:54
개발자로 한 20년쯤 살아온 결과, 느낀점은..
1. 설명서와 개념서는 완전히 분리해야 한다. 2. 기왕이면 설명서는 없어도 되는게 좋다. 별도의 설명서보단 기기(소프트웨어)를 보고 직관적으로 알 수 있게 해야 한다. 그리고 2에 충실한게 근래의 UX 개념이죠. 기존의 UI 개념이 "이건 이런 기능을 가진 버튼이다." 정도의 개념이었다면, UX는 "이걸 누르면 이게 될 것 같아 보이게 한다." 라는 개념이거든요. 둘 사이의 차이는 꽤 큽니다. 근데 요새 클라이언트들은 UX의 개념을 "애플처럼 이뻐보이는 아이콘" 정도로 이해하더군요;;;
21/02/22 17:11
저도 이번에 miui 최신버전이 volte가 안되는 문제가 발생해서 커스텀 패치를 하려고 관련 블로그를 탐독한 적이 있는데, 그나마 기능 위주로 썰 푼것조차 몰입이 굉장히 힘들게 설명되어 있더군요.
21/02/22 22:39
매뉴얼을 초급용, 중급용으로 나눠서 만들어야 합니다.
단순하게 기능만 있는 매뉴얼을 쓰면 오류가 발생했을 때 대처가 안되니까요. 관리자에게 문의하라고 하지만 문의하면 답이 없습니다. 왜냐하면 관리자가 그걸 대응할 수 있을 시간이 없거든요. 그런데 중급용을 쓸 정도의 사용자가 되면 알아서 자기만의 노하우가 생겨서 매뉴얼을 안봅니다. 크크크
|