watist's blog ... I am interested and passionate in building software.

개발팀을 구성할 때 다음과 같이 하면 어떨까하는 생각이 듭니다. 하나의 제품 안에 2개의 팀을 구성하고, 설계 - 구현 - 검수 - 휴식을 번갈아 가면서 진행하는 것이죠. 검수와 설계 단계에선 두 팀의 상호작용을 최대한으로 해서 앞 버전의 검수와 뒤 버전의 설계를 같이 진행하고, 구현 자체는 각 팀에서 책임지고 진행하는 것이죠. 스텝별로 역할을 구성하면 다음과 같이 됩니다. PM은 쉴때가 없군요ㅡㅡ;; 생각해 보니 각 버전의 구현 단계에서 PM은 좀 쉬어도 될 것 같습니다^^;; 표 에서 숭~~ 숭~~ 비는 부분이 많아서 일 안 하고 뭐하나 하는 의문이 생길 수도 있지만, 이런 팀 구성의 의도는 잦은 릴리즈와 각 버전별 책임 강화 그리고 휴식을 통한 재충전입니다. 휴식은 정말 휴가가 되거나, 전체 기간 ..

SI 프로젝트를 진행하게되면 빈번하게 왔다갔다 하는 것이 견적서입니다. 네고 할 것으로 예상하고 견적 금액을 작성하고, 응당 그럴줄 알았다는 듯이 10%에서 20%를 네고합니다. 구매 담당자의 평가 항목으로 네고율이 있나 싶을 정도로, 몇 퍼센트를 한다는 사내 룰이 있기도 하죠. 이렇게 프로젝트의 비용 10%를 네고하면 프로젝트의 리스크는 몇 퍼센트가 올라갈까요? 저가 수주를 프로젝트 실패의 첫 단추라고 합니다. 저가로 수주하니, 저급 인력이 들어가고, 저급 인력이 들어가니 일이 제대로 안 되는 것이죠. 물론 저가로 수주 하지 않으면 되겠지만, 영세업체들이 입장에선 당장 벌기에 급급해 자신은 물론, 전체 시장의 코앞을 보지 못 하는 사태가 벌이집니다. 아마도 10%의 네고가 몇 퍼센트의 리스크를 발생시키..

SI 프로젝트는 다양한 조직의 다양한 사람들이 함께 일한다는 점에서 웹포털 개발과는 다른 점이 있습니다. 여러 조직간의 이해가 충돌해 갈등이 발생할 여지가 높죠. 그래서 역할을 분명히 하고, 역할 책임자를 확실히 하는 것이 중요합니다. ** SI 프로젝트 역할도 프로젝트의 중심을 잡는 PM의 역할이 중요하고, PM은 의사결정권자에게 보고하고, 프로젝트의 여러 중요한 이슈에 대한 결정을 내립니다. 현업과의 원활한 의사소통을 통해 프로젝트가 현업의 요구사항을 충실히 반영하게 해야 하고요. PMO로 부터 여러 지원 사항을 받습니다. PM 은 업무설계, 개발설계, 개발의 3개 하부 조직을 운영합니다. 각 조직엔 해당 업무를 잘 아는 PL이 있어야 하고요. 각 PL이 실제 작업자들을 책임집니다. 이렇게 프로젝트를..