[“딥뿔군의 글”:http://myruby.net/archives/002324.html]에 적혀있는 세가지 법칙을 보고 생각난 것을 적어보자면…
**1. ‘공격적인’ 스케쥴에 메인 프로젝트는 좀 더 타당한 스케줄을 따랐을 때보다 프로젝트를 끝내는 데 더 오래 걸린다.**
bq. 흔히 스케줄을 일에 비해 짧게 또는 희망적으로 잡는 경우인데, 스케줄은 프로젝트 관리에 경험이 적을 수록 비관적으로 잡는 것이 좋다고 생각한다. (경험이 많아지면, 스케줄을 재조정하는 것도 프로젝트에 나쁜 효과를 끼치지 않고 유연하게 할 수 있지 않을까 생각) 그런데, 의외로 이렇게 잡아야만 열심히 일한다고 생각하는 사람이 많다. 하지만, 경험적으로 리스크가 끼어들거나 해서 시간이 부족하면 위에서는 압력이 들어오고, 당사자들은 초조해지고, 그래서 프로젝트가 방향을 잃고 좌초하는 경우도 많다.
**2. 작업을 완료하는데 필요한 프로세스에 대한 자신의 직감을 모델링한다.**
bq. ‘직감’ 이런 단어가 들어가면 정말 어려운 것들이다. 책을 읽지는 않아서, 이 말이 무엇을 말하는지 정확히는 모르겠지만, 경험을 통해 직감을 성숙시키고, 이를 ‘모델’화하라는 말인 것 같다. 대부분의 책들은 이를 위한 의식적인 노력이 필요하다고 얘기하고 있다. 특히 ‘측정’을 통해, 원래의 예측이 얼마나 틀렸는지, 무엇이 원인인지 등을 파악해야한다. 난 측정까지가 아니라 원인 분석 정도에 그치고 있는데, 측정을 활용하면 좀 더 빠르게 이러한 직감에 이를 수 있지 않을까 생각해본다.
**3. 하루를 잃는 데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한가지 방법조차도 존재하지 않는다.**
bq. 내 경우, 하루를 잃게 되는 대부분의 경우는, 오늘 할 일을 내일로 미루는 것이다. 프로젝트 원에게 진행상황을 물어볼 것을 오늘 하지 못하는 경우, 무엇을 확인하고 시켜야할 것을 내일로 미루는 경우, 스케줄은 하루씩 미뤄지는 것 (단축할 수 없는 것)과 마찬가지인거다.
1. 너무 루즈한 스케쥴도 문제이지만(시간을 낭비하므로) 공격적인 스케쥴은 정말 도움이 안되는 해를 끼치는 일이라는데 동감
2. 모델링을 잘하는 능력이 꼭 필요할 듯.
Software Metrics가 지금은 별로 도움이 되지 않는 수준으로 보이지만 꼭 필요한 분야라는 생각을 세삼스레 하게된다.
comment를 중앙 정렬하니까 이상하다.