'프로젝트관리론/프로젝트수행' 카테고리의 글 목록

'프로젝트관리론/프로젝트수행'에 해당되는 글 9건

2011.12.22 제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~ (1)
2008.09.15 프로젝트의 성공 요인 분석 #2
2008.09.15 프로젝트의 성공 요인 분석 #1
2008.08.28 프로젝트에 이름을 지어주자~
2008.02.27 애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)
2007.10.18 자주 리펙토링을 하라.(3)
2007.10.16 자주 리펙토링을 하라.(2) (1)
2007.10.13 자주 리펙토링을 하라.(1)
2007.08.19 테스트 코드.. 우선 개발할 것인가?

제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~

| 프로젝트관리론/프로젝트수행 2011.12.22 08:04

Posted by 미니~

모바일 시장이 발전하면서 개인도 모바일 App을 만들어서 돈을 벌 수 있게 되었습니다.
그러나 제대로 된 서비스를 만들려면 어떠한 역할들이 필요할 지 한번 정리해 봤습니다.

1. 기획 (Planning)

- 새로운 서비스/시스템을 기획
- 일반적인 아이디어를 보다 실현 가능하도록 구체화 함
- 서비스 기획안, 화면 구성 방안 및 사용자 매뉴얼 등을 작성

독서량이 많아야 한다. (다양한 분야의 도서를 읽어야 함)

기존의 서비스를 많이 사용해 봐야 한다.

기획하려는 분야의 전문가가 되어야 한다.

좋은 아이디어를 선별할 수 있는 판단력이 있어야 한다.

기획하는 서비스에 대한 시장 조사 능력이 있어야 한다.

2. 디자인 (Design)

- 디자인은 단순히 그림을 그리는 것이 아님

- 디자인은 해당 서비스의 이미지를 구축함으로써 성공 여부를 결정함

- UI/UX에 대한 디자인을 수행 (사용자 경험 중시)

Best Practice와 같은 좋은 디자인을 많이 봐야 한다.

개발자가 아닌 사용자를 고려하여 서비스를 디자인 해야 한다.

다양한 입력 방식과 같은 새로운 사용자의 경험을 반영해야 한다.

매번 새로운 디자인 스타일을 구축해야 한다.

웹과 모바일은 디자인에 있어 화면의 크기를 고려해야 한다.

3. 설계 (Architecture)

- IT 서비스를 위해서 개발보다 중요한 것이 설계임 (잘못된 설계는 추후 엄청난 손실을 가져옴)

- 보통 설계자는 개발자보다 많은 경험을 가지고 있음

- DB 설계, Framework 설계, 기능 설계 등을 수행함

플랫폼(DB, 프로그래밍 언어, 시스템)에 대한 상세한 분석이 필요하다.

새로운 기술의 등장과 함께 누구보다 먼저 연구해야 한다.

서비스의 효율을 결정하는 분야이므로 성능 개선에 항상 관심을 가져야 한다.

DB / OS / 네트워크 / 프레임워크 등 각 분야별로 전문가가 되어야 한다.

4. 개발 (Development)

- 실제로 서비스나 시스템을 위한 프로그램을 개발하는 분야임

- 프로그래밍 환경은 끊임없이 변화하고 있으므로 빠른 대응이 필요함

- 서비스 가능한 프로그램을 개발함

프로그램 개발을 위한 기술을 습득해야 한다.

개발 관련 기술은 끊임없이 변하므로 꾸준히 학습해야 한다.

기존의 API를 최대한 활용하여 개발의 생산성을 높여야 한다.
과거 수행한 개발 내역을 자산화 하여 유사한 프로그래밍에 재사용 해야 한다.

5. 테스트 (Test)

- 현대의 IT 환경에서 테스트의 중요성이 점차 강화되고 있는 분야임

- 테스트는 정상적인 상황 뿐만 아니라 비정상적 환경에서도 수행해야 함

- Black Box 테스트, 경계 테스트, 예외 처리 테스트 등을 수행함

테스터는 상당한 끈기와 노력을 요구하는 분야이다.

테스트의 중요성에 비해 다른 분야보다 대우를 받지 못하기도 한다.

테스트 시나리오를 작성하고 이에 따라 철저하게 테스트를 수행해야 한다.

테스트에서 찾지 못한 오류를 서비스 개시 후 발생하게 되면 손실이 크다.

6. 운영 (Operating)

- 서비스의 지속적인 발전을 위해서 운영 업무를 수행해야 함.

- IT 분야에서 운영은 하드웨어와 같은 시스템 모니터링 및 장애 대응과 같은 것을 포함함.

- VOC 운영, 시스템 운영, 유지 보수 운영 등의 업무를 수행함

하드웨어 시스템에 대한 많은 지식을 가지고 있어야 한다.

시스템 모니터링, 장애 대응, 네트워크 모니터링을 위한 기술들을 습득해야 한다.

개발을 지원하기 위한 서버 구성 등도 수행해야 한다.

고객 대응의 경우, IT 분야는 아니지만 서비스 운영에서는 필요하다.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~ (1)	2011.12.22
프로젝트의 성공 요인 분석 #2 (0)	2008.09.15
프로젝트의 성공 요인 분석 #1 (0)	2008.09.15
프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18

app, 개발, 기획, 디자인, 모바일, 설계, 운영, 테스트

Trackback 0 And Comment 1

프로젝트의 성공 요인 분석 #2

| 프로젝트관리론/프로젝트수행 2008.09.15 22:58

Posted by 미니~

지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다.
이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다.

다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다.

5. 사소해 보이는 문제도 '이슈화' 하자

프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다.

이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다.

이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행 모니터링 -> 이슈 종결 내용 공지

이슈가 문제가 되면 리스크(위험)이 됩니다.
그럼에도 불구하고 이슈가 발생할 것 같으면 쉬쉬하고 내부적으로 해결해 보려는 노력을 많이 합니다.
프로젝트에서는 이슈가 언제든지 발생할 수 있습니다. 이런 문제를 내부에서만 조용히 해결하려다 더 큰 문제가 많이 발생할 수 있습니다.
사소한 이슈라도 제대로 파악하고 챙기는 프로젝트 관리자가 되어 보시기 바랍니다.

이슈화 전체보기..

프로젝트를 추진하다 보면 예상치 못한 문제에 부딪쳐 진행이 순조롭지 않은 경우가 있다. 이럴 경우 담당자는 문제 발생 초기에 나타나는 현상을 사소하게 보거나 대수롭지 않게 생각하기 쉽다. 그래서 이를 공개적으로 문제화하지 않고 담당자 혼자 또는 관련자 몇 사람이 모여서 토의하는 수준에서 자체적으로 해결하려고 한다. 이런 과정을 통해 문제가 완전히 해결되면 다행이지만, 그렇지 않고 대증적 처방에 머물러 문제를 잠복시키게 되면 프로젝트 전체 일정에 지장을 초래하게 된다.

프로젝트팀은 프로젝트 초기에 예측 가능한 범위 내에서 최대한 정교한 프로젝트 계획을 세우게 된다. 하지만 시간에 따라 변하는 현실 상황을 감안하기에는 어려움이 따른다. 그 때문에 프로젝트를 진행하면서 계획을 수정하거나 보완하게 되는 경우가 발생하게 된다.

이렇게 프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때, 이런 경우를 '이슈의 발생'으로 정의하자. 먼저 이슈가 생겼을 때 어떻게 처리할 지에 대한 절차를 세워야 한다. 절차를 세우면서 제일 먼저 '어떤 것을 이슈라고 할 것인가'라는 이슈 관리 기준을 정해야 한다. 이런 절차 및 기준은 회사별로 다를 수 있으며, 또 프로젝트 규모 등 성격에 따라 달라질 수 있다.

예를 들면 어떤 사안이라도 일정에 차질을 초래하면 이슈로 인식하는 것이다. 이슈로 인식하는 일정 차질의 일수를 며칠로 할 것인가라는 기준은 프로젝트 기간에 따라 정할 수 있다. 6개월 이상 되는 프로젝트의 경우 전체 일정의 1～2%에 해당하는 일수를 일정 차질 기준 일수로 정하는 것도 한 방법이다. 이런 일이 생기면 미리 수립돼 있는 이슈 관리 프로세스를 따르게 해야 한다. 그 절차는 6단계로 나뉘어 있다.

첫째, 이슈 발생의 인지다. 정해진 기준에 따른 일정 지연의 사안이 발생하면 프로젝트 관리 조직에서는 이슈를 인지하게 된다. 이슈의 인지는 프로젝트 관리의 자동화 및 정교화 정도에 따라 프로젝트 관리 조직이 자동으로 인지할 수 있거나 해당 프로젝트 팀원 및 관련자가 신고하도록 해야 한다.

둘째, 인지된 이슈의 분류다. 사전에 이슈 관리 등급을 정해야 한다. 예를 들면 파급되는 영향의 규모, 프로젝트 내부 해결 가능 여부, 추가 투입 자원 규모 등을 분류해야 한다. 분류된 이슈는 중요도에 따라 우선 순위를 부여해 관리하도록 한다.

셋째, 이렇게 이슈에 관한 분류 작업이 이뤄지고 나면 이에 따른 대응 방안을 세워야 한다. 우선 자체적으로 해결될 수 있는 이슈라면 자체 대응 방안을 세우도록 해야 한다. 물론 이럴 때 추가 자원이 필요하다면 이에 따른 자원 투입 의사결정을 정해진 기준에 따라 받아야 한다. 프로젝트 관리 조직이 해결할 수 있는 범위 내에서는 즉각 승인하고 범위를 벗어나면 의사결정권자의 승인을 신속하게 받도록 해야 한다.
하지만 프로젝트 내부가 아니라 외부와 관련된 이슈인 경우에는 프로젝트 관리 조직에서 관련자들과의 협의 과정을 거쳐 대응 방안을 수립해야 한다. 예를 들어 비즈니스 부분에서 당초에 예상돼 있지 않은 추가 요건이 발생한다든지, 비즈니스의 의사결정이 이뤄지지 않아 지연되는 문제에 대해서는 프로젝트 관리 조직에서 비즈니스를 관장하는 의사결정권자에게 신속히 이슈를 알려주고 이로 인해 일정이 지연되고 있음을 주지시키고, 아울러 CEO에게도 이런 사실을 같이 알리는 장치가 있어야 한다. 이렇게 필요한 의사결정이 적시에 이뤄지지 않아 일정에 차질이 빚어지는 경우가 많음에도, 이런 문제가 제대로 알려지지 않는 경우 또한 많다.

넷째, 대응 방안이 수립되고 이에 따른 영향도가 평가되고 나면 프로젝트 관리 조직에서는 프로젝트 팀원들이 정해진 일정에 따라 대응 절차를 진행하도록 해야 한다. 이렇게 이슈의 발생으로 인해 처리되는 일들은 계획에서 벗어나 있는 일로, 신속하게 처리해 원래 수립된 계획이 제대로 진행되도록 해야 한다.

다섯째, 프로젝트 관리 조직에서는 대응 방안에 따라 프로젝트 조직이 수행하고 있는지 모니터링해야 한다. 모니터링 작업을 통해 이슈가 해결되고 있는지를 해당 프로젝트 팀원은 물론, 관련 조직에게 공지해야 한다.

여섯째, 이슈가 종결됐을 때는 프로젝트 팀원은 물론, 관련 조직에게 이슈 종결 내용을 공지해야 한다. 또 이슈 처리 과정을 빠짐없이 기록해 향후 유사한 문제가 발생하지 않도록 참고 자료로 활용할 수 있게 해야 한다.

프로젝트를 진행하면서 '이슈의 발생'에 해당하는 문제가 전혀 발생하지 않기를 기대하는 것은 어렵다. 문제는 어떻게 하면 발생한 이슈를 조기에 발견해 발빠르게 처리하도록 할 수 있느냐는 것이다. 사소해 보이는 이상 징후를 놓치지 않고, 조기에 이슈화해 해결책을 찾음으로써 나중에 가래로도 막기 어려워질 것을 호미로 막을 수 있을 것이다.

6. 프로젝트의 조기 경보기 "리스크 관리"

리스크를 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성이라고 정의하고 있습니다.

프로젝트 특성상 발생할 수 있는 리스크에 대해서 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있으며, 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다고 합니다.

그래서 미리 막을 수 있는 대응책과 실제 발생했을 때 처리 방법이 있어야 한다고 이야기 합니다.
또한, 지표를 통해 리스크를 지속적으로 모니터링 할 수 있어야 함은 기본사항이구요..

앞에서 리스크/위험 관리에 대해서는 #1, #2로 정리한 내용이 있습니다.
리스크 완화, 회피, 모니터링, 관리에 대해서 이야기 했었습니다.
이런 위험 관리는 모든 프로젝트에서 중요한 요소라고 다시 한번 강조하고 싶네요..

리스크관리 전체보기..

