고객의 기술적 의견이 아닌 Ruby on Rails를 어떻게 방어 할 수 있습니까?


16

번역 사업자 인 내 고객은 루비 온 레일즈에 대해 읽고 있다고 말했고 " 주변에 더 많은 PHP 사용자가 있으며" " 지역 사회가 선호하는 것 같습니다 "라고 말했습니다. 소프트웨어 엔지니어 및 프리랜서로서 고객에게 다음과 같은 목표를 달성하기 위해 무엇을 말 하시겠습니까?

  • 팔다
  • 그는이 기술이 저의 전문적인 결정이며 Rails가이 특정 프로젝트에서 PHP (+ 프레임 워크)보다 우수하거나 우수하다는 것을 알게되었습니다.

업데이트 : 제안에 감사드립니다! 내일 나는 그와 또 다른 회의를 가졌습니다. 그것이 어떻게 진행되는지 보자, 나는 다시 업데이트 할 것이다 :)

업데이트 2 : 마지막 으로이 스레드를 읽으라고 말했고 결과는 환상적이었습니다. 그는 프로젝트를 주었고 우리는 지금 시작할 것입니다. 도움을 주셔서 감사합니다. 언젠가 볼 경우 무료로 맥주를 마실 수 있습니다. :)

BTW : 나는 교훈을 배웠습니다. 가능한 한 투명해야합니다. 당신이 자신과 당신의 일을 믿는다면, 당신을 이길만큼 타협 할만한 질문이 없기 때문입니다.

문안 인사


2
이 질문을 옮기기로 한 투표 ... 그러나 shopify.com, twitter.com 등과 같은 산업 용도의 예를 사용하는 것을 고려하고 Rails의 개발이 PHP의 개발보다 빠르다고 설명합니다. ).
iwasrobbed

답변:


47

기술 선택이 순전히 기술적 인 결정이라고 가정하면 실수를 저지른 것 같습니다.

고객은 특정 기술을 선택함으로써 비즈니스에 미치는 영향에 대해 우려하는 것 같습니다. 이를 감안할 때 최소한 기술 의견만큼이나 그의 비즈니스 문제를 해결하는 사례를 제시해야합니다.

  • 고용주는 특정 지역에서 채용해야하며 특정 지역에는 특정 기술 스택 주변에서 특히 활발한 커뮤니티가 있습니다. 예를 들어, 미국 태평양 북서부에서 사업을 시작하는 경우, Microsoft가 해당 지역에서 영향력이 매우 높기 때문에 Microsoft 스택에 대한 강한 편견이있을 것입니다. 그 스택에 대한 경험이 있습니다. 다른 지역에서는 프로필이 매우 다릅니다.
    고객과 의견을 나누고 고객의 의견이 왜 그리고 어떻게 형성되었는지 이해하십시오. 아마도 그는 지역 PHP 커뮤니티가 특히 활발하거나 지역 대학이 많은 PHP를 가르치고 루비는 가르치지 않는다고 읽었습니다. 아마도 그는 PHP 프로와 루비 네오 피 테인 비상 사태에 대비할 수있는 신뢰할 수있는 개발자를 보유하고있을 것입니다. 물론 다양한 키워드를 언급하는 구인 광고 나 이력서 수와 같은 열악한 측정 항목을 사용하고있을 수도 있습니다.
  • 고용주는 기술 스택의 장기 지속 가능성에 관심을 가져야합니다. 예를 들어 수년 전에 많은 회사들이 PowerBuilder 앱 (및 해당 장르의 다른 언어)을 구축하는 데 많은 시간과 노력을 투자했습니다. PowerBuilder는 종종 비즈니스 응용 프로그램을 구축하기가 매우 쉬워졌으며 당시 개발자들은 종종 그것에 매료되었습니다. 불행히도 PowerBuilder 커뮤니티는 어느 정도의 언어로 존재하는 기존 코드가 많은 상황에서 유능한 개발자가 기존 코드와 비용이 많이 들고 시간이 많이 걸리는 프로젝트를 유지하는 데 어려움을 겪고 싶어하는 상황에 처하게되었습니다. 이러한 앱을 다른 기술 스택으로 마이그레이션합니다. PowerBuilder의 상대적인 기술적 장점은 Java 또는 C ++ 또는 C # 또는 그 시점에서 마이그레이션 한 것입니다.
    루비와 같은 상대적으로 틈새 언어는 사람들이 다음 유행으로 넘어갈 때 또는 진정한 체재 력이 있는지 몇 년 안에 언어가 어지러워 질지 예측할 수없는 회사에 이러한 종류의 레거시 문제를 만들 가능성이 절대적으로 있습니다 . 루비가 한 회사 나 조직에 의존하지 않기 때문에 더 이상 회사의 전략적 제품이 아니라고 결정할 수는 없습니다. 과거에 비즈니스 두통이 된 언어로 개발 된 응용 프로그램을 사용하여 고객을 태운 적이 있다면 루비는 Linux 및 다른 오픈 소스 기술과 비슷하지만 수년에 걸쳐 죽었다.
  • 고용주는 환경의 일관성을 원하므로 한 프로젝트의 언어를 선택하면 다른 많은 프로젝트를 선택해야합니다. 비록 루비가 당신이 투구하고있는 프로젝트에 기술적으로 이상적 일지라도,이 고객이 필요로하는 다른 모든 애플리케이션에 왜 그것이 적합한 지 설명하거나 당신이 적절하다고 생각하는 기술의 혼합을 설명해야합니다. Y를위한). 그러나 이기종 기술을 다룰 때 필연적으로 비즈니스 비용이 추가로 발생합니다.

