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

Question

Давайте сыграем адвоката дьявола: по каким причинам вы бы дали руководству НЕ кодировать решение, а приобрести дорогой пакет?

Answer 1

1. Дешевле купить.
2. Если домен незнаком существующим разработчикам
3. Если уровень риска неприемлемо высок
4. критичность по времени.

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

Answer 2

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

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

Answer 3

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

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

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

В каком случае

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

С другой стороны:

• Когда пакет - это не просто программное обеспечение, это размещенная служба, и затраты на организацию обучения кого-либо для установки службы и круглосуточного обслуживания всего человека для ее обслуживания будут даже больше, чем «дорогой» пакет. Это еще одна часть совокупной стоимости владения, но она применяется, даже если само ПО стоит так же в любом случае.

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 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 - это время (человек), необходимое для выполнения задачи, включая любые накладные расходы, tool_development_time - это время, необходимое для разработки инструмента.

Я упускаю множество переменных, чтобы упростить его. Добавить больше к костюму:)

Answer 8

Я думаю, что подойдёт аналогия.

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

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

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

Answer 9

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

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

Answer 10

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

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

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