티스토리 뷰

아주 오랜 옛적 학교에서 배울때 SDLC(소프트웨어 개발 생명주기) 의 도표를 보며 설명되어진 것에는 분석에 많은 시간을 투자하는것이 나중의 유지보수의 비용을 줄이고 오류를 줄이는 방법이라고 나와있다.
그리고 회사에서도 분석및 설계단계에는 가장 유능한 인력(혹은 가장 경험이 많은)을 투입한다.또한 간단한거 하나 수정이나 개발하는는 데에도 분석이나 설계단계에서 요구하는 문서도 상대적으로 엄청나다.

그런데 그렇게 분석과 설계를 공들여 하는데도 사용자들은 항상 새로운걸 들고 와서 괴롭히는 걸까?
아까 오전과 오후에도 사용자와 약간은 격앙된 회의를 했다.또다시 먼가를 변경해달란다.
그럼 처음부터 그렇게 요청했었어야지.돌아오는 대답은 한결같다.처음부터 그럴줄 알았나?.
해보니깐 아닌걸 어떻하냐?..ㅋㅋ
물론 요구사항분석하고 설계할때 충분히 토의되고 설명되었던 일이었다.
요구사항대로 분석하고 설계하지만 사용자들은 자기가 요구했던 사항들이 구현되면 어떤일이 일어날지 예상하지 못한다.

예상하지 못한다기보단 허용하는 예상범위를 벗어나거나 뭔가 다른 문제가 생기는 거겠지.
이건 물론 분석과 설계단계에서 잘못된거다.어떻게 해결할까?
그럼 완벽한 분석과 설계란게 가능이나 한걸까?..

첫째 사용자들 스스로가  자기가 원하는 바가 먼지 모를땐 불가능하다.
(그냥 저것처럼 해주세요~~~.다른데는 이렇게 저렇게 되던데 그것처럼 해주세요.혹은 내가 가르쳐 줘야한다)

둘째 사용자가 설명하는 바를 내가 정확히 알아듣지 못할땐 역시 불가능하다.

셌째 사용자들은 자기가 원하는 바를 알고 그 결과치도 예상하지만 그게 아예 잘못됐을땐 역시 결과적으로 불가능하다.
(어 이게 아니네요.뭐 이럴줄 알았겠어여.이것만 이렇게좀 해봐 주세요)

그런데 문제는 저런것중에 하나는 반드시 일어나서 지속적으로 꾸준히 설계를 변경해야하는 요구가 일어난다는 것이다.
결국 누구에게 원인이 있고 어찌됐든간 정해진 일정에 못맞춘 우리가 항상 욕을 먹는다는것.사용자의 입장에서 최고 경영자의 분노어린 화살을 피하는 핑계중 제일은 역시 적당히 이쪽 핑계를 대는것..그래서 우리는 항상 욕먹는다.아마도 이 풍진 세상 오래살겠지.

오늘도 그일정이란것 때문에 회의내내 밀고 당기기를 했다..
밀고 당기기...
하지만 끝에  밀리는건 나다..
에고 고달픈 -의-  내인생아..ㅠㅠ
댓글