클라이언트 커뮤니케이션의 일반적인 실수: 클라이언트를 좌절시키지 않는 방법

누군가가 프로젝트를 요청할 때 우리는 그것이 매우 중요하고 그들이 당신이 작업할 제품에 대해 깊은 관심을 갖고 있다고 가정해야 합니다. 따라서 클라이언트는 최종 제품에 대해 많은 기대를 해야 하므로 배송에 관해서는 감정적일 수 있다고 가정하는 것이 안전합니다.

프로젝트가 진행되는 동안 클라이언트는 제공된 기능에 대해 매우 흥분하고 당신을 사랑할 수 있으며, 다음 날에는 작동하지 않는 무언가가 발견되고 그 애정이 사라진다는 것을 알게 될 것입니다. 대부분의 경우 클라이언트 커뮤니케이션이 잘못되었을 뿐입니다.

원격 소프트웨어 개발에 있어 성공을 위한 비법은 없지만, 저는 당신의 손에 많은 신뢰를 주는 클라이언트와 건전하고 생산적인 관계를 유지하기 위해 피해야 할 몇 가지 사항이 있다고 믿습니다.

고객과의 기본 커뮤니케이션에 실패하지 마세요

동료, 친구 또는 예의를 베풀고 싶은 다른 사람과 매일 의사 소통하는 것처럼 고객과의 의사 소통을 상상해보십시오.

오랜 친구가 집을 방문하고 몇 주 후 정오에 "예전 장소에서" 현지 별미를 즐기기로 동의한다면 그냥 거기에 나타나시겠습니까? 그 동안 연락을 유지하고 며칠 전에 미리 전화를 걸어 확인하시겠습니까? 아니면 그들이 너무 바빠서 아무 이유 없이 그들을 귀찮게 하고 싶지 않다고 생각할까요? 그들이 도착하면 알려줄 것이라고 기대하시겠습니까?

할 이야기가 많지 않으면 매일 채팅을 계속할 가능성은 없지만 예의와 실용성을 위해 어떤 형태의 의사 소통을 유지합니다. 상대방이 당신이 그들을 잊어 버렸다고 생각하는 것을 원하지 않습니다. , 하지만 정당한 이유 없이 시내를 가로질러 운전하고 싶지는 않을 것입니다.

어느 시점에서는 오랜 파트너 및 동료와도 전문적인 의사 소통에서 비슷한 상황을 경험했을 것입니다. 일부 프로젝트는 간단한 점심을 확인하기 위해 "평소에 정오에 거기에서 만나요"라고 말하는 것처럼 최소한의 의사 소통으로 실행됩니다. 무슨 일이 일어나더라도 상대방이 반드시 알려줄 것이고 당신은 일정을 조정하는 데 동의할 것입니다.

그러나 소프트웨어 개발의 세계에서 상황은 그렇게 단순하거나 선형적이지 않습니다.

프로젝트 작업을 시작하는 경우, 특히 새로운 고객을 상대할 때 그들이 당신에게서 소식을 듣지 못한다면 그들은 당신의 일과 헌신에 대해 다시 생각하기 시작할 것입니다. 몇 주 후에 완벽한 제품을 보여주더라도 고객은 이미 귀하에 대해 이상적이지 않은 인식을 갖고 있을 수 있습니다.

가끔 어색하게 느껴질 때도 있지만, 평소에 보고할 일이 없더라도 클라이언트와 이야기하는 것은 나쁘지 않습니다! 사용자 스토리의 작은 부분에 대해 의문점이 있습니까? 그것이 중요하다고 생각되면 그들에게 알려주십시오. 조금 늦어서 약속한 예상 날짜를 맞출 수 있을지 확신이 서지 않습니까? 고객에게 최대한 빨리 전화하십시오! 그들은 그것에 대해 즉시 듣는 것이 좋습니다.

의심의 여지가 없고 프로젝트가 완벽하게 예정대로 진행되고 있는데 클라이언트가 말을 많이 하지 않습니까? 며칠에 한 번씩 진행 상황을 설명하는 이메일을 보내면 어떨까요? 이메일이 누구에게도 성가신 일이 아니기 때문에 아무런 해를 끼치지 않을 뿐만 아니라 진행 상황을 문서화하고 클라이언트와 정기적인 의사 소통을 유지하게 됩니다.

