사용자가 스스로 요구 사항을 함께 얻거나 안내 할 수 있습니까?

모두가 이와 같은 것을 경험했다고 확신합니다. 프로젝트가있는 고객과 회의를합니다. 요구 사항이 거의 없거나 마음에 들지 않고 원하는 것을 모호하게 이해합니다. 이 시점에서 두 가지 옵션이있는 것 같습니다.

1) 사용자들에게 "좋아, 아직 설명조차 할 수 없다면 무언가를 만들 수 없다. 원하는 것을 알면 몇 주 후에 다시 만나지 않겠습니까?"

2) 사용자를 몇 번 만나서 좋은 ole Socratic 방법으로 안내함으로써 원하는 것을 파악하도록 도와줍니다. "X를 추적해야합니까?", "Y는 어떻습니까?", "기능 Z가 필요합니까?"

첫 번째 옵션을 사용하면 다른 사람의 일을하거나 정신적 힘을 얻는 데 방해가되지 않지만 사용자는 일관된 사양을 제시하지 않거나 마감일이 다가올 때까지 영원히 걸릴 수 있습니다. 두 번째 옵션을 사용하면 비즈니스 분석가가되는 데 많은 시간을 허비하고 다시는 사용하지 않을 비즈니스 지식을 머리에 쏟아 부어야하지만 사양이 더 많이 나올 수 있습니다. 어떤 의미가 있습니다.

나에게 이것은 개발의 가장 도전적인 측면 중 하나이며, 나는이 감정에서 혼자가 아니라는 느낌을받습니다. 경험상 이러한 옵션 중 어떤 것이 더 잘 작동합니까?

때로는 옵션 3을 선택한다는 것을 인정해야합니다.)

3) 고객의 모호한 아이디어를 듣고 원하는 것을 정확히 파악하는 데 도움이되는 몇 주를 소비한다는 아이디어를 듣습니다. 필요한 것이 무엇인지 파악하고, 빌드하고, 필요에 따라 리팩터링하십시오.

이것은 특히 소규모 작업에 효과적입니다. 고객이 현실에서 비현실적인 아이디어를 머리 속에 가지고있는 상황을 피할 수 있기 때문입니다.

그것은 항상 나에게 일어난다. "확실히 할 수 있습니다 ..."는 매우 무서운 문구입니다. 특히 언급되는 것은 거의 항상 종, 휘파람 및 "좋은"클래스의 기능입니다. 그들은 "버그 트래커를 분명히 잘 알고있다가 ..."라는 진술에서 그 잠재적 인 작업의 대부분이 처음 네 단어에 있다는 것을 알지 못합니다.

따라서 때때로 고객의 비전 을 취하고 적절한 프로그래머 분량의 상식을 적용하고 자신의 요구에 맞는 것을 구축하는 것이 좋습니다.

원래 질문의 관점에서; 상황에 따라 많이 다릅니다. 내담자에게 갇힌 경우 (즉, 계약이 체결되어 있거나 대체 작업이없는 경우) # 2가 가장 어려운 방법입니다. 그렇지 않으면 일주일 안에 프로그래머로서 당신에게 완전히 쓸모없는 훌륭하고 상세한 사양이 제시 될 가능성이 높습니다.

