Причины не кодировать программу?

Ответ 1

• Дешевле купить.
• Если домен незнакомо с существующими разработчиками
• Если уровень риска недопустимо высокий
• Время критичности.

Хотя в конце дня все сводится, так или иначе, к пункту 1.

Ответ 2

Простой; ПОКУПАТЬ, когда общая стоимость владения (TCO) для написания собственного значения больше, чем совокупная стоимость владения пакетом. (Как вы надежно разрабатываете TCO для написания собственного, это упражнение, оставленное читателю;-))

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

Ответ 3

Уже существует очень похожая программа. Если вы не делаете это для удовольствия/обучения

Ответ 4

Преимущества покупки компонента: - Возможно, было бы дешевле купить его, чем его развить - (в некоторых случаях) у команды нет ноу-хау для разработки этого компонента. Таким образом, время, чтобы собрать это ноу-хау, является запретительным - Расходы на техническое обслуживание переданы поставщику.

Неудобство - Отсутствие контроля жизненного цикла компонента (в том числе при создании новых выпусков, каких исправлений и т.д.) - Это может потребовать усилий по адаптации/интеграции. - Это может привести к нарушениям производительности из-за проблем с интеграцией.

Ответ 5

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

Я работаю в сфере финансов, и есть несколько систем поставщиков (примеры - Murex, Summit и Sophis), которые выполняют функции риск/бронирование/бэк-офис для различных продуктов финансового рынка. Я думаю, что их выбор опасен по двум причинам.

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

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

Я потерял счет количества фирм, которых я видел, которые отчаянно пытаются отключить системы с добавлением стоимости (типичные примеры: Murex, Sophis, Summit... см. выше:) и писать свои собственные.

Дополнительный аргумент против систем поставщиков для добавленной стоимости заключается в том, что консультанты/подрядчики обычно намного дороже. Старшего консультанта С# можно получить здесь за £ x00 в день. Консультант с опытом работы с поставщиками будет на 20-25% больше.

Ответ 6

Я бы дал им истинные причины (предполагая, что я был в компании, на которой я действительно хотел работать, то есть вместо того, чтобы поработить PHB). Обычно это "Я заработаю свою работу быстрее, если у меня есть это, и мое время для вас очень дорого".

Но быть более полезным: если возникает вопрос: "Когда возникают ситуации, когда вы хотите заплатить за программное обеспечение?", тогда:

• Когда рассматриваемое программное обеспечение не является основной компетенцией, из которой компания делает свои деньги. В случае не-софтверных компаний то же самое, но с "департаментом", а не "компанией" и "оправдывает его существование", а не "делает свои деньги". Итак, мы собираемся получить пакет, вопрос в том, стоит ли покупать дорогой.

В КОТОРОМ СЛУЧАЕ

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

В качестве альтернативы:

• Когда пакет представляет собой не просто программное обеспечение, он представляет собой размещенную услугу, и затраты на организацию обучения кого-либо, чтобы установить услугу, и поддержание целого человека по вызову 24/7, чтобы поддерживать его, было бы даже больше, чем "дорогой" пакет. Это еще одна часть TCO, но она применяется, даже если само программное обеспечение стоит одинаково в любом случае.

То, что означает первый пункт, заключается в том, что игровые компании не должны писать собственные IDE, компании веб-приложений не должны писать свои собственные компиляторы, отделы банковского программного обеспечения не должны писать офисные приложения и т.д., если вы действительно подумайте, что вам лучше это делать, чем писать игры или веб-приложения, или торговое программное обеспечение, или то, что у вас есть на самом деле крайние сроки. Очевидно, что есть некоторые исключения: если вы хотите маленький маленький script или webapp, может быть проще просто написать его, чем найти что-то с полки, которое делает то, что вам нужно.