현재 프로젝트가 계획대로 진행되고 있더라도 프로젝트 관리자는 프로젝트가 완료될 때까지 긴장을 늦추지 못한다. 프로젝트를 진행하다 보면 예상치 못한 상황이 벌어지고, 이에 따른 여러 가지 문제가 발생하게 된다. 이렇게 발생한 문제들은 이슈로 관리돼 대응책을 만들고 문제를 해결하게 된다.

하지만 프로젝트가 진행되면서 계속 변하는 프로젝트 내부와 외부 환경으로 인해 프로젝트 진행에 장애를 일으키는 문제가 발생할 가능성이 있다. 이렇게 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성을 '리스크'라고 정의해보자.

프로젝트를 진행하다 보면 여러 가지 리스크를 안게 마련이다. 예를 들어 업무 범위가 갑자기 외부 요인에 의해 대대적으로 변경될 수도 있고, 프로젝트를 진행하고 있는 인적 자원이 예기치 못한 사정으로 갑자기 교체돼 진행에 적잖은 차질을 초래할 수도 있다. 또 프로젝트 예산이 줄어들자 자원이 원활하게 수급되지 못해 프로젝트 규모를 축소해야 하는 일이 생길 수도 있다. 이렇게 프로젝트를 둘러싸고 있는 내/외부 환경의 변화는 프로젝트의 진행에 지대한 영향을 주게 마련이다.

물론 초기에 예상할 수 있는 리스크를 감안해 프로젝트를 기획하고 풍부한 자원을 갖고 프로젝트를 수행하고 있다면 예상치 못한 문제가 생기더라도 프로젝트 진행에 크게 지장을 주지 않을 수도 있다. 하지만 대부분 프로젝트는 주어진 일정이나 자원에 여유가 없거나 부족한 상황에서 진행하게 되며, 이렇게 여유가 없는 상황에서 예상치 못한 문제로 인해 프로젝트가 늦춰지면 이에 따른 책임과 손실을 감당하기가 매우 어렵다.

프로젝트를 진행하면서 그 프로젝트의 특성상 발생할 수 있는 리스크에 대해서는 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있다. 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다.

이런 체크 항목에 등재된 리스크에 대해서는 대응책을 마련해야 한다. 이 대응책에는 미리 막을 수 있는 대응책과 실제로 리스크가 발생했을 때를 구분하는 게 필요하다. 예방할 수 있는 리스크는 발생하기 전에 대응책에 따라 대비하는 것이 제일 좋다. 실제 리스크가 발생했을 때의 대응책은 실질적으로 조치가 가능한 수준의 방안이어야 한다. 이 대응책에는 자원의 조달에 관한 대책이 명시돼야 한다. 대부분 대응 방안에는 반드시 자원이 추가로 소요되게 마련이다. 이런 자원을 구체적으로 어떻게 조달할 것이지, 그리고 어떻게 의사결정을 지체하지 않고 받을 수 있는지에 대해 미리 합의해 두어야 한다.

프로젝트 관리팀은 리스크 체크 항목을 정기적으로 점검해 리스크를 끊임없이 모니터링해야 한다. 효과적인 모니터링 작업을 위해 리스크를 산술적으로 측정할 수 있는 지표를 만들어야 하고, 이 지표에 의해 리스크의 양을 구해야 한다. 이 때 예측이 가능한 리스크는 지표에 의해서 리스크량이 산출되지만, 예측이 어려운 리스크는 경험에 의한 추정치를 구해야 한다. 이것조차 어려우면 몇 번의 프로젝트를 진행하면서 경험치로 계산된 리스크량에서 산출된 일정 비율로 더하는 방법이 있다.

이렇게 각각의 리스크량을 산출해 더하면 프로젝트 리스크의 총량이 계산된다. 그리고 프로젝트 관리팀은 프로젝트 내/외부의 상황이 변해 리스크가 해결되거나, 자동으로 소멸되거나, 새로 발생하는 리스크 변화 부분을 리스크 측정지표에 의해 다시 산출해야 한다. 그래서 현재 시점에서 리스크 총량이 얼마인지 파악하고 어떻게 변화하고 있는지 알고 있어야 한다.

시간이 지나면서 리스크 총량이 감소하는 게 바람직하다. 프로젝트가 성공하려면 시간이 경과되고 완료 시기가 다가올수록 리스크의 총량은 줄어들어야 한다. 만약 리스크의 총량이 감소되지 않고 정체 상태이거나 오히려 늘어난다면 프로젝트의 성공을 바라기가 매우 어려울 것이다. 프로젝트의 리스크 총량을 줄이려면 프로젝트 팀원이나 관리자를 막론하고 끊임없이 리스크 관리에 관심을 두어야 한다. 정기적으로 프로젝트 내/외부에서 변하는 상황과 관리하고 있는 리스크를 비교, 분석해 이를 방지할 수 있도록 최선을 다해야 한다.

전쟁 중에 조기경보기는 하늘에서 적진의 움직임을 감시하면서 공습에 대비하고 아군의 승리를 위해 지원하듯이, 리스크 총량 관리는 프로젝트의 조기경보기 역할을 수행하면서 프로젝트의 성공에 일조할 수 있을 것이다

7. 인적 자원의 파악, 가볍게 여기면 큰 코 다친다.

의욕이 앞서 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 프로젝트가 제대로 진행되기 어렵습니다.
특히 인적자원은 사람의 수 뿐만 아니라 그 사람이 보유한 역량의 수준까지도 파악해야 한다고 합니다.

또한 아웃소싱에 의존하는 비율도 미리 정한 것을 초과하지 않도록 해야 하는데, 이유는 추후 유지보수나 관리에 문제가 발생할 소지가 있기 때문입니다. 프로젝트의 핵심 업무는 내부 인력으로 처리하는게 바람직하다고 하네요..

프로젝트 뿐만 아니라 모든 일은 결국 사람이 해결할 수 밖에 없다고 봅니다. 프로젝트에 있어서 갑자기 인력이 교체되거나 역량이 부족한 인력으로 수행하게 되면 댱연히 문제가 발생할 수밖에 없을 겁니다.
아웃소싱에 의존하는 업체도 아웃소싱 인력의 능력에 따라 프로젝트의 성패를 맡겨야 하니 불안할 수밖에 없을 거구요..

인적자원 전체보기..

손자병법에 '지피지기면 백전백승'이라는 말이 있다. 전쟁을 할 때 적군의 전력이나 상황을 정확히 알면 그에 따른 대책을 세워서 이길 수 있다는 얘기다. 이때 전제되는 것은 아군의 전력이나 상황을 정확히 아는 것이다. 아군의 전력이나 주어진 내/외부 상황을 파악하지 못한 상태에서 대책을 수립한다면 소용없는 일이다.
프로젝트에 착수하기 전에 기업의 자원을 정확히 파악해야 한다. 의욕이 앞서 기업이 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 제대로 프로젝트가 진행되기 어렵다. 경우에 따라서는 프로젝트의 우선 순위나 중요도에 관계없이 자원 조달과 관련한 프로젝트 책임자의 역량이나 외부 환경에 의해 프로젝트의 성공과 실패가 결정되기도 한다.

먼저 프로젝트와 관련된 주요 자원에는 인적 및 재무 자원 등이 있다. 인적 자원은 단순히 사람 수만이 아닌 어떤 역량을 가진 사람이 있는지 파악해야 한다. 또 그 사람이 보유한 역량의 수준까지 파악해야 한다. SI 프로젝트를 아웃소싱할 때 과학기술처에서 기술 숙달 정도에 따라 고급/중급/초급으로 분류해 역량의 차이에 따라 임금 체계를 나누고 있다. 재무 자원은 프로젝트 수행에 필요한 예산 외에 리스크를 감안한 여유 분이 확보돼야 한다. 흔히 예비비라는 비목으로 별도 책정하기도 한다.

기업에서는 일반적으로 차기 연도 사업 계획과 소요 예산을 4～5개월 전부터 세우기 시작한다. 2～3개월 정도의 기간을 두고 조정 작업을 거쳐 이사회에 보고 및 승인 절차를 거쳐 확정한다. 대부분 사업 계획에는 다수의 프로젝트가 포함돼 있으며, 각각의 프로젝트를 결정할 때 소요되는 재무 자원인 투자 금액과 투자 효과에는 관심을 기울이지만, 프로젝트를 수행하게 될 인적 자원 조달 계획의 타당성 등에는 상대적으로 관심도가 낮은 경향이 있다.

인적 자원을 계산하는 방법에는 주의해야 할 사항이 있다. 먼저 각 사업본부에서 일상적으로 일어나는 업무에 드는 인력의 총량을 계산해야 한다. 그리고 해당 본부에서 추진하는 프로젝트에 소요되는 인적 자원의 총량도 구해야 한다. 물론 프로젝트에 소요되는 인적 자원의 수준에 맞는 역량을 가진 인적 자원을 계산해야 한다. 그리고 다른 본부의 프로젝트에 소요되는 지원 인력에 관해서도 정확히 계산돼야 한다. 지금까지 많은 기업의 프로젝트에서 간과해온 지원 인력의 계산 부문은 잘 드러나진 않지만 프로젝트의 성공으로 가는 길에 상당히 중요한 요소로 작용하고 있다.

이렇게 계산하다 보면 대체적으로 모든 사업이나 프로젝트에 소요되는 인적 자원의 총량은 가용 인적 자원보다 초과되게 마련이다. 이런 경우 부족 인력을 아웃소싱해야 하는 경우가 발생하는데, 이럴 경우 아웃소싱 인력은 사전에 설정한 적정 비율을 넘지 않도록 주의해야 한다. 부족하다고 아웃소싱 인력에만 의존할 경우 프로젝트가 종료된 뒤 프로젝트에 종사했던 아웃소싱 인력이 빠져나가 유지보수 업무에 많은 차질을 초래하는 경우가 종종 발생하고 있기 때문이다. 되도록 프로젝트의 핵심 업무에는 유지보수가 가능한 자체 인력을 투입하는 게 바람직하다.

이렇게 계획된 모든 프로젝트와 일상 업무에 소요되는 인적 자원이 기업이 보유한 인적 자원의 총량을 넘지 않도록 주의해야 한다, 만약 소요되는 자원이 소유하고 있는 인적 자원과 일정 비율의 아웃소싱 자원의 합을 초과한다면 인적 자원을 제대로 지원 받지 못할 것으로 예상되며, 전략적으로 우선 순위를 조정해 프로젝트의 부실화를 예방해야 한다.

의욕이 앞서는 것은 좋으나 이렇게 인적 자원이 제대로 파악되지 않아 적절한 인적 자원을 지원받지 못해 프로젝트가 실패한다면 너무나 어리석은 짓이다. 하지만 많은 기업에서 이렇게 인적 자원이 부족할 것을 알면서도 강행하는 경우에는 프로젝트를 진행하는 책임자들은 프로젝트의 본업보다 프로젝트에 필요한 인적 자원을 확보하려고 노력하고 이에 많은 시간을 소비하게 된다. 많은 경우 사람 때문에 다투거나 제대로 지원을 받지 못해 어려움에 처하는 경우를 보게 된다. 특히 인적 자원이 필요한 시기에 못 받거나 적절하지 못한 사람을 받아 프로젝트를 진행하는 과정에서 어려움에 봉착하는 경우를 많이 보게 된다.

이제까지 소홀히 했던 인적 자원에 대해 프로젝트의 수립 단계부터 정확히 계산해야 한다. 역량에 맞는 인적 자원을 제대로 확보할 수 없다면 처음부터 프로젝트를 시작하지 말아야 한다. 전략적으로 중요한 프로젝트라면 다른 프로젝트를 중단하거나 연기해서라도 충분한 지원이 가능할 때 시작해야 한다. 기업에서 일어나는 사업이나 일들에 사람이 중요하지 않은 일이 없지만 프로젝트야말로 사람이 성공의 핵심 요소임을 인식하고 이에 대한 준비를 철저히 해서, 시작한 프로젝트는 성공으로 이끌어야 한다.

8. 현실과 지표 사이의 괴리를 메우자

프로젝트를 진행하면서 나오는 몇 % 진행되었다는 숫자에 대한 문제점을 지적하고 있습니다.
산출물 기준으로 진척도를 계산하게 되면 외형은 확인할 수 있지만, 품질은 확인이 곤란하다는 겁니다.
그리고 개발자의 감으로 진척도를 이야기 하면 테스트에 대한 부분이 포함되어 있지 않으며 객관적이지 않은 진행 상황일 수밖에 없다고 합니다.

그래서 전체 진척도와 단계별 진척도를 별도로 관리하고 테스트와 검토 단계의 비중을 높여서 계산해야 한다고 합니다.

어디서 보니까 어른들은 숫자를 참 좋아한다고 합니다. 모든 데이터를 정량화 하는 것은 프로젝트 관리에서도 중요한 작업임에 틀림없습니다.
그러나 그 정량화에는 반드시 현실이 제대로 반영되어 있어야 합니다. 그러기 위해서는 기준이 중요하고, 프로젝트에서도 개발 속도 뿐만 아니라 품질까지도 포함해야 한다는 것이죠..

