Товар или сервис

    На Хабре (да и в реальной IT жизни) встречаeтся много вопросов вида:


    • Надо ли обновлять систему (или зависимости в приложении), если и так всё работает?
    • Нужны ли вообще тесты (автотесты) в приложении (вы ведь на них потратите своё время и деньги заказчика)?
    • Если ли смысл в паттернах и выделении абстракций (ведь подобное размазывает код, приводит к снижению производительности и т.д.)?

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


    Термины


    В них есть принципиальная разница: товар обладает законченностью, его можно продать, а потом забыть о его существовании. В случае сервиса, покупатель и продавец общаются долго (по аналогии с подпиской, которая является этим самым сервисом).


    Примеры продуктов:


    • Строительство моста. Собственно, мост построен, сдан (это принципиально важный шаг), компания-строитель забыла о нем. В реальности еще существует гарантия на постройку, однако для сферичности эксперимента лучше пока сделать вид, что она отсутствует (или же очень короткая). При строительстве будет абсолютно нелогично менять планы в процессе (например, вернуть привезенную ограду и купить другую, более эффективную).
    • Продажа табуретки. Всё аналогично мосту, самое главное — продать эту самую табуретку. После этого продавец забудет про покупателя очень надолго (по крайней мере, в большинстве случаев).
    • Продажа квартиры (особенно на вторичном рынке). Тут опять-таки, самое важное — продать квартиру так, чтобы она не развалилась в первые месяцы. А что будет дальше — продавцу абсолютно неважно.

    Примеры сервисов:


    • Банковское обслуживание. Клиент платит за обслуживание раз в месяц, банк предоставляет сервис весь этот месяц. Клиент и банк помнят друг о друге как минимум весь месяц, а зачастую и несколько лет. Нет смысла продавать неликвид, ведь клиент откажется от обслуживания довольно быстро.
    • Сервис такси (т.е. Яндекс Такс, Gett и пр.). Несмотря на то, что поездки носят законченный характер, компании делают основные деньги на постоянных клиентах, на тех, которые возвращаются. Поэтому нет никакого смысла обманывать покупателя в первую же покупку (в стиле бомбил), так как отношения здесь длительные.
    • Супермаркет. Опять-таки, нам длительность общения продавца и покупателя намного важнее сиюминутной выгоды. А этом значит, что вместо продажи испорченного хлеба, магазину выгоднее утилизировать партию. Иначе покупатель купит хлеб в последний раз и не придет в магазин вообще. Более того, в отличии от примера с мостом, для супермаркета абсолютно нормально проводить "рефакторинг" — анализ того, насколько стеллажи стоят эффективно и т.д.

    Зачем нам знать разницу между товаром и сервисом?


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


    Однако если вы оказываете сервис для пользователей (например, делаете аналог Facebook), то у вас будут задачи обновления зависимостей, у вас будут задачи добавления/удаления функций, а потому тесты всё-таки будут, ибо они снизят риски в долгосрочной перспективе. Более того, вам потребуется выделять абстракции, как минимум для того, чтобы в будущем встраивать новую логику. Итого, если вы рассматриваете свою разработку как сервис, то вам необходимо обновлять зависимости, писать тесты, выделять абстракции и делать немало другой работы по уходу от legacy и минимизации рисков ошибки в будущем.


    Пособие: как сделать из программы legacy своими руками


    В контексте этой статьи можно очень легко вывести формулу того, как можно очень просто из практически любого разрабатываемого ПО сделать legacy, причем следуя этой формуле успеха достигает сам разработчик этой самой программы, без чьей либо помощи. Формула проста: чтобы получить legacy софт, вам необходимо относится к разработке сервисного ПО так, как будто вы делаете товар.


    Или другими словами: если вы видите, что участвуете в разработке сервиса (то есть вы надолго в этом проекте, вы будете еще несколько лет добавлять новые функции в проект, адаптировать его к новым реалиям), однако есть желание сделать из проекта истинное legacy (то есть программу, в которую невероятно сложно вносить изменения, которая неспособна работать на более новой ОС/железе и т.д.), то просто начните относиться к проекту как к товару. Просто рассматривайте каждый релиз, как последний. Чаще употребляйте слова "ну всё, продали версию". Как можно активнее делайте маленькие костыли и хаки, вместо переработки кода. И напоследок: побольше ручного труда (забудьте про TeamCity/Jenkins), и никогда не пишите документаций, спецификаций и разных комментариев в коде.


    Довольно интересно, что если буквально чуть-чуть изменить отношение к ПО, то оно само будет становится страшным legacy, причем сделанным своими руками.


    Пособие: как же не делать из своих программ legacy


    Как ни странно, однако для того, чтобы не получить ужасное ПО на руках, необходимо всего лишь задавать себе вопрос раз в месяц/квартал: а продукт, который я делаю, является товаром или сервисом? И запомнить/записать этот ответ хотя бы на некоторое время. В дальнейшем любые вопросы о тестах, рефакторинге, документации и пр. будут отпадать сами собой.


    Примеры:


    • Что нам лучше сделать с тестами, которые постоянно падают при каждом обновлении зависимостей и при каждом релизе? Причем падают они не по делу.
      • Для программы-товара: лучше просто удалить эти проблемные тесты. Всё равно от них сейчас уже больше проблем, чем пользы. А в дальнейшем они будут никому не нужны.
      • Для программы-сервиса: есть смысл починить/исправить тесты, чтобы уменьшить их false-positive срабатывание. Каждая починка тестов — это наше время, однако наличие этих самых тестов уменьшит риски пропустить ошибку в будущем.
    • Стоит ли обновиться на Spring Boot 2, или есть смысл оставаться на 1.5?
      • Для программы-товара: строго нет. Мы скоро закончим проект и никогда не вернемся к этому заказчику. У нас не будет задач ни по поддержке этой программы, ни по добавлению новых функций, ни по обновлению на новую Java с исправлениями безопасности.
      • Для программы-сервиса: строго да. Ведь эта версия будет неподдерживаемой уже через год. Более того, чтобы запускаться на бесплатной Java, нам необходимо будет обновиться на Java 11 уже очень скоро, однако ряд модулей из Spring Boot 1.* (как минимум — ASM) не поддерживает байткод от Java 9+.
    • Стоит ли нам обновить техническую документацию по продукту?
      • Для программы-товара: а нам за это заплачено? Если нет — лучше вообще удалить, так как в ней могут быть ошибки, которые потом придется исправлять "по гарантии". А если нет документации — то нет и ошибок.
      • Для программы-сервиса: конечно да. Через пару лет эта документация нам очень пригодится, когда новым разработчикам придется объяснять, как и почему у нас всё так работает.

    Товар или сервис продает IT аутсорсер


    Несмотря на то, что аутсорсер технически является IT компанией (более того, основная часть послужного состава — это люди, относящиеся к IT), самые важные шаги в проекте:


    • Подписан договор с заказчиком
    • Заказчик подписал "приемо-сдаточный акт" (или по-другому — готовый товар продан)

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


    Например, для государственных заказов зачастую разрабатываются товары. И ни разу не сервисы (хотя и такое тоже бывает). А потому, в таких проектах нет никакого резона делать документацию, ускорять работу программы (то есть делать заказчика довольными). А значит получаем правило: если вы разрабатываете, тестируете или настраиваете ПО в фирме аутсорсере, который забудет про контракт после подписания акта, то нет никакого смысла даже задумываться о тестах, документации, выделении абстракций и пр.. Более того, если вы будете советовать менеджеру среднего звена "сделать софт лучше", то он абсолютно не поймет, зачем вы в принципе задумываетесь о таком. Ведь компания мало того, что не получит никакой прибыли от рефакторингов, она зачастую может понести вполне реальные убытки то того, что разработчик тратит время не пойми на что.


    Более того, если компания-аутсорсер делает подобный софт на заказ, то у неё зачастую нет никакого стимула делать программы безопасными (ведь в будущем всегда можно просто наехать на блогера, как это делали в 90е, верно? а все убытки так или иначе понесет заказчик)


    Так почему же получается legacy?


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


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


    Примеры конфликта, когда команда разрабатывает сервис, однако относится к нему, как к товару:


    • Если участники проекта не заинтересованы в долгой работе с этим проектом. Например, человек может планировать уйти из фирмы в ближайшее время. Или в компании высокая текучка (в том числе когда люди часто переходят из команды в команду), которая приводит к тому, что участники проекта могут не ассоциировать себя с этим проектом. Т.е. если ты знаешь, что через полгода будет работать с другими людьми и над другими задачами, то какой смысл вкладывать силы в текущую программу? Зачем писать документацию, зачем делать авто-тесты и пр.? Лучше просто сделать побыстрее, получить премию за ускоренную пятилетку и пойти работать в другое место.
    • Метод кнута и пряника в команде/компании построен так, что намного выгоднее чаще отчитываться о создании новых продуктов и о замене старых. Такое может получиться, если все бонусы в компании выдаются за то, что "был сделан продукт А" или за то, что "был переделан продукт Б", а не за то, что "продукт С постоянно развивается и помогает зарабатывать деньги". В этом случае все разумные люди будут избегать долгих сроков (за это не дадут пряник). Ключевая разница — в презентации будут превуалировать законченные формы глаголов, по отношению к проектам (т.е. программа сделана, проект завершен), вместо длительных (сервис позволяет зарабатывать, команда обеспечивает инфраструктуру).
    • И не забываем про стандартный саботаж (или job security) — зачем делать документацию к продукту, который ты хорошо знаешь? Ведь иначе менеджер легко найдет тебе замену. Зачем упрощать жизнь при поддержке ПО? Ведь если поддержка ПО очень простая, то тебя можно заменить на кого-нибудь другого. Этот пункт очень пересекается с первым, который описывал компанию с большой текучкой. Однако стоит понимать, что условная "job security" мало перекликается с идеей товаров или сервисов, просто это зачастую является хорошим объяснением многих процессов, так что нельзя не упомянуть.

    Примеры обратного конфликта, когда команда на самом деле создает товар, однако относится к нему как к сервису:


    • Непонимание бизнеса. Даже очень честный аутсорсер редко признается, что его прибыль — это разница между тем, сколько платит заказчик за проект, и тем, сколько он может стоить в минимальном исполнении, при условии, что заказчик готов принять его. То есть основной заработок — это возможность сэкономить там, где в долгосрочном периоде экономить было бы неразумно. Отсюда и возникает конфликт — если менеджер среднего звена говорит заказчику о том, что "мы делаем лучший в мире софт", то разработчик может начать принимать всё это за чистую монету.
    • Всегда так делали. Если команде enterprise java разработчиков (делающих сервисы, которые потом улучшаются и дополняются в течении десятилетия) дать задание "сделать временный сервис по копированию файлов из пункта А в пункт Б", то велик шанс того, что этот простейший сервис будет переусложненным. Да, он будет копировать файлы, однако само копирование будет спрятано за 10ю слоями абстракции (а через пару месяцев — за 11ю).

    Влияние товаров и сервисов на языки и технологии


    На хабре зачастую есть немало споров по части того, какой язык программирования лучше. Или же какая технология лучше. Как ни странно, немало из них возникает из-за того, что у сторон разное понимание того, чем является программа — товаром или сервисом.


    Если у вас одноразовая задача (например, перекопировать файлы из пункта А в пункт Б с некоторыми условиями и минимальными преобразованиями), то довольно глупо будет выбирать технологии, рассчитанные на долгую поддержку, дающие длинную обратную совместимость. Для таких задач Go/Python будет идеальным решением.


    И наоборот — если в вашу задачу входит длительное оказание сервиса (с частыми обновлениями безопасности и т.д.), то на первое место выходят такие плюсы платформы, как обратная совместимость, легкость обновления, простота патчинга и т.д. Вам уже становится абсолютно неважно, легко или сложно написать Hello World на выбранном языке, так как такие программы будут создаваться раз в несколько лет.


    И как это использовать?


    В заключении — как использовать то, что программа может являться как товаром, так и сервисом.


    1. Раз в месяц просто вспоминайте, что вы делаете: товар или сервис.
    2. Не пытайтесь развивать товар. Его продают один раз и забывают. Этот подход невероятно понятен бизнесу. Работайте по системе "сделал — забыл".
    3. Не относитесь к сервисным проектам как к товару. Вы будете долго общаться с пользователями, им в этом случае важнее долговременное сотрудничество, а не сиюминутная выгода.
    Поддержать автора
    Поделиться публикацией

    Комментарии 22

      +1
      По-моему, вы путаете тёплое с мягким. Даже в вашем примере вам приходится явно оговаривать что дальнейшее общение есть, но вы решили им пренебречь
      Товар — это то, что можно пощупать. Сервис — то, что можно только описать. Это влияет на структуру продаж и оценки качества.

      Вы же описываете товары, разового и длительного пользования. Сервисы вы не описываете
        +1
        Вы же описываете товары, разового и длительного пользования.

        Это зависит от терминологии. Можно принять вашу.


        Даже в вашем примере вам приходится явно оговаривать

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


        Примерно так лет 10 назад строили дороги в РФ, что приводило к тому, что лучше всего строить дороги так, чтобы формально было бы нельзя придраться, однако на практике асфальт требовал бы частого ремонта. В терминологии этой статьи это товар, то есть продавцу главное продать товар, далее общение будет минимальным.


        Другой пример: это требование долговременной гарантии, как это пытаются делать сейчас. То есть дорога ложится на баланс компании, а оплата идет частями (в стиле "по 10% каждый год"). Получается, что строителям не выгодно быстро построить полотно, получить деньги и обанкротить компанию, так как в новом мире они получат только часть денег. Значит, дорога должна мало того, что стоить мало и соответствовать нормам, так она еще и обязана быть недорогой в дальнейшем обслуживании.


        На примере выше, возможно, разница видна лучше. И из-за разной философии (товар/сервис) получаются разные подходы к разработке.

          +2
          Да, мысли верные. Понятийный аппарат хромает на всю голову :)

          Сервис — такого слова в русском языке нет. Он переводится как Услуга.
          Товар — это материальный продукт. То что можно взять в руки или пощупать. Разработка софта не может быть Товаром. Это всегда Услуга или Сервис.

          То о чем вы говорите это Продукт или Проект. Продукт без срока — нужно думать о завтра и играть в долгую. Проект всегда конечен — можно жить сегодняшним днем, сдать его и дальше хоть трава не рости.

          У нас у людей мозги в смятку. Услуги называют словом Сервис. Продукты словом Проект. А вы тут отличились и Услугу умудрились назвать Товаром. При этом по понятиям Товар в вашем понятии и Проект в народном понятии — противоречящие вещи/идеи.

          Также это классическая делема истории про Яблоко от Владимира Тарасова. Потратиться на чистку и скушать быстро? Или начать кушать сейчас, но медленно тк там могут быть риски (грязные/червивые участки)? Даже в продуктовой разработке ответ не всегда очевиден. Иногда надо войти в тех долг и сделать криво, но быстро. А иногда надо замедлиться, но сделать сразу хорошо и с заделом на будущее. Что правильно и кто решает? Решает владелец продукта и он же отвечает за результат принятых решений.
            0
            разработка софта не может быть Товаром. Это всегда Услуга или Сервис


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

            Вполне себе товар.

            Разработчики конечно могут доделывать патчи, но это аналог гарантийного обслуживания. Могут разрабатывать продавать аддоны, но это опять же товары, я плачу за готовую игру, а не за услугу по разработке игры.
              0
              Товар — это материальный продукт. То что можно взять в руки или пощупать.
              Вот здесь ошибка. Программа или информационная система — является вполне обычным товаром, который пользователь покупает и использует, точно так же как телевизор или табуретку.

              разработка софта не может быть Товаром. Это всегда Услуга или Сервис
              Тоже не правильно. Разработка программы — это производство товара. Тот кто продает свой товар может давать дополнительную услугу (настройку, гарантийное обслуживание и поддержку), а может и не давать, зависит от производителя и требований заказчика, а в конечном счете от условий в подписанном договоре.

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

                Тогда что такое подписка? Товар или услуга? Мне кажется, что после покупки товара покупатель становится владельцем товара. Владельцем услуги стать нельзя (кроме как стать ее "производителем").

                  0
                  Тогда что такое подписка? Товар или услуга? Мне кажется, что после покупки товара покупатель становится владельцем товара.
                  Подписка — это всего лишь способ монетизации уже готового продукта-товара. Каждый производитель волен выбирать способ монетизации какой ему больше нравится…

                  Главное здесь — это продукт, если речь о программном продукте, то по факту, товаром является даже не сама программа-продукт (т.к. это цифровой предмет, который можно неограниченно клонировать и понятие «владения» к нему не применимо), а «лицензия на пользование программой», и в этой лицензии уже прописано то, за что производитель хочет получать деньги, это могут быть даже отдельные ф-ции программы, которые разрешается использовать пользователю на ограниченное время или вечно, в зависимости от способа монетизации выбранного производителем.

                  Таким образом, платная подписка на пользование программой — это продажа товара (лицензии на пользование продуктом, ограниченной по времени). Здесь у автора статьи, насколько я понимаю, подписка называется сервисом, в том смысле, что производитель заинтересован в том, чтобы один и тот же пользователь купил товар-лицензию больше чем один раз, в отличии от обычного товара (с точки зрения ПО это товар-лицензия на пользование продуктом без ограничений по времени), который можно продать только один раз.
                    0
                    цифровой предмет, который можно неограниченно клонировать и понятие «владения» к нему не применимо

                    Это по чему же не применимо?


                    Подписка — это всего лишь способ монетизации уже готового продукта-товара

                    Я всё же считаю, что подписка — услуга. И я ею не владею, а соответственно не могу перепродать, например.


                    Кроме того, товар имеет ценность даже после исчезновения его производителя. Услуга же пропадает вместе с ним.


                    Товар может быть продан здесь и сейчас. Услуга далеко не всегда. Товар может приобретать дополнительные характеристики каждого из владельцев, например старинные вещи или вещи знаменитостей.


                    В контексте статьи — с последним абзацем полностью согласен, хотя иногда товар и услуга идут в комплексе.

                      0
                      цифровой предмет, который можно неограниченно клонировать и понятие «владения» к нему не применимо
                      Это по чему же не применимо?
                      С моей точки зрения, это очевидно — потому что цифровой предмет не материален. Согласитесь, странно утверждать, что кто-то владеет «буквой А» или «цифрой 1», точно так же странно утверждать, что.кто-то является владельцем-собственником последовательности букв или цифр, т.к. эта последовательность не материальна, она может храниться на разных материальных носителях — но сама по себе — это всего лишь нематериальная абстракция. Здесь под «владением» я имею в виду «нахождение в чьей-либо собственности», закон может защищать авторское право или наказывать за нарушение лицензии использования/распространения последовательности бит, но вот сделать кого-либо владельцем не материального объекта, он не может. Можно создавать/разрушать последовательности букв/цифр/бит на своем материальном носителе, но владельцем этих букв/цифр/бит стать нельзя… можно лишь претендовать на авторство… да и то, лишь в пределах человеческой цивилизации :)
                        0
                        Один вопрос: какое отношение имеет этот спор за материальность цифрового товара к теме статьи?

                        И одно возражение: вы считаете, что владеть можно только материальным, но как вы тогда трактуете, например, владение акциями, не старыми бумажными, а современными, абсолютно цифровыми?
                          0
                          Один вопрос: какое отношение имеет этот спор за материальность цифрового товара к теме статьи?
                          Ну… это не спор, это обсуждение в котором каждый делится своим мнением, что-то кому-то доказывать здесь цели нет. Человек спросил почему я так думаю и я ему пояснил. Если Вам тоже интересно мое мнение отвечу и на ваше возражение:
                          владеть можно только материальным, но как вы тогда трактуете, например, владение акциями, не старыми бумажными, а современными, абсолютно цифровыми?
                          Под цифровым предметом, я имею в виду любую последовательность бит, которая является нематериальной абстракцией и может быть представлена на материальных носителях в любом виде. К абстракции не применимо понятие «владения», так как она существует не зависимо ни от кого и соответственно не может ни кому принадлежать. Любые акции — это по сути документы, подтверждающие права и обязанности (обязательства) акционеров и фирмы, в каком виде хранятся эти документы цифровом или бумажном не важно, главное тут то, принимает ли закон эти документы в качестве доказательства наличия обязательств между сторонами или нет. Вы можете стать владельцем бумаги, на которой стоят подписи (это материальный предмет), но вы не можете стать владельцем последовательности бит, которыми описываются эти документы с цифровой подписью на сервере. Никто не может быть владельцем последовательности бит. О владении цифровыми предметами говорить смысла нет, можно лишь говорит о правообладателях с точки зрения закона.
                            0
                            Никто не может быть владельцем последовательности бит
                            Таки каким образом обустроено владение акциями, если их никто на бумаге не выпускал? Но, по сути, вы уже ответили, и даже подтвердили возможность владеть чем-то цифровым:
                            главное тут то, принимает ли закон эти документы в качестве доказательства наличия обязательств между сторонами или нет
                            .
                            С программным продуктом всё то же самое. Законами описаны механизмы передачи прав пользования или владения, равно как и права и обязанности. И естественно, всё это качается не конкретной последовательности бит, где-то абстрактно существующей. Но если у меня на компьютере есть образ программы, которую я официально купил, то я имею полное право говорить, что владею этой копией. Даже если я эту последовательность бит многократно скопирую.
                            Точно так же можно быть владельцем репродукции картины, не будучи владельцем визуального образа, на ней запечатлённого. Или быть владельцем копии изображения из фотобанка.
                            При всём при этом, конечно, нельзя быть владельцем буквы или цифры — это вообще абстракции, не зависимо от носителя. Но можно быть владельцем специфичной 3-d модели, воплощающей букву, не зависимо от носителя, т.е. и в цифре в после распечатки на принтере.
                              0
                              У нас с Вами просто разное понимание понятия «владение».

                              То, что вы называете «владение», я называю «правообладание по закону или имущественное право», а под «владением», я имею ввиду возможность распоряжения чем либо — разрушение, изменение, перемещение и т.п… С абстрактной последовательностью бит ничего этого принципиально сделать нельзя, поэтому и владеть ей нельзя, но можно зарегистрировать патент и стать правообладателем на эту последовательность бит по закону какой-либо страны, при этом в другой стране у вас такого права может и не быть.

                              Показательная аналогия:
                              Над территорией примитивных туземцев высоко в небе зависает космический корабль (КК) и космонавты наблюдают за туземцами в течении года. В одном племени руководители боятся КК и в своих законах запрещают всем смотреть на него, в другом за право смотреть на КК и рисовать его начинают брать плату, в третьем на основании того, что они первыми увидели КК объявляют его своей собственностью и применяют санкции к тем, кто не признает их права… т.е. в своих законах туземцы могут делать всё что угодно (в том числе и считать себя владельцами), но по факту владельцами КК из них никто не является.

                              Поэтому, с этой точки зрения, Ваше утверждение
                              Но можно быть владельцем специфичной 3-d модели
                              , верно если под «владельцем» Вы имеете ввиду «правообладателя по закону кокой-либо страны», и не верно, если имеется в виду «человек имеющий возможность распоряжения абстракцией, которой является 3d-модель».
            0
            Когда вы пришли в кино, посмотрели фильм, ушли и забыли про него через пару дней.
            Это все еще услуга?
              0
              Конечно услуга. Оказанная в момент показа фильма. Что я с ней потом сделал (забыл) на терминологию не влияет
                0
                А пицца в пиццерии — товар?
            +2

            А вообще всё можно выразить кратко:


            • Товар должен работать на презентации.
            • Сервис должен работать заметно дольше, чем на презентации, и в случае незначительных изменений среды быть легко адаптируем.

            И пара моих личных правил по этому поводу:


            • Библиотека всегда должна быть сервисом.
            • Приложение желательно должно быть сервисом.
              0
              > Товар должен работать на презентации.

              Товар должен работать весь гарантийный срок. Иначе это не товар, а услуга по презентации товара.

              > Сервис должен работать заметно дольше, чем на презентации, и в случае незначительных изменений среды быть легко адаптируем.

              Сервис (услуга) — это процесс. Может быть процессом создания товара или процессом его изменения/ремонта/т.п. Процесс всегда конечен.

              Отличия услуги от товара не в сроке действия, а в том, что товар вы можете пощупать, а услугу только описать.

              Вы, конечно, можете и дальше пытаться переименовывать товары в сервисы или кошек в яблоки, но, боюсь, понимать вас будут не все
              +2
              Для большей ясности можно обратиться к чисто бизнесовым понятиям: есть короткие и длинные деньги. У них разные финансовые показатели и механики. Если утрировать, то всё оказывается просто: «товар» (short terms) — это дёшево сделали и дорого продали, «сервис» (long terms) — это когда первые платежи не покрывают инвестиций, и требуется просчёт положительных и отрицательных бонусов от принимаемых решений. Риски тоже разные. В первом случае главный технический риск — хватит ли начальных инвестиций для того, чтобы продать с прибылью? Во втором — хватит ли будущей оплаты услуг на покрытие начальных инвестиций, учитывая будущие расходы.

              Если подходить к разработке с оглядкой на финансовую модель — много и ясно становится, и договориться с заказчиком проще. Но есть пара областей, где это плохо получается. Первая — внутренний заказчик. Обычно хочет чтобы быстро и дёшево, но сильно негодует, что потом оказывается долго и дорого. Проблема существенна, если не удаётся донести соответствие технический решений и финансовых результатов. Вторая область — это нефинансовые отношения. Друзья, опенсорс и т.д. Тут вместо отсутствующих денег начинают играть психологические мотивы. Кому-то хочется попробовать что-то новое, кому-то сделать монументально-крутое, кому-то отделаться от задачи, отказаться от которой нет желания…

              Надо ещё понимать, что в любой из ситуаций могут присутствовать косвенные бонусы для все участников, как-то нематериальные мотиваторы (гордость, чувство глубокого внутреннего удовлетворения...), так и потенциальные будущие прибыли (если не стыдно проект в портфолио положить). Но эти инструменты уже очень индивидуальны и склоны меняться прямо в процессе, по не зависящим, так сказать.
                0
                Товар как и софт обладает каким либо функцоналом, который интересен клиенту. Сам по себе товар мало интересен, за исключением антиквариата. Если какие либо функции товара не работают или в каких либо режимах работают неправильно это неинтересно клиенту, соответственно продажи падают. Производитель товара старается подогнать товар под запросы клиента, соответственно учесть как можно больше его хотелок. Многие производители товаров используют системы по учету пожеланий, требований, опыта эксплуатаци, результатов испытания, сравнения с конкурентами и пр. при разработке продукции, аналогично баг репортам при разработке софта.
                  0
                  Я так понимаю, те же дорожные службы уже очень давно внедрили данную концепцию, что дороги — это товар, и его главное втюхать, а потом на сервисе ремонта стричь бабло.

                  Статья для рубрики вредные советы?
                    0
                    Статья для рубрики вредные советы?

                    Да, самая последняя часть именно "вредные советы". Остальные — про то, что практически всегда лучше чуть потратить время и решить — продукт мы делаем, или сервис. А далее — если мы делаем таки сервис, то вполне разумно вкладываться в архитектуру, рефакторинги и т.д.


                    дорожные службы уже очень давно внедрили данную концепцию

                    Да, потому я сейчас вижу активную борьбу с этим. Деталей, к сожалению, не знаю.

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

                  Самое читаемое