Joypia

머 거창(?)하게 제목을 붙였지만 어디까지나 개인적인 생각이다. 공공SI를 하기 위해 계약과 관련된 문서 중 가장 비중이 큰 세 개가 있다. 보통 RFP 라고 하는 제안요청서, 이 걸 보고 밤새워 업체에서 만드는 제안서, 그리고 수주하게 되면 10일 이내 만들어 내는 사업수행계획서가 그 것이다. 이들의 의미를 생각해보자. 확실한 근거를 찾기 위해 여기 저기 뒤져야하지만 매우 귀찮은 관계로, 그냥 내가 이제껏 들어 왔거나,혹은 어디서 봤거나, 아무튼 내가 인지하고 있는 것으로 설명해 보겠다. 우선 제안요청서부터 살펴보자. 제안요청서가 만들어지려면 먼저 사업계획서가 만들어 져야 한다. 그래야 내부적으로 결재도 받고, 예산도 받고 할 수 있다. 이 거 만들 때, 요즘은 공공기관이나 정부부처 담당자가 직접 만드..

SI 프로젝트에서 요구분석은 매우 중요하고, 이 때 강조되는 것이 고객과의 의사소통이다. 물론 이 의사소통은 요구분석시 뿐만 아니라 프로젝트가 끝날 때 까지 고객과의 관계유지에 매우 중요하다. 뿐만 아니라 팀원끼리의 의사소통도 매우 중요하다. 이 부분에 대해 간략하게 얘기하기 전에 지금 중고등 학생-과연 대학생이 되면 이 현상(?)이 없어지는지는 모르겠지만- 의식구조의 한 단면을 살펴볼 필요가 있다. 이 이야기는 우리 애들과 관련되어 어느 한 설명회에 갔을 때, 관계자(장학사인지 교육감인지 기억이 잘 나지 않지만)에게 들은 말이다. 요즘 청소년은 지시한 행동에 대한 유추가 안 된다는 것이다. 예를 들어, 선생님이 복도를 지나가다 떨어져 있는 휴지를 보고 그 옆에 있는 학생에게 이렇게 말했다고 치자. "학..

난 SI 프로젝트에서 고객보다 반 보(요즘은 한 보 앞서가는 건 거의 불가능하다) 정도만 앞서가길 원한다. 매번 프로젝트가 시작되면 PM 이나 PL 들에게 요구하는 첫 번째 사항이다. '고객보다 반보 앞서 가라.' 1. 이는 고객이 얘기하기 전에 먼저 선수를 치라는 얘기다. 고객이 무엇을 궁금해 하는지 미리 파악하여 준비를 하고 일정을 통보하는 것이다. 물론 고객이 전혀 생각 안할 수도 있다. 이 경우에도 고객에게 신뢰를 심어 준다. 2. 고객이 요구하는 것 보다 조금 더 확대된 서비스를 제공하는 것을 뜻한다 고객이 두 가지 안을 보자고 하면 3가지 방안을 만들어서 보여주어야 한다. 기능이나 범위를 확대하아는 얘기가 아님을 명심하자. 3. 미리 일어날 수 있는 문제를 예고할 수 있는 것을 뜻한다. 미리 ..

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

단일 시스템 구축의 프로젝트가 아니라 여러 개의 단위 시스템을 구축하고 그것들 간에 연계가 이루어지는 과업이 있다면, 각 시스템간 연계 부분을 정의하고 설계를 하겠지만 반드시 전체적인 관점에서 정리할 필요가 있다. 보통 연계를 정의하고 식별하기 위해서는 다음과 같은 산출물들이 생성된다. - 인터페이스 정의서 - 인터페이스 명세서 - 인터페이스 구성도 각 시스템별로 자기 입장에서 연계 부분에 대해 정의 및 명세화를 하고 나면 공통 업무로 전체를 통합하여 작성할 필요가 있다. 이 때 혹시나 서로 연계에 대한 정의를 다르게 기술하거나 누락된 것이 있는지 점검할 수 있게 된다. 통상 인터페이스 정의는 다음과 같은 항목을 정의한다. 1. 송신 항목 - 송신 시스템명 - 프로세스명(프로세스 ID 포함) - 프로그램..

