고객이 요청한 내용을 이해하는 것은 소프트웨어 개발자의 책임입니까?

예 / 아니오 질문의 종류와 이유는 무엇입니까?

고객이 자신의 요청으로 무엇을 의미했는지 이해하는 것은 소프트웨어 개발자의 책임입니까, 아니면 자신의 요청을 개발자에게 올바르게 설명하는 것은 고객의 책임입니까?

현재 상황은 "고객이 이미 우리에게 원하는 것을 설명했습니다. 더 많은 질문을하지 않고 요청을 이해하는 것은 귀하의 책임"입니다.

영어는 저의 강력한 모음이 아니지만 모든 요청은 잘못 배치 된 단어와 문장을 이해하기 어려운 모호한 영어로 작성되지만 일부 요청은 내 시스템의 사전 이해를 가정합니다.

저는 시스템의 3 번째 또는 4 번째 개발자입니다 (마지막 개발자가 일을 그만 두었습니다). 그러면 고객이 개발자 측에 대한 이해를 기대할 수 있습니다.

시스템 자체는 UI와 소스 코드 수준에서 상당히 지저분합니다. 이것은 원숭이 코딩처럼 보입니다-코드를 요청하면 실제로 요청을 이해하지 못하면서 요청을 올바르게받을 수 있기를 바랍니다.

나는 실제로 일을 그만 둘 생각을하고 있지만, 누가 옳고 그른지 확실하지 않다면 아직 결정하지 못했다.

이해하는 것이 당신의 일이라면, 할 때까지 질문을하는 것이 당신의 일입니다

당신이 요청하는 사람 수 고객에게 이야기에 당신을 금지하는 사람이 대신 질문에 스스로 답을하거나 당신을 참조해야합니다 그래서 (나는 종종 고객과 접촉했다 중간에 이야기) 고객이 아닌 사람이 될 할 수있는 사람.

그러나 결국 어떤 종류의 의사 소통이 있어야합니다. 그들이 그것을 거부하고 (그리고 당신이 이해하지 못하는 일부 문서를 제공하는 것이 효과적으로 의사 소통을 거부하는 것이라면), 당신의 전임자들이했던 것처럼 : 도망 가고, 빨리 도망 가야합니다.

고객과 상사가 지저분한 종이 흔적을 남기고 떠날 때, 당신이 할 수있는 유일한 것은 당신이 가진 것에서 가능한 한 많은 의미를 모으고, 어떻게 영어에 대한 지식을 구조화하기 위해 평범한 영어로 시나리오를 쓰기 시작하는 것입니다. 시스템이 작동해야합니다.

주어진 / 언제 / 그러면 시나리오를 통해 어떤 일이 발생해야하는지, 그리고 평범한 영어로 작성되고 구조화되어 있기 때문에이를 사용하여 상사 및 고객과 의사 소통 할 수 있습니다. 나는이 시점에 도달했고 여기서 시스템이 무엇을해야하는지 전혀 모른다. "

추가 설명을 요구할 때 간단하게 포기한 경우, 자신이 이해하고 이해하지 못하는 모든 것을 문서화하려는 노력을 기울 였음에도 불구하고 이전 개발자는 사양을 전달하는 방법을 몰랐기 때문에 실패한 것이 아니라 그렇게하는 것은 불가능합니다.

내 의견으로는 (고객과 개발자) 모두 문제와 그 해결 방법에 대해 동일한 이해 를 얻어야합니다 .

요청을 이해하지 못하면 솔루션을 작성할 수 없습니다.

따라서 사양을 읽어야합니다. 사양이 명확하지 않은 경우 (또는 서면 사양이없는 경우) 답변을 줄 수있는 사람이 있어야합니다.

비즈니스 질문에 답변 할 수있는 한 사람이있는 팀에서 일합니다. 이 비즈니스 소유자 는 고객 비즈니스 또는 고객 팀의 구성원을 알고있는 내가 일하는 개발 회사의 구성원입니다.

특정 상황에서 프로젝트 관리자는 고객이 동일한 질문을 여러 번 (개발자 이직으로 인해 필요) 여러 번 요청하면 고객이 화가 났을 것이라고 두려워하며 이는 자신과 회사에 제대로 반영되지 않을 것입니다.

물론 이러한 질문을하지 않으면 시스템을 완성 / 수정하는 데 시간이 훨씬 오래 걸리고 결과적으로 고객이 원하는 결과를 얻지 못할 수 있으며, 이로 인해 더 많은 지연이 발생하고 프로젝트 관리자와 고객에게 잘 반영되지 않을 수 있습니다. 적어도 고객의 눈에는

프로젝트 관리자가 질문을하지 않는 이유는 다음과 같습니다.

1. 그는 실제로 부정적인 결과를 이해하지 못하거나 그에 대해 부정하고 있습니다.
2. 그는 대안을 알고 있지만 고객이 성가신 질문보다 지연과 품질 저하를 받아 들일 가능성이 높다는 것을 알고 있습니다.
3. 그는 정치적 게임을하고있다. 아마도 그가 프로젝트를 곧 떠날 것이라는 것을 알고 그때까지 문제를 숨기고 싶거나 의사 소통 부족으로 인한 문제에 대해 당신을 비난 할 계획이다.

