Как объяснить клиенту, что Вы не можете дать им часть источника
У нас есть много компонентов AS/Flex, которые мы создавали со временем и улучшали. Они были превращены в компоненты, таким образом, они могут быть снова использованы в различных проектах и сэкономить нам время. Таким образом, можно думать о них как о части внутренней своего рода платформы.
Мы теперь понимаем, что не имеет смысла выпускать исходный код для этих компонентов различным клиентам как часть проекта, потому что технически этот код действительно не принадлежит клиентам.
Так мой вопрос
Когда клиент приезжает к Вам, как Вы объясняете им, что не можете дать им полный исходный код для тех компонентов. Клиент не понимает различия, он просто ожидает, что Вы дадите им весь код для сайта, который он заплатил Вам, чтобы сделать. Он не понимает, что этот код взял Вас намного дольше для записи, чем, что он оплачивает свой сайт. Но так как он не понимает, он выключить и думает, что Вы срываете его или что-то.
Как Вы обрабатываете эту ситуацию? Что Вы говорите клиентам заранее? Вы рекламируете его на своем сайте с самого начала? Как Вы обрабатываете их возражения, таким образом, они все еще нанимают Вас?
Как вопрос о стороне, как часто Вы даете AS и Исходный код Flex Вашим клиентам? В случае, когда код не имеет никаких внутренних компонентов, которые Вы снова используете в нескольких проектах, и в случае, когда он действительно имеет внутренние компоненты.
Я также хотел бы получить известие от людей, которые работали в творческих агентствах, так как они наиболее вероятны уже, столкнулись с той проблемой.
5 ответов
Я бы объяснил своему клиенту, как устроен мир. Я бы использовал примеры, аналогии и метафоры.
Это не проблема разработки программного обеспечения, это относится ко всем продуктам. Некоторые вещи продаются как черный ящик, а некоторые - как прозрачный ящик, внутри которого находятся черные ящики.
Допустим, вы хотите купить дом. Вы платите инженеру и архитектору за их работу и получаете документы, которые они составляют. Эти документы содержат информацию, которая опирается на другие части информации, которые вы не получаете. Например, инженер может использовать в своих планах огромные стальные прутья. Спецификации инженера определяют качества, которыми должен обладать каждый стальной прут, но они не определяют, как эти пруты создаются. Покупая планы домов, вы не покупаете планы создания строительных блоков дома. С программным обеспечением дело обстоит примерно так же: покупая приложение .NET "с включенным исходным кодом", вы не получаете исходный код фреймворка .NET. Что вы получаете, так это документацию .NET, определяющую, как работать с фреймворком (и не определяющую, как фреймворк делает то, что он делает).
Количество примеров на самом деле бесконечно, потому что - как было сказано выше - так устроен мир.
Создавайте свои собственные аналогии в соответствии с вашим сценарием. Объясните клиенту, где заканчивается инфраструктура и начинается его собственное решение.
quoo прав насчет необходимости указать это в контракте. Контракт - это юридическая основа сделки. Но я хотел бы подчеркнуть тот факт, что указывать на контракт следует в последнюю очередь. Если вы можете дать клиенту разумное объяснение, которое позволит ему понять, почему все так, как есть, вам не придется размахивать контрактом (в котором прописано только то, как все есть, без мотивации, объяснений и т.д.).
Просто объясните, что вы не можете предоставить исходный код для внешних библиотек, которые вы использовали в его проекте, чтобы сделать ставку для него дешевле. Он не ожидал бы источника от стороннего поставщика, который вы использовали в его проекте, просто попытайтесь объяснить, что это точно такая же ситуация.
Я не деловой человек, но обычно это оговаривается в контракте. Если в вашем контракте указано, что вы предоставляете клиенту исходный код в конце проекта, то, по крайней мере, вы должны предоставить им swcs ваших компонентов, чтобы они могли при необходимости перекомпилировать код. Если вы не хотите делиться своим кодом с клиентом, это тоже нужно указать заранее.
Вопросы интеллектуальной собственности должны решаться заранее в рамках контракта. Я не юрист, но общепринятая практика заключается в том, чтобы указать:
- Какие компоненты предоставляются третьими сторонами и ссылаться на их условия лицензирования
- Какой код будет создан в рамках контракта.
- Лицензируете ли вы или продаете различные права интеллектуальной собственности.
- Условия лицензирования.
Законы об интеллектуальной собственности `сложны и разнообразны, они различаются от страны к стране. В зависимости от того, где вы находитесь и где находится ваш клиент, возможно, потребуется изменить условия лицензирования. Например, обратный инжиниринг рассматривается по-разному в разных юрисдикциях.
Помимо сторонних компонентов и программного обеспечения, которые вы не хотите продавать или предоставлять исключительную лицензию, вы, вероятно, захотите иметь возможность выставлять и распространять работы как часть портфолио вашей компании.Этот последний вид деятельности также должен быть включен в контракт.
Если заранее подготовить хорошо составленный контракт, это избавит от множества недоразумений и ненужных переговоров. Вам, вероятно, понадобится всего один шаблон, который вы сможете использовать для всех своих клиентов. Так что мой совет на самом деле «поговорите с юристом» .
В вашем контракте должно быть четко указано, что разработанные вами компоненты лицензируются клиенту для использования в рамках проекта и только проекта(ов), который вы для него сделали. Конечно, вам нужно будет определить точную формулировку для себя и ситуации, но если вы неоднократно используете эти компоненты в своих проектах, вам действительно следует иметь что-то вроде шаблона именно для этой ситуации.