Как я могу защитить Ruby on Rails от не технического мнения клиентов?

Мой клиент, владелец переводческого бизнеса, только что сказал мне, что он читает о Ruby on Rails, и сказал, что « там больше PHP-ребят » и « кажется, сообщество это предпочитает ». Что бы вы, как инженер-программист и фрилансер, сказали бы клиенту для достижения этих целей:

• Продам
• Пусть он увидит, что технология - это мое экспертное решение, и Rails такой же или лучше, чем PHP (+ любая платформа) для этого конкретного проекта.

ОБНОВЛЕНИЕ: Спасибо всем за предложения! Завтра у меня еще одна встреча с ним, посмотрим как получится, обновлю еще раз :)

ОБНОВЛЕНИЕ 2: Наконец я сказал ему прочитать эту ветку, и результат был фантастическим: он дал мне проект, и мы собираемся начать прямо сейчас. Спасибо всем за помощь, у вас есть бесплатное пиво в моем ведении, если мы увидим когда-нибудь :)

Кстати, я усвоил урок: будь как можно более прозрачным, потому что, если ты веришь в себя и свою работу, нет никаких сомнений в том, что ты сможешь победить.

С уважением

Я думаю, вы ошибаетесь, полагая, что выбор технологии - это чисто техническое решение.

Заказчик, похоже, обеспокоен последствиями выбора конкретной технологии для бизнеса. Учитывая это, вам нужно представить дело, которое затрагивает его деловые интересы, по крайней мере, так же сильно, как ваши технологические мнения.

• Работодатели должны принимать на работу из определенной географической области, и у определенных областей есть особенно активные сообщества вокруг определенных технологических стеков. Например, если вы начинаете свой бизнес на тихоокеанском северо-западе США, это сильно повлияет на стек Microsoft просто потому, что Microsoft очень влиятельна в этой области, поэтому большинство разработчиков, которых вы бы хотели нанять, будут иметь опыт работы с этим стеком. Другие географические регионы имеют очень разные профили.
  Поговорите с вашим клиентом и поймите, почему и как он сформировал свое мнение. Возможно, он читал, что местное сообщество PHP особенно активно или что местный колледж преподает много PHP, а не Ruby. Возможно, у него есть надежный разработчик, к которому он может обратиться в случае непредвиденной ситуации, это профессионал PHP и неофит из Ruby. Конечно, также возможно, что он использует плохие показатели, такие как количество объявлений о работе или резюме, в которых упоминаются различные ключевые слова.
• Работодатели должны заботиться о долгосрочной устойчивости технологических стеков. Например, много лет назад многие компании вложили много времени и усилий в создание приложений PowerBuilder (и других языков этого жанра). PowerBuilder часто очень упрощал создание линейки бизнес-приложений, и разработчики в то время были весьма им очарованы. К сожалению, сообщество PowerBuilder более или менее рухнуло, в результате чего компании оказались в ситуации, когда у них было много существующего кода на языке, который никто не хотел использовать, когда у них были трудности с поиском компетентных разработчиков для поддержки существующего кода и дорогих, отнимающих много времени проектов. перенести эти приложения в другие технологические стеки. Относительные технические достоинства PowerBuilder были в сравнении с Java, C ++ или C # или чем-то еще, к чему они перешли;
  Относительно нишевые языки, такие как Ruby, потенциально могут создать такие унаследованные проблемы для компаний, которые не могут предсказать, изменится ли язык через несколько лет, когда люди перейдут к следующему увлечению или у него будет реальная жизненная сила. , Вы, конечно, можете смягчить это, указав, что Ruby не зависит от одной компании или организации, поэтому никто не может решить, что он больше не является стратегическим продуктом для компании. Если в прошлом ваш клиент был сожжен из-за того, что приложения разрабатывались на языках, которые стали головной болью для бизнеса, вам нужно будет доказать, что Ruby больше похож на Linux и другие технологии с открытым исходным кодом, которые процветали без поддержки со стороны компании, чем на языках с вымер за эти годы.
• Работодатели хотят последовательности в окружающей среде, поэтому выбор языка для одного проекта делает выбор для многих других. Даже если Ruby технически идеально подходит для проекта, который вы представляете, вы должны объяснить, почему он подходит для любого другого приложения, которое потребуется заказчику, или объяснить, какое сочетание технологий вы считаете подходящим (например, Ruby для X, что-то еще для тебя). Однако работа с разнородными технологиями неизбежно приводит к дополнительным затратам для бизнеса.

