일상 업무에서“올바르게”와“최대한 빨리”사이에서 어떻게 균형을 유지합니까? [닫은]

나는 때때로이 질문에 대해 반복해서 생각하고 있습니다. 유지 관리하기 쉬운 깨끗하고 이해하기 쉽고 올바른 코드를 작성하는 것이 올바른 방법입니다. 그러나 내가 한 일은 패치에 패치를 작성하는 것입니다. 단지 시간이 없기 때문에 고객이 기다리고 있습니다. 버그는 밤새 고쳐야합니다. 회사는이 문제로 돈을 잃고 있습니다. 매니저는 열심히 압박하고 있습니다.

나는 장기적으로이 패치들에 더 많은 시간을 낭비하고 있지만,이 시간이 수개월에 걸친 작업으로 아무도 신경 쓰지 않는다는 것을 잘 알고 있습니다. 또한 내 관리자 중 한 사람이 말했듯이 "지금 수정하지 않으면 장기적인 문제가 있는지 알 수 없습니다."

나는이 끝없는 실제 / 이상적인 선택주기에 갇힌 유일한 사람이 아니라고 확신합니다. 동료 프로그래머 여러분,이 문제에 어떻게 대처하십니까?

업데이트 :이 흥미로운 토론에 대해 모두 감사합니다. 많은 사람들이 매일 코드의 수량과 품질 사이에서 선택해야한다는 것은 슬픈 일입니다. 그럼에도 불구하고 놀랍게도 많은 사람들이이 전투에서 이길 수 있다고 생각하므로이 격려에 감사드립니다.

실제로 이것은 정답이 없기 때문에 매우 어려운 질문입니다. 우리 조직에서는 더 나은 코드를 생성하기 위해 더 나은 프로세스를 도입했습니다. 우리는 그룹으로서 코드를 작성하는 방법을 반영하기 위해 코딩 표준을 업데이트했으며 매우 강력한 테스트 / 리 팩터 / 디자인 / 코드 루프를 제정했습니다. 우리는 지속적으로 또는 최소한 시도합니다. 최소한 2 주마다 이해 관계자를 보여줄 것이 있습니다. 우리는 우리가 소프트웨어 장인이며 사기가 높다고 생각합니다. 그러나 이러한 모든 수표와 균형에도 불구하고 동일한 문제로 인해 어려움을 겪고 있습니다.

하루가 끝나면 유료 고객에게 제품을 제공합니다. 이 고객은 현실적이든 아니든 요구와 기대를 가지고 있습니다. 영업 팀은 종종 수수료를 받기 위해 문제를 일으 킵니다. 때때로 고객은 계약을 체결하더라도 비현실적이거나 수요 변화에 대한 기대감을 가지고 있습니다. 타임 라인이 발생합니다. 스프린트 동안 PTO 및 손실 된 일이 발생할 수 있습니다. 우리가 "올바로해라"또는 "빨리해라"라는 수수께끼에 빠진 상황에서 모든 종류의 작은 일들이 끝날 수 있습니다. 거의 항상, 우리는 "최대한 빨리"해야합니다.

소프트웨어 장인, 개발자, 프로그래머, 직업을 코딩하는 사람들은 "올바르게하는"것은 우리의 자연스러운 성향입니다. "최대한 빨리해라"는 우리 대부분이하는 것처럼 우리가 생존하기 위해 일할 때 일어나는 일입니다. 균형이 어렵다.

나는 항상 일정, 팀 및 수행중인 작업을 방어하기 위해 경영진 (소프트웨어 개발 이사 및 해당 그룹의 적극적인 개발자)에게 접근하여 시작합니다. 일반적으로 그 시점에서 나는 고객에게 지금 그것을 가지고 있어야하며 작동해야한다고 들었습니다. 협상이나 기부의 여지가 없다는 것을 알고 나면 돌아가서 팀과 협력하여 어떤 코너를 잘라낼 수 있는지 확인합니다. 고객의 요구를 최대한 빨리 이끌어내는 기능에서 품질을 희생하지는 않지만 무언가가 진행되어 다른 스프린트로 밀려날 것입니다. 거의 항상 괜찮습니다.

