HCBBS Forum (한국어)
Submit Chemical Projects / Find Solutions
Amplify Your Requirements on a Broader Chemical Platform *Engineering · Technology · Equipment · Solutions*
Submit Request

디자이너라면, 이런 입주자를 만났을 때 어떻게 해야 할까요?

2016-05-04View Original

Thread Content

디자인원에서 일하면서 최근 프로젝트를 진행하다가 이런 발주처를 만났습니다. 우선, 그 발주처의 사람은 매우 훌륭했습니다. 비록 발주처의 고위 임원이긴 했지만, 성격이 매우 온화하여 거만한 태도는 전혀 없었습니다;하지만 그 리더는 소유주 측에서 다른 분야의 업무를 담당하고 있었기 때문에, 공학 설계에 대해서는 거의 아는 바가 없었으며, 매우 무시하는 태도를 보였습니다. 그는 항상 “이건 아주 간단한 일이야!”라고 말했습니다그리고 그가 제시한 요구사항들은 듣기만 해도 화가 나요~~ 원글 작성자는 기술 분야에 종사하는 여성이지만, 업무를 수행할 때는 소통이 매우 중요하다는 것을 잘 알고 있어요. 계속해서 소통해야 한다는 거죠.하지만 이런 상황에서는 정말 어떻게 대화를 나누어야 할지 모르겠어요저는 영업에 관한 책을 읽은 적이 있는데, 그 책의 요지 중 하나는 “고객과 논리적으로 다투지 마라”는 것이었습니다(아무도 잘못한 사람이 되고 싶어 하지 않기 때문입니다).하지만, 그에게 이성적으로 설명하지 않는다면, 어떻게 그가 제 생각을 받아들이도록 할 수 있을까요?해천의 여러분, ** 조언을 부탁드립니다.(영업 담당자나 매니저 등 전문가분들의 답변을 특별히 환영합니다).여러분, 감사합니다!분명히 **점수가 올라요.
Reply #22016-05-04
서명하고 날인하라고, 그가 요구한 것으로, 문서로 기록하고 그 자신의 서명을 요구했다.중요한 요청은 공식 도장을 찍어야 하며, 각자 자기 책임이니 어쩔 수 없습니다. 확실한 서면을 가지고 있어야만 상사와 대화할 수 있습니다.그러면 중간에 끼게 되어서, 어느 쪽도 아닌 처지가 될 거예요.
Reply #32016-05-04
맞아, 바로 이 방법이야.백지에 하나하나 명확하게 적어 내려가세요. 세부적일수록 좋습니다.이것은 사실 양측 모두에게 보호가 되어, 나중에 다툼을 피할 수 있습니다.
Reply #42016-05-04
당신의 설명을 들어보면, 이 리더는 분명히 의뢰처 측에서 상당한 권위를 가진 인물로, 말에 무게가 있어서 종종 결정적인 의견을 내릴 수 있는 위치에 있습니다. 그래서 성격상으로는 단호한 편이며, 일단 결론을 내리고 나면 반대 의견을 받아들이려 하지 않습니다. 하지만 평소에는 매우 겸손하고 거만하지 않은 성격입니다. 이런 설명은 다소 모순되어 보이는데, 독단적이면서도 겸손한 이러한 모순된 성격이 한 사람에게서 나타난다는 것은 실제로 다루기 어려운 문제입니다. 그렇다면 두 가지 측면에서 접근해 보는 것이 좋겠습니다. 하나는 2층 선배의 방식을 따르는 것인데, 사소한 일이라도 그들이 제시하는 모든 요구사항을 명문으로 명시하여 서명과 도장을 찍는 것입니다. 이렇게 하면 분쟁을 피할 수 있을 뿐만 아니라, 당신이 말한 그 리더의 성격상 이로 인해 곤란을 겪지도 않을 것입니다. 또 다른 측면은 평소의 교류를 통해 더 많이 접촉하며, 친구처럼 자연스럽게 소통할 수 있는 상대적으로 평등한 환경을 만드는 것입니다. 점차적으로 그 사람을 여러분의 실제 업무 현장에 초대하여, 여러분의 업무 과정과 어려움들을 이해하도록 해야 합니다. 사람들 간의 소통에서 가장 큰 문제는 서로를 이해하지 못하고, 허황된 상상으로 인해 생기는 오해들입니다. 만약 그 사람이 여러분과 여러분의 업무상의 문제들을 이해한다면, 소통하는 데 그렇게 어려움을 겪지 않을 것입니다.
Reply #52016-05-04
소통이 단연 가장 중요하죠. 서명이나 도장을 강요해서 상사에게 잘못을 인정하라고 할 수 있나요?제 생각에는 최악의 방법입니다.상대방 회사에서 리더를 설득할 수 있는 사람을 찾아, 여성의 장점을 충분히 활용해 부드러운 방법을 쓰는 것이 삶에서 필요합니다.
Reply #62016-05-04
리더, 특히 전문가가 아닌 리더는 애초에 최종 결정만 내리면 되고 구체적인 문제에 대해서는 언급해서는 안 됩니다. 결정을 내리기 전에 준비 작업을 철저히 해서, 리더가 선택지만 고르면 되도록 하세요. 구체적인 문제에 대해서는 아래의 엔지니어와 직접 상담하는 것을 권장합니다. 그렇지 않으면 답답할 수 있습니다
Reply #72016-05-04
매우 현실적인 방법이다.이 사람은 우리와 다투지는 않는 편이지만, 항상 자기 멋대로 생각하고 상황을 제대로 이해하지 못해요;입술 운동을 더 많이 해야겠어요.감사합니다!
Reply #82016-05-04
당신의 의견에는 그다지 동의하지 않습니다.서명하고 날인하는 것은 나중에 책임을 회피하지 않기 위한 것이지, 잘못을 인정하도록 강요하기 위한 것이 아닙니다.상대방 회사에 가서 이 리더를 설득할 사람을 찾는 건가요?이건 좀 위에 고자질하는 것 같은 느낌이에요.하지만, 도와주셔서 정말 감사합니다!
Reply #92016-05-04
나도 그렇게 하고 싶지만, 현실적으로는 전문가가 아닌 사람들과 소통해야 하는 경우가 많아요.나는 자기중심적이고 우월감에 사로잡힌 입주자들을 견딜 수 없어요. 비록 그들이 발주처라 할지라도 말이죠.
Reply #102016-05-04
모든 일에 서명해야 하는 것은 좋지 않다고 생각해요. 다른 사람들의 반감을 살 수 있거든요. 제 방식은 모든 것을 이메일로 소통하는 것이지만, 서명은 하지 않습니다.문제가 생기면 모두 이메일을 확인하게 되고, 입주자도 회피할 수 없으며, 다른 사람들도 이를 더 쉽게 받아들입니다.
Reply #112016-05-05
몇 가지 자료와 이유를 나열하여 그에게, 당신이 하는 것의 근거가 자신의 막연한 상상에서 비롯된 것이 아니라고 말해야 합니다
Reply #122016-05-05
몇 가지 자료와 이유를 나열해서, 당신이 그 일을 하는 근거가 자신의 막연한 상상에서 비롯된 것이 아니라고 말해줄 수 있습니다
Reply #132016-05-05
소유주가 내놓은 생각에는 분명 이유가 있을 것이며, 신중하게 고려한 결과이거나 경험에 기반한 것일 테니, 먼저 대화를 나누어 그의 생각을 들어본 다음, 그가 고려하지 못한 요소들을 추가로 알려주어 그를 자신의 생각으로 이끌면 그도 받아들이기 쉬울 것입니다.앞으로의 업무에서 당신의 일을 더욱 지원해 줄지도 모릅니다.소통의 목적은 상대방을 이기거나 자신이 더 우월하다는 것을 증명하는 것이 아니라, 업무를 위해, 그의 업무와 이익을 위해 하는 것입니다. 말할 때에는 입장을 명확히 해야 하며, 당신의 입장이 곧 그의 입장이 되어야 합니다. 당신의 지적과 제시한 근거를 통해 그가 스스로 자신의 생각을 보완하게 만드는 것이 바로 성공입니다.소통은 정보가 더해지는 과정이지, 이쪽이 장점이고 저쪽이 단점인, 서로 틀리다고 하는 과정이 아닙니다. 말할 때는 긍정적인 단어를 많이 사용하세요.또한 대화할 때는 오직 사안에만 집중해서 이야기하면, 그는 당신이 상당히 노력했다고 생각할 것이며 진지하게 고려해 줄 거예요.
Reply #142016-05-05
저도 그런 경험이 있습니다. 프로젝트 설계가 완료된 후 현장에 파견되어 공사를 지원할 때였는데, 발주처의 고위 임원도 설계에 대해 잘 이해하지 못했습니다. 약간의 문제가 생기면 변경을 요구했고, 공사팀도 그걸 무리한 요구라고 생각했습니다. 결국 규정을 위반하지 않는 선에서 그의 요구대로 변경을 진행했지만, 반드시 그 사람이 직접 서명하고 도장을 찍어야 했습니다.
Reply #152016-05-05
2층 의견은 글쓴이에게 유리해 보이며, 뒤의 몇 개 게시물에는 찬성하는 사람들이 많습니다.하지만 소인은 동의할 수 없습니다. 우선 글쓴이는 집주인이 “정말 좋은 사람”이라고 긍정적으로 평가했으며, 이로써 좋은 기반이 마련되었습니다. 건물 주인은 글쓴이를 “화나게” 할 만한 요구를 했으며, “아주 쉬운 일”이라고 생각했다. 소유주가 그 기관의 고위 임원이 될 수 있었던 것은 분명 특출난 점이 있기 때문일 것입니다.제시된 “화나게 하는” 요구에는 분명 이유가 있을 것이다. 이렇게 말하는 것을 권장합니다. “잘 말씀하셨습니다. 기술 요구사항(또는 추가 사항)에 적어주시면, 저는 그 기술 요구사항에 따라 처리하겠습니다.”” 기술 문서는 분명 관련 기술 인력이 담당하게 될 테니, 당신은 ‘전문가’들과 소통하고 협의할 기회를 갖게 될 것입니다. 화내지 마세요!
Reply #162016-05-05
디자인 업계에서 일하다 보면 대체로 이런 리더를 마주치게 되는데, 리더와 소통하는 것이 가장 우선적인 방법입니다. 만약 발주처와 좋은 협력 관계를 구축하고 싶다면, 리더의 요구사항을 그대로 거부하거나 리더가 틀렸다고 직접 지적하지 않는 것이 좋습니다. 리더의 합리적이든 비합리적이든 하는 요구사항에 대해서는 다양한 디자인 근거, 즉 규범, 법률, 법규 등을 충분히 준비해야 합니다. 이것이 가장 설득력이 있습니다. 그 다음으로는 디자인 매뉴얼에 나와 있는 일반적인 지식과 경험도 근거로 활용할 수 있습니다. 원활한 소통을 통해 리더의 고집이나 완고함을 해결할 수 있습니다. 어차피 그 사람이 리더가 될 수 있었다는 것은 능력이나 배경 덕분일 테니, 설령 공사에 대해 잘 모른다 하더라도 적어도 무엇이 합리적이고 무엇이 비합리적인지, 옳고 그름을 구분할 수는 있을 것입니다. 또한 책임 문제도 있습니다. 리더의 요구사항이 서명과 도장이 찍혔다고 해도 그것만으로는 디자인의 근거가 되지 않으며, 효력이 없습니다. 마치 살인을 의뢰했는데 누가 무죄가 될 수 있겠습니까... 디자인 측면에서 큰 영향을 미치지 않고 합리적인 요구사항이라면 서명과 도장을 받아내는 것이 좋습니다. 이는 디자인 작업의 일정을 맞추기 위함입니다. 비합리적인 요구사항이라면 가능한 한 타협할 방법을 찾아서 그 요구사항의 장단점을 명확히 설명해 주면 됩니다. 분명히 이런 문제들도 잘 처리할 수 있을 것입니다 :) 개인적인 의견입니다. 마음에 들지 않으면 댓글 남기지 마세요:lol
Reply #172016-05-05
여러분은 기술을 다루는 일을 오랫동안 해오고 있군요.인정세계도 이해하지 못하면서, 상사에게 서명하고 도장 찍게 하다니??네, 서명이 무엇을 증명하죠?문제가 생기면 누가 책임을 져야 할지, 당신인지 아니면 그 사람인지 모르겠어요. 그때 상황을 수습할 수 없고 돈도 받지 못하면 어떡하죠? 혹시 정말 문제가 생기면, 당신을 찾을 수 없게 되면 어떻게 될까요?이런 리더를 만났을 때는 그에게 빈칸 채우기 문제를 주어서는 안 되며, 선택지가 있는 문제를 주는 것이 좋습니다.다음에 문제가 생기면 그에게 당신의 결정을 말해주고, 두 가지 선택지를 주어서 그 중 하나를 고르게 하면 됩니다. 그러면 그도 기뻐할 거예요.또한, 한두 번만이라도 중요한 문제에 있어서는 자신의 의견을 고수해야 합니다. 하지만 그와 함께 해결책과 그 이유도 제시해야만 합니다. 그래야 상사가 당신이 무한정 양보할 수 있는 사람이 아니라는 것을 이해할 것입니다.중요한 것은, 당신이 문제를 제기하는 사람이 아니라 문제를 해결하는 사람이라는 점을 이해해야 한다는 것입니다.
Reply #182016-05-05
당신은 인정세태를 너무 잘 아는 건가요? 서명과 날인에는 회의록, 기술 부록 등의 형태가 있을 수 있다. 보기문제든 객관식이든 자신이 통제할 수 있는 것이 아니에요. 왜냐하면 때로는 상대방의 요구가 특별하거나 갑자기 제시될 수도 있기 때문입니다. 때로는 처음에는 열심히 올려주다가, 서명을 하라고 하면 바로 자동으로 줄어듭니다.
Reply #192016-05-05
중요한 변경 사항들은 반드시 회의를 통해 논의한 후 회의록을 작성하여 양측이 서명한 뒤 보관해야 합니다. 평소에 제기되는 변경 사항들은 발주처가 공사 연락서 형태로 제출하여 설계사무소에 피드백할 수 있으며, 이는 발주처 측의 변경 사항에 해당합니다. 이렇게 하면 향후 분쟁이 생기는 것을 방지할 수 있습니다!

Submit a Project

**Looking for Chemical Technology, Equipment & Solutions?** No Registration Required Broader Platform Exposure | Global Chemical Service Provider Connections

Submit Request — Free Consultation

Disclaimer

This is an automated machine translation of the original thread. Some technical terms may have inaccuracies; the original text shall prevail. Click "View Original" at the top right to access the source page, which supports IP-based automatic real-time language translation. Please watch out for contact details and sales inducements to prevent fraud. All content and translations are for reference only, representing solely the poster's personal views. For enquiries, email service@hcbbs.com.