비전문가가 소규모 프로젝트에 대한 사양 작성을 어떻게 배울 수 있습니까?

비전문가가 소규모 프로젝트에 대한 사양 작성을 어떻게 배울 수 있습니까?

내 친구가 통계 프로젝트에서 일부 개발을 아웃소싱하려고합니다.

특히, 그는 많은 일을 탁월하게 수행하고 있으며, 현재 손으로하는 일을하기 위해 스크립트 작성을 아웃소싱하려고합니다.

그러나 내 친구는 매우 기술적이지 않습니다. 그는 기술 사양을 잘 작성하지 못했습니다.

그가 스펙을 작성할 때, 엑셀에서 무언가를 수행하는 방법을 기술합니다 (이 셀로 이동 한 다음 해당 셀에 값을 복사합니다). 또한 지나치게 장황하며 예제를 여러 번 수행합니다. 그가 코너 사건을 올바르게 묘사했는지 확실하지 않습니다.

그가 아웃소싱 한 첫 번째 프로젝트는 실패였습니다. 나는 그가 몇 가지 세부 사항을 설명했지만 코너 사례를 설명했습니다. 그 및 / 또는 그가 고용 한 코더는 모퉁이 사건을 생각하지 않고 적절한 질문을했습니다. 잘 모르겠습니다. 나는 그와 IM을 얻었고 설명하는데 5 분 이하가 걸리는 설명을 발굴하는데 30 분이 걸렸다. 나는 마지막에 그를 위해 스크립트를 작성했지만 코더와의 프로세스가 실패한 이유를 조사하지 않았습니다.

그는 나에게 도움을 요청했다. 그러나 나는 스펙을 받아 들여 명확한 요구 사항으로 변환하는 것이 명확하게 작성된 스펙을 실행하는 것보다 10 배 더 많은 작업을하기 때문에 참여를 거부합니다.

그가 배우는 올바른 방법은 무엇입니까? 그가 사용할 수있는 자원이 있습니까? 코더가있는 소규모 저압 연습 프로젝트에서 배울 수있는 방법이 있습니까?

그의 스크립트는 대부분 통계 및 데이터 처리에 중점을두고 있습니다. 예를 들어이 열을 가져 와서 평균을 계산하십시오. 이러한 조건에서이 행을 제거하십시오. 따라서 도전 과제는 웹 앱을 지정하는 것과 다릅니다.

이 문제에 대한 두 가지 가능한 접근 방식이 있습니다. 그러나 두 가지를 실현하는 것이 중요합니다. 첫째, 요구 사항 엔지니어링은 어려운 작업입니다. 아이디어를 시스템을 구축하기에 충분한 공식 사양으로 바꾸려면 많은 시간과 노력과 연습이 필요합니다. 둘째, 요구 사항이 정식 사양 (공식 사양에서 덜 공식적인 사용자 사례 및 사용 사례에 이르기까지) 인 경우 소프트웨어를 실제로 구축하고 바로 구축하는 것이 훨씬 쉽고 저렴하며 빠릅니다.

친구가 수많은 소프트웨어 도구를 만들거나 계약을 맺을 계획이라면 최소한 비즈니스 목표와 운영 개념 수준에서 소프트웨어 요구 사항을 작성하는 방법을 배워야합니다. 소프트웨어 요구 사항 엔지니어링에 관한 두 가지 주요 책은 Karl Wiegers – 소프트웨어 요구 사항 (제 2 판) 및 소프트웨어 요구 사항에 대한 추가 정보 : 핵심 문제 및 실용 조언 입니다. 나는 그가 고용하는 대부분의 사람들이 최소한 비즈니스 목표 나 운영 개념 수준에서 시스템을 설명하는 일종의 문서를 원할 것이라고 기대할 것이다. 또한 우수한 개발자가 프로젝트 초기에 통과 할 것으로 예상되는 요구 사항 엔지니어링의 다른 측면의 방법과 이유에 대해서도 설명합니다.

