Техподдержка

[Alexey Veselovsky]

Когда клиент заплатил деньги за продукт, он оказывается уже "завязан" на данном производителе.

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

Миграция на что-то иное осложняется двумя факторами: 1) конвертация данных в новый формат + конвертация конфигов в новый формат - вообще говоря очень не тривиальная задача. 2) Имеется уже опыт как работы с этим ПО, так и взаимодействия со данной службой тех. поддержки. Как поведет себя новая тех. поддержка - неизвестно, получится ли мигрировать безболезненно (пункт 1) - неизвестно. Т.о. риски весьма велики. Также нужно переучивать персонал. => гарантированные простои в работе.

И вообще - в поддержке (в т.ч. и тех.) нуждаться может только то что постоянно падает. То что не падает, то и поддерживать и подпирать не надо.

[Alexey Veselovsky]

Я против ненужных новых фич. Зачем в программе записи дисков медиапроигыватель, мне никогда не понять. Одна задача - одна программа/утилита, пусть маленькая, но эффективная. Это называется unix-way.

Объясняю суть ущербности оного "юникс-вея": Разделение функционала по разным узкоспециализированным программам это безусловно благо. Но есть одна проблема. Когда у нас функций (а соответственно и этих программ) становится МНОГО, то мы получаем хорошо организованный хаос, в котором что-либо найти почти невозможно. Этот пропагандируемый unix-way можно сравнить с чистым структурным программированием ярким представителем которого является классический Паскаль (не путать с Борланд Паскалем!) в котором небыло ни понятия юнита, ни модуля ни класса. Зато были процедуры и функции. Небольшие программы (с небольшим колличеством (в пределах скажем паря десятков) пишутся на нем элементарно. Но что-то большее уже написать сложно. Сложность примерно пропорциональна квадрату колличества сущностей с которыми приходится оперировать (на самом деле еще хуже - факториал там, ну да ладно).

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

К сожалению в стандартном шеле юниксов группировки функционала практически не наблюдается. Все разбито на большое колличество мелких утилит которые находятся в глобальной области видимости. Жмем Таб+Таб - получаем что-то типа "Вы действительно хотите просмотреть 1500 возможных команд?". Конечно! Вот всю жизнь мечтал!

Возвращаясь к неро, гуям и винде - Неро и им подобные программы не делают ничего нового, они всего лишь ГРУППИРУЮТ функционал, ну, попутно еще завертывают его в красивую оболочку. Это аналог ООП и компонентного программирования. Модула, Оберон, С++, Ява... Эта парадигма давно используется в программированияя (в т.ч. и для хрюниксов), но почему-то упорно не признается с т.з. пользовательского интерфейса в них (с т.з. шела). Видимо сказывается инертность мышления и приверженность к сомнительным традициям.

[Alexey Veselovsky]

Если пожарных и врачей не драли бы за статистику (а их за неё дерут) - то ИМЕННО В ЭТОМ они и были бы заинтересованы. Подумай об этом

Кстати, о этой модели я давно задумывался... И пришел в общем то ровно к тому же выводу.

Выход из ситуации (один из...) - продавать не сервис, не программу, а ГАРАНТИЮ правильной работы программы (а то сейчас в случае если программа взорвет ваш компутер мы ни за что не отвечаеи), гарантию что не пропадут данные, что не будет сбоев и т.д. и т.п. Чем программа надежней, тем на бОльшую сумму можно давать гарантии (при фиксированных взносах потребителя). При этом конечно патчи, фиксы и сервис не отменяются, но они становятся уже второстепенными и служат предотвращению неприятностей, а не исправлению последствий оных (хотя и это тоже, если уж все рухнуло, то надо позаботиться чтобы оно не придавило чего лишнего).

Соответственно всплывают такие интересные вопросы, как верификация программ и доказательство (строгое) правильности их работы. Чего сейчас почти никогда не делается. Кстати, при таком подходе языки Си-семейства указываются в далеком пролете, причем, вилимо, вместе и с ОС построенными на них. :-)

[Necroman]

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

Выход из ситуации (один из...) - продавать не сервис, не программу, а ГАРАНТИЮ правильной работы программых

Продавать гарантию можно, но сложно: если машина все-таки сломалась (программа все-таки упала), является ли это основанием для расторжения договора и возврата денег по гарантии?

Можно попробовать продавать что-то вроде беспроблемной эксплуатаци. Для автомобилей это время (или пробег) от ремонта до ремонта, для компьютерных программ это uptime (или количество выполненных полезных фукнций - в зависимости от характера программы). Проблема в том, что такая схема не стимулирует появление новых фич.

[Alexey Veselovsky]

Цитата(Necroman @ 2.03.2007 - 18:10) Можно попробовать продавать что-то вроде беспроблемной эксплуатаци. Для автомобилей это время (или пробег) от ремонта до ремонта, для компьютерных программ это uptime (или количество выполненных полезных фукнций - в зависимости от характера программы). Проблема в том, что такая схема не стимулирует появление новых фич.

Точнее - не гарантию, а страховку. Аналогии полностью с обычными страховками. В случае падения программы, порчи данных и т.д. контракт не разрывается, а просто страховая софтверная компания выплачивает страховую сумму. Естественно оным компаниям удобно будет держать под рукой разработчика ПО. Или же самим быть оным разработчиком.

А с новыми фичами проблем не будет, ибо это САМЫЙ ЛЕГКИЙ способ привлечения новых юзверей. Для примера: Есть язык С++ а есть Оберон. В первом фич больше (всяких бубенчиков с колокольчиками), во втором - существенно выше надежность. Стоят и тот и другой - ноль (бесплатных компиляторов море и там и там). Как показывает практика, колокольчики таки побеждают. Поэтому заботиться о дальнейшем росте колличества оных колокольчиков не стоит - они и так будут расти. Стоит озаботиться надежностью и прозрачностью ПО.

[Necroman]

А с новыми фичами проблем не будет

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

Если за новую фичу пользователь платит деньги сразу, то это компенсирует затраты производителя на customer support. А вот если фича приводит только к страховым выплатам, то она она разоряет разработчика сейчас, а все выгоды от её существования остаются в туманном будущем. Это очень рискованно. В особенности пострадает "открытый софт", который предпочитает release early, release often ("Cathedral and Bazaar").

Надежность и прозрачность ПО важны, но их не следует абсолютизировать или как-то особо акцентировать. Это просто фичи, ничем не важнее функциональности (если мы не говорим о ПО атомных станций). "Страховая" модель увеличит надежность, но если и не убъет инновации, то сильно их замедлит. Мир высоких технологий станет надежным и серым, как невский гранит.