17
+1이 포럼의 많은 사람들이 선택의 학문적 이유에 초점을 맞추고 경제학을 무시하는 것 같습니다
dietbuddha

10
+1 실제 비즈니스 관련 문제를 제기하고 (내가 말하려고하는 대부분의 글을 작성하여 시간을 절약했습니다.)
jcmeloni

루비가 모든 애완 동물 프로젝트에 대한 답이 아닌 몇 가지 비즈니스상의 이유나 몇 가지 기술적 이유를 추가 할 수 있습니다. 그러나 당신은 그것을 꽤 잘 못 박았으므로 두 엄지 손가락!
Alex

2
리얼리즘 레슨 Justin과 답을 쓰는 노력에 감사드립니다. 정말 고맙습니다.
okeen

1
나는이 답변에서 약간 헤지 된 것을 지적 할 것이다. 고객이 옳을 수도있다. 기술적으로 우수한 답변은 아니지만 그의 우려가 유효 할 수 있으며 RoR 어지럽고 죽을 수는 있지만 그럴 것 같지 않습니다. 고객이 정보에 입각 한 결정을 내릴 때 필요하므로 기술적 인 의견을 제공하는 것이 좋습니다.
MattG

8

우선, Rails 주변에 존재하는 생태계를 살펴 보려면 여기 로 고객을 안내 할 수 있습니다 . 또한 LivingSocial, Shopify, 37signals 등과 같이 Ruby 및 Rails로 비즈니스를 구축 한 성공적인 신생 기업을 가리킬 수도 있습니다.

AT & T, SAP, 시만텍과 같은 대기업에서도 Rails를 사용하고 있다고 언급 할 수 있습니다 (작년에 RailsConf에서 많은 직원을 채용했습니다).

유니 코드를 지원하고 i18n을 비교적 고통없이 사용하는 언어 / 프레임 워크를 사용하면 번역 비즈니스에 많은 이점이 있음을 알 수 있습니다.

물론 모든 중 "궁극적으로, 당신이 레일을 사용 할 수있는 것이라는 생각을 판매 할 필요가 있다고 생각은 그가 당신을 고용함으로써 얻는 프리미엄 기능입니다 다른 사람이 PHP를 사용하지만. 당신은 가질 수있는 기회가 현대적인 응용 프로그램에 전원을 공급 스택을 "