현실과지표 전체보기..

프로젝트를 진행하게 되면 늘 보는 숫자가 있다. 오늘 현재 공정상 계획은 70%인데 달성은 77%라고 하는 숫자다. 과연 이 숫자는 어떤 의미를 가질까. 대부분 이 숫자를 보면서 계획 대비 7% 초과이므로 계획보다 잘 돼 간다고 생각한다. 과연 숫자만큼 내용도 잘 돼서 믿을 만한 것일까. 도대체 이 숫자는 어떻게 산출됐으며 무엇을 시사하고 있을까.

일반적으로 프로젝트 공정 계획을 세울 때 설계/구현/테스트 등으로 단계를 세분화하게 되고, 단계별로 투입될 인적 자원의 양을 계산하게 된다. 예를 들어 프로젝트 전체 중 설계 단계에 30%, 구현 단계에 40%, 테스트 단계 30%의 인적 자원이 소요된다고 예상하면 전체 투입될 인적 자원을 단계별 투입 비율로 계산해 공정지표로서 활용한다. 물론 각 단계에서는 다시 세부 단계를 나누어 정교하게 공정지표들이 산출된다.

이런 계획에 따라 단계별로 인원이 투입되고, 계획된 일정대로 이상이 없으면 비율만큼 진행된 것으로 계산해 지표로서 활용한다. 하지만 여기에 맹점이 있다. 외형상 진행됐는데 실제 내용은 미진할 수 있기 때문이다. 이런 현상을 방지하고자 단계별로 정해진 산출물을 확인하게 돼 있다. 문제는 이 산출물의 외형은 확인할 수 있는데 품질은 확인하기가 대단히 곤란하다. 뿐만 아니라 그 내용물의 품질을 정확하게 확인하려면 작업하는 사람보다 내용을 더 잘 아는 전문가를 투입해야 하는데, 그런 인력을 투입하기엔 현실상 힘들다. 또 품질 확인을 위해 추가 인력을 투입하는 것 자체도 자원의 증가를 의미하므로 어렵다.

이런 어려움으로 인해 단계별 진척도가 정확한지 따지는 건 쉽지 않은 일이다. 이러다 보니 대부분 개발자 자신들의 신고에 의한 진척도를 활용할 수밖에 없다. 이 상황에서 정확한 진척도를 가늠하기란 어려울 수밖에 없다. 프로젝트 책임자는 모든 부문의 진척도를 세세히 알기 어렵다. 언뜻 보면 목표 진척도대로 진행돼 가는 것으로 알고 있지만 어디까지 진실을 반영하고 있는지 불안할 수밖에 없다.

이런 일이 발생하는 것은 SI 프로젝트가 여러 세부 프로세스로 나뉘어 있고, 개별 프로세스도 많은 프로그램으로 이루어져 있기 때문이다. 대부분 개발자들은 자신이 맡고 있는 응용 프로그램을 작성하는 것인데, 프로그램은 작성자의 의도에 따라 같은 언어를 사용하더라도 구현 방법이 다양하기 때문이다. 작성하면서 프로그램의 논리적인 착오는 찾아내지만 실제 고객이 사용할 수 있는지 여부는 개별 테스트를 거쳐 프로젝트의 거의 끝 단계에서 전체 테스트를 실시하면서 발견하는 경우가 많다. 그래서 전체 테스트를 수행하기 전에는 프로그램의 착오를 찾아내는 게 매우 힘들다.

이런 전체 연결 테스트를 수행하면서 착오도 발견하고 또 논리적 모순을 집어내기도 한다. 이런 테스트에 생각보다 많은 시간이 걸린다. 경우에 따라서는 다시 프로그램을 작성해야 한다. 이러면 지금까지 예상 진척도대로 진행됐다는 것이 의미가 있는 것일까, 반문하게 된다.

이런 이유로 우리가 흔히 관리하고 있던 진척도는 상당히 의미를 상실한다. 실제 상황을 표시하기엔 문제가 많다. 방법이 없을까. 그러면 전체 테스트가 완료되기 전에는 진척도 자체가 의미가 없는 것일까. 진척도 자체는 전체 자원의 투입을 의미한다. 하지만 내용과 품질 면에서는 의문이 남는다. 그리고 정확히 알려면 일 그 자체보다 더 많은 자원이 필요할 수도 있다. 딜레마가 아닐 수 없다.

여기서 대안으로 진척도를 산출할 때, 전체 진척도와 별도로 단계별 진척도를 관리하는 것이다. 예를 들어 설계 단계에서는 설계도를 작성할 때까지 진척도를 표시한다. 그리고 설계도 작성이 끝날 때 설계도 검토 과정을 넣어 설계도 검토 후 통과 판정을 받았을 때 비로소 설계 단계의 완성으로 보는 것이다. 프로그램의 작성 단계 또한 프로그램의 작성 단계의 비중은 낮추어야 한다. 오히려 테스트와 검토 단계의 비중을 높여야 한다. 예를 들어 프로그램의 완성도 측면에서 보면 작성자의 비중은 50%, 개별 테스트 10%, 전체 테스트 20%, 그리고 수정 절차에 20%를 배정하는 것이다. 이런 과정을 거쳐서 전체 완성도가 이룩됐을 때 완료된 것으로 해야 한다.

전체 관점에서 일괄적으로 진척도를 산술로 표시하는 것은 실제 상황을 왜곡하는 경우를 많이 낳는다. 이런 왜곡을 방지하려면 전체 진척도는 참고 자료 정도로만 사용하면 될 것이다. 대신 각 단계별로 진행 정도를 지금 산정 방식보다 절반 정도로 비율을 낮추고, 전체 테스트가 완료됐을 때 비로소 완료되는 것으로 간주하는 게 그나마 왜곡을 상당히 막을 수 있을 것이다.

여기에 더해 전체 테스트에는 이 프로젝트가 마무리됐을 때의 사용자가 반드시 참여해야 한다. 실제 상황에서 가동돼야 하고 실제 사용자가 사용하기에 문제가 없어야 한다. 지금까지 프로젝트 진행에서는 주어진 설계도대로 작성하는 데 주력했다면 이젠 그 범위를 넓혀 제품의 최종 사용자가 참여해 품질과 내용에 대해 처음부터 참여하고 같이 검토해야 한다. 그래야만 완성도를 높일 수 있기 때문이다. 모든 산업에서 최종 사용자인 고객의 참여가 필수인 시대에 SI 업계에서도 프로그램을 작성하는 전문가들의 분야에서 고객까지 범위를 넓혀야 한다. 이럴 때 고객이 만족할 수 있으며, 고객이 인정하는 지표로서 가치가 있게 되는 것이다.

프로젝트를 진행할 때 현실과 지표 사이의 괴리를 메우는 방법은 멀리 있지 않고 고객 관점에서 진척도를 배정하고 점검하는 것이다. 이렇게 고객이 사용하기에 품질과 편리성에 문제가 없어야만 프로젝트가 끝날 수 있다는 사실을 명심해야 한다.

이상으로 프로젝트의 성공 요인에 대해 정리해봤습니다. 일반적으로 생각하는 부분과 큰 차이가 없어서 정리해봤습니다.

여러분은 어떻게 생각하는지요? 이 외에도 중요한 요소가 있다면 댓글 부탁드립니다.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~ (1)	2011.12.22
프로젝트의 성공 요인 분석 #2 (0)	2008.09.15
프로젝트의 성공 요인 분석 #1 (0)	2008.09.15
프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18

관리, 리스크, 성공, 인적자원확보, 지표, 프로젝트, 프로젝트관리

Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #1

| 프로젝트관리론/프로젝트수행 2008.09.15 19:19

Posted by 미니~

2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다.
4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다.

1. 업무 변경 관리로 프로젝트 성공률을 높이자.

첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다.

방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요
변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요.
단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미리 일정을 반영해서 변경관리를 해야 한다고 합니다.
마지막에 일시에 수행하는 것은 프로젝트가 긴 경우, 업무 변경의 양도 많고 시간도 오래 걸리므로 주의해야 한다고 하네요..

어쨌든 추가 비용이 들더라도 업무 변경 관리는 어떤 형식으로든지 해야 합니다.
보통 프로젝트 수행시에 보면, 마지막에 설계 문서를 한꺼번에 다시 고치는 경우가 가장 많은 것 같습니다.
즉, 프로젝트가 끝난 후에 개발 결과물에 맞추어서 설계문서를 다시 만드는 것인데요..
실질적인 변경관리라고 볼 수는 없다고 봅니다.

정말 성공하는 프로젝트를 만들고 싶다면, 설계를 변경하는 것에 대한 위험성을 고객이나 프로젝트 수행자 모두 인식하고 초기 설계부터 신중을 기해야 할 것입니다.

업무변경관리 전체보기...

기업은 오늘도 경쟁력 및 생산성 향상을 위해 크고 작은 여러 프로젝트를 진행하고 있다. 이 프로젝트 가운데 성공하는 프로젝트도 있고 실패하는 프로젝트도 있게 마련이다. 성공하는 프로젝트에는 성공하는 요인들이 있고 실패하는 프로젝트에는 그럴만한 요인이 있다. 요인 그 자체보다는 요인들을 어떻게 관리하느냐에 따라 프로젝트의 성패가 갈리는 경우도 많다. 이런 요인 가운데 "업무 변경을 어떻게 관리하느냐"는 성패에 상당한 영향을 미친다.

일반적으로 프로젝트의 최초 설계 시 프로젝트에서 성취해야 할 업무 범위를 설정한다.
이 범위를 바꾸는 것을 범위변경이라고 정의한다. 범위가 정해지고 나면 구체적인 업무를 정의한다. 이 정의된 업무가 여러 가지 내/외부 환경의 변화로 인해 변경되면 업무를 바꿔야 한다. 예를 들면 신상품 프로젝트일 경우 경쟁사에서 프로젝트 진행 중에 유사한 신제품을 먼저 출시했을 경우 여러 영향을 고려해 프로젝트를 취소할지 최초에 설계한 개념을 변경할지 신중히 결정해야 한다.

IT 프로젝트일 경우 대상 비즈니스는 현업에서 끊임없이 업무 변화를 수반하고 있다. 이렇게 현업에서 변하는 업무를 어느 시점에서 어떻게 반영할 것인지는 대단히 중요한 과제다. 새로운 공장을 건설하는 프로젝트의 경우 주변 환경에 관한 예상하지 못한 변수들이 발생해 프로젝트 진행을 어렵게 할 경우가 있다. 이럴 때도 미처 예상하지 못한 변수들을 어떻게 반영할 것인지는 전체 일정과 자원에 영향을 미치게 마련이다. 대부분 프로젝트에서 처음 작성한 설계도가 바뀌고 있는 실정이며, 이에 대한 대비가 철저할수록 프로젝트의 성공 가능성은 높다. 그리고 프로젝트가 구현되고 실제 사용자가 사용할 때를 대비해 사용자에게 변경된 업무를 미리 알려주고 사용법을 학습하는 행동들을 변화관리라고 정의한다.

프로젝트의 설계 시 설계도가 확정돼 프로젝트 기간 동안 업무 변경이 없다면 변경에 대해 고민할 필요가 없을 것이다. 하지만 대부분 프로젝트는 어느 시점에서 설계도를 그려 프로젝트를 시작하지만 실제 비즈니스 업무는 프로젝트와 상관없이 변경돼 진행되게 마련이다.

이렇게 변하는 업무를 따라잡기 위해 처음부터 신경을 곤두세우지 않으면 나중에 변화된 업무를 추적하기가 쉽지 않다. 이런 변화되는 업무를 추적하려면 '업무변경관리위원회'를 프로젝트 가동과 함께 처음부터 운영해야 한다. 이 위원회가 제대로 운영되려면 해당 업무 비즈니스 의사결정자, IT 관련 의사결정자, 프로젝트 의사결정자 등 실제로 해당 프로젝트와 관련이 되는 각 분야의 의사결정 책임자가 참여해야 한다. 업무가 바뀔 경우 현재 운영되고 있는 업무와 새로운 프로젝트 양쪽의 업무 영향도를 분석해 현행 업무에도 반영할 것인지, 그리고 새로운 프로젝트에도 어떻게 반영할 것인지 결정해야 한다.

이렇게 프로젝트 시작부터 업무 변경에 대비하지 않으면 현행 업무만이 바뀔 경우 프로젝트의 처음 설계도에 있던 업무가 서서히 변해 가는 것을 모르게 된다. 프로젝트의 적용 단계에서 그 차이를 발견하고 원인을 파악하느라 고생하기 마련이다. 그리고 잘못 파악하면 정확한 변경 사항을 모두 반영하지 못하고 에러를 일으키는 중요한 원인을 제공하게 된다. 업무가 바뀔 때마다 업무변경관리위원회를 거치는 게 복잡하고 시간이 걸릴 수도 있지만 결과적으로 전체 시간을 줄이고 에러를 막는 길이다.

