Ⅰ. 저자에 대하여

신승환

고려대학교 기계공학과를 졸업하였으며 동대학원에서 석사를 마쳤다. 소프트웨어 개발, 프로젝트 관리, 컨설팅의 업무를 수행하고 있다. 관심 분야로는 더 나은 개발 환경 및 직장생활이고, 이에 대한 저작 작업에 주력하고 있다. 현재는 차량용 임베디드 소프트웨어 개발, 컨설팅을 하고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(http://twitter.com/talkwithhani)에 꾸준히 남기려고 노력한다. 저서로는 『시지프스를 다시 생각하다』『겸손한 개발자가 만든 거만한 소프트웨어』『도와주세요! 팀장이 됐어요』 등이 있으며 역서로는 『뽀모도로 테크닉』『고약한 문제, 합당한 해결』『Manage it!』『Release it』『애자일 프랙티스』『실천가를 위한 실용주의 프로젝트 관리』『레일스와 함께하는 애자일 웹개발』등이 있다.

*yes 24 작가란 참조

Ⅱ. 내 마음을 무찌러드는 글귀

1부 덫에 걸린 프로젝트

111, 상관의 지시라고 무조건 따르는 것도 위험합니다. 상관의 명령을 실행하는 것보다 프로젝트가 올바른 방향으로 나아가게 하는 것이 더 중요하기 때문이죠.

139, 영철씨가 코칭을 오해할 것 같습니다. 코칭은 교습이 아닙니다. 팀원이 능력을 키워야 할 때 어떻게 목표를 설정하고 목표를 달성하려면 계획을 어떻게 세워야 하는지, 아울러 계획에 따라서 올바르게 수행하는지, 문제는 없는지 평가하는 게 코칭입니다.

141, 이런 관리방법이 몸에 배려면 문제가 생겼을 때 누군가에게 비난의 화살을 돌기기보다 근본문제를 찾으려고 부단히 노력해야 하고, 사람을 관리하기보다 목표를 관리해야 합니다. 아울러 목표를 달성하려면 팀원들을 어떻게 도와주어야 하는지 고민해야죠. 그렇기 때문에 관리는 어렵지만 그만큼 보람 있는 일입니다.

2부 초보 팀장이 알아야 할 관리기법

177, 배신과 잔인한 짓을 거듭하는데도 불구하고 지배자가 오랫동안 권력을 유지하는 경우가 있다. 그가 잔인한 수단을 효과적으로 이용했기 때문이다. 다시 말하면 처음에는 권력을 완전하게 확보하기 위해서 악한 수단을 사용하지만, 자기에게 대항할 세력이 모두 사라진 뒤에는 그 수단을 버리고 백성들에게 유익한 조치를 취하는 것이다.

잔인한 짓을 처음에는 적게 하다가 날이 갈수록 더욱 많이 하는 것처럼 어리석은 짓은 없다. 그런 지배자는 자기 지위를 오랫동안 유지할 수 없다.

-마키아벨리의 ‘군주론’에서

179, 관리자를 양성하려고 체계적인 교육 과정을 운영하는 회사는 드뭅니다. 체계적으로 교육받지 못하기에 관리는 일종의 기술입니다. 즉, 깨지고 넘어지고 실수하고 배우는 게 관리죠.

184, 도요타식 문화가 자리잡지 않은 팀이라면 가급적 ‘왜’라는 질문은 삼가는 것이 좋습니다. 문맥에 따라서 달라지는 ‘왜’라는 질문은 애매한 상황에서 사용하면 관계를 악화시키기 때문입니다.

184, 쉽지 않은 일이지만 여러 가지 문제를 일으키는 근본 문제를 찾아보세요! 근본 문제를 찾아 해결한다면 여러분을 괴롭히는 많은 문제를 해결할 수 있답니다.

186, 자신이 속한 곳에서 자신이 경험했던 것을 바탕으로 문제를 바라보기 때문입니다.

187, 쉬운 문제라고 생각했던 것도 다양한 관점에서 바라봄으로써, 내가 알고 있는 것보다 더 좋은 해결책을 얻습니다. 경험을 통해서 인간은 발전하기도 하지만, 이처럼 경험이 더 나은 해결책을 생각해내는 것을 방해하기도 합니다.

187, 팀을 이끄는 팀장으로서 익숙한 해결책을 선택하기보다, 팀원과 다양한 관점에서 해결책을 찾도록 노력해보세요.

189, 타인과 좋은 관계를 맺지 못하면 내가 이야기하는 것이 아무리 옳다 하여도 내 이야기는 감정의 영역에서 걸러지기에, 상대방에게 전달되지도, 상대방을 설득하지도 못합니다.

195, 팀원의 능력과 팀의 성과 사이에 강한 상관관계가 존재하지 않는 이유는 뭘까요? 바로 ‘시너지 효과’와 ‘책임감 나눔’에서 이런 현상이 벌어지는 원인을 찾을 수 있습니다

198, 특히 작은 프로젝트 팀에서, 리더십은 팀장의 과거를 반영하는 거울입니다. 팀원들이 팀장이 제시한 목표를 향해 달려 나갈 때, 팀원들의 의지를 이끌어 가는 것은 팀장이 한 약속, 말 그대로 말뿐인 약속입니다.

199, 팀장이 한 약속이 한두 번 지켜져서 두터원 신뢰가 쌓이면 이 팀에는 열정과 신뢰가 넘칩니다. 반면에 팀장이 내뱉는 공허한 약속은 팀원들의 사기를 저하시키고 얼마 안 되는 똑똑한 팀원을 멀리 떠나 보냅니다.

199, 아침부터 퇴근까지 함께 생활하는 프로젝트 팀에서 리더십을 이루는 기초는 ‘신뢰’입니다. 팀장이 사소한 것 하나라도 반드시 지키려는 모습은 작은 신뢰를 쌓고, 이런 소소한 신뢰들이 모여 초대형 태풍이 몰아쳐도 팀을 보호하는 강력한 리더십 방파제가 된답니다.

202, 계획보다 더 중요한 것이 ‘계획하기’입니다. ‘계획하기’라는 행위로, 우리는 미래에 원하는 곳에 도달하기 위해 현재 부족한 것이 무엇이며, 준비해야 할 것이 어떤 것이며, 어떻게 그 곳에 도달할지 생각하는 기회를 갖습니다.

203, 계획과 현실이 어긋나는 시점은 배움의 시작입니다. 백전노장 관리자는 계획에 영향을 준 새로운 인자가 무엇인지 알아내고, 새롭게 배운 사실을 기초로 계획을 수정합니다.

205, 미래가 현실이 되면 계획한 것과 다른 일이 많이 생기겠지만, 우리는 계획하기 덕분에 목표로 하는 곳에 더욱 효과적으로 도달할 수 있습니다.

207, 프로젝트의 핵심은 개발이 아니라 ‘고객이 무엇’을 원하고 ‘프로그램으로 해결해야 할 문제점’이 무엇인지 정확하게 파악하는 게 아닐까요?

207, 소프트웨어의 본질인 ‘눈에 보이지 않는다는 특징’ 때문에 무언가를 만들어 고객에게 전달하기 전까지 고객은 자신이 원하는 것이 진정 무엇인지, 문제의 본질이 무엇인지 알 수 없습니다.

208, 아이젠의 발견에 의하면 기분이 좋을 때 당신은 브레인스토밍을 더 잘하고 다양한 대안을 훨씬 생각해 낼 수 있다는 것이다.

208, 창의적인 사고를 팀에 불어넣기 위해서 팀원들은 기분 좋게 만들어 줘야 합니다.

212, 정해지지 않은 것이 많았던 개발 기간에는 창의적이고 자유로운 사고가 중요했다면, 대부분의 것이 정해지고 마감해야 하는 프로젝트 막바지에는 집중력이 필요합니다.

215, 어떤 사람은 V모델이 죽었다고 선언하기도 하지만, V모델이 시사하는 의미는 아직도 유요합니다. V모델은 개발이 진행되면서 앞의 단계로 돌아가기 위해서 많은 비용을 지불해야 한다는 것을 알려줍니다.

221, 사람의 실수로 일어나는 사건을 막으려면 조직엔 시스템이 필요하죠. 그러나 100퍼센트 오나벽한 시스템은 존재하지 않습니다. 완벽하지 않은 시스템을 계속해서 보완하고 발전시키려면 실수를 대하는 조직문화가 중요합니다.

222, 따라서 불완전한 인간이 완벽을 추구하는 프로젝트에서 중요한 것은 실수한 것을 책망하기보다 실수가 반복되지 않게, 실수에서 많은 것을 배울 수 있는 분위기를 만드는 것입니다.

223, ‘문서화’는 ‘현재의 나’를 위한 것보다는 ‘미래의 나’ 더 나아가서 동료, 조직 그리고 회사를 위한 행위입니다.

223, 문서화를 달가워 하지 않는 환경에서 조직의 경험을 조직의 자산으로 남기기 위한 다른 방법은 내재화입니다. 즉 조직원의 뇌리에 조직의 경험을 심어 놓는 것입니다. 내재화는 교육, 학습, 팀 활동으로 이루어집니다. 이 가운데 팀 활동, 즉 ‘회고’가 효과적입니다.

234, 자신의 태도와 행동이 상반될 때 이를 일치시키기 위해 태동를 바꾸든 행동을 바꾸든 해야 하는데, 태도는 다른 사람이 모르지만 행동은 이미 다른 사람이 알고 있으므로 행동에 맞게 태도를 바꾸게 된다고 한다.

236, 0.5Man Month를 경계하라

237, 첫째, 건축업처럼 일의 범위가 정확하지 않습니다.

237, 둘째, 콘텍스트 스위칭 비용이 비쌉니다.

244, 개발 환경과 실전 환경이 다르다면 개발을 끝내고 실전 환경에서 테스트해야 합니다.

244, 하지만 소프트웨어 개발에서 은총알은 존재하지 않습니다. 따라서 생산성을 높이는 ㅂ아법은 개발자가 업무에 집중하게 하는 것입니다. 즉, 고객에게 가치를 주는 것을 만드는 작업만을 해야 합니다.

246, 반복적인 작업은 대개 부가가치를 창출하지 못합니다. 반복적이면서 부가가치도 창출하지 않는다면, 그런 업무는 최대한 자동화해야 합니다.

249, 설계자들이나 개발자들이 하기 쉬운 실수는 전체를 고려하지 않은 부분 최적화입니다.

249, 부분 최적화의 폐해를 막으려면 전체적인 관점에서 일정과 과업을 조율하는 팀장이 필요합니다.

251, 팀장이 바쁘면 프로젝트 망해요.

253, 일손이 모자랄 때 팀장이 프로그램을 짜야 할까? 라는 물음에 정답은 상황마다 다릅니다. 어쩔 수 없이 이롯ㄴ이 모자라 팀장이 프로그램을 작성해야 할 때도 있지만, 그럴 때에도 팀장이 프로그래머로서 일하기 전에 관리자로서 역활에 충실했는지 스스로에게 물어봐야 합니다.

256, 일을 할 때 총량의 부족을 추구하며, 사람을 대할 때 완벽한 사람이란 존재하지 않는다고 믿는 것. 즉, 상대적인 2프로 부족 덕분에 부족한 팀원이지만 가능성을 발굴하고, 우울한 프로젝트 현실이지만 희망을 발견할 수 있습니다.

257, 팀장은 프로젝트를 하면서 긍정적인 면만을 바라보는 경향이 있습니다. 팀원은 부정적인 면을 바라보곤 합니다.

258, 자발적이고 생명력이 넘치는 팀을 만들려면, 팀원의 의견을 지지해주고 한걸음 더 나가 팀원의 생각대로 실행하도록 도와주세요. 팀원의 ㅅ애각이 틀렸다면, 좋지 않은 결과가 생길 것입니다.

261, 제가 아는 부지런함은 아는 것을 매일같이 꾸준히 실천할 수 있는 능력을 말합니다. 1초라도 쉬지 않고 열심히 일하는 돌쇠 같은 부지런함이 아닙니다. 지행일치, 즉 아는 것과 행동하는 것을 일치시키려는 노력을 부지런함이라고 부르겠습니다.

262, 팀장은 고객의 요구사항을 파악하려는 부지런함과 좋은 결과를 내는 습관을 실천하려는 부지런함이 필요하며, 팀원들이 힘들어 하는 문제점이나 고민을 해결해 주려는 부지런함을 갖추어야 합니다.

263, 좋은 관리 기법을 알고만 있는 게 아니라 실천한 사람들이죠. 자신이 옳다고 믿는 것, 팀원에게 최선이 되는 것을 항상 실천하려는 부지런함이 초보 팀장을 훌륭한 관리자로 탈바꿈시켜 줍니다.

268, TDD가 테스트 통과라는 목표를 제시함으로써 개발 생산성을 높이는 것처럼. 일을 할 때는 무엇을 위해 일을 하는지 고민해 봐야 해. 즉, 보고서를 작성하는 경우라면 보고서를 만드는 목적이 무엇인지 가장 먼저 고민해야겠지. 그런 의미로 본다면 보고서를 만들 때는 목표 주도 문서작업 같은 게 필요하겠지.

274, 아군과 적군이 구별되지 않는 전투 상황 속에서 초보 팀장님들, 무엇을 해야 할까요? 바로 팀원을 무사히 이끌어 낙오자 없이 프로젝트 완료 고지를 점령하는 것입니다. 이렇게 바라 본다면 시련으로만 보이는 사내 정치 속에서 한줄기 희망을 발견할 수 있답니다.

276, 시스템을 설계하는 조직들은 자신들의 조직 사이에 의사소통 구조를 모방한 형태의 설계를 만들곤 한다.

-콘웨어의 법칙

277, 제품이 좋다는 것은, 그 제품을 만드는 회사의 ‘의사소통 구조’가 훌륭하다는 의미죠.

279, 팀장이 갖추어야 할 여러 가지 덕목 중 한 가지가 바로 협상력입니다.

280, 협상의 기본은 정보라고 말했습니다. 스펙 늘리기와 스펙 줄이기의 줄다리기 협상에서 정보는 무엇일까요? 바로 개발명세서와 개발명세서에서 산출된 공수 그리고 개발 계획입니다.

284, 조직의 분위기와 구성원입니다. 두 가지 환경의 조합에 따라서 나쁜 관리가 자라나기 좋은 호나경이나 좋은 관리가 자라나기에 안성맞춤인 분위기가 됩니다.

285, 뛰어난 팀장도 어떤 상위 관리자를 만나느냐에 따라 다른 성과를 냅니다.

289, 가치와 이익은 동전의 앞면과 뒷면처럼 처음부터 끝까지 부합할 수도 있고, 반대로 너무나 상반돼서 편도 차선에서 마주보고 달려 오는 자동차처럼 끝이 뻔한 파국을 맞이할 수도 있습니다.

290, 일종의 화두인 셈입니다. 화두의 의미는 생각의 단초입니다. 생각의 흐름을 놓지 않는 끈입니다. 가치의 연쇄입니다. 그렇기 때문에 적절한 답을 구하려면 적절한 질문을 던져야 합니다. 그래서 전 “진정한 프로젝트의 가치는 어디에서 오는 것일까?”라는 질문을 던져봅니다.

290, 이 시간에도 개인과 개인, 조직과 조직이 만납니다. 그리고 프로젝트가 생깁니다. 그렇다면 진정한 가치는 어디에서 오는 것일까요?

Ⅲ. 내가 저자라면

개인적으로 신승환이라는 작가에 관심이 많다. 그가 쓴 책이 감동적인 것은 아니지만 내가 원하는 비슷한 길을 먼저 걷고 있기 때문이다. 그는 IT이야기를 어렵게 하지 않는다. 대신 적절한 메타포를 이용하여 쉽게 설명해준다. 비전공자가 흥미를 가질 정도로 재밌는 주제는 아니지만, IT계통의 사람들이라면 아주 재밌게 읽을 수 있을 것이다. 그 아슬아슬한 줄타기를 잘하고 있는 것처럼 보였다.

이 책을 통해 내가 책을 쓴다면 어떻게 써야할지 많은 고민을 했다. 전문적인 책을 써야할지, 재밌는 책을 써야할지. 두개를 다 가질 방법은 없는지 생각해보았다. 컴퓨터 이야기를 일반인들도 흥미를 가질 수 있는 방향이라는 진정 있는 것인지도 고민했다.

하지만 저자를 알아가면서 최근에 그가 IT쪽을 완전히 벗어난 책을 집필하기 시작하는 것 같던데 이 부분은 꽤나 아쉬웠다. 식어가는 출판시장 때문이겠지만, 그가 뜻을 굽힌 이유가 무엇인지 궁금했다.