Topic 45 요구 사항의 구렁텅이
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
p.350
이 말은 어느 상황이든지 공감할 수 있다. 프로젝트가 있다면 이를 발주한 측과 이를 수행하는 측 모두 처음부터 미래를 완벽히 알지 못한다. 사실상 컨셉의 구체화 정도 차이라고 본다. 개발자가 만들다보면 니즈가 바뀌고 요구사항이 바뀌기 나름이기 때문이다. 그리고 더 상세한 정책을 수립하다보면 플로우가 바뀌기도하고 기능이 바뀌기도 하기 때문이다. 그러나 이를 잘 조율하는 키 또한 개발자에게 있다.
프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.
p.351
프로그래머는 알고리즘 문제처럼 상황과 예제 데이터가 명확한 문제만 해결하지 않는다. 오히려 코드를 작성하는 것보다 요구사항 정립이 더욱 중요하다. 아무리 성능적으로 좋은 퍼포먼스를 가지더라도 사용자의 불편함을 극복하지 못한다면 무용지물이기 때문이다. 그렇기에 프로그래머는 니즈를 파악하고 해결해주는 것이 중요하며 덕목인 것 같다.
상담 치료로서의 프로그래밍
신입 개발자들이 자주 범하는 실수는 이런 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다. 우리의 경험상 최초의 요청 사항은 궁극적인 요구 사항이 아니다. 의뢰인은 인식하지 못할 수도 있지만, 의뢰인의 요청 사항은 사실 함께 탐험을 떠나자는 초대장이다.
p.352
바로 해결책을 구현하는 것이 잘못된 것은 아니지만 그 요구 사항을 완벽히 만들기 위해 많은 시간을 쓰는 것이 실수인 것 같다. 왜냐하면 결국 조금이나마 바뀌게 될 것이기 때문이다. 화면에 특정 데이터만 더 보여주는 정도면 다행이지만 플로우가 바뀌어 버리면 여러모로 귀찮아지기 때문이다. 즉 만들고자하는 기능의 흐름을 보여줄 수 있어야한다. 그 후 다듬고 보완하는 것이 좋은 것 같다.
여러분: 총 5만 원에 대해 궁금한 점이 있습니다. 여기에 우리가 원래 부과하는 배송비도 포함됩니까?
의뢰인: 물론이죠. 고객이 지불하는 금액 전체를 말하는 겁니다.
여러분: 고객이 이해하기 쉽고 좋네요. 반응이 좋겠는데요? 그런데 일부 비양심적인 고객이 이 시스템을 이상하게 사용하려고 할 것 같은데요.
의뢰인: 어떻게요?
여러분: 음. 예를 들어 2만 5천 원짜리 책을 하나 사고, 가장 비싼 당일 배송을 고른다고 해 보죠. 당일 배송 비용은 3만 원이니까 총 5만 5천 원이 되는데요. 그러면 결제금액이 5만원이 넘으므로 배송이 무료로 바뀝니다. 따라서 고객은 2만 5천 원만 내면 되고, 배송비 없이 2만 5천 원짜리 책을 당일 배송으로 받을 수 있게 되겠지요. (이 지점에서 경험이 많은 개발자는 멈출 것이다. 사실을 전달하고 의뢰인이 결정을 내리도록 한다.)
의뢰인: 아이코, 그건 제가 의도한 것이 아닌데요. 그러면 우리가 손해예요. 어떻게 해야 할까요?
p.353
저자는 이와 같이 협상을 할 때 처음부터 끝까지 물어보지 말라고 한다. 이런 상황에서는요? 이럴 떄는요? 이런 식으로 모든 상황을 물어보지 말고 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주라는 것이다.
이는 생각하지 못하고 깨닫지 못한 부분인데 유의해서 적용할 부분인 것 같다. 필자는 가능한 모든 상황에 대해 정책을 정립하는 것이 잘하는 것이라고 생각했는데 이러한 접근 방식 또한 필요한 것 같다. 모든지 양쪽 모두 장점이 있고 단점이 있듯 중화해서 가장 좋은 지점을 찾아야한다.
요구 사항은 과정이다
요구 사항은 피드백을 반복하며 알게 된다.
p.354
내가 필요해서 만드는 것이라면 만들면서 스스로 피드백을 주면 되겠지만 특정 상황에 필요한 것을 만들기 위해서는 지속적인 피드백으로 같은 결과물을 바라볼 수 있어야한다. 개발자는 계속 직진을 하는데 방향 또한 중간중간 틀어서 가장 빠른 길로 갈 수 있도록 해야한다. 방향을 틀지 않으면 어디에 도착은 하겠지만 분명 목표했던 곳은 아닐 것이다.
실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정을 보아야 한다. 그래서 우리는 짧은 주기로 반복하는 것을 선호한다. 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다. 그러면 우리가 궤도에서 벗어나지 않을 수 있다. 혹시 우리가 정말로 잘못된 방향으로 가더라도 잃어버리는 시간을 최소화할 수 있다.
p.355
애자일 방법론이 좋은 이유가 지속적인 배포가 가능하는 것인데 이를 지속적인 피드백이라는 관점에서 보니 더욱 와닿는 부분이 있다. 지속적으로 피드백을 받아야 가장 짧은 거리로 갈 수 있기 때문이다.
의뢰인의 입장에서 보라
“일하시는 데 일주일만 옆에 앉아 있어도 될까요?”라고 부탁하는 것이 의뢰인과 신뢰를 구축하고 의사소통의 기반을 다지는 데 얼마나 도움이 되는지 놀라게될 것이다. 단, 방해하지 않도록 주의하라.
p.355
도메인 지식이 부족한 파트에 관한 프로젝트를 해야 한다면 기존 소스 코드가 있어도 실무자의 사용을 보는 것보다 못하다. 코드로 모든 것을 볼 수 있으나 실무자의 사용을 본다면 소스를 분석하지 않고 이해할 수 있기 때문이다. 그러나 옆에 앉아서 실무자의 사용을 보라는 조언은 나름 파격적이라고 생각이 드는데 기회가 된다면 실천으로 옮기어보고 싶다.
사용자처럼 생각하기 위해 사용자와 함꼐 일하라.
p.355
가장 어렵기도 한 부분인데 사용자 관점에서 보려고 노력할 때 가장 큰 장점은 스스로 몰입할 수 있다는 것이다. 개인적으로 몰입은 재밌거나 프로젝트 마감일 때 되는거 같은데 내가 더 발전시키거나 사용성을 향상 시킬 수 있는 것을 고민하면 어느새 재미를 느끼어 몰입하게 되는 것 같다. 진짜 재밌는건지 재밌을려고 노력해서 재밌는건지는 모르곘다. 여하튼 재밌고 몰입하면서 개발을 하면 더 좋은 결과물을 만들 수 있을 것이다.
요구 사항 대 현실
이 예는 도구가 성공하려면 사용하는 사람의 손에 적응할 수 있어야 한다는 우리의 믿음을 잘 보여 준다. 이 점도 염두에 두어야 성공적으로 요구 사항을 수집할 수 있다. 그래서 프로토타입이나 예광탄을 이용한 빠른 피드백으로 의뢰인으로부터 “네. 이것이 것이 맞긴 한데 제가 원하는 방식은 아니네요.”라는 반응을 얻어야 하는 것이다.
p.357
회의를 하거나 의견 조율을 할 때 서로 맞다만 외칠 가능성은 별로 없다. 이건 해주세요. 이건 안되는데요. 등 사실 이런 이야기가 안 나올 수 없기 때문이다. 즉 맞다는 이야기만 나올 경우 서로 이해를 잘못한 상황일 가능성이 크다.
요구 사항 문서는 계획을 위한 것이다
우리는 진짜 인덱스카드 혹은 가상의 인덱스카드에 들어갈 정도로 적는 방식을 선호한다. 이런 짧은 설명을 ‘사용자 스토리(user story)’라고 부른다. 여기에는 애플리케이션의 작은 일부가 그 기능을 쓰는 사용자 관점에서 어떻게 작동해야 하는지를 적는다.
p.359
인덱스 카드는 어떻게 보면 Work Item 으로 볼 수 있다. 이를 통해 작업을 분할하고 작업을 순서별로 진행할 수 있기 때문이다.
지나치게 자세한 명세
요구 사항 문서를 만들 때 생기는 또 다른 심각한 문제는 지나치게 자세히 서술하는 것이다. 좋은 요구 사항은 추상적이다. 요구 사항을 기술할 때는 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다.
p.359
꼼꼼함이 꼼꼼하지 않은 것보다는 낫다고 생각하지만 완벽하게 적을려고 말이 길어지면 정리하기도 어렵고 오히려 이해가 쉽지가 있다. 간단하게 적는 것이 하나의 스킬이지 않나 싶다. 꼭 모든 것을 문장으로 쓸 필요 없이 1, 2, 3.. 처럼 리스트 형태로 적어도 도움이 되고 중요 키워드만 적어도 된다. 아직 이런 경험이 많지는 않아서 몸소 깨달은 바는 적다.
Topic 45 느낌
Topic 45 에서는 프로그래밍은 요구 사항으로 시작해서 요구 사항으로 끝난다는 것을 명심하게 한다.