Для начала вы можете направить своего клиента сюда, чтобы взглянуть на экосистему, которая существует вокруг Rails. Вы также можете указать на успешные стартапы, такие как LivingSocial, Shopify, 37signals и т. Д., Которые построили свой бизнес на Ruby и Rails.

Можно упомянуть, что крупные предприятия, такие как AT & T, SAP и Symantec, также используют Rails (в прошлом году все они активно набирались на RailsConf).

Вы можете отметить, что бизнес по переводу может получить много пользы, используя язык / среду, которая делает поддержку Unicode и i18n относительно безболезненной.

В конечном счете, я думаю, что вам нужно продать идею о том, что возможность использовать Rails является премиальной функцией, которую он получает, нанимая вас: «Конечно, все эти другие ребята используют PHP. Но у вас есть возможность иметь современный стек, питающий ваше приложение. «.

В конце дня также должно быть ясно, что в конечном итоге он покупает ваши навыки и опыт; если бы он был настолько хорошо осведомлен о серверных веб-технологиях, он бы вам не понадобился. Язык и структура являются решениями по реализации, а не требованиями.

PS Не упоминайте Twitter. Мы все еще пытаемся отменить плохие PR-рельсы, взятые из этого.

Я бы объяснил, что это в основном выбор «Колы» против «Пепси». Оба получили широкое признание, у обоих есть люди, которые будут сражаться и умирать за каждого, и они оба совершенно адекватны. Укажите причины, по которым вы предпочитаете RoR.

Он говорит о людях, вы говорите о языке и структуре. Он не собирается слышать никаких технических причин, поэтому вам следует сосредоточиться на том, что люди делают с языком . Вы можете говорить о силах людей в Rails, о том, как одному человеку проще делать больше, чем человеку PHP, быстрее (если вы в это верите). Вы можете спросить, означает ли преобладание водителей Honda, что это лучший автомобиль, чем Rolls Royce, который редко можно увидеть. Вы можете поговорить о том, из чего на самом деле состоит сообщество, есть ли в модульном супе слишком много поваров (самоцветы и модули и т. Д.), Есть ли у всех синдром НИЗ и так далее.

Независимо от этого, это должно быть с точки зрения людей, потому что он хочет знать, что он может заменить вас. Помогите ему узнать это, потому что он (вероятно) не захочет уходить в любом случае. Ваше «экспертное решение» не имеет абсолютно никакого отношения, когда он уделяет гораздо меньше внимания тому, что знает данный человек. Он просто хочет, чтобы было «больше людей», которые знают то же самое.

В конце концов, не стыдно называть его блефом. "Хорошо, иди с PHP. Удачи!"

Укажите, что у толпы PHP больше участников, потому что это самый низкий барьер для входа и существует дольше. Обязательно отметьте, что в небольших сообществах более высокий процент программистов, которых стоит нанимать, PHP может иметь 10 000 хороших программистов по сравнению с 5000 программистами rails, но программисты PHP скрыты в блоке 100 000 по сравнению с 20 000 для программистов rails. (Эти цифры составлены, но все понятно.) Затем вам нужно объяснить, что у сообщества действительно нет предпочтений между PHP и Rails.

Вы не можете использовать технические причины для не технического специалиста, вы не можете объяснить, почему iPhone уступает другим смартфонам тому, кто знает только, как выглядят телефоны. Вам нужны причины, которые они понимают.

Ваш клиент нанял вас, так что, вероятно, он доверяет вашему опыту. Объясните, что разные специалисты могут предпочесть разные инструменты, и ваш предпочтительный инструмент - RoR. Укажите присутствие сообщества и признание сообщества, которое существует для RoR и успешных компаний, таких как 37signals, использующих его, чтобы снять с него озабоченность тем, что вы рекомендуете некоторые тайные технологии, о которых никто, кроме вас, не знает. Укажите, что вы будете более продуктивными, используя инструменты, которые предпочитаете (таким образом, снижая его затраты и улучшая его успехи), и что если вам или ему когда-нибудь понадобится найти больше экспертов по RoR, это будет не сложно. Если он более техничен, вы можете указать, как RoR может быть успешным в задачах, которые ему нужны, по сравнению с его предпочтительным решением.

