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

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

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.

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.

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.

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!”

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ą.

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.

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.

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.

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.

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.

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.

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?”.

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.