프로젝트 초기 단계에서의 교육

프로젝트 초기 단계에서 프로젝트 전반에 대한 프로세스(engineering process or managerial process)에 관해서 교육을 들은 적이 있습니까?

규모가 좀 큰 경우는 간혹 프로세스에 관한 교육을 하고 서로의 지켜야할 사항에 대해서 곰감대를 가지는 경우가 있던데, 대부분의 경우 그냥 시작... 저의 크고 작은 약 20여 번에 걸친 프로젝트 경험에 의하면 그러했습니다. 운 좋게 금융, 공공, 학교, 개인, 통신의 프로젝트를 골고루 해볼 경험이 있었는데. 프로세스에 대한 교육을 제대로 해본 경험은 없었습니다.

요구사항이 없었기 때문이 아닌가 하는데, 고객이 원하는 것이 산출물이었으므로 그외의 것은 모두 무시되거나 경시되는 분위기였습니다. 일반화의 오류를 각오하고 말한다면.. 모두가 거의 이렇지 않을까요?

예전에는 이런 현실을 탓했습니다. 왜냐면 프로세스는 품질을 위해서 지켜야할 가장 기본 적인 것이거든요. 성질이 급한 탓인지 품질을 위해서 프로세스를 중시하는 것이 아니라 품질을 논할 그 주체 산출물에만 너무 신경을 쓰는 그런 분위기에 많이 아쉬워 했던 것도 사실입니다.

그러나 한발 뒤로 물러나 생각해 보면, 프로세스를 중시하는 것은 아마도 영원히 이루기 힘든 일이지 않나 싶습니다. 그 이유에 대해서는 다음에 좀 자세히 더 이야기하기로 하고.. 현실을 고려한 해결 책은? 이라는 질문에 수백 페이지에 달하는 프로세스 핸드북을 가진 기존의 방법론은 그리 feasibility(!)가 있어 보이지 않습니다. 현장의 개발자들은 너무나도 바쁘고, 머리속과 마음속이 복잡하기 때문입니다. (머리속이 복잡한 것은 해야할 것이 많기 때문... 그럼 마음속이 복잡한 것은..아마도 잘못 길들여진 고객과 불합리한 하도급의 관행.. 때문이 아닐까요? 인터뷰에 응한 많은 개발자들이 머리속 보다 마음속이 더 복잡하다고 했습니다...)

서로 지켜야할 기본 원리만을가진 그런 방법론은 없을까? Kent Beck의 XP... 그 원리들은 소프트웨어 프로젝트의 가장 중요한 산출물인 코드에 촛점을 맞추고 있습니다. 현재 잘 돌아가는 소프트웨어 코드 뿐만 아니라 이후 의 필연적인 코드변경에도 능동적인 코드를 생산해 내게 하는 그런 원리들을 담고 있습니다.

진정한 성공을 원한다면 한번쯤 고려해 봐도 될듯..