강력하게 어필했지만 새로운 기술을 배우는 것을 싫어하는 문화에 부딪혀서 실패.
혼자만 쓰면서 어필했더니 이제 전체 회의 때 쓰는 것으로 지정.
잠시 자리를 비운 사이에 다른 영향력 있는 분이 오셔서 한순간에 트렐로 보고가
다시 문서 보고로 사라짐.
그 분이 가르치는 학생들이 전부 트렐로를 써서 다시 부활의 조짐. 그러나 이미 새로운 기술을 싫어하는 사람들의 반대에 다시 부딪힘..
트렐로를 쓰자는 헛심일수도 있지만, 소프트웨어 공학을 공부하다 보니 따로 공부를 하는 것보니 툴 중심으로 생각만 해도 업무 형태가 많이 바뀌는 경험을 한다.
우선 트렐로를 쓰면 원격으로 일할 기본 조건과 업무를 더 잘하는 사람에게 편하게 넘길 수 있고 일정 조절도 쉬우 경험을 하게 된다. 이게 칸반이던... 익스트림프로그래밍이던, 애자일의 정수던 , 변형된 워터폴 방식이던 그건 중요치 않다.
개발자는 충분히 소프트웨어 공학을 공부할 시간도 없고, 이론가의 책을 보면 두껍게 그지 얺는데 실제 이론가들이 제대로 만든 솔루션이란게 존재하지도 않는다.
큰 기업이라면 이론가를 앉혀두고 실제 개발하는 코더들과 계속해서 충돌을 일으키는 것 자체가 좀 더 나은 산출물을 나오게 하겠지만 작은 곳에선 그럴 필요도 없다. 툴 중심으로 가는게 맞다.
기왕 이렇게 된거, 그냥 나를 따르는 후임 2명과 쓰기로 했다. 어차피 시간이 지나면 전체적으로 쓸 것은 뻔하고 그 때 반대하는 사람들이 분명 자기 생각 때문에 했다고 글로리를 가져갈 것은 불보듯 뻔하기 때문이다. 누가 잘되면 회사만 잘되면 된다는 생각은 버리자. 대중소기업 스타트업을 다 경험했는데 윗 사람은 아랫사람이 자신이 받는 50%의 월급을 가져가는 것도 싫어한다.(그나마 이건 대기업이 더 젠틀하다)
서론이 길었는데 이 생각은 무수하고 복잡한 정치환경 속에서도 통한다고 봐야 한다.
먼저 쓰고 잘 쓰는게 핵심이기 때문에.
후임2명이 쓰면서 카테고리를 어떻게 만들어야 할지 고민하더라.
일단 무조건 PLAN DO SEE 를 만들라고 했다. 스스로 업무를 정의하고 실행하고 일정잡고 피드백도 생각하라는 의미였다. 트렐로를 회사에 안착시키는데 1년이 걸렸는데 그나마 이걸로 잘 사용하던 친구는 병특이라 군대를 가버렸다. 그 친구는 PLAN을 스스로 짜는 친구인데 다른 친구들은 아니라는 생각이 든다. 여러번 일을 시켜도 자꾸 겉으로 보이는 업무에만 치중해서 대표님이 보실 때도 딱히 분주하기만한 상황이 연출되기도 하기 때문이다. 그도 그럴 것이 신뢰가 깨진 상태에서 충돌을 피하는 사람이 많아져서 모두 방자를 통하는 상황이 연출되기 때문이다.
이럴 때 쓸 수 있는 것은 SAR 인 것 같다. 자신이 처한 상황을 정의하고, Action을 취하는 것. 사실 PLAN DO SEE와 다른 것은 PLAN이 상황으로 바뀌는 것 뿐이다. 그러나 CEO가 아닌 이상 판을 짜는 것은 금지되어 있다. 카카오에서는 이를 헌신으로 포장하지만 결국 결정권은 없다는 것이다. 잘났으면 사장하라는 말처럼 미치지 않은 사장이 아니고서야 기업에서 이미 정해져 있는 진리기도 하다.
댓글 없음:
댓글 쓰기
국정원의 댓글 공작을 지탄합니다.