버그가 너무 많아서 전달할 수없는 경우 코드 품질이 나 빠지고 악화되고 타임 라인이 짧아지면 내가 설명한 것과 다른 상황에있는 것입니다. 이 경우 현재 또는 과거의 잘못된 관리, 나쁜 코드 품질로 이어진 나쁜 개발 관행 또는 기타 요인으로 인해 사망자가 발생할 수 있습니다.

여기에 제 의견은 좋은 코드와 모범 사례를 방어하기 위해 최선을 다해 회사를 도피하기 시작하는 것입니다. 단 한 명의 동료가 경영진에 대해 그룹의 의견을 경청하거나 방망이를 가지지 않는다면 새로운 일자리를 찾기 시작할 때가되었을 것입니다.

결국 실생활은 모든 것보다 우선합니다. 개발중인 제품을 판매해야하는 회사에서 일하는 경우 매일이 절충이 발생합니다. 초기에 좋은 개발 원칙을 달성하려고 노력해야 만 코드 품질 곡선을 능가하는 데 성공했습니다.

개발자와 영업 사원 간의 밀고 당기는 농담을 떠올리게합니다. "중고차 판매원과 소프트웨어 판매원의 차이점은 무엇입니까? 적어도 중고차 판매원은 그가 거짓말을하고 있다는 것을 알고 있습니다." 턱을 위로 올려 놓고 "옳은 일을"하려고 노력하십시오.

제가 경력에서 깨달은 한 가지는 항상 제대로 할 시간 이 있다는 것입니다 . 네, 관리자가 밀고있을 수도 있습니다. 클라이언트가 화 났을 수도 있습니다. 그러나 그들은 일이 얼마나 오래 걸리는지 모른다. 당신 (당신의 개발자 팀)이 그것을하지 않으면, 그것은 끝나지 않습니다. 당신은 모든 레버리지를 보유합니다.

실제로 관리자가 귀 하나 고객을 화나게하는 원인 을 알고 있기 때문에 ? 품질이 나쁩니다 .

이것은 내가 "영원한 갈등"(비즈니스와 엔지니어링 사이)으로 생각하기 시작한 것으로 요약됩니다. 나는 결코 사라지지 않는 문제이기 때문에 해결책이 없지만 완화에 도움이되는 것들을 할 수 있습니다.

• 가치 전달

사람들이 종종 깨닫지 못하는 것은 엔지니어로서 "성공적인 비즈니스"의 문제가 항상 주어진다고 가정합니다. 우리는 코드가 훌륭하고 깔끔하고 유지 관리 가능해지기를 원하므로 더 나은 코드로 방해 받았던 기괴한 프린지 사례를 발견하여 새로운 기능을 추가하고 기존 기능을 신속하게 조정하고 최소한의 고객으로 QA를 수행 할 수 있습니다. 고객을 유지하고 기능과 섬세함을 갖춘 경쟁력을 유지하는 사람은 누구도 충분히 빨리 생산할 수 없습니다. 좋은 코드가 직접 코드를 직접 작성하고 더 나은 코드를 원하는 이유를 알려주는 비즈니스 성공입니다.

철자를 쓰세요. "우리는 Y로 인해 비즈니스에 부정적인 영향을 미치지 않으면 서 코드베이스에서 X를하고 싶습니다." "

개선이 효과가 있다는 확실한 증거를 얻으려고 최선을 다하십시오. 앱의 일부 하위 집합을 개선하여 기능 / 개선이 더 빨라진 경우 증거를 위해 사용중인 백 로그 도구를 확인하고 적절한 회의에서 지적하십시오.

• 같은 빌어 먹을 페이지에서 팀을 잡아

자아는 종종 문제입니다. 엔지니어링 팀이 매우 나쁘게 필요한 한 가지는 자신의 쿨 에이드 주르 컵을 더 잘 아는 모든 사람들에 대해 특정 유형의 문제를 해결하기위한 일관된 접근 방식의 가치를 확립하는 것입니다. 다른 사람의 선호도가 당신보다 나쁘다는 것을 믿어도 괜찮지 만 그의 접근 방식이 실행 가능하고 이길 수없는 논쟁이라면 일관성을 중요하게 생각합니다. 일관성을 위해 타협하는 것이 중요합니다. 일관된 방법이 일반적으로 가장 빠른 방법이기 때문에 일이 일관되면 잘못하기가 더 어렵습니다.