하루가 끝날 때, 그가 궁극적으로 구매하는 것이 당신의 기술과 전문 지식이라는 것이 분명 해져야합니다. 그가 서버 측 웹 기술에 대해 잘 알고 있다면, 그는 당신을 필요로하지 않을 것입니다. 언어 및 프레임 워크는 요구 사항이 아닌 구현 결정입니다.

추신 트위터는 언급하지 마십시오. 우리는 여전히 나쁜 PR Rails를 취소하려고 노력하고 있습니다.


6

기본적으로 "Coke"대 "Pepsi"선택이라고 설명하겠습니다. 둘 다 널리 받아 들여지고, 둘 다 서로 싸우고 죽을 사람들이 있으며, 그들은 모두 완벽하게 적합합니다. RoR을 선호하는 이유를 지적하십시오.


4
나는 이것이이 상황에서 도움이 될 것이라고 생각하지 않습니다. 그것이 정말로 개인적인 취향의 문제라면, 아마도 응답은 "잘 구입하고 있습니다. 따라서 유지 보수 프로그래밍 컨설턴트가 저보다 저렴한 가격이기 때문에 PHPepsi를 사용하십시오." Ruby를 사용하는 것은 부가 가치 제안이되어야하며, 기본 다국어 지원은 번역 사업을위한 확실한 플러스입니다.
Jason Lewis

6

그는 사람들에 대해 이야기하고 언어와 프레임 워크에 대해 이야기하고 있습니다. 그는 순수하게 기술적 인 이유를 듣지 않을 것이므로 사람들언어로 하는 일 에 집중해야 합니다 . Rails에서 사람들의 힘에 대해 이야기 할 수 있습니다. 한 사람이 PHP 사람보다 더 빨리하는 것이 더 빠릅니다 (이것이 믿는다면). 혼다 운전자의 유병률이 롤스 로이스보다 더 나은 차를 의미하는지 여부를 물어볼 수 있습니다. 커뮤니티가 실제로 어떻게 구성되어 있는지, 모듈 수프에 쿡이 너무 많은지 (젬 대 모듈 등), 모든 사람이 NIH 증후군을 가지고 있는지 등을 이야기 할 수 있습니다.

어쨌든, 그는 당신을 대신 할 수 있기를 원하기 때문에 사람들의 관점에서 볼 필요가 있습니다. 그가 어쨌든 전환하고 싶지 않기 때문에 그를 알도록 도와주십시오. 당신의 "전문가 결정"은 주어진 사람이 알고있는 것에 훨씬 덜 신경 쓸 때 전혀 아무런 관련이 없습니다. 그는 단지 같은 것을 아는 "더 많은 사람들"이 있기를 원합니다.

하루가 끝나면 블러 프를 부르는 데 부끄러움이 없습니다. "좋아요, PHP와 함께 가십시오. 행운을 빌어 요!"


2
항상 클라이언트를 시작하는 것이 옵션이라는 것을 기억하는 것이 중요합니다.
Jason Lewis

3

PHP 군중은 진입 장벽이 가장 낮고 더 길어 졌기 때문에 더 많은 구성원을 가지고 있다고 지적하십시오. 소규모 커뮤니티에는 고용 할 가치가있는 프로그래머 비율이 더 높으며 PHP는 5,000 개의 레일 프로그래머에 비해 10,000 명의 우수한 프로그래머가있을 수 있지만, PHP 프로그래머는 레일 프로그래머의 경우 20,000 개에 비해 100,000 개의 블록으로 숨겨져 있습니다. (이 숫자들은 구성되어 있지만, 요점을 잘 알고 있습니다.) 그러면 커뮤니티가 실제로 PHP와 Rails 사이에 선호 사항이 없다는 것을 설명해야합니다.

기술적 인 사람이 아닌 사람에게는 기술적 이유를 사용할 수 없으며, iPhone이 다른 스마트 폰보다 열등한 이유를 설명 할 수는 없습니다. 그들이 이해하는 이유가 필요합니다.


