Ruby on Rails'i müşterilerin teknik görüşlerine karşı nasıl savunabilirim?

Bir çeviri işletme sahibi olan müşterim, Ruby on Rails hakkında okuduğunu söyledi ve " orada daha fazla PHP adamı var " ve " topluluk bunu tercih ediyor gibi görünüyor " dedi. Yazılım mühendisi ve serbest çalışan olarak, müşteriye şu hedeflere ulaşmak için neler söylerdiniz:

• Satmak
• Teknolojinin uzman kararım olduğunu ve Rails'in bu proje için PHP'den (+ herhangi bir çerçeve) daha iyi veya daha iyi olduğunu görmesini sağlayın.

GÜNCELLEME: Önerileriniz için hepinize teşekkürler! Yarın onunla başka bir görüşmem var, nasıl geçtiğini görelim, tekrar güncelleyeceğim :)

GÜNCELLEME 2: Sonunda ona bu konuyu okumasını söyledim ve sonuç harika oldu: Bana projeyi verdi ve şimdi başlayacağız. Yardım için hepinize teşekkür ederim, bir gün görürsek ücretimde bedava bira var :)

BTW: Dersi öğrendim: Mümkün olduğunca şeffaf olun, çünkü kendinize ve işinize inanıyorsanız, sizi yenecek kadar uzlaşmacı bir soru yoktur.

Saygılarımızla

Bence teknoloji seçiminin tamamen teknik bir karar olduğunu varsayarak hata yaparsınız.

Müşteri, belirli bir teknolojiyi seçmenin ticari sonuçları konusunda endişeli görünmektedir. Bu göz önüne alındığında, iş endişelerini en azından teknoloji görüşleriniz kadar ağır bir şekilde ele alan bir vaka sunmanız gerekir.

• İşverenler belirli bir coğrafi bölgeden işe almak zorundadırlar ve belirli alanlarda belirli teknoloji yığınları etrafında özellikle aktif topluluklar bulunur. Örneğin ABD'nin Kuzeybatı Pasifik bölgesinde bir işletmeye başlıyorsanız, Microsoft'un bu alanda çok etkili olması nedeniyle bir Microsoft yığınına karşı güçlü bir önyargı olacaktır, bu nedenle işe almak istediğiniz geliştiricilerin çoğu bu yığını deneyimleyecek. Diğer coğrafi bölgeler çok farklı profillere sahiptir.
  Müşterinizle konuşun ve fikrini neden ve nasıl oluşturduğunu anlayın. Belki de yerel PHP topluluğunun özellikle aktif olduğunu veya yerel kolejin çok fazla PHP öğrettiğini ve Ruby olmadığını öğretti. Belki de bir PHP uzmanı ve bir Ruby neofit olan acil durum için arayabileceği güvenilir bir geliştiriciye sahiptir. Tabii ki, iş anahtarlarının sayısı veya çeşitli anahtar kelimelerden geçen özgeçmişler gibi zayıf metrikler kullanması da mümkündür.
• İşverenler, teknoloji yığınlarının uzun vadeli sürdürülebilirliği ile ilgilenmelidir. Yıllar önce, örneğin, birçok şirket PowerBuilder uygulamalarını (ve bu türün diğer dillerini) oluşturmak için çok fazla zaman ve çaba harcadı. PowerBuilder çoğu zaman iş uygulamaları geliştirmeyi çok kolay hale getirdi ve o zamanlar geliştiriciler genellikle oldukça büyülendi. Ne yazık ki, PowerBuilder topluluğu az ya da çok çöktü, şirketleri, hiç kimse gerçekten kullanmak istedikleri bir dilde mevcut kodun olduğu bir durumda, mevcut kodu ve pahalı, zaman alan projeleri sürdürmek için yetkin geliştiricilere sahip olmakta zorluk çeken bir durumda bıraktı. bu uygulamaları diğer teknoloji yığınlarına taşımak için. PowerBuilder'ın göreceli teknik değerleri, Java veya C ++ veya C # ile o noktada taşındıkları her şeydir;
  Ruby gibi nispeten niş diller, insanların bir sonraki modaya geçtiklerinde veya gerçek kalma gücüne sahip olup olmadıklarını birkaç yıl içinde düzeleceklerini tahmin edemeyen şirketler için kesinlikle bu tür eski problemleri yaratma potansiyeline sahiptir. . Ruby'nin bir şirkete veya kuruluşa bağımlı olmadığını belirterek bunu azaltabilirsiniz, böylece kimse artık şirket için stratejik bir ürün olmadığına karar veremez. Müşteriniz geçmişte iş baş ağrısı haline gelen dillerde geliştirilen uygulamalar geliştirerek yakılmışsa, Ruby'nin bunları destekleyen bir şirket olmadan gelişen Linux ve diğer açık kaynaklı teknolojilere daha çok benzediği bir durum ortaya koymanız gerekir. yıllar içinde öldü.
