이번 장에서는 4장에 이어서 소프트웨어 장인이 지녀야 하는 태도를 설명한다. 사실 이 책을 좀 오해했던 것 같다. 1~4장에서는 프로 정신을 강조하면서 모든 것에 적극적이고 최선을 다하라는 내용이 많았는데, 머리로는 공감됐지만 몸으론 공감하기가 쉽지 않았다. 좋은 말이긴 한데, 한정된 시간에 그것을 실천하기는 어려울 것 같아서 '현실과는 약간 동떨어진, 상위 1%의 개발자를 위한 책인가?' 싶었다. 그런데 이번 장을 읽고는 이 생각이 오해였다는 것을 깨달았다. 이번 장에서 이야기하는 '아니오'는 '과도한 업무 지시를 거부하는 것'을 의미한다.
상용화 수준에 미달되는 저품질의 소프트웨어가 될 수 밖에 없다면 주어진 조건들을 거부했어야 했다
책에 나오는 위 문장을 읽고 내가 업무를 받았었던 상황들을 생각해 봤다. 나는 소프트웨어의 품질이 저하되더라도 업무를 최대한 수용하여 기간 내에 끝냄으로써 비즈니스의 성공에 기여하려 했다. 개발자도 결국 기업에 속한 근로자이기 때문에 비즈니스를 최우선으로 생각해야 한다고 생각했다. 그런데 품질의 저하를 감소시키는 업무를 수용하는 것이 꼭 비즈니스를 우선으로 하는 것은 아니었던 것 같다. 오히려 수용하지 않는 것이 비즈니스를 위한 선택일 수 있었을 것 같다. 책에서는 업무를 수용하지 않아서 비즈니스가 성공했었던 일화를 소개해 주기도 한다. '소프트웨어의 품질에 손해가 가더라도 업무를 진행하는 것이 우리의 비즈니스를 위한 것'은 기획자를 실망시키지 않겠다는, 그리고 단순히 내 개인 시간을 조금 더 쓰면 된다는 '선의'에서 나온 생각이었다. 이게 어찌보면 무책임한 태도인 것 같기도 해서 반성하게 된다. 비지니스의 성공을 위했던 내 선의에 의해, 비지니스가 아이러니하게도 실패할 수도 있다는 생각이 든다. 무엇이 진정 비지니스의 성공을 위한 것인지 잘 판단해야겠다.
당연하지만, 일정을 맞추지 못할 경우의 결과에 대해 모두가 극도로 걱정하며 공포에 휩싸였다. 비즈니스 부서의 압력에 굴복하지 않고 우리의 결정을 고수하기는 상당히 어려웠다. 하지만 우리는 그렇게 했다. 코드의 품질 수준을 낮추고 야근과 휴일 근무를 연이어 하게 되면 모두가 지쳐 쓰러지고 프로젝트 전체가 위태로워진다. (119p)
위 내용을 보고 '만약 당분간 어느 정도 개인 시간을 포기하고 프로젝트를 완수한 후에 포기했던 것에 대한 보상을 받는 것을 약속할 수 있다면, 작가는 그러면 그 업무를 수용할까?'라는 궁금증이 생겼다. 마치 은행 대출처럼 말이다. 지금의 하루와 프로젝트가 끝난 후의 하루의 가치가 다르다면 프로젝트가 끝난 후의 하루를 미리 당겨 쓰는 것이다. (물론 그 보상의 크기가 실무자들이 만족해야 하는 수준이어야만 할 것이다!)
'아니오'라고 말할 때에도 근거를 갖춰야 한다. 근거 없는 거절은 내가 기획자라도 이해하지 못할 것 같다. 또한 말이 아 다르고 어 다르듯, 기획자가 내 거절을 수용할지 말지는 업무를 거절하는 어투에 따라 갈릴 것이다. 기획자 입장에서도 개발자의 업무 거절을 수용하는 것이 쉽지 않을 테니, 업무 거절이 수용되었을 때 개발자는 기획자에게 감사함을 느껴야 한다. 서로의 업무를 서로가 존중하면 비즈니스는 성공에 보다 더 가까워질 것이다.