인생이란/생각
기능조직에서 목적 조직으로 변경 시 생각해볼 것들
기능조직에서 목적 조직으로 변경 시 생각해볼 것들
2023.07.22나는 목적 조직으로 구성된 회사는 현 회사가 처음이었다. 현 회사에서의 경험을 바탕으로 기능 조직에서 목적 조직으로 변경 시 협업 관점에서 일하는 방식이 어떻게 달라지는 지, 기존과 다름을 느끼는 포인트들을 공유해보려고 한다. 어느 조직에서나 발생 가능한 상황이라서 ‘미리 이런 부분들에 대해 조직 내 문제 인식이나 합의가 있었다면 좋지 않았을까?’ 라는 생각이 들어서 글을 써본다. 내 배경에 대해 간단히 설명하자면, 나는 백엔드 개발자로 그 동안 기능 조직으로 구성된 회사에서 일하거나 프로젝트 단위로 임시로 팀을 꾸려서 함께 일하는 형태로만 근무를 해왔다. 지금 속해있는 팀은 해결하고자 하는 비즈니스 목표/문제를 달성/해결하고자 구성된 팀이고, 팀 내에 PO/PM, 개발자, 디자이너, BA 직군이 존재한..
코딩보단 개발, 내가 되고 싶은 개발자의 모습
코딩보단 개발, 내가 되고 싶은 개발자의 모습
2021.06.20보통 사람들이 개발자가 하는 일은 주로 코딩(텍스트 창에 영어를 잔뜩 타이핑하는)이라고 생각한다. 그렇기 때문에 코딩을 잘 하는 개발자가 좋은 개발자라고 생각하는 분들도 많다. 나도 처음 개발자로서 월급을 받을 때에는 그렇게 생각했다. 요즘에는 생각이 조금 다르다. 좋은 개발자의 조건 중 코딩이 있는 건 맞지만, 코딩을 잘 한다고 해서 좋은 개발자는 아니라는 생각이 든다. 좋은 개발자가 되기 위해서는 일단, 개발자가 하는 일이 무엇인지 나열해봐야할 것 같다. 개발자에게 코딩이란? 첫 회사(SI)를 다닐 때 참석했던 회의에서 받았던 질문이 아직도 기억에 남는다. "이 화면 개발하는 데에 얼마나 걸렸어요?" 이 질문을 들었을 때 많이 당황했다. 그 질문을 한 고객과 함께 회의에 참여하고 요구사항을 논의한 게..
SI개발자가 스타트업으로 이직한 이유
SI개발자가 스타트업으로 이직한 이유
2021.01.05이 글을 쓰는 이유는 다른 사람들은 나와 같은 선택을 해야할 때 너무 고생하지 않고 결정하길 바라는 마음이다. 오랫동안 SI에서 개발하던 나는 막연하게 스타트업으로 이직을 해보고 싶었다. 기술적으로 성장하고 싶고, 실제로 사람들이 사용하는 서비스를 개발하고 싶었다는 게 첫번째 이유였다. 하지만 그 이유 하나로 이직을 하기에는, 지금 SI 개발자로서 누리고 있는 것들을 포기하는 게 너무 아쉬웠다. 그렇게 몇 달을 고민했지만 사실 어떻게 고민해야하는 지도 몰랐고, 뭘 고민해야하는 지, 누구에게 조언을 구해야 하는 지도 몰랐다. 그냥 인터넷만 뒤적거리면서 남들 생각을 들어보려고 허우적거렸다. 이것도 좋아보이고, 저것도 좋아보이고, 이걸 포기하기도 아쉽고, 저것도 놓치고 싶지 않고... 시간을 허비한 끝에 스타..
스타트업 채용 공고에 속지 말자
스타트업 채용 공고에 속지 말자
2020.11.28좋은 스타트업은 없다. 나와 맞는 회사, 나와 맞지 않는 회사, 그리고 나쁜 회사만 있을 뿐이다. 채용 공고를 보고 솔깃하기 전에 스타트업에 대한 환상을 깨고 있는 그대로 바라보자. 스타트업도 회사다 유니콘처럼 스타트업에 대한 실체없는 전설은 가득하다. 스타트업은 자유롭고, 직원 복지가 좋고, 능력이 뛰어난 자를 우대하고, 직원의 성과를 보상해주고, 수평적인 문화고, 직원들의 역량 향상을 지원하고, 새로운 기술에 항상 도전적이고, 효율적으로 조직을 운영할 거야! 스타트업이라는 단어 대신 회사를 넣어서 잘 생각해보자. 스타트업과 회사는 같은 조직체를 지칭하는 데, 스타트업에 대해서는 긍정적인 일반화가 가득하고, 회사에 대해서는 부정적인(사실적인) 일반화가 가득하다. 아래는 내가 했던 경험과 약간의 상상력을..
팀문화를 위한 작은 발버둥
팀문화를 위한 작은 발버둥
2020.11.14목마른 자가 우물을 판다. 회사의 대부분이 TF팀 형태로 그때 그때 프로젝트 구성원이 매핑된다(?). 서로 공유하는 업무 체계가 없는 상태에서 다양한 사람들과 일을 하다 보니 자연스럽게(?) 팀문화랄게 딱히 없고, 좋은 노하우와 경험이 전파되지 못하는 상황인 것 같다. 드디어 바쁘게 돌아가던 프로젝트에서 숨구멍이 트였고, 같은 업무를 하는 동료들끼리 힘을 모아 여러 시도를 시작했다. 데일리 스탠드업 미팅 아이스 브레이킹 용이기도 하고, 별다른 커뮤니케이션 비용을 들이지 않고 근황이나 업무 현황을 캐치하기 좋다. 삭막한 TF팀에서 한줄기의 빛 . 매일 5분~10분 정도로 진행하기로 했다. 주간 회고 회고를 통해 자체적인 피드백 시스템을 적용했다. (+속풀이) 현 회사에서 구성하는 묘한 TF팀은 각 팀원이 ..
협업을 위한 작은 발버둥
협업을 위한 작은 발버둥
2020.11.11협업 방식의 중요성을 깨달았다 우리 회사의 독특한 조직문화 입사 6 개월 차, 이 회사는 굉장히 독특한 조직 문화가 있다. 그것은 바로 아무런 문화가 없어 보인다는 점이다. 흔히들 체계가 없다고 말하는데, 우리 회사는 disorder나 mess의 의미가 아니라 그냥 없다. undefined에요. 초반에는 어떤 체계를 만들어가던지 회사 차원에서 시도라도 했으면 좋겠다.라고 생각했었는데, 지금은 오히려 깨끗한 상태라서 팀원 레벨에서 이러한 시도를 할 수 있으니 다행이라고 생각한다. 그리고 이번 TF팀의 동료 개발자분들도 적극적으로 참여해주었다 :) 불편했던 협업 과정, 특히 파편화된 커뮤니케이션 채널 우리 회사는 구두, 구글 행아웃(업무용 메신저), 각종 문서를 통해 협업한다. 모든 회사가 이 정도 채널들을..
개발자를 존중하는 회사 (feat. 역할별 책임)
개발자를 존중하는 회사 (feat. 역할별 책임)
2020.10.16흔히들 말한다. "우리는 개발자를 존중합니다. (그러니 오세요.)" 나는 개발자를 존중하는 회사에서 일하고 싶다. 사실 기획자든, PM이든, 디자이너든지 본인의 역할과 그에 따른 책임이 존중되는 회사에서 일하고 싶은 것은 당연하다. 서비스는 다양한 역할의 사람들이 협력을 하며 만들어지는 것이다. 서비스를 만들어가는 과정에서 각 역할은 모든 과정에 참여한다. 단지 각 역할의 책임이 다르기 때문에 서비스를 만들어가는 단계에 따라 역할별 중요성이 크고 작다는 차이가 있을 뿐이다. 각 역할을 존중한다는 것은 각자의 책임을 수행하기 위해 주도적으로 의견을 냈을 때, 그것을 긍정적으로 검토하되 그에 대한 사이드 이팩트, 혹은 추가로 고려해야 할 사항에 대해 논의하는 것이라고 생각한다. 즉, 모두 본인의 책임과 다른..
요구사항을 정의할 수 있는 역할이 명확하지 않을 때 (feat. 개발자와 조직문화)
요구사항을 정의할 수 있는 역할이 명확하지 않을 때 (feat. 개발자와 조직문화)
2020.10.14특정 기능에 대해 기획자와 PM의 의견이 달라요 최근에 있었던 일을 통해 조직 내에서 특정 책임(기획, PM, 개발)을 수행하는 역할의 구분이 모호할 때, 특히 요구사항 정의하는 기획자의 역할이 모호할 때 생기는 일을 말해보겠다. 일단 각 회사마다 직함이 같더라도 수행하는 업무가 다를 수 있으니, 현 직장에서 내가 바라본 역할과 책임에 대해 정의해보겠다. (현 프로젝트에서는 기획자와 PM을 수행하는 사람이 나누어져 있다.) 기획자 : 사용자의 니즈(건강 관리)를 충족하기 위해 필요한 기능(로그인, 출석체크, 퀴즈 등)을 정의하고, 사용성을 높이기 위해 기능 제공 방식을 요구사항으로서 정의 PM : 프로젝트의 일정과 인력 배분, 구현해야하는 기능의 우선 순위 등 프로젝트 전반을 관리 기획자가 요구사항을 정..
개발자가 서비스 운영 측면에서 커뮤니케이션 비용을 줄이는 방법
개발자가 서비스 운영 측면에서 커뮤니케이션 비용을 줄이는 방법
2020.07.28개발자는 회사 서비스에 주도적으로 기여할 수 있는 부분이 많다. 회사 내의 각 직군들은 각자의 방법으로 서비스에 기여하고 있지만, 개발자는 업무 특성상 시스템 내부에서 서비스를 바라볼 수 있기 때문에 다른 직군보다 기여할 수 있는 요소를 파악하기 쉽기 때문이다. 개발자가 서비스 운영 비용을 줄이는 데에는 다양한 방법이 있을 테지만, 이 포스팅에서는 '커뮤니테이션 비용' 측면에서 이야기해보려고 한다. 이걸 위해 엔지니어링 지식이나 엄청난 기술 역량이 필요하지는 않다. 토이 프로젝트에서도 작게 시도해볼 수 있는 부분이 많으니, 한번 생각해보자! 고객님, 잠시만 기다려주세요 김개발이 진행 중인 프로젝트에서 외부 API를 응답하는 데에 10초가 소요된다(!) User flow상 해당 API는 5분 내로 3~4번..