Jak mogę bronić Ruby on Rails przed opinią nietechniczną klientów?

16

Mój klient, właściciel firmy tłumaczeniowej, właśnie powiedział mi, że czytał o Ruby on Rails i powiedział mi, że „jest tam więcej ludzi z PHP ” i „ wygląda na to, że społeczność woli ”. Co byś, jako inżynier oprogramowania i freelancer, powiedział klientowi, aby osiągnąć te cele:

  • Sprzedać
  • Spraw, by zobaczył, że technologia jest moją decyzją eksperta, a Rails jest tak dobry lub lepszy niż PHP (+ jakiekolwiek ramy) dla tego konkretnego projektu.

AKTUALIZACJA: Dziękujemy wszystkim za sugestie! Jutro mam kolejne spotkanie z nim, zobaczmy, jak to będzie, zaktualizuję ponownie :)

AKTUALIZACJA 2: W końcu powiedziałem mu, żeby przeczytał ten wątek, a wynik był fantastyczny: dał mi projekt i zaraz zaczniemy. Dziękuję wszystkim za pomoc, jeśli za jakiś czas się zobaczymy, masz do dyspozycji darmowe piwo :)

BTW: Nauczyłem się tej lekcji: bądź tak przejrzysty, jak to możliwe, ponieważ jeśli wierzysz w siebie i swoją pracę, nie ma mowy o kompromisach na tyle, by cię pokonać.

pozdrowienia

okeen
źródło
2
Głosuję, aby przenieść to pytanie ... Zastanowiłbym się jednak nad przykładami zastosowań branżowych, takich jak shopify.com, twitter.com itp., A także wyjaśniłem, że rozwój w Railsach jest zazwyczaj szybszy niż rozwój w PHP (to moja opinia ).
iwasrobbed

Odpowiedzi:

47

Myślę, że popełniacie błąd, zakładając, że wybór technologii jest decyzją czysto techniczną.

Klient wydaje się być zaniepokojony konsekwencjami biznesowymi wyboru określonej technologii. Biorąc to pod uwagę, musisz przedstawić przypadek, który rozwiąże jego problemy biznesowe przynajmniej tak mocno, jak Twoje opinie technologiczne.

  • Pracodawcy muszą rekrutować pracowników z określonego obszaru geograficznego, a niektóre obszary mają szczególnie aktywne społeczności wokół określonych stosów technologii. Na przykład, jeśli zaczynasz działalność na północno-zachodnim wybrzeżu Pacyfiku w Stanach Zjednoczonych, silna stronniczość w stosunku do stosu Microsoft po prostu dlatego, że Microsoft ma duży wpływ w tym obszarze, więc większość programistów, których chciałbyś zatrudnić, mieć doświadczenie z tym stosem. Inne regiony geograficzne mają bardzo różne profile.
    Porozmawiaj ze swoim klientem i zrozum, dlaczego i jak ukształtował swoją opinię. Być może przeczytał, że lokalna społeczność PHP jest szczególnie aktywna lub że miejscowa uczelnia uczy dużo PHP, a nie Ruby. Być może ma zaufanego programistę, do którego może zadzwonić w razie nagłego wypadku, jakim jest zawodowiec PHP i neofita Ruby. Oczywiście możliwe jest również, że używa złych wskaźników, takich jak liczba ogłoszeń o pracę lub CV, które zawierają różne słowa kluczowe.
  • Pracodawcy muszą martwić się długoterminową trwałością stosów technologii. Na przykład wiele lat temu wiele firm zainwestowało dużo czasu i wysiłku w tworzenie aplikacji PowerBuilder (i innych języków tego gatunku). PowerBuilder często ułatwiał tworzenie linii aplikacji biznesowych, a programiści byli w tym czasie bardzo zakochani. Niestety społeczność PowerBuilder mniej więcej upadła, pozostawiając firmy w sytuacji, w której posiadały dużo istniejącego kodu w języku, którego nikt tak naprawdę nie chciał używać, w którym mieli trudności z uzyskaniem kompetentnych programistów do utrzymania istniejącego kodu i kosztownych, czasochłonnych projektów aby przenieść te aplikacje na inne stosy technologii. Względne zalety techniczne PowerBuilder były w porównaniu z Javą, C ++ lub C # lub czymkolwiek, do czego migrowały w tym momencie;
    Względnie niszowe języki, takie jak Ruby, mają absolutnie potencjał do stworzenia tego rodzaju problemów dla firm, które nie są w stanie przewidzieć, czy język zniknie za kilka lat, gdy ludzie przejdą do następnej mody, czy też ma prawdziwą siłę . Z pewnością możesz to złagodzić, wskazując, że Ruby nie jest zależna od jednej firmy lub organizacji, więc nikt nie może zdecydować, że nie jest to już strategiczny produkt dla firmy. Jeśli twój klient był w przeszłości palony przez tworzenie aplikacji w językach, które stały się problemami biznesowymi, musisz udowodnić, że Ruby bardziej przypomina Linux i inne technologie open source, które kwitły bez wsparcia firmy niż języki, które mają wymarł z biegiem lat.
  • Pracodawcy chcą spójności w środowisku, dlatego wybór języka dla jednego projektu wymusza wybór dla wielu innych. Nawet jeśli Ruby jest technicznie idealny do projektu, który realizujesz, musisz wyjaśnić, dlaczego jest odpowiedni dla każdej innej aplikacji, której ten klient będzie potrzebował, lub wyjaśnić, jaką kombinację technologii uważasz za stosowną (tj. Ruby dla X, coś innego dla Ciebie). Radzenie sobie z heterogenicznymi technologiami nieuchronnie przekłada się jednak na dodatkowe koszty dla firmy.