Старайтесь не повторять FUD и вообще унижать PHP - если вы не являетесь экспертом в PHP, есть большая вероятность, что вы скажете что-то неточное, неправильное или крайне противоречивое, и если ваш клиент узнает, что вы ошиблись, это может повредить Ваш авторитет с ним в других аспектах.

Ваш босс имеет смысл. PHP гораздо более популярен, чем RoR, для нескольких сайтов, которые пытаются отслеживать такие вещи. Например, см. Http://lang-index.sourceforge.net и http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Я думаю, что было бы глупо игнорировать факты.

Я предлагаю вам признать, что у него есть смысл, а затем напомнить ему, что у RoR тоже есть сильные последователи. Не мешало бы иметь несколько ссылок на популярные сайты, созданные с помощью RoR, которые вы можете показать ему.

В конце концов, он действительно ищет вашу уверенность в том, что он принимает правильное деловое решение и хочет, чтобы доказательства подтвердили это. Как гласит старая пословица: «Никто никогда не стрелял в них за рекомендацию Microsoft». То же самое касается PHP в веб-разработке. Дайте ему убедительные факты и избегайте мнений. У тебя все будет хорошо.

Переведите ваши убеждения в поддающиеся количественному выражению экономические термины (если это возможно / действительно). Тот факт, что его бизнес ориентирован на перевод, говорит о том, что RoR (или любой язык с родной многоязычной поддержкой) технически превосходит PHP - но это должно быть компенсировано затратами разработчиков и предоставлением серверов, связанными с этими соответствующими платформами. Их бизнес, вероятно, продлится дольше, чем ваши отношения, они захотят заверить, что они закладывают правильную основу.

ИММ, признание минусов (а также плюсов) вашей стратегии более убедительно, чем любое количество евангелизации - это говорит о том, что вы больше заинтересованы в решении их проблемы, чем в использовании своего любимого молотка.

Ваш клиент может иметь действительную точку. Спрос и предложение влияет на цены. Если количество разработчиков, обладающих определенными навыками в географической области заказчиков, невелико, цена на обслуживание программного обеспечения, требующего более редкого набора навыков, со временем может увеличиться больше, чем если бы программное обеспечение разрабатывалось с использованием более популярного языка, для которого было значительно больше местный пул опытных разработчиков. Таким образом, проблема также может быть связана с долгосрочным управлением рисками.

Когда у меня есть клиент, который хочет использовать конкретный инструмент, потому что он «отраслевой стандарт», имеет «консенсус» или «то, что используют все», я отмечаю им, что все эти термины являются кодом для «среднего по отрасли». " Это то, что делает большинство других людей в этом районе. «Средний» бизнес терпит неудачу. Подбирайте свои инструменты, основываясь на требованиях к работе, а не на том, что делают все остальные. Меньшее количество программистов RoR не имеет значения, если системе не нужно так много возиться, когда это будет сделано.

Конечно, это бизнес-решение для вас обоих .

Для вас вопросы:

• Сколько будет стоить мне реализовать требования своих клиентов с помощью Ruby on Rails?
• Сколько будет стоить мне реализовать их в PHP?
• Какую ценность я придаю использованию моей предпочтительной среды?

Для вашего клиента вопрос

• Сколько стоят мне преимущества PHP по сравнению с Ruby on Rails?

Если вы предоставите своему клиенту предложение с Ценой для реализации с использованием Ruby on Rails и отдельной Ценой для реализации с использованием PHP , оба из которых основаны на ответах на ваши собственные вопросы, то ваш клиент может сделать свой собственный выбор в отношении того, стоит ли Стоимость сейчас стоит возможной будущей экономии.

Это не отличается от того, как они принимают решение относительно того, должны ли они отдавать контракт вам или другому разработчику, который будет реализовывать его с использованием PHP по запросу.

Лучшая аналогия в реальном мире, которую я могу придумать: «Купил бы Ford, а не BMW только потому, что доля BMW на рынке меньше?».

В конечном счете, PHP программисты - это половина стоимости Rails-программистов, и что вы сделаете, если завтра найдете лучшую работу? Ваш босс был бы совершенно не в силах найти разработчика Rails, а это требует времени и денег, так как разработчиков Rails не хватает.

Единственная причина, по которой ваш босс согласился бы с этим, заключается в том, что если вы чувствуете, что это сделает вас счастливее, и если вы позволите принимать решения, которые вы хотите, вы будете счастливее работать на него и, следовательно, будете более продуктивными.