Làm cách nào tôi có thể bảo vệ Ruby on Rails trước ý kiến ​​kỹ thuật của khách hàng?

Khách hàng của tôi, một chủ doanh nghiệp dịch thuật, chỉ nói với tôi rằng anh ta đã đọc về Ruby on Rails và nói với tôi rằng " có nhiều người PHP hơn ở đó " và " có vẻ như cộng đồng thích điều đó ". Bạn, với tư cách là kỹ sư phần mềm và freelancer, sẽ nói gì với khách hàng để đạt được những mục tiêu này:

• Bán
• Làm cho anh ta thấy rằng công nghệ là quyết định chuyên môn của tôi và Rails tốt hoặc tốt hơn PHP (+ bất kỳ khuôn khổ nào) cho dự án cụ thể này.

CẬP NHẬT: Cảm ơn tất cả các bạn đã góp ý! Ngày mai tôi có một cuộc họp khác với anh ấy, hãy xem mọi chuyện diễn ra như thế nào, tôi sẽ cập nhật lại :)

CẬP NHẬT 2: Cuối cùng tôi bảo anh ấy đọc chủ đề này và kết quả thật tuyệt vời: Anh ấy đã cho tôi dự án và chúng tôi sẽ bắt đầu ngay bây giờ. Cảm ơn tất cả các bạn đã giúp đỡ, bạn có bia miễn phí nếu chúng tôi thấy một ngày nào đó :)

BTW: Tôi đã học được bài học: hãy minh bạch nhất có thể, bởi vì nếu bạn tin tưởng vào bản thân và công việc của mình, không có câu hỏi nào đủ thỏa hiệp để đánh bại bạn.

Trân trọng

Tôi nghĩ bạn đã sai lầm khi cho rằng việc lựa chọn công nghệ là một quyết định hoàn toàn về mặt kỹ thuật.

Khách hàng dường như quan tâm đến ý nghĩa kinh doanh của việc chọn một công nghệ cụ thể. Do đó, bạn cần trình bày một trường hợp giải quyết mối quan tâm kinh doanh của anh ấy ít nhất là nhiều như ý kiến ​​công nghệ của bạn.

• Nhà tuyển dụng phải tuyển dụng từ một khu vực địa lý cụ thể và một số khu vực nhất định có cộng đồng đặc biệt tích cực xung quanh các ngăn xếp công nghệ cụ thể. Ví dụ, nếu bạn đang bắt đầu kinh doanh ở Tây Bắc Thái Bình Dương của Hoa Kỳ, sẽ có sự thiên vị mạnh mẽ đối với một ngăn xếp của Microsoft chỉ vì Microsoft rất có ảnh hưởng trong khu vực nên hầu hết các nhà phát triển bạn muốn thuê sẽ có kinh nghiệm với chồng đó. Các khu vực địa lý khác có hồ sơ rất khác nhau.
  Nói chuyện với khách hàng của bạn và hiểu lý do tại sao và làm thế nào anh ta hình thành ý kiến ​​của mình. Có lẽ ông đọc rằng cộng đồng PHP địa phương đặc biệt tích cực hoặc trường đại học địa phương dạy rất nhiều PHP và không có Ruby. Có lẽ anh ta có một nhà phát triển đáng tin cậy mà anh ta có thể gọi cho trường hợp khẩn cấp không thường xuyên đó là PHP pro và Ruby neophyte. Tất nhiên, cũng có thể là anh ta sử dụng các số liệu kém như số lượng quảng cáo việc làm hoặc sơ yếu lý lịch đề cập đến các từ khóa khác nhau.