• İşverenler çevrede tutarlılık istiyorlar, bu nedenle bir proje için bir dil seçmek diğerleri için bir seçim yapmaya zorlar. Ruby, sunduğunuz proje için teknik olarak ideal olsa bile, bu müşterinin geliştirmesi gereken diğer tüm uygulamalar için neden uygun olduğunu açıklamanız veya hangi teknolojilerin uygun olduğuna inandığınızı (yani X için Ruby, başka bir şey) açıklamanız gerekir. Y için). Bununla birlikte, heterojen teknolojilerle uğraşmak kaçınılmaz olarak işletme için ekstra maliyete dönüşür.

Yeni başlayanlar için, Rails çevresinde bulunan ekosisteme bir göz atmak için istemcinizi buraya yönlendirebilirsiniz . Ayrıca, işlerini Ruby ve Rails ile inşa eden LivingSocial, Shopify, 37signals vb. Gibi başarılı girişimlere de işaret edebilirsiniz.

AT&T, SAP ve Symantec gibi büyük işletmelerin de Rails kullandığını söyleyebilirsin (geçen yıl hepsi RailsConf'da yoğun bir şekilde işe alındı).

Bir çeviri işinin Unicode desteğini ve i18n'yi nispeten ağrısız hale getiren bir dil / çerçeve kullanarak kazanacağı çok şey olduğunu belirtebilirsiniz.

Elbette tüm hastalardan": Sonuçta, ben Rails kullanabilme fikrini satmak gerek seni işe alarak alır premium bir özelliktir diğer adamlar PHP kullanıyorsunuz Ama. Eğer bir yaşama şansını Modern başvurunuzu güç yığını ."

Günün sonunda, nihayetinde satın aldığı şeyin sizin beceri ve uzmanlığınız olduğu da açık olmalıdır; eğer sunucu tarafı web teknolojileri konusunda bilgili olsaydı, sana ihtiyacı olmazdı. Dil ve çerçeve gereklilikler değil uygulama kararlarıdır.

PS Twitter'dan bahsetme. Hâlâ PR Ray'larının bundan geri çekilmesine çalışıyoruz.

Ben temelde bir "Kola" vs "Pepsi" seçim olduğunu açıklamak istiyorum. Her ikisi de yaygın olarak kabul edilir, her ikisinin de her biri için savaşacak ve ölecek insanlar var ve ikisi de mükemmel bir şekilde yeterli. RoR'yi tercih etme nedenlerinizi gösterin.

İnsanlar hakkında konuşuyor, sen bir dil ve çerçeve hakkında konuşuyorsun. Tamamen teknik olan herhangi bir neden duymayacak, bu yüzden insanların dil ile ne yaptığına odaklanmalısınız . Rails altındaki insanların gücü, bir kişinin bir PHP'den daha fazlasını yapmasının ne kadar kolay olduğunu (daha önce inandığınız bu ise) konuşabilirsiniz. Honda sürücülerinin yaygınlığının, nadiren görülen bir Rolls Royce'dan daha iyi bir araba anlamına gelip gelmediğini sorabilirsiniz. Topluluğun gerçekte neden oluştuğu, modül çorbasında çok fazla aşçı olup olmadığı (taşlar vs modüller vb.), Herkesin NIH sendromu olup olmadığı hakkında konuşabilirsiniz.

Ne olursa olsun, insanlar açısından olmalı, çünkü senin yerini alabileceğini bilmek istiyor. Bunu bilmesi için ona yardım et, çünkü (muhtemelen) yine de geçmek istemeyecek. "Uzman kararınızın", belirli bir kişinin bildiklerine çok daha az önem verdiği zaman kesinlikle hiçbir etkisi yoktur. Sadece aynı şeyi bilen "daha fazla insan" olmasını istiyor.

Günün sonunda blöfünü çağırmanın utancı yok. "Güzel, PHP ile git. İyi şanslar!"

PHP kalabalığının daha fazla üyesi olduğuna dikkat edin, çünkü girişin en düşük engeli ve daha uzun süredir. Daha küçük toplulukların işe almaya değer programcıların daha yüksek yüzdelerine sahip olduğuna dikkat edin, PHP 5.000 ray programcısına kıyasla 10.000 iyi programcıya sahip olabilir, ancak PHP programcıları ray programcıları için 20.000'e kıyasla 100.000'lik bir blokta gizlidir. (Bu sayılar oluşur, ancak bu nokta üzerinde durur.) O zaman topluluk gerçekten PHP ve Rails arasında bir tercih olmadığını açıklamak gerekir.

Teknik olmayan bir kişinin teknik nedenlerini kullanamazsınız, iPhone'un neden diğer telefonlara niye daha düşük olduğunu sadece telefonların nasıl göründüğünü bilen birine açıklayamazsınız. Anladıkları nedenlere ihtiyacınız var.

Müşteriniz sizi işe aldı, bu yüzden muhtemelen uzmanlığınıza güveniyor. Farklı profesyonellerin farklı araçları tercih edebileceğini ve tercih ettiğiniz aracın RoR olduğunu açıklayın. Topluluğun varlığını ve RoR ve bunu kullanan 37 işaret gibi başarılı şirketler için var olan topluluk kabulünü, kimsenin bilmediği bazı gizli teknolojiler önerdiğiniz konusundaki endişesini ortadan kaldırmak için işaret edin. Tercih ettiğiniz araçları kullanarak daha üretken olacağınızı (böylece maliyetlerini düşürdüğünüzde ve başarıdaki değişikliklerini geliştirdiğinizi) ve sizin veya daha fazla RoR uzmanı bulmanız gerektiğinde bunun zor olmayacağına dikkat edin. Daha teknikse, RoR'nin ihtiyaç duyduğu görevlerde nasıl başarılı olabileceğine, tercih ettiği çözümden daha azına dikkat çekebilirsiniz.

FUD'yi tekrarlamaktan ve genellikle PHP'yi küçümsemekten kaçının - PHP'de uzman değilseniz, doğru, yanlış veya tartışmalı olmayan bir şey söyleme olasılığınız yüksektir ve müşteriniz yanlış olduğunu öğrenirse bu zarar verebilir. başka açılardan onunla olan güvenilirliğiniz.

Patronun bir anlamı var. PHP, RoR'den çok daha popülerdir ve bu tür şeyleri takip etmeye çalışan çeşitli sitelere yönelir. Örneğin, bkz. Http://lang-index.sourceforge.net ve http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Bence gerçekleri görmezden gelmek aptalca olur.

Onun bir anlamı olduğunu kabul etmenizi ve sonra RoR'nin de güçlü bir takipçisi olduğunu hatırlatmanızı öneririm. RoR ile oluşturulmuş popüler sitelere gösterebileceğiniz birkaç bağlantıya sahip olmak acı vermez.

Sonuçta, gerçekten doğru iş kararını verdiğine dair güvencenizi arıyor ve bunu desteklemek için kanıt istiyor. Eski deyişe göre, "Hiç kimse Microsoft'u önerdiği için onlara hiç ok vurulmadı." Web geliştirme PHP için de geçerlidir. Ona somut gerçekler ve kaçınma görüşleri verin. İyi olacaksın.

İnançlarınızı ölçülebilir ekonomik terimlere çevirin (mümkünse / geçerli). İşinin çeviriye özel olması, RoR'nin (veya yerel çok dilli desteği olan herhangi bir dilin) ​​teknik olarak PHP'den daha üstün olduğunu göstermektedir - ancak bu, ilgili platformlarla ilişkili geliştiricilerin ve sunucu provizyonuna karşı dengelenmelidir. İşleri muhtemelen ilişkinizden daha uzun sürecek, doğru temelleri attığına dair güvence isteyecekler.

IME, Stratejinizin eksilerini (yanı sıra artılarını) itiraf daha evangelizm herhangi miktardan daha inandırıcı olduğunu - bu çözümü daha fazla ilgi olduğunu göstermektedir onların kullanmaktan daha sorunu sizin favori çekiç.

Müşterinizin geçerli bir puanı olabilir. Arz ve talep fiyatları etkiler. Müşterilerin coğrafi alanında belirli bir beceriye sahip geliştiricilerin tedariki düşükse, daha nadir beceri setini gerektiren yazılımı sürdürmenin fiyatı, zaman içinde, yazılımın önemli ölçüde daha büyük olduğu daha popüler bir dil kullanılarak geliştirildiğinden daha fazla artabilir. yetenekli geliştiricilerin yerel havuzu. Dolayısıyla sorun uzun vadeli maliyet riski yönetiminden biri olabilir.

"Endüstri standardı" olduğu için belirli bir aracı kullanmak isteyen bir müşterim olduğunda, "fikir birliği" vardır veya "herkesin kullandığı" şeydir, onlara tüm bu terimlerin kod ortalamasının "endüstri ortalaması" olduğuna dikkat çekerim. " Bölgedeki diğer insanların çoğunun yaptığı şey budur. "Ortalama" iş başarısız. Araçlarınızı, herkesin ne yaptığına göre değil, iş gereksinimlerine göre seçin. Daha az RoR programcısı olması, sistemin bittiğinde çok fazla müdahaleye ihtiyaç duyup duymadığı önemli değildir.

Elbette bu ikiniz için de bir ticari karardır .

Sizin için sorular:

• Ruby on Rails kullanarak müşterilerimin gereksinimlerini yerine getirmeme ne kadar mal olacak?
• Bunları PHP'de uygulamamın maliyeti nedir?
• Tercih ettiğim ortamı kullanmaya nasıl değer veririm?

Müşteriniz için soru şu

• PHP'nin Ruby on Rails üzerindeki algılanan faydaları bana ne kadar değer veriyor?

Eğer bir olan bir alıntıyla müşterinizi sağlarsanız Ruby Rails kullanılarak uygulanması için Fiyat ve ayrı PHP kullanarak implmentation için fiyat , hem kendi soruların cevaplarını dayalı, sonra müşteri yapabilirsiniz kendi ekstra olmadığı konusunda yargı çağrısı şimdi maliyet gelecekteki olası tasarruf değer.

Bu, sözleşmenin size verilip verilmeyeceğine veya istendiği gibi PHP kullanarak uygulayacak başka bir geliştiriciye karar vermelerinden farklı değildir.

Gelebileceğim en iyi gerçek dünya benzetmesi, "BMW'nin pazar payı daha küçük olduğu için BMW yerine bir Ford satın alır mıydınız?"

Nihayetinde, PHP programcıları Rails programcılarının yarı maliyetidir ve yarın daha iyi bir iş bulursanız ne olur? Patronunuz bir Rails geliştiricisi bulmak için tamamen berbat ve çabalıyor ve Rails geliştiricileri yetersiz tedarik edildiğinden bu zaman ve para gerektiriyor.

Patronunuzun kabul etmesinin tek nedeni, SİZİ daha mutlu edecek gibi hissetmesi ve istediğiniz kararları vermenize izin vererek onun için daha mutlu olmanız ve böylece daha üretken olmanızdır.