일단 프로젝트가 시작되면 사용하는 내/외부 고객에게 프로젝트 진행 사실을 알리고 불필요하거나 사소한 업무 편의를 위한 업무 변경을 자제시킬 수 있는 제도 장치로 활용할 수 있다. 특히 업무변경관리위원회가 형식적이거나 각 분야의 실질적인 의사결정자가 참여하지 않는 형식적인 기구가 되면 업무 변경을 정밀히 추적할 수 없게 돼 프로젝트의 부실을 낳을 수 있다. 우리의 현실을 살펴보면 대부분 프로젝트 부실의 상당수 원인이 업무 변경에 관한 이런 대처를 소홀히 함으로써 생기는 경우를 종종 보게 된다.

프로젝트 출발 시 업무 범위를 확정했는데 프로젝트가 진행되면서 그림처럼 업무가 대부분 변경되게 마련이다. 단기 프로젝트일 경우 이 업무 변경 범위가 작아 큰 영향을 미치지 않지만 중장기 프로젝트일 경우 업무 범위가 최초의 설계 시와 상당히 차이가 난다. 이럴 경우 이런 업무 차이를 어떻게 반영할 것인지는 프로젝트 성패에 영향을 미치는 대단히 중요한 요인으로 작용한다.

업무 변경 차이를 막판에 일시에 반영하는 방법이 있을 수 있고, 프로젝트 기간 중에 몇 단계로 나눠 순차로 반영할 수도 있다. 또 업무가 바뀔 때마다 반영하는 방법이 있을 수 있다. 현실적으로 업무가 변경될 때마다 반영하는 방법은 너무 번거롭고 프로젝트 진행을 더디게 하는 부작용이 있어 채택하기가 쉽지 않다.

남은 두 가지 방법 중 단계별로 반영하는 방법은 단계마다 진행 중인 프로젝트를 잠시 쉬고 설계도를 고쳐서 진행되는 사항과 비교 분석해 업무 변경 요건을 반영해야 한다. 이 방법은 비교적 업무 변경을 주기적으로 반영할 수 있는 장점이 있으나, 일정을 잡을 때 이런 일정을 미리 반영해 두어야 한다. 그렇지 않으면 단계별로 진행 중인 업무를 멈추고 그때까지 변경된 업무를 반영함으로써 그 기간만큼 일정에 차질이 생기게 된다.

마지막으로 변경된 업무를 프로젝트 일정이 모두 마무리된 뒤 최초의 설계부터 그 때까지 변경된 내용을 모아서 반영하는 방법이 있다. 이 방법은 일시에 반영할 수 있는 장점은 있으나 프로젝트 기간이 긴 경우 변경된 업무의 양이 많으므로 설계도에 상당한 변화를 주어 이 시간 자체도 오래 걸린다. 각 방법마다 장단점은 있으나 프로젝트 일정이 짧은 경우와 업무의 변화 폭이 소량일 경우 마지막에 모아서 반영하는 방법이 적당할 것이다. 하지만 프로젝트 일정이 중장기일 경우에는 단계별로 반영하는 방법이 효과적일 수 있다. 업무의 특성과 프로젝트 진행 기간에 변화될 업무량을 추정해 반영 방법을 결정해야 한다.

업무 변경에 대비해 프로젝트의 계획 단계부터 업무변경관리위원회를 가동해 처음부터 변경되는 업무에 대해 철저히 반영하고, 변경 업무를 프로젝트에 어떻게 반영할 것인지 결정하고 진행한다면 프로젝트 성공에 기여하게 될 것이다. 아울러 지금까지 이런 변경 관리 업무를 사소한 추가 업무로 여기고 프로젝트 전체 일정에 넣지 않는 경향이 있었다. 하지만 이제 변경된 업무를 반영하는 것도 프로젝트의 품질을 높인다는 점을 인식하고 일정과 자원을 명확히 배분하고 관리함으로써 성공 가능성을 높일 수 있다.

2. 회의도 관리가 필요한 시대다.

회의로 인해 낭비되는 시간의 가치에 대해서 이야기 하고 있습니다.
회의를 줄이기 위해 단순한 정보 공유는 이메일이나 인트라넷 게시판을 활용하고, 화상회의 같은 것을 충분히 활용하자는 겁니다.

만약 회의를 진행한다면, 미리 회의 목적과 내용을 회의 참석자에게 알리고, 회의의 시작과 끝나는 시간을 정해서 준수하고, 회의 끝 부분에 안건과 결론을 정리하고, 결론이 난 부분을 해당 부서나 팀에 효과적으로 전달해야 한다고 하네요..

회의가 많은 기업은 그리 성공하지 못한다는 이야기를 들은 적이 있습니다.
물론 회의라는 것이 매우 중요한 것이지만 그만큼 잘못 사용하면 탁상공론에 실행이 뒷받침되지 않는 조직이 될 가능성도 높겠죠..

회의관리 전체보기..

오늘도 기업에서 수많은 회의가 새벽부터 밤늦게까지 진행되고 있다. 회의 참석자의 범위와 규모는 회의의 성격에 따라 결정된다. 예를 들어 경영협의회는 경영진을 비롯한 주요 간부가 참석하게 되고, 실무 회의에는 사안에 따라 직/간접으로 연관되는 실무자들이 참석하게 된다. 대부분 기업에서는 의사결정이 필요할 때 폭넓은 의견을 확보하고 수렴하기 위해 관련자들을 모아 회의체를 운영하게 된다.

그런데 회의체 운영 시 참석자들이 미리 검토했어야 할 회의 자료가 회의 직전에야 전달된다든지, 아예 회의 장소에서 배부되는 경우가 잦다. 또 회의 참석자 자신이 참석 이유도 모르고 앉아 있는 경우도 종종 있다. 이런 경우 대부분 주최하는 측의 의도대로 회의 결과가 도출되든지, 충분한 협의를 거치지 않은 상태에서 회의가 중단되거나 졸속 결론으로 회의가 끝나 바람직한 회의 성과를 기대할 수 없다.

직원 1인당 연간 비용(직접 인건비와 직간접 경비 포함)을 5천만 원으로 가정했을 때, 월 근무 시간인 176시간을 기준으로 나눠보면 대략 시간당 2만 4천 원이 쓰인다. 이런 직원 20명이 모여 2시간 회의를 했다면 96만 원이다. 100만 원 가까운 비용이 소비된다. 또 이 직원들이 회의를 하지 않고 영업을 하거나 자기 직무를 수행했을 경우에 발생하는 기회비용까지 계산한다면 훨씬 많은 비용이 회의를 위해 쓰여지고 있는 셈이 된다. 만약 이렇게 많은 비용과 시간이 소요된 회의가 별 성과 없이 진행됐다면 그만큼 회사의 자원을 낭비했다고 볼 수 있다.

이같은 소모적인 회의로 인한 낭비를 막기 위해 회의 참석자들에게 실제로 지급하지는 않지만 계정처리를 할 수 있는 회의비를 각 부서나 팀에 미리 배정해두는 방법이 있다.

예를 들어 A팀에서 연간 사용할 수 있는 이런 회의비로 1억 원을 배정해뒀다고 가정하자. 위의 예와 같이 20명의 인원이 참석하는 정기 회의를 한 주에 3번씩 진행하면 월 1200만 원, 연간 1억 4400만 원이 소요되므로 회의를 축소하든지 참석 인원을 줄여야 한다. 그리고 배정된 경비를 쓰지 않았을 때는 차액의 일정 부분을 인센티브로 전환해 해당 팀이 실제로 사용할 수 있는 경비로 배정해줄 수 있다. 물론 이에 따른 부작용도 있을 수 있지만 불필요한 회의를 억제할 수 있으며, 더 효율적인 회의 방안을 강구해 운영할 수 있다.

물론 이런 물리적인 억제책만으로 회의의 효율을 높일 순 없다. 먼저 기업에서 회의를 하는 목적 중 단순히 정보를 공유하거나 홍보할 목적이라면 굳이 바쁜 직원들을 모아 놓고 회의를 할 것이 아니라 전자게시판이나 e메일을 활용하도록 한다. 국제화?디지털 시대에 맞춰 동일 기업의 조직원들도 근무 장소와 근무 시간대가 각자 다르다. 이런 다양한 근무 형태 탓에 많은 직원이 같은 시간대에 한 장소에 모이기가 쉽지 않다. 요즘 같은 인터넷 시대에 꼭 무리하게 물리적인 공간을 고집할 것이 아니라 화상회의 시스템이나 콘퍼런스 콜 등 가상의 공간을 적극적으로 이용하도록 하면 조직의 능률을 높일 수 있다.

기업 중에 영업을 해야 하는 직원들이 많은 부서는 아예 모바일 오피스를 운용한다. 직원들은 고정된 책상이 없이 필요할 때 와서 비어 있는 책상에서 업무를 수행한다. 정보를 공유할 경우에는 인터넷이나 인트라넷을 통해 처리하고 업무 관련 연락과 지시 사항도 e메일을 통해 처리하는 경우가 많으며, 되도록 함께 모이는 시간은 최대한 줄이는 경우가 많다. 재택 근무를 하는 직종에서도 함께 모이는 회의는 억제되고 공유가 필요한 정보는 전자 수단을 통해 전달된다. 이와 같이 기업에서는 직원들이 많이 모이는 회의를 적극 억제하는 경우를 많이 볼 수 있다.

회의를 해야 한다면 미리 회의 목적과 내용을 회의 참석자에게 알려야 한다. 이때 참석자의 선정도 신중해야 한다. 회의 시 결론을 내야 하는 안건을 분명히 고지해야 한다. 되도록 회의의 시작과 끝나는 시간을 알려 정해진 시간을 준수하는 습관을 가져야 한다. 그리고 회의 끝 부분에 회의의 안건과 결론 부분에 대해 정리해야 한다. 결론이 난 부분은 해당 부서나 팀에 효과 있게 전달해 방안에 그치지 않고 실행될 수 있게 해야 한다. 실행 과정도 피드백할 수 있는 제도 장치를 마련해야 한다. 이렇게 회의의 시작부터 실행까지가 기획되고 투명하게 진행될 때 조직원들은 회의에 진지하게 참석하게 되고 회의는 효율적이 될 것이다.

회의의 시작부터 끝까지 관리해야 회의의 효율화를 기할 수 있다면 기업 내에 회의를 관리하고자 "회의관리자"를 지명해 운영하는 것도 하나의 방법이다. 회의 주최 측에서는 우선 회의관리자에게 회의 장소, 일시, 참석자 명단, 회의 목적과 안건, 결정할 사항 등을 전달한다. 회의관리자는 회의 장소 및 참석자의 참석 가능 여부를 확인, 조정하며 회의를 진행하고 난 뒤 미리 계획된 대로 회의가 진행됐는지, 결론은 도출됐는지 점검하고, 결정된 결론이 실행되고 있는지 사후 관리하게 해 전체 회의체 운영의 효율화를 기할 수 있다. 이렇게 기업 내에서 진행되고 있는 수많은 회의들을 비용?실행?참석자 시간 관리 측면에서 총체적으로 관리하는 회의관리자를 지명, 운영함으로써 조직 전체로 낭비될 수 있는 자원의 손실을 막을 수 있다.

지금 이 시간에도 기업 내의 회의실에서 많은 회의가 진행되고 있다. 과연 몇 명의 직원이 몇 시간씩을 모여 앉아 어떤 결론을 내렸는지 알 수 있거나, 어떤 결론을 내고자 회의를 계획 중인지 예상할 수 있는 기업이 몇이나 될 것인가! 이 글을 읽고 있는 여러분의 회사는 어떻게 회의를 진행하고 있는가. 이 기회에 회의가 진행되고 있는 회의실 뒤쪽에 앉아 있어 보라!!!

3. 이해관계자를 '내 편'으로 만들어라

이해관계자라 하면 고객과 같은 '프로젝트 스폰서', 프로젝트를 수행하는 '프로젝트 실행자', 프로젝트에는 직접 관여하지는 않지만 영향을 주거나 받을 수 있는 '외부 이해관계자'를 이야기 합니다.

이런 이해관계자를 명확하게 파악하고, 각자의 입장에서 프로젝트 수행에 대한 득실과 주장의 정보를 파악하고, 프로젝트에 대한 영향을 분석하고, 대응전략과 구체적인 실행방안을 세우고, 모니터링 및 피드백을 해야 한다는 겁니다.

여기에서는 주로 외부 이해관계자에 대한 이야기를 하고 있는데요..
저는 일반적으로 IT 프로젝트에 있어서 고객에 초점을 맞추고 싶습니다. 고객이라 하면 외부고객과 내부고객으로 나눠 볼 수 있을 겁니다.
내부에 같이 프로젝트를 진행하는 사람들도 하나의 고객이라고 생각하고 내편으로 만들어 업무를 진행한다면 프로젝트 진행이 좀 더 수월해지지 않을 까 합니다.

