원하는 것을 모르는 고객과 협력

최근에 기존 시스템에서 작업하는 작업을 시작했습니다. 새로운 코드뿐만 아니라 조정 및 업데이트가 필요합니다. 나는 지금 프로젝트를 추가하는 몇 가지 유지 관리 / 기능을 수행했으며 그중 일부는 실제로 요청 된 것과 크게 다릅니다. 그래서 요청자가 원하는 곳으로 가져 오기 위해 항목을 여러 번 프로그래밍해야했습니다.

이제 기능을 프로그래밍해야하는 것이 마음에 들지 않습니다. 그러나 프로젝트의 소요 시간을 줄이고 싶습니다. 병목 현상은 요청자가 수행해야 할 작업에 대한 요청자의 인식에있는 것으로 보입니다. 요청자가 더 빨리 필요한 것을 파악하기 위해 내가 할 수있는 일에 대한 아이디어가 있습니까?

몇 가지 조언 :

• 해결책이 아니라 문제를 경청하십시오 . 많은 고객들이 문제를 해결하는 방법을 알려 드리고자합니다. 듣지 마세요. 당신은 프로그래머이고 문제에 대한 해결책을 찾는 것이 당신의 일입니다. 대신 고객이 겪고있는 문제에 귀를 기울이고이를 해결하는 가장 좋은 방법을 찾으십시오. 다른 사람들이 말했듯이, 고객은 그들이 원하는 것을 실제로 알지 못하며 때로는 고객에게 먼저 보여줘야합니다.

• 질문하십시오 . 질문을 마치면 더 물어보십시오. 고객은 실제로 생각하지 않기 때문에 세부 사항을 거의 발표하지 않습니다. 필요한 정보를 얻는 유일한 방법은 정보를 빼내는 것입니다.

• 서면으로 받기 고객과의 상황에 따라, 고객이 제공 한 내용이 "요청한 내용이 아닌"방법에 대해 불평하기 시작하는 것이 나중에 중요 할 수 있습니다. 다른 정보가 없으면 세부 사양을 작성하면 필요한 모든 정보를 확보하고 고객과 고객 간의 모호성을 해소 할 수 있습니다.

• 의사 소통이 핵심 입니다. 클라이언트와 대화하고 정보를 얻거나 코드를 작성하지 않고 대화가 끝날 때까지 대화하지 마십시오. 항상 고객과 연락하십시오. 과정 전반에 걸쳐 질문하십시오. 진행 상황을 보여주고 피드백을받습니다. 장기적으로 모든 사람의 삶을 편하게 해줄 것입니다.

당신이 의사 소통을하는데 도움을 줄 수있는 거의 모든 자조 책은 이것에 대한 변형을 줄 것입니다 :

• 먼저 이해를 구한 다음 이해를 구하십시오

이것은 7 가지 습관 책에서 비롯된 것이지만 모두 " 능동적 인 듣기 "방법의 변형입니다 . 목표는 이해하는 것이 아니라 이해 한 내용으로 다시 전달하는 것입니다.

필요한 것이 무엇인지 잘 알고 있다고 생각하면 ( 구현 세부 정보를 설명하기 시작하면 특히 원하는 것을 피하십시오-그것이 당신의 일이 아닙니다) 시스템을 사용하는 다양한 사람들의 이야기 예제를 제공합니다. 그들과 함께 지브.

그런 다음, 일단 기능을 본 후에는 그것이 정확히 그들이 원하는 것이 아니라는 것을 깨달을 것으로 기대합니다. 모든 것을 유연하게 유지하십시오. 유일한 상수는 변화입니다. 나는 일반적으로 첫 번째 빠른 업데이트 후 두 번째 빠른 업데이트 후에 거친 가장자리의 대부분을 처리하지만 항상 도달 할 수없는 이상적인 것에 거의 무조건 접근하고 있습니다. 결국 당신은 중요하지 않은 것들이 더 높은 가치의 목표로 나아가도록해야합니다.

나는 너의 고통을 느낀다....

나쁜 소식은, 정확히 어떤 종류의 고객을 처리 하느냐에 따라 평소와 같이 비즈니스가 될 수 있습니다.

일반적인 일반적인 문제는 기본적으로 클라이언트가 원하는 것을 모르는 것 입니다. 이들은 일반적으로 비즈니스 목표 측면에서 달성하고자하는 목표를 알고 있지만 소프트웨어 솔루션 측면에서 어떻게 보일지 모릅니다. 따라서 많은 경우에 클라이언트가 계속 마음을 바꾸고 솔루션을 조정하고 다시 조정하기를 원하기 때문에 프로젝트가 초기 예상 시간보다 5 배 이상 튀어 나오는이 반복주기를 경험하게됩니다. 그렇습니다. 최종 결과가 초기 목표와 완전히 다른 것으로 변형되는 것은 드문 일이 아닙니다.