Во втором пункте "лучше" означает разные вещи для разных организаций. Предполагая равную функциональность, если ваш отдел заполнен Linux-выродками, тогда бесплатный вариант, вероятно, имеет больше плюсов, чем если бы у вас не было Linux-гиков, а также требуется SLA в рассматриваемом пакете. Если "пакет" собирается быть скомпилирован в ваш несвободный продукт, а не просто поддерживать ваше развитие, то очевидно, что программное обеспечение free-as-in-GPL бесполезно для вас, тогда как Free-as-in-MIT, вероятно, будет хорошо. И так далее.

Ответ 7

Очень упрощенно, но выберите наименьшее из:

• Для инструмента для дома: cost = (task_execution_time * использует * $/user-h + tool_development_time * $/dev-h
• Для приобретенного инструмента: cost = task_execution_time * использует * $/user-h + tool_purchase_price
• Без инструмента: cost = task_execution_time * использует * $/user-h

стоимость - это стоимость выполнения task uses количества раз. task_execution_time - это время (person-), которое требуется для выполнения задачи, включая любые накладные расходы, tool_development_time - это время, необходимое для разработки инструмента.

Я оставляю много переменных, чтобы это было просто. Добавьте еще один:)

Ответ 8

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

Ответ 9

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

Ответ 10

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

• Отсутствие знаний и опыта в организации
• Отсутствие рабочей силы для быстрой адаптации к изменениям на рынке или в законодательстве (налогообложение).

Преимущества аутсорсинга:

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

Ответ 11

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

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

Ответ 12

Некоторые причины

• Решение не поддерживает основной бизнес-процесс, но товарный процесс, например, управление финансами, персоналом, средствами управления, где вы ничем не отличаетесь от своих конкурентов (ваши основные/неактивные процессы будут меняться!). Ваши навыки внутреннего развития будут лучше использоваться для создания и поддержки решений, которые дают вашей компании конкурентное преимущество.
• Первое применяется в пиках, если решение не нуждается в большой интеграции с существующими или будущими решениями (оно поддерживает относительно изолированный процесс).
• Нет необходимости в бюджете и обслуживании персонала на протяжении всего жизненного цикла встроенного приложения. Числа меняются, но одна цифра, которую я видел и считаю вполне правдоподобной, заключается в том, что первоначальные затраты на разработку настраиваемого приложения учитывают только одну десятую общую стоимость жизненного цикла. Конечно, это включает в себя такие вещи, как обучение конечных пользователей, модернизация и интеграция O/S, которая также попадает в решение, полученное извне, но 10-процентный фактор на начальной цене заставит большинство руководителей сделать паузу.
• Особый случай первого: навыки для разработки, обслуживания и операций могут отсутствовать или быть узким местом в вашей организации. Каждый недостаток квалифицированного персонала может быть заполнен достаточным количеством времени и денег, но не обязательно в пределах приемлемых границ. Каждый дополнительный навык, необходимый вашим персоналу, означает меньшее время для разработки и поддержания существующих навыков: стоимость навыков в разнообразном техническом ландшафте растет более чем линейно...
• Как, например, Питер утверждает: предсказуемый, но высокие затраты могут превзойти риски запуска проекта разработки в бизнесе, где перерасход средств в 20% часто считается успешным проектом, тогда как безуспешные проекты в принципе не имеют ограничений...
• Как отмечает Ватина, коммерческое программное обеспечение может быть теперь, отложенное только путем установки и обучения конечных пользователей. Конечно, установка чего-то типа SAP не выполняется за один день...

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

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

Ответ 13

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

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

Однако одноразовые затраты на основное программное обеспечение, которое не обеспечивает основную функцию, легко оправдать, будь то огромная сумма денег для Oracle, приличная система CMS, CRM или клиентской системы, которая вам нужна по последней неделю.

Ответ 14

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

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

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

Ответ 15

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

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

Ответ 16

Я думаю, что аналогия будет подходящей.

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

Вместо этого вы собираетесь объединиться с кем-то, кто сделает лучшие шины и кто-то, кто сделает лучшие кадры и объединит ваш двигатель с ними. Это экономит ваше время и деньги, поскольку вы фокусируетесь на своем продукте, не предоставляя поддерживающую инфраструктуру.

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