요구된 기능에서 가치 추구하기

 - Einar Landre

Einar Landre 는 개발자, 아키텍트, 관리자, 컨설턴트, 저자/프레젠터로 25년 동안의 경험을 가진 현재 활동중인 소프트웨어 전문가이다.
현재 StatoilHydro의 비즈니스 어플리케이션 서비스팀에 있으며, 비즈니스 중요 어플리케이션 개발, 아키텍처 리뷰 및 소프트웨어 프로세스 개선 활동에 종사하고 있으며, SOA, 도메인 기반 설계, 다중 에이전트 사용 및 대규모 네트워크 기반의 소프트웨어 중심 소프트웨어의 설계에 전문가이다.




고객과 최종 사용자들은 요구사항으로 문제에 대한 자신들이 생각한 실용적인 해결책을 종종 언급합니다. 이러한 전형적인 예를 F-16 팔콘의 리드 설계자인 Harry Hillaker가 말했었습니다. 그의 팀은 마하 2-2.5 의 비행기를 설계했었는데, 그 당시, 아니 지금도 이것은 단순한 작업이 아니었습니다 – 특히 목표가 “값싼” 경량 비행기를 만드는 경우에. 속도가 두배인 동시에 4배까지 힘이 가하는 것을 극복했을 때 비행기 무게에 어떠한 충격이 가할지를 상상해보십시오.

설계팀이 공군에 왜 마하 2-2.5가 필요한지를 물었는데, 그 대답은 “전장으로부터 벗어날 수 있기 위함”이라는 것이었습니다. 검토 단계에서 실질적인 요구사항을 가지고 설계팀은 근본 문제를 파헤치고 실제 도움이 되는 해결책을 제시할 수 있었습니다. 즉, 최대 속도가 아니라 가속과 기동성을 보장하면서 높은 무게 대비 추진력 비율을 가지는 민첩한 비행기였습니다.

소프트웨어 개발 역시 위의 교훈을 참고해야 할 것입니다. 요구되는 기능이나 요구사항의 의도된 가치를 추구함으로써 아키텍트는 실질적인 문제에 집중하고, 잘 되면 고객이 말한 것보다 더 좋고 값싼 해결책을 제시할 수 있습니다. 가치에 집중하는 것은 또한 우선순위를 단순화시키는 작업입니다. 즉, 가장 가치가 있는 요구사항이 영향을 미치는 요구사항이 됩니다.

그렇다면, 그 다음에 어떻게 진행할까요? 여러 측면에서 필요한 방법은 애자일 메니페스토 에 있는 “계약보다는 협업” 이라는 원칙에서 발견됩니다. 사실상, 이는 아키텍트가 고객의 요구에 부응하는 – 즉 고객에게 “왜”라는 질문에 답하도록 요청하는 – 워크샵과 미팅에 초점을 맞추는 것을 의미합니다. 아키텍트는 너무나 흔하게 기술적인 지식에 대해서 언급하기 때문에 “왜”라는 질문에 답한다는 것이 어려울 수 있다는 사실에 유의하십시오. 기술적인 해결책을 어떻게 제공할지에 대한 토의는 이러한 워크샵에서 피해야 합니다. 그 이유는 고객의 영역에서 소프트웨어 개발이라는 영역으로 초점이 옮겨지기 때문입니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - Seek the value in requested capabilities