이해관계자 전체보기..

최근 우리나라의 각종 국책사업 중 어려움에 직면해 있는 프로젝트들이 있다. 예를 들어 새만금 간척사업과 부안 핵폐기물 처리장 건설사업 등이 있으며, 고속철도나 고속도로 건설의 경우 환경단체의 반대로 건설이 지연되는 경우도 있다. 기업에서도 신제품을 개발할 경우 특허권 분쟁이나 경쟁사의 이의 제기로 프로젝트가 미뤄지는 때도 있다. 이렇게 국책사업이거나 기업에서 추진하는 많은 프로젝트들이 시작 단계나 진행 과정에서 곤란을 겪는 경우가 종종 발생한다. 개인의 경우 주택이나 빌딩을 건축하는 과정에서도 일조권 같은 문제로 건축물 신축 프로젝트의 진행이 난관을 겪는 경우도 허다하다. 왜 이런 문제들이 발생하고 있을까.

어떤 일을 하고자 할 때 직/간접으로 이해 관계가 있는 사람들을 우리는 이해관계자라고 말한다. 쉽게 말하면 어떤 일로 인해 직/간접으로 손해를 보거나 이익을 보는 사람들을 "이해관계자"라고 정의한다. 프로젝트 추진에 관한 이해관계자로는 첫째, '프로젝트 스폰서'로서 기업의 이사회, 임원이나 부서장, 고위 관리 감독자, 외부나 내부의 고객들이며, 프로젝트를 입안하고 궁극적으로 프로젝트가 운영되도록 힘쓴다. 둘째, '프로젝트 실행자'로서 프로젝트 팀장, 팀원, 프로젝트 관련 공급자, 계약자, 전문가, 컨설턴트 등이며 직접적으로 프로젝트를 실행하는 그룹이다. 셋째, '외부 이해관계자'로서 환경단체, 사회단체, 언론, 경쟁사 등이며, 이 그룹은 이론상 프로젝트에 직접 관여하지는 않지만 프로젝트 진행 과정 중이나 결과로 영향을 받는다. 이런 외부 이해관계자들의 영향력이 너무 강력할 경우에 프로젝트 진행이 곤란할 경우도 있다.

프로젝트 초기부터 이해관계자들이 존재한다는 사실을 명확하게 인식하고 출발해야 프로젝트의 성공 확률을 높일 수 있다. 프로젝트를 입안할 때 우선 관련되는 이해관계자가 누구인지 명확하게 파악해야 한다. 이때 제외되는 이해관계자가 없도록 꼼꼼히 살펴야 한다. 이해관계자가 파악됐으면 각자의 입장에서 어떤 이해 득실이 있는지, 그들의 주장은 무엇인지 등 이해관계자에 대한 기초 정보를 수집해야 한다. 그리고 수집된 정보를 바탕으로 프로젝트에 어떤 영향을 미칠 수 있는지 상세히 분석해야 한다. 최종적으로 이해관계자별로 프로젝트에 미칠 수 있는 영향을 파악한 뒤 이에 대한 대응 전략을 세워야 한다. 대응 전략 수립 시 구체적인 실행 방안이 포함되도록 한다. 프로젝트를 진행하면서 실행 과정을 계속 모니터링하고 실행 결과를 피드백하는 일도 놓치지 않도록 한다. 이런 일을 위해 ??이해관계자를 관리할 책임자??를 선정해 체계적으로 관리한다면 더욱 효과가 있을 것이다.

하지만 이해관계자를 체계적으로 관리하는 일은 생각만큼 녹록치 않다. 그 이유는 이해관계자 간의 이해 관계가 단순하지 않다는 것이다. 우선 하나의 프로젝트에도 이해관계자는 다수가 존재하게 되며, 이런 여러 이해관계자 안에서도 그룹별로 이해 관계가 상충될 수 있다는 점이다. 또 이해 관계의 정도에 따라 이해관계자가 프로젝트 진행에 미치는 영향력의 크기에 차이가 나기도 하고 이해관계자 간의 이해 득실이 복잡하게 상호 작용하므로 사안이 단순하지 않다. 우리 사회 전반에서도 예전처럼 이해 관계가 있더라도 침묵하는 것이 아니라 적극적인 의사 표시를 하는 경우가 많아지고 있다. 인터넷 시대로 접어들면서 소수 집단이든 개인이든 의사를 명확하게 표현하는 시대로 접어들고 있다.

이제는 이런 의사 표시에 프로젝트의 진행 측에서도 명확하게 입장을 밝혀야 하는 시대가 됐다. 어떻게 보면 프로젝트의 진행 과정에서 관련 이해관계자들한테 투명하고 명확하게 사실을 밝히고 이해를 구해야 한다. 프로젝트의 종류에 관계없이 이해관계자는 있게 마련이고 대체적으로 모두를 만족시키기는 매우 어렵다. 그리고 이해관계자들이 필요한 정보를 모르고 있다가 프로젝트의 막바지에 알려져 프로젝트의 진행이 멈추어져 더욱 곤란을 받는 것보다는 처음부터 이해관계자들한테 사실을 알리고 충분히 설명하고 이해를 구해서 프로젝트를 진행하는 것이 오히려 시간을 절약하는 길이다. 대체적으로 처음 프로젝트를 설명하고 알릴 때는 사실보다 과장하거나 장밋빛으로 말하는 경향이 많다. 그러기보다는 사실에 가깝게 더욱 보수적으로 얘기하고 솔직하게 접근하는 것이 프로젝트가 진행되거나 종료되고 실행 단계에서 저항을 줄이게 된다.

프로젝트를 진행하려고 이해관계자들에게 여러 근사한 제안을 하거나 요즈음 사회 전반에 이슈가 되고 있는 선거에서도 입후보자가 여러 가지 환상적인 공약을 내걸고 있는 예를 많이 본다. 예전에는 공약은 공약이고, 제안은 제안에서만 잘 말하면 그만이었지만 이제는 사회가 투명해지고 있고 이런 제안이나 공약을 감시하는 사회단체들도 많아졌다. 이제는 이해관계자들이 처음 말한 사실과 실제 집행 과정을 비교 분석하면서 모니터링하고 있다. 섣불리 하면 더욱 곤경에 처할 수 있는 사회가 돼가고 있다. 이제는 처음부터 솔직하게 예상되는 문제점들을 정확하게 말해야 한다. 이해관계자들에게 적당히 얘기하고 넘어갈 수 있는 시대는 지나갔다. 좀 어렵고 시간이 걸리더라도 프로젝트의 시작 단계에서 프로젝트의 내용을 정확히 설명하고 설득해 이해를 구해야 한다. 논리적인 말로서는 약간의 문제가 있지만 요즘 교통방송에서 흘러나오는 '느린 것이 빠른 것이다'라는 캠페인은 프로젝트의 진행 과정에서도 더욱 실감나는 얘기로 들린다.

차라리 이해관계자들에게 대체적인 의견 접근을 이루지 못한다면 프로젝트를 출범하지 않는 게 현명할 수 있다. 우리는 너무 쉽게 이해관계자들을 취급하는 경향이 있다. 출발 전에 이렇게 이해관계자들에게 이해를 구하거나 공감대를 형성해두면 진행 과정에서 문제를 훨씬 줄일 수 있다. 물론 처음에 이해를 구했다고 해서 진행 과정에서 소홀히 해서는 안 된다. 프로젝트의 진행 과정에서도 관심을 갖고 이해관계자들에게 진행 과정을 계속 알려야 한다. 이렇게 해야 이해관계자들이 이 프로젝트의 열렬한 옹호자들이 되어 프로젝트의 성공을 기원하게 된다.

프로젝트의 성공으로 가는 길은 이렇게 험난한 여정이 도사리고 있다. 하지만 외롭게 프로젝트 관련자들만 가는 것보다 프로젝트의 이해관계자들과 동행해서 그들을 우리의 우군으로 만들어 같이 갈 수 있다면 어려운 난관도 쉽게 넘어서 프로젝트의 성공에 이를 수 있을 것이다.

4. 프로젝트 연착륙 뒤엔 변화관리가 있다.

여기에서 변화관리는 위의 변경관리와 다른 이야기 입니다. 변경관리가 프로젝트 진행 중에 발생하는 변경 요소를 관리하는 것이라면, 변화관리는 프로젝트 완료 후 새롭게 적용되는 변화에 대한 관리를 말합니다.

프로젝트를 완료하더라도 적용해야 하는 직원들의 새로운 환경이나 제도에 대한 저항을 받을 수 있다고 합니다. 그래서 실행 과정에서 직,간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다고 합니다.

변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 필요하다고 이야기 하고 있습니다.

실제로 어렵게 프로젝트를 통해 결과물을 만들어도 제대로 활용하지 않으면 무용지물일 겁니다.
결국 만드는 것만이 최종 마무리가 아니라 제대로 필요한 곳에 적용하는 것이 성공적인 프로젝트의 마무리가 아닐까 합니다.

변화관리 전체보기..

우리는 오늘도 어제와 변함없이 같은 장소에서 근무하고 있다고 생각한다. 하지만 우주 공간에서 좌표를 따져보면 어제와 같은 위치에서 근무할 가능성은 거의 없다. 이 우주 공간에서 지구는 태양을 중심으로 자전과 공전을 하고 있고, 물체들은 한순간도 멈추지 않고 내부적인 운동에 의해 변하지만 외부적인 운동으로도 끊임없이 변하고 있다. 이런 변화 속에 모든 물체들은 스스로 생존을 위한 노력과 관성에 의해 움직이고 있고, 모든 생물은 변화하는 환경에 적응하려고 노력한다. 이런 노력을 하지 않거나 포기한 생물은 점차 도태되거나 사라지게 되는 자연의 법칙을 우리는 배운다.

대부분 사람들은 어제까지 배웠던 지식을 오늘도 활용하고 싶어하며, 익숙한 행동을 하는 것에 편안함을 느낀다. 물론 로버트 풀검이 지은 책 <내가 알아야 할 모든 것은 유치원에서 배웠다>라는 제목처럼 한번 배운 것을 평생 사용할 수 있다면 얼마나 편하고 좋을까. 하지만 어제의 지식이 오늘 새롭게 변하는 환경에 적응하지 못하고 더 이상 유효하지 못하는 세상이 도래하고 있다. 이런 변화는 지금까지 배웠던 지식을 뒤로하고 새로운 것에 관한 학습을 요구하며, 새로운 것에 신속하게 익숙해질 것을 강요한다. 힘들게 배워서 적응할 만하면 또 변화하므로 늘 새로 배워야 한다는 부담은 사람들을 두렵게 만드는 요인으로 작용하며, 변화에 저항하게 하는 요인으로까지 작용하게 된다. 기업에서 비즈니스 프로세스 리엔지니어링(BPR)이나 전사자원관리(ERP), 연봉제, 새로운 원가관리시스템의 적용과 같은 많은 경영 혁신 기법들이 좋은 의도로 출발하나 실패하는 경우를 종종 보게 된다. 이렇게 실패하는 배경에는 조직원의 새로운 환경이나 제도에 대한 저항이 도사리고 있는 경우가 많다.

오늘날 기업들은 급변하고 있는 경쟁 환경 아래 시시각각 변하고 있는 고객의 마음, 경쟁사의 동태와 기술의 발전을 따라잡고자 애쓴다. 고객의 욕구에 맞는 제품이나 솔루션 또는 서비스를 제공해 경쟁 기업보다 더 많은 고객들을 확보하고, 나아가 치열한 경쟁에서 살아남으려고 노력한다. 이런 고객의 욕구를 더욱 빠르게 파악하고 변화에 대비하고자 여러 가지 경영 기법을 사용하기 위해 프로젝트를 수행하게 되며, 그 결과로서 기업 내부의 시스템이나 조직을 더욱 유연하게 만들게 된다.

이 시각 현재 기업에서는 경쟁력 향상 및 수익성 제고 등을 위해 ERP, 고객관계관리(CRM), 공급망관리(SCM) 등 각종 비즈니스와 IT 프로젝트를 수행하고 있다. 이런 프로젝트는 기업 내부 프로세스뿐만 아니라 조직상의 변화를 가져오게 되며, 폭넓게는 기업 문화 및 외부 이해관계자까지 영향을 미치게 되고, 조직원들에게는 큰 변화를 요구하게 된다.

대부분 IT 프로젝트 팀은 계획된 일정과 예산 아래 프로젝트를 성공리에 마치고자 프로젝트 수행에 모든 역량을 집중하게 되며, 프로젝트와 관련돼 일어날 변화에 대해 정작 알아야 할 조직원들에게는 상대적으로 대응을 등한시하게 된다. 어떤 프로젝트든지 크든 작든 그 프로젝트를 실행하는 과정에서 현재의 프로세스와 다른 변화가 뒤따르게 되며, 프로젝트 성과는 이해관계자의 변화 수용의 정도에 영향을 받게 된다. 프로젝트 종료 후 실행 과정에서 직/간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다.

