연구와 개발의 밸런스
R&D에 계속 몸을 담고 있지만, R과 D가 크게 다르다는 점은 별로 주목받지 못하는 것 같다.
연구 조직과 개발 조직을 완전히 분리하는 경우도 있겠지만, 내가 몸담은 조직은 개발 조직에서 연구를 함께 진행하는 경우이다.
연구와 개발은 다르다
Software 제품의 개발과 기술 심화를 위한 연구는 결과적으로는 제품이라는 형태로 가치가 외화된다는 점에서는 같은 것이라고 볼 수 있겠지만, 개발과 연구를 하나의 영역으로 간주한다면 효율과 성과 측면에서 어려움에 부닥칠 것이다.
연구를 개발의 일부로만 바라보고 제품 개발 프로세스에 직접적으로 포함시켜버린다면 연구의 깊이나 창의성은 매우 약해질 것이다. 연구가 제품의 직접적인 이슈를 해결해주기 위한 보완적 성격으로만 사용될 것이고, 장기적인 제품 비전과 질적 깊이를 이루지 못할 것이다.
반대로 연구 중심의 프로세스를 셋업하고 개발을 부차적인 프로세스로 간주한다면 Software 제품의 직접적인 품질을 결정하는 코드 품질이나 모듈화 등 기본 방법론적 측면이 약화될 것이고, 연구 성과를 제품의 일부로 흡수하기까지 너무 많은 시간을 허비하면서 제품은 그 시간 한계 속에서 시장으로부터 벗어나게 될 것이다.
연구는 흔히 투자 개념으로 바라본다. 보통 투자는 상대적으로 장기적인 관점의 수익을 기대하는 부분이지만, 시장 요구 혹은 트렌드와 무관하지는 않다.
개별 제품 개발 프로세스는 보통 진척률과 이슈, Feature Set 등을 중심으로 관리하게 되는데 연구는 핵심 기술 영역 확보 혹은 차별적인 Key Feature Set을 가지기 위한 특별한 투자로 바라볼 수 있다.
문제는 연구는 제품 개발에 비해 시간 제약이나 성과에 대한 예측이 더 어렵다는 데 있다.
제품 개발의 경우 Risk를 최소화하기 위해 여러 가지 기법들이 연구되어 있고, 마일스톤별 Feature를 축소하는 등 시장에 대한 시간 압박에 적응하기 위한 노력들이 정형화될 수 있지만, 연구의 경우는 그러한 제약들을 매우 느슨하게 적용하는 것이 일반적이다.
연구 개발의 관리
연구 관리와 개발 관리를 어떻게 조화롭게 관리하여 손실을 최소화할 수 있느냐는 관점에서 바라봤을 때, 연구와 개발은 먼저 관리되는 업무로서는 완전히 분리를 해서 다르게 관리를 해야 한다는 것은 분명하다.
연구 Task와 개발 Task를 다르게 바라보고, 그 다른 성격을 존중하되 시장과의 긴장은 각 영역별로 다르게 제약을 하는 것이 필요하다. 단일 Project 안에서 연구 Task와 개발 Task가 혼재하는 경우에는 연구 Task와 개발 Task가 의존성이 생기므로 문제가 더욱 복잡해진다.
연구 Task이든 개발 Task이든 Task의 time frame과 milestone별 성취에 대한 관리는 정형적으로 관리될 필요가 있다.
다만, 연구 Task의 예측률은 상대적으로 많이 떨어지므로 개발 Task의 time frame을 기조로 연구 Task의 성취를 제한적으로 반영해가는 형태가 될 것 같다.
현실적으로는 연구 Task와 개발 Task는 Task 관리 뿐 아니라 멤버들의 역할 조화가 큰 이슈가 된다. 같은 조직 내에서 연구와 개발 Task를 모두 감당해야 하는 경우에는 더욱 팀웍과 성취감 부여가 이슈가 된다.
Task별 성취에 대한 관리와 멤버별 연구 및 개발 능력의 판단, 멤버별로 성취도에 따른 새로운 성격의 Task 부여 등이 하나의 해결책이 될 수 있을 것이다. 같은 조직 내에서라면 연구 Task와 개발 Task의 엄격한 역할 구분은 오히려 독이 될 수 있다. 각 멤버별로 연구 능력과 개발 능력을 함께 성장할 수 있도록 배려하고 연구에만 전념하는 멤버는 특수한 경우에 한해 최소화하고 개발에서 성취를 이룬 멤버는 점차 좀더 도전적인 과제와 연구 성격의 과제로 도전할 수 있도록 성취도 체크를 마일스톤별로 할 필요가 있을 것이다.
관리는 단일해를 구할 수 없다
연구 관리는 어려운 문제이고 연구와 개발의 밸런스 뿐 아니라 수많은 다른 관리 능력을 요구한다.
오류와 개선은 모든 사람이 하는 프로세스의 필수 요소인 것 같다. 하나의 정답이 존재하는 것이 아니니, 시행 착오를 줄이기 위해 하나의 시행에서 더 많은 교훈을 추출해내고 다음 시행에 반영할 뿐이다.
연구 조직과 개발 조직을 완전히 분리하는 경우도 있겠지만, 내가 몸담은 조직은 개발 조직에서 연구를 함께 진행하는 경우이다.
연구와 개발은 다르다
Software 제품의 개발과 기술 심화를 위한 연구는 결과적으로는 제품이라는 형태로 가치가 외화된다는 점에서는 같은 것이라고 볼 수 있겠지만, 개발과 연구를 하나의 영역으로 간주한다면 효율과 성과 측면에서 어려움에 부닥칠 것이다.
연구를 개발의 일부로만 바라보고 제품 개발 프로세스에 직접적으로 포함시켜버린다면 연구의 깊이나 창의성은 매우 약해질 것이다. 연구가 제품의 직접적인 이슈를 해결해주기 위한 보완적 성격으로만 사용될 것이고, 장기적인 제품 비전과 질적 깊이를 이루지 못할 것이다.
반대로 연구 중심의 프로세스를 셋업하고 개발을 부차적인 프로세스로 간주한다면 Software 제품의 직접적인 품질을 결정하는 코드 품질이나 모듈화 등 기본 방법론적 측면이 약화될 것이고, 연구 성과를 제품의 일부로 흡수하기까지 너무 많은 시간을 허비하면서 제품은 그 시간 한계 속에서 시장으로부터 벗어나게 될 것이다.
연구는 흔히 투자 개념으로 바라본다. 보통 투자는 상대적으로 장기적인 관점의 수익을 기대하는 부분이지만, 시장 요구 혹은 트렌드와 무관하지는 않다.
개별 제품 개발 프로세스는 보통 진척률과 이슈, Feature Set 등을 중심으로 관리하게 되는데 연구는 핵심 기술 영역 확보 혹은 차별적인 Key Feature Set을 가지기 위한 특별한 투자로 바라볼 수 있다.
문제는 연구는 제품 개발에 비해 시간 제약이나 성과에 대한 예측이 더 어렵다는 데 있다.
제품 개발의 경우 Risk를 최소화하기 위해 여러 가지 기법들이 연구되어 있고, 마일스톤별 Feature를 축소하는 등 시장에 대한 시간 압박에 적응하기 위한 노력들이 정형화될 수 있지만, 연구의 경우는 그러한 제약들을 매우 느슨하게 적용하는 것이 일반적이다.
연구 개발의 관리
연구 관리와 개발 관리를 어떻게 조화롭게 관리하여 손실을 최소화할 수 있느냐는 관점에서 바라봤을 때, 연구와 개발은 먼저 관리되는 업무로서는 완전히 분리를 해서 다르게 관리를 해야 한다는 것은 분명하다.
연구 Task와 개발 Task를 다르게 바라보고, 그 다른 성격을 존중하되 시장과의 긴장은 각 영역별로 다르게 제약을 하는 것이 필요하다. 단일 Project 안에서 연구 Task와 개발 Task가 혼재하는 경우에는 연구 Task와 개발 Task가 의존성이 생기므로 문제가 더욱 복잡해진다.
연구 Task이든 개발 Task이든 Task의 time frame과 milestone별 성취에 대한 관리는 정형적으로 관리될 필요가 있다.
다만, 연구 Task의 예측률은 상대적으로 많이 떨어지므로 개발 Task의 time frame을 기조로 연구 Task의 성취를 제한적으로 반영해가는 형태가 될 것 같다.
현실적으로는 연구 Task와 개발 Task는 Task 관리 뿐 아니라 멤버들의 역할 조화가 큰 이슈가 된다. 같은 조직 내에서 연구와 개발 Task를 모두 감당해야 하는 경우에는 더욱 팀웍과 성취감 부여가 이슈가 된다.
Task별 성취에 대한 관리와 멤버별 연구 및 개발 능력의 판단, 멤버별로 성취도에 따른 새로운 성격의 Task 부여 등이 하나의 해결책이 될 수 있을 것이다. 같은 조직 내에서라면 연구 Task와 개발 Task의 엄격한 역할 구분은 오히려 독이 될 수 있다. 각 멤버별로 연구 능력과 개발 능력을 함께 성장할 수 있도록 배려하고 연구에만 전념하는 멤버는 특수한 경우에 한해 최소화하고 개발에서 성취를 이룬 멤버는 점차 좀더 도전적인 과제와 연구 성격의 과제로 도전할 수 있도록 성취도 체크를 마일스톤별로 할 필요가 있을 것이다.
관리는 단일해를 구할 수 없다
연구 관리는 어려운 문제이고 연구와 개발의 밸런스 뿐 아니라 수많은 다른 관리 능력을 요구한다.
오류와 개선은 모든 사람이 하는 프로세스의 필수 요소인 것 같다. 하나의 정답이 존재하는 것이 아니니, 시행 착오를 줄이기 위해 하나의 시행에서 더 많은 교훈을 추출해내고 다음 시행에 반영할 뿐이다.
댓글