잘못된 클라이언트 커뮤니케이션은 비현실적인 기대를 조장합니다.

그래서 처음에는 클라이언트가 프로젝트에 대해 많은 기대를 가질 수밖에 없다고 말씀드렸죠? 오른쪽. 기간.

클라이언트는 이미 제품에 많은 것을 기대하고 있습니다. 생각한 대로 되지 않으면 클라이언트는 필연적으로 좌절할 것입니다. 그렇다면 왜 사람들은 자신이 제공할 수 있는 것보다 더 많은 것을 약속하여 훨씬 더 비현실적인 기대를 만들까요?

여기에 빠른 병렬이 있습니다. 온라인으로 태블릿을 구입하고 10일 배송을 약속했습니다. 8일 만에 가게에서 문제가 있다고 해서 일주일 정도 배송을 미룬다. 귀하의 불편을 보상하기 위해 소매업체는 $75 스토어 크레딧을 제공할 것을 약속합니다.

어쨌든 앞으로 며칠 동안은 그 태블릿이 정말로 필요하지 않았을 것입니다. 그래서 당신은 그것이 좋은 거래라고 생각합니다! 이제 태블릿을 즐길 수 있을 뿐만 아니라 스토어 크레딧을 사용하여 자녀에게 좋은 것을 사줄 수 있습니다. 그러나 상점은 모든 것이 하룻밤 사이에 정리되었다고 다음 날 전화를 겁니다.

다음 날 태블릿을 받을 수 있습니다. 추가 사항 없음, 스토어 크레딧 없음. 이제 좌절한 건 너야 !

"뭐? 어제 당신은 내가 더 나은 거래를 얻을 것이라고 말했다! 그건 불공평하네요! 이미 애들한테 말했는데..."

며칠을 되돌리면 어쨌든 태블릿 만 기대했습니다. 아무도 당신에게 더 나은 거래를 약속하지 않았다면 다음 날 도착했을 때 장난감에 만족했을 것입니다. 하지만 지금 당신은 가게에서 알려주기로 한 결정 외에는 아무 이유 없이 놓치고 있는 것처럼 느껴집니다.

개발자, 특히 프리랜서는 클라이언트와 의사 소통할 때 유사한 상황을 어떻게 피할 수 있습니까?

정신을 차리지 않고 처음부터 생각나는 모든 것을 말함으로써. 제안은 금지되지 않습니다. 실제로 요청한 특정 기능이 당면한 문제를 해결하는 데 그다지 좋은 옵션이 아니라고 생각하는 경우 매우 환영합니다. 그러나 핵심은 다음과 같습니다 . 먼저 생각하십시오.

• 클라이언트의 말을 들어보세요.

• 그들의 문제를 분석하십시오.

• 제안된 솔루션을 분석합니다.

• 예산/일정 내에 있는지 확인하십시오.

• 마지막으로 제안을 제출하십시오.

이것이 클라이언트 의사소통 기술이 까다로울 수 있는 이유입니다. 처음 네 단계 중 하나만 실패하면 결국 귀하의 시간을 낭비하게 될 수 있고 더 나아가 클라이언트의 시간도 낭비할 수 있기 때문입니다.

클라이언트가 필요로 하는 것을 알고 있다고 가정하지 마십시오

Mary Schmich, '17학번 신사 숙녀 여러분: 고객의 말을 들어보십시오. 미래에 대한 조언을 하나만 제공할 수 있다면 고객의 의견을 경청하는 것입니다.

프로젝트에 부름을 받았다면 누군가가 필요하기 때문입니다. 그리고 그 필요성에 대해 고객보다 누가 더 잘 알겠습니까? 당연한 것 같지만 현실 세계에서 사람들은 종종 그것을 잊어버립니다.

