'프로젝트 관리' 태그의 글 목록

'프로젝트 관리'에 해당되는 글 3건

2008.07.03 소프트웨어 공학과 PM의 역량 - 기획자는 PM이 아니다.
2007.12.03 소프트웨어 프로젝트에서의 리스크관리 - Waltzing with Bears
2007.11.19 프로젝트 매니저와 아키텍트를 혼동하는 사람들 3

2008. 7. 3. 12:50

소프트웨어 공학과 PM의 역량 - 기획자는 PM이 아니다.

2008. 7. 3. 12:50 in Project Management

하나의 시스템 개발은 많은 사람이 현업을 통해 만들어내는 공동 작품입니다.
조각 그림을 맞춰 나가듯 많은 공동 작업자들이 각 부분의 조각을 하나씩 완성해 나가고 그것을 통합하여 그림판에 옮겨 놓는 작업 입니다.

이런 작업에서는 우선 밑그림을 그리고, 각 조각을 만들고, 조각을 다시 그림판에 올려 놓는 일련의 활동을 하게 됩니다.

개발 방법론도 이런 일맥 상통한 작업이라고 할 수 있습니다.

하드웨어의 발전에 비해 소프트웨어 발전은 뒤처져 왔습니다. 그 원인이야 여러가지가 있겠지만, 소프트웨어 및 시스템은 반세기 동안 하드웨어/인프라 발전을 따라가지 못하고 있는 것이 현실 입니다.

소프트웨어가 발전이 느렸던 이유중 가장 큰 이유는

정형화 되어 있는 하드웨어 비해 소프트웨어는 정형화되어 있지 않기 때문입니다.
정형화되어 있지 않다는 것은 하드웨어 보다 소프트웨어쪽이 사람에게 가깝기 때문입니다.
(시스템중에 하드웨어 보다 소프트웨어가 사람의 생활패턴에 접근되어 있는 것이고, 기계와 인간간의 인터페이스 역활을 하고 있습니다. )

인간과 접근되어 있다 보니, 인간의 변화(혹은 변심)속에서 정형화라는 자체가 어려울 수 밖에 없습니다.

정형화를 위한 부분보다 어떻게 인간의 변화에 정확하게 대응하느냐에 대한 연구가 더 많이 발생할 수 밖에 없었을 것입니다.

개발 방법론은 이런 근본적인 원인으로 인한 많은 문제점을 효율적인 해결을 위한 방법으로 더욱 발전하게 되었습니다.

- 소프트웨어 공학 등장배경 -

● 하드웨어 개발 비용에 비해 소프트웨어 개발 비용의 증가
● 새로운 시스템 개발 요구 및 수요 급증
● 요구 및 수요 급증 대비 개발자 생산성 저하
● 개발 인력 부족
● 개발 기술 미비
● 기존 소프트웨어의 유지보수 어려움

소프웨어 공학은 소프트웨어의 개발에 필요한 모든 측면을 공학적인 접근 방법으로 다루는 학문으로

- 주어진 기간 내에 프로젝트을 효율적으로 관리하는 방법
- 프로젝트에 투입될 비용(Cost)를 예측하고 인력을 관리하는 방법
- 사용자 요구사항(Requirement)을 정확히 분석하고 요구사항에 적합한 소프트웨어를 개발하는 방법
- 개발 과정의 산출물을 체계적으로 문서화(Documentation)하는 방법

중심으로 연구를 합니다.

이런 의미에서 개발 방법론의 기본 개념은 소프트웨어 공학에서 나온 것입니다.

개발 방법론이란 제품을 생산하기 위한 일련의 활동(Activity)와 산출물(OutPut)를 체계적으로 관리하는 일련의 활동이라고 정의할 수 있으며, 이런 활동을 소프트웨어 공학에서는 소프트웨어 프로세스라고 정의하고 있습니다.

일반적인 프로세스 활동은 4단계로 이뤄집니다.

명세(Specification) : 기능과 운영상의 제약조건 정의
개발(Development) : 명세를 만족하는 소프트웨어 개발
검증(Validation) : 사용자가 원하는 소프트웨어인지 확인
진화(Evolution) : 사용자 요구사항의 변화에 부응하는 소프트웨어 변경

소프트웨어 공학이나, 개발 방법론이나 요구사항에 부합되는 제품, 서비스를 생산해내는 활동에 초점이 맞춰져 있고, 발생 예견된 많은 위험(RIsk) 최소화 하는 활동을 위한 관리기법(Management)이 필요한 것입니다.