IMO 이유 2는 거의 없습니다. 이유 1을 제거하기 위해 대안을 설명하고 그 사이에 명시적인 선택을 요청하십시오. 고객에게 문제를 설명하여 성가심을 줄이십시오. 이유 3을 제거하기 위해, 서면으로이를 수행하여 잠재적 인 문제를 조기에 인식하고 수정하려고 시도했음을 증명할 수 있습니다. 그러나 솔직히 말해서, 이것이 필요하다고 생각되면 가능한 한 빨리 나가야합니다.

고객의 의도를 이해하도록하는 것은 항상 서비스 제공 업체의 책임이라고 생각합니다.

우리 분야의 전문가로서, 브리핑을 완료하는 것뿐만 아니라 우리의 서비스 사용 과정을 통해 고객을 안내하는 데 도움이되며,이를 통해 우리가 제공 할 수있는 가능성과 현재하는 일에 대해 교육합니다.

나는 고객 중심의 접근 방식이 절대적으로 일을하는 방법이라고 생각합니다. 그것은 시도되고 테스트 된 비즈니스 모델입니다.

고객과 개발자는 시스템에 대한 이해를 개선하기 위해 협력해야합니다.

소프트웨어 회사는 각 당사자에게 필요한 사항, 즉 계약의 기본 측면에 대해 고객과 계약을 체결해야합니다. "마음의 만남"이 없다면, 실제로는 계약이 없습니다.

당신이 유능한 프로그래머라고 가정 할 때, 사양이 명확하지 않다면 간단히 "요청을 이해하고 더 많은 질문을하지 않는 것은 당신의 책임입니다"라고 말하는 것은 어리석은 일입니다.

이것은 원래 질문에 대한 주석의 일부 새로운 정보를 기반으로합니다.

그 진술

고객은 이미 우리가 원하는 것을 설명했습니다. 요청을 이해하고 추가 질문을하지 않는 것은 귀하의 책임입니다.

프로젝트 리더가 제공합니다. 명시된 이론적 근거는

내가 시스템의 첫 번째 개발자가 아니기 때문에 더 많은 질문으로 고객의 대표자를 귀찮게하지 말고 필요한 경우 질문을 해석하는 데 더 많은 시간을 할애해야합니다

따라서 고객 이 피하려고하는 것은 고객에게 질문을하는 것 입니다.

"질문을 해석하는 데 추가 시간을 보내도록 요청"한다고 반드시 불합리한 것은 아닙니다. 고객이 실제로 말한 내용을 기반으로 요구 사항이 무엇인지 파악하기 위해 합리적인 노력을 기울이거나 약간 비합리적인 노력을 기울여야합니다. 다른 것이 없다면 그것은 귀중한 기술입니다.

실패하면 (그리고 여러 가지 이유로 이미 가지고있는 것처럼 들린다면) 프로젝트 리더에게 도움을 요청하십시오. 숙제를 끝냈다는 것을 보여 주면서 질문에 최대한 구체적으로 노력하십시오. 예를 들어

이 사람들 은 무엇을 원합니까 ??? "

다음과 같이 물어보십시오

요구 사항 문서의 17 절에서, foobar는 거품을 뿌려야한다. 이 세 가지 거품 중 어느 것이 그런 의미입니까? "

또는 요구 사항이 실제로 잘못 작성되어 해독 할 수없는 경우 그에게 알려주십시오.

요구 사항이 올바르게 이해되도록하는 것은 궁극적으로 프로젝트 리더의 책임이라고 말하고 싶습니다 (확실히 프로젝트가 성공하기 위해서는 그의 최선의 이익입니다). 그러나 팀원으로서 귀하는 그 책임 중 일부를 공유합니다. 당신이 스스로 노력을 기울 였다는 것을 보여주고 프로젝트 리더가 당신을 돕기를 거부한다면, 그는 전적으로 당신의 책임이되었습니다. 그것이 그 시점에 도달하면, 그가 그것을 알고 있는지 확인하십시오.

완벽한 세상에는 어딘가에 기능과 사양의 목록이 있어야합니다.이 목록에는 회사와 고객이 계약 한 계약서에 작성된 것이 있습니다.

귀하의 질문에 대답하기 위해 개발자는 고객이 원하는 것을 실제로 이해하고 문서가 있어야 양 당사자가 동일한 비전에 동의 할 수 있습니다.

물론, 이것은 완벽한 세계가 아니며 종종 사양이 없으며, 서면 사양이 없으면 글쎄, 어려울 것입니다. 귀사에 고객과의 관계 대의원으로 일하고 고객이 원하는 것을 이해하도록 도울 수있는 사람이 있습니까?

그렇지 않다면, 당신의 입장에서, 나는 당연히 과제를 이해했다고 가정하고 이전 개발자로부터 정보를 얻으려고 노력할 것입니다.

요구 사항을 이해하는 사람을 지정하는 실제 역할은 이러한 변수 중 일부에 따라 다릅니다.

• 팀 규모
• 회사 표준
• 보스가 일하는 방식
• 팀원 간의 다른 전문성

따라서 한 사람으로 구성된 팀이라면 요청을 최대한 처리하기 위해 모든 노력을 기울여야합니다. 진행중인 프로젝트를 처음 사용하는 경우 고객과 다시 요청을 처리하기 위해 노력해야합니다.

편집 : 가장 중요한 것은 고객이 요구 사항이 불충분하다는 것을 알지 못할 수 있으며 요구 사항을 수집하는 프로세스는 길고 지루하지만 종종 중요한 프로세스이며 다른 사람이 없기 때문에 귀하에게 해당되는 경우 그들과 함께하십시오.