엔지니어 마인드, 무엇이라고 생각하시나요?

특히 요샌 통계툴을 이용하여 엔지니어링 데이타를 객관화하여 나 아닌 다른 사람들이 반박할 수 없는 자료를 만드는것 까지 해야 한답니다.
"최소의 input으로 최대의 output을 만들어 내고 증명까지 한다" 정말 멋진말 아닙니까? 하지만 그렇게 하는 엔지니어는 죽을 맛입니다.

"엔지니어가 그런 마인드를 가지고 어떻게 일을 하나?"
"적어도 엔지니어라면 그렇게 하지 않는다."
"데이터없이 말만 하는 사람은 엔지니어가 아니다."
"모든게 충분한 상황에선 누가 일을 못하나? 엔지니어이기 때문에 가능하지."
등 상사 입장에선 엔지니어란 말을 여기저기에 가져다 붙이면 정말 쉬워집니다.

저만 이렇게 일하나요?

thisrule wrote:

특히 요샌 통계툴을 이용하여 엔지니어링 데이타를 객관화하여 나 아닌 다른 사람들이 반박할 수 없는 자료를 만드는것 까지 해야 한답니다.
"최소의 input으로 최대의 output을 만들어 내고 증명까지 한다" 정말 멋진말 아닙니까? 하지만 그렇게 하는 엔지니어는 죽을 맛입니다.

"엔지니어가 그런 마인드를 가지고 어떻게 일을 하나?"
"적어도 엔지니어라면 그렇게 하지 않는다."
"데이터없이 말만 하는 사람은 엔지니어가 아니다."
"모든게 충분한 상황에선 누가 일을 못하나? 엔지니어이기 때문에 가능하지."
등 상사 입장에선 엔지니어란 말을 여기저기에 가져다 붙이면 정말 쉬워집니다.

저만 이렇게 일하나요?

당연히 엔지니어는 주어진 조건에서 가질 수 있는 최선의 결과가 어떤 것인지를 증명할 수 있어야하고 증명된 결과를 가져올 수 있는 계획의 수립과 실천이 가능해야 합니다. 그럴 수 있어야 훌륭한 엔지니어라고 할 수 있죠.

자신이 할 수 없다면 자신을 다른 대상으로 치환했을 때 가능한지, 개선할 수 있는 조건은 어떤 것인지, 개선을 했을 때는 어떤 결과의 향상이 있는지 등에 대해서도 관리자에게 설명/이해를 시킬 수 있어야죠.

관리자가 엔지니어는 딴 세계사람이고 엔지니어의 말을 신뢰할 수 없다고 말을 할 때는 바로 이런 과정이 없거나 이런 부분에 대한 연구도 없이 그냥 자신이 임의로 할 수 있다 없다를 결정하기 때문입니다.

엔지니어라면 어떠한 결과를 얻고 싶을때, 어느정도까지의 결과를 얻을
것인가를 고민해야합니다. 100% 만족하는 답이 나올때 까지 구할 것인가,
한달안에 95%의 만족도로 구할 것인가, 하루에 90%의 만족도를 구할
것인가를 판단해야하고, 그 퍼센테이지에 따른 한계를 파악해둬야하겠지요.
무작정 언제인지 모르지만 100%가 될 때까지 해보겠다는 마인드를 저는
'사이언티스트'적인 사고라고 평합니다.

qed wrote:

다들 일을 시작하기 전에 그 일이 언제 어떻게 끝나리란걸
예언하고, 그것대로 일을 끝마치시는건가요?

Unix System Administration Handbook의 정책과 정략(전 한글판 ^^) 파트를 보면 다음과 같은 말이 나오죠.

Quote:

현실적으로 예상 시간을 설정하라. 크거나 중요한 과제에 대해서는 예측 소요 시간을 두배 혹은 세배로 정하라. 만약 업그래이드를 삼일이 아니라 이틀에 끝냈다면, 예측 시간을 하루로 잡았을 때 당신을 비난할 사람도 예측 시간을 삼일로 잡았다면 감사하게 될 것이다.

가슴 깊이 와닿는 말입니다.

결국엔 trade-off인거긴 한데, 늘상 보면 어디서 cut해야 하는지가
어렵더군요^^;