예를 들어보겠습니다. 소매업체는 자신의 비즈니스를 위한 "소프트웨어 시스템"을 요청합니다. 그것을 보자마자 당신은 그들이 원하는 것이 사용 가능한 모든 제품을 등록하고, 모든 구매를 기록하고, 고객을 위한 영수증을 생성하고, 주기적으로 판매된 것과 품절된 품목에 대해 보고하는 것이라는 결론에 뛰어듭니다. 스톡.

따라서 첫 번째 미팅에서 효율적임을 보여주고 준비한 것, 제안된 기능, 상점의 시각적 아이덴티티에 어울리는 기본 디자인 등을 제시하고 싶습니다. 그러나 어리둥절한 고객은 실제로 필요한 것은 특정 브랜드와 제품의 수익을 높이는 것을 목표로 선반에 제품을 더 잘 표시하는 방법을 계산하는 알고리즘이라고 말합니다.

여기서 오류는 단순히 해결해야 할 문제를 식별하지 못한 것입니다. 물론 이 경우에는 프로젝트 초기였기 때문에 바로잡을 시간은 충분하겠지만, 가끔 이런 실수가 계속해서 발생하기도 합니다. 이전 예만큼 과감할 수는 없지만 여전히 프로젝트 및/또는 고객과의 관계에 해를 끼칠 수 있습니다.

내 제안은 다음과 같습니다. 미래의 사용자와 가능한 한 많이 이야기하고 프로젝트의 다양한 이해 관계자와 상담하십시오. 그들은 상황에 대한 좋은 개요를 가지고 있고 그들이 필요로 하는 것이 무엇인지 알고 있습니다. 그들이 현재 하고 있는 모든 단계를 파악하고 소프트웨어가 어떻게 유용할 수 있는지 설명하십시오. 나는 고객이 원하는 것을 이해하려고 할 때 내 목표는 거의 스스로 일을 수행할 수 있도록 하는 것이라고 말하고 싶습니다. 이 지점에 가까워지면 진정으로 그들의 필요가 무엇인지 알게 된 것입니다.

클라이언트가 무엇을 요구하는지 이해하지 못함

당면한 문제에 대한 일종의 문서를 받는 것은 드문 일이 아닙니다. 때로는 상위 수준의 설명일 뿐인 반면 다른 경우에는 사용 사례 및 비즈니스 규칙이 포함된 자세한 문서입니다. 어쨌든 기록이 아무리 명확해도 거기에 기록된 모든 것이 절대적인 사실이라고 가정하는 것만으로는 할 수 없습니다.

뭐???

정확히. 첫째, 어떤 것은 특정한 맥락에서 누군가에게는 하나의 의미가 될 수 있고, 그 현실에 속하지 않는 사람들에게는 완전히 다른 의미가 될 수 있습니다. 그리고 당신과 클라이언트 사이에 공통점이 없다면 그것은 바로 맥락입니다!

둘째, 모든 사람이 매우 숙련된 작가는 아닙니다. 그들은 A라고 말하려고 하지만 결국 B를 묘사합니다.

그래서, 당신이 보낸 모든 것을 읽은 후, 당신이 읽은 것이 정말로 그들이 의미한 것인지 어떻게 확신할 수 있습니까? 글쎄, 당신은 모든 것을 소화하고, 몇 가지 메모를 작성하고, 모든 것을 분석하고… 회의를 소집할 것입니다. (보시죠? 소통이 전부입니다!) 회의에서 문제에 대해 이야기하고 이해한 내용을 자신의 말로 설명합니다. 이 단계에서 오해를 식별할 수 있을 것입니다.

“아, 그런데 제 경우에는 서류가 하나도 없었어요. 나는 클라이언트와 함께 앉아서 메모를 하는 동안 모든 것을 설명했습니다.”

글쎄, 당신이 그것이 의미하는 바를 이해했다는 보장은 없으며 내 제안은 여전히 ​​유효합니다. 메모에 시간을 할애하고 전체 문제에 대해 생각하고 모든 것을 가급적이면 일종의 이벤트 타임 라인에서 정리한 다음 다시 전화/회의하십시오. 당신이 이해한 것을 제시하는 클라이언트. 반복적으로 들릴 수도 있지만 때로는 클라이언트조차도 특정 작업을 수행하는 데 관련된 모든 프로세스에 대한 완전한 비전을 갖고 있지 않고 소프트웨어가 얼마나 복잡해야 하는지 알게 될 것입니다.

