일반인이 개발자에게 원하는 것??!

지인분이 사업체를 하시는데 오늘 전산 관계 문제로 저에게 상담하시더라구요. 저야 줏어든 것만 많아서 영양가 있는 답변은 못해드렸습니다만 느낀 것을 몇자 적어봅니다.

1. 클라이언트에게 외계어로 말하지 말라.

온갖 갖은 IT 용어를 쓰면서 난관을 빠져나가려는 극 소수의 개발자 들이 있습니다. 훌륭한 개발자는 일반어만을 사용해도 충분히 클라이언트에게 자신이 할 일과 할 것들을 이야기 해 줄수 있어야 합니다. 그렇지 않다면 자신의 말을 통역해 줄 수 있는 훌륭한 통역사와 같이 활동해야 됩니다.

2. 분석 없이 코딩 없다

완벽하지는 않더라도 클라이언트의 업무와 일을 파악하여 정확한 시스템 분석 후 코딩을 해야 합니다. 관련 지식이 없다면 코딩은 잠시 제껴두고 관련 업무 부터 배워야 합니다. 눈가리고 아웅하기씩 개발로는 얼마 가지 못해 프로그램을 다시 엎는 결과가 비일비재하게 일어납니다.

3. 할 수 있는 일과 할 수 없는 일을 분명히 하라

자기가 할 수 없거나 완성도가 낮을 것으로 예상되는 부분은 밝혀야 됩니다. 당장의 쪽팔림이 있겠지만 자신이 만든 누더기 소스를 받을 클라이언트는 향후 더 큰 절망을 안게 됩니다.

4. 합리적인 명세서를 작성한다.

항상 클라이언트의 망설임 혹은 막판 뒤집기에 혹은 돈 떼어먹기에 데어서 항상 여러가지 유상 옵션 추가와  +알파를 요구합니다만 일단 믿을 수 있는 클라이언트라고 생각되면 정확한 시스템 판단 후 향후 가능한 추가 옵션을 붙일 필요가 없는 자세한 명세서를 제출해야 됩니다. 고생하는 프리랜서나 IT 업체가 많은 것은 사실입니다만 그 반대로 IT 업체나 프로그래머를 칼 대신 키보드 들은 강도로 생각하는 일반인 들이 많은 것도 가슴아픈 일입니다.

5. 코딩 완료가 업무의 완료는 아니다.

코딩이 끝났다고 업무가 끝이 아닙니다. 그 2~3배의 시간이 걸릴 수 있는  QA, 문서화 작업, 프로그램 사용 법 설명 및 유지 보수. 아마 코딩은 전체 작업의 1/10 밖에 되지 않을 것입니다. 적은 보수와 많은 업무로 코딩 끝내고 바로 페이를 원하시겠지만 외주를 맡기는 클라이언트들은 완성된 프로그램을 접하는 순간 부터 더 많은 문제점에 직면하게 됩니다.  

아 저도 개발 경력이 있습니다만 오늘 이야기 듣고 다소 충격이었습니다. 뉴 3D로 불리우는 개발자 (Developer), 분명 약자임에는 분명합니다만 그 약자인 개발자들에게도 휘둘리는 클라이언트가 많다는 것을 꼭 기억해주시길 바랍니다. 오죽 클라이언트가 답답하면 학원에 가서 프로그래밍을 배운다고 하겠습니까. 개발자와 클라이언트들이 서로 대우 받으면서 살 수 있는 꼬꼬마 텔레토비 랜드를 생각하며 글 줄입니다.

오늘 들은 점을 느낀 것을 그대로 적은 것이며 개발자들에게는 무한한 존경심을 가지고 있음을 밝힙니다.

그럼~