글

라벨이 실패인 게시물 표시

개발팀장이 되면서 겪게된 점들 1

이미지
                                                         <팀원을 모집하기 위해 고군분투하는 모습이다. > 첫 한달  개발팀장을 맡다 2021년 5월 , 기존에 있던 CTO분이 휴직(개인사)을 하게 되면서    개발에 대한 모든 권한을 내게 일임하였다.   개발에 대한 모든 의사결정을 전부 내게 맡긴 것으로 ,   어느 정도 규모가 있는 회사의 의사결정권한을 갖게 된 것은 그만큼 내게 큰 신뢰가 있었음을   알수 있게해주는 대목이었다. 그러나 전혀 예측하지 않았던 상황이기에 준비가 되어있지 않았던만큼 처음에는 삐걱거렸다. 가장 첫번째로 어려움을 겪었던 것은 업무의 배분이었다.   관리자가 되니까 해야할일은 업무를 만들고 또 그것을 팀원들에게 분배하고 잘 되고있는지 취합하고 관리감독을 하는것이었다.   군 시절 장교로 복무하면서 겪어봤던 일이긴 했지만, 군복무 당시에도 그닥 잘 하지는 않았던 것 같다.   그럼에도 어쨌든 전반적인 시스템을 이해하고 있었고, 어떻게 구현해야할지에 대해서는 어느정도 경험이 쌓여있었기때문에 큰 문제가 없을 줄 알았다.   실무자로 일을 할 때에도 항상 업무를 받아서 하지는 않았다. 스스로 돌이켜보건대, 나는 주어진 업무가 없으면 스스로 만들어서 제안하고 기획하여 업무를 진행했다.  조그마한 스타트업이었던 첫 회사에서부터  내가 할일은 내가 만들어서 곧 잘했다. 어떤 큰 방향만 정해져있다면 그건 큰 어려움은 아니었다. 나에게 일은 항상 있었다.   매니저가되면서 달라진게...

점검표를 왜 만드는 것인가 ?

이미지
자주 이용하는 카페의 화장실에서 점검표를 발견하였다. 상호를 가리기위해 연도 칸을 잘랐지만, 날짜는 2016년으로 되어있다. 전형적인 불필요 행정업무이다. 이 점검표를 보고 시행여부 판단하는 것은 굉장히 어려운 일이다. 화장실을 둘러본 바 굉장히 청결하고, 잘 정리가 되어있다. 지금까지 이용하면서, 한번도 더럽다고 느껴본적이 없다. 도대체 제대로 쓰지도 않는 왜 이런 점검표를 만드는 것일까? 꼭 필요한 것인가? 이와 관련된 경험을 하나 떠올려보며 필요유무에 대해 생각해보고자 한다. 점검표를 만드는 행위는 점검,결재의 행위로 나타낼 수 있다. 군 장교시절 이와 유사한 행위를 많이 목격했고, 수도 없이 경험했다. 결재서류에 사인을 하는 행위만으로 두어 시간을 보낸적이 있다. (확인도 안하고 결재할수도 없으니...) 덕분에 사인이 없던 내가 사인이 생길 정도였다. 점검과 결재라는 행위의 목적은 일어나는 업무사건에 대한 책임을 명시하는 것이다. 이 행위는 조직이 커질수록 수가 많아진다. 수가 많아지는 이유는 간단하다. 사건발생 -> 책임여부 확인 ->책임 불분명 - > 예방을 위한 점검체계 확립 이 프로세스 대다수는 각각 통합도 할 수 없는 독립적인 사건으로 일어난다. 하나하나 쌓인다는 것이다. 결국 군 부대 월별 계획표에는 점검업무가 50%를 차지하는 아주 기이한 현상이 나타난다. 주말빼고 20일의 업무중에서 10일을 점검만 하는 것이다.한 달에 업무 진행할 수 있는 시간은 10일뿐이다. 10일 만으로 현안업무를 제대로 수행할 수 있을까? 이는 조조출근, 야근, 주말/공휴일 업무로 이어지며, 전체적으로 생산성을 떨어뜨림은 물론이고 구성원의 사기마저 저하시킨다. 나중에는 점검업무를 제대로 하지못해, 구성원들은 미봉책으로 점검없는 결재행위를 저지른다. 점검 없는 결재행위는 전과 같이 사건을 발생시킨다. 사건 발생은 또다시 점검,결재프로세스를 만들어낸다. 악순환이다. 군에서도 이런 문제점을 직시하고 행정간소화...