현재 다니는 회사가 첫 번째 회사이다.
그리고 다행스럽게도 회사분들과 아주 잘 지내고 있다. 모두들 너무 좋은 분들이기 때문이다.
모두 유머러스하고, 밝은 분들이면서 직급이 높은 분들도 소위 말하는 '꼰대'가 없다.
다만 이런 좋은 분위기에서도 문제가 없진 않다. 많은 분들이 강한 자기 주관을 가지고 있기 때문에 다소 일의 진행 속도가 느려지기도 한다는 점이다.
가장 큰 문제점은 결론적으로 회의 자체가 모두의 동의를 얻기 위한 '타협'의 방향으로 가기도 한다는 점이다. 그러나 타협은 최적의 해결책이 아니다.
혹은 반대로 모두가 반대하지만 '상사'의 결정으로 진행되기도 한다.
두 경우 모두 회의 참석자들이 만족할만한 결과는 아닐 것이다. (물론 여러 사람들의 회의에서 모두가 만족할만한 결과를 도출하는 것이 가능한지는 모르겠지만 말이다)
그리고 특히 개발자들은 '이건 도대체 왜 개발하는거지...?'라는 생각이 들게 되면 동기부여를 잃게 되는 문제점도 있다.
결론적으로 이 책에서는 '자신의 의견을 표현하되 최종 결정을 받아들이는 법을 배우라'고 한다.
받아들이는 법을 배우면 필요 이상의 스트레스와 불안을 상당히 줄일 수 있다.
최종 결정이 마음에 들지 않을 땐 받아들이기 쉽지 않겠지만 회사 전체의 책임과 부담을 떠안고 소프트웨어를 어떻게 제작해야 할지에 집중하기보다 주어진 변수 내에서 할 수 있는 최선의 업무를 하는 데 집중할 수 있으므로 일하기가 쉬워진다는 뜻이다.
개발자들은 어떤 기능을 개발할 때, "이 기능 개발의 목적이 무엇인가요?"라고 질문하기도 한다.
명확한 목적에 맞게 개발하기 위함도 있고, 우선순위가 중요하지 않음에도 불구하고 무작정 빨리 개발하려고 하는 것은 아닌지 물어보기 위함이다.
그런데 "다른 곳에도 하니까 우리도 해야하지 않을까?" 라는 대답이 돌아오면 매우 당황스럽다. '이게 진짜 현재 우리 상황에서 필요한 기능일까?' 라는 의문 때문에 현타(?)가 오기도 한다.
(열심히 다 만들었는데, 안쓰면 속상하다)
무엇이 정답인지는 아직 모르겠지만, 충분한 의견을 표현한 후에도 결정이 내려진다면 받아들이는 법을 배울 필요가 있긴 하다고 생각한다.
그리고 정말 견디기 힘들 경우(비도덕적인 일을 시킨다거나, 항상 불필요한 일만 시킬 때)는 그만 둘 수 있는 실력을 키우면 된다.