두 번째 옵션은 소프트웨어 개발 및 요구 사항 엔지니어링 경험이있는 사람을 고용하여 문제 공간을 이해하고 소프트웨어 솔루션이 필요한 위치와 소프트웨어 솔루션이없는 위치를 결정하는 것입니다. 유익하고, 문서를 작성하고, 개발 노력을 감독하거나 수행 할 수도 있습니다. 그러나 이는 요청한 시스템뿐만 아니라 요구 사항 및 아키텍처도 개발하기 위해 장기간 소프트웨어 개발자를 장기간 고용하는 데 더 많은 비용과 비용이들 것입니다.

솔직히, 나는 당신의 친구가 소프트웨어 개발 과정을 이해하지 못하는 사람에게는 흔하지 않다고 생각합니다. 또한 그 책임이 전적으로 그에게 있다고 생각하지 않습니다. 첫 번째 소프트웨어 프로젝트에 요구 사항이 충분하지 않은 경우, 아웃소싱 한 개발자는 요구 사항을 명확하게 설명하고 세분화하고 문서화해야합니다. 솔직히 말해서, 당신이 기꺼이 시간을 내거나 기술이 아닌 사용자 / 고객과 협력하고 좋은 기술 사양을 개발하려는 노력을 기울이지 않는다면, 당신이 참여할 올바른 사람인지 확실하지 않습니다. 엔지니어링 분야에서 요구 사항 엔지니어링을 수행하는 모든 사람의 주요 역할).

최적의 솔루션은 실제로 두 가지 옵션의 조합이라고 생각합니다. 당신의 친구 (그리고 아마도 당신도)는 요구 공학과 관련된 것이 무엇인지, 그리고 견고한 요구 사항이 프로젝트에 가져올 수있는 이점에 대해 알아야한다고 생각합니다. 소프트웨어 개발자는 요구 사항 엔지니어링 및 소프트웨어 프로젝트에 적합한 요구 사항을 도출, 문서화, 분석 및 관리하는 방법에 대해 더 잘 알고 있어야합니다. 이는 소프트웨어 수명주기의 어느 부분에서든 작업을 수행하는 모든 사람에게 유용한 기술입니다.

비 기술적 인 고객의 사양이 필요할 때 나는 보통 그들이 원하는 것이 무엇인지 평범한 언어로 작성하도록 요청합니다. "응용 프로그램은 C를 누를 때 A에서 B를 수행해야하지만 D 인 경우에만 수행해야합니다." "D가 의미하기 때문에 ..."에 대한 추가 보너스.

실제로 "이 칼럼을 가져 와서 평균 이상으로 실행하십시오." 올바른 방향으로 나아가는 단계입니다. 더 나은 설명은 "테이블에 이것과 저것이 포함되어 있습니다"(구조가 사전 정의 된 경우)입니다. "평균 X를 얻는다". 기본적으로 세부 사항을 잃지 않고 가능한 가장 기술적 인 방법입니다.

다시 말해, 구현이 아니라 아이디어를 설명하십시오.

그런 다음 돌보는 프로그래머는 자신이 위임 한 일의 실제 목적 을 이해하고 명백한 단계를 스스로 선택하여 명백한 것을 묻습니다.

충분히 신경을 쓰고 프로세스를 이해하는 사람이 없으면 프로젝트는 실패합니다.

그는 스토리 보드 방식을 사용해 볼 수 있습니다 .

응용 프로그램이 수행해야 할 것들 ( 이야기 ) 목록과 해당 목록 내에서 각 이야기의 기능에 대해 자세히 설명하게하십시오.

그는 Asana 와 같은 도구를 사용 하여 프로젝트 범위와 기능을 구체화하고 개발자와 상호 작용할 수도 있습니다.

명확한 요구 사항으로 변환하는 것은 명확하게 작성된 사양에서 실행하는 것보다 10 배 더 많은 작업입니다.

아멘. 또한 이유를 설명합니다.

그가 고용 한 코더는 코너 케이스를 생각하지 않고 적절한 질문을했습니다.