Justin Cave
źródło
17
+1 Uważam, że wiele osób na tym forum koncentruje się na akademickich powodach wyboru i wydaje się, że ignorują ekonomię
dietbuddha
10
+1 za poruszenie prawdziwych problemów związanych z biznesem (i za napisanie większości tego, co chciałem powiedzieć, oszczędzając mi w ten sposób czas :))
jcmeloni
Mógłbym dodać jeszcze kilka powodów biznesowych lub kilka technicznych powodów, dla których Ruby nie jest odpowiedzią na każdy projekt dotyczący zwierząt domowych. Ale przybiłeś ją całkiem dobrze, więc dwa kciuki do góry!
Alex
2
Ok, dziękuję za lekcję realizmu Justina i wysiłek napisania odpowiedzi, naprawdę to doceniam.
okeen
1
Chciałbym wskazać coś, co jest nieco zabezpieczone w tej odpowiedzi: Twój klient może mieć rację. Być może nie jest to technicznie lepsza odpowiedź, ale jak wskazano, jego obawy mogą być uzasadnione, a RoR może zgnieść się i umrzeć, jakkolwiek mało prawdopodobne. Z pewnością dobrze jest przedstawić swoją opinię techniczną, ponieważ klient potrzebuje jej również do podjęcia świadomej decyzji.
MattG
8

Na początek możesz skierować swojego klienta tutaj, aby spojrzał na ekosystem, który istnieje wokół Railsów. Możesz także wskazać udane start-upy, takie jak LivingSocial, Shopify, 37signals itp., Które zbudowały swoje firmy za pomocą Ruby i Rails.

Możesz wspomnieć, że ogromne firmy, takie jak AT&T, SAP i Symantec, również korzystają z Railsów (wszystkie w ubiegłym roku intensywnie rekrutowały na RailsConf).

Można zauważyć, że firma tłumaczeniowa może wiele zyskać, korzystając z języka / frameworka, który sprawia, że ​​obsługa Unicode i i18n są stosunkowo bezbolesne.

Ostatecznie myślę, że musisz sprzedać pomysł, że możliwość korzystania z Railsów jest cechą premium, którą dostaje, zatrudniając cię: „Oczywiście ci wszyscy inni faceci używają PHP. Ale masz okazję mieć nowoczesny stos napędzający twoją aplikację . ”

