기획자가 복잡한 기능을 글(혹은 문서)로 써왔다.
근데 이 기능을 수식화(알고리즘) 하는 작업은.. 개발자가 해야하는 걸까? 기획자가 해야하는 걸까?
당연히 개발자가 수식화하겠지?
그럼 개발자가 수식화해서 코딩을 했다치자.
실제로 제대로된 결과값이 나오는걸 기획자가 검증할 수 있을까?
결과값이 ‘모’아니면 ‘도’처럼 제한되어 있다면 쉽게 검증하겠지만..
파라미터가 여러개고, 결과값 또한 여러 가지라면?
개발자가 테스트 코드를 작성했다고 하지만,
그건 개발자가 만든 것이다보니 기획자의 의도가 투영이 안되었을 수도 있다.
파라미터 A가 ’1′이고, 파라미터 B가 ‘철수’면
기획자의 의도대로는 ‘꺄~~~ 조인성!!’이 나와야 하지만
실제 작성된 코드로는 ‘송혜교 겁나 이뿌다’가 나올 수도 있다는 얘기.
그 겨울 바람이 분다. 조인성
결국은 기획자가 QA를 해야하는데, 그럼 수식은 기획자가 짜야하는걸까?
그건 아니다.
이때까지(고작 11년 밖에 안되는 짧은 시간이지만) 경험에 비추어 보면,
대부분의 경우 기획자는 그냥 툭 던지고 가버린다.
예를들어 지하철 노선도 프로그램을 만든다고 치자.
기획자는 “‘길찾기’기능 필요해요~”라고 툭 던지고 가고..
개발자는 그냥 열심히 만든다.
열심히..
뚝딱뚝딱..
밤을 새가며
키보드 부셔져라
코딩한다.
그래서 완성했다.
근데 ‘길찾기’ 검증은 어떻게 하지?
‘그걸 기획자가 왜 검증해?’라고 생각했다면
난 되묻고 싶다. ‘당신 기획자 맞습니까?’
제대로 동작하는지 당연히 확인해야지.
소소한것들은 잘도 쪽쪽 찝어서 테스크 생산 해주시는데 (예를들어 버튼이 좌측으로 1px 밀려있다. 응? 이건 디자이넌가? 암튼 뭐 이런것들)
복잡한 기능의 ‘검증’은 그냥 개발자를 믿어버리는(떠밀어버리는)것 같다.
종종 ‘검증’을 아에 잊어버린 것 같다고 느낄 때도 있다.
위에도 썼지만 기능을 기획한 사람이 검증도 할 수 있어야 한다.
옛말에 결자해지라고.. 쿨럭;;
그러므로 ‘이게 좀 복잡한 기능이다~’ 라고 생각이 들면 테스트 케이스를 미리 만드는것이 바람직하다.
만들기 귀찮다고?
그래도 만들어야한다. 우리는 완성도 높은 제품을 만드는 공통 목적을 가진 팀이 아닌가?
개발자 믿는다고?
개발자는 기본적으로 커뮤니케이션 능력이 떨어지는 경우가 많고, 기획서(암호문)를 구독(해독)해서 이해하는 능력도 떨어지는 경우가 많다. (이건에 대해서 별도의 포스팅을 할려고 하는데.. 뭐 봐서)
분명 서로 오해하는 경우가 생긴다.
“개발자를 이해시키면 안되요?” 라고 생각할 수도 있다.
개발자가 이해를 해야 개발에 들어갈 수 있으므로 설명은 당연히 해야하는 것이다.
기획서 휙 떤져주고 가면 안된다.
네비게이션 길찾기 처럼
파라미터와 결과값이 너무 방대한 경우라 하더라도 테스크 케이스는 만드는것이 좋다.
간략하게 본인집과 동사무소가는길, 본인집과 시골집가는길 등등으로 말이다.
만약 테스트 케이스 만들기가 너무 막막하다면
개발자에게 도움을 요청해서 함께 만들어 보는것도 괜찮은 방법이다.
개발시 테스트 케이스가 있다면
개발자는 불안감 없이 개발할 수 있고(검증을 믿을 수 있으니깐)
기획자 또한 빠른 시일내에 제대로 된 프로그램을 받아볼 수 있게 될 것이다.
가장 중요한 것은, 검증은 기획자만 하는게 아니다.
기획자, 디자이너, 개발자 등 팀원 모두가 함께 해야하는 것이다.
소소한 것부터 복잡한 기능까지 모두 함께 하는 것이다.
우리는 완성도 높은 제품을 만드는 공통 목적을 가진 팀이고 거기서 보람을 느끼는 족속들이기 때문이다.
“팀웍이라는게 뭐야?
그저 도와주고, 막아주고 그런걸로 되는거야?”
“그렇게 생각하는 녀석들도 있겠지만 말야,
나에겐 입에 발린 말이라는 생각밖에 안들어.
각자가 자신이 할 수 있는 일을 죽을 각오로 한 뒤에,
‘난 다했다. 다음은 네 차례다. 못하면 죽여버릴거야!’
라고 말할 정도의 기합이 있고서야 비로써 팀웍이라는게 형성되는게 아닐까?
그렇게 생각하면 우리는 각자 한 마리의 외로운 늑대들이라고 해도 괜찮지 않을까?”
- 원피스, 조로와 쵸파의 대화 中
Sorcery를 이용해서 Facebook 로그인을 하는데..