• 올바른 도구를 선택하십시오

프레임 워크 / 툴셋 / 라이브러리 / 무엇의 두 학교가 있습니다. "내가 당신을 원하지 않을 때 방해하지 말고 내가 실제로 원하는 것들로 DIY를 매우 빠르고 일관되게 도와주십시오." 스틱 원리보다는 당근에 사용하는 것이 좋습니다. " 두 번째 것을 좋아하십시오. 비즈에게 "우리 자신의 도구가 우리를 허락하지 않기 때문에 우리는 이것을 할 수 없습니다"라는 말은 결코 받아 들일 수없는 대답이며 질문은 항상 사소한 / 일회용 제품 엔지니어링. 내 경험상, 융통성이없는 도구는 거의 항상 활짝 열리거나 부주의하게 작업하여 유지 관리 할 수없는 커다란 거대 쓰레기를 만듭니다. 보다 더 자주하지, 유연하고 쉬운 솔루션 수정은 단기적으로 거의 또는 거의 빠릅니다. 올바른 도구를 사용하여 빠르고 유연하며 유지 관리가 가능합니다.

• 엔지니어가 결정하지 않은 경우 FFS는 도구 선택에 대한 엔지니어의 의견을 얻습니다.

나는 이것이 개발자 관점의 질문이라는 것을 알지만 제로 엔지니어 입력으로 기술 결정이 내려진 너무 많은 상황에 처해 있습니다. 도대체 무슨 일이 있다는 것입니다? 예, 누군가 최종적으로 전화를해야하지만, 기술 담당자가 아닌 경우 영업 사원이나 데모 사이트가 자체 제품에 대해 말한 것이 아니라 자격을 갖춘 의견을 얻으십시오. 사람들이 똑똑하지 않아도되거나 개발자를 자신으로부터 보호하기 때문에 돈을 절약 할 수 있다고 약속하는 것은 더럽고 더러운 거짓말입니다. 신뢰할 수있는 인재를 고용하십시오. 스택 또는 기타 기술 솔루션에서 원하는 것을 철자하고 기술 밴드 왜건을 결정하기 전에 입력을 진지하게 받아들입니다.

• 구현보다 디자인에 집중

도구는 구현을위한 도구이므로 도움이 될 수 있지만, 우선 순위는 해당 아키텍처를 구축하기 위해 가지고있는 장난감 세트에 관계없이 아키텍처 여야합니다. 하루가 끝나면 KISS와 DRY 및 .NET 또는 Java 또는 무료 또는 빠지지 않는 것 이상의 문제에서 확장되는 모든 훌륭한 철학이 있습니다.

• 우려 사항 기록

비즈 측이 나쁜 방법을 고집 할 때, 특히 비용이 많이 드는 이유를 말한 부분을 이메일로 저장하십시오. 모든 예측이 이루어지고 심각한 비즈니스 피해 문제가 발생하면 엔지니어의 우려를 더 심각하게 받아 들일 수있는 많은 논란이 생깁니다. 그러나 신중하게 시간을 내십시오. 타오르는 불길의 한가운데는 화재 코드를 따르는 데있어 "I-told-you-so"가 안 좋은시기입니다. 화재를 진압하고 이전에 무시한 우려 사항 목록을 회고 회의 / 대화에 가져 와서 실제 사람들의 이름이 아닌 공학적 우려에 대해 표현하고 무시한 이유와 이들이 무시 된 이유를 이해 한 이유에 계속 집중하십시오. 무시하기로 결정했습니다. 당신은 엔지니어입니다. 사람들이 아니라 문제를 해결하십시오. " 우리는 Y 문제로 이어질 까봐 X에 대한 우려를 표명했습니다. 우리는 Z에게 말하고 그것을 다루는 것을 연기했다. "

하나의 솔루션 만 있습니다. 리팩토링을 위해 프로젝트 / 작업 시간의 약 10-20 %를 예약하십시오. 경영진에게 정당한 일임을 확신시키기 어려운 경우, 코드 유지 보수 비용을 리팩토링하지 않으면 시간이 지남에 따라 기하 급수적으로 증가 할 것입니다. 관리자와의 회의에서이 논문을 뒷받침하기 위해 몇 가지 지표 / 기사 / 연구 결과를 얻는 것이 좋습니다. :)

