|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
06.12.2017, 12:14 | #1 |
Заблокирован
Регистрация: 09.08.2017
Сообщений: 1,136
|
Учимся продавать самопал
Россия – родина слонов. Куда не кинь – у каждого зрелого программиста есть несколько личных библиотек и даже фреймворки попадаются. Это неудивительно – надо же накапливать и систематизировать свой опыт.
Однако продавать свои наработки непросто. Несмотря на богатый функционал, проработку архитектуры, оптимизацию алгоритмов и инкапсуляцию, потенциальные клиенты не хотят это покупать. В чём же проблема? - Это отсутствие видимости простоты. Никто не хочет плутать по лабиринтам кода. Что же делать? Вот отличная картинка из библии ООП Гради Буча: См. Рис. внизу. Идея заключается в том, что нельзя сразу предлагать клиенту сложность. Надо создать иллюзию простоты. – Что же можно сделать? Видимо надо создать демонстрационный контекст. Одним из решений этой проблемы я считаю библиотеки компании Stingray. Они создали мастера (визарды), которые генерируют код стартового приложения по опциям. Великолепная идея! Это хороший вектор для развития бизнеса. В книге психолога Дэна Ариэли «Предсказанная иррациональность», демонстрируется бизнес-модель компании IKEA. Оказывается, что простые конструкции мебели IKEA собрать не легко. В чём же дело? Оказалось, что существует обратный эффект. Когда клиент прикладывает значительные усилия для внедрения продукта, то это становиться для него более ЦЕННЫМ! А значит – он получит потом больше удовольствия и будет готов платить больше за такие решения. Таким образом, я делаю вывод на основе этих фактов: чтобы мне продавать свою библиотеку – надо сделать приложение-мастер, которое по выбору пользователя некоторых опций, сгенерирует компактный демонстрационный стартовый код с комментариями. А как Вы думаете? Последний раз редактировалось LV1974; 06.12.2017 в 12:17. |
06.12.2017, 12:17 | #2 |
Заблокирован
Регистрация: 09.08.2017
Сообщений: 1,136
|
+
Теперь меня интересует вот какая проблема: клиенты бояться связываться с единичными разработчиками, потому что это не надёжно. Думаю, что это организационный вопрос о создании сообществ поддержки и артелей. Что же можно сделать? |
06.12.2017, 12:51 | #3 |
Форумчанин
Регистрация: 09.11.2017
Сообщений: 121
|
Так и думаем. Продаётся не код, а решение задачи, проблемы.
Есть у кого-то задача - сжимать/разжимать данные, покупают библиотеку компрессии. Код должен что-то решать прежде всего, а простой интерфейс использования, документация к нему делают его привлекательнее для покупателя
Профессионально программирую видео-игры. Пишу бекстейдж-блог о разработке игр CoreMission.net.
Разрабатываю календарь выхода игр. |
06.12.2017, 14:14 | #4 | |
Заблокирован
Регистрация: 09.08.2017
Сообщений: 1,136
|
Цитата:
В заголовке была сформулирована задача, в которой строиться объектная модель и настраиваемое взаимодействие с пользователем. Понимание архитектуры и построение расширений для такой библиотеки, является основанием для раскрытия исходного кода. А это уже принципиально иная бизнес-модель, чем у утилит. |
|
06.12.2017, 14:28 | #5 | |||
Лис
Старожил
Регистрация: 18.09.2015
Сообщений: 2,409
|
Цитата:
Но нравится не значит, что так надо делать. Почему никому не нужны чужие фремворки и библиотеки? Цитата:
Так чтобы вашей разработкой начали пользоваться разработчика надо вывести из нормального положения. В принципе это делает его начальник, сроки, планы. В какие моменты это происходит? Я вижу два момента, при написание эскизного проекта и когда сроки поджимают и срочно надо сделать. Что-бы разработчик начал использовать библиотеку о ней надо раструбить. Написать как легко и просто её использовать и повесить к примеру на хабр. Так же вы должны предложить разнообразие. Так как фреймворк и бибилотека нужны для разных проектов и для одной задачи/цели они не нужны. Заметь те фреймворки необходимы если у вас несколько разных но однотипных проектов. В чем у вас разнообразие? А вот визарды нужны если нужен готовый код. В первом случае разработчика возьмут на зарплату, а во втором только популярность так как все будут пользоваться визардом. Выходит что визарды это второстепенно, но что-то манящее простотой в них есть. Наверно эти подходы нацелены на 2 разных таргет-группы. Цитата:
Так что думаю и с Икеей тоже самое, кто хочет берёт по нормальной цене, кто не хочет тот переплачивает за сборку. А по поводу клиента, да если он вложит свои знания он будет стремится. Но тут есть ещё и психологические моменты: http://akosarchuk.blogspot.ru/2015/04/ioc.html http://akosarchuk.blogspot.ru/2014/08/blog-post_19.html И связи с клиентами надо всё время "тренировать".
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал . Последний раз редактировалось Pavia; 06.12.2017 в 14:38. |
|||
06.12.2017, 14:57 | #6 |
Заблокирован
Регистрация: 09.08.2017
Сообщений: 1,136
|
Спасибо за отклик, Pavia!
Как всегда - рад возможности пообщаться с Вами. Первая часть Вашего сообщения относится к стратегии развития внутреннего инструментария компании. Это имеет косвенное отношение к теме. Вторая часть - вызывает недоумение. На мой взгляд очевидно, чтобы приучить прикладного программиста к некоторому средству, надо использовать примерно такую схему: 1. Демонстрация. 2. Мастер-Визард - генератор кода с опциями выбора функционала. 3. Программный интерфейс, API. 4. Мануал и FAQ. 5. Форматы файлов, буфера обмена, протоколы передачи данных, синхронизация. 6. Исходный код. Ну и конечно надо давить на мозги рекламой и постараться попасть в струю. Последний раз редактировалось LV1974; 06.12.2017 в 15:11. Причина: + |
06.12.2017, 15:47 | #7 |
Заблокирован
Регистрация: 09.08.2017
Сообщений: 1,136
|
В распространении\продаже библиотеки с исходным кодом есть некоторые плюсы - Вам не обязательно обрабатывать и выдавать исключения на каждый чих. Грамотный программист в исходном коде всегда найдёт проблему по стеку вызовов.
|
06.12.2017, 15:54 | #8 | |
Старожил
Регистрация: 28.01.2009
Сообщений: 21,000
|
Цитата:
выкидывайте грамотные исключения с сохранением стека внутреннего и все будет ок. Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел. Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите. |
|
06.12.2017, 16:55 | #9 | |
Заблокирован
Регистрация: 09.08.2017
Сообщений: 1,136
|
Цитата:
Исключения актуальны для закрытого кода. А мы говорим про самопал - про открытый код. Зачем мне в нём кидать исключения на null или на выход за пределы массива? Не понимаю. Просто чтобы было? Потому что профессор так научил, да? + Каналья в рот его профессора с его песочком! Мне C# выдаёт нормальную диагностику по границам массивов и null. Нафига мне её дублировать? Похороните Вы своего препода на фиг! + Сугубо для любителей исключений: Если фигура не поместилась в экран - то "это уже плохо, нафиг такая библиотека нужна". Тогда обрабатывайте выход фигуры за пределы экрана на клиентской базе. Давайте доведём это до идиотизма и сделаем assert! + Тут были любители обработки попаданий отдельно от рисовалки. Потом они сами удивлялись, что получаются разные результаты. Последний раз редактировалось LV1974; 06.12.2017 в 17:43. Причина: + |
|
06.12.2017, 19:53 | #10 |
МегаМодератор
СуперМодератор
Регистрация: 27.11.2012
Сообщений: 5,657
|
А если её найдёт злоумышленник? Открытое ПО и предоставление исходного кода ответственным лицам - это разные вещи.
Благими намерениями устлана дорога на programmersforum.ru
|
|
Опции темы | Поиск в этой теме |
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Как законно продавать программу? | Pamparam | Свободное общение | 22 | 27.04.2012 17:45 |
Учимся работать с Delphi, но... | Xezon | Помощь студентам | 150 | 29.02.2012 20:22 |
Учимся правильно работать | Gromsky | WordPress и другие CMS | 2 | 11.09.2009 14:27 |