• Người sử dụng lao động phải quan tâm đến tính bền vững lâu dài của ngăn xếp công nghệ. Ví dụ, nhiều năm trước, rất nhiều công ty đã đầu tư rất nhiều thời gian và công sức để xây dựng các ứng dụng PowerBuilder (và các ngôn ngữ khác thuộc thể loại đó). PowerBuilder thường làm cho nó rất dễ dàng để xây dựng dòng ứng dụng kinh doanh và nhà phát triển vào thời điểm đó thường khá say mê với nó. Thật không may, cộng đồng PowerBuilder ít nhiều đã sụp đổ khiến các công ty rơi vào tình trạng họ có rất nhiều mã hiện có trong ngôn ngữ mà không ai thực sự muốn sử dụng khi họ gặp khó khăn trong việc giúp các nhà phát triển có thẩm quyền duy trì mã hiện có và các dự án tốn kém, tốn thời gian để di chuyển các ứng dụng đó sang ngăn xếp công nghệ khác. Các giá trị kỹ thuật tương đối của PowerBuilder là so với Java hoặc C ++ hoặc C # hoặc bất cứ thứ gì họ di chuyển đến thời điểm đó;
  Các ngôn ngữ tương đối thích hợp như Ruby hoàn toàn có khả năng tạo ra các loại vấn đề di sản này cho các công ty, những người không thể dự đoán liệu ngôn ngữ này sẽ biến mất trong một vài năm khi mọi người chuyển sang mốt tiếp theo hay nếu nó có sức mạnh thực sự . Bạn chắc chắn có thể giảm thiểu điều này bằng cách chỉ ra rằng Ruby không phụ thuộc vào một công ty hoặc tổ chức để không ai có thể quyết định nó không còn là sản phẩm chiến lược của công ty. Nếu trước đây khách hàng của bạn đã bị đốt cháy bởi các ứng dụng được phát triển bằng các ngôn ngữ trở thành vấn đề đau đầu trong kinh doanh, bạn sẽ cần phải làm cho Ruby giống với Linux và các công nghệ nguồn mở khác phát triển mà không có công ty nào hỗ trợ họ hơn các ngôn ngữ chết trong những năm qua.
• Nhà tuyển dụng muốn sự nhất quán trong môi trường vì vậy việc chọn ngôn ngữ cho một dự án buộc phải lựa chọn cho nhiều người khác. Ngay cả khi Ruby lý tưởng về mặt kỹ thuật cho dự án mà bạn đang quảng cáo, bạn phải giải thích lý do tại sao nó phù hợp cho mọi ứng dụng khác mà khách hàng này sẽ cần phát triển hoặc giải thích sự kết hợp công nghệ nào mà bạn tin là phù hợp (ví dụ: Ruby for X, một thứ khác cho y). Đối phó với các công nghệ không đồng nhất, tuy nhiên, chắc chắn sẽ chuyển thành chi phí thêm cho doanh nghiệp.

Để bắt đầu, bạn có thể hướng khách hàng của bạn đến đây để xem hệ sinh thái tồn tại xung quanh Rails. Bạn cũng có thể chỉ ra các công ty khởi nghiệp thành công như LivingSocial, Shopify, 37signals, v.v ... đã xây dựng doanh nghiệp của họ với Ruby và Rails.

Bạn có thể đề cập rằng các doanh nghiệp lớn như AT & T, SAP và Symantec cũng đang sử dụng Rails (tất cả họ đều đang tuyển dụng rất nhiều tại RailsConf năm ngoái).

Bạn có thể chỉ ra rằng một doanh nghiệp dịch thuật có rất nhiều để đạt được bằng cách sử dụng ngôn ngữ / khung làm cho hỗ trợ Unicode và i18n tương đối không gây đau đớn.

Cuối cùng, tôi nghĩ bạn cần bán ý tưởng rằng có thể sử dụng Rails là một tính năng cao cấp mà anh ta có được bằng cách thuê bạn: "Tất nhiên tất cả những kẻ khác đang sử dụng PHP. Nhưng bạn có cơ hội để có một ngăn xếp hiện đại cung cấp năng lượng cho ứng dụng của bạn . "

Vào cuối ngày, cũng cần phải rõ ràng rằng những gì cuối cùng anh ấy mua là kỹ năng và chuyên môn của bạn; nếu anh ta am hiểu về công nghệ web phía máy chủ, anh ta sẽ không cần bạn. Ngôn ngữ và khung là quyết định thực hiện, không phải là yêu cầu.

PS Đừng đề cập đến Twitter. Chúng tôi vẫn đang cố gắng hoàn tác các đường ray PR xấu đã lấy từ đó.

Tôi sẽ giải thích rằng về cơ bản đó là sự lựa chọn "Coke" so với "Pepsi". Cả hai đều được chấp nhận rộng rãi, cả hai đều có những người sẽ chiến đấu và chết vì nhau, và cả hai đều hoàn toàn tương xứng. Chỉ ra những lý do bạn thích RoR.

Anh ấy đang nói về mọi người, bạn đang nói về một ngôn ngữ và khuôn khổ. Anh ta sẽ không nghe thấy bất kỳ lý do nào hoàn toàn là kỹ thuật, vì vậy bạn nên tập trung vào những gì mọi người đang làm với ngôn ngữ . Bạn có thể nói về sức mạnh con người trong Rails, làm thế nào dễ dàng hơn cho một người làm nhiều hơn một người PHP, nhanh hơn (nếu đây là những gì bạn tin). Bạn có thể hỏi liệu mức độ phổ biến của các trình điều khiển của Honda có nghĩa là nó là một chiếc xe tốt hơn so với Rolls Royce, điều hiếm thấy. Bạn có thể nói về những gì cộng đồng thực sự bao gồm, cho dù có quá nhiều đầu bếp trong súp mô-đun (đá quý so với mô-đun, v.v.), cho dù mọi người đều mắc hội chứng NIH, v.v.

