[독후감]프로젝트가 서쪽으로 간 까닭은 by 오리대마왕

프로젝트가 서쪽으로 간 까닭은프로젝트가 서쪽으로 간 까닭은 - 8점
톰 드마르코 외 지음, 박재호 외 옮김/인사이트

소프트웨어 개발 프로젝트에서 볼 수 있는 양상을 86개의 항목으로 정리한 책이다. 이 86개 항목 중에는 권장할 만한 패턴들도 있고, 반대로 만약 현장에서 이러한 양상이 보인다면 시급한 개선이 필요한 항목들도 있다.

이쪽 계열에서는 유명한 저술가인 톰 드마르코 외에 5명이 함께 쓴 책이다. 톰 드마르코의 책 2권 (피플웨어, 소프트웨어 프로젝트에서의 리스크 관리) 을 읽어봤지만, 전혀 내 취향이 아니었던지라 조금 주저하게 되었으나 이 책은 아주 좋았다. 조엘 온 소프트웨어를 연상시킬 정도로 상당히 유머러스하며, 핵심만 간략히 찝어준다. 364 페이지에 86개 항목이니 각 항목에 대략 4 페이지 정도를 할애하고 있으며, 그 4페이지 중의 하나에는 커다란 사진 한장만 덩그라니 나와 있다. 교과적으로 주저리 주저리 얘기하는 대신, 백전노장들의 따끔한 충고가 아주 함축적으로 3페이지에 걸쳐 나와있는 형태이다. 나름 상당히 구체적으로 얘기하고 있어서 실전에 써먹어 봄 직 하다.