Na koniec dnia musi również być jasne, że to, co ostatecznie kupuje, to twoje umiejętności i wiedza; gdyby był tak kompetentny w zakresie technologii sieciowych po stronie serwera, nie potrzebowałby cię. Język i struktura to decyzje wdrożeniowe, a nie wymagania.

PS Nie wspominaj o Twitterze. Nadal staramy się cofnąć złą wersję PR Railsów.

Jason Lewis
źródło
6

Wyjaśniłbym, że jest to w zasadzie wybór „Coli” vs. „Pepsi”. Oba są powszechnie akceptowane, oboje mają ludzi, którzy będą walczyć i umrą za każdego z nich, i oboje są całkowicie wystarczający. Wskaż powody, dla których wolisz RoR.

Brian Knoblauch
źródło
4
Nie sądzę, żeby to pomogło w tej sytuacji. Jeśli to naprawdę kwestia osobistego gustu, prawdopodobna odpowiedź będzie brzmiała: „Cóż, kupuję, więc używaj PHPepsi, ponieważ konsultanci ds. Programowania konserwacji będą dla mnie tańsi w dalszej drodze”. Korzystanie z Ruby musi być propozycją wartości dodanej, a natywna wielojęzyczna obsługa stanowi zdecydowany plus dla firmy tłumaczeniowej.
Jason Lewis,
6

On mówi o ludziach, ty mówisz o języku i strukturze. Nie usłyszy żadnych powodów, które są czysto techniczne, więc powinieneś skupić się na tym, co ludzie robią z językiem . Możesz porozmawiać o sile ludzi w Railsach, jak łatwiej jednej osobie zrobić więcej niż PHP, szybciej (jeśli tak uważasz). Możesz zapytać, czy przewaga kierowców Hondy oznacza, że ​​jest to lepszy samochód niż Rolls Royce, co rzadko się widuje. Możesz porozmawiać o tym, z czego składa się społeczność, czy w zupie modułowej jest zbyt wielu kucharzy (klejnoty vs. moduły itp.), Czy wszyscy mają zespół NIH i tak dalej.

Niezależnie od tego, musi to dotyczyć ludzi, ponieważ chce wiedzieć, że może cię zastąpić. Pomóż mu to wiedzieć, ponieważ (prawdopodobnie) i tak nie będzie chciał się odejść. Twoja „decyzja eksperta” nie ma żadnego znaczenia, gdy poświęca znacznie mniej uwagi temu, co wie dana osoba. Po prostu chce, żeby było „więcej ludzi”, którzy wiedzą to samo.

Pod koniec dnia nie ma wstydu nazywać jego blef. „W porządku, idź z PHP. Powodzenia!”

Eric
źródło
2
Zawsze należy pamiętać, że zwolnienie klienta jest zawsze opcją.
Jason Lewis,
3

Zwróć uwagę, że tłum PHP ma więcej członków, ponieważ jest to najniższa bariera wejścia i istnieje już dłużej. Należy pamiętać, że mniejsze społeczności mają wyższy odsetek programistów wartych zatrudnienia, PHP może mieć 10 000 dobrych programistów w porównaniu do 5 000 programistów szyn, ale programiści PHP są ukryci w bloku 100 000 w porównaniu do 20 000 dla programistów szyn. (Te liczby są wymyślone, ale ma sens.) Następnie musisz wyjaśnić, że społeczność tak naprawdę nie ma preferencji między PHP a Railsami.

Nie można używać powodów technicznych w przypadku osób nietechnicznych, nie można wyjaśnić, dlaczego iPhone jest gorszy od innych smartfonów, komuś, kto wie tylko, jak wyglądają telefony. Potrzebujesz powodów, które rozumieją.