위에서 언급 한 것과 같은 문제 (# 3)와 어쨌든 # 2를 해야하는 문제가 있습니다.

프로그래머가 되려면 다른 사람이 클라이언트가 필요로하는 것을 알아낼 때까지 기다렸다가

당신이되고 싶은 경우 개발자 , 그리고 이것이 당신의 클라이언트, 당신은 고객의 손을 잡고 함께 당신이 원하고 필요로의 교차점에서 행복 토끼 가득 초원을 찾을 때까지 부드럽게 가능성의 밀도 무서운 숲을 걷는다.

부록 :이 프로세스를 "시스템 분석 및 디자인"이라고도하며 컨설팅 을 무료로 수행해서는 안됩니다.

프로그래밍은 예비 적으로 사용자의 문제를 해결하는 것입니다. 따라서 사용자에게 효과적이고 만족스러운 솔루션을 제공하기 위해 "추가"노력과 고통을 겪으면 거의 항상 "추가"번거 로움을 피하고 결국에는 유용한 것을 제공하지 않습니다.

(물론, 원하는 것을 실제로 전혀 알지 못하는 실제 사용자가 있으며, 의미있는 결정을 내릴 수있는 상태로 만들 수있는 노력은 없습니다. 그러나 나는 대부분의 경우에 실제 문제, 그들은 해결하기 위해 노력과 현금을 기꺼이 쏟아 내고, 우리가 그들이 일하는 해결책에 더 가까이 도울 수 있다면 기쁠 것입니다.)

결론은 사용자의 문제를 해결하는 것입니다. 때로는 일부 대상 질문을하고 답을 알아낼 시간을 더 필요로 할 수도 있습니다. 때로는 긴밀한 협력으로 도메인을 함께 차트로 작성해야합니다. 때로는 간단한 스케치 / 프로토 타입 / 모형을 만드는 데 시간을 소비 한 다음 결과를 보여주고 "이것이 생각한 것과 비슷합니까?" (그들은 "실제로, 완전히 다른 무언가에 대해 생각하고 ..."라고 말할 때 프로토 타입을 버리고 시작합니다 ... :-)

실제 기술은 적시에 올바른 접근 방식을 선택하는 것입니다.

마지막으로, 제 경험상 좋은 솔루션은 거의 항상 개발자 측의 도메인 지식이 필요합니다. 이것이 없으면 사용자와 실제로 공통된 언어가 없으므로 제공하는 것이 실제로 유용하다는 보장은 없습니다. 사용자는 일반적으로 기술에 대한 단서가 없으므로 가능한 것과 불가능한 것과 다른 접근 방식 / 기능의 비용이 무엇인지 모릅니다. 우리는 그들이 기술을 충분히 자세하게 배울 것을 합리적으로 기대할 수 없기 때문에 다리 끝에서 그 단계를 더 나아가 야합니다.

이것은 "추가적"노력으로 보답을받지 못하지만, 두 가지 이유로 투자로 보는 것을 선호합니다.

• 좋은 솔루션을 제공하는 데 도움이됩니다. 장기적으로 개발자로서의 시장 가치가 높아지고
• 서로 다른 도메인은 완전히 구별되지 않으므로 해당 도메인 지식의 적어도 일부는 향후 공연에서 재사용 할 수 있습니다.

소프트웨어 개발자로서 귀하의 작업 중 일부는 소프트웨어가 사용될 도메인을 충분히 이해하는 것입니다. 따라서 프로젝트의 초기 단계에 참여하는 것은 시간과 고객 경험 측면에서 매우 중요합니다. . 예, 이는 철저한 도메인 및 요구 사항 분석을 의미합니다. 대상 사용자를 통합하고, 인터뷰하거나, 소프트웨어가 사용될 위치를 걸어 다니기에 완벽한 시간입니다.

그러나이 기술을 습득하는 것은 거의 예술적인 형태입니다. 특히 도메인이 엔지니어링 분야에 연결되어 있지 않은 경우에 특히 그렇습니다. 당신의 명백한 질문은 고객에게 어려워 보일 수 있으며, 현장에서의 존재는 원치 않을 수 있으며, 대상 고객의 사회적 구조에 대한 이해 부족은 여전히 ​​취약한 관계를 무너 뜨릴 수 있습니다.

이 단계의 복잡성을 이해하지 못하면 종종 소프트웨어 개발자와 고객 모두에게 실망하게됩니다. 우리는이 단계를 더 빨리 끝내거나 완전히 없애고 싶습니다. 결과는 종종 비참합니다. 서두른 시작 후 개발 중에 성공의 스테이크가 점점 높아지고 드로잉 보드로 돌아 가기가 더욱 어려워집니다. 시스템이 최종적으로 완성되고 수백만 달러가 소비되면 고객이나 엔지니어링 회사는 모두 실패를 인정하지 않아 실패한 시스템을 강제로 도입하게됩니다.

대안은 비즈니스 분석가가 당신을 위해 일하도록하는 것입니다. 이것은 일부 제품에 대해 합리적 일 수 있으며 분석가는 종종 중개자가 될 수 있지만 더 많은 통신 채널을 생성하므로 오류 가능성이 높아집니다.

어쨌든 : 코드를 다시 작성하는 것이 요구 사항을 다시 작성하는 것보다 결코 중요하지 않습니다.

추신 당신은 내가 폭포 방법을 옹호한다고 생각합니다. 나는 '빅 디자인 초기'를 믿는 사람은 아니지만 도메인 분석 노력이 구현 노력에 비례해야한다고 생각합니다. 다수의 사이클 (시제품, 릴리스 후보 등)을 만들 수 있습니다.

사용자가 개발자가 아닌 한 확실히 옵션 2 (옵션 2가 필요할 수도 있음).

대부분의 소프트웨어 개발 수명주기는 요구 사항 수집에 중점을 둡니다. 대부분의 사용자는 자신이 원하는 것을 알 수있을뿐만 아니라 가능한 것을 알지 못하므로 사용자와 협력하여 사용자에게 필요한 것을 이해하는 것이 중요한 소프트웨어 개발 작업입니다.

두 가지 옵션 을 모두 사용해야한다고 생각합니다 . 그들이 떠나고 그들이 원하는 것을 결정하게하십시오. 그런 다음 출발점으로 사용할 구체적인 아이디어가 있으면 요구 사항을 유용한 것으로 세분화하도록 안내하십시오.

그들이 원하는 것을 간신히 설명 할 수있을 때 옵션 # 2로 넘어 가고 싶지는 않습니다. 전체 프로세스가 느리고 좌절감을 줄 것입니다. 내 경험상 이것은 매우 드)니다). 그들이 그들의 아이디어를 함께 얻도록하십시오. 종이에 무언가를 적어두고 가능한 경우 기존 시스템의 관점에서 원하는 것을 설명하도록하십시오 (예 : "우리는 blahblah.com과 같은 웹 사이트를 원하지만 이러한 차이점이 있지만 제품 X와 같은 작업 A를 수행하는 도구를 원합니다.) UI도 작업 B를 수행해야합니다 ... "). 그런 다음 원하는 것을 시스템을 구축하는 데 사용할 수있는 매우 구체적인 요구 사항으로 구체화하는 것이 좋습니다.

일반적으로 고객은 자신이 필요하다고 생각하는 것이 무엇인지 정확하게 알게됩니다. 불행히도, 이것이 그들이 제공한다고 생각하는 솔루션으로 이끄는 문제를 설명하는 대신 그들이 당신에게 말할 것입니다.

그들의 요구를 충족시킬 무언가를 디자인하려면, 당신은 그 요구를 식별해야하며, 그렇게하려면 누군가가 클라이언트를 붙잡고 그 요구를 추출해야합니다. 다른 사람이 할 수 없다면 반드시해야합니다. (다른 누군가가 할 수 있다고 생각하면 나중에 그들 과 함께 앉아서 실제 요구를 추출 해야 할 수도 있습니다 ...)

여러 번의 회의를 통해 옵션 2를 사용하면 고객이 솔루션보다는 문제를 공유하도록 교육 할 수 있습니다. (클라이언트가 기술적 인 능력을 가지고 있더라도 (예를 들어,이 작업을 수행 할 수있는 능력이 없어서 대신이를 수행해야하는 경우에도) 최종 클라이언트에 적합하지 않은 구현에 여전히 집중하고있을 수 있습니다.) 어떤 개발 프로세스를 사용하든, 사양을 정의하는 방식으로 질문에 대답 할 수있을 때까지 몇 번이나 앞뒤로 이동해야합니다.

개발주기 초기에 가능한 빨리 결함을 포착하려고합니다. 코딩 또는 테스트가 아닌 요구 사항 동안이를 파악할 수 있으면 많은 시간을 절약 할 수 있습니다.

옵션 1은 일부 작업을 피하는 훌륭한 방법입니다. 작업이 불필요하다고 생각하거나 더 중요한 일을했을 때 사용했습니다.

첫째, 사용자는 컴퓨터가 무엇을 할 수 있는지 모릅니다. 대부분의 사람들은 컴퓨터와 계산을 이해하는 데 오랜 시간을 보냈으며, 다른 것들을 배우는 데 그 시간을 보낸 사람에게는 분명한 내용이 이해하기 어려울 수 있습니다.

둘째, 사용자는 필요한 것을 반드시 알 필요는 없으며 일반적으로 원하는 것을 알 수 없습니다.

현재 집을 살 때 인테리어 디자이너가 비유를하기 위해 인테리어 디자이너가 메인 (미국 최초, 영국 지상) 층의 객실에 벽 색상을 선택했습니다. 나는 그 색상을 직접 선택하지 않았을 것입니다. 나는 좋아 보이는 집을 원했고 그것을 얻었습니다. 디자이너가 내 말을 듣고 내가 말할 수있는 것을 주면 거의 나오지 않았을 것입니다.

사용자가 원하는 방식으로 필요한 작업을 수행 할 수있는 유일한 방법은 직접 작업하는 것입니다.