[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

!!!사람을 힘들게 하는 것은 "Hard work"가 아니다. "Stress"다
사람들이 일을 즐기면 - 즐기지는 못하더라도 할만하면 -, 열심히 일해도 힘들지 않다.
그러나, 사람들은, 자신이 무엇을 하고 있고, 왜 이 일을 하고 있는지 알지 못하면 일을 즐길 수가 없다.
사람들은 자신이 하고 있는 일의 방향과 타당성을 알고 비젼에 공감하며, 열심히 일한 것에 대한 보상이 있을때, 일을 즐길 수 있고, 이때는 하루에 10시간 혹은 12시간을 일하더라도, "회사일 때문에 힘들다."라는 이야기를 하지 않을 수 있다.

반면, 내 경력에 전혀 도움이 되지도 않고, 왜 이 일이 필요한지도 모르겠는 일을 계속해서 하면서, 다른 사람과의 갈등으로 계속해서 스트레스를 받으면, 아무리 9-6 8시간 근무를 하더라도.."회사일 때문에 힘들다."라는 생각이 들 수 밖에 없다.

음.... 지금 당연한 이야기를 하고 있는 것일 수도 있으나.. 다시 한 번 되새겨 보자는 의미에서 한번 적어 본다....

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Before developing something, we should clarify "what we want to develop". In the same context, we want clear requirement specification. But I am not saying about requirement specification. Subject of this article is "Clear description about outcome - not only final one but also intermediate and sub-module's one". In case of very short and simple program, required goal is also simple and clear. So we don't need to worry about this. But, usually, size of software project is quite big.

Here is very big-size-software project. So, we divide a project into several sub-projects and assign these to sub-team; After developing each sub-project, we try to integrate them. But, as you know, integration is not an easy job. There may be conflicts between sub-module, interface mismatching and so on. Changing software design or algorithm may be required to resolve these integration issues, and usually, this kind of change is very expensive. How can we reduce this costs?.

Yes. I think everyone already knows the solution.To reduce this, we should clarify outcome of each sub-project.
Actually, changing software due to integration issues means "Requirement of that sub-project is changed"; Big Costs!. In this scenario, outcome of sub-project can be interface, data format and so on. In sub-teams' point of view, "Knowing exactly about outcome of other module" means "Knowing exactly what we can use and what we can supports". In my opinion, this is basic knowledge to reduce integration issues.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

"世有伯樂然後有千里馬, 天里馬常有而伯樂不常有." 라 했다.

좋은 사람을 알아 본다는 것은 그 만큼 힘든 일이고 어려운 일이다.

옛 중국에는 '사람을 추천했을 경우 추천받은 사람이 죄를 지으면 추천한 사람도 그와 같은 처벌을 받는다.'는 법이 있었다고 한다. 모르긴 몰라도, 그 반대로 추천받은 사람이 공을 세울 경우, 추천한 사람도 그 공을 나누어 가지지 않았을까?

따라서 사람을 추천한다는 것 혹은 추천받는 다는 것은 그 만큼 어렵고 또 중요한 일이란 뜻이다. 추천 받은 사람은 자신의 공과가 추천한 사람에게 그대로 이어짐을 명심해야하고, 추천한 사람또한 이러한 것을 충분히 고려한 후 추천해야 한다.

그렇지만 무엇보다도, 사람을 추천하기 전에 '좋은 사람을 알아본다'는 것이 얼마나 어려운 일인지 알고, '좋은 사람을 추천할 수 있는 사람' (伯樂)의 가치를 알며, 이를 소중히 여길 줄 아는 것! 이것이 아마도 가장 중요한 것이 아닐까? 그리고 나 또한 '좋은 사람을 알아볼 수 있는 안목'을 기르는데 노력해야 하지 않을까?

+ Recent posts