요구 사항을 이해하는 것은 대부분의 프로그래밍 프로젝트에서 가장 어렵고 비용이 많이 드는 부분입니다. 비전문가가 요구 사항을 작성할 때 대체하려는 해결 방법 만 문서화하는 경우가 많습니다 ( "Excel 열기, B3 셀 클릭 ..."). 그들이 기대할 수있는 최선은 현재의 어려움과 정확히 일치하는 것입니다!

이 문제를 해결하는 가장 생산적인 방법은이 사람이 유스 케이스 를 작성하도록 권장하는 것입니다 ( "사용"은 "느슨한"으로 운임). 요구 사항을 작성하는 대신 시스템 사용 방법을 설명하십시오. 이로 인해 개발자는 현재 사용자보다 더 나은 솔루션을 제안 할 수 있습니다.

이 문제는 친구 측의 저술 한 의사 소통 기술로 인해 악화 된 것 같습니다. 그는 아이디어를 효과적으로 전달하기 위해 작업을 수행하거나 프로그래머가 아이디어를 통해 정보를 얻을 수 있도록 비용을 지불해야합니다. 프로세스는 고통스럽고 시간이 많이 걸리지 만 직접 처리하는 것은 다른 사람에게 비용을 지불하는 것보다 저렴합니다.

어쨌든 이것은 창조적 인 사람들이 불완전한 아이디어를 가지고 있거나 백만 단어 미만으로 설명 할 수없는 일반적이고 실망스러운 어려움입니다. 이 사람은 자신이 실제로하려고하는 일을 기꺼이 해내 고이를 실현시킬 수있는 매우 참을성 있고 통찰력있는 프로그래머를 찾아야합니다.

그가 고용 한 코더는 ... 적절한 질문을하지 않았습니다.

이것이 재난의 요리법입니다. 그것은 또한 코더 가 요구할 것이라는 기대입니다 . 코더는 인센티브없이 습관을 잃을 것이라고 예상하는 것은 의사 소통을하지 않고 코딩하는 것을 매우 비현실적입니다.

친구가 일을 끝내고 싶다면 코더와 지속적인 의사 소통을하는 프로세스를 더 잘 수립하십시오. 코더가 아니라 그 역할을 적극적으로 수행 해야하는 친구입니다. "매주 월요일에 수행 된 작업을 보여주고 매주 화요일에이 문제를 논의하기 위해 2 시간을 설정하십시오."

• 소개를 위해 반복 및 민첩한 개발 방법론 (Wikipedia 기사가 수행 할 작업)에 대한 간단한 개요를 제공하여 이들이 어떻게 구성되는지에 대한 느낌을 갖도록하십시오.
   
• 과거 실패를 이해하는 데 도움이되도록 Waterfall / Big Design Up Front에 대한 간단한 개요를 제공하십시오 (비판을 포함하는 주제-다시 말하지만 Wikipedia 기사에서 수행함)-일반적으로 올바른 항목을 지정하는 것이 어려운 방법을 설명하는 꽤 좋은 작업을 수행합니다. 앞.

필자의 경험에 따르면 비 기술적 인 고객이 원하는대로 소프트웨어 작업을 수행 할 수있는 가장 신뢰할 수있는 방법은 기능 설명을 한 번에 지정하지 않고 영구적으로 통신하고 반복하는 것이 었습니다.

그의 스크립트는 대부분 통계 및 데이터 처리에 중점을두고 있습니다. 예를 들어이 열을 가져 와서 평균을 계산하십시오. 이러한 조건에서이 행을 제거하십시오. 따라서 도전 과제는 웹 앱을 지정하는 것과 다릅니다.

웹 앱을 지정하는 것보다 훨씬 간단합니다. 논리적 인 과정입니다. 이것은 쉬운 일입니다.

친구는이 과정을 수행 할 때 취해야 할 단계를 적어두면됩니다. 그는 원하는대로 할 수 있지만, 집중해야 할 핵심 사항은 정확성, 간결성 및 명확성입니다. 원고와 같은 텍스트로 순전히 할 수없는 이유는 없습니다. 구성 요소 또는 작업을 논리적으로 나누면 이점이 있으며 플로우 차트 또는 다이어그램으로 잘 작동 할 수 있습니다.