차를 몰고 가다보면 가끔 '사고다발구간'이라는 표지판을 볼 때가 있다. 그 구간 또는 지역을 하나하나 살펴보면 별 문제가 없는 것처럼 보인다. 아마도 그 구간의 도로 여건, 신호체계, 교통량 등 여러 가지 주변 특성으로 인해 사고가 다른데 보다 빈번하게 일어나는 게 아닌가 싶다. 마찬가지로 SI 프로젝트에도 '사고다발 프로젝트'가 존재하는 것이 아닌가 하는 생각이 든다. 정리한 것은 없지만 괘 경험이 있는 PM 이나 개발자들은 나름대로 사고다발의 조건을 알고 있을 것 같다. 물론 도로의 사정과 교통체계 등 여러 가지가 변하듯이, 프로젝트도 환경이 변함에 따라 그 조건도 변하고 있는 것 같다. 뻔히 보이는 위험이 있는 경우가 아니라 별개로 보면 문제가 없는데 사고가 발생하는 프로젝트의 경우 또는 조건을 정..

막 인터넷상에 쇼핑몰 서비스가 여기저기 생겨나기 시작할 때쯤의 에피소드이다. 당시 나는 웹에이전시 회사에서 제 2의 개발자 길을 걷고 있었다. 그동안 파워빌더 코드로 C/S 프로그램 개발을 하고 있었다면, 이 때는 웹 프로그래밍을 하고 있었는데, ASP가 주였고 가끔 PHP와 Perl 을 다루었다. 나는 당시 다른 개발자와는 좀 다른 서비스를 고객에게 제공하고 있었다. 그전에 파워빌드 코더 였으므로, 관리자 페이지는 파워빌더로 개발하여 별도로 제공했던 것이다. 사실 당시엔 보안에 대해서는 거의 무방비 이었기에, 나름 웹상에 백도어로 관리자 페이지를 접근하기도 해서 보안에 대한 일부 방안이 되기도 했다. 내 입장에서는 그런 치밀하고 깊은 뜻이나 보안적 측면을 충분히 고려한 적 없고 그냥 개발하기 편해서 였..

프로젝트를 진행하다 보면 매번 소홀히 하는 것이 있다. 그 중 하나가 메뉴얼 작업이다. 메뉴얼 작업이 소홀한 이유는 크게 두 가지로 생각된다. 첫 째, 글재주도 없고 작성 가이드가 너무나 개발자 위주이다. 작성 가이드가 얼마나 형편 없는가 하면 화면설계서에서 항목을 조그만 바꾸면 사용자 메뉴얼이 된다. 이렇게 하지 않고 무언가 그래도 마지막으로 작품(?)을 남기고 싶어서 일반적인 형태의 크라운판 메뉴얼을 만든다고 해도 실제 사용자는 알아보기 힘들게 만들어진다. 아무리 알기 쉽게 쓴다고 해도 그것은 작성자 기준이다 보니 생기는 현상이다. 그러니 설령 소홀히 하지 않았다고 해도 보는 사람은 대충 만들었다고 느낄 수밖에 없을 것이다. 둘 째, 대부분의 개발이 끝난 끝물에 작업하기 때문이다. 보통 SI 프로젝트..

일기기 전에 - 이 글은 무려 7년 전에 작성한 것이어서 상당한 오류가 발생했을 수 있다. 그럼에도 불구하고 아직도 여전히 이런 구성의 프로젝트 관리도구를 시도한 예를 찾아보지 못했다. SI 프로젝트가 힘든 이유 중 하나는 불확실성 아니 좀더 가깝게 표현하면 불가시성이다. 누구나 현재 계획대로 프로젝트가 진행되는 지 바로 즉시성 있게 알고 싶어한다. 또는 일정대로 진행되지 않는다면 과연 그 원인은 어디서 기인하는지 객관적이고 정확한 정보를 그것도 단시간에 얻기 원한다. 이에 대해 많은 사람들이 노력하여 관리툴들을 쏟아내고 있지만 마땅한 것이 없다. 그나마 쓸만한 것은 가격이 비싸거나 개발자들에게 또다른 일거리를 안겨주는 부담이 있다. 한편으로 오픈소스를 이용해서 프로젝트의 전체 영역과 전주기를 자동으로 ..

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