|
한국에서 IT기술서적은 많으나, IT 프로젝트의 필수적인 요소인 인간, 조직, 관계를 기술과 함께 논의하는 책은 드물다. 그래서 이 책을 기다렸는 지 모른다. SI프로젝트는 속된 말로 요구사항이 있고, 이를 바로 프로그래밍한다 소위 잘 수행되는 프로젝트 잘 만들어진 시스템을 위해 새로운 구현기술과 설계기술, 절차를 도입하지만, SI프로젝트의 수행에서 기술은 전부가 아니라 부분에 불과하다. 저자는 많은 전문가들이 감춰오고 감춰왔던 여러 이야기를 실질적이고 사실적으로 풀어나간다. 조직과 조직의 싸움, 개인과 개인의 싸움, 욕구와 욕구와의 싸움, 여기서 강한자의 욕구가 관철될 것이고, 강한자는 더한 권력이 있는 사람이다. 이 상황에서 저자는 생존을 얘기한다. 얼마나 자신의 능력을 어필하여 주도할 수 있는가? 주도할 수 없다면, 어떻게 프로젝트에서 필요한 사람이 되겠는가? 어느 영화에서처럼 끝까지 살아남은 자가 강한자라면, 험난한 IT 산업계에서 이 책은 필수 도서가 아닌가 싶다.
|
|
한국 소프트웨어 엔지니어들은 노조조차 없이 전근대적인 환경에서 착취당하는 노예나 다름없다면서 이야기를 시작하고 있는 이 책은 소프트웨어 개발 현장은 처절한 전쟁터이며 프로젝트 현장은 대단히 정치적인 곳이기에 정치적인 감각이 없으면 생존할 수 없다고 말한다. 혼자서 살아남기 어렵기 때문에 강력한 팀을 만들어 팀의 능력을 극대화해야 하는데, 자신이 그런 팀의 리더가 되든지, 그런 팀에 들어가 자신을 보호해야 한다고 조언한다. 그리고 소프트웨어의 특성을 이해하고 분석, 설계, 구현, 테스트까지 기본적인 것은 해낼 수 있는 능력을 키워야 생존할 수 있다고 말한다. 사실 이 책은 현장경험에서 우러나온 아주 현실적인 조언들을 해주고 있다. 프로젝트 상황이 정상적으로 흘러가지 않기 때문에 정상적인 상황을 가정하고 만든 소프트웨어 공학이나 방법론은 소용이 없다면서 차라리 프로젝트가 늘 비정상적이라고 생각하고 해결책을 찾는 것이 나을 것이라 말하고 있으며, 모든 프로젝트는 사업상 매력적인 이유 때문에 선택되기 때문에 기술적으로 이것이 가능한 인지 고려하는 것은 우선 순위에서 밀린다면서 결국 프로젝트 시작부터 실패가 예견될 수 있다고 말한다.
수많은 유사한 건물을 지으면서 무엇을 하면 안 되는지 비교적 명확해졌기 때문에 건물이 어떠해야 하는지에 대한 사람들의 요구사항은 비교적 분명한 반면 소프트웨어의 경우 프로젝트 마다 독특하며 이전 프로젝트에서 했던 것을 가져다 활용할 수 있는 것이 많지 않다는 특징도 언급한다. 그래서 이 책은 소프트웨어도 문제 영역을 정의할 때는 일단 문제는 이것이라는 가설을 세운 후 프로그램을 구현해야 하며, 이렇게 가설을 세우고 결과물을 만들고 다시 가설을 세우는 과정을 반복해야 한다고 주장한다. 그 도구로 테스트 주도 개발, 짝 프로그래밍, 리팩토링을 적용할 수 있다고 말한다. 또한 도메인 주도 개발의 문제점을 언급하며 근본적으로 도메인의 복잡성을 소프트웨어 서비스, 컴포넌트, 유스케이스, 클래스로 단순화 시킬 수 없다고 말한다. 현실적인 방법으로 도메인의 변경을 두려워한다면 우리가 최선을 다해 할 수 있는 것은 변경되지 않으리라고 판단되는 것을 가설로 세워야 한다고 조언한다. 즉, 변경되지 않는 부분을 기초로 프로그램의 구조를 결정하는 것이 최선이라는 말이다. 사실 소프트웨어 분야가 발전하지 못하는 이유가 정보의 교류가 상당히 미흡한 탓이라 언급한다.
소프트웨어 공학이나 새로운 프로그램 언어, 개발 도구는 소프트웨어 발전에 끼치는 영향이 미미한 반면 진정 필요한 것은 도메인에 대한 지식을 서로 교환하는 것이라는 조언도 빼놓지 않는다. 이어서 이 책은 프로젝트 상황과 팀워크에 대한 문제로 넘어간다. 개발자가 무엇을 하고 있는지 알 수 없다는 것이 프로젝트 관리의 큰 구멍이라면서 소프트웨어의 비가시성을 내부 감리, 외부 감리를 동원하여 풀려는 것은 어리석은 행위라 말한다. 개발자들은 자신을 감시하는 사람들이 많을수록 보고서 작성, 회의 등으로 더 많은 시간을 가치 없는 업무에 할애하기 때문이란 것이다. 또한 요구사항을 정의한 후 요구사항의 내용을 분석하는 폭포수 개발 방법은 비현실적인 개발 방식이라면서 현실에서는 시도하고 수정하기 방식으로 작업이 진행해야 한다고 조언한다. 그리고 아키텍처를 설계할 때 초기에 어려움을 겪는 이유 중 대부분은 너무 많은 것을 한 그림에 담으려고 하는 것이라면서 아키텍처의 목적은 구성요소의 조합에서 발생하는 문제점을 해결하는 것이라 언급하고 있다. 특히 아키텍처는 구성요소 자체의 문제점에 대해서는 말하지 않는다면서 구성요소를 어떻게 잘 만드는가는 개발 프로세스를 통해 해결할 문제라 말한다.
결국 아키텍처는 개별적은 구성요소들을 조합했을 때 어떤 문제가 발생하는지에 관심을 둔다고 말한다. 또한 한국인은 팀으로 일하는 것을 배울 기회가 공식적으로는 거의 없다면서 진정한 팀이란 개인에게 주어진 일조차 팀 전체로 처리되기 때문에 팀은 개인의 미숙함이나 개인의 변덕스러운 생산성 저하에 구애 받지 않는다고 말한다. 그리고 잘 굴러가는 조직은 그대로 놔두라는 이야기도 있다. 조직이란 자생적으로 스스로에게 주어진 문제를 해결하기 위해 역할을 분담할 수 있기 때문이라고 한다. 또한 두 사람에게 일을 시켰는데 서로 갈등이 있어서 성과가 나지 않는다면 개인적인 갈등을 해소하려 들지 말고 두 사람이 목표에 헌신하고 있는지 물어야 한다고 말한다. 그럼에도 불구하고 개인적인 갈등을 해소하지 않는다면 팀에서 추방해야 한다고 조언한다. 한편 팀원의 희생을 최소화하기 위해서는 특정인만 희생해서는 안되며 팀원 모두가 희생해야 하고, 장기적인 희생이 불가피하다면 팀원들이 서로 배우고 발전할 수 있도록 학습 시스템을 구축하며, 가끔 팀원들의 가족들과 함께 식사하며 팀원들이 얼마나 훌륭하고 대단한 일을 하고 있는지 알려주어야 한다고 조언한다.
또한 소프트웨어 개발을 포함하여 지식 산업은 무엇을, 어떻게, 왜 할 것인지에 대한 생각을 정리하는 것이 핵심인데, 그 생각이라는 것은 눈앞에 뭔가 보이는 것이 없으면 늘 혼란스럽기에 아이디어가 떠오르는 즉시 눈에 보이는 무엇인가를 만들어야 한다고 조언한다. 그리고 눈에 보이는 것이 있으면 사람은 보이는 것에 생각을 고착시키기 때문에 생각을 바꾸면 눈에 보이는 것과 새로운 생각이 간섭을 일으켜서 혼란에 빠지고 생산성이 떨어진다고 말한다. 따라서 지식 산업에서는 속도가 품질을 결정한다고 단언하고 있다. 특이한 것은 WBS는 될 수 있으면 작성하지 않는 것이 좋으며 일정을 작성하더라도 마일스톤만 정하되 한 달 이하로 작업을 쪼개서는 안 된다고 조언하고 있는 것이다. 또한 최대 10분이 넘어가는 프로젝트 계획에 없는 회의는 참여할 의무가 없다고 선언하는 것도 중요하다고 말한다. 한마디로 말해 개발자를 다른 일로 괴롭히지 말라는 것이다. 현재 개발 프로젝트는 고객, 감리, 경영진, 감독자의 감시 하에 놓여 있다면서 프로젝트 팀이 권한은 전혀 없으나 책임은 무한한 상황에서는 품질관리, 개발 방법론, 심지어 테스트 등의 짐을 덜어주는 것이 오히려 개발프로젝트를 도와주는 길이라고 말한다.
결국 소프트웨어 개발 프로젝트를 수행하는 사람은 고객이나 본사, 그리고 팀으로부터 권력을 획득해야 한다면서 프로젝트에서는 프로젝트의 성격과 일의 본질을 정확히 아는 것이 권력을 획득하는 최고의 방법이라 말한다. 프로젝트 관리자보다 관련된 업무를 더 많이 아는 사람이 없다는 것을 고객에게 인정받아야 한다는 것이다. 또한 프로젝트 현장을 잘 알고 그에 맞게 행동하는 PM은 본사와의 관계는 좋지 않은 것이 보통이기 때문에 본사와의 관계가 부드러운 사람을 차석으로 임명하여 함께 하는 것이 좋다고도 조언한다. 물론 권력을 얻기 위해서는 권력을 행사할 수 있는 사람의 신임을 얻어야 한다면서 프로젝트에서는 사람들이 실제로 필요로 하는 것을 줄 수 있는 사람이 권력을 얻는다고 말한다. 그리고 그런 권력을 획득하여 다른 사람이 내가 할 일을 대신 하도록 해야 한다고 조언한다. 또한 소프트웨어의 품질관리에는 한계가 있으며 결국 개발자를 신뢰하는 것 외에는 특별한 품질관리 방법이 없기 때문에 사람이 무엇을 원하는지 끊임없이 고민하면서 인문학 등을 공부할 필요가 있다고 주장한다. 전반적으로 현장의 목소리를 반영한 소프트웨어 개발자의 현실을 잘 보여주고 있는 책이라 할 수 있겠다.
|