Bất kể, nó cần phải ở khía cạnh của mọi người bởi vì anh ấy muốn biết rằng anh ấy có thể thay thế bạn. Giúp anh ta biết điều này, vì dù sao anh ta cũng sẽ không muốn chuyển đi. "Quyết định chuyên gia" của bạn hoàn toàn không có ý nghĩa gì khi anh ta ít quan tâm đến những gì một người nhất định biết. Anh ta chỉ muốn có "nhiều người" biết điều tương tự.

Vào cuối ngày, không có gì xấu hổ khi gọi người vô tội vạ. "Tốt thôi, đi với PHP. Chúc may mắn!"

Chỉ ra rằng đám đông PHP có nhiều thành viên hơn vì rào cản thấp nhất để vào và đã tồn tại lâu hơn. Đảm bảo chỉ ra rằng các cộng đồng nhỏ hơn có tỷ lệ lập trình viên đáng thuê cao hơn, PHP có thể có 10.000 lập trình viên giỏi so với 5.000 lập trình viên đường ray, nhưng các lập trình viên PHP bị ẩn trong một khối 100.000 so với 20.000 đối với lập trình viên đường ray. (Những con số này được tạo thành, nhưng nó có điểm chính.) Sau đó, bạn cần giải thích rằng cộng đồng thực sự không có sự ưu tiên giữa PHP và Rails.

Bạn không thể sử dụng lý do kỹ thuật cho một người không có kỹ thuật, bạn không thể giải thích lý do tại sao iPhone kém hơn so với các điện thoại thông minh khác với người chỉ biết về điện thoại trông như thế nào. Bạn cần lý do họ hiểu.

Khách hàng của bạn đã thuê bạn, vì vậy có lẽ anh ta tin tưởng vào chuyên môn của bạn. Giải thích rằng các chuyên gia khác nhau có thể thích các công cụ khác nhau và công cụ ưa thích của bạn là RoR. Chỉ ra sự hiện diện của cộng đồng và sự chấp nhận của cộng đồng tồn tại đối với RoR và các công ty thành công như 37signals sử dụng nó, để loại bỏ mối quan tâm của anh ấy rằng bạn đang đề xuất một số công nghệ phức tạp mà không ai ngoài bạn biết. Chỉ ra rằng bạn sẽ làm việc hiệu quả hơn bằng cách sử dụng các công cụ bạn thích (do đó giảm chi phí và cải thiện thành công của anh ấy) và nếu bạn hoặc anh ấy cần tìm thêm chuyên gia RoR thì sẽ không khó để làm. Nếu anh ta có nhiều kỹ thuật hơn, bạn có thể chỉ ra làm thế nào RoR có thể thành công trong các nhiệm vụ anh ta cần so với giải pháp ưa thích của anh ta.

Tránh lặp lại FUD và thường chê bai PHP - nếu bạn không phải là chuyên gia về PHP, có khả năng cao bạn sẽ nói điều gì đó không chính xác, sai hoặc gây tranh cãi cao và nếu khách hàng của bạn biết bạn đã sai về điều đó có thể làm tổn thương uy tín của bạn với anh ta trong các khía cạnh khác.

Sếp của bạn có một điểm. PHP phổ biến hơn nhiều so với RoR theo mã đến một số trang web nỗ lực theo dõi những thứ như vậy. Ví dụ: xem http://lang-index.sourceforge.net và http://www.tiobe.com/index.php/content/apersinfo/tpci/index.html >. Tôi nghĩ sẽ thật ngu ngốc nếu bỏ qua sự thật.

Tôi đề nghị bạn thừa nhận anh ta có một điểm và sau đó nhắc nhở anh ta rằng RoR cũng có một sự theo dõi mạnh mẽ. Sẽ không hại gì khi có một vài liên kết đến các trang web phổ biến được xây dựng với RoR mà bạn có thể hiển thị cho anh ấy.

Rốt cuộc, anh ta thực sự đang tìm kiếm sự đảm bảo của bạn rằng anh ta đang đưa ra quyết định kinh doanh đúng đắn và muốn bằng chứng sao lưu nó. Như người xưa thường nói "Không ai từng bắn mũi tên vào họ để giới thiệu Microsoft." PHP cũng vậy trong phát triển web. Cung cấp cho anh ấy sự thật vững chắc và ý kiến ​​eschew. Bạn sẽ làm tốt.

