기획자, PM 위한 개발자 상식
#생존형 개발자의 생각 #95
개발자의 습성
개발자 역량을 메모지 1장으로 정리해보았다개발자는 머리보다 근성으로 버티는 사람이다. 타 업종에서 오해하는 것 중에 하나가 “두뇌” 사용법이 효율적이다라고 생각하는 데, 사회생활 28년간 가장 머리가 좋은 직군의 사람들은 “기획”이었지 개발이 아니었다. 개발자는 우직하고 한 곳에 집중하는 근성이 발달된 사람이다. 그러다보니 “근성”을 유지하기 위해서 “정성적 요인”과 “정량적 요인”을 가지게 된다.
정량적 요인으로는 맥락위주 사고방식, 문서화, 학습방법 같은 것들이 있다. 정성적으로는 “개발자 특유의 B급 감성”이 있다. 물론 모두가 그런 감성을 가지고 있지는 않지만 개발자 문화에 자연스럽게 녹아있기에 익숙하게 느껴질 수 밖에 없다.
개발자의 사고방식
개발자는 정량적 업무로 가능한 일을 해야 한다."해보겠습니다", "할 수 있습니다"가 아닌 "해야 한다"가 업무이다. 개발자는 아는 것이 중요하지 않다. "하는 것"이 중요하다. 아는 것도 현실에서는 재대로 되지 않는 것이 태반이다.
이유는
환경(Enviroment)이 다르고
맥락(Context)이 달라지고
예측못함(Bug, Error)이
발생하기 때문이다. 그러므로 개발자는 3가지 변수를 제거해야 한다. 그렇게 하지 않으면 기획자나 고객의 요청이 원할하게 수행되지 못하게 된다. 이런 이유로 개발자는
간단한 요청 1개에 수 십개의 질문과 이유를 말한다.
그리고 수많은 경우의 수를 경험하며 서로의 지식을 공유한다.
개발자가 기대하는 기획자와 PM
개발 업무의 위험성을 감지하는 PM과 기획자와 함께 하기를 원한다. 개발자 입장에서 개발팀이 제기하는 이슈를 기획자나 PM이 모른다는 것은 무책임한 것이다.
종종 기획자는 "기술적 제약을 무시하고 기획" 한다.
종종 PM은 "잘못된 업무할당과 순서"로 프로젝트를 산으로 보낸다.
아래는 아쉽게도 종종 현장에서 발생하는 업무 Flow이다. 위의 상황에서 각 파트들은 다음과 같은 실수를 하게 된다.
프로젝트에서 모든 사람은 반드시 실수한다. 핵심 얼마나 빨리 실수를 보안할 수 있는가이다.
결국은 개발자의 소통능력이 프로젝트의 성패를 좌우할 때가 있다.머리보다 몸과 기억을 믿는다
개발자는 머리보다 기록을 믿는다(문서를 강조하는 이유). 그리고 코딩은 머리가 아니라 손이 먼저 생각하는 것이다. 그런 점에서 “격투기”에 가깝다는 생각을 할 때가 많다. 해결해야 할 issue를 미리 분석하고 그에 대응하기 위한 전략으로 모듈을 설계하고 코드를 작성한다. 모듈을 구상하는 것은 머리를 활용하지만 코드 작성의 순간은 “머리보다는 체화된 손”이 할 때가 많다. 결국은 습관이다.
그만큼 평소 트레이닝 시간이 중요하다. 이 점이 격투기와 비슷하다고 느껴지기도 한다.
개발자를 표현하는 “말”들
서점에 가면 개발자와 소통하기 또는 업무이해에 관련된 서적들이 있다. 그만큼 IT에서는 뜨거운 감자에 속하는 직군임은 틀림없다. 개인적으로 개발자를 궁금해 하는 사람들에 개발자는 “오크”라는 표현을 할 때가 많다. 평소 거친 분노를 품고 살지만 “명예”에 대한 강한 집착과 “과제”에 대한 전투력 면에서 오크와 비슷한 점이 많다. 심지어 대외적으로 비호감인 점도 어느정도 비슷하다.
Obsidian으로 개발자 특성을 정리 중이다. 개발자다운 B급 법으로 문서를 작성 중이다. "호드를 위하여!"며칠 전 알라딘에서 중고로 구매한 “화성에서 온 프로그래머, 금성에서 온 기획자”라는 책을 읽다가 몇 군데 공감하는 구절이 있어서 정리를 해보았다.
여러분은 프로그래밍을 알고 있나요? 혹시 여러분이 '아니오'라고 답변하는 기획자라면 앞으로 기획에 어려움을 겪을 가능성이 큽니다. - "화성에서 온 프로그래머(한빛 미디어)" P018
"이 앱과 완전히 똑같이" 만들어 달라고 부탁하면 프로그래머에게 미움받는 지름길입니다. - "화성에서 온 프로그래머(한빛 미디어)" P027
개발자의 용어가 이해되지 않으면 묻고, 정확하게 이해한 뒤 대화해야 합니다. - "화성에서 온 프로그래머(한빛 미디어)" P249
디지털 전환의 시대, 기획자도 PM도 역량이 중요
적지않은 기획자와 PM들이 프로그래밍 또는 Software 서비스에 대한 이해가 부족하다. 물론, 그들이 프로그래밍을 해야 할 이유는 없다. 그러나 프로젝트의 핵심인 프로그래밍에 대한 일자무식을 당당하게 말하는 것은 있을 수 없는 시대이다. 업무 중 쏟아져나오는 “외계어”를 이해하지 못하면 프로젝트가 산으로 갈 수 있기 때문이다.
그런 점에서
기획자, PM도
[프로그래밍 업무]를 학습할 필요가 있다.
적어도 자신들이 기획하거나 관리하는 프로그램의 공정과정은 체험해보아야 하지않겠는가? 소스코드의 중요성, 빌드환경의 문제, 데이터베이스 백업의 심각성들을 이해하지 못한 체 개발자들의 위험 시그널을 들으면 그 말의 중요도를 알 수 없기 때문이다.
그리고 무엇보다 git으로 문서자료관리를 하지않는 것은 jira(bitbucket 기본연동)같은 이슈 트래킹 시스템을 십수년전부터 사용하는 시대에 맞지 않는 행동이다. jira의 개발사에서는 비개발자 민중들을 위해 sourcetree라는 프로그램을 십수년전부터 배포중이다.
기획자나 PM의 실제상황에 맞게 git 사용 시나리오까지 만들었건만.. 쓰지를 않는다. 자세의 문제다.기획자, PM들이 어려워 하는 부분은 소프트웨어 사용법, 개발자 환경이 아닐 수도 있다. 개인적으로는 개발자 유머를 클리어하는 순간 모든 것을 클리어할 수 있다고 본다.