개발자 커뮤니티에서 신호 대 잡음비의 중요성을 지적한 +1
Jason Lewis

2
숫자가 구성되어 있다는 사실은 그 요점도 구성되어 있다는 결론으로 ​​이어집니다. 사실 일 수도 있고 틀릴 수도 있지만, 사실이 증명되거나 반증되는 사실이 필요합니다. 사실이 없다면, 그것은 "다른 팀에서 뛰기 때문에 당신이 suck 다"는 것입니다.
StasM

나는이 주장을 기술적 인 상사들과도 동의하고 사용했다. RFC 및 커뮤니티 기여 프로세스가 작동하는 Python 또는 Ruby 용으로 급증한 고품질 PHP 개발자의 기회는 매년 증가합니다. PHP는 가장 복사하기 쉽고 붙여 넣기가 가능하며 진입 언어에 대한 장벽이 낮아 원하지 않는 개발자를 끌어들입니다.
Lincoln B

3

귀하의 고객이 귀하를 고용 했으므로 아마도 귀하의 전문 지식을 신뢰합니다. 전문가마다 다른 도구를 선호 할 수 있으며 선호하는 도구는 RoR입니다. RoR 및이를 사용하는 37 개의 신호와 같은 성공적인 회사에 대해 존재하는 커뮤니티와 커뮤니티 수용의 존재를 지적하여 아무도 모르는 비전 기술을 추천하고 있다는 우려를 제거하십시오. 원하는 도구를 사용하면 생산성이 높아지고 (따라서 비용을 낮추고 성공에 대한 변경 사항을 개선 할 수 있음) 더 많은 RoR 전문가를 찾아야한다면 어렵지 않을 것입니다. 더 기술적 인 사람이라면 RoR이 자신이 선호하는 솔루션과 비교할 때 필요한 작업에서 어떻게 성공할 수 있는지 지적 할 수 있습니다.

FUD를 반복하고 일반적으로 PHP를 파산하지 마십시오. PHP 전문가가 아닌 경우 정확하지 않거나 틀리거나 논란의 여지가있는 말을 할 가능성이 높습니다. 다른 측면에서 그와의 신뢰.


2

당신의 상사는 포인트가 있습니다. PHP는 그러한 것들을 추적하기 위해 노력하는 여러 사이트에서 RoR을 인코딩하는 것보다 훨씬 인기가 있습니다. 예를 들어 http://lang-index.sourceforge.nethttp://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >을 참조 하십시오 . 사실을 무시하는 것은 어리석은 일이라고 생각합니다.

나는 그가 지적한 점을 인정한 다음 RoR도 강한 관심을 가지고 있음을 상기시켜 줄 것을 제안합니다. RoR로 구축 한 인기 사이트로 연결되는 링크가 있어도 문제가되지 않습니다.

결국, 그는 자신이 올바른 비즈니스 결정을 내리고 있으며이를 뒷받침하는 증거를 원한다는 확신을 찾고 있습니다. 오래된 말에 따르면 "아무도 Microsoft를 추천하기 위해 화살을 쏘는 사람은 없었습니다." 웹 개발에서 PHP도 마찬가지입니다. 그에게 확실한 사실을 알려주고 의견을 피하십시오. 당신은 잘 할 것입니다.


1
원래의 격언은 "아무도 IBM을 사기 위해 해고 된 사람이 없었습니다"였습니다. 아마도 그들은했을 것입니다…
Matthew Flynn

1
오, 나는 사람들이 PHP를 따기 위해 화살을 쏘는 것으로 알려져있다 ... :-)
Brian Knoblauch

1

당신의 믿음을 가능한 경제적 용어로 해석하십시오 (가능한 경우 / 유효한 경우). 그의 사업이 번역에 특유하다는 사실은 RoR (또는 다국어를 지원 하는 모든 언어)이 PHP보다 기술적으로 뛰어나다는 것을 시사 하지만, 이는 해당 플랫폼과 관련된 개발자 및 서버 프로비저닝 비용과 상쇄되어야합니다. 그들의 사업은 당신의 관계보다 오래 지속될 가능성이 높으며, 그들이 올바른 기초를 세우고 있다는 확신을 원할 것입니다.