Dịch niềm tin của bạn vào các thuật ngữ kinh tế có thể định lượng (nếu có thể / hợp lệ). Thực tế là việc kinh doanh của anh ấy là dịch thuật cụ thể cho thấy RoR (hoặc bất kỳ ngôn ngữ nào có hỗ trợ đa ngôn ngữ bản địa) vượt trội về mặt kỹ thuật so với PHP - nhưng điều này phải được bù đắp với chi phí của các nhà phát triển và cung cấp máy chủ liên quan đến các nền tảng tương ứng đó. Công việc kinh doanh của họ có thể tồn tại lâu hơn mối quan hệ của bạn, họ sẽ muốn trấn an rằng họ đang đặt nền móng đúng đắn.

IME, thừa nhận nhược điểm (cũng như ưu điểm) của chiến lược của bạn có sức thuyết phục hơn bất kỳ số lượng truyền giáo nào - điều đó cho thấy rằng bạn quan tâm đến việc giải quyết vấn đề của họ hơn là sử dụng cây búa yêu thích của bạn .

Khách hàng của bạn có thể có một điểm hợp lệ. Cung và cầu ảnh hưởng đến giá cả. Nếu nguồn cung của các nhà phát triển có kỹ năng đặc biệt trong khu vực địa lý của khách hàng thấp, giá cho việc duy trì phần mềm yêu cầu bộ kỹ năng hiếm hơn đó có thể tăng nhiều hơn theo thời gian so với khi phần mềm được phát triển sử dụng ngôn ngữ phổ biến hơn với mức lớn hơn đáng kể nhóm các nhà phát triển lành nghề địa phương. Vì vậy, vấn đề cũng có thể là một trong những quản lý rủi ro chi phí dài hạn.

Khi tôi có một khách hàng muốn sử dụng một công cụ cụ thể vì đó là "tiêu chuẩn ngành", có "sự đồng thuận" hoặc là "những gì mọi người đang sử dụng", tôi chỉ ra cho họ rằng tất cả các thuật ngữ đó là mã cho "mức trung bình của ngành. " Đó là, những gì hầu hết những người khác trong khu vực đang làm. Kinh doanh "trung bình" thất bại. Chọn công cụ của bạn dựa trên yêu cầu công việc, chứ không phải những gì người khác đang làm. Có ít lập trình viên RoR hơn không thành vấn đề nếu hệ thống không cần nhiều sự sửa đổi khi hoàn thành.

Chắc chắn đây là một quyết định kinh doanh cho cả hai bạn .

Đối với bạn các câu hỏi là:

• Tôi sẽ tốn bao nhiêu tiền để thực hiện các yêu cầu của khách hàng khi sử dụng Ruby on Rails?
• Tôi sẽ tốn bao nhiêu tiền để thực hiện chúng trong PHP?
• Giá trị nào để tôi sử dụng môi trường ưa thích của tôi?

Đối với khách hàng của bạn, câu hỏi là

• Bao nhiêu lợi ích nhận thức được của PHP so với Ruby on Rails đáng giá với tôi?

Nếu bạn cung cấp cho khách hàng của mình một báo giá với Giá thực hiện bằng Ruby on Rails và Giá riêng cho việc cấy ghép bằng PHP , cả hai đều dựa trên các câu trả lời cho câu hỏi của riêng bạn, thì khách hàng của bạn có thể đưa ra phán quyết của riêng họ về việc có thêm chi phí bây giờ là giá trị tiết kiệm trong tương lai có thể.

Điều này không khác gì họ đưa ra quyết định về việc họ nên giao hợp đồng cho bạn hay cho một nhà phát triển khác sẽ triển khai nó bằng PHP theo yêu cầu.

Sự tương đồng tốt nhất trong thế giới thực mà tôi có thể nghĩ ra là "Sẽ mua một chiếc Ford chứ không phải một chiếc BMW chỉ vì thị phần của BMW nhỏ hơn?".

Cuối cùng, các lập trình viên PHP chỉ bằng một nửa chi phí của các lập trình viên Rails, và bạn sẽ làm gì nếu bạn tìm được một công việc tốt hơn vào ngày mai? Sếp của bạn sẽ hoàn toàn khó khăn và tranh giành để tìm một nhà phát triển Rails, và điều đó làm mất thời gian và tiền bạc vì các nhà phát triển Rails đang bị thiếu hụt.

Lý do duy nhất mà sếp của bạn đồng ý là nếu cảm thấy điều đó sẽ khiến BẠN hạnh phúc hơn, và bằng cách cho phép đưa ra quyết định mà bạn muốn bạn sẽ hạnh phúc hơn khi làm việc cho anh ta, và do đó sẽ hiệu quả hơn.