CTO는 일을
쉽게 해야 합니다.
그래야, 비즈니스와 업무, 팀이 제대로 동작합니다.
CTO는 개발 전체 업무를 부드럽고 쉽게 처리해야 합니다.
그것이 가능해야 하는 이유는 간단합니다.
그렇게 해야, 개발자들 간의 의사소통과 복잡한 개발 프로세스가 원활하게 동작하기 때문입니다.
CTO는 풍부한 경험, 사전적인 고민과 대응들을 지속적으로 하고 있습니다.
대부분 개발에 대한 경험적 이야기의 반복을 통해서 자신을 단련해 왔습니다.
풍부한 경험을 가진 CTO가 아니라면,
다른 사람이 경험하게 되면 엄청 어려운 일들일 것입니다.
( 특히, 비개발자 출신의 경영자들이 보기에는.. )
.
.
.
그런데, 그렇더군요.
그래서, 쉽게 보여야 합니다.
CTO라 불리는 사람들은..
어떤 행위에 대해서 결정하는 것이 수월하고...
어떤 결정 사항에 대해서 해야 할 것과 하지 말아야 할 것들을 알고 있습니다.
초보 개발자나, 경력 10년, 20년 차 개발자들이
하는 이야기, 그들이 하고 싶은 것...
그들에게 어떤 로드맵과 어떤 방법으로
무언가를 선택할 수 있게 조언하고, 이야기하고...
즐겁게 일하는 방법을 경험적으로 알고 있습니다.
그냥 알고 있는 것들은
행하면 되는 것이고...
하지 말아야 할 것들은
하지 않으면 되는 것입니다.
소프트웨어 아키텍트나 개발 총괄로써
CTO들이 지켜야하는 철칙으로 지키는 몇 가지 규칙들을 나열해보겠습니다.
첫째. 경영진이나 개발 총괄로써 의사결정을 빠르게 한다.
회의는 짧게 하고, 개발자들의 업무는 언제나 시시각각 선택과 집중을 요구하고 있습니다. 이때에, 개발 총괄은 중요한 의사결정들에 대해서 빠르고 간결하고 정리해주어야 합니다.
물론, 말을 바꾸지 않는 것도 중요하고, 하지 말아야 할 것과, 장기적으로 해야 할 순서들을 지키도록 해야 합니다.
둘째. 휴가나 연차에 대한 자유로움을 부여한다.
분명 정해진 것들이 고, 개인의 권리입니다.
그리고, 개발자들은 필요한 시기에 필요한 만큼 업무를 충실하게 하고 있습니다.
그들이 힘들다고 하면, 그들의 이야기를 듣고..
그들을 쉬게 해야 합니다.
그래서, 그들이 선택하는 휴가에 대해서 자유로움을 부여해야 합니다.
셋째. 회식은 커뮤니케이션이 중요합니다. 부서장 과거 자랑 늘어놓는 자리가 아닙니다.
술을 마셔도 좋고, 고기를 구워 먹어도 좋고, 점심에 식사를 하는 것도 좋습니다.
가능하면, 부서장이거나 개발 총괄은 개발자들끼리 최대한 서로 간에 의사소통하고, 이야기하고, 어울릴 수 있도록 하는 것이 중요합니다.
선배라고 하더라도, 너무 많은 자신의 이야기를 하는 것은 좋은 것이 아니다.
물론, 상담을 요청하거나, 이야기를 하고 싶다고 이야기하는 경우는 조금 다른 경우죠.
하지만, 그 역시... 회식자리에서 해야 할 일은 아닙니다.
넷째. 문서 중심의 보고가 아니라, 의미 전달이 가능한 보고체계 구축
개발자들의 문서는 커뮤니케이션에 도움이 되는 수준으로 정리되는 것이 바람직합니다.
의사 결정된 내용들은 지라에 남기고, 빠르고 간결한 의사소통은 슬랙으로도 충분합니다. 여러 사람에게 보낼 의사결정들은 이메일을 활용하는 것이 좋고, 외부 멤버들과의 소통도 이메일이 적당합니다.
중요한 것은 문서를 만드는 것이 아니라, 의미 전달이 가능한 형태로 만들어지는 것이죠.
이것은 기획과 개발자들 간에도 동일한 예의가 필요한 것들입니다.
다섯째. 일하는 사람에게 유연성을 부여해야 합니다. 카페에서 일하던, 집에서 일하던...
자기 자신의 업무 통제가 가능한 사람들은 재택근무를 해도 무방합니다. 그런 개발자들과 같이 일하는 것은 정말 개발 동료들에게는 최고의 행복입니다.
그런데, 재택근무하는 개발자가 실수할 수 있다고요? 물론... 그럴 수 있죠.
다만, 그 실수들 대부분을 검토해보세요. 대부분 기획 미스이 거나, 중요한 의사결정 미스의 경우가 대부분입니다. 수시로 개발자들과 대화하지 않으면 개발이 안된다고 이야기하는 조직은...
'기획'과 '의사결정'의 프로세스가 엉망이라고 본인들이 선언하는 행동입니다.
개발자와 일하는 단계는 최소로 하는 것이, 최고의 품질을 위한 최선의 선택입니다.
여섯째. 뜬구름 잡는 모호한 업무지시가 아니라, 구체적으로 지시하는 것.
개발자는 점쟁이가 아닙니다. 마법사나 도사도 아니고요. 구체적으로 무엇을 만드는 것인가에 대해서 구체적으로 이야기를 해주거나, 청사진이나 로드맵, 구체적인 요구사항들과 성능적인 비기능적인 사항들에 대해서 이야기를 해주어야 합니다.
경영자는 목표 지향적인 비즈니스 상황과 일정, 그리고. 동료들이 일할 환경을 조성해야 합니다.
또한, 기획자는 구체적이고 구현 가능한 기획서를 제공해야 하고,
개발 총괄의 경우에는 매우 추체적인 개발 순서와 로드맵, 기술적인 단계와 아키텍처에 대한 비기능적인 사항들에 대해서 정리 정돈을 해주어야 합니다.
언제나 소프트웨어 개발자들의 열정적인 동기부여는...
모호한 그 무언가가 아니라,
구체적으로 만들고자 하는 그것을 정리 정돈해주는 것입니다.
일곱째. 불필요한 회의는 하지 않고, 생산성 높은 회의를 하는 것.
그렇습니다.
정말 필요시기에 의사결정을 하거나, 구체적인 방향성을 전달해야 할 경우에만 회의가 필요합니다.
오히려, 개발자들에게 필요한 것은...
개발자들 스스로 상호작용하면서 논의하고 협의하는 자체적인 회의들이지...
경영진이나 기획자들이 잡는...
뜬금없는 아이디얼 한 회의들이 아닙니다.
물론...
아이디어를 위한 회의에는 사전적인 준비나
아이디어를 위한 배경들을 제공해주면 더 좋겠죠.
가능하면, 개발자들은 개발에 전념할 수 있게 해주어야 합니다.
개발자들은...
비개발자들이 모르는 세부적인 개발 순서들을 지키기 위해서 최선을 다합니다.
여덟 번째. 업무 집중도를 위한 시간 보장.
제발, 개발자들이 업무에 집중할 수 있게 해 주세요.
정말 급한 버그나 문제가 발생하면, 개발자들 스스로 움직이고, 그런 문제가 지적되었다면...
개발자들 내부적으로 말없이 위기상황을 해결하기 위해서
서로 머리를 맞대고 고민하고 있습니다.
오류 프로세스와 위기 대처 프로세스에 따라서 움직여주세요.
정말, 급한 오류에 대해서는...
각 개발팀장들이 시간과 상황에 따라서 논의하고 있습니다.
비개발자들이
개발자의 자리에 찾아와서 따지는 듯이
행동해봐야...
개발자들의 문제 해결에 큰 도움이 안 됩니다.
오히려...
그런 상황을 만들지 않도록...
제발, 사전 테스트나 사전에 요구사항을 제대로 이야기하세요.
사전 테스트도 못하고,
사전 요구사항도 정리 못하는 '비즈니스'나 '상황'은 없습니다.
비개발자들이 해당 내용에 대한 '정의'를 못하는 것은..
업무를 잘 이해하지 못하고 있기 때문입니다.
물론, 업무 진행은 할 수 있습니다.
이해도가 없어도, 반복적인 훈련이나 정해진 업무들은 동작할 수 있으니까요.
이 상황을...
개발자들은 이해합니다.
이런 상황들을 '비개발자'들에게 끊임없이 이해시켜야 합니다.
그들은, 개발자들의 상황을 이해하지 못합니다.
아홉 번째. 퇴근 후에 업무 연락하지 않기.
그렇습니다.
사실, 퇴근 후에도 개발자들은 필요한 프레임웍에 들어갈 컴포넌트나 자료들을 찾거나, 부족한 부분을 채우기 위해서, 관련된 기술 자료를 찾고 있고, 주말에는 관련 커뮤니티의 기술세미나를 찾아갑니다.
그리고,
서버에 이상이 있거나, 앱에 이상이 있는 상황에 대응하기 위해서...
서비스와 시스템에
오류 상황과 모니터링 도구를 언제나 가동하고 있습니다.
담당자를 믿고, 정말 급한 상황이 아니라면...
굳이 연락할 필요 없습니다.
그들 스스로 비상연락체계를 구축하고 있으니까요.
열 번째. 정시 퇴근시키세요. 쓸데없이 야근시키지 마세요.
그거 아시나요?
비개발자들 가운데 제대로 야근 업무를 수행하는 사람의 비중이 얼마 안 된다는 것을...
그들 스스로 놀고 있거나, 어울려서 술자리나 오락 거리등을 만들면서 오히려, 개발자들이 야근할 분위기를 만들지 못하는 경우도 많다는 것을 알고 계신가요?
그들은 자리에 앉아있지만, 사실.. 업무 수행능력이 떨어져서, 그 형태로 작업하는지도 모르죠.
하지만, 개발자들은 그들에 대해서 '구체적으로 왜? 일하는지 관심'을 가지거나,
그들이 업무 시간에 무엇을 하는지에 대해서 관심이 없습니다.
회사의 비즈니스와 업무에 관심이 없고, 그 사람에 대해서 애정이 없어서가 아닙니다.
그 사람이, 그 업무를, 관련된 롤에 맞추어서 제대로 일하고 있다고 믿기 때문입니다.
그리고,
그 사람이 속해있는 팀과 부서에서 제대로 일하고 있다고 믿기 때문에....
그 사람이 놀고 있는지, 일하고 있는지 관심이 없습니다.
그 사람과 그 부서를 믿기 때문이죠.
개발자들은 비개발자들에 대해서 이렇게 신뢰하는데...
왜?
비개발자들은 개발자들이 업무시간에 무엇을 하는지?
업무 순서는 어떻게 되는지?
어떤 업무로 진행되는지에 대해서 궁금한가요?
이야기해주어도 모르면서 말이죠.
그냥, 개발자들 스스로 잘 일할 수 있도록 해주세요.
개발자들 스스로 알아서 일 잘합니다.
그리고, 일 잘 못하는 개발자이거나,
품질이 떨어지는 코드를 만드는 개발자,
말을 잘 못 알아 들어서 엉터리 코드를 만드는 개발자,
요구사항에 따른 아키텍처 정리가 안 되는 개발자,
자기 자신이 스스로 발전하지 못하는 개발자...
새로운 도구와 기술에 대해서 관심 없는 개발자...
그런 개발자들은 스스로 정리합니다.
비개발자들 스스로 자신의 업무에 충실하세요..
개발자들에게 관심 가지지 마시고.
그리고...
마지막으로...
CTO는...
비즈니스를 이해하고, 매출과 회사의 구조에 대해서 고민합니다.
그리고,
비개발 조직에게 최선을 다합니다.
우리는 같은 동료이니까요.
ps.
개발자 2~3명 있는 곳에서 CTO라고 이야기하는 것은 좀 우스운 상황입니다.
그리고,
대부분의 스타트업에서 CTO들이라고 불리우지면...
그냥, 개발팀장인 경우가 많고...
어쩔 수 없이 개발자들의 리더 역활을 해야 하기 때문에...
CTO라고 불리우는 경우도 많습니다.
다만, CTO라고 불리우려면...
1. 개발조직의 예산이나 인사권이 명확하고
2. 개발로드맵과 기술적인 판단에 대한 의사결정권한이 있어야 합니다.
하지만, 1,2의 두가지 조건이 빠진 경우가 참 많습니다.
그런 경우에...
그 사람은 CTO가 아니라...
그냥, 개발리더...
개발 팀장이죠.
하지만, 그런 사람들에게도...
동일한 이야기입니다.
개발리딩을 하고 있다면...
'책임'은 개발자들 앞에 있다는 것...
그 '책임'을 행해야 합니다.
개발자들이 언제나
즐거운 개발이 가능하기를 기원합니다.
