Как вы делаете случай для Django [или Ruby on Rails] для нетехнических клиентов

Предприниматели обычно хотят разработать веб-приложение. Они знают о .net или J2EE по именам, не зная об этом.

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

Задача начинается с введения Django (или Rails), цитируя некоторые блоги/исследования. Затем создайте пример использования рамки для конкретного проекта.

Ложь задачи повторяется. Каковы источники/блоги/документы и другие материалы, которые вы используете для создания случая для django (или Rails)

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

Кажется, достаточно обсуждения Django vs Rails. В то время как потребность в (Django и Rails) vs (.net и J2EE), по крайней мере, при создании бизнес-кейса. Оба представляют собой более быструю прагматичную веб-разработку на динамическом языке.

ОТВЕТЫ

Ответ 1

Проще просить прощения, кроме разрешения.

Сначала создайте начальную версию в Django. Быстро. Постройте модель хорошо (действительно хорошо!). Но используйте как можно больше функциональных возможностей администратора по умолчанию.

Проведите время только для отчетов и отображения страниц, где HTML может иметь значение для презентации.

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

Ответ 2

Вам нужно говорить на языке бизнеса: деньги.

"Если мы сделаем это Rails, это будет стоить вам на 50% меньше, чем те же функции на Java".

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

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

Ответ 3

Прежде чем приступать к созданию Django или Rails, вы должны убедиться в правильном стеке в первую очередь в контексте потребностей бизнеса. Если бизнес-лицо является предпринимателем, у него могут быть другие факторы, выходящие за рамки того, как быстро может быть разработано решение. Например:

  • Если его предприятие играет, что разрабатывается (что-то вроде SalesForce.com, SugarCRM и т.д.), может иметь смысл записать его на Java, потому что это облегчает приобретение и слияние с потенциальными разработчиками Java.
  • Если его внутренняя ИТ-игра для пользовательского решения в крупной компании, у них может быть уже значительная инфраструктура MS. Возможно, не имеет смысла, чтобы ваш клиент устанавливал SQLServer или еще больше усложнял свой стек с помощью удобного для Rails/Django стека.

Если вы преодолели эту пропасть и убедились, что у вас есть лучший интерес для клиента, я бы посмотрел примеры в Интернете, где одно и то же приложение было создано как в Java, так и в Rails/Django. Вот пример магазина домашних животных, реализованного в Rails.

http://www.anassina.com/projects/railspetstore/

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

Объясните клиенту, почему менее ценный код: чем меньше вы пишете код, тем меньше ошибок у вас будет.

Ответ 4

Первые два аргумента из моего разума:

  • Простое и быстрое развитие = более дешевый продукт, меньше времени для выхода на рынок.

  • Оптимизация SO из коробки.

Ответ 5

В то время как многие из вас сделали несколько хороших предложений, WRT переговоры/ресурсы для использования этих фреймворков, вы также можете обратить внимание на поговорить о перепроектировании желтые страницы в ROR:

Сводка с сайта:

В этом разговоре объясняется, как YELLOWPAGES.COM, один из сайты с самым высоким трафиком в США, был написан с использованием Ruby on Rails, как он был масштабирован для обработки трафика и как архитектура программного обеспечения эволюционировали. Также: причины выбрав Ruby on Rails.

Ответ 6

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

Ответ 7

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