PM(Project Manager)에 대한 잠시 짚어 보겠습니다.

- 프로젝트(Project) 란 프로젝트란 유일한 제품, 서비스 또는 결과를 창출하기 위해 일과성으로 투입하는 노력을 말한다.

- 프로젝트 관리(Project Management)란 프로젝트 요구사항을 충족시키는 데 필요한 지식, 기량, 도구 및 기법 등을 프로젝트 활동에 적용하는 것을 말한다.
프로젝트관리는 프로젝트 착수, 기획, 실행, 감시, 통제 및 종료 단계로 진행되는 프로젝트관리 프로세스의 적용과 통합을 통해 이루어진다.

- 프로젝트관리자(Project Manager)란 프로젝트 목표를 달성할 책임을 지고 있는 관리자를가리킨다.

- 출처 : PMBOK 3rd-

간혹 PM에 대해서 잘못 이해하고 있는 사람들이 많이 있습니다. 특히 웹에이전시의 PM는 그 역량에 대한 부분보다, 단지 클라이언트와의 접점을 위한 존재로만 인식하는 경우가 많이 있습니다.
그렇다보니, 기획자가 PM을 한다는 인식이 많이 가지고 있습니다.

PM은 관리자라고 해야 정확한 것입니다.
▶ 사용자(Client)의 요구사항과 프로젝트의 근본 방향을 정확하게 이해하고,
▶ 프로젝트 과업에 대한 일관성 있는 목표 달성의 책임을 가지고 있는 사람입니다.

프로젝트에 대한 전반적인 책임을 지기 위해서는 3가지의 중요한 역량이 있어야 합니다.

1. 일괄성
간혹 프로젝트를 하다 보면... 배가 산으로 간다는 말이 있습니다. 그 방향을 잃어 표류하는 배들은 난파될 확률이 높습니다. 초기반에 프로젝트의 배경을 이해하고 방향성을 갖추고 나면, 프로젝트 진행은 일괄성을 지녀야 합니다.
이 일괄성은 요구사항에 대한 부분이 가장 강합니다.

2. 단계성
일에는 순서가 있다고 말합니다. 각 단계에 대한 수행능력과 그 단계에 대한 조율을 적절하게 이뤄나가야 합니다.

3. 체계성
프로젝트를 진행하다 보면, 각 단계를 생략하는 경우가 많이 있습니다. 물론 상황에 따라 진행이 변화될 수 있겠으나, 모든 단계는 근거와 과정에 대한 이유가 존재하는 것입니다. 이런 단계를 거쳐 나갈때-변화가 되던 안되던- 체계적인 관리가 있어야 합니다. 특히 단계가 생략되는 경우에는 더욱 그렇습니다.

PM에 대한 이해가 낮을수록 프로젝트는 표류하여 난파될 가능성이 높습니다.

전쟁에서 많은 병사도 중요하지만, 병사들과 그들을 전쟁에 보낸 이들이, 중심에서 지휘하고 선장을 서는 장군이 어떤 존재인지를 이해해야지만, 일괄성을 단계성을 체계성을 보장 받을 수 있으며, 결국 전쟁에서 이길 수 있게 되는 것입니다.

기획자 = PM의 논리에서 벗어나야 합니다. PM은 누구나 될 수 있으나, 기본적인 지식을 습득되어야 합니다.

PM 는 개발/관리 방법론에 대한 지속적인 지식습득이 필요로 합니다.
집을 짓더라도, 토대가 제대로 잡히지 않는다면... 오래 가지 합니다.

Posted by 강팀장

2007. 12. 3. 15:01

소프트웨어 프로젝트에서의 리스크관리 - Waltzing with Bears

2007. 12. 3. 15:01 in 강팀장이 읽는 책/책소개

Project Management 관련 책의 대부분이 그들의 방법론 중심을 책을 저술하는 것이 사실입니다. 읽다보면 자신이 알는 것과는 다른 내용과 이해하기 어려운 프로세스에 대한 이야기로 일괄하다 결국 반도 못보고 책을 덮어 버리는 경우가 많았습니다.