마지막으로 모호함이나 오해가 없는지 확인해야 합니다.

고객이 생각하지 않고 요구하는 모든 것을 제공하면 안 되는 이유

자, 이제 고객의 말을 듣고 이해한 내용을 확인해야 한다는 것을 알았으므로 계속 진행하여 고객이 요청한 모든 작업을 수행할 수 있습니다. 그렇죠?

잘못된!

이제 마침내 당신이 가진 모든 경험을 사용할 수 있고 스스로에게 물어볼 수 있는 순간입니다 . 고객이 요청한 것이 문제를 해결할 수 있습니까? 그들이 당신에게 요구한 것이 정말로 그들에게 필요한 것입니까?

"아니오"라는 대답이 몇 번이나 나오는지 알면 놀랄 것입니다.

고객이 요청한 것을 전달하기 전에 문제를 분석해야 하며, 고용주가 제안한 내용에 동의하지 않는 경우 이를 명확히 하는 것은 귀하의 직업이자 전문적인 책임입니다. 물론, 그들의 제안이 좋지 않다고 생각하는 이유와 이러한 단점을 해결하기 위해 대안적 접근 방식이 무엇을 할 것인지 설명해야 합니다. 다시 한 번, 커뮤니케이션이 핵심입니다.

귀하와 고객이 합리적이라면 솔루션을 계속 진행하거나 더 나은 솔루션을 찾기 위해 브레인스토밍 세션을 가질 것입니다(어떤 이유로 고객이 귀하의 아이디어를 수용할 수 없는 경우).

프로토타입 - 방대한 문서를 작성하지 마십시오

나는 이미 당신과 당신의 고객이 일반적으로 같은 관점을 가지고 있지 않다고 말했습니다. 그렇죠? 따라서 문서에 대한 귀하의 이해에 영향을 미치는 것처럼 귀하가 서면으로 전달하는 내용에 대한 이해도 영향을 미칩니다. 그것도 맥락의 문제다.

따라서 어떻게든(높든 낮은 수준에서든) 개발하려는 내용을 문서화해야 한다는 데 동의합니다. 그러나 시각적 요소 없이 여러 페이지의 텍스트를 전달하는 것은 그다지 도움이 되지 않습니다. 클라이언트는 그것을 읽는 데 지루해하고 주의를 기울이지 않을 것이며 아마도 복잡한 비즈니스 규칙이 의미하는 바를 이해하지 못할 것입니다. 아니면 그들은 당신이 상상했던 것과 완전히 다른 것을 해석할 것입니다.

고객에게 기술적 배경이 없는 경우 이러한 오해가 더욱 악화될 수 있음을 명심하십시오.

이러한 모든 요소는 동일한 문제가 있는 결과를 초래할 수 있습니다. 고객은 제품을 배송할 때 고객이 염두에 둔 것이 아닐 가능성이 높기 때문에 불평할 것입니다.

내가 제안하는 것은 다음과 같습니다 . 계획이 무엇인지 그리기 위한 스케치일지라도 항상 프로토타입을 만드십시오. 그리고 어떤 정의를 내려야 하든 거기에서 시작하십시오. 참조를 만들고 단순하게 유지하십시오.

고객이 옳다고 설득하는 데 시간을 낭비하지 마십시오.

나는 모든 개발자가 다음과 같은 상황을 겪었을 것이라고 거의 확신할 수 있습니다. 프로젝트가 시작될 때 클라이언트는 “소프트웨어의 배경색이 노란색이어야 합니다. 이미 이사회에서 합의했다”고 말했다. 그런 다음 소프트웨어가 배달되면 "아, 하지만 배경색은 노란색일 수 없습니다. 녹색이어야 한다고 말했잖아!” 자, 어떻게 대처해야 할까요?

확실히, 어떤 경우에도 당신이 옳고 그들이 틀렸다고 주장하는 것은 아무 소용이 없을 것입니다. 무엇이든, 그것은 당신과 클라이언트 모두에게 힘든 시간을 줄 것입니다.

