프로그래머 필독서 피플웨어(내용은 좋지만 책의 내용을 실현시키기 위해서는 고민을 해봐야 할 책)

피플웨어

프로그래머 필독서로 유명한 피플웨어라는 책을 읽어 보았다.

우선 이 책의 경우 사원급인 내가 읽고 실현을 해보기에는 너무나도 내 경력과 직급이 낮기에 실현이 불가능하다라는 생각이 들었다.  왜 직급이 낮은 사람이 읽어보고 실현이 불가능하다는 생각이 들었냐고 묻는다면 인적관리에 해당되는 내용이 상당히 많기 때문이다. 개발자가 효율적으로 일하기 위해서는 조용한 공간을 만들어줘야한다. 사무실 경비절감은 좋지 않은 결과를 가져온다. 전화를 받는 행위는 몰입을 방해하기 때문에 전화를 받지 않게 해야한다. 사내방송은 집중을 방해한다. 등과 같은 다양한 내용들이 적혀있다.

 

하지만 위와 같은 내용들은 일개 사원급이 해결할 수 없는 부분이다. 회사의 일개 사원급 개발자가 효율적으로 일하기 위해서 개발자들에게 조용한 공간을 만들어 줄 수 있는가? 사원급 개발자가 개발자들이 개발을 하는 도중에 전화를 받지 않을 수 있게 해줄 수 있는가? 엄청나게 젊고 다양한 의견들을 수용하는 회사가 아니라면 대부분의 경우는 수용 할 수 없을 것이다. 물론 회사에 건의는 해볼 수 있겠지만 회사에 이러한 사항들을 건의한다고 회사 측에서 수용을 해줄까? 위에서도 이야기 한 것처럼 이 책에서는 경비절감에 대해서도 이야기를 하지만 아마 사무실의 구조를 바꾼다던가, 책상을 교체한다던가 하는 행위에 대해서는 경비가 발생하기 때문에 회사측에서 수용하지 않을 가능성이 상당히 높다.

 

SI프로젝트를 하는 곳에서는 더더욱 실현이 불가능하다고 생각이 된다. SI프로젝트의 경우 장기적으로 보는 것이 아니라 단기적으로 빨리 개발만 하고 프로젝트를 끝내는 것이 중요하기 때문에 아마 관리자들에게 개발을 하는 도중에는 말을 걸지 말게 해달라, 사내방송을 꺼달라 등의 건의사항은 수용될 확률이 정말 낮다고 생각된다.

 

이 책을 읽고 실현은 할 수 없겠지만 프로젝트 관리자들이 어떠한 방향으로 나아가고 있고 프로젝트가 어떻게 흘러가고 있는지는 어느정도 가늠할 수 있다. 나의 경우에는 SI프로젝트를 하고 있어서 그런지 모르겠지만 우선 관리자들이나 연륜이 많은 개발자들이 상당히 잘못된 방향으로 나아가고 있다는 것을 알 수 있다. 개발실력과 개발경력은 비례하지 않는다는 이야기를 많이 들어보았을 것이다. 공부를 꾸준히 하고 있는 개발자가 아니라면 개발경력 3년차와 20년차의 실력차이는 크게 없다. 여기서 꾸준히 공부한 초급개발자와 꾸준히 공부한 고급개발자는 실력차이가 많이 나지 않느냐?라고 반문 할 수 있을 것이다. 하지만 실제 프로젝트에 투입되어 개발자들과 이야기를 해보면 따로 공부를 하는 개발자는 정말 보기 드물다. 그러므로 개발 경력 3년차와 20년차의 경우 생산성 측면에서 그다지 차이가 나지 않는다고 생각하는게 타당하다. 하지만 SI프로젝트의 경우에는 개발경력에 따라 생산성 차이가 많이 난다고 가정을 하기 때문에 개발경력에 따라 초급, 중급, 고급, 특급으로 나누어 급에 따른 생산성을 잡고 프로젝트 일정을 만든다. 

 

이렇게 경영학적으로 일정을 산출하게되면서 문제가 나타난다. 특급이면 업무생산성 300이고 고급이면 200 중급이면 150 초급이면 100 이러한 방식으로 일정을 잡게되는데 실제 프로젝트를 진행하면서 사람들을 지켜보게 되면 특급이거나 고급과 특급 사이에 있는 고연령 개발자들이 생산성이 초급과 크게 다르지 않다고 생각된다. 2021년 현재 거의 은퇴를 직전에 둔 개발자라거나 나이가 50이 넘은 개발자들을 코볼과 같은 옛날 개발 언어에 익숙해져 있는 사람들이기 때문에 현재 한국에서 많이 쓰이는 자바와 같은 언어를 잘 다루지 못한다. 오히려 대학교를 갓 졸업하고 프로젝트에 투입된 개발자들보다 생산성이 떨어진다고 할 수 있다.

 

이 책에서는 처음부터 좋은 인재를 찾는 것이 제일 중요하다고 이야기 한다. SI프로젝트에서 좋은 인재를 찾으려면 어떻게 해야할까? SI프로젝트에서 개발자의 개발실력을 가늠하기란 어렵다. 개발실력을 보고 그 사람을 데리고 오는 것이 아니라 단순히 경력만 보고 그 사람들 데려오는 SI프로젝트의 방식 때문에 그 개발자가 실제 현장에 투입되서 개발을 하기 전까지는 개발을 잘하는지 못하는지는 알 수 없다. 그렇다면 개발을 잘하는지 못하는지 알 수 없는 개발자가 현장에 투입된 이후에는 무엇을 보아야할까? 바로 개발자의 인성과 적극성이라고 보면 될 것 같다.

 

