Записки о софтверном бизнесе

Кастомизация программного продукта под отдельных клиентов

February 10th, 2008 Posted in Бизнес
Многие софтверные компании сталкиваются с ситуацией – клиент просит срочно добавить какую-то фичу в программу и готов за это заплатить любые разумные деньги. Если возможность срубить деньжат по легкому вам на руку, можно назначить хорошую почасовую оплату, скажем 100 долларов в час и сделать для клиента кастомную версию.

Какие есть минусы у такого подхода?

  1. Какой бы приятной и быстрой не была эта подработка, это всего лишь разовые деньги. Потратив время на разработку фичи которая войдет в основной продукт, вы можете получать от нее выгоду многократно.
  2. Поддержка. Если у этого клиента возникает проблема, вам нужно будет искать ее именно в кастомизированной версии. Это означает дополнительные неудобства. Если таких клиентов большего одного, сложности увеличиваются пропорционально.
  3. Апгрейды. Если клиент хочет обновить программу, вам придется встраивать для него его фичу во все последующие версии. Он может быть согласен оплачивать такую кастомизацию каждый раз, но это может быть неинтересно уже вам.Представьте себе, что таких клиентов у вас десять. После выхода новой версии вам придется потратить две недели на включение для каждого из них его личной фичи.Чаще всего приходится договариваться, что такое изменение делается единоразово. Это защитит вас от повторного выполнения одной и той же работы, но не очень красиво по отношению к клиенту. Вам же хочется чтобы он был доволен на протяжении всего сотрудничества с ним.

Когда такая кастомизация работает?
Когда вам действительно нужны деньги. Если у компании сложный период, такая подработка может помочь поддержать ее на плаву. Фраза Cash is king появилась не на пустом месте.

Другой случай  – у вас есть хороший вариант использовать эту сумму для развития бизнеса. Например взять в аренду еще один сервер или купить какой-то дорогой софт. Это тоже может оправдать потенциальные неудобства.

Как это делаем мы?

  1. Мы реализуем только те дополнительные функции, которые и так собирались сделать, но не прямо сейчас. Т.е. клиент платит за привилегию передвинуть ту или иную фичу в начало очереди. Этим решается проблема саппорта и апгрейда, ибо эта фича сразу включается и в основную версию продукта.
  2. Мы делаем это только для постоянных и проверенных клиентов.
  3. Мы берем 100% предоплату. Это не вопрос доверия или недоверия к клиенту – есть достаточно много ситуаций, которые клиент контролировать не может, вплоть до банкротства компании. У меня такие ситуации были.

 
 

  1. 17 Responses to “Кастомизация программного продукта под отдельных клиентов”

  2. By webveter on Feb 11, 2008

    Пункт 1 в разделе “Как это делаем мы?” правильній на 200%.
    А вот пункт 2 не имеет смісла в свете пункта 3 при наличии пункта 1 :)

  3. By Igor Barinov on Feb 11, 2008

    Либо можете добавить фунциональность для существующего приложения через другое приложение, и если вы немного > чем SMB, то скоро найдете миллион применений такого подхода. Подсказка: http://www.openspan.com

  4. By Андрей Смехунов on Feb 11, 2008

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

    это был пример из строительного бизнеса :)
    клиент – покупатель квартиры в строящемся доме, просил поставить двойной стеклопакет вместо одинарного

  5. By Poikom on Feb 11, 2008

    С минусами не согласен. Их с такой же радостью можно поставить в плюсы…

  6. By Антонов Сергей on Feb 11, 2008

    клиенты на “кастомизацию” не обижаются? :)

    просто был случай, что человека само слово обидело, – мол, что это вы меня уже в касту записали

  7. By Сергей Корнилов on Feb 11, 2008

    2webveter:
    пункт 2 из последней части я недостаточно раскрыл. Идея в том, что такие усовершенствования приносят больше геморроя чем денег, независимо от цены. Поэтому мы большинству вынуждены отказать, а делаем только если “человек хороший″.

  8. By Сергей Корнилов on Feb 11, 2008

    2Антонов Сергей:
    у нас все клиенты англоязычные, поэтому customization вопросов не вызывает.

    Тут главное не перепутать с circumcision. Кто не помнит о чем речь, пересмотрите “Мужчины в трико”.

  9. By Сергей Корнилов on Feb 11, 2008

    2Igor Barinov:
    мысль понятна, но пока у нас бизнес немного другой. Мы продаем продукт, а не сервис. До создания своей платформы еще не доросли.

  10. By Сергей Корнилов on Feb 11, 2008

    2Андрей Смехунов:
    при всей схожести строительного и софтверного бизнесов есть и пара отличий.

    Первое – если мы сделаем дополнительную фичу одному, другие не узнают и обид не будет.

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

    К счастью нет таких клиентов, которым нельзя сказать “нет”.

  11. By Андрей Смехунов on Feb 11, 2008

    2 Сергей Корнилов: отличия только в виде продукта и типе отношений B2B или B2C. В остальном – стандартные бизнес-процессы
    неважно, узнает или нет, этика нужна, даже когда никто не видит :)
    как минимум, об этом узнают твои сотрудники
    критичная фича – а где были его глаза, когда он покупал продукт? видимо, если он хороший клиент, то пользуется им не первый день. Возвращаясь к строительному бизнесу – клиент (хороший, купил не один десяток квартир) приходит ко мне и говорит – а проруби мне еще одно окно и побольше, я решил играть на концертном рояле, а он по лестнице не входит.
    тут скорее безответственность клиента, если он поставил успех своего проекта в зависимость от того, будет ли у вас возможность добавить фичу.

    а так вообще все считается: есть возможность удовлетворить дополнительные потребности клиента без ущерба к базовым – надо согласиться, нет – отказать. Я для себя это формулирую так: надо всегда творить добро, когда это тебе ничего не стоит :)

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

  12. By Сергей Зырянов on Feb 11, 2008

    У нас кастомизация занимает до 50% от объема продаж “не своего” продукта. Наша компания это именно та фирма которая занимается продажей и кастомизацией. Наверное надо изучать спрос на кастомизацию и при удачном раскладе действительно выводить этот вид работ в отдельное направление.

  13. By Николай Курков on Feb 11, 2008

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

  14. By Наумов Михаил on Feb 12, 2008

    Могу сказать, что для таких целей рулят плагины. Это решает п.2 и 3. Правде не везде можно на плагинах выехать…

  15. By Serch on Feb 14, 2008

    вообще в Европе давно живут по принципу заказа ПО под определенные потребности

  1. 3 Trackback(s)

  2. Feb 11, 2008: Я легенда
  3. Feb 12, 2008: Блог как элемент мощной системы продаж | Работа дома и информационный бизнес
  4. Feb 21, 2008: Софт на Ближнем Востоке: Когда клиент просит фичу

Post a Comment