가치를 만들어내는 일은 여러가지가 있다. 소프트웨어 개발자들은 보통 구현이나 설계로 가치를 만들어내는 경우가 많다. 보통 개발자의 메인 업무로 할당되진 않지만, 기획도 가치 창출의 한 방법이다.
기획에 대해서는 아주 많은 이야기가 있다. 모두가 동의하는 정의는 없는것 같지만, 대체로 “목표를 세우고 이를 달성하기 위한 전략을 수립”하는 정도면 충분히 추상적이어서 그러려니 생각되는 정도인 것 같다. 기획의 첫 단계를 목표 설정, 그러니까 문제 정의로 잡는건 거의 공식화 되어있다. 사실 기획 뿐 아니라 모든 Problem solving 이 그렇겠지만
세우는 목표의 종류에 따라서 여러가지 기획 테크트리를 타게 되는데, 개발자들과 직접적으로 관계가 있는 것은 제품/서비스 기획이다. 보통 개발자들은 기획에 약한 모습을 많이 보인다. 정확하게는 첫 번째 단계인 목표 설정을 하는데 약하다. … 아니라면 미안, 사실 내가 약하다. 어쨌건 목표가 일단 잡히고 나면, 이를 달성하기 위한 전략을 세우는 것은 개발과 직접적인 관계가 없더라도 엔지니어라도 흐름을 잘 따라갈 수 있다 - 설계와 매우 닮아서 분할정복을 시도할 수 있다.
나는 왜 목표를 세우는 데 약할까? 이유를 알면 - 사실과 다르다고 해도 - 공략을 시작할 수 있다. 한 가지 이유만 있는 것은 아니겠지만, 내가 생각하는 가장 큰 이유는 주로 하는 활동인 구현, 설계와 사고 흐름의 방향이 반대이기 때문인 것 같다. 목표 세우기를 다른 말로 표현하면 “큰 문제 내기” 이다.
준비되었거나 준비할 수 있는 작은 문제들을 사용해서 어떤 큰 문제를 만들어 풀어야 의미가 있을까
를 생각하는, 정확히 여기서 이야기한 설계의 역방향 사고흐름이다. 그래서 이 문제가 얼마나 어려운가, 쪼개진 부위가 어떤가 에 대한 것이 아니라 사람들이 이 문제를 풀면 좋아할까? 라는 전혀 다른 쪽의 직관을 필요로 한다.
이게 방향의 문제가 맞나? 그냥 다른 분야라서 그런게 아닐까? 라고 생각도 조금 해 보았다. 하지만 직접적으로, 대놓고 “좋은 코딩 문제를 내 보아라”고 해도 이에 답하는게 일반적으로 매우 어렵다는걸 깨닫고 분야의 문제는 아니라고 확신했다. 문제는 내는 것과 푸는 것은 서로 다른 능력이다. 가르치는 것과 배우는 것이 다른 것처럼. 뭐가 좋은 코딩 문제인가? 를 정의하는 것 부터 대 혼란에 빠질 수 있다.
자, 어떻게 공략을 시도할 수 있을까?
… …
나는 요새 문제내기를 좀 더 잘 하기 위해 이것 저것 분석 중이다. … 다음 글에 이어서.
Comments