당신이 같은 페이지에 있는지 확인하고 서면 흔적을 남기기 위해 고객과의 의사 소통에 대한 좋은 기록을 항상 유지하는 것이 좋습니다. 대부분의 경우 간단한 문제라면 "저희가 회의에서 동의한 대로 시스템 배경이 노란색이 될 것입니다." 라고 고객에게 이메일을 보낼 수 있습니다. 그리고 미래에 고객이 마음을 바꾸면 이메일에 언급된 회의 때문에 그렇게 했다고 주장할 수 있지만 실제로 수정해야 하는 경우 추가 x시간 동안 실행할 수 있습니다. (때로는 추가 x 달러).

그러나 당신이 옳았다는 것을 증명할 것이 없다면 아마도 당신은 결정을 내려야 할 것입니다(또한 배울 교훈): 현재 아키텍처를 변경해야 하거나 다른 기능에 영향을 미칠 정도로 큰 변화입니까? 그렇지 않다면, 그냥 진행하고 클라이언트를 옆에 두는 것이 가장 좋습니다(그러나 다시는 그런 일이 일어나지 않도록 눈을 크게 뜨고). 그렇다면 고객과의 대화가 최상의 솔루션이 될 것입니다. "당신이 옳았던 방법"이 아니라 "현재 문제를 해결할 수 있는 방법"에 초점을 맞추는 것이 아닙니다.

어쨌든 큰 수정을 가하지 않는 가장 좋은 방법은 짧은 시간에 짧은 새 기능을 제공하는 것입니다. 따라서 변경해야 할 사항이 있다면 이미 존재하는 것의 주요 변경 사항은 아닐 것입니다.

기한을 지켜야 할 때를 아십시오.

마지막으로 가장 큰 실수 중 하나는 클라이언트에게 프로젝트를 완료할 기한을 정하는 것입니다. 그리고 그들은 당신이 그 실수를 저지르도록 애원할 것입니다!

물론 클라이언트로서 지난 몇 주(몇 달?) 동안 논의한 멋진 기능을 모두 언제 사용할 수 있는지 알고 싶습니다. 그러나 프로젝트는 정의된 제품이 아니기 때문에 개발이 시작되고 소프트웨어를 사용할 준비가 될 때까지 많은 일이 발생할 수 있습니다.

첫째, 예측할 수 없는 것은 예측할 수 없습니다. 예상하지 못했던 일을 겪게 될 가능성이 매우 큽니다. 클라이언트가 약속한 라이선스로 제때 구매하지 않았거나, 사용해야 하지만 출시해야 하는 시점에 출시되지 않은 다른 내부 소프트웨어, 처음에 동의한 환경과 다른 환경이 있을 수 있습니다. 또는 클라이언트가 (몇 가지) 기능에 대해 마음을 바꿨고 몇 가지 작업을 다시 해야 했습니다.

그 중 어느 것도 실제로 개발자의 잘못이 아니며 프로젝트의 마감일에 깊은 영향을 줄 수 있습니다. 그러나 당신이 기꺼이 고객을 기쁘게 하기 위해 모든 것을 언젠가는 배달하겠다고 약속했지만 모든 정당한 이유로 그렇게 하지 않는다면, 내가 보장할 수 있는 한 가지는 고객이 적어도 조금은 , 좌절스러운. 프리랜서라면 이 Toptal 엔지니어링 블로그 기사에서 설명하는 것처럼 시간을 효율적으로 관리해야 합니다. 고객 관계 관리도 당신의 일이라는 것을 잊지 마십시오.

따라서 자신과 프로젝트에 의존하는 사람에게 호의를 베풀고 최소한 모든 것을 개발하는 데 걸리는 시간에 대한 추정치를 제공하되 기한이 아닌 추정치일 뿐이라는 점을 항상 분명히 하십시오.

또한 (특히 이미 견적을 내렸을 경우) 항상 고객에게 예상보다 시간이 오래 걸리면 알려서 도움을 줄 수 있도록 강력히 제안합니다.