블로그에 담아두고 있다가... 이번 프로젝트를 수행하면 꼭 읽어야 겠구나 싶어 1년 가까이 북마크만 해 놓았던 책을 구매를 하고야 말았습니다. (강팀장의 책 수집 블로그 http://blog.yes24.com/hanjum)

프로젝트 관리자 또는 리더(매니저)라면 한번 읽어 시길 추천합니다. 기술적인 방법론을 익힌기 위한 분도 괜찮겠지만 요즘 들어 왠지 답답한 분이나... 변명이 필요한 분이라면 재미있게 읽을 수 있을 것 같습니다. (^^ 제 경험일까요?? )

불확실성과 관련된 보다 중요한 원인들은 다음과 같다.

1. 요구사항(requirment) : 정확히 무엇을 하기 위한 시스템인가?

2. 정합성(match) : 사용자 및 다른 관련 시스템과 어떻게 연계할 것인가?

3. 환경 변경(chainging environment) : 개발 기간 중에 요구와 목표들이 얼마나 변경되는가?

4. 자원(resources) : 프로젝트를 위해 필요한 핵심 기술을 가진 사람을 확보할 수 있는가?

5. 관리(managerment) : 관리 조직에게 생산성이 높은 팀을 구성하며 사기를 유지하고, 인원 변경을 최소화하면서 관련 업무간의 복잡한 관계들을 풀어 나갈 능력이 충분히 있는가?

6. 공급망(supply chain) : 다른 관련 조직들이 기대대로 대응해 줄 것인가?

7. 정치(politics) : 현실을 호도하여 프로젝트의 궁극적 성공과는 상충되는 제약들을 부과하는 경우 어떤 영향이 있을까?

8. 상충(conflict) : 다양한 이해 조직 간의 상호 양립할 수 없는 목적들을 어떻게 다룰 것인가?

9. 혁신(innovation) : 이 프로젝트에만 적용된 기술이나 접근 방식이 최종 결과에 어떤 영향을 미칠 것인가?

10. 규모(scale) : 과거에 경험하지 못한 큰 규모가 프로젝트 성과에 어떤 영향을 미칠 것인가?

- 3장 덴버 국제공항 中 (45P)

운(Luck)

"내 생각에는 4월까지는 매우 어려워 보이네. 그래서 자네에게 이 일을 맡기는 것일세"

프로젝트가 하나의 도전으로 포장되어 주어졌을 때, 그로 인해 사람들은 어느 정도 운에 의존하는 자세를 취하게 된다. 예를 들어 사장이 당신에게 "당신과 당신 아래 8명의 직원이 4월까지 이 중요한 일을 해내는 것이 우리 회사의 마지막 희망이오. (저런, ceo가 언론에다가도 이를 말해 버렸다.)"라고 말한다면 달리 할 일이 무엇이 있겠는가? 만약 사장이 당신의 눈을 똑바로 쳐다보면서 사기를 쳐서라도 이것을 맡아 달라고 한다면, 당신은 그냥 최선을 다하면서 행운이 함께 하기를 바라는 수밖에는 없을 것이다.

중간에 특별한 행운이 없이는 4월까지 도저히 할 수 없다는 것을 인식하고, 그러한 행운을 잡는 것이 프로젝트의 아주 중요한 부분이 되어 버린다. 이는 리스크 관리와는 정확히 상반되는 것으로, 프로젝트 계획의 초점이 만약 행운이 따르지 않는다면 어떻게 할지에 맞추어진다.

개인적인 도전으로 시작된 프로젝트에서는 리스크를 합리적으로 관리하기 어렵다. 대신 행운에 의존하게 된다. 프로젝트가 그런식으로 주어진다면 할 수 있는 일은 많지 않을 것이다. 그러나 미래를 생각하면 배울 것이 없는 것도 아니다. 당신이 프로젝트를 직접 지시할 위치에 올랐을 때, 절대로 운에 의해 지배되도록 프로젝트를 포장하지 말라. 합리적이고 신축적인 목표를 제시하되, 실제 기대치는 행운이 일어나지 않으리라는 것을 고려하여 조금 여유를 두도록 하라

- 7장 운(luck) (77p)

모든 소프트웨어 프로젝트에 공통적인 리스크

여기저기 도처에서 발생하는 문제들이 꽤 있기 때문에, 모든 프로젝트에 대해, 정도는 다르겠지만, 발생하리라 예상되는 20~30개 정도의 문제에 대한 리스트를 만드는 것은 그다지 어려운 일이 아니다. 여기서는 그 중 다섯개만을 선택하여 다루었다. 그 이유는 이들을 통해 현실이 계획을 벗어나는 대부분의 상황을 설명할 수 있으며, 또 이 리스크와 업계의 유용한 데이터를 이미 확보하고 있기 때문이다. 핵심 리스크는 다음과 같다.

1. 원래 일정의 결함
2. 요구사항의 확대(시간에 따라 요구사항이 조금씩 늘어나는 것)
3. 인원의 교체
4. 설계 명세 붕괴(specification breakdown)
5. 낮은 수행능력(under-performance)

이 중 맨 마지막 것만이 수행능력과 관련된 것이다. 나머지 네 개는 당신이 얼마나 열심히 일하는가, 그리고 얼마나 경쟁력이 있고 능숙한가와는 거의 무관하다. 이를 강조하는 이유는 많은 관리자들이 리스크 관리를 수행능력의 저하에 대한 변명으로 삼기도 한다는 점을 우려하기 때문이다. 리스크 관리의 핵심은 제어불가 항목들에 대해서 합리적인 준비를 하는 것이다.
그런 중비를 통해 실패를 미연에 방지할 수 있다. 다시 말해 앞서 말한 제어불가 항목들이 당신을 문제에 빠뜨리는 경우에 대한 대비책을 마련하도록 해 주는 것이다.

- 중략 -

- 13장 소프트웨어 프로젝트의 핵심리스크 (152p)

우리에 대한 농담

우리 IT 사람들이 리스크 수용에 접근하는 방식이 다른 사람들과 다르다는 것에 대한 농담을 만든다면, 아마 이렇지 않을까?

IT 관리자와 보통 사람이 수요일 오후에 시카고에서 일을 하고 있고, 둘다 금요일 정오에 샌프란시스코에서 미팅에 참석해야 하며 시간을 지키는 것이 매우 중요한 것을 안다.
보통 사람은-다이안이라고 하자- 목요일 밤 비행기를 타고 샌프란시스코 사무실에서 한 블록 떨어진 조그만 호텔에 방을 잡는다.
허남이라는 식당에서 한가로이 식사를 하고 영화를 보고 유니온 스트리트 쪽으로 향한다. 다음날 여유 있는 아침식사를 하고 노트북 컴퓨터로 11시까지 작업을 한다.
11시 30분 체크아웃을 하고는 걸어서 10분 일찍 사무실에 도착한다.

반명 IT 관련자인 잭은 금요일 아침 8시 40분 비행기를 예약한다.
미드타운에서 7시 5분에 택시를 잡아타고 아이젠하워의 교통체증 속으로 들어간다. 오하라 공항까지 가는 내내 택시 운전사에게 화가 나서 불만을 토로한다.
멍청한 택시 운전사는 잭이 이 비행기를 타는 일이 얼마나 중요한지 이해하지 못하는 것 같다.
유나이티드 에어에 체크인을 하면서 직원에게 비행기가 정시에 출발해야 하고 변명은 통하지 않는다고 이야기한다.
그녀에게 어떤 이유로 인한 지연도 '매우, 매우 실망스러울 것'이라고 말한다. 탑승이 지연될 것이라는 말에 펄쩍 뛰며 반발한다.
조정된 시간이 방송되는 순간 그가 가지고 있는 관리도구들을 뒤져서 최후의 통첩을 전달한다.
"만약 내가 12시 미팅에 참석할 수 있도록 당신들이 샌프란시스코에 제때 데려다 주지 않는다면, 모자기자 날아갈 줄 아시오"

납기일자가 중요한 프로젝트는 일찍 시작하는 것이 진정한 리스크 완화다.
이는 아마도 거의 모든 프로젝트에서 지연이라는 리스크를 수용하는 가장 효과적인 방법일 것이다.
좋다. 프로젝트를 일찍 시작하기에는 너무 늦었다는 것을 알고 있다. 시작할 때 시작을 했고 이미 곤경에 빠져 있는 것이다. 그리고 어떻게 하면 곤경에 빠져 들지 않을 수 있었나를 알기 위해 이 책을 읽고 있지는 않을 것이다. 어떻게 하면 무사히 빠져 나올 수 있을지 알고 싶은 것이다. 모두 맞는 말이다. 그러나 아래에서 설명하는 것처럼 일찍 시작하는 선택은 어쨌든 가치 있는 일이다.

- 중략 -

- 17장 궁극적인 리스크 완화 전략(202p)

소프트웨어 프로젝트에서의 리스크 관리

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

Posted by 강팀장

2007. 11. 19. 22:00

프로젝트 매니저와 아키텍트를 혼동하는 사람들

2007. 11. 19. 22:00 in Project Management

소프트웨어 프로젝트가 실패하는 이유에는 수많은 원인들이 있다. 가장 고전적인 원인을 꼽는다면 ‘잘못 결정된 프로젝트 기간과 비용’일 것이다. 또는 요구사항을 제대로 파악하지 않았거나 빈번하게 수정했기 때문일 수도 있고, 주요 이해관계자의 참여 또는 경영층의 지원이 부족했거나, 제대로 된 프로젝트 계획을 작성하지 않았기 때문일 수도 있다. 그것도 아니면 프로젝트 또는 조직 내부의 정치적인 문제 때문일 수도 있다.

어떤 최악의 프로젝트에서는, 그 모든 요인들이 결합해서 나쁜 시너지를 만들어내고 그 결과로 참담한 상황을 맞이하기도 한다. 프로젝트에 나쁜 영향을 미치는 모든 요인들에 대해 살펴보려면 엄청난 지면이 필요할 것이다.

이번 컬럼에서는 가장 중요한 실패 원인 중 하나이지만 잘 거론되지 않는 사실을 하나 소개해 보겠다. 그것은 바로 프로젝트 매니저, 아키텍트의 역할을 혼동한 나머지, 잘못한 책임을 부여하는 것이다. 즉 관리 책임과 기술 책임을 구분하지 않는 문제인데, 가장 중요한 인적자원에 오류가 있는 것이어서 프로젝트의 근본적인 실패 원인으로 작용하게 된다.

현재의 상황을 살펴보자. 먼저, 지금 당장 아무 구인구직 사이트든 가서 확인해보라. 다음과 같은 글을 쉽게 만날 수 있을 것이다.

[PM 모집: 자격 요건은 다음과 같음]
C/C++, Java, DBMS를 능란하게 구사 가능해야 함
UML 등을 활용한 설계 능력이 뛰어나야 함
고객과의 원활한 의사소통 및 협상이 가능해야 함
교육 및 프레젠테이션 스킬이 뛰어나야 함
소프트웨어 프로젝트의 관리 능력이 능숙해야 함
기술사, PMP, CISA 등의 자격증 우대

위와 같은 사람을 구하려고 한다면 장담컨대 거의 확실하게 구할 수 없을 것이다. 우리 업계에 그런 스펙을 갖춘 사람도 드물지만, 그런 사람이 있다고 하더라도 구인 업체에서 어떻게 평가하고 판단할 수 있겠는가? 또한 충분한 대우는 가능할까?

멀티 플레이어에 대한 무지 또는 욕심
프로그래밍 능력의 경우 면접 시 테스트 프로그래밍을 통해 어느 정도 평가를 할 수도 있겠지만, 설계 능력과 관리 능력의 경우 테스트 자체가 거의 불가능하다.

위와 같은 사람을 구하는 것은 그저 업체의 욕심일 뿐이다. 프로그래밍 능력, 설계 능력, 관리 능력을 모두 갖춘 그런 자원이 거의 없는 것이 국내 업계의 현실이다. 개인 탓이 아니라 시대가 그렇다.

기술 쪽을 살펴보면, 지금은 코볼로 개발을 하던 1980년대가 아니다. 그때에는 코볼 하나만 알면 모든 것이 해결되었지만 지금은 알아야 할 것이 너무 많다. 관리 쪽도 만만치 않다. 비즈니스 환경을 전반적으로 이해해야 하고, 정치력도 필요하고, 문서 작성, 프레젠테이션을 잘 해야 하는 등 고도의 스킬이 필요해졌다. 그리고 관리와 기술은 서로 다른 분야이다.

하지만 주요 인적자원의 실제 업무를 이해하지 못한 채로, 멀티 플레이어(또는 업계 용어로 올라운드 플레이어)를 뽑으려고 노력하는 업체들이 참으로 많다. 그것은 무지 또는 욕심. 둘 중의 하나이다.

잘못된 역할 배정의 문제
위에 예를 든 구인 공고를 보면 알겠지만 그 제목은 어쨌거나 ‘PM 모집’이다. 즉 프로젝트 매니저를 뽑는 것이다. 그런데 세부 사항을 보면 도통 프로그래머를 뽑는 것인지, 설계자를 뽑는 것인지, 관리자를 뽑는 것인지 헷갈린다.

물론 척박한 국내의 IT 현실에 비추어 볼 때, 프로젝트에서 수많은 역할을 동시에 수행할 수 있는 그런 멀티 플레이어를 선호하는 상황을 인정하지 못하는 바는 아니다. 하지만 바로 그런 잘못된 판단 또는 욕심이 바로 프로젝트를 실패하게 만든다.

일단 프로그래머의 경우 모든 사람들이 익히 잘 아는 역할이므로 논외로 치고, 소프트웨어 아키텍트와 프로젝트 매니저의 역할을 생각해보자.

소프트웨어 아키텍트는 설계자이다. 개발을 위한 ‘소프트웨어 요구사항’을 파악하고, 큰 그림의 소프트웨어 아키텍처를 디자인하고, 개개의 프로그래머들이 작업해야 할 서브 시스템과 컴포넌트를 정의하는 사람이다. 또한 테스트 엔지니어들과 함께 테스트 요구사항을 수립하기도 하면서, 소프트웨어 개발의 전 과정에서 중요한 기술 책임자의 역할을 수행하는 사람이다.

프로젝트 매니저는 관리자이다. 프로젝트의 진행을 위한 ‘프로젝트 요구사항’을 파악하고, 프로젝트 계획을 수립하고, 개개의 팀원들이 작업해야 할 프로젝트 활동을 시간과 비용 개념을 갖고서 정의하는 사람이다. 또한 품질 담당자와 함께 품질 보증을 위한 활동을 수립하기도 하면서, 프로젝트의 전 과정에서 관리 책임자의 역할을 수행하는 사람이다.

소프트웨어 아키텍트는 소프트웨어 개발을 위한 높은 수준의 디자인을 계획하고 책임지는 사람이고, 프로젝트 매니저는 프로젝트 관리를 위한 여러 활동들을 계획하고 책임지는 사람이다. 기술 활동과 관리 활동은 분명히 다른 것이다.

하지만 많은 업체들이 그것을 혼동함으로써 재앙을 불러온다. 마치 프로젝트 매니저가 프로그래밍도 잘 알아야 하고, 설계도 잘 해야 하고, 관리도 잘 해야 한다고 생각한다. 물론 작은 규모의 프로젝트에서는 단 한 명이 모든 역할을 다 수행하는 경우도 있겠지만, 그것은 아주 예외적인 것이다.

기술 책임자와 관리 책임자는 구분되어야 한다
대부분의 소프트웨어 프로젝트에서 프로젝트 매니저의 역할과 아키텍트의 역할은 명확히 구분될 필요가 있다. 물론 두 사람이 상호 신뢰 하에 관리 책임자, 기술 책임자로서 긴밀하게 협조해야 하는 것은 자명하다.

그러므로 이 컬럼의 진지한 충고는, 프로젝트 매니저와 아키텍트의 역할을 제대로 구분하고 적합한 사람을 각각의 역할에 배정하라는 것이다. 그런 사람이 없어서 못 쓴다고 항변하는 업체들도 있을 것이다. 글쎄, 세상에 쉬운 일이 어디 있겠는가? 그것은 시간을 갖고 업체 스스로 양성을 하든, 경쟁 업체에서 스카우트를 하든, 해외에서 데려오든 해당 업체가 판단할 일이다.

프로젝트의 실패. 그것은 바로 소프트웨어와 프로젝트의 본질을 무시하고 인적자원의 중요성을 무시한 행동에 따른 필연적인 결과가 아닐까 필자는 생각한다. 그래서 필자는 다음의 주장을 명백히 강조하고 싶다.

“기술 책임자와 관리 책임자는 구분되어야 한다” 그것은 CEO와 CTO가 구분되어야 하는 것과 같은 개념이다. 만일 무지하여 그러한 구분을 제대로 해내지 못하거나, 또는 비용 절감의 욕심에 사로잡혀 고의적으로 그것을 행하지 않는다면, 프로젝트는 필히 재앙으로 보답할 것이다. 소프트웨어 프로젝트의 역사는 그것을 증명하고 있다. @

류한석(피플웨어 운영자)

오래전의 글 입니다.

요즘 이런 글에 더욱 관심이 가는 것은 앞으로 강팀장은 무엇을 해야 하는가에 대한 스스로에 대한 고찰이라고 할지도 모르겠습니다.

그러고 보면 요즘 참 많은 고민을 하고 사는 것 같습니다.