IT 프로젝트의 성과는 프로젝트 결과에 직/간접적으로 영향을 받게 되는 조직원들의 의식 구조와 업무 방식이 변해야 나타난다. 따라서 변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 갈수록 중요해지고 있다. 이에 IT 프로젝트팀 구성 시 따로 변화 관리를 전담할 수 있는 이른바 '변화관리 추진조직'을 구성해 프로젝트 초반부터 변화 관리를 도맡도록 하는 게 바람직하다.

변화관리팀은 변화 관리에 대한 계획을 세우고 커뮤니케이션과 교육 및 훈련을 통해 운영하며, 그 결과를 평가해 성과를 보상해줌으로써 IT 프로젝트가 연착륙할 수 있는 중요한 역할을 맡게 된다. 변화관리팀의 역할은 첫째, 이해관계자 관리를 수행한다. 변화 스폰서의 지원을 가시화하고 조직원의 참여와 변화의 수용도를 높이고자 스폰서십 구현을 지원한다. 둘째, 프로젝트의 활성화를 꾀한다. 프로젝트 추진팀의 구성부터 프로젝트 추진에 전념할 수 있는 환경 조성을 위한 활동을 수행하며, 프로젝트 추진 성과에 대한 모니터링을 수행한다. 셋째, 조직원의 변화 관리 계획을 수립한다. 다양한 정보 분석을 통해 변화의 준비 상태를 평가하고 그 평가 결과를 활용해 변화 관리 계획을 수립한다. 넷째, 조직 역량에 관한 변화 방안을 세운다. 새로운 시스템 구축에 따른 프로세스 및 업무 양식의 변화를 위해 조직 구조 재설계와 바람직한 조직문화 형성을 위한 방안을 수립한다. 다섯째, 성과 관리 및 보상 체계를 수립하고 운영한다. 변화 관리 활동의 성과를 평가해 그 결과를 보상과 연계한다. 여섯째, 커뮤니케이션 활동을 통해 조직원들이 겪을 수 있는 변화에 대한 저항을 없애면서 변화에 순응할 수 있게 한다. 프로젝트 진행 과정에서 발생하는 프로세스, 시스템 및 조직상의 변화 방향에 대한 조직 구성원의 긍정적인 인식을 확보하려면 이해관계자별로 다양한 커뮤니케이션 채널을 활용해 수행한다. 일곱째, 교육과 훈련을 통해 조직원들을 변화에 적응시킨다. 프로젝트에 따른 업무 변화와 프로젝트의 활용 능력을 극대화해 조직원들의 시스템 이용률을 높이게 된다.

지금 이 시각에도 많은 기업 내부에서 IT 프로젝트가 진행되고 있으며, 프로젝트의 시작을 '우리는 매우 중요한 새로운 프로젝트에 착수합니다. 우리는 진정으로 이것이 중요한 일이라고 생각합니다'라는 메시지를 보내면서 시작하고 있다. 하지만 조직원들은 이 메시지에 쉽사리 관심을 기울이지 않는다. 이것이 변화관리팀이 직면하고 있는 어려움이다. 즉 그들은 사려고 하지 않는 사람들에게 뭔가를 팔아야 한다. 그들이 팔고자 하는 것은 변화이고, 사기를 주저하는 구매자들은 기업 내부의 사람들이다. 하지만 어렵다고 변화 관리 활동을 게을리 한다면 많은 프로젝트는 실행 과정에서 난관에 부딪치게 될 것이다. 이런 어려움을 극복하고 기업 생존을 위해 프로젝트를 수행한다는 것을 부단히 알리고 체계적으로 설명한다면 조직원들도 훨씬 적극적으로 변화를 수용하고 프로젝트의 성공에 동참할 것이다.

이어서 나머지 이슈화, 리스크관리, 인적자원, 현실과지표에 대해서 정리해 보도록 할께요~
프로젝트 관리 알면 알수록 배울게 많은 것 같습니다.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~ (1)	2011.12.22
프로젝트의 성공 요인 분석 #2 (0)	2008.09.15
프로젝트의 성공 요인 분석 #1 (0)	2008.09.15
프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18

분석, 성공, 요인, 프로젝트, 프로젝트관리

Trackback 0 And Comment 0

프로젝트에 이름을 지어주자~

| 프로젝트관리론/프로젝트수행 2008.08.28 11:17

Posted by 미니~

Don't call me names!
언뜻 보면 "내 이름을 부르지 마라" 일 것 같지만,
실제 의미는 "욕하지 마라", "약올리지 마라" 라는 뜻으로 사용되는 문장입니다.

names가 복수가 아닌 단수형인 name으로 사용되었다면 이름이라는 의미 그대로 쓰였겠지만,
복수가 되면서 여러개의 이름 즉, 별명으로 보기 때문에 위와 같은 뜻이 되었을 거라고 합니다.

이름이라는 것은 하나의 고유한 의미를 가져야 합니다.
그리고 이름을 지어준다는 것은 그 객체(물체이건 상황이건)에 생명력을 불어넣는 계기가 됩니다.

빅무(Big Moo)라는 책에 나오는 이야기 인데요..
뉴턴이 중력을 발견해서 유명해진 것으로 알고 있지만,
실제로 뉴턴이 발견한 것은 미적분과 반사 망원경이라고 합니다.

뉴턴은 미적분과 연금술 연구에 많은 시간을 보냈는데
오히려 그가 유명해진 것은 중력이라는 이름을 붙인 것 때문이라고 합니다.

중력이라는 이름을 부여함으로써 많은 사람들이 중력을 이용할 수 있는 기회를 준 것이죠..

한때 포탈들의 이름이 어떻게 만들어졌는지에 대한 포스팅이 유행했었는데요..
네이버는 navigate(향해하다) + 사람 접미사(er)의 합성어이고,
구글(google)은 googol이라는 10의 100제곱이라는 단어에서 유래했다고 하죠..

사이트가 성공해서 이름이 멋있어 보이는 건지,
이름을 멋지게 지어서 사이트가 성공한 건지는 모르겠네요..

여러분도 지금 하는 프로젝트에 이름을 지어주고, 의미를 부여해 보세요..
아마도 프로젝트가 한결 수월하게 진행되지 않을까 합니다. ^^

김춘수님의 꽃으로 마무리합니다.

내가 그의 이름을 불러 주기 전에는
그는 다만
하나의 몸짓에 지나지 않았다.

내가 그의 이름을 불러 주었을 때
그는 나에게로 와서
꽃이 되었다.

내가 그의 이름을 불러 준 것처럼
나의 이 빛깔과 향기에 알맞는
누가 나의 이름을 불러다오.
그에게로 가서 나도
그의 꽃이 되고 싶다.

우리들은 모두
무엇이 되고 싶다.
너는 나에게 나는 너에게
잊혀지지 않는 하나의 (의미가) 눈짓이 되고 싶다.

- 김춘수, 꽃 -

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

프로젝트의 성공 요인 분석 #2 (0)	2008.09.15
프로젝트의 성공 요인 분석 #1 (0)	2008.09.15
프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18
자주 리펙토링을 하라.(2) (1)	2007.10.16

이름, 코드명, 프로젝트

Trackback 0 And Comment 0

애자일.. XP.. 잘 안되는 이유는 뭘까요?

| 프로젝트관리론/프로젝트수행 2008.02.27 13:15

Posted by 미니~

요즘 애자일 방법론이나 XP(eXtreme Programming)가 프로젝트 관리에 있어 많은 관심을 받고 있습니다.

기존의 폭포수 모델 보다는 반복을 통해 보다 빠른 피드백이 가능하고..
자동 배포, 자동 테스트를 통한 개발 생산성 향상..
짝 프로그래밍을 통한 프로그래밍 효율성 증대..
그리고 주 40시간에서 16시간 근무로의 변경..

정말 매력적인 요소가 많습니다.
특히 야근에 찌들어있는 개발자들에게는 환상적인 요소지요.

그런데 제가 이런 부분들을 적용하면서 느끼는 점이 있는데요..
개발자 스스로 입맛에 맞는 것만 취하고 나머지는 버린다는 점입니다.

대표적인 것이 주 16시간 근무와 같은 것인데요..
이것의 기본 개념은 40시간에 일할 내용을 우리는 16시간이면 처리한다는 겁니다.
그리고 남는 시간에 자기개발이나 다른 새로운 것을 시도해 보는 것이죠..

이런 가치를 공유하지 못하고, 단순히 주 16시간이라는 것에 집착하는 경우가 많습니다.
그러다 보니 반복을 통한 피드백을 하려해도..
지난주 업무가 완료되지 않아.. 계속 일이 지체되는 안타까운 일이 반복되기도 합니다.

애자일이나 XP 방법론의 성공요소는 그 내용을 아는 것이 아니라..
그 속에 포함된 가치를 서로 공유하고 실행할 때 비로소 가능해 지는 것 같습니다.

실천을 통해 우리에게 맞는 방법론으로 변화한다면,
진정 개발자나 관리자, 회사책임자들 모두 즐겁게 일할 수 있는 환경이 만들어지지 않을까 합니다.

그래서 나 자신과 우리 회사에 이런 환경이 만들어질 수 있도록 계속 시도해보고 도전해보려고 합니다.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

프로젝트의 성공 요인 분석 #1 (0)	2008.09.15
프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18
자주 리펙토링을 하라.(2) (1)	2007.10.16
자주 리펙토링을 하라.(1) (0)	2007.10.13

xp, 방법론, 애자일

Trackback 1 And Comment 1

자주 리펙토링을 하라.(3)

| 프로젝트관리론/프로젝트수행 2007.10.18 09:00

Posted by 미니~

리펙토링을 실제로 어떻게 수행하는지.. 마틴 파울러(Martin Fowler)의 리펙토링 책에 나온 내용을 요약합니다.

여기에 정리한 내용은 인덱스 정도로 활용하시고.. 실제 리펙토링을 위한 예제나 자세한 설명은 책을 참고하시기 바랍니다.

1. 메소드 정리 (Composing Methods)

Extract Method (136)
그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.

Inline Method (144)
메소드 몸체가 메소드의 이름 만큼이나 명확할 때는, 호출하는 곳에 메소드의 몸체를 넣고 메소드를 삭제하라

Inline Temp (146)
간단한 수식의 결과값을 가지는 임시변수가 있고, 그 임시변수가 다른 리펙토링을 하는데 방해가 된다면, 이 임시변수를 참조하는 부분을 모두 원래의 수식으로 바꾸라

Replace Temp with Query (147)
어떤 수식의 결과값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 뽑아내서 메소드로 만들고 임시변수를 참조하는 곳을 찾아 모두 메소드 호출로 바꾼다. 새로 만든 메소드는 다른 메소드에서도 사용될 수 있다.

Introduce Explaining Variable (151)
복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용하라.

Split Temporary Variable (155)
루프 안에 있는 변수나 collecting temporary variable도 아닌 임시변수에 값을 여러 번 대입하는 경우에는, 각각의 대입에 대해서 따로따로 임시변수를 만들어라.

Remove Assignments to Parameters (159)
파라미터에 값을 대입하는 코드가 있으면, 대신 임시변수를 사용하도록 하라.

Replace Method with Method Object (163)
긴 메소드가 있는데 지역변수 때문에 Extract Method를 적용할 수 없는 경우에는, 메소드를 그 자신을 위한 객체로 바꿔서 모든 지역변수가 그 객체의 필드가 되도록 한다. 이렇게 하면 메소드를 같은 객체 안의 여러 메소드로 분해할 수 있다.

Substitute Algorithm (167)
알고리즘을 보다 명확한 것으로 바꾸고 싶을 때는, 메소드의 몸체를 새로운 알고리즘으로 바꾼다.

2. 객체간의 기능 이동

Move Method (170)
메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들어라. 그리고 이전 메소드는 간단한 위임으로 바꾸거나 완전히 제거하라.

Move Field (175)
필드가 자신이 정의된 클래스보다 다른 클래스에 의해서 더 많이 사용되고 있다면, 타켓 클래스에 새로운 필드를 만들고 기존 필드를 사용하고 있는 모든 부분을 변경하라.

Extract Class (179)
두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우, 새로운 클래스를 만들어서 관련 있는 필드와 메소드를 예전 클래스에서 새로운 클래스로 옮겨라.

Inline Class (184)
클래스가 하는 일이 많지 않은 경우에는, 그 클래스에 있는 모든 변수와 메소드를 다른 클래스로 옮기고 그 클래스를 제거하라.

Hide Delegate (187)
클래스가 객체의 위임 클래스를 직접 호출하고 있는 경우, 서버에 메소드를 만들어서 대리객체를 숨겨라.

