실패하지 않는 제품개발 3 - 사양서 없는 제품의 말로
하드웨어 개발에서 협업이 실패하는 진짜 이유
“기획서에 다 써놨어요.”
“그건 기획자 생각이죠.”
“이건 원래 이렇게 하기로 한 거 아닌가요?”
하드웨어 제품개발에서 이런 대화는 흔하다.
기획, 디자인, 기구설계, 회로설계, 펌웨어, 제조…
모든 부서가 같은 제품을 만들고 있지만, 서로 다른 그림을 보고 있는 경우가 너무 많다.
그 결과는?
금형은 다시 떠야 하고, 회로는 수정돼야 하며, 일정은 터진다.
그리고 모두가 이렇게 말한다.
“처음부터 제대로 정리했어야 했어”
말이 아니라, 문서로 정리했어야 한다
하드웨어 제품개발은 말로 시작하면 망하기 쉽다.
‘이 정도면 알겠지’라는 가정이, 몇 천만 원짜리 손실로 돌아온다.
그래서 진짜 중요한 건 명확한 제품사양 요구서,
즉, 기획자 한 사람만이 아닌, 모든 팀이 같은 방향을 향하게 해주는 명세서다.
좋은 사양서는 무엇을 담아야 할까?
이 제품은 누구를 위해 만들어지는가? (목표 사용자 정의)
어떤 기능은 반드시 필요하고, 어떤 기능은 있으면 좋은가? (우선순위)
사용자는 이 제품을 어떻게 사용할 것인가? (시나리오, 유스케이스)
제품의 크기, 소재, 무게, 포트 위치, 인터페이스 등은 어떻게 설계되는가?
필요한 부품 리스트와 예상 소비 전력은 어느 정도인가?
사양서는 혼자만 이해해서는 안 된다. 모든 팀이 같은 그림을 그릴 수 있어야 한다.
협업을 망치는 말 vs. 살리는 언어
“이거 그냥 간단한 기능이에요.” ❌
→ 실제 구현이 복잡하면 간단하지 않다. 그건 착각이다.
“그 정도는 당연한 거 아닌가요?” ❌
→ 협업에서 당연한 건 없다. 문서화되지 않은 정보는 없는 정보다.
“이건 사양서 3페이지 2항 참고해주세요.” ✅
→ 이 한 문장이 모든 팀을 같은 기준으로 정렬시킨다.
사양서가 없는 프로젝트의 결말
디자인팀은 예쁘게 만들고, 개발팀은 구현 가능한 걸 만들고,
기구설계팀은 설계대로 만들었지만, PCB와 맞지 않는다.
테스트 단계에서 기능이 누락되었고, 수정은 불가능하다...
이제 돌이킬 수 없다는 걸 깨닫는 순간,
모두가 이렇게 말한다.
“처음에 왜 그걸 명확히 하지 않았을까?”
요구사항 분석 없이 제품을 만드는건,
개발이 아니라 도박이다.
하드웨어 제품개발에서는 특히 다음 두 가지가 절대적이다.
1. 요구사항 분석 (Requirement Analysis)
고객이 진짜 원하는 것이 무엇인지,
그 니즈를 어떻게 기능/형태로 구현할지,
비즈니스 목적과 사용자 행태를 함께 고려해야 하는 단계
이 단계가 부실하면, “우리가 만든 걸 고객이 이해 못 하네?”라는 말이 나온다.
2. 명확한 제품사양 명세서 (Requirement Specification)
기능 하나하나를 명확하게 기술
디자인, 기구설계, 회로, 펌웨어팀 모두가 동일한 기준을 갖고 움직일 수 있어야 한다.
필수요소, 우선순위, 예외처리, 크기/무게/전원/UI 요소 등까지 포함된 문서여야 한다.
사양서가 명확하지 않으면 “이건 그런 의도가 아니었는데요?”가 반복되고, 개발비는 폭증하게 된다.
제품개발은 글로 시작해야 한다
요구사항 분석 없이 시작된 개발은
협업이 아니라, 각자의 해석이 충돌하는 싸움터가 된다.
제품은 실행의 총합이고,
실행은 문서로 정리된 기준에서 출발해야 한다.
사양서가 없는 제품은, 초기부터 실패할 이유를 갖고 움직이기 시작한 것이다.
