Clean Coders 책 챕터 2 - Saying No 좋은 문장들
Intro
“프로들은 매니저들에게 ‘안됩니다’라고 말할 수 있는 용기를 가지고 있습니다”
“노예들은 ‘안됩니다’라고 말할 수 없습니다. 노동자는 ‘안됩니다’라고 말하기 꺼려할 겁니다. 하지만 프로(전문가)들은 ‘안됩니다’라고 말할 수 있는 사람이여야합니다”
Adversarial roles
“매니저와 당신, 양쪽 모두가 각자의 임무를 완수하기 위해 최선을 다 해야만 ‘최선의 결과’를 얻을 수 있습니다” (매니저는 시간을 완수해야하고, 개발자는 좋은 제품을 만들어야한다)
케이스 1:
매니저: “내일까지 A 기능을 만들어주세요”
개발자: “내일까지요? 흠, 해볼게요”
매니저: “좋아요, 고마워요!”
“여기서 매니저는 ‘해볼게요’를 ‘만들겠습니다’로 인지했습니다. 멍청한 생각이에요. ‘정말 내일까지 만들 수 있나요?‘라고 했었어야합니다”
케이스 2:
매니저: “내일까지 A 기능을 만들어주세요”
개발자: “시간이 더 필요할 것 같은데요?”
매니저: “얼마나 더 필요한데요?”
개발자: “2주 정도면 어떨까요?”
매니저: “좋아요, 2주 후에 봅시다”
“개발자는 2주면 괜찮을지 물어볼 것이 아니라, 정확하게 ‘2주 걸릴 것 같다’라고 얘기했어야합니다. 매니저는 이 2주라는 시간을 질문도 없이 그대로 받아드리면 안됬습니다.”
케이스 3:
매니저: “내일까지 A 기능을 만들어주세요”
개발자: “안됩니다. 그건 2주짜리 개발 업무에요”
매니저: “2주요?? 아키텍트들은 3일을 예상했는데, 벌써 5일이나 지났잖아요!”
개발자: “아키텍트들이 잘못 예상한거에요. 3일을 예상했던 작업은 지난번 마케팅 회의 때 요구사항이 뒤엎어졌어요. 새로운 요구사항은 아직 최소 열흘은 더 걸립니다. 위키에 업데이트 해놨는데, 안보셨어요?”
매니저: “(부들부들대며) 이건 말도 안돼요. 고객들은 당장 내일 데모를 보기를 원한다구요. 그리고 이 A 기능이 작동해야한다구요.”
개발자: “A 기능의 어떤 부분이 필요한데요?”
매니저: “A 라는 기능 자체가 필요하다구요!”
개발자: “A의 기능을 보여주는 mock-up 기능을 만들 수는 있어요. 실제 서비스되는 A 기능에 필요한 서버 기능, 쿠키 데이터 저장, 보안 체크, 데이터베이스 통신과 같은 기능은 작동하지는 않겠지만, 데모에 필요한 필수 클라이언트 기능들은 작동하는 모습은 보여줄 수 있습니다. 이건 어떨까요?”
매니저: “A가 작동하는게 보여진다구요?”
개발자: “네, 고객들 입장에서는 작동하는 것 처럼 보여질거에요”
매니저: “완벽합니다! 고마워요! (내적 “예쓰으으!!”를 외치며 자리를 떠남)
“양쪽 모두가 각자의 임무를 지키려고 함으로써, 양쪽 모두가 원하는 바를 얻는 ‘최선의 결과’를 얻었습니다.”
“제 경험 상, fact가 why보다 더 중요합니다.”
High stakes
“‘안됩니다’라고 말할 수 있는 가장 중요한 때는 사활이 걸려있을 때 입니다”.
케이스 4:
(기존의 예상보다 더 개발에 딜레이가 걸린다는 사실을 알렸을 때)CEO: “이 건을 따내지 못하면 우린 진짜… 당신도 알고 있죠? 이렇게나 많이 늦어진다면… 하… 투자자들한테는 뭐라고 얘기를 해야하지… 당신, 뭐든 상관없으니 어떻게든 해봐요.”
개발자: “이미 제가 할 수 있는건 다 했어요. 대표님도 아시잖아요. 3개월 전에 개발 명세 조정을 요청했던게 거절당한거. 고객사에서는 개발 요구사항을 줄여주지도 않고, 안정성 테스트도 할 여건을 만들어주지 않는걸요. 대표님도 그 떄 고객사 편을 들어줬구요. 지금 저희 팀은 할 수 있는 모든걸 쏟아붓고 있어요. 지금 하는거보다 더 빠르게 작업할 순 없어요.”
CEO: “젠장, 당신 지금 그 말에 책임 질 수 있어요?”
개발자: “날 짜른다고 해서 개발 스케줄이 바뀌진 않아요.”
CEO: “알았어요. 지금이라도 액션을 취해볼게요. 당신은 계속 개발을 진행해주세요.”
Being a ‘team player’
“팀플레이어가 된다는건 마치 ‘내 할일도 잘 하고, 팀원이 막힐 때 도와줄 수 있는 사람’과 같은 사람처럼 들립니다.”
“하지만 사실 팀플레이이어는 ‘팀원이 원하는대로 다 해주는 사람’이 아닙니다“
케이스 5:
개발자: “팀원들과 상의해서 개발 스케줄을 새로 짜왔습니다. 8주 후면 데모를 보여줄 수 있을 것 같네요. +- 1주 정도 오차가 있을 수 있습니다.”
매니저: “안됩니다. 6주 후에 고객 데모를 진행하기로 이미 예정되어있어요.”
개발자: “우리 의견은 듣지도 않고요?”
매니저: “이미 위에서 정해진 내용입니다.”
개발자: “(한숨) 알았어요, 팀원들과 6주 안에 개발 할 수 있는 내용들로 다시 정리해올게요. 대신 기존에 상정했던 개발 요구사항에서 몇개 빠질거고, 데이터 로딩 부분은 미완성으로 나갈겁니다.”
매니저: “안돼요. 그 기능들도 다 포함되야합니다. 고객들은 완성된 데모를 보고싶어해요.”
개발자: “그건 불가능합니다. 이미 우리는 팀 리소스를 전부 투입하고 있어요.”
매니저: “젠장, 알았어요. 우선 팀원들과 상의해보고 내일까지는 계획을 공유해주세요.”
개발자: “알겠습니다.”
매니저: “이해가 안되네요. 정말 더 해볼 방법이 없어요? 좀 더 똑똑하게 일할 방법을 찾는다던지, 뭔가 창의적인 방법이 있겠죠.”
개발자: “우린 이미 충분히 창의적이에요, 매너저님. 업무 내용도 정확하게 다 파악하고 있어요. 8-9주의 시간이 필요해요. 6주는 절대 안된다구요.”
매니저: “야근이랑 휴일업무를 해도 안될까요?”
개발자: “더 느려지기만 할거에요. 지난번에 초과업무 3주 내내 하다가 팀원들 다 지쳐서 에러 투성이 코드를 릴리즈한거 기억 안나요?”
매니저: “그게 꼭 이번 릴리즈에 반복되라는 법은 없잖아요.”
개발자: “아뇨, 이번 릴리즈에 정확히 똑같이 반복될거에요. 이 부분은 저희 쪽 의견 믿어주셔야해요. 이거 다 하려면 8-9주 걸려요. 6주론 부족해요.”
매니저: “알았어요, 내일까지 계획 세워서 공유해주세요. 하지만 6주 안에 가능하게 만들 수 있는 방법도 계속 고민해주세요. 똑똑한 분들이시니까 분명 방법을 찾으실 수 있을 거에요. 이거 진짜 중요한 데모거든요.”
개발자: “아뇨, 안된다니까요. 6주짜리 계획은 세워서 줄 수 있지만, 아까 얘기했듯이 기능이 몇개 빠질거에요. 이거말고는 방법이 없어요.”
매니저: “알았어요, 하지만 우리 회사에서 제일 똑똑한 분들이신데, 분명 방법을 찾을 수 있을거에요!”
…
(오후에 있는 PM 미팅에서…)
CEO: “매니저님, 6주 후에 데모 있는거 아시죠? 고객들은 이번에 완벽한 데모를 기대하고 있어요”
매니저: “데모는 계획했던 대로 진행될겁니다. 저희 개발 팀이 엄청 열심히 일하고 있어요. 일정이 타이트해서 초과근무는 하겠지만, 다들 똑똑한 사람들이라서 잘 해낼겁니다!”
CEO: “허허, 저희 매니저님과 개발팀원분들은 팀의 목표를 이루기 위해 무엇이든 해내는 팀플레이어들이라서 너무 다행입니다”
(쓰으으으으으으으읍)
“여기서 누가 진짜 팀플레이어일까요? 팀을 위해 1. 현실을 직시하게 해주고, 2. 최선의 결과를 낼 수 있도록 각자의 임무에 충실하게 한 개발자가 팀플레이어입니다.”
“여기서 매니저는 자신의 목표 달성에만 충실했습니다. 개발자의 편도 아니였지만, CEO의 편도 아니였어요. 매니저는 CEO가 자신을 팀플레이어처럼 보기를 원했기 때문에, 개발자에게 온갖 사탕발린 말과 비꼬기 등으로 개발자를 휘두르려고 했습니다.”
“이 대화에서 개발자가 가장 잘 한 것은 ‘알았어요, 한번 해볼게요’라고 말하지 않은 것 입니다. 개발의 세계에서 ‘해본다’나 ‘최선을 다해보겠습니다’라는 말은 존재하지 않아요.”
“‘한번 해보겠습니다’라는건, 원래의 계획과는 다르게 더 어려운 목표에 도전한다는 의미입니다.”
“더 어려운 목표에 도전해서 성공할 수 있는거라면, 당신이 처음에 생각했던 목표/스케줄은 부족했던게 아닐까요?” 더 어려운 목표를 해결하기 위해서, 당신이 처음에 생각했던 스케줄과는 어떤 점을 다르게 할 건데요? 문제에 대한 접근 방법이 달라지나요? 마인드셋이 달라지나요? 당신이 ‘해보겠다’라는거로 어떤 점이 달라지는데요? “
“‘최선을 다 해보겠습니다’라는 말은, 평소에는 대충한다는 뜻인가요? 평소에 아껴둔 에너지를 이번에 쓰면 목표를 달성할 수 있는건가요? 그게 아니면 당신은 그냥 지키지 못할 약속을 하는게 아닐까요?”
“새로운 계획도 없고, 새롭게 문제를 해결할 접근법도 없고, 추가로 가용할만한 에너지도 없고, 처음에 세웠던 계획에도 자신감이 있었다면, ‘해보겠습니다’나 ‘최선을 다해보겠습니다’와 같이 ‘약속‘을 하는 행위는 단순히 ‘거짓말’을 하는 행위에 불과합니다. 논쟁을 피하고 싶어서 하는 거짓말이죠.”
Passive aggression
케이스 6:
매니저: “저희 데모가 3주 앞으로 임박했습니다. 고객들은 기능 A.12를 보기 원해요”
개발자: “매니저님, 그건 저희가 개발하기로 협의한 기능이 아니잖아요.”
매니저: “알아요. 근데 고객들이 보고싶어합니다.”
개발자: “(한숨) 알았어요. 그러면 기능 A.11이나 A.13은 데모에서 제외해야합니다. 시간이 부족해요”
매니저: “절대 안됩니다. 고객들은 그 기능들도 보고싶어해요.”
개발자: “이정도면 그냥 모든 기능을 다 보고싶다는거 아니에요? 이건 안된다고 이미 몇번이나 말씀드렸잖아요.”
매니저: “미안합니다. 하지만 고객들이 마음을 바꾸지 않는걸요. 모든 기능들을 다 보고싶어해요.”
개발자: “안됩니다 매니저님. 이건 진짜 안돼요.”
매니저: “진짜 왜 그러는거에요? 고객들이 원한다구요. 시도는 해볼 수 있잖아요?”
개발자: “매니저님, 제가 공중부양을 하는걸 시도해볼순 있죠. 납을 금으로 바꾸려고 시도해볼 수도 있구요. 태평양을 수영해서 건너는걸 시도해볼 수도 있어요. 근데 제가 성공할거 같아요?”
매니저: “이제는 말도 안되는 소리나 하고 있군요. 제가 불가능한걸 요구하는거도 아니잖아요.”
개발자: “아뇨 매니저님. 지금 불가능한걸 요구하고 계셔요.”
매니저: “(장난조로 웃으며, 뒤 돌아 자리를 떠나며) 개발자님 진짜 개그센스가 좋으시네요. 잘 하실 수 있는거 다 알아요. 조금만 더 고생 해주세요.”
개발자: “(멀어지는 매니저를 향해 말하며) 진짜 안된다니까요? 이렇게 피하기만 하면 진짜 안 좋게 끝날거에요”
“이제 개발자는 결정을 내려야합니다. 개발자는 이제 당연히 매니저가 CEO에게 새 개발 계획을 공유하지 않았을 것이라는걸 알아요. 아마 매니저는 CEO에게 개발자가 약속된 일정을 지키지 못했다고 얘기하겠죠. 여기서 개발자는 2가지 방법을 택할 수 있습니다”
“첫째는 매니저가 알아서 죽도록 놔두는 겁니다. 문제가 터졌을 때, 개발자는 지금까지의 위키 업데이트, 대화 메모, 주변 사람들의 증언등을 모아 ‘몇번이나 매니저에게 이야기했다고’ CEO에게 알리는 겁니다.”
“둘째는, 지금 바로 CEO에게 가서 이야기하는 겁니다. 물론 여기에 리스크가 있지만, 이 방법이 진정으로 팀플레이어가 되는 방법입니다. 저기 멀리서 폭주기관차가 우리를 향해 오고있다는걸 당신만 인지하고 있다면, 혼자만 레일에서 내려오는것보다는, 모두가 도망칠 수 있게 알리는게 팀플레이어입니다.”
케이스 7:
개발자: “매니저님, CEO님에게 개발 일정을 공유드렸나요? CEO님이 고객들에게 A.12 기능은 작동하지 않을 거라고 알렸나요?”
매니저: “개발자님, 지난번에 그거 개발하기로 했잖아요.”
개발자: “아뇨 매니저님, 안된다고 분명히 말씀드렸어요. 불가능하다고 말씀드렸고, 그 때 저희 얘기했던 회의록도 있어요.”
매니저: “그랬죠, 근데 그래도 시도해보겠다고 했잖아요?”
개발자: “그 때 대화 기억 안나요? 태평양 수영?”
매니저: “(한숨) 개발자님. 이건 진짜 어쩔수 없이 그냥 하셔야해요. 어떤 수단과 방법을 써도 되니까, 이거만큼은 절 위해서라도 꼭 해주셔야해요.”
개발자: “아뇨 매니저님. 제가 매니저님을 위해서 이걸 해야할 이유는 없어요. 제가 해야하는건, 매니저님이 직접 안하신다면, CEO님께 이 상황을 알리는거에요.”
매니저: “진짜 말도 안되는 소리 하지 마세요. 안 그러실거잖아요.”
개발자: “저도 그러고 싶진 않아요. 하지만 매니저님이 저를 그렇게 만들고 있잖아요.”
매니저: “아, 제발”
개발자: “매니저님. 그 기능들은 시간에 맞춰서 개발을 못해요. 이걸 제대로 알아주셔야해요. 저보고 일을 더 하라고 하지 마세요. 제가 어떻게 마법을 부려서 해낼거라고 믿는거 그만두셔야해요. 제대로 현실을 보고 CEO님에게 알리세요. 오늘요.”
매니저: “(크게 눈을 뜨며) 오늘?!”
개발자: “네. 오늘요. 왜냐면 내일 CEO님과 제가 데모에 들어갈 기능을 리뷰하는 미팅을 잡아놨거든요. 내일 이 미팅 전에 말씀드릴거 아니면, 제가 직접 말씀드릴 수 밖에 없어요.”
매니저: “당신 지금 이게 말이 된다고 생각해? 당신 밥통만 챙기면 다야? 일도 제대로 안하면서”
개발자: “매니저님, 저 지금 우리 둘 모두의 밥통을 챙기는거거든요? 고객들이 다 모시고 그 앞에서 데모 터지는 꼴 보고 싶으세요?”
“지금까지 개발자는 프로답게 행동했습니다. 매니저가 개발자를 가스라이팅하고, 모욕하고, 업신여기고, 떄로는 빌면서 부탁을해도 현실만을 직시하며 ‘안됩니다’라고 얘기했습니다. 또, 개발자는 매니저가 가지고 있는 환상을 깨부셔주었습니다”.