Ryathal
źródło
+1 za wskazanie znaczenia stosunku sygnału do szumu w społecznościach programistów.
Jason Lewis,
2
Fakt, że liczby są wymyślone, prowadzi do wniosku, że punkt również jest wymyślony. Może to być prawda lub fałsz, ale wymagałoby to udowodnienia lub obalenia faktów, których nie ma. Bez faktów jest to po prostu „ssanie, ponieważ grasz w innym zespole”, co nie jest zbyt profesjonalne.
StasM
Zgadzam się i użyłem tego argumentu również z przełożonymi technicznymi. Szanse na to, że wysokiej jakości programiści PHP rzucą się na Python lub Ruby, którzy mają działający RFC i proces wkładu społeczności, rosną z każdym rokiem. PHP jest najbardziej kopiowalnym i łatwym do wklejenia, niskim poziomem barier dla języka wejściowego, przyciągając programistów, których nie chcesz.
Lincoln B,
3

Twój klient cię zatrudnił, więc prawdopodobnie wierzy w twoją wiedzę. Wyjaśnij, że różni profesjonaliści mogą preferować różne narzędzia, a Twoim preferowanym narzędziem jest RoR. Wskaż obecność społeczności i akceptację społeczności dla RoR i odnoszących sukcesy firm, takich jak 37signals, które go używają, aby usunąć jego obawy, że polecasz jakąś tajemną technologię, o której nikt poza tobą nie wie. Zwróć uwagę, że będziesz bardziej produktywny, korzystając z preferowanych narzędzi (obniżając w ten sposób jego koszty i poprawiając jego sukcesy) i że jeśli ty lub on kiedykolwiek będziecie musieli znaleźć więcej ekspertów RoR, nie będzie to trudne. Jeśli jest bardziej techniczny, możesz wskazać, w jaki sposób RoR może odnieść sukces w zadaniach, których potrzebuje, w porównaniu z jego preferowanym rozwiązaniem.

Unikaj powtarzania FUD i ogólnie dyskredytuj PHP - jeśli nie jesteś ekspertem w PHP, istnieje duże prawdopodobieństwo, że powiesz coś niedokładnego, błędnego lub wysoce kontrowersyjnego, a jeśli twój klient dowie się, że się myliłeś, może to zaszkodzić twoją wiarygodność wobec niego w innych aspektach.

StasM
źródło
2

Twój szef ma rację. PHP jest znacznie bardziej popularny niż RoR, akceptując kilka witryn, które starają się śledzić takie rzeczy. Na przykład zobacz http://lang-index.sourceforge.net i http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Myślę, że głupotą byłoby ignorowanie faktów.

Sugeruję, abyś przyznał, że ma rację, a następnie przypomnij mu, że RoR ma również silną pozycję. Nie zaszkodzi mieć kilka linków do popularnych stron zbudowanych z RoR, które możesz mu pokazać.

W końcu naprawdę szuka twojej pewności, że podejmuje właściwą decyzję biznesową i chce dowodów na poparcie tego. Jak mówi stare powiedzenie: „Nikt nigdy nie strzelał do nich ze strzałów za polecenie Microsoft”. To samo dotyczy PHP w tworzeniu stron internetowych. Podaj mu solidne fakty i unikaj opinii. Nic ci nie będzie.

chuck97224
źródło
1
Oryginalne powiedzenie brzmiało: „Nikt nigdy nie został zwolniony za zakup IBM”. Być może powinni byli, ale ...
Matthew Flynn
1
Och, byłem znany z strzelania w ludzi za wybieranie PHP ... :-)
Brian Knoblauch
1

Przetłumacz swoje przekonania na wymierne terminy ekonomiczne (jeśli to możliwe / ważne). Fakt, że jego działalność związana jest z tłumaczeniem, sugeruje, że RoR (lub dowolny język z natywną obsługą wielojęzyczną) jest technicznie lepszy od PHP - ale należy to zrównoważyć z kosztami programistów i udostępniania serwerów związanych z tymi platformami. Ich działalność prawdopodobnie potrwa dłużej niż związek, będą chcieli zapewnić, że kładą odpowiednie fundamenty.