나는 몇 년 전에 이런 일이 일어났다는 서사시를 보았습니다. 코드 작성에 10 주가 걸렸던 프로젝트는 15 개월의 반복 반복으로 바뀌 었습니다. 이 경우 주로 클라이언트 회사의 다른 관리자와 부서가 서로 다른 것을 원했기 때문에 작업을 계속 되돌려 서 조정하고 다시 조정했습니다 (소프트웨어는 구독 기반이며 주요 클라이언트였습니다). 우리의 재정적 인 피부는 없었습니다-실제로 큰 기술적 성가심).

기본적으로 내 조언은 다음과 같습니다.

이것이 특정 산업과 이러한 고객의 방식 (큰 IF)이라면 익숙해 지십시오. 그것을 민첩하고 유지 보수 지향적 인 직업이라고 생각하십시오 (이것이 내 현재 공연이 얼마나 많거나 적은 지입니다). :)

이것이 일이 의도 된 방식 이 아니고 긴 처리 기간 동안 비난을 받고 있다면 상사에게 이야기하십시오. 통신 문제가 있으며 클라이언트에서 제공하는 사양이 원하는 솔루션을 구현하기에 충분하지 않다고 설명하십시오. 고객이 원하는 것을 제공하기 위해 필요한 정보를 모두 얻지 못하는 경우 고객이 원하는 것을 제공하지 않았다는 비난을 받고있는 상황에서 자신을 찾기를 원하지 않습니다.

우선, 고객은 고객이 볼 때까지 원하는 것을 실제로 알지 못한다는 사실을 받아 들여야합니다. 그들은 지금 당신에게 특징 X가 필요하다고 말할 수도 있습니다. 그들에게 특징 X를 보여 주면 그들이 정말로 필요한 것은 특징 Y 또는 특징 X의 다른 변형이라는 것을 알게 될 것입니다.

고객이 실제로 원하는 것을보다 빨리 파악할 수있는 좋은 방법은 커뮤니케이션 및 고객 협업에 중점을 둔 Agile Manifesto 를 수용하고 따르는 것 입니다. 개발주기를 반복으로 나누고 반복이 끝날 때마다 기능의 프로토 타입을 클라이언트에게 표시하십시오. 이렇게하면 기능에 너무 많은 리소스를 투자하지 않고도 클라이언트의 피드백에 따라 즉각적인 피드백을 받고 변경할 수 있습니다. 그렇게하면 귀하와 고객 모두 제품의 결과에 만족할 것입니다.

팀이나 회사에서 전환이 어려울 것이라고 확신하지만 빠르게 변화하는 요구 사항에 대처하는 가장 좋은 방법 중 하나입니다.

많은 이야기와 비슷한 이야기가 여기에서 찾을 수 있습니다 . 다른 개발 회사의 하청 업체로 일한 적이 없어도 원하는 것을 정확히 알고있는 고객을 찾지 못했습니다.

나는 그들이 원하지 않는 것을 피하거나 피하고 싶은 것을 정말로 잘 알고있는 누군가와 함께 일할 수있어서 행복하다. 나는 보통 그곳에서 그들이 좋아하는 일을 할 수 있습니다.

내 경험은 주로 응용 프로그램 / 플랫폼 개발에 있습니다. 고맙게도 웹 디자이너처럼 미학적 문제를 다루는 일은 거의 없습니다.

많은 성가신 재 작성 후에, 나는 이제 내가 완전 공개라고 부르는 것을 운영합니다.

따라서 고객 요구 사항과 요구 사항을 논의한 후에는 항상 고객이 원하는 것을 인식하고 해당 요구 사항을 이행하는 방법을 작성합니다. 그런 다음 내가 작성한 것을 보내어 그들이 일을 시작하기 전에 긍정적 인 대답을 할 때까지 기다립니다.

대규모 프로젝트 (5 일 이상 일하는 경우)도 프로토 타이핑합니다. 이것은 그들에게 엄청난 코드 변경없이 마음을 바꿀 수있는 기회를줍니다.

항상 작동하지는 않지만 적어도 나는 고객이 마음을 바꾸고 잘못 구현하지 않는다는 것을 알고있는 위치에 있습니다.