지금 참여하고 있는 프로젝트가 상당히 힘든 상황이라 사무실 풍경을 머리 한켠에 떠올리며 책을 읽었다. 구체적인 정황을 이야기 하긴 어렵지만 한마디로 "소프트웨어 개발, 정말 어렵구나." 를 아주 뼈저리게 느끼고 있다. 물론 코드로 구현하는 것도 어렵긴 하지만, 코딩으로 가기 위한 중간 과정이 정말이지 너무 어렵다. 우울하게도 책에서 얘기하는 좋은 양상은 잘 보이질 않네. 덕분에 사람들 만나면 맨날 한탄만 하는 것 같구나. :(

인상깊었던 패턴과, 짧은 감상을 정리해본다.

1. 아드레날린 중독증 - 멍청하면 손발이 고생한다는 것을 잘 풀어서 이야기 하고 있다.
2. 발바닥에 땀나도록 뛰어라 - 제목만 보면 나쁜 패턴같아 보이지만, 결정 내용에 대해 실천하는 조직의 우수성을 이야기한다. 반대는 토크쇼 팀 회의 이다. 주저리 주저리 말만 많고 정작 내용도 없으며 실행도 없는.
3. 생선 썩는 내 - 침몰해가는 배에 탑승한 선원의 느낌이랄까. 여기저기 냄새는 나지만, 그렇다고 뭐라 하기도 어렵고. 이럴 땐 팀을 옮기던지, 회사를 옮기던지, 야근을 하는 게 답이리라. 적어도 하는 시늉이라도 해야 나중에 욕이라도 덜 먹지. 정말 사기 쪽쪽 떨어지게 만드는 상황.
6. 관련통 - 다음 문장에 밑줄 쫙 - "근본 원인이 아니라 관련통만 치료하는 일반적인 이쥬 중 하나가 조사를 꺼려서다. 조사를 꺼리는 이유는 조직 문화 탓이너가 아니면 빨리빨리 결과를 내라는 압력 탓이다./관련통을 치료하는 프로젝트는 흔히 편법을 남발한다."
7. 내일 - 일을 잘게 쪼개는 것이 무엇보다 중요하다. 그래야 숨은 영향도 빨리 보이고, 사람들 간 의존관계도 쉽게 풀릴 수 있고. 근데 이 잘게 쪼개는 것이 어마어마하게 어렵더라. 초반에 WBS 백여개로 쪼개는 것도 보긴 했지만, 결국 재조정,재조정. 프로젝트 초기에 꼼꼼하게 잡기는 애초에 불가능 하니, 단계 초기에 시간을 들여서라도 계획을 세밀히 하면 좋으리라.
9. 무드링 관리 - 우리나라만 이러는 게 아니구나. "열심히 하고 있으니 잘 될 겁니다!" / "우린 정말 최선을 다 하고 있습니다." 류의 주간보고. 열심히 삽질할 계획중이신 우리나라 높은 분 생각이 나는군.
11. 영혼을 빌려주다 - "진짜 유능한 전문가는 해결할 문제에 맞춰서 답을 찾아간다." 패턴 이름, 정말 잘 지었다.
12. 시스템 개발 레밍 주기 - 프로세스는 각 프로젝트마다 다 달라야 한다. 프로세스, 방법론은 반드시 테일러링 되어야 함을 잘 이야기 해 주고 있다.
13. 후보 선수 없음 - 데이터 백업이 중요하듯이, 백업 인력도 중요하다. "프로젝트를 진행 하다 보면 어느 순간 시간이 부족해진다. 그때는 돈을 들여서라도 시간을 살 수 있으면 좋겠다고 생각한다. 하지만 프로젝트 트 후반에 이르면 시간을 살 기회는 거의 없다. '벤치'에 후보 선수 몇 명을 챙겨두면 핵심 인력이 떠났을 때 시간을 돈으로 사들이는 셈이 된다." 멋진 표현이다. 프로젝트 후반에 닥쳐서 땜방 인력 투입해 봤자 프로젝트에 독만 된다는 것을 명심해야 한다.
14. 조각칼을 주었으니 미켈란젤로가 되어라 - 책은 관리자가 주도하는 도구 적용을 이야기 하지만, 나는 개발자들도 함께 조심해야 할 사항이라 생각한다. 깔쌈해 보인다고 무조건 깔지 말자. 괜히 새로나온 이클립스 세팅한다고 바쁜 프로젝트 와중에 반나절 날리지 말자.
15. 대시보드 - 나도 대시보드에 환상을 갖고 있다. 하지만 과연 잘 사용할 수 있을까?
17. 끝없는 장애물 - 불평은 결정 나기 전에 얘기할 것. 결정 난 상황에 대해선 닥치고 따를 것.
18. 영계와 노땅 - IT 노년화 증상은 이미 흔하게 보이고 있다. 내가 지금 7년차인데, 난 항상 막내였다. 도대체 신입 개발자들은 어디에 있는걸까?
19. 영화평론가 - 진짜 밉상인, 한대 콱 패주고 싶은 놈들이 꼭 있다. 마치 지 이름 들어간 프로젝트인데도 남의 일 같이 얘기하는 놈들.
20. 한 놈만 팬다 - R&R(역할&책임) 의 중요성은 두말하면 잔소리다. 무조건 모든 작업엔 담당자를 붙여야 한다.
23. 자연적인 권위 - 일을 맡겼으면 좀 믿자. 그들의 결정을 믿자.
25. 침묵은 암묵적인 동의다 - 이건 정말 어려운 얘기다. 특히 여러 조직 얽혀 있을 때. 무조건 증거를 남겨놓고, 만천하에 공개하자.
30. 몽당연필 - "지난친 비용절감은 회사 경쟁력을 떨어뜨리고 결국 비용 상승마저 초래한다." 그런데 나는 지금 비용절감 한다고 직원들 커피믹스부터 안사주는 회사들이 득시글한 나라에 살고 있다.
33. 포커 게임 - "부서가 다른 직원들이 모여서 업무와 무관한 활동을 함께 한다." 회사의 동아리 지원은 참 좋은 정책이라 생각한다. 팔은 안으로 굽기 마련이다.
36. 사이다하우스 규칙 - 규칙을 만들어야 하는 입장에서, 많은 반성을 하게 된다. "유용하고 합당하고 합리적인 규칙이라야 팀이 따른다. 하지만 현실과 규칙이 다르다면 현실이 이긴다."
37. 말한 다음 써라 - 회의록 작성이 이제서야 몸에 익었다. 회의록은 한줄이던 두줄이던 무조건 쓰고, 무조건 참여자에게 돌려야 한다. 적어도 내가 안까먹기 위해서도 필요하다.
38. 프로젝트 매춘부 - 이름 죽인다. 프로젝트를 희생양 삼아 자기 발판을 다지는 관리자...
39. 대들포 - 예상과 달리 나쁜 패턴이다. 적극적으로 위임하자. 오죽하면 자리가 사람을 만든다는 말도 있겠어. 근데 난 맨날 막내라서 ^^
40. 옷 입는 이유 - 모두가 모든 걸 다 알 필요는 없다. 알아서도 안된다. 사공이 많으면 배가 산으로 간다.
44. 파란 영역 - "습관적으로 권위를 무시하는 팀원이 한명 정도는 필요하다." 난 이 정도로 열정이 있을까?
46. 진실은 천천히 알려주마 - 완전 동감. 이슈를 깔아뭉게게 되는 문화가 있다. 반드시 개선되어야 한다.
48. 음악가 - IT쟁이들 중에 밴드하는 사람 진짜 많다. 나도 그렇고 말이지. :)
53. 자료 품질 - 기능 품질도 문제지만, 자료 품질이 문제인 경우도 많다. 데이터 마이그레이션 해 본 사람들은 (도대체 어떻게 들어온 지 모를) 말도 안되는 쓰레기 더미들을 매번 한가득 발견할 것이야.
55. 예의바른 조직 - 우리나라에선 더 큰 문제일 것이다. 산출물과 자신을 동일시하여 산출물에 대한 비판을 자신의 비판으로 받아들인다. 나도 크게 자유롭진 못하고. 내가 택한 방법은 "그럼 어떻게 개선하면 더 나아질까요?" 라는 방향으로 이끌어나가는 것이다. 그럼 그나마 덜 상처를 받게 되더라.
56. 전념 - 사람의 context switching 비용은 엄청나다. 프로젝트 중복 투입은 절대 피하자.
61. 고아 산출물 - 뭐 너무도 많이 보는 경우이니. 근데 나 자신이 산출물 관리하는 역할이다보니 이것도 참 쉽지가 않다. 차라리 모든 산출물에 스폰서 개념을 도입하는 건 어떨까. "요구사항 명세서는 아무개씨가 요구한 문서입니다. 따라서 요구사항 명세서 개발에 투입된 공수에 대해서는 아무개씨가 유용성을 입증해야 합니다." 류의?
62. 숨겨진 아름다움 - 아무리 밥벌이를 위해 하는 것이라고 해도, 많은 개발자들은 좋고 멋진 SW를 만들겠다는 사명감을 갖고 일한다. 멋진 걸 멋지다고 알아보는 사람들과 일할 수 있다는건 정말 축복일 것이야.
69. 말린 몬스터 - 절이 거지같다면, 중이 떠나는게 맞겠지. 침몰할 배에서는 빨리 뛰쳐나가는 게 똑똑한 것 아니겠어?
70. 브라운 운동 - 프로젝트 목표, 방향성, 표준등은 소수의 사람이 잡아야 한다.
71. 크고 또렷하게 - 많은 갑들에게 묻고 싶어. "당신, 이 프로젝트 왜 하는 지는 알고있나요?"
79. 인쇄소 - 산출문 목록을 만드는 입장에서 많은 고민이 된다. 대부분 비겁하게 고객에게 꼬투리 잡히기 싫어서 문서들을 만들어내야 한다고 하지는 않았는가?
84. 설익은 아이디어의 고결함 - 문제는 "오, 그 아이디어 개선해서 다음주까지 완벽하게 보고서 만들어오세요." 와 같이 흐를 경향이 많다는 것... 보상은 없고 일만 떨어지니 누가 아이디어를 내?
86. 템플릿 좀비 - 변명할 여지가 없다. 난 템플릿 좀비이고, 남들에게도 템플릿 좀비를 강요하고 있어. 도대체 어떻게 똘똘하게 산출물을 정의할 수 있을까...


http://kingori.egloos.com2009-12-05T16:25:260.3810

핑백

덧글

  • 매운맛나리 2009/12/06 13:55 #

    이 책 재밌겠넹
  • 오리대마왕 2009/12/07 19:34 #

    매우 재밌다. 읽어보셈~
  • 2009/12/22 14:35 # 삭제 비공개

    비공개 덧글입니다.
  • illlust 2009/12/26 17:44 #

    제목들이 와닿는게 많네요 제가 해온 삽질들을 포함해서..^^; 한 번 사서 읽어봐야겠네요
  • 오리대마왕 2009/12/27 15:33 #

    매~우 재밌습니다. 한번 읽어보세요 :)
  • nexus11 2012/01/09 15:21 # 삭제

    캬~ 잘 봤어요 ~
※ 로그인 사용자만 덧글을 남길 수 있습니다.