프로그래머 업무 분장, 분업의 중요성과 SI 현실
- 블라블라
- 2018. 3. 3.
프로그래머 업무 분장, 분업의 중요성과 SI 현실
분업이 이뤄지지 않던 예전에는 코딩만 잘한다고 프로그래머가 아니란 이야기가 있었습니다. 과연 그럴까요? 업무 분장도 안 된 현실에서 그 말이 맞았나요? 왜 존경할만한 개발자가 그땐 많이 없었죠?
90년대 또는 현재 SI 회사만 봐도 개발자가 제안서 작성, 업무 회의, 프로그램 설계, DB 제작, 메뉴얼 작성, 검수, 그리고 계속 이어지는 코딩을 해야 합니다. 이걸 당연하게 생각하면 안 됩니다. 매우 비효율적이고 회사의 이윤 창출을 방해하는 덜떨어진 프로세스입니다.
즉, 업무 분장도 안 된 비효율적인 회사의 프로세스입니다. 분업의 중요성을 모르는 조직에서나 하는 비효율적인 업무 처리 방식입니다. 업무 분장 중요해요.
그리고, 우리 팀에서 무슨 일을 해야 하느냐? 그건 관리자가 결정해야죠. 실무 프로그래머까지 회의에 참석시키는 건 전형적인 헬조선 페이퍼 워크입니다. 왜 관리자가 할 일을 남에게 떠넘기나요? 이럴 거면 관리자가 필요 없죠. 관리자 내보내야죠.
분업이 지켜지면 개발자는 코딩에만 집중할 수 있어서 소스의 질은 늘어나 양은 오히려 줄어들 겁니다. 그만큼 함축적이면서 효율적인 소스를 작성하게 되면서, 동시에 중복 소스를 제거할 테니깐요. 집중해서 만든 소스 때문에 퍼포먼스는 증가하고 사후 관리해야 할 업무도 줄어들 겁니다.
이건 분업의 긍정적인 측면이죠. 업무 분장을 제대로 해야 한다는 뜻입니다.
90년대 IT 버블이 심했는데, 프로그래머들이 좋은 프로그램을 많이 만들지 못했습니다. 나라에서 돈을 쏟아부었는데 다~ 눈먼 돈 되버렸죠. 현재 SI 업체에서도 좋은 프로그램 만들지 못해요. 왜냐면 개발자에게 많은 업무를 지시하다 보니 코딩 수준이 떨어지기 때문입니다.
업무 분장이 안 된 상태에서 일을 합니다. 그 과정에서 개발자는 많은 업무를 담당하다 보니 만성 야근에 피로를 달고 삽니다.
프로그래머가 재충전하기 전에 또 다른 업무, 가령 다른 프로젝트를 위한 업무 협의나 제안서 작성 등 ... 개발자가 개발을 못 하게 만드는 업무 프로세스 때문에 회사 매출이 반 토막 난다는 생각을 해야 합니다.
이렇게 많은 업무에 치이면서 소스를 만들어 봐야 다른 담당자가 소스를 이해하는 데 시간이 오래 걸리고 처음부터 설계가 잘못된 프로그램을 다루다 보니 유지보수 시간과 비용이 더 많이 듭니다. 이 모든 게 분업의 필요성을 느끼지 못하고 덜떨어진 프로세스를 채택하는 회사들의 문제점입니다.
개발자의 능력을 극대화하려면 분업해야 합니다. 업무 분장 해야죠. 이건 고민할 게 아닙니다. 필수 사항이죠.
프로그래머 업무 분장, 분업의 중요성과 SI 현실