Joypia

그동안 개발자들이 자기의 권익을 제대로 찾기 위해 여러가지 움직임이 일고있다. 2013년도에는 서울시에서 IT 개발자들을 모아 그들의 의견을 청취하기도 했는데, 깜작 이벤트로 끝난 것 같다. 그 뒤 개발자에게 직접 의견을 청취하는 노력을 별로 보지 못했다. 그러나 내가 보기엔 다른 분야는 모르겠으나 공공 SI 분야의 개발자들은 그 능력이 예전만 못하다는 느낌을 받는다. 물론 여기엔 여러가지 이유가 있다. 나중에 시간이 되면 이 부분에 대해서도 얘기를 해보고 싶다. 개발자로써 당당한 권리와 정당한 대가를 받고 싶다면 능력을 우선 보여줘야 한다. 잘 알다시피 코딩 실력외에 철저히 업무를 분석하는 능력과 설계 능력을 갖춰야한다. 이럴려면 문서 작성 능력과 리뷰하는 능력도 잘 갖춰져야 한다. 말도 안되는 표현으..

앞서 얘기 하고자 했던 것은 우리가 개발방법론이라는 것을 여러가지 도입해서 사용하고, 또 각각 방법론을 조합해서 사용하기도 하지만, 실제 얼마나 도움이 되는지는 안따지고 막연히 최면에 빠져 사용하는 게 아닌가 하는 점을 들었다. 과연 생산성이 올라가고, 품질이 높아졌는가 하는 것이다. 오히려 문서 작성으로 개발자를 괴롭히고는 몰라서 그런다. 능력이 없다라고 하면서 억지 춘향을 부렸다고 나도 양심고백을 하면서, 다른 PM 들도 다르지 않을 것이라고 감히 생각한다. 혹 동의 못하시는 분들에게, 한가지 예를 들고 넘어가자. 처음부터 개발하지 않고, 2차 또는 3차 개발 사업에 투입되었을 경우, 그 전 산출물을 얼마나 참조하는가? 그 많은 종류의 산출물 중에 몇가지나 들쳐 보는가? 다른 문제이긴 한데, 그 산출..

지금 부터 하는 얘기는 상당한 오류를 포함할 수 있다. 이글은 무려 7년 전에 작성했던거고, 내가 SW 공학 전문가도 아니요, 솔직히 개발방법론 가이더나 모델러도 아니기 때문이다. [생각하기 1] 개발방법론은 SW 개발을 성공시키는 필수 방정식이다. 공학이란 모름지기 수학이나 다른 기초과학처럼 이론에서 발전하는 것이 아니라, 상당한 경험을 분석하여 발전시키는 것이니, 개발방법론 또한 수많은 SW 개발 사례를 분석하여 나온 결과인 셈이다. 따라서 적합한 방법론을 적용한 것이라면, 그 방법론대로만 하면 그 개발은 반드시 성공할 것이다. [생각하기 2] 내가 프로그램을 짜기 시작한 후 상당 기간 동안은 나름대로의 방법으로 알아서 개발했다. 1990년대 말부터 개발방법론을 발주처에서 요구하기 시작했고, 처음 정..