Remove Middle Man (191)
클래스가 간단한 위임을 너무 많이 하고 있는 경우에는, 클라이언트가 대리객체를 직접 호출하도록 하라.

Introduce Foreign Method (194)
사용하고 있는 서버 클래스에 부가적인 메소드가 필요하지만 클래스를 수정할 수 없는 경우에는, 첫 번째 인자로 서버 클래스의 인스턴스를 받는 메소드를 클라이언트에 만들어라.

Introduce Local Extension (196)
사용하고 있는 서버 클래스에 여러 개의 메소드를 추가할 필요가 있지만 서버 클래스를 수정할 수 없는 경우, 필요한 추가 메소드를 포함하는 새로운 클래스를 만들어라. 이 확장 클래스를 원래 클래스의 서브클래스 또는 래퍼 클래스로 만들어라.

3. 데이터 구성 (Organizing Data)

Self Encapsulate Field (205)
필드에 직접 접근하고 있는 필드에 대한 결합이 이상해지면, 그 필드에 대한 get/set 메소드를 만들고 항상 이 메소드를 사용하여 필드에 접근하라.

Replace Data Value with Object (209)
추가적인 데이터나 동작을 필요로 하는 데이터 아이템이 있을 때는, 데이터 아이템을 객체로 바꾸어라.

Change Value to Reference (213)
동일한 인스턴스를 여러 개 가지고 있는 클래스가 있고 여러 개의 동일한 인스턴스를 하나의 객체로 바꾸고 싶으면, 그 객체를 참조 객체로 바꾸어라.

Change Reference to Value (217)
직고, 불변성(immutable)이고 관리하기 어려운 참조 객체가 있는 경우, 그것을 값 객체로 바꾸어라.

Replace Array with Object (220)
배열의 특정 요소가 다른 뜻을 가지고 있다면, 배열을 각각의 요소에 대한 필드를 가지는 객체로 바꿔라.

Duplicate Observed Data (224)
GUI 컨트롤에서만 사용 가능한 도메인 데이터가 있고 도메인 메소드에서 접근이 필요한 경우, 그 데이터를 도메인 객체로 복사하고 옵저버를 두어 두 데이터를 동기화하라.

Change Unidirectional Association to Bidirectional (232)
각각 서로의 기능을 필요로 하는 클래스가 있는데, 링크가 한쪽 방향으로만 되어 있는 경우, 반대 방향으로 포인터를 추가하고 수정자(modifier)가 양쪽 세트를 모두 업데이트 하게 변경하라.

Change Bidirectional Association to Unidirectional (236)
서로 링크를 가지는 두 개의 클래스에서 한 쪽이 다른 한쪽을 더 이상 필요로 하지 않을 때는 불필요한 링크를 제거하라.

Replace Magic Number with Symbolic Constant (240)
특별한 의미를 가지는 숫자 리터럴이 있으면, 상수를 만들고 의미를 잘 나타내도록 이름을 지은 다음 숫자를 상수로 바꾸어라.

Encapsulate Field (242)
public 필드가 있는 경우, 그 필드를 private으로 만들고 접근자를 제공하라.

Encapsulate Collection (244)
컬렉션(collection)을 리턴하는 메소드가 있으면, 그 메소드가 읽기 전용 뷰를 리턴하도록 만들고 add/remove 메소드를 제공하라.

Replace Record with Data Class (254)
전통적인 프로그래밍 환경에서 레코드 구조에 대한 인터페이스가 필요한 경우, 그 레코드를 위한 데이터 객체를 만들어라.

Replace Type Code with Class (255)
클래스의 동작에 영향을 미치지 않는 숫자로 된 타입 코드가 있으면 숫자를 클래스로 바꾸어라.

Replace Type Code with Subclass (261)
클래스의 동작에 영향을 미치는 변경 불가능하는 타입코드가 있다면, 타입 코드를 서브클래스로 바꾸어라.

Replace Type Code with State/Strategy (265)
클래스의 동작에 영향을 미치는 타입 코드가 있지만 서브클래싱을 할 수 없을 때는 타입 코드를 스테이트(state) 객체로 바꾸어라.

Replace Subclass with Fields (270)
상수 데이터를 리턴하는 메소드만 다른 서브클래스가 있으면, 그 메소드를 수퍼클래스의 필드로 바꾸고 서브클래스를 제거하라.

4. 조건문의 단순화

Decompos Conditional (276)
복잡한 조건문 (if-then-else)이 있는 경우, 조건 then 부분 그리고 else 부분에서 메소드를 추출하라.

Consolidate Conditional Expression (278)
같은 결과를 초래하는 일련의 조건 테스트가 있는 경우, 그것을 하나의 조건식으로 결합하여 뽑아라.

Consolidate Duplicate Conditional Fragments (281)
동일한 코드 조각이 조건문의 모든 분기 안에 있는 경우, 동일한 코드를 조건문 밖으로 옮겨라.

Remove Control Flag (283)
일련의 boolean 식에서 컨트롤 플래그 역할을하는 변수가 있는 경우, break 또는 return을 대신 사용하라.

Replace Nested Conditional with Guard Clauses (288)
메소드가 정상적인 실행 경로를 불명확하게 하는 조건 동작을 가지고 있는 경우, 모든 특별한 경우에 대해서 보호절을 사용하라.

Replace Conditional with Polymorphism (293)
객체의 타입에 따라 다른 동작을 선택하는 조건문을 가지고 있는 경우, 조건문의 각 부분을 서브클래스에 있는 오버라이딩 메소드로 옮겨라. 그리고 원래 메소드를 abstract로 만들어라.

Introduce Null Object (298)
null 체크를 반복적으로 하고 있다면, null 값을 null 객체로 대체하라.

Introduce Assertion (306)
코드의 한 부분이 프로그램의 상태에 대하여 어떤 것을 가정하고 있으면, assertion을 써서 가정을 명시되게 만들어라.

5. 메소드 호출의 단순화

Rename Method (313)
메소드의 이름이 그 목적을 드러내지 못하고 있다면, 메소드의 이름을 바꿔라.

Add Parameter (316)
어떤 메소드가 그 메소드를 호출하는 부분에서 더 많은 정보를 필요로 한다면, 이 정보를 넘길 수 있는 객체에 대한 파라미터를 추가하라.

Remove Parameter (318)
파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면, 그 파라미터를 제거하라.

Separate Query from Modifier (320)
값을 리턴할 뿐만 아니라 객체의 상태도 변경하는 메소드를 가지고 있는 경우, 두 개의 메소드를 만들어서 하나는 값을 리턴하는 역할을 하고, 하나는 객체의 상태를 변경하는 역할을 하게 하라.

Parameterize Method (325)
몇몇 메소드가 메소드 몸체에 다른 값을 포함하고 있는 것을 제외하고는 비슷한 일을 하고 있다면, 다른 값을 파라미터로 넘겨 받는 하나의 메소드를 만들어라.

Replace Parameter with Explicit Methods (327)
파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면, 각각의 파라미터 값에 대한 별도의 메소드를 만들어라.

Preserve Whole Object (331)
어떤 객체에서 여러 개의 값을 얻은 다음 메소드를 호출하면서 파라미터로 넘기고 있다면, 대신 그 객체를 파라미터로 넘겨라.

Replace Parameter with Method (335)
객체가 메소드를 호출한 다음, 결과를 다른 메소드에 대한 파라미터로 넘기고 있다. 수신자 또한 이 메소드를 호출할 수 있다면 그 파라미터를 제거하고 수신자가 그 메소드를 호출하도록 하라.

Introduce Parameter Object (339)
자연스럽게 몰려다니는 파라미터 그룹을 가지고 있다면, 그것들을 객체로 바꾸어라.

Remove Setting Method (344)
어떤 필드가 객체 생성시에 값이 정해지고 그 이후에는 변경되지 않아야 한다면, 그 필드 값을 설정하는 모든 메소드를 제거하라.

Hide Method (348)
메소드가 다른 클래스에서 사용되지 않는다면, 그 메소드를 private로 만들어라.

Replace Constructor with Factory Method (350)
객체를 생성할 때 단순히 생성하는 것 이외에 다른 작업도 하고 있다면, 생성자를 팩토리 메소드로 대체하라.

Encapsulate Downcast (355)
메소드가 그 호출부에서 다운캐스트 될 필요가 있는 객체를 리턴하고 있다면 다운캐스트 하는 것을 메소드 안으로 옮겨라.

Replace Error Code with Exception (357)
메소드가 에러를 나타내는 특별한 코드를 가지고 있다면, 대신 예외를 던져라.

Replace Exception with Test (363)
호출부에서 먼저 검사할 수 있는 조건에 대해 예외를 던지고 있다면, 호출부가 먼저 검사하도록 바꿔라.

6. 일반화 다루기

Pull Up Field (368)
두 서브클래스가 동일한 필드를 가지고 있다면, 그 필드를 수퍼클래스로 옮겨라.

Pull Up Method (370)
동일한 일을 하는 메소드를 여러 서브클래스에서 가지고 있다면, 이 메소드를 수퍼클래스로 옮겨라.

Pull Up Constructor Body (373)
서브크래스들이 대부분 동일한 몸체를 가진 생성자를 가지고 있다면, 수퍼클래스에 생성자를 만들고 서브클래스 메소드에서 이것을 호출하라.

Push Down Method (376)
수퍼클래스에 있는 동작이 서브클래스 중 일부에만 관련되어 있다면, 그 동작을 관련된 서브클래스로 옮겨라.

Push Down Field (377)
어떤 필드가 일부 서브클래스에 의해서만 사용되고 있다면, 그 필드를 관련된 서브클래스로 옮겨라.

Extract Subclass (378)
어떤 클래스가 일부 인스턴스에 의해서만 사용되는 기능을 가지고 있다면, 기능의 부분집합을 담당하는 서브클래스를 만들어라.

Extract Superclass (384)
비슷한 메소드와 필드를 가진 두 개의 클래스가 있다면, 수퍼클래스를 만들어서 공통된 메소드와 필드를 수퍼클래스로 옮겨라.

Extract Interface (389)
여러 클라이언트가 한 클래스 인터페이스와 동일한 부분 집합을 사용하고 있거나, 두 클래스가 공통된 인터페이스를 가지는 부분이 있다면, 그 부분 집합을 인터페이스로 뽑아내라.

Collapse Hierarchy (392)
수퍼클래스와 서브클래스가 별로 다르지 않다면, 그것들을 하나로 합쳐라.

Form Template Method (393)
각각의 서브클래스에 동일한 순서로 비슷한 단계를 행하지만 단계가 완전히 같지는 않은 두 메소드가 있다면, 그 단계를 동일한 시그니처를 가진 메소드로 만들어라. 이렇게 하면 원래의 두 메소드는 서로 같아지므로, 수퍼클래스로 올릴 수 있다.

Replace Inheritance with Delegation (401)
서브클래스가 수퍼클래스 인터페이스의 일부분만 사용하거나 또는 데이터를 상속 받고 싶지 않은 경우, 수퍼클래스를 위한 필드를 만들고 메소드들이 수퍼클래스에 위임하도록 변경한 후 상속 관계를 제거한다.

Replace Delegation with Inheritance (404)
위임을 사용하고 있는데 전체 인터페이스에 대해 간단한 위임을 자주 작성하고 있다면, 위임하는 클래스를 대리객체의 서브클래스로 만들어라.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18
자주 리펙토링을 하라.(2) (1)	2007.10.16
자주 리펙토링을 하라.(1) (0)	2007.10.13
테스트 코드.. 우선 개발할 것인가? (0)	2007.08.19

리펙토링, 소스코드, 프로젝트

Trackback 0 And Comment 0

자주 리펙토링을 하라.(2)

| 프로젝트관리론/프로젝트수행 2007.10.16 09:00

Posted by 미니~

리펙토링을 하려면 소스 코드 속의 나쁜 냄새를 맡을 수 있어야 한다고 합니다.

"리펙토링"이란 책에서 켄트 벡(Kent Beck)과 마틴 파울러(Martin Fowler)가 이야기한 코드 속의 나쁜 냄새에 대해 정리해 보려고 합니다.

사용자 삽입 이미지

중복된 코드 (Duplicated Code)
- 동일한 소스가 여기 저기 사용된다면 반드시 리펙토링을 해야 한다고 합니다.
Extract Method (136), Extract Class (179), Pull Up Method (370), Form template Method (393)

긴 메소드 (Long Method)
- C 프로그래밍부터 시작해서인지 절차적 프로그래밍에 익숙한 경우, 하나의 메소드에서 모든 일을 처리하는 경우가 종종 있습니다. 긴 메소드는 쪼개야 한다고 하네요~
Extract Method (136), Replace Temp with Query (147), Replace method with Method Object (163), Decompose Conditional (276)

거대한 클래스 (Large Class)
- 클래스가 너무 많은 일을 하면 변수도 많아지고, 중복된 코드도 많아질 가능성이 높다고 합니다.
Extract Class (179), Extract Subclass (378), Extract Interface (389), Replace Data Value with Object (209)

