Учимся продавать самопал

[LV1974]

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

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

В чём же проблема? - Это отсутствие видимости простоты. Никто не хочет плутать по лабиринтам кода. Что же делать?
Вот отличная картинка из библии ООП Гради Буча: См. Рис. внизу.

Идея заключается в том, что нельзя сразу предлагать клиенту сложность. Надо создать иллюзию простоты. – Что же можно сделать?
Видимо надо создать демонстрационный контекст.
Одним из решений этой проблемы я считаю библиотеки компании Stingray. Они создали мастера (визарды), которые генерируют код стартового приложения по опциям. Великолепная идея!

Это хороший вектор для развития бизнеса. В книге психолога Дэна Ариэли «Предсказанная иррациональность», демонстрируется бизнес-модель компании IKEA. Оказывается, что простые конструкции мебели IKEA собрать не легко. В чём же дело?
Оказалось, что существует обратный эффект.

Когда клиент прикладывает значительные усилия для внедрения продукта, то это становиться для него более ЦЕННЫМ! А значит – он получит потом больше удовольствия и будет готов платить больше за такие решения.

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

А как Вы думаете?

[LV1974]

+
Теперь меня интересует вот какая проблема: клиенты бояться связываться с единичными разработчиками, потому что это не надёжно. Думаю, что это организационный вопрос о создании сообществ поддержки и артелей. Что же можно сделать?

[coremission]

Так и думаем. Продаётся не код, а решение задачи, проблемы.

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

[LV1974]

Сообщение от coremission

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

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

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

[Pavia]

Сообщение от LV1974

Одним из решений этой проблемы я считаю библиотеки компании Stingray. Они создали мастера (визарды), которые генерируют код стартового приложения по опциям. Великолепная идея!

Мне нравится Intel Qartus - там под 100 этих визордов для генерации различных элементов схем. И можно свои написать на TCL/TK.
Но нравится не значит, что так надо делать.

Почему никому не нужны чужие фремворки и библиотеки?

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

Источник http://akosarchuk.blogspot.ru/2014/05/blog-post.html

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

Что-бы разработчик начал использовать библиотеку о ней надо раструбить. Написать как легко и просто её использовать и повесить к примеру на хабр. Так же вы должны предложить разнообразие. Так как фреймворк и бибилотека нужны для разных проектов и для одной задачи/цели они не нужны. Заметь те фреймворки необходимы если у вас несколько разных но однотипных проектов. В чем у вас разнообразие?
А вот визарды нужны если нужен готовый код. В первом случае разработчика возьмут на зарплату, а во втором только популярность так как все будут пользоваться визардом. Выходит что визарды это второстепенно, но что-то манящее простотой в них есть.

Наверно эти подходы нацелены на 2 разных таргет-группы.

Сообщение от LV1974

Когда клиент прикладывает значительные усилия для внедрения продукта, то это становиться для него более ЦЕННЫМ! А значит – он получит потом больше удовольствия и будет готов платить больше за такие решения.

Абсолютно плохой пример. Почему APPEL I взлетел? - потому что в отличии от конкурентов он продавался уже собранным. Да была наценка в 10-30% за сборку, но клиент готовы переплачивать. Так же и с Икеей и прочими сервисами. Вон Амазон к примеру поднялся только за счёт доставки. Люди готовы переплачивать за доставку до 10-30%. Амазон забирает себе прибыль от доставки, да и ещё с неё продавцам приплачивает.
Так что думаю и с Икеей тоже самое, кто хочет берёт по нормальной цене, кто не хочет тот переплачивает за сборку.

А по поводу клиента, да если он вложит свои знания он будет стремится. Но тут есть ещё и психологические моменты:
http://akosarchuk.blogspot.ru/2015/04/ioc.html
http://akosarchuk.blogspot.ru/2014/08/blog-post_19.html

И связи с клиентами надо всё время "тренировать".

[LV1974]

Спасибо за отклик, Pavia!
Как всегда - рад возможности пообщаться с Вами.

Первая часть Вашего сообщения относится к стратегии развития внутреннего инструментария компании. Это имеет косвенное отношение к теме.

Вторая часть - вызывает недоумение. На мой взгляд очевидно, чтобы приучить прикладного программиста к некоторому средству, надо использовать примерно такую схему:
1. Демонстрация.
2. Мастер-Визард - генератор кода с опциями выбора функционала.
3. Программный интерфейс, API.
4. Мануал и FAQ.
5. Форматы файлов, буфера обмена, протоколы передачи данных, синхронизация.
6. Исходный код.

Ну и конечно надо давить на мозги рекламой и постараться попасть в струю.

[LV1974]

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

[Пепел Феникса]

Сообщение от LV1974

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

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

[LV1974]

Сообщение от Пепел Феникса

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

Странный разговор.
Исключения актуальны для закрытого кода.
А мы говорим про самопал - про открытый код.
Зачем мне в нём кидать исключения на null или на выход за пределы массива?
Не понимаю. Просто чтобы было? Потому что профессор так научил, да?

+
Каналья в рот его профессора с его песочком!
Мне C# выдаёт нормальную диагностику по границам массивов и null.
Нафига мне её дублировать?
Похороните Вы своего препода на фиг!

+
Сугубо для любителей исключений:
Если фигура не поместилась в экран - то "это уже плохо, нафиг такая библиотека нужна".
Тогда обрабатывайте выход фигуры за пределы экрана на клиентской базе.
Давайте доведём это до идиотизма и сделаем assert!

+
Тут были любители обработки попаданий отдельно от рисовалки.
Потом они сами удивлялись, что получаются разные результаты.

[MihalNik]

Сообщение от LV1974

Грамотный программист в исходном коде всегда найдёт проблему по стеку вызовов.

А если её найдёт злоумышленник? Открытое ПО и предоставление исходного кода ответственным лицам - это разные вещи.