'프로젝트'에 해당되는 글 2건

  1. 2008.07.07 프로젝트 이해 관계자의 권리와 책임 (2)
  2. 2007.02.27 개발 프로젝트는 누가 하는가

프로젝트 이해 관계자에게 주어진 권리

  1. 개발자는 비즈니스와 목표에 대해 배운다.
  2. 개발자는 자신들이 사용하는 언어로 배우고 말한다.
  3. 개발자는 요구 사항을 인식하고 이해한다.
  4. 프로젝트 이해 관계자와 함께 일하는 작업의 일환으로 개발자가 사용하는 창조물에 대해 설명한다. 창조물에는 생성을 위한 모델(예: 사용자 스토리, 핵심적인 UI 프로토타입)이나 표현 결과물(예: UML 배포 다이어그램) 등이 있다.
  5. 개발자를 존중하기를 기대한다.
  6. 요구사항을 위한 아이디어와 대안을 듣는다.
  7. 제품을 쉽게 사용하도록 특징을 기술한다.
  8. 재사용을 허용하고, 개발 시간을 단축하거나 개발 비용을 줄이도록 요구사항을 조정할 기회를 제공한다.
  9. 선의에서 나온 추정값을 제공한다.
  10. 기능과 품질 요구를 충족하는 시스템을 제공한다.

프로젝트 이해 관계자에게 주어진 책임

  1. 프로젝트 팀에게 자원(시간, 돈, ...)을 제공한다.
  2. 개발자에게 비즈니스에 대한 교육을 진행한다.
  3. 요구사항을 제공하고 명확하게 하기 위해 시간을 투자한다.
  4. 요구사항을 구체적이고 정확하게 만든다.
  5. 시의적절한 결정을 내린다.
  6. 비용과 가능성이라는 개발자 추정을 존중한다.
  7. 요구사항 우선 순위를 정한다.
  8. 개발자가 만들어낸 유효한 작업과 관련해 시의적절한 검토와 피드백을 제공한다.
  9. 요구사항 변경이 일어나면 바로 알려준다.
  10. 조직에 필요한 소프트웨어 프로세스를 직접 만든다. 프로세스를 따르는 동시에 필요할 때 수정하도록 적극적으로 도와준다.


출처 : IBM Developer Woks

Posted by spponge

댓글을 달아 주세요

  1. Favicon of http://youlsa.com BlogIcon youlsa 2008.09.01 01:26  댓글주소  수정/삭제  댓글쓰기

    참 당연한건데 실생활에서는 무시되는 경우가 너무 많은 것 같습니다. 조금씩 나아지고는 있습니다만... 우리나라의 소프트웨어 산업이 전체적으로 낙후된 데에는 이런 원인이 꽤 큰 역할을 하고 있는 것 같습니다.

  2. Favicon of https://portno80.tistory.com BlogIcon spponge 2008.09.06 08:59 신고  댓글주소  수정/삭제  댓글쓰기

    그렇죠... 실속 없이 비대해진 IT 산업 구조에서 원인과 결과가 꼬리를 물고 도는 형국이라 현실을 개선하기란 참 어렵습니다. 그렇거나 말거나 노력은 개속 되어야죠. 그것이 우리의 희망이니까요. :D

사용자 삽입 이미지

"대한민국의 SI 업계에선"

프로젝트가 Man/Month 계산으로 시작해서 마지막까지 Man/Month 계산으로 끝난다.
이상한 일이지만 프로젝트가 심도있게 진행될 수록 그 중심에 있어야할 설계와 구현, 테스트는 어디로 갔는지 찾을 길이 없고 오직 Man/Month 줄이기와 뚜껑덮기만이 중심에 우뚝 설 뿐이다.

사실 프로젝트의 규모와 기간, 예산 등은 영업 단계에서 기술에 무지한(최소한 바삭하지는 않은) 영업맨의 손에서 문서로 탄생하고 그것은 곧 투입될 개발자들에게 다가올 기나긴 고난의 나날들을 예고한다. 이쯤에서 고객은 문서대로 구현될 소프트웨어를 기대하며 입가에 미소를 가득 머금는다.
 허울좋은 기획과 요구사항 정리를 거쳐 껍떼기 뿐인 설계과정을 거치고 나면 개발자들은 숱한 밤을 지새워 가며 그 허울좋은 껍데기에 걸맞는 소프트웨어를 구현하기 위해 코딩과 수정을 반복하고... 또 반복하게 된다. 업무 코디네이터는 나름 구상했던 결과물이 나오지 않는다며 아우성을 칠테고 요구사항을 변경해야겠다며 회의에 또 회의를...

이쯤되면 개발사에서는 남아봐야 본전이라며 혼신의 힘을 다하여 Man/Month 줄이기에 착수하고 본래의 목적이었던 "사용자가 만족하는 소프트웨어 시스템" 개발하기는 이미 제 운을 다하고 어디 하수구 구멍에나 쳐박혀있게된다. 이제 남은 것은 고객과의 협상을 통해 최대한 재빨리 뚜껑을 덮는 일.

다시말해 프로젝트가 산으로 가는 형상이다.
아주 나쁜 상황을 예로 들긴했지만 많은 수의 프로젝트들이 대개 이러한 상황에 봉착하고 있다고 아니 말할 수 있겠는가...

  • 영업맨의 기술적 마인드와 깊이있는 이해 부족
  • 설계자와 프로젝트 관리자의 경험, 설계능력, 요구사항 도출/분석 능력 부족
  • 개발자의 근본적 개발 마인드 부족
  • 고객(업무 코디네이터)과 개발자 간의 커뮤니케이션 능력 부족, 방법적인 문제

이중에 중요한 것을 꼽으라면 "요구사항 도출/분석, 설계"와 개발자-업무코디네이터 간의 유기적인 커뮤니케이션 체제를 들겠다. 분석/설계와 같은 일은 개발자가 스스로 노력하여 기술적 완성도를 높여 가면 되는 일이니 그것은 일단 제껴두고...

사람과 사람이 대화와 이해, 희생정신을 바탕으로 할 때 개발팀은 그 기능을 충분히 다할 수 있고 고객과의 협업도 또한 이루어질 수 있는 것이다. 그러한 마인드가 되어 있지 않고서 서로의 목소리만을 높인다거나 마음의 문을 굳게 닫고 있는다면 그 프로젝트는 얼음성이 녹아내리듯 서서히 녹아내려 마침내는 그 형체조차 희미하게 되고 말 것이다.

Posted by spponge

댓글을 달아 주세요