편집 :이 백서에 언급 된 "리팩토링 및 유지 관리 비용 상승"에 대한 유용한 자료가 있습니다. http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

올바른 일을 할 시간이있을 때마다 사용하십시오. 가능한 최고의 코드를 작성하고 꾸준히 개선하십시오. 불필요하게 벌리고 필요가 없을 때 기술 부채를 도입하여 일을 더 힘들게하지 마십시오.

심각한 버그 수정을위한 비상 전화는 스스로 통제 할 수있는 것이 아니며, 문제가 발생했을 때 최대한 빨리 대응해야합니다. 물론 전체 업무가 비상 전화로 구성되어 있고 일을 제대로 할 시간이 충분하지 않다는 인상을 받았다면 소진 할 길에 서서 상사와상의해야합니다.

그래도 도움이되지 않는다면, "Scotty의 전략"은 여전히 ​​올바른 일을하기에 충분한 시간을 확보하는 것입니다. 모든 추정치에 4를 곱하십시오.

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

저는 제 업무가 프로젝트에 허용 된 시간 제한 내에서 가능한 최고 품질의 소프트웨어를 제공하는 것으로보고 있습니다. 품질 수준이 낮을 지 걱정되면 프로젝트 소유자와 계약을 체결합니다. 본인은 우려 사항을 설명하고 해당 주에 소프트웨어를 배포 할 때 발생할 수있는 잠재적 위험에 대해 논의합니다. 이 시점에서 다음 세 가지 중 하나가 발생합니다.

1. 프로젝트 소유자는 위험을 감수하기를 원하지 않으며 일정을 다시 변경하여 소프트웨어 품질에 더 많은 시간을 할애 할 수 있습니다.

2. 프로젝트 소유자는 위험을 감수하고 싶지 않지만 일정을 되돌릴 수는 없습니다. 이 경우 애플리케이션의 주요 부분에 대한 소프트웨어 품질에 더 많은 시간을 투자하기 위해 프로젝트 범위에서 제거 할 기능 / 기능에 대해 협상해야합니다.

3. 프로젝트 소유자는 위험을 감수하고 저품질 소프트웨어는 예정대로 나갑니다. 때로는 아무 것도 배포하지 않거나 늦게 배포 할 때의 비즈니스 위험이 저품질 소프트웨어를 배포 할 때의 비즈니스 위험보다 훨씬 크므로 프로젝트 소유자 만 결정을 내릴 수 있습니다.

소프트웨어 작성은 초상화를 그리는 것과 매우 유사합니다. 초상화가 "올바른"또는 "완벽한"것으로 말하는 것은 불가능합니다. 완성은 적입니다. 말 그대로 단일 방법으로 작업하는 데 1 개월을 소비 할 수 있지만 일부에서는 여전히 "완벽한"것으로 간주되지 않습니다. 내 직업은 고객이 만족하는 인물 사진을 그리는 것입니다.

모든 경우에 해당되는 것은 아니지만 문제가 긴급하게 해결되어야하는 생산 중단 문제인 경우이 전략을 사용하여 운이 좋았습니다. 프로덕션 운영을 위해 빠른 수정을 수행 할 시간과 향후 품질 수정을 수행 할 시간을 예측하십시오. 상사 / 고객에게 견적을 제시하고 두 사람 모두에게 시간을 승인하십시오. 그런 다음 긴급한 시간 압력이 해제되면 신속하게 수정 작업을 수행하고 장기 수정 작업을 즉시 래프터로 수행합니다. 이번에 작업을 올바르게 수행하기 위해 필요에 따라 제시하면 임시 수정을 할 수있을 때까지 고객이 그 접근 방식을 좋아하는 것처럼 보입니다. 다시 실행되고 장기적인 관리가 필요합니다.

최적의 균형은 제대로 수행함으로써 제거하는 버그를 수정하는 것보다 낭비하는 데 추가 시간을 더 소비하는 것일 수 있습니다. 용액에 금도금을하지 마십시오. 대부분의 경우 올바르게 수행 된 폭스 바겐 솔루션은 캐딜락 솔루션만큼 좋습니다. 캐딜락이 필요한 것으로 입증되면 나중에 업그레이드 할 수 있습니다.

