항상 저의 블로그에 방문해 주셔서 감사합니다. 좋은 하루 되세요. *^^*
애자일 이야기 블로그에서 일부 퍼옴.
일에 대해서는 오래된 격언이 있습니다.
It's better to work smart than to work hard.
소프트웨어 공학의 스타, 스티브 맥코넬은 쾌속 개발에 대한 10가지 미신이라는 제목의 발표자료에서 말합니다. 마이크로소프트는 그 격언을 다음과 같이 바꿨답니다.
It's better to work smart and hard.
아마존은 거기에 한 수 더 했습니다.
It's better to work smart and hard and long.
그러면서 왜 이 전략이 멍청한 결과를 내는지 설명하며, "Work smart, not hard"는 여전히 유효한 말이라고 결론 내립니다.
우리 욕심은 끝이 없죠. 많은 회사는 직원들이 똑똑하게 일하면서 열심히, 그리고 오래 일하기를 바랍니다. 열심히나 오래 일하기가 생산성에 도움이 될 거라고 믿습니다. 한 발 물러서서, 열심히나 오래가 똑똑하게 보다 생산성이 못하다고는 해도 뭔가 플러스가 될 것이라고 믿습니다.
음의 생산성(negative productivity)이란 것이 있습니다. 일을 많이 하다보면 어느 순간 실수를 저지르기 시작합니다. 그런데 지식 노동에서는 그 실수를 나중에 찾아내는 것이 쉽지가 않습니다. 스티브 말에 따르면 평균적인 소프트웨어 개발 프로젝트는 비용(시간, 인력 등)의 40%에서 80%를 이런 실수(결함, 즉 버그가 되겠죠?)를 잡아내는 데에 쓴다고 합니다. 과다하게 업무를 하다보면 debug(버그 제거)가 아니라 자기도 몰래 enbug(버그 삽입)를 하게 됩니다. 이때부터는 음의 생산성이 됩니다. 즉, 내가 한 시간 일하면 프로젝트는 열시간 할 일이 늘어납니다. 왜 일대일로 시간이 대응되지 않냐구요? 적어도 소프트웨어 개발에서는 결함 삽입에 걸리는 시간과 그걸 고치는 데 걸리는 시간에는 막대한 차이가 있으며, 결함 직후에 바로 고치면 몰라도 그 시기가 늦춰지면(즉 나중에 결함을 발견하고 수정하려고 하면) 통상 비용이 50배에서 200배 커지는 것으로 알려져 있습니다.
고되게 일하는 것이 인지적으로는 어떤 영향이 있을까요? 바로 생각나는 것은 일이 많아지면 잠을 적게 잘 것이고, 학습과 고도의 지적활동에 수면이 차지하는 위상(최근의 연구들을 통해 수면의 중요성은 훨씬 더 높아졌습니다)을 생각해 볼 때 분명 큰 문제가 있을 겁니다. 몇가지 연구를 인용해 보죠.
The reaction time of residents who had just finished a month of heavy work schedules was 7 percent slower and they committed 40 percent more errors than when they were on a month of light schedules,
Wake Up, Doc: Lack Of Sleep Affects Young Doctors Just Like Alcohol Does
장시간 일하는 레지던트들에 대한 연구입니다만 소프트웨어 개발 업종에 종사하시는 분들에게도 똑같이 적용이 될 거라고 생각합니다.
이런 연구들을 잘 정리해 놓은 글도 있습니다. Why Crunch Mode Doesn't Work: 6 Lessons
XP의 아버지 중 한 사람인 론 제프리즈(Ron Jeffries)도 이에 대해 글을 썼습니다.
A common effect of putting teams under pressure is that they will reduce their concentration on quality and focus instead on "just banging out code". They'll hunker down, stop helping each other so much, reduce testing, reduce refactoring, and generally revert to just coding. The impact of this is completely predictable: defect injection goes way up, code quality goes way down, progress measured in terms of net working features drops substantially.
Impact of Overtime on Productivity
다음은 좀 자극적인 결과입니다.
After 17 to 19 hours of staying awake -- a normal working day for many people -- reaction times are up to 50 percent slower than they are after drinking alcohol ...... The effects of fatigue are thought to play a part in almost two-thirds of the road accidents in the United States, say the authors. Extended working hours, shift work, and lifestyle choices are likely to decrease the amounts of sleep we have, they conclude. The effects, which are likely to be cumulative, pose a serious risk to safety, they say.
Long Working Days With Too Few Hours' Sleep Slow Responses As Much As Alcohol
여러분 중에 음주 코딩 하시는 분은 별로 없을 것이고 그걸 회사에서 허락하는 곳은 더 드물 겁니다. 그런데 "밤샘해서라도 일해라"고 시키는 회사는 사실 "술 먹고 코딩해라"고 말하는 것과 큰 차이가 없다는 연구 결과입니다.
음주 코딩이 있나 하면 마약 코딩도 있습니다. 회사가 직원에게 과도한 업무를 지우는 방법 중 하나가 멀티 태스킹입니다. 동시에 여러가지 일을, 여러가지 프로젝트를 진행하도록 하는 것이죠. 그 결과는?
The study, carried out at the Institute of Psychiatry, found excessive use of technology reduced workers' intelligence. Those distracted by incoming email and phone calls saw a 10-point fall in their IQ - more than twice that found in studies of the impact of smoking marijuana, said researchers.
The Multi-Tasking Myth에서 재인용
멀티 태스킹, 멀티 프로젝트의 병폐에 대해 관심이 있으시면 다음 링크를 참고하세요.
(멀티 프로젝트의 문제에 대해서는 차후에 좀 더 자세히 다루도록 하겠습니다.)
켄트 벡은 XP란 소프트웨어 개발 방법론을 인간성과 생산성 모두를 높히는 방법이라고 설명합니다. 여기에 더 고되게 일한다거나, 더 오래 일한다는 말은 없습니다. 조직은 더 바쁘게 일하라고 합니다. 하지만 바쁘게 일하는 것보다 빠르게 일하는 것이 중요합니다(faster, not busier). 또한 빠르게 일하는 것보다는 더 많은 가치를 더 일찍 전달하는 것이 더 중요합니다(more value sooner, not faster). 더 바쁘게 일하면서 결과 가치는 더 떨어지는 예는 TOC(제약 조건 이론) 관련 서적(더 골을 추천합니다)을 보시면 쉽게 납득하실 겁니다.
이런 글은 모든 개발 프로젝트 발주자 및 프로젝트 메니저 들에게 강제로 읽게 해야 합니다. !!!