긴 파라미터 리스트 (Long Parameter List)
- 메소드에 전달되는 파라미터가 길면 소스를 이해하는 것이 어렵기 때문에 수정하는 것이 낫다고 합니다.
Replace Parameter with Method (335), Introduce Parameter Object (339), Preserve Whole Object (331)

확산적 변경 (Divergent Change)
- 말이 좀 어려운데요.. A라는 클래스를 "가" 이유 때문에 3개의 메소드를 수정해야 하고, 또 "나" 이유 때문에 4개의 메소드를 수정해야 한다면.. 차라리 "A가", "A나"와 같이 두개의 객체로 만드는 것이 바람직하다는 것인데요.. 대략적으로는 알겠는데 정말 확 와닿지는 않네요..
Extract Class (179)

산타총 수술 (Shotgun Sugery)
- 역시 어려운 말입니다. -.- 자주 수정하는 부분인데.. 한번 수정할 때마다 여러개의 클래스를 수정해야 한다면 이를 하나의 클래스만 수정하도록 변경해야 한다는 겁니다. 요건 가끔 있을 것 같네요..
Move Method (170), Move Field (175), Inline Class (184)

기능에 대한 욕심 (Feature Envy)
- 메소드가 자신이 속한 클래스보다 다른 클래스를 더 많이 활용하고 있다면, 옮겨야 겠죠..
Move Method (170), Move Field (175), Extract Method (136)

데이터 덩어리 (Data Clump)
- 한 클래스와 관련없는 여려 데이터들이 모여있는 경우입니다. 각각의 역할에 맞는 여러개의 객체로 쪼개야 한다고 하네요..
Extract Class (179), Introduce Parameter Object (339), Preserve Whole Object (331)

기본 타입에 대한 강박관념 (Primitive Obsession)
- 기본 타입만을 고집하지 말고 Money 클래스, Range 클래스, 전화번호 클래스, 우편번호 클래스등 특정한 작업을 위한 작은 객체를 충분히 활용하라고 합니다.
Replace Data Value with Object (209), Extract Class (179), Introduce Parameter Object (339), Replace Array with Object (220), Replace Type Code with Class (255), Replace Type Code with Subclasses (261), Replace Type Code with State/Strategy (265)

Switch 문 (Switch Statements)
- Switch 문은 객체지향 코드에서는 다형성을 이용해 수정해 주어야 한다고 합니다. 기본적으로 Switch문이 중복성을 가지고 있기 때문이라고 하네요~
Replace Conditional with Polymorphism (293), Replace type with Subclasses (261), Replace Type Code with State/Strategy (265), Replace Parameter with Explicit Method (327), Introduce Null Object (298)

게으른 클래스 (Lazy Class)
- 클래스가 충분한 일을 하지 않을 경우, 제거해야 한다는 겁니다.
Inline Class (184), Collapse Hierarchy (392)

추측성 일반화 (Speculative Generality)
- 앞으로 필요할 것 같아서 미리 추가한 기능과 관련된 코드중 실제로 사용되지 않는 것은 삭제하라는 거네요
Collapse Hierarchy (392), Inline Class (184), Remove Parameter (318), Rename Method (313)

임시 필드 (Temporary Field)
- 객체 안의 인스턴스 변수가 특정 상황에서만 사용된다면, 이해하기 어렵게 되므로 변경해야 한다고 하네요.
Extract Class (179), Introduce Null Object (298)

메시지 체인 (Message Chains)
- 어떤 객체를 사용하기 위해 다른 객체에 물어보고, 다른 객체는 다시 또 다른 객체에 물어보고, 그 객체는 다시 다른 객체에 물어보고.. 이런 경우가 메시지 체인이라고 하네요~~
Hide Delegate (187)

미들 맨 (Middle Man)
- 클래스 메소드의 대부분이 다른 클래스로 위임하고 있다면.. 지나친 캡슐화를 사용한고 있다는 것인데요.. 리펙토링을 적용해야 한다고 하네요~
Remove Middle Man (191), Inline Method (144), Replace Delegation with Inheritance (404)

부적절한 친밀 (Inappropriate Intimacy)
- 지나치게 친밀한 클래스는 서로 갈라 놓아야 한다고 하네요..
Move Method (170), Move Field (175), Change Bidirectional Association to Unidirectional (236), Replace Inheritance with Delegation (401), Hide Delegate (187)

다른 인터페이스를 가진 대체 클래스 (Alternative Classes with Different Interface)
- 같은 작업을 하지만 다른 시그너처를 가진 메소드에 대해서 리펙토링 하라는 거네요..
Rename Method (313), Move Method (170)

불완전한 라이브러리 클래스 (Incomplete Library Class)
- 기존의 라이브러리 클래스가 가지고 있었으면 하는 메소드가 있다면 리펙토링을 통해 보완하라는 겁니다.
Introduce Foreign Method (194), Introduce Local Extension (196)

데이터 클래스 (Data Class)
- get / set 메소드만 가진 클래스.. 실제로 많이 만드는 데요~ 이런 경우 적절한 리펙토링을 하라는 거네요~
Move Method (170), Encapsulate Field (242), Encapsulate Collection (244)

거부된 유산 (Refused Bequest)
- 상속구조가 잘못된 경우, 새로운 형제 클래스를 만들고 리펙토링해야 한다는 이야기 입니다.
Replace Inheritance with Delegation (401)

주석 (Comments)
- 주석을 써야 할 것 같다면 먼저 코드를 리펙토링 하여 주석이 불필요하도록 하라는 거네요..
Extract Method (136), Introduce Assertion (306)

리펙토링은 최적화의 개념이 아니라.. 소스 코드를 이해하기 쉽게 만드는 겁니다.
소스 코드 속의 나쁜 냄새를 잘 파악할 수 있도록 위의 내용을 참고하시기 바랍니다.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18
자주 리펙토링을 하라.(2) (1)	2007.10.16
자주 리펙토링을 하라.(1) (0)	2007.10.13
테스트 코드.. 우선 개발할 것인가? (0)	2007.08.19

나쁜 냄새, 리펙토링, 소스코드

Trackback 0 And Comment 1

자주 리펙토링을 하라.(1)

| 프로젝트관리론/프로젝트수행 2007.10.13 16:02

Posted by 미니~

프로그래머들은 한번쯤 리펙토링이라는 것을 들어봤을 겁니다.
리펙토링이 좋다는 것은 익히 들어 알겠는데 실제로 못하는 경우가 대부분입니다.

왜 그럴까요?

우선, 리펙토링이 무엇이고 어떻게 하는 것인지 모르기 때문인 것 같습니다.
솔직히 저도 리펙토링 관련 책을 이번에 읽어보기는 했지만,
아직도 어떤 경우에 리펙토링을 해야 하는지 느낌이 확 오지는 않습니다. -.-

A->B로 변경하는 것이 설명되어 있으면, 바로 B->A로 바꾸는 것도 설명되어 있습니다.
즉, 경우에 따라 적용하는 리펙토링이 다르다는 것인데.. 이건 경험이 필요한 것 같습니다.~
끊임없이 생각해보고 변경하다보면 어떤 것이 올바른 리펙토링인지 알수 있지 않을까 합니다.

다음으로는 리펙토링을 하고 있으면, 윗분들은 아무것도 하지 않고 있다고 생각하는 경우가 많을 것 같습니다.
열심히 뭔가 코드를 고치고는 있는데, 프로그램 결과물이 바뀐게 없으니까요..
리펙토링은 기능개선이나 디버깅과 달리 프로그램을 현재 상태 그대로 두고 소스코드만 이해하기 쉽게 바꾸는 것이니까요..

하지만 이 작업의 중요성을 충분히 설명해 주어야 한다고 생각합니다.
프로젝트가 대규모가 될수록.. 추후 유지보수를 위해서도 리펙토링은 반드시 필요하거든요.

방법론에 따른 산출물이 있지 않느냐? 하고 반문할 수도 있지만..
글쎄요~~ 산출물은 끊임없이 바뀌는 프로그램을 모두 반영할 수 있을지 솔직히 의문이거든요
특히, 산출물에 기반하는 개발이 아닌, 개발후 형식적으로 만드는 산출물은 더욱 문제겠지요..
리펙토링을 통해 소스 자체가 훌륭한 산출물이 된다면 더할 나위 없지 않을까 합니다. ^^

사용자 삽입 이미지

마틴파울러(Martin Fowler)의 다음 이야기가 떠오르네요..

"컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다."

그렇다면, 리펙토링은 언제 해야 할까요?
자주.. 생각날 때마다 하는 것이 따로 일정을 잡아서 하는 것보다는 수월하다고 하네요..

그리고 리펙토링을 하려면 잘못됐을 때 소스를 이전 버전을 바꿀 수 있는 버전관리와..
현재 프로그램 전체를 테스트할 수 있는 테스트코드 또한 중요한 요소라고 합니다.

리펙토링을 통해서 잘 디자인된 소스코드를 만드시기 바랍니다.

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18
자주 리펙토링을 하라.(2) (1)	2007.10.16
자주 리펙토링을 하라.(1) (0)	2007.10.13
테스트 코드.. 우선 개발할 것인가? (0)	2007.08.19

리펙토링, 소스코드, 코드, 프로젝트

Trackback 0 And Comment 0

테스트 코드.. 우선 개발할 것인가?

| 프로젝트관리론/프로젝트수행 2007.08.19 18:17

Posted by 미니~

요즘 테스트 코드와 관련해서...

테스트 코드를 먼저 만들고 난 후, 코딩을 진행하는 것이 좋다...
또는 프로그래밍 코딩을 하면, 테스트 코드를 만들어 확인해야 한다..
리펙토링을 하기 전에는 반드시 테스트 코드가 있어야 한다..

라는 이야기를 많이 합니다.

테스트 코드라는 것이 매우 중요한 개념이라는 것은 많이 들어서 알 것 같습니다.
그런데.. 실천이 매우 어렵다는 것을 한번 느낀 적이 있어 글을 써봅니다.

최근 프로젝트에서 JUnit이라는 테스트 프레임워크와
Ant 툴을 이용해서 프로젝트에서 테스트 프로그램을 구성해 보았습니다.

흔히 말하듯 빌드 한방에 테스트가 완료되구요..
테스트 전후의 데이터도 변화가 없게 만들고...
나름 머리써가면서 잘 만들어 놨었죠~~

하지만, 테스트 구현에 있어 약간의 한계가 있었는데요..

첫째로, 테스트 코드를 만든 사람과 실제 프로그램 소스를 구현하는 사람이 달랐다는 점입니다.
팀원간의 소스코드에 대한 이해도 높인다는 (실은 프로젝트 관리자로서 개발자들의 코드를 살펴본다는 의미가 더 강했죠.. -.-) 명목하에 그렇게 구성했었죠..
그러다 보니.. 소스 코드가 명세 변경에 바뀌어 갈 때마다 테스트 코드도 업버전 되어야 하는데. 그렇게 되지 못했다는 겁니다.
결국 나중에는 테스트 코드는 쓰레기 코드가 되어 버려지게 되었죠.. -.-
(이 점이 아쉬웠는데요... 테스트 코드를 계속 발달시켜야 하는데.. 프로젝트 중간에 그러기가 어려웠거든요.)

둘째로, 테스트 프로그램이 모든 소스 코드를 커버해 주면 좋겠지만...
웹에서 받아들이는 부분은 일단 커버를 못해줬다는 점입니다.
Junit에 살펴보면 request, response를 가상으로 제어하는 부분이 있기는 하지만,
거기까지 적용하기는 복잡해서.. 내부 프레임워크에서 비즈니스 로직을 처리하는 부분부터만 테스트 코드를 적용한 거죠..
(이 부분은 이렇게 하는게 오히려 단순해 지기 때문에 테스트 구현에 도움이 되기는 하지만, 전체 프로젝트를 커버할 수없다는 단점도 있는 것 같더라구요.. )

어쨌든 처음으로 테스트 코드를 만들어 프로젝트에 넣어보았지만, 일단 성공하지는 못한 것 같습니다.
다음에는 테스트 코드를 먼저 만들고 코딩을 진행하는 방법도 한번 시도해 보려고 합니다.

혹시 이 부분에 대해서 좋은 경험 가진 분들의 댓글 부탁드립니다.
그럼.. 좋은 일요일 저녁 되세요~~

공감

sns신고

'프로젝트관리론 > 프로젝트수행' 카테고리의 다른 글

프로젝트에 이름을 지어주자~ (0)	2008.08.28
애자일.. XP.. 잘 안되는 이유는 뭘까요? (1)	2008.02.27
자주 리펙토링을 하라.(3) (0)	2007.10.18
자주 리펙토링을 하라.(2) (1)	2007.10.16
자주 리펙토링을 하라.(1) (0)	2007.10.13
테스트 코드.. 우선 개발할 것인가? (0)	2007.08.19