|
▶ 읽게 된 동기
지인이 이 책에 대해서 극찬을 하며 읽어보라고 건내었다. 1달정도 책꽂이에 꽂아 두었는데, 요즘 앞으로의 방향성에 대해 고민이 깊어지는 중 이 책이 생각나서 꺼내들었다.
▶ 책 리뷰
필자는 1년간 회사생활을 하면서 몇개의 프로젝트에 참가하였다. 물론 모든 프로젝트에서 최하위 개발자 역할을 담당하였지만, 시작되는 프로젝트마다 점점 맡는 역할이 늘어난다는 것이 꽤나 고무적이였다.
업무의 중요도가 높아지면서 조금씩 스스로의 생각들도 늘어나게 되었는데 그 생각들을 조금씩 표출하게 되고 내 이야기가 반영이 되지 않으면 불만을, 반영되면 희열을 느끼게 되었다.
본 책에는 여섯명의 저자들이 도합 150년에 달하는 경력을 바탕으로 프로젝트의 시작부터 끝까지 일어나는 프로젝트의 패턴을 86가지로 정리하여 소개하였는데, 나의 1년간의 아주 짧은 프로젝트 경험을 대입해보며 흥미롭게 읽었다.
신기술이 정답은 아니다.
소프트웨어 공학에서 배우는 소프트웨어 방법론 중 가장 처음 배우는 모형이 폭포수 모형이다. 폭포수 모형은 폭포의 시작에서 끝까지 차례로 폭포가 떨어지는 과정. 즉, 1.0 -> 2.0 -> 3.0 으로 버전업을 하는 대부분의 프로젝트 유형을 말한다. 필자 또한 폭포수 유형의 프로젝트에 참가하였다.
애자일 방법론을 쉽게 말하면 특공대라고 할 수 있다. 빠른 개발을 추구하며, 곧바로 시장의 반응을 살피는데 용이하기 때문에 Start up 에서 많이 사용하고 있는 방법이라 할 수 있다.
단, 새로운 방식이라 해서 무조건 좋은 방법은 아니다. ‘프로젝트마다 다른 방법론이 필요하다.’ 라는 알리스테어 콕번의 말처럼 애자일 방법론 등의 새로운 기술만 추구하는 것은 위험하다고 저자는 이야기 한다.
팀워크!
필자는 팀워크의 중요성에 대한 패턴을 정리하였는데, ‘포커게임’ 과 ‘음식++’ 이 그것이다.
포커게임은 업무를 떠나서 프로젝트 팀원들이 모여 업무와 전혀 상관없는 대화를 나누며 게임을 하라는 것인데, 그렇게 가까워짐으로써 얻게되는 시너지 효과들을 이야기 하였다. 또한 ‘음식++’ 에서는 영화 ‘센과 치히로의 행방불명’의 프로젝트팀 이야기가 나오는데, 함께 저녁을 만들어먹으면서 깊어지는 유대관계에 대해서 이야기 하였다.
이처럼 프로젝트는 혼자 하는 것이 아님이 명확함에도 불구하고 실제 필드에서는 ‘회사는 회사일뿐’ 같은 생각을 가진 사람들이 더러 있다.
아직 필자는 실패한 프로젝트를 경험하지 못하여서 유대관계가 깊지 않았을때의 프로젝트 실패가 어떤 결과를 가져오는지 모르지만, 필자들은 함께 게임을 하고 음식을 만들어 먹으면서 유대관계를 깊이 할 것을 추천하고 있다.
<프로젝트가 서쪽으로 간 까닭은? / 출처 – Dragon>
가볍게 읽어야 좋을 책.
필자는 본 책을 일주일에 걸쳐 읽게 되었는데, 딱히 큰 감명은 받지 못하였다. 물론 중간중간 흥미있는 문장들은 여러줄 적었지만 무릎을 ‘탁’ 칠 정도의 희열은 없었다.
본 책은 프로젝트의 긍정적인 패턴과 부정적인 패턴을 이야기 하지만 그 방향성에 대해서는 명확히 제시하지 않는다. 단지 문제점만 이야기 하기 때문에 ‘그렇군…’ 하고 생각이 머문다. 물론 이는 필자의 프로젝트 경험이 부족하기 때문일수도 있다.
또한, 번역서라는 느낌이 너무도 강하게 다가왔다. 흔히 이런 블로그 포스팅 형식의 글들은 수필처럼 술술 읽히게 마련인데 한페이지를 다 읽고서도 고개를 갸우뚱 하며 다시 위로 올라와 읽을 정도로 본책의 문장들이 익숙한 표현은 아니였다.
한가지 흥미로운 사실은 이 책이 해외에서 쓰여진 책 임에도 불구하고 꽤나 많은 패턴에 대해서 공감한 사실은 해외의 it 프로젝트도 크게 다를 바 없다는 사실을 깨닫게 해주었다.
국내 개발자는 해외와는 달리 3D 업종이다 라는 말은 그저 어리광임을 깨닫게 되었다. it는 우리나라만 3D인게 아니고 원래가 3D 였던 것이다… ㅜㅜ
오랜만에 읽은 책. 필자는 이책에 평점을 별3개로 정의 하였다.
‘it의 여러 사례들을 알 수 있겠다’ 라는 가벼운 마음으로 읽고 싶다면 추천하고 싶다.
▶ 책 속의 좋은 글
– 우리들 대다수는 현재에서 대략 30일에서 90일 정도를 내다보고 계획을 세운다.
– 프로젝트마다 다른 방법론이 필요하다. – 알리스테어 콕번
– 새것이 무조건 좋지는 않다.
– 기본기 이상을 익히고 표준 조리법을 벗어날 때에야 진짜 뛰어난 요리사로 부상한다.
– 도구 ‘사용’ 비용은 도구 ‘구입’ 비용보다 훨씬 더 비싸다. – 도로시 그라함
– 자신에게 책임이 주어지면, 그것도 아주 명확한 책임이 주어지면 사람들은 의욕이 높아진다.
– 자신에게 맡겨진 책임을 분명히 이해하는 사람은 자신감이 넘친다.
– 적막한 사무실은 팀이 마법을 잃었다는 징후다.
– 아이팟은 프로젝트 팀이 흔히 간과하는 비기능적인 요구사항을 제대로 갖추었다.
– 프로젝트 초반부터 프로토타입을 활용하여 피드백을 얻으라. 비기능적인 품질을 높여 사용자가 좋아할만한 제품을 만들어라.
– 리듬이 없는 팀에 비해 리듬이 있는 팀은 좀더 유용한 결과물을 더 자주 내놓는다.
– 조직도에서 멀리 떨어진 사람과 개인적인 친분을 쌓으면 중요한 업무를 매끄럽게 진행하기 쉬워진다.
– 때로는 발가락만 담가 봐도 굳이 뛰어들 필요가 없다는 사실이 드러난다.
– 자료 품질이 엉망이다. 그런데 회사는 자료 처리 소프트웨어를 개선한다.
– 소프트웨어 프로젝트가 성공하려면 한 번에 한 프로젝트에만 전념하는 개발자가 필요하다는 뜻이다.
– 한 팀이니까. 같이 먹고 싶으니까. 그래서 그들은 같이 밥을 먹었다.
– 완벽은 더할 내용이 없을 때가 아니라 뺄 내용이 없을 때 도달하는 상태다. – 앙투안 드 생텍쥐페리
– ‘잘 모르겠습니다.’ 라는 답변은 진실이라는 장점 외에도, 협력을 촉발하는 방아쇠가 된다. 문제를 아는 누구나 도우려고 나서는 분위기가 조성된다. 무지한 상태가 오래가지 않는다. 지식 격차를 모두에게 알렸으니 금방 좁혀진다.
– 게릴라 팀은 낯설고 새로운 문제 영역을 탐험하여 혁신적인 해결책을 찾아내는 프로젝트에 가장 적합하다.
– 우리는 남들이 나를 이해하리라 생각한다.
– 그렇다면 앞으로 네 번째 반복에서 여덟 번째 반복까지 비슷한 사건이 생길 경우를 대비해서 어느 정도 버퍼를 잡았습니까?
– 프로젝트에서 작성하는 모든 문서는 필요성이 분명히 정의되어야 하며, 전체 프로젝트 지식으로 추적이 가능한 내용을 담아야 한다.
– 정작 프로젝트에 속하는 사람들은 냄새를 못 맡는다.
DragonAce
Comments