9 Scheduling #1465
Description
제 9장 일정
일정을 제대로 세우면 급하게 잘못된 결정을 하는 걸 막을 수 있다.
일정 수립은 효과적인 계획 수립, 신중한 설계, 품질보증을 통해 시간을 절약하는 데 중요하다.
일정은 누가 세우는가
"이 분야에 일하는 사람 중 대부분은 일정에 대한 통제력이 없다. 일정은 위에서 결정되서 내려온다."
"이 분야에서 누구 못지 않게 까다로운 비판자로서, 현장에서 일하는 많은 사람들과 대화를 나눈다. 모두 예외없이 일정 문제가 가장 크다고 말한다. 급속하게 변하는 기술도 아니고 새로운 관리 철학도 아니다. 불가능한 일정을 맞추기 위해 일하는 상황이 가장 큰 문제다." - 로버트 글래스
9.1 지나치게 낙관적인 일정
오래동안 전통적으로 내려온 문제이다.
- 1967년 진 불린스키는 "중대한 프로그램 문제는 어떤 문제든 응급하다고 판명난다"고 했다. (Bylinsky 1867)
- 1970년대, 프레드 브룩스는 "시간 부족으로 실패한 프로젝트 수가 다른 원인을 모두 합했을 때보다 많다"고 지적했다. (Brooks 1975)
- 스콧 카스텔로는 "소프트웨어 공학에서 기한 압력이 가장 큰 적이다"라고 말했다 (Castello 1984)
지나치게 낙관적인 일정 수립 사례
마이크로소프트 워드 개발 사례가 좋은 예다.
5년의 개발 기간 600 M/M 249,000 라인 코드로 만들었다 (Iansiti 1994)
최종 일정 5년은 원래 계획한 일정보다 5배나 길었다.
- 윈워드는 달성할 수 없는 목표를 세웠다. 빌 게이츠는 팀에게 '가장 우수한 문서 작성기 개발'과 '가급적 빨리, 12개월 안에' 라는 지시를 내렸다. 둘 중 하나는 가능할 수 있었지만 둘 다는 불가능했다.
- 프로젝트 중도 이직률이 높았다. 5년 간 개발 수석이 네 번이나 바뀌었다. 일정 압력으로 2명, 건강문제로 1명이다.
- 일정 때문에 개발자들은 기능을 대충 구현했다. 미완성인데도 완료로 보고했다. 3개월 걸린다고 보고한 안정화 작업도 12개월이 걸렸다.
윈워드는 쾌속 개발보다는 혁신이 더 중요한 프로젝트였다. 따라서 그에 맞는 계획을 세웠어야 했다.
만약 윈워드가 효율적인 개발 프로젝트로 설정하고 일정을 잡는다면 22개월을 예측할 수 있다.
이렇게만 했어도 개발 수석 이직과 긴 안정화 기간을 초래한 일정 압력은 덜었을 것이다.
막연한 기대가 주의깊은 계획 수립을 대신할 수는 없다.
막연한 기대로 일정을 세우는 프로젝트는 몇 주에서 몇 달에 이르는 일정 지연이라는 대가를 치르게 된다.
지나치게 낙관적인 일정을 세우게 만드는 근본 원인
- 전시, 법률, 쇼핑 시즌과 같이 변경할 수 없는 기한이 있다.
- 예측값 범위를 무시하고 최선의 경우를 예측값으로 하고 계획을 세운다.
- 도전이나 압력 조건에서 일하는 걸 선호해서 프로젝트를 고의적으로 축소 평가한다.
- 낮은 입찰가를 제출할 목적으로 프로젝트를 축소 평가한다.
- 일정이 촉박하면 개발자가 더 열심히 일할 것이라 믿고 일정을 잡는다.
- 특정 마감 날짜를 요구하는데, 설득을 못한다.
- 현실적인 일정으로 시작했지만, 새로운 기능을 추가하면서 낙관적인 일정으로 변한다.
- 프로젝트 예측을 제대로 할 줄 모른다.
지나치게 낙관적인 일정이 미치는 영향
프로젝트를 가능한 빨리 마치기 위해 일정을 짧게 잡는게 합리적이다.
설계와 구현을 빨리 하라고 개발자를 독려할 수 있는지에 대한 대답은 "소프트웨어에서는 효과가 없다" 이다.
일정 정확도
낙관적인 일정이 효과가 없는 첫 번째 이유는 일정 정확도를 떨어뜨리기 때문이다.
개발자들은 스스로 프로젝트를 20%~30%정도 축소 평가하는 경향이 있다 (van Genuchten 1991)
개발자가 내놓는 예측값을 사용하면 정확도는 떨어진다. 결국 출시가 늦게 될 가능성만 높아진다.
프로젝트 계획 수준
지나치게 낙관적인 일정은 효과적인 계획 수립을 막는다.
계획 단계에서 잘못된 가정을 세워도 수행에 차질이 없다면 문제는 없겠지만 불행히 그런 일은 불가능하다.
그릇된 가정은 비효율적인 프로젝트 계획을 세우게 만든다.
일정을 낙관적으로 세우면 계획이 살짝 어긋나는 정도로 끝나지 않는다.
평균 소규모 프로젝트 예측값은 오차가 100%가 넘는다. (Standish Group 1994)
평균 대규모 프로젝트는 1년 정도 늦어진다. (Jones 1994)
이정도 오차라면 프로젝트 계획을 세우는 건 쓸모가 없는 셈이다.
계획 고수
계획을 효과적으로 세워도 일정 문제에 부딪치면 전문 소프트웨어 개발 회사가 아닌 회사 대부분은 계획을 무시하고 멋대로 한다 (Humphrey 1989).
낙관적이고 달성 불가능한 일정에서는 프로젝트가 계획없이 흘러 갈 위험이 증가한다.
프로젝트 범위 축소
지나치게 낙관적인 일정은 요구사항 분석이나 설계에 쓰는 시간이 줄어든다.
정상적인 프로젝트라면 개발 시간의 1/3을 설계로 쓴다.
하지만 일정이 촉박하면 요구사항 분석과 설계를 적당히 얼버무리거나 끝내지 않고 넘어간다.
프로젝트 시작에서 저지른 실수는 나중에 비용과 시간을 증가시킨다.
프로젝트 초점
지나치게 낙관적인 일정은 관리자가 프로젝트 진행 업무를 소홀하게 만든다.
프로젝트에 드는 기간과 새 일정이 원래 일정보다 더 믿을만한 이유를 고객에게 설명해주는 데 주의를 돌린다.
매번 기한을 놓칠 때마다 일정을 재조정해야 하고 그 작업 역시 개발자 시간을 뺐는 셈이 된다.
고객 관계
프로젝트가 낙관적인 출시 날짜를 맞추지 못하는 분위기면 고객, 관리자, 사용자는 불쾌해한다.
프로젝트가 무리 없이 진행중이라고 해도 문제가 있거나 통제가 안된다고 가정한다.
이렇게 되면 프로젝트 관리자는 프로젝트 보다는 고객 관계 관리에 신경을 쓰게 된다.
개발자도 프로젝트 진행 업무 보다는 고객을 안심시키기 위해 보여주기식 업무를 하게 된다.
성급한 통합
소프트웨어 개발자라면 제품 기능을 완료하고 안정화하기 전에 출시 버전을 만드는 일은 의미 없다고 할 것이다.
그런데도 지나치게 낙관적인 일정에서는 이런 무모한 일을 저지른다.
1년 프로젝트라면 8주 ~ 12주 전에 제품 출시를 위한 준비를 한다.
보통 프로젝트 출시 직전만 하는 시간 소모성 업무를 수행한다.
프로젝트 통합을 너무 일직 수행하려고 시도하면 실패한다.
이런 시간 소모성 활동을 나중에 다시 수행해야만 한다.
한 번으로 충분한데, 두 번 수행한다면 이는 당연히 비효율적이다.
그외 여러가지 측면에서 성급한 통합은 시간을 낭비한다.
성급한 통합이 미치는 가장 나쁜 영향은 개발자 사기 저하다.
장기적인 프로젝트는 속도 조절이 중요한다.
성급한 통합은 개발자를 너무 빨리 지치게 만든다.
프로젝트 관리가 안 되서 제품 통합이 안된다는 걸 알고 다서야 처음으로 일정에 문제가 있음을 깨닫는 경우가 흔하다.
처음에 통합을 할 수 없으면 일단 물러서서 일을 계속하고 나중에 다시 시도해야 한다.
그러나 낙관적인 일정에서는 통합을 성급하게 그리고 여러 번 시도하게 된다.
성급한 통합과 잦은 통합, 이 두 가지 모두가 일정을 지연시킨다.
과도한 일정 압력
일정을 맞추지 못하면 고객과 관리자는 개발자에게 압력을 줘서 초과근무를 요구한다.
큰 프로젝트는 75%에서 초대형 프로젝트에서 100%에서 과도한 일정 압력이 이루어지고 있다. (Jones 1994)
소프트웨어 개발에서 개발자들은 일정 압력을 어쩔 수 없는 현실로 받아들인다.
낙관적인 일정이 실제 개발 일정을 망쳐도 과도한 일정 압력 만큼은 아니다.
품질
소프트웨어 오류 40%가 압력 때문에 생긴다고 밝혀졌다. (Glass 1994c)
극단적인 일정 압력에서 출시한 제품은 그렇지 않은 제품보다 4배나 많은 결함을 발견하기도 했다 (Jones 1994)
오류 유발성 모듈이 생기는 원인도 과도한 일정 압력으로 밝혀졌다 (Jones 1991)
일정 압력이 극단적으로 높으면 개발자들도 품질 보다는 업무에 치중하게 된다.
팀의 코드를 검토하는 일 보다는 자신의 코드를 더 작성하는 걸 택하게 된다는 뜻이다.
다음 부터 코드 검토 한다는 생각은 하지만 그렇지 못한 선택으로 인해 품질은 떨어진다.
도박
지나치게 낙관적인 일정을 달성하기 불가능하므로, 관리자와 개발자들은 위험을 계산하고 감수하기 보다는 도박에 눈을 돌리게 된다.
일정 압력은 위험 관리를 소홀하게 만들고 실수를 저지르게 만들어 개발 속력을 늦춘다.
동기
낙관적인 일정이어도 달성 가능한 목표라면 작은 일정 압력이 의욕을 자극할 수도 있다.
하지만 믿을 만한 수준을 넘어서는 순간 의욕은 급속하게 떨어진다.
지나치게 낙관적인 일정은 개발자들이 열심히 일해도 실패자로 낙인찍히는 상황을 만든다.
개발자에게 불가능한 일정을 약속시켜 동기를 불어 넣으려고 하면 정확히 그 반대를 얻을 것이다.
창의성
소프트웨어 개발은 많은 면에서 창의력이 필요하다.
그와 더불어 깊은 사섹과 끈기도 있어야 한다. 이는 자발저긴 의욕에서 나온다.
외부에서 오는 과도한 동기 자극은 자발적인 의욕을 떨어뜨리고 결국 창의성을 저하한다 (Glass 1994a)
쇠진
한 프로젝트에서 초과근무를 너무 많이 하면 개발자들은 다른 프로젝트에서 보상을 받으려고 한다.
개발자에게 일정 압력을 너무 심하게 준다면 다음 프로젝트까지 갈 필요도 없이 현재 프로젝트에서 이런 현상을 발견하게 된다.
이직률
대체로 프로젝트를 그만두는 사람은 높은 성과 펴가를 받은 가장 우수한 인력일 확률이 높다 (Jones 1991)
장기적인 관점에서 쾌속 개발
초과 근무로 개발자는 자신의 경력 개발에 쓸 자유 시간을 뺏긴다.
스스로를 연마하지 않는 개발자는 새로운 기술을 배울 수 없다.
개발자와 관리자의 관계
개발자는 관리자가 개발자를 존중하지 않고 신경쓰지 않는다고 느깐다.
불가능한 일을 요구할 만큼 소프트웨어 개발에 무지하다고 생각한다.
Figure 9-4. Unreasonable schedule pressure can cause developers to lose respect for their managers.
결론
소프트웨어 개발은 따분한 공학 과제가 아니라 모험이어야 하기 때문에 프로젝트 일정을 낙관적으로 잡아야 한다고 생각한다.
그리고 일정 압력이 개발 의욕을 자극한다고 말한다.
소프트웨어 프로젝트를 과소평가하고 불충분하게 계획하는 일도 스스로 무덤을 파는 행위다.
제럴드 와인버그는 Quailty Software Management에서 소프트웨어 프로젝트를 시스템으로 간주하라고 제안했다(Weinberg 1992)
일정을 정확하게 계획한 프로젝트를 시스템으로 표현하면 그림 9.5와 유사하다.
Figure 9-5. System diagram for a project with an accurate schedule. Most people will be happy with the outputs from an accurately-scheduled project.
일정을 지나치게 낙관적으로 세운 프로젝트를 표현한 시스템은 불행하게도 그림 9.6과 유사하다.
Figure 9-6. System diagram for a project with an overly optimistic schedule. Most people won't like the outputs from a project with an overly optimistic schedule.
결론적으로 지나치게 낙관적인 일정을 수립하는 관례는 효과적인 계획 수립을 막고 개발자의 능력을 약화시키며 고객 관계 손상, 높은 이직률, 제품 품질 저하를 일으킨다.
또 저급 개발자 양산으로 소프트웨어 개발 수준을 전반적으로 낮추기 때문에 바람직하지 않다.
무엇보다도 지나치게 낙관적인 일정은 효과가 없기 때문에 강력히 반대한다.
실제로 일정을 단축하지 못하며, 오히려 늘일 뿐이다.
9.2 일정 압력 해소하기
일정 압력 문제를 풀기 전까지 쾌속 개발 문제를 풀 수 없다.
그림 9.7과 같이 일정 압력은 스트레스 심화, 실수 증가, 일정 지연 증가, 일정 압력 증가라는 악순환을 만들어 낸다.
*Figure 9-7. Vicious circle of schedule-pressure and schedule-slips. Anyone who wants to solve the problem of rapid development must first solve the problem of excessive schedule pressure.
소프트웨어 개발 산업 종사자로서 일정 압력을 해소하는 방법을 배울 필요가 있다.
소프트웨어 일정 수립 과정에서 많은 문제가 발생하는 이유를 다음 세 가지로 요약할 수 있다.
- 막연한 기대
- 소프트웨어 예측 이야기나 낙관적인 일정이 미치는 영향에 대한 무지
- 협상 기술 부족
또 개발자들은 다음 이유로 협상에 미숙하다.
- 개발자들은 대개 내향적이다. 다른 사람과 잘 어울리지만 대립하는 일은 성격에 맞지 않다.
- 개발자들이 영업부와 협상하는 건 불리한 입장에서 협상을 시작하는 셈이다. 영업부원은 보통 나이가 많고 협상으로 먹고 사는 사람이라고 제럴드 와인버그는 지적했다. (Weinberg 1994)
- 개발자들은 기질상 협상 기교를 싫어하는 편이다. 그런 기교는 기술상 정확성과 공평성을 침해한다고 여긴다.
일정 협상이 어려운 이유
고객의 기대 날짜를 맞추기 위해 그릇된 일정을 세우는 관례는 다른 어떤 공학 분야보다 소프트웨어 분야에서 훨씬 쉽게 찾아볼 수 있다. 정량적인 방법이나 뒷받침하는 자료없이 관리자의 직감으로 내놓는 예측값을 강력히 설득하기는 매우 어렵다." - 프레드 브룩스
원칙적인 협상
Getting to Yes에서 제시하는 원칙적인 협상 방법이 협상 기술 향상에 좋은 시작점이 될 수 있다(Fisher and Ury 1981)
- 상대가 사용하는 협상 기술에 대응한다.
- 양쪽 모두 유리한 방안을 모색하는 데 기반을 둔다.
- 협력을 통해 양쪽 모두가 승리하는 방법을 찾으려고 한다.
이 방법은 양측 모두가 이해하고 사용할 때 가장 효과가 있다.
협상 전략은 사람, 이익, 방안, 기준을 다루는 네 부분으로 이루어져 있다.
- 문제와 사람을 구분하라.
- 입장보다 이익에 집중하라.
- 서로 이익이 되는 방안을 만들어라.
- 객관적인 기준 사용을 주장하라.
문제와 사람을 구분하라
중간 관리자 대부분이 불가능한 일정을 요구하는 이유는 멍청하거나 불합리하기 때문이 아니다.
불가능함을 깨닫지 못할 정도로 기술적 업무를 모르거나 상사, 고객, 경영진이 주는 압력을 너무 직접적으로 느낄 뿐이다.
개발자가 할 수 있는 일은 다음과 같다.
- 고객 관계 개선을 위한 노력
- 협력하는 태도
- 고객의 기대 수준을 현실적으로 인식시키기
- 소프트웨어 예측을 확실히 이해시키기
- 일정 문제에 조언자가 되고 반대자라는 인식 심어주지 않기
- 일정을 줄일 수 있게 프로젝트를 변경 제안하기
협상 공식에서 감정을 제거하는 시도 역시 유용하다.
상대가 화를 낸다고 감정적으로 대응하면 안된다.
상대가 자신의 입장을 완전히 표현하도록 유도한다. 그리고 그 감정을 이해하고 있다고 알려야 한다.
그리고 서로 이익이 되는 해결책을 찾기 위해 애쓰겠다는 약속을 반복하여 강조한다.
입장보다 이익에 집중하라
일정 협상에서 중요한 문제는 단지 일정에만 치중해서 피상적인 협상이 되기 쉽다는 점이다.
입장에만 매달리지 말고 모든 각도에서 대안을 검토할 용의가 있음을 명백히 밝혀라.
상대편이 특정 일정을 고수한다면 다음과 같은 방법을 사용해본다.
- 진짜 개발 속력으로 설득하라: 낙관적인 일정은 실제 개발 속력을 늦춘다는 사실을 강조한다.
- 성공 가능성 증가로 설득하라: 일정을 줄이면 제시간에 완료할 가능성은 더 줄어든다.
- 회사 프로젝트 기록을 지적하라: 프로젝트 과소평가, 출시 지연 등 회사 프로젝트 내력을 지적하라.
상호 이익이 되는 방안을 만들어라
한 편이 져야 다른 편이 이기는 제로섬 게임으로 보면 안된다.
문제를 창의적으로 해결해가는 과정으로 봐야 한다.
양 편이 모두 이기는 방법을 찾는 사람이 진짜 똑똑한 협상가다.
일정 협상에서 가장 강력한 우방은 상대편이 전혀 알지 못하는 방안을 생각해내는 능력이다.
기술 지식을 가진 사람은 개발자이므로 비개잘자보다 창의적인 해결책을 생각해내야 할 책임이 더 무겁다.
소프트웨어 프로젝트에 얼마나 많은 자유도가 있는지를 생각해보면 도움이 된다.
일정, 비용, 제품 삼각형의 세 꼭지점에서 균형을 잡아야 프로젝트가 성공한다.
삼각형의 균형을 잡는 방법은 다양하며 상대편이 특정 조합을 더 마음에 들어할 수도 있다.
제품 자유도는 다음과 같다.
- 원하는 기능 일부를 다음 버전으로 옮긴다. 요청 당시에 모든 기능이 다 필요하지 않기 때문이다.
- 중요한 기능 부터 단계적으로 출시한다.
- 기능을 완전히 쳐낸다. 시간이 오래 걸리거나, 통합이 필요하거나 호환성을 유지해야 하거나 성능 문제가 있는 기능은 협상 가능하다.
- 기능 치장을 줄여라. 적정 수순까지 구현하고 치장하지 말자.
- 상세 요구사항에 여유를 둔다. 기존 상용 컴포넌트를 이용해 요구사항에 가능한 가깝게 구현한다고 목표를 정하라.
프로젝트 자원에 관한 자유도는 다음과 같다.
- 초반에 개발자를 더 투입하라.
- 효율이 높은 개발자를 투입하라.
- 테스트 담당자 수를 늘여라.
- 행정 지원을 늘여라.
- 개발자 지원 수준을 높여라.
- 관료주의를 타파하라.
- 최종 사용자 참여 정도를 높여라.
- 경영진 참여 수준을 높여라.
프로젝트 일정에 관해 제안할 수 있는 자유도는 다음과 같다.
- 상세 설계, 제품 설계, 요구사항 명세를 끝낼 때까지는 최종 기한을 정하지 말고 일정 목표를 세워라.
- 프로젝트 초반에 제품 개념, 명세, 설계를 구체화하는 과정에서 개발 기간을 줄이는 방법을 찾는데 합의하라.
- 예측값 범위나 근사치 예측값을 일단 사용하고, 프로젝트를 진행하면서 구체화해 나가자고 합의하라.
몇 가지 자유도가 더 있는데 개발기간을 줄일 수 있지만 정치적으로 곤란한 문제일 가능성이 크다.
상대쪽에서 공감해주리라 확심할 때 까지 말을 안하는 게 낫다.
- 개발자 지원 수준을 높인다. 쇼핑, 식사, 세탁, 집 청소, 잔디 관리 등이다.
- 개발자에게 동기를 부여하라. 유급 초과 근무, 보상 휴가 보장, 이익 배당, 하와이 포상 휴가 등이다.
일정, 비용, 제품 삼각형을 불균형하게 만드는 조건에 동의하면 안된다.
일단 기능 집합에 동의하고 나면, 삼각형 크기는 사실상 물리법칙을 따른다는 사실을 기억해야 한다.
세 꼭지점은 항상 균형을 맞추게 되어 있다.
협상하는 동안에는 할 수 있는 일을 강조하라.
할 수 없는 일을 약속해서 진퇴양난에 빠지는 상황을 피하라.
해야 한다는 압박에 할 수 없거나 불가능하다고 대답해야 하는 상황을 피하고
선택할 수 있는 여러 방안을 제시해 할 수 있는 일을 놓고 토론하는 데 집중하라.
객관적 기준 사용을 주장하라
이 분야에서 가장 기이한 현상 중 하나는 고객이나 관리자가 신중하게 계산한 예측값이 예상보다 크게 길면 그저 무시해버리는 현상이다. (Jones 1994)
예측값을 의심하는 건 타당하고 유용하지만 예측값을 버리고 막연한 기대로 대치하는 습관은 타당하지도 않으며 유용하지도 않다.
원칙적 협상에서 교착 상대를 깨는 열쇠는 객관적인 기준 사용이다.
상대편과 가장 적합한 기준에 대해 의논하고 그들이 제안하는 기준에 귀를 기울인다.
압력에 굴복하지 않고 원칙에만 승복하는 것이다.
몇 가지 지침은 다음과 같다.
- 예측값 자체를 협상하지 마라.
- 전문가에게 예측을 맡기자고 주장하라.
- 합리적인 예측 절차를 고수하라.
- 폭풍을 견뎌라.
읽을 거리
- DeMarco, Tom. Why Does Software Cost So Mush? New York: Dorset House, 1995.
- 소프트웨어 비용 연구에 대한 상당한 통찰력을 담고 있다. 상식적으로 효율적인 개발자 중심 개발법을 얘기한다.
- DeMarco Tom. and Timothy Lister, Peopleware: Productive Projects and Teams. New York: Dorset House, 1987.
- 비현실적인 소프트웨어 일정을 강력하게 비난한다. 과도한 압력을 받는 개발자를 정신적으로 지지한다.
- Maguire. Steve. Debugging the Development Process. Redmond, Wash.: Microsfot Press, 1994.
- 일정을 촉박하면서도 긍정적으로 세우는 방법, 과도한 초과근무가 미치는 영향을 점검한다.
- Gilb, Tom. Principles of Software Engineering Management. Workingham, England: Addison-Wesley. 1988.
- 고객과 상사의 기대를 현실과 맞추기 위한 실용적인 조언을 제시한다.
- Costello, Scott H. 'Software engineering under deadline pressure.' ACM sigsoft Software Engineering Notes, 9:5 October 1984, pp. 15-19.
- 일정 압력이 우수한 소프트웨어 개발법에 미치는 많은 영향을 통찰력 있게 집어낸다.
- Fisher, Roger, and William Ury. Getting to Yes. New York: Penguin Books, 1981.
- 모두가 이기는 협상에 초점을 맞춰 원칙적인 협상 기법을 제시한다. 협상 기교를 쓰지 않으면서 상대가 쓰는 기교를 되받아치는 방법을 설명한다.
- Iansiti, Marco. 'Microsoft Corporation: Office Business Unit.' Harvard Business School Case Study 9-691-033, revised May 31, 1994, Boston: Harvard Business School, 1994.
- 윈도우 1.0용 워드 개발에 쓴 재미있는 연구 논문이다.