모범 사례를 따르지 않는 코드를 수정하는 데 종종 더 오래 걸립니다. 호출이 abcde ()처럼 보일 때 null이 어디에서 오는지 찾으려면 시간이 오래 걸릴 수 있습니다.

DRY를 적용하고 기존 코드를 재사용하는 것은 일반적으로 다른 솔루션을 코딩하고 테스트하는 것보다 훨씬 빠릅니다. 또한 변경 사항이 발생할 때 쉽게 적용 할 수 있습니다. 두 개, 세 개 또는 20 개가 아닌 하나의 코드 세트 만 변경하고 테스트하면됩니다.

견고한 기본 코드를 목표로합니다. 완벽하게 만들기 위해 많은 시간을 낭비 할 수 있습니다. 코드가 빠르지 만 반드시 가장 빠를 필요는없는 모범 사례가 있습니다. 그 외에도 병목 현상을 예상하고 코드가 빌드 될 때 코드를 최적화하려고하면 시간이 낭비 될 수 있습니다. 더 나쁜 것은 최적화로 인해 코드 속도가 느려질 수 있습니다.

가능하면 최소한의 작업 솔루션을 제공하십시오. 몇 주 동안 금도금 용액이 낭비되는 것을 보았습니다. 범위에 대해 매우주의하십시오.

나는 6 개월이 걸렸어 야하는 프로젝트에 시간을 보냈다. 내가 합류했을 때 1 년 반 동안 진행되었습니다. 프로젝트 책임자는 프로젝트 관리자에게 시작시 한 가지 질문을했습니다. "제대로 하시겠습니까?" 일주일 동안, 월요일, 수요일 및 금요일에 기능이 구현되었습니다. 화요일과 목요일에 기능이 제거되었습니다.

편집 : 코드가 만족스러운 수준으로 완료되면 그대로 두십시오. 더 나은 방법을 찾으면 다시 고치지 마십시오. 스스로 메모를해야하는 경우. 변경이 필요한 경우 아이디어를 검토 한 후 여전히 적절하다면 구현하십시오.

향후 기능에 대한 확장을 구현할 위치가있는 경우 확장을 구현하지 마십시오. 마커 주석을 남기면 어디에서 변경해야하는지 알려줍니다.

작동시키고 완벽하게 만드십시오

나는 이것에 약간의 여유를 줄 수 있지만-시간이 핵심이라면, 당신의 주요 우선 순위는 그것이 간단하게 작동하도록하는 것입니다. 코드의 단점에 대해 광범위하게 설명하고 사용중인 프로젝트 / 시간 관리 소프트웨어에서 수행 한 작업을 기록하십시오.

이 문제로 돌아와서 완벽하게 만들 수있는 시간이 더 많이 제공되기를 바랍니다.

분명히 이것에 대한 절대 정답은 없지만, 내가 시도하고 고수하는 대답입니다. 그래도 현재 작업 스타일에 적합하지 않을 수 있습니다. 어느 것이 나를 대안으로 인도합니다 ...

당신에게 맞는 방법을 찾으십시오 . 그리고 그것을 고수하십시오. 모든 사람은 프로젝트를 다루는 자신 만의 방식을 가지고 있으며 "모든 규모에 맞는"접근 방식은 없습니다. 접근 방식을 찾아 내십시오.

"올바른 행동"은 특정 상황에 대한 올바른 균형을 이루는 것을 의미합니다. 그들 중 일부는 다음과 같습니다.

1. 개발 시간과 비용
2. 변수 이름에서 아키텍처에 이르기까지 나중에 코드를 쉽게 읽고, 디버깅하고, 업데이트 할 수 있습니다.
3. 솔루션의 철저 함 (가장자리 경우)
4. 실행 속도

분명히, 코드 조각이 한 번 사용되어 버려지면 # 2는 다른 코드를 위해 희생 될 수 있습니다. (그러나 조심하십시오. 버릴 것이라고 생각할 수도 있습니다. 그런 다음 계속 사용하고 유지해야한다는 것을 알게됩니다.이 시점에서 사람들이 "작동하는"무언가를 개선 할 시간을주는 것이 더 어려워집니다.

귀하 및 / 또는 팀이 일부 코드를 계속 사용하고 업데이트하려는 경우 바로 가기를 사용하면 나중에 속도가 느려집니다.

