흔히들 전산 개발자들에게 많은 것을 원한다.
그게 조직 내부일수도 있고, 조직 외부일수도 있다.
(여기서 조직은 프로젝트를 같이 하는 그들이다. )
그들에게 들리지는 않겠지만,
회사옥상에서 술먹고, 소리 질러보는 심정으로 두서없이 글을 시작하고자 한다.
1. 문서를 바라지 말라!
흔히 바라는 점은 잘 정리된 문서를 원하는 일이다.
문서가 필요하다는 것은 개발자가 작성한 코드를 보기엔 시간이 없으니,
그 코드를 문장으로 풀어놓은 설명서 따위가 필요하다는 뜻이 되겠다.
하지만, 문서란 시간이 필요한 작업이고, 그런 설명서는 요건자가 만들어야 하는 것들이다.
개발자는 요건자가 원하는 방법으로 원하는 성능을 발휘하는 환경을 만들어 줄 뿐이다.
문서는 요건자가 만들기 바란다. (아니면 문서 작성하는 시간을 주던지? 그건 싫지? -_-;)
2. 프로그래머는 절대 모두 같지 않다.
처음부터 말을 하자만, 말짱 황 ~! 개 풀 띁어 먹는 소리다.
프로그래머는 천차만별이다.
어떤 넘은 메뉴얼을 보고 코딩 패턴까지 똑같이 진행하는 넘이 있는가 하면,
어떤 프로그래머는 보도 듣도 못한 로직으로 프로그램을 진행한다.
물론 전자도 후자도 나쁘다 할수 없다. 하지만, 시간과 효율성이 당연히 차이가 난다.
오너들이 흔히 하는 실수는 이 사람이 없으면 다른 놈 대려다 일 시키지~ 라는 개념이 있겠지만,
그건 달리는 차속에서 운전자를 바꾸는 위험한 방법과 동일하다는 점을 기억해야 한다.
(프로그래머를 회사에 보배로 생각해야, 그 회사가 성공한다. ㅋㅋ)
3. 프로젝트가 지연되는것은 인원이 적기 때문만은 아니다.
지연되는 프로젝트에 새로운 자원을 투입해서 진척 속도를 높일 수는 있다.
하지만 모든 경우 그런것은 아니다.
열심히 진행되던 프로젝트가 점점 느려지고, 예상 기일이 점점 늘어나고 있다면,
변경된 로직이나, 요건이 필요이상으로 많아 지고 있다는 점을 기억하기 바란다.
이런 늘어난 프로젝트 때문에 신규인력을 붙이면 그 사람들을 가르치는 시간때문에
프로그래머는 더 부담을 느낀다. (막말로 더 느려진다. 알간??)
4. 개발시간을 추정하는 것은 불가능하다.
어떤 변수가 어떻게 생길지 모른다.
원하는 요건이 100% 수정되지 않는 다는 전재로 개발시간을 산정하는 것이 아니라면,
절대 개발시간을 못박지 말아라. 촉박한 개발시간은 언제 터질지 모르는 폭탄을 들고 뛰는것과 같다.
5. 프로그래머의 생산성을 코드의 줄수와 같은 간단한 척도로 측정하여 하지 마라.
같은 프로그램을 더 간결히 짠다면, 그것이 능력이고, 그것이 혁명이다.
6. 시중에 나와 있는 경영혁신 프로그램을 무턱대고 전산에 적용하지 마라.
식스시그마, 블루오션 경영 등 공장에서나 통하는 경영혁신법을 무턱대고 전산에 적용하지 말아야 한다.
식스시그마는 단순화된 작업을 효율성있게 진행하여,
작업속도를 저해되는 문제들을 단계별로 해소해서 공정의 효율을 높이는 작업이다.
이것은 이미 메모리 관리주체인 서버나 메인프레임, 또는 컴파일러가 자동으로 결정한다.
사람들의 개발시점에 식스시그마를 적용한다 하더라도, 그 효율성은 미미하다,
잭윌치가 애플에 식스시그마를 적용했다면, 아이포드나, Max OS는 사장됐을것이다.
식스시그마는 더이상 신제품 개발이 거의 없는 , 백색가전, 혹은 자동차 업체에나 적용되는 법칙이다.
매일 매일 참신한 아이디어가 적용되는 전산에는 백해 무익하다.
어눌하고 수박겉할기 식에 적용은 Copy&Paste 만 할줄아는 Corder 만 양산할 뿐이다.
공군 파일럿 양산에 10억 넘는 다는 얘기가 있다.공군사관학교 4년에 실무 경력까지 하면,
쉽게 생각해서 고유가 시대에 비행기 연료비만도 10억이 넘을 거란 단순한 생각도 한다.
막말로, 기계 다루는 운전사 정도가 이렇게 양산비용이 많이 든다는 얘기다.
잘짜놓은 프로그램으로 이륙부터 발사까지 수 많은 계기판 안보고 맘대로 할수 있게 만들면
어떨까 라는 생각을 해본다. (솔직히 비행기 운전사 정도가 어깨에 힘주는 것 보기 싫다.)
재취업 전문학교, 학원에서 찍어내듯 나오는 코더들이 아닌 ,
진정한 프로그래머들이 더 많아 지는 날이 오길 바라며 글을 접고자 한다.
