1.
미국 라이코스 CEO인 임정욱씨가 시사 IN에 기고한 글을 보면 재미있는 내용이 있습니다.
읽으면서 가장 부러웠던 점은 창업자를 대하는 태도입니다.
무엇보다도 가장 부러운 것은 창업자를 존중하는 분위기다. 스물한 살의 WeGame CEO 제라드 김은 “실리콘밸리에서 ‘창업자’라고 하면 보는 눈이 달라진다”라고 말한다. 새로운 것에 도전하는 열정을 가진 사람으로 인식하는 것. 이런 젊고 똑똑하고 열정과 아이디어를 가진 젊은이가 창업하겠다고 하면 발벗고 도와주는 분위기가 있다. 실패를 두려워하지 않고 장려한다. 성공한 창업자가 큰돈을 벌고 나서도 다시 창업에 도전한다. 이런 분위기가 끊임없는 혁신을 낳는다.
임정욱씨의 글이나 Mickey kim이 구글에 대해 쓴 글을 볼 때 미국문화는 한국문화와? 많은 차이가 있다는 생각을 들었습니다. 구글같은 회사니까 그럴 수 있다고 치부할 수 있지만? 그래도? 평범한 소프트웨어 개발자들의 생활을 어떨까 무척이나 궁금해 집니다. 우리처럼 야근에 날 밤새는 것을 밥 먹듯 하는지.
우선 우리는 법적으로 주 40시간 – 물론 소기업에서? 일하는 분들은 아닙니다 – 을 일합니다. 소프트웨어 개발자도 마찬가지로. 그런데? 신뢰성있는 자료는 아니지만 실제 일하는 시간은 62시간이라고 합니다.
우리나라 대부분 개발자들이 SI일을 한다고 하면 62라는 숫자가 꼭 틀리다고는 할 수 없습니다.
그러면 미국은? 미국연방정부에 펴낸 통계자료를 보니까 근무시간은 주 40시간인 듯 합니다.
Most software?engineers and programmers work 40 hours a week, but about ?15 percent of software engineers and 11 percent of programmers worked?more than 50 hours a week in 2008. Injuries in these occupations are?rare. However, like other workers who spend long periods in front of a?computer terminal typing at a keyboard, engineers and programmers are?susceptible to eyestrain, back discomfort, and hand and wrist problems?such as carpal tunnel syndrome.?Occupational Outlook Handbook, 2010-11 Edition 중에서
11%정도만 50시간이상이라고 합니다. 미국도 야근과 휴일근무가 있다는 뜻이네요. 프로젝트를 할 경우 일정을 맞춰야 하는 것은 어디서나 보편적인 진리이기때문에 어쩔 수 없나 봅니다.
Software developers and programmers usually work normal office hours,?but may work extra hours, including weekends and evenings, to meet?deadlines. They usually work in an open plan office. Some travelling may?be required.
2.
프로젝트 일정을 맞추기 위해 휴일근무나 야간근무는 공통이라고 하면 차이점은 없을까요? 이런 글이 보았습니다.
More features will always bring more revenue, more customer?satisfaction, other good things. Therefore there is always pressure for?people to work harder, longer hours.
한국이나 미국이나 이런 생각을 하는 경영자나 관리자 혹은 PM이 많을 듯 합니다.? 긴 노동시간 = 높은 생산성이라는 생각을 가진 사람들이 많은가 봅니다. 이런 생각을 갖는 높은 분들이 사용하는 방법은 압력(pressure)입니다.? 압력을 가하는 방법은 잘 아시죠?
SI프로젝트를 경험한 분이면 누구나가 짐작하시겠지만? 일하는 시간을?늘리면 생산성이 향상된 듯한 착각을 갖습니다. 사실 일정계획을 놓고 보면 전척도가 달라집니다.? 50%가 80%가 되고 결국 100%가 됩니다.? 프로젝트를 수행하면서 생산성 평가를 진척도로 합니다.
어떤 결과물을 내놓느냐는 사실 중요하지 않습니다. 목표설정 자체가 주먹구구식입니다.? 이 점은 RFP를 보면 알 수 있습니다.
프로젝트를 수행할 때 진리는 딱 하나, 보고한 일정대로 프로젝트를 마치느냐 입니다. 발주자는 일정대로 마무리되었다는 보고, 수주자는 용역대금을 필요로 할 뿐입니다.
일정돌파식으로 목표에 도달하도록 개발자를 닥달거리면 만사형통.
그러면 품질은?? 프로젝트를 마무리하고 나면 꼭 남는 문제가 버그를 어떻게 하느냐입니다. 대부분 편법을 씁니다. 짧으면 한달, 길면 몇달씩 개발자가 남아서 추가작업을 합니다. 물론 방법론이나 개발기준등을 준순하였는지는 논외입니다.
압력을 가하고 일하는 시간을 늘이는 방식으로는 생산성이 향상될까요? 물론 아닙니다. 많은 연구와 경험을 통해 아닌 것으로 증명되고 있습니다.
페어프로그래밍(Pair Programming), 피어리뷰(Peer Review)를 강조하는 미국도 역시 생산성과 야근은 무관하다고 합니다.
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.
A recent Circadian study addressed productivity in white collar?workers. They found that even as little as a ten percent increase in work hours could result in a 2.4 percent drop in productivity, while?sixty hour weeks could result in a 25 percent drop in productivity.?None of these studies have combined just the right ingredients to?tell us with accuracy what will happen if we drive our people too hard,?or where the line is. We can be certain, however, that code quality will?go down, and defects will go up, and that the effects will be felt at?pressures and hours well below 12 hours days or sixty hour weeks.
피플웨어, 데드라인으로 유명한 드마르코(Tom DeMarco)도? Slack에서 다음과 같이 야근(Overtime)이 비생산적임을 주장합니다.
Much analysis has been done to determine the correlation between?software function points / lines of code and work effort. This analysis?has shown that using workdays is more reliable as an indicator/predictor?than using workhours. The result is that “overtime is explicitly?ignored in projecting effort required to perform new work” (Slack, page?64).This means that on average, working overtime does not mean more is?accomplished than working a normal work day. DeMarco identifies four?reasons why overtime hurts enough to offset the effect of the addedhours:
- Reduced quality
- Personnel burnout
- Increased?turnover of staff
- Ineffective use of time during normal hours
(See Slack, pages 65-70 for further elaboration on these four points.)
파견근무없이 내부근무하는 개발자는 경영자, 관리자와 소통을 통해, 아니면 개발자들간의 협력을 통해 변화를 모색할 여지가 있습니다.
그렇지만 문제는 SI프로젝트로 파견나가서 근무하는 개발자들입니다. ‘갑’,’을’ 다음인 ‘병’인데 보통 ‘갑’이나 ‘을’은 납기준수가 거의 철칙이기때문에 쉽지 않은 문제입니다.
야근없는 프로젝트를 위해서 가장 먼저 ‘을’의 역할이 중요합니다.
추상적인 수준의 희망사항을 요구사항정의로 구체화하여야 합니다. 가능하면 개발과 관련된 일에 집중할 수 있는 환경을 만들어주어야합니다.? 야근을 하더라도 두주이상 지속하면 안됩니다.
그래도 필요하면 Steve Mcconell이 ‘Rapid Development: Taming Wild Software Schedules’에서 정의한 방법은 어떨까 합니다.? 야근을 하더라고 강압적인 방식이 아니라 자발적인 방식으로 하자는 권고입니다.
Overtime is misused more often than it’s used effectively, so keep the following guidelines in mind if you want to get more than 40 productive hours per week out of your team members.
1.Use a developer-pull approach rather than a leader-push approach
2.Don’t use overtime to try to bring a project under control.
3.Ask for an amount of overtime that you can actually get.
개발자의 건강에도 도움이 되지 않고,? 프로젝트의 생산성에 기여하지 못하고,? 일 더한다고 돈을 더주지 않으면서 야근을 강요하지 맙시다. 대신 Ineffective use of time during normal hours 을? effective use of time during normal hours로 바꾸는 방법을 더 고민합시다.(^^)
생산성과 야근이 무관하면 다행이지만… 더 떨어지는게 문제죠..ㅎㅎㅎ
대부분의 사람은 생산성이 향상된다고 알고 있어요…일정을 어떻게든 맞춘다고 생각하니까…
얽힌 실타래를 풀기보다 더 어려운 일인 소프트웨어개발 프로젝트의 관행인데. 쩝.
고객이든 개발사든 경영진이 IT에 대한 이해가 넓어졌으면 합니다.