이제 친구는 유능한 분석가 / 개발자를 찾아서 서비스를 하나씩 제공해야합니다. 친구가 개발자와 만나서 진행 상황을 직접 확인해야합니다. 친구는 이러한 시연 동안 개발자에게 시간을 지불하지만 프로젝트가 사양에 맞게 실행되도록하는 것이 좋습니다. 사양에 대한 모든 변경 사항, 즉 친구가 생략 한 사항은 협상되어 견적 가격에 추가되어야합니다.

내가 '유능한'이라고 말한 것에 주목하십시오-유능하지 않은 '평균적인'개발자가 많기 때문에 이것은 '평균'과 같지 않습니다. 친구가 가장 저렴한 코더를 얻거나 온라인에서 누군가를 찾으면 문제가 생길 것입니다. 온라인에서 일하는 사람들은 좋지 않다고 제안하지는 않지만 추천 없이는 일을하지 않을 것입니다.

친구는 단순히 적합한 사람을 찾아야합니다. 모든 소프트웨어 프로젝트에는 분석가, 프로그래머, 시스템 관리자, 테스터 및 프로젝트 관리자가 필요합니다. 친구가 '아웃소싱'하기를 원하는 역할이 많을수록 제공자는 더 숙련되고 친구가 더 많이 지불해야합니다.

이것을 깨뜨리는 사람이되어 죄송하지만 공식적인 사양을 작성하는 방법을 배우는 것은 비전문가의 일이 아닙니다. 비 기술적 인 사람을 인터뷰하고, 그 사람이 당신이 무엇을하는지에 관해 당신에게 말한 것을 나누고, 고객이 정말로 원하는 것을 결정하는 것은 개발자의 일입니다. 항상 같은 것은 아니지만 상대적으로 비공식적 인 요구 사항 문서 (체계적으로 구성되었지만 클라이언트가 이해하지 못하는 전문 용어를 피하려고 시도하는 문서)를 작성하고 해당 문서를 클라이언트와 검토합니다.

고객이 비공식 요구 사항 문서에 만족하면 필요한 공식적인 요구 사항 사양을 작성하기위한 기초로 사용할 수 있습니다.

이 전체 프로세스를 "요구 사항 캡처"라고하며 소프트웨어 엔지니어링 프로세스의 첫 번째 단계를 형성합니다. 실제로 소프트웨어를 작성하는 것은 소프트웨어 엔지니어링의 비교적 작은 부분 일 뿐이며, 많은 소프트웨어 개발자가 슬프게도 잊어 버리는 사실입니다. 그들이 잊어 버린 또 다른 것은 모든 과정에서 고객과 의사 소통하고 대화를 유지하여 상황을 추적 할 필요가 있다는 것입니다.

비 기술적 인 사람들과 의사 소통하는 경우 컴퓨터와 전문 용어를 사용하여 대화 할 때 피하는 것이 매우 중요합니다. 이들이 자신의 분야에서 전문 용어를 사용하는 경우 이러한 용어의 의미를 이해하는 것이 중요하므로 이러한 용어에 대한 공식적인 정의를 얻으려면 프로젝트 용어집을 작성해야합니다. 당신은 결국 그들을 위해 일하고 있으므로 그들이 어디에서 왔는지 이해하는 것이 중요합니다.

전문 용어 대신에, 당신은 클라이언트와 의사 소통하는 위협적이지 않은 방법을 사용하려고 노력해야합니다. 평범한 영어로 작성된 문서는 도움이 될 수 있지만, 소프트웨어 비즈니스의 많은 사람들이 사람이 아닌 컴퓨터를 쓰는 데 익숙합니다. 어려운. 또한 고객은 언어가 아무리 평범하더라도 큰 종이 더미를 읽는 것을 좋아하지 않으므로 시각 보조 도구를 사용하는 것이 좋습니다. 다이어그램, 와이어 프레임 및 스토리 보드는 여기서 유용한 도구입니다.

요컨대, 핵심 요점은 언어를 배우는 것이 클라이언트의 일이 아니며 언어를 배우는 것이 당신의 일이라는 것입니다.