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


На Хабре (да и в реальной 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. Не относитесь к сервисным проектам как к товару. Вы будете долго общаться с пользователями, им в этом случае важнее долговременное сотрудничество, а не сиюминутная выгода.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (15):

  1. salkat
    /#19009635

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

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

    • imanushin
      /#19009647

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

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


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

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


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


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


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

      • maxxannik
        /#19011039

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

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

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

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

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

        • Newbilius
          /#19011527

          разработка софта не может быть Товаром. Это всегда Услуга или Сервис


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

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

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

        • FreeMind2000
          /#19011895

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

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

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

          • FRiMN
            /#19011955

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

    • ggo
      /#19010507

      Когда вы пришли в кино, посмотрели фильм, ушли и забыли про него через пару дней.
      Это все еще услуга?

      • salkat
        /#19018921

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

        • ggo
          /#19019391

          А пицца в пиццерии — товар?

  2. vyo
    /#19009887 / +1

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


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

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


    • Библиотека всегда должна быть сервисом.
    • Приложение желательно должно быть сервисом.

    • salkat
      /#19018925

      > Товар должен работать на презентации.

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

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

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

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

      Вы, конечно, можете и дальше пытаться переименовывать товары в сервисы или кошек в яблоки, но, боюсь, понимать вас будут не все

  3. Mikluho
    /#19010291

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

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

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

  4. Igggi
    /#19010595

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

  5. ZurgInq
    /#19010823

    Я так понимаю, те же дорожные службы уже очень давно внедрили данную концепцию, что дороги — это товар, и его главное втюхать, а потом на сервисе ремонта стричь бабло.

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

    • imanushin
      /#19011155

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

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


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

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