IME는 전략의 단점 (물론 프로)를 인정하는 것은 더 전도의 금액보다 설득력이 - 당신이 해결에 더 관심이 있음을 시사 자신의 사용하는 것보다 문제를 당신 이 좋아하는 망치.


1

고객에게 유효한 포인트가있을 수 있습니다. 수요와 공급은 가격에 영향을 미칩니다. 고객 지역에서 특정 기술을 보유한 개발자의 공급이 낮은 경우, 소프트웨어가 현저히 큰 인기있는 언어를 사용하여 개발 된 경우보다 희귀 한 기술 세트를 요구하는 소프트웨어 유지 보수 비용이 시간이 지남에 따라 더 증가 할 수 있습니다 숙련 된 개발자의 로컬 풀. 따라서이 문제는 장기적인 비용 위험 관리 중 하나 일 수도 있습니다.


0

"공업 표준"이거나 "합의"또는 "모든 사람이 사용하는"도구이기 때문에 특정 도구를 사용하려는 고객이있는 경우 모든 용어가 "산업 평균"의 코드임을 지적합니다. " 즉,이 지역의 다른 사람들 대부분이하는 일입니다. "평균"비즈니스가 실패합니다. 다른 사람이하는 일이 아니라 업무 요구 사항에 따라 도구를 선택하십시오. RoR 프로그래머가 적더라도 시스템이 완료 될 때 땜질을 많이하지 않아도되는 것은 중요하지 않습니다.


0

확실히 이것은 당신 둘 다를 위한 사업 결정 입니다 .

당신을 위해 질문은 다음과 같습니다

  • Ruby on Rails를 사용하여 고객 요구 사항을 구현하는 데 비용이 얼마나 듭니까?
  • PHP로 구현하는 데 비용이 얼마나 듭니까?
  • 선호하는 환경을 사용하면 어떤 가치가 있습니까?

고객의 질문은

  • Ruby on Rails에 비해 PHP의 이점은 얼마입니까?

당신이 가진 인용과 함께 고객을 제공하는 경우 Ruby on Rails에 사용하여 구현을위한 가격 과 별도의 PHP를 사용하여 implmentation에 대한 가격을 모두 자신의 질문에 대한 답변에 따라, 당신의 고객은 만들 수 있습니다 자신의 여분의 여부에 관한 판단 호출을 지금 비용은 미래에 가능한 절감 효과가 있습니다.

이는 계약을 귀하에게 제공해야하는지 여부 또는 요청 된대로 PHP를 사용하여 계약을 구현할 다른 개발자에게 결정을 내리는 것과 다르지 않습니다.


-1

내가 생각해 낼 수있는 가장 실제적인 비유는 "BMW의 시장 점유율이 더 작기 때문에 BMW가 아니라 포드를 살 것인가?"입니다.


1
모든 BMW 서비스 메커니즘이 구매자 지역에 대해 소비자 기관에 의해 너무 멀리 떨어져 있거나, 너무 비싸거나, 매우 열악한 경우 강력한 가능성.
hotpaw2

@hotpaw-충분히 공평하지만 그것은 합리적인 고려입니다. 자체 시장 점유율은 의미가 없습니다.
James Anderson

-1

궁극적으로 PHP 프로그래머는 Rails 프로그래머 비용의 절반이며 내일 더 나은 직업을 찾으면 어떻게해야할까요? 귀하의 상사는 Rails 개발자를 찾기 위해 완전히 망쳐 놓았으며 Rails 개발자가 부족하기 때문에 시간과 돈이 필요합니다.

당신의 상사가 그것에 동의하는 유일한 이유는 그것이 당신을 더 행복하게 만들고 싶다고 느끼고 당신이 원하는 결정을 내림으로써 당신이 그를 위해 더 행복하게 일할 수 있고, 따라서 더 생산적이기 때문입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.