현재 버그가있는 코드를 제공하고 (# 4에 약함) 시간이 오래 걸리고 (# 1에 약함), # 2에 약한 코드를 업데이트하려고했기 때문입니다. 당신의 관행을 바꾸는 것에 대한 견고하고 실용적인 주장이 있습니다.

버그 인 경우 최대한 빨리 해보십시오. 새로운 기능인 경우 시간이 걸립니다.

또한 개발자의 업무를 존중하지 않는 회사에서 근무하는 경우에는 선택의 여지가없고 품질을 빠르게 희생해야합니다.

저는 프로젝트에서 프로젝트로 이동하고 모든 것을 빠르게 수행하는 많은 회사에서 근무했습니다. 궁극적으로, 그들은 (프로그래밍뿐만 아니라) 구현이 서두르 기 때문에 모든 프로젝트에서 거의 성공하지 못했습니다.

최고의 회사는 훌륭한 소프트웨어가 시간과 장인 정신을 필요로한다는 것을 이해합니다.

비상시에 패치 솔루션을 작성하십시오. 이것을 언급하는 버그 추적에 새로운 버그를 만듭니다. 적절한 시간이있을 때마다 올바르게 작성하십시오.

나는이 업계에서 일하는 모든 사람들이하는 일을한다고 생각합니다. 나는 그것을 최대한 빨리 해내 고, 앞으로 문제를 예방하거나 앞으로 문제를 더 쉽게 해결하는 데 도움이되는 몇 가지 좋은 것들을 배제해야한다면 나는 그렇게한다. 최적의 상황은 아니지만 예측할 수없는 예상 변수, 알 수없는 많은 변수를 기반으로 한 추정치에 따라 마감일이 정해져있는 경우에는 최선을 다할 수 있습니다.

좋은 계획이 있습니다.

1. 올바른 계획을 최대한 빨리 작성하십시오.
2. 환경이 행복해질 때까지 시간을 최적화하십시오. 품질 유지
3. ???
4. 성공

나는 대부분의 일을 일상적인 방식으로 생각합니다. 그것은 빠르며, 나는 괜찮은 프로그래머라고 생각하고 첫 시도에서 합리적으로 대부분의 일을합니다.

때때로 나는 (하루에 두 번 말하고 싶지만 일주일에 두 번 더 사실적입니다), 특히 일상적인 방식으로 매우 지루한 일을 발견 할 때, " 나는 이것을 할 수있는 가장 좋은 방법은 무엇입니까? ? " 더 좋은 방법을 찾거나 발명하기 위해 여분의 시간을 보냅니다.

내가 자주 그렇게 많이하면 일상적인 코딩이 계속 향상 될 것이라고 생각합니다.

소프트웨어가 이상하고 소프트웨어 개발 프로세스가 이상합니다.

실제 생활에서 대부분의 것과 달리, 컴퓨터와 관련된 대부분의 것과 같습니다.

빠를수록 더 안정적입니다

이것은 당신이 지금까지 당신이 가르친 모든 직관에 위배되며, 고도로 튜닝 된 자동차는 표준 자동차보다 자주 고장납니다.

그러나 체계적인 절차가 느리더라도 더 나은 소프트웨어가 생성되지 않습니다. 요구 사항 문서를 작성하는 데 몇 주를 소비하고 코드를 작성하기 전에 며칠 동안 수업 다이어그램을 작성하는 사람은 더 나은 소프트웨어를 생산하지 못합니다. 기본 요구 사항을 충족하고 몇 가지 문제를 해결하고 화이트 보드에서 클래스 다이어그램을 낙서하며 팀 코딩을받는 사람은 거의 항상보다 안정적이고 더 나은 소프트웨어를 생산하며 몇 개월이 아닌 며칠 내에 그렇게합니다.

직업이 당신에게 적합하지 않습니다.

"시간이 없기 때문에 고객이 기다리고 있습니다. 버그가 밤새 해결되어야합니다. 회사가이 문제로 돈을 잃고 있습니다. 관리자가 열심히 압박하고 있습니다"라는 저품질 코드는 제대로 관리되지 않은 회사의 증상입니다.

당신의 일에 자부심을 가지고 고품질의 코드를 작성하고자한다면, 최선의 방법은 그것을 이해하고 그것을 지불하도록 고용주를 찾는 것입니다.