IME, przyznając minusy (jak również wady) od strategii jest bardziej przekonujący niż kwota ewangelizacji - to sugeruje, że jesteś bardziej zainteresowany w rozwiązywaniu ich problemów, niż stosując swój ulubiony młotek.

sunwukung
źródło
1

Twój klient może mieć ważny punkt. Podaż i popyt wpływają na ceny. Jeśli podaż programistów posiadających szczególne umiejętności w obszarze geograficznym klientów jest niska, cena utrzymania oprogramowania wymagającego rzadszych umiejętności może wzrosnąć z czasem bardziej niż gdyby oprogramowanie zostało opracowane przy użyciu bardziej popularnego języka, dla którego istniał znacznie większy lokalna pula wykwalifikowanych programistów. Tak więc problemem może być również długoterminowe zarządzanie ryzykiem kosztów.

hotpaw2
źródło
0

Kiedy mam klienta, który chce użyć określonego narzędzia, ponieważ jest to „standard branżowy”, ma „konsensus” lub jest „tym, czego wszyscy używają”, zwracam uwagę, że wszystkie te warunki są kodem dla „średniej branżowej”. „ To jest to, co robią większość innych ludzi w okolicy. „Przeciętny” biznes kończy się niepowodzeniem. Wybierz narzędzia na podstawie wymagań pracy, a nie tego, co robią wszyscy inni. Jest mniej programistów RoR, nie ma znaczenia, czy system nie potrzebuje aż tyle majsterkowania, kiedy jest gotowy.

Laurence Perkins
źródło
0

Z pewnością jest to decyzja biznesowa dla was obu .

Dla ciebie pytania są następujące:

  • Ile będzie mnie kosztowało wdrożenie wymagań moich klientów za pomocą Ruby on Rails?
  • Ile będzie mnie kosztowało wdrożenie ich w PHP?
  • Jaką wartość przywiązuję do korzystania z preferowanego środowiska?

Pytanie dotyczy twojego klienta

  • Ile warte są dla mnie postrzegane zalety PHP w stosunku do Ruby on Rails?

Jeśli podasz swojemu klientowi ofertę z ceną do wdrożenia za pomocą Ruby on Rails i osobną cenę za wdrożenie za pomocą PHP , obie oparte na odpowiedziach na twoje pytania, wtedy twój klient może samodzielnie ustalić, czy dodatkowe koszt teraz jest wart możliwych oszczędności w przyszłości.

Nie różni się to od tego, czy podejmą decyzję, czy powinni dać kontrakt Tobie, czy innemu programistowi, który wdrożyłby go za pomocą PHP zgodnie z żądaniem.

Mark Booth
źródło
-1

Najlepsza analogia w świecie rzeczywistym, jaką mogę wymyślić, brzmi: „Czy kupiłby raczej Forda niż BMW tylko dlatego, że udział BMW w rynku jest mniejszy?”.

James Anderson
źródło
1
Jest to duża możliwość, jeśli mechanicy serwisowi BMW byliby zbyt daleko, zbyt kosztownie lub bardzo źle oceniani przez agencje konsumenckie dla lokalizacji kupujących.
hotpaw2
@hotpaw - dość sprawiedliwe, ale jest to racjonalne rozważenie, sam udział w rynku jest bez znaczenia.
James Anderson
-1

Ostatecznie programiści PHP są o połowę mniejsi niż programiści Rails, a co, jeśli jutro znajdziesz lepszą pracę? Twój szef byłby kompletnie spieprzony i starałby się znaleźć programistę Rails, a to wymaga czasu i pieniędzy, ponieważ programistów Rails brakuje.

Jedynym powodem, dla którego twój szef się na to zgodzi, jest to, że czujesz, że sprawiłoby to, że byłbyś szczęśliwszy, a to umożliwiając podejmowanie decyzji, które chcesz, byłbyś szczęśliwszy dla niego pracując, a tym samym bardziej produktywny.

Etay Luz
źródło