인성과 적극성이 좋지 않으면 그 개발자는 프로젝트에서 하차시켜야한다고 나는 생각한다. 하지만 프로젝트가 진행되다 보면 처단해내고 싶어도 처단 할 수 없는 상태가 나타난다. 고급 개발자를 데리고 왔고 개발기간이 어느정도 지나게 되었다고 가정하면 해당 고급개발자는 어느정도 해당 프로젝트의 개발능숙도와 업무지식을 가지게 되는데 프로젝트 관리 측면에서 해당 개발자를 프로젝트에서 하차시키기에는 상당한 리스크라고 생각하고 해당 고급개발자가 인성도 좋지 않고 적극성이 없어도 그냥 데리고 프로젝트를 진행시키는 경우가 많다. 하지만 이러한 경우 최대한 빨리 그 개발자를 프로젝트에서 하차시켜야한다.

 

인성도 별로고 적극성도 별로인 말그대로 인품이 별로인 개발자를 데리고 있으면 어떠한 악영향이 나타날까에 대해 생각해보면? 팀원 자체에 피해를 끼치게된다. 나의 경우에도 우리 팀에 특급 개발자로 온 사람이 1명 있다. 인성도 별로고 적극성도 별로고 성격도 더럽다. 이러한 개발자가 팀원으로 있게되면 우선 팀워크라는 것이 사라지기에 개발의 효율성이 상당히 떨어진다. 해당 개발자랑 이야기를 하기가 싫다보니 나의 경우에도 디자인패턴을 이용하여 공통으로 사용 할 기능을 만들었지만 해당 개발자에게 내가 만든 이 기능을 써라라고 이야기가 하기 싫어서 다 같이 사용 할 수 있는 기능을 혼자서 사용하게된다. 또는 성격이 더러운 개발자가 공통 기능이랍사고 어떠한 기능을 만들었는데 기능이 조금 미흡하여 수정을 해달라고 하면 자기가 만든 기능에대해 폄하 한다고 생각하는지 수정해주지도 않고 성질만 낸다. 따라서 그 공통의 기능은 사용되지 않고 내가 다시 그 기능을 새로 만들어 사용하게 된다. 이런식으로 일이 진행되다보니 개발속도가 뒤쳐질 수 밖에 없다.

 

인성도 별로고 적극성도 없는 개발자가 얼마나 프로젝트에 악영향을 끼치느냐에 대해서는 "소프트웨어 장인"이라는 책에서 보았던 것 같다. 내 기억이 맞다면 아마 3년이 걸려도 프로젝트가 끝나지 않아 그 프로젝트를 분석해보니 개발자들이 문제였고 거기서 일하던 개발자들을 다 내보내고 다른 팀이 와서 개발을 했는데 6개월만에 끝났다고한다. 이전 개발자들이 3년동안 익힌 개발능숙도와 업무지식은 개발자의 적극성에 이기지 못했다. 매일 문제를 일으키고 있는 개발자를 계속 데리고 있다면 프로젝트가 좋지 않은 방향으로 나아가고 있다고 추론 할 수 있다.

 

피플웨어에서는 공동체에 대한 내용도 나오는데 관리자는 팀원들이 공동체 의식을 가지고 서로 재미있게 일 할 수 있는 환경을 만들어주어야한다고 한다. 재미있게 일 할 수 있는 환경을 만드는 조건 중 하나가 아마 위와 같이 팀 전체에 악영향을 미치는 개발자를 처단하는 것도 조건에 들어가지 않을까 싶다. 일 안하고 성격 더러운 개발자를 아무리 다독여도 효과는 없을테니 말이다. 사람은 바뀌지 않는다.

 

초과근무를 하고 있다면 악순환의 시작이라고 생각해야한다. 대게 초과근무를 하는 이유는 프로젝트가 제 시간에 끝나지 않았을 때 비난을 모면하기 위해서라고 보면된다. 초과근무를 한다고 하여 그 시간만큼 업무 생산성이 증가하지는 않는다. 오히려 개발자의 사기는 죽고 업무생산성은 떨어지기 시작하고 프로젝트를 하차하는 개발자가 나타나기 때문에 프로젝트의 위험요소가 증가한다고 봐야한다. 개발자와 같은 지식노동자에게는 시각적 감시가 필요없다. 집중을 한 시간이 제일 중요하다. 하지만 대부분의 관리자들은 초과근무와 같은 단순 노동시간을 제일 중요하게 생각한다.

 

이 책을 읽으면서 느낀점은 프로젝트 관리적 면에서 한참 멀었다는 것이다. 프로젝트 관리자들은 프로젝트 관리에 대한 책을 1권도 읽어본 적도 없고 프로젝트 관리적 측면에서 하면 안되는 행위를 모두 다 하고 있다. "일정이 이날까지니까 이날까지 끝내세요", "주말에 출근하세요", "잔업을 많이하세요"등 개발자의 사기를 꺽고 업무 효율성을 낮추는 행위를 참 많이하고 있다. 하지만 교육을 많이 받은 젊은층의 개발자들이 점점 더 많아지고 있고 프로젝트에 관한 논문과 데이터들은 점점 더 쌓이고 있기 때문에 미래에는 좀 더 발전해 있을 것이라 믿는다.