Неопределенность качества информационных систем

forsalecarПредположим у вас есть команда лучших программистов в мире и они разрабатывают гениальный программный продукт. Лучший в своем классе. Способный после короткого 1,5-2 недельного обучения пользователей катастрофически повысить производительность их труда. К сожалению, вы вряд ли сможете выгодно продать такой программный продукт. Не сможете потому, что есть сотни или тысячи других людей, продающих информационные технологии. А заказчик (пользователь) он просто не очень понимает, какая программа, действительно, хорошая, а какая нет. Для него программное обеспечение как часы. Он видит только циферблат и стрелки, но не знает, как устроен механизм внутри часов.  Продавать хорошее программное обеспечение это как продавать хороший, но не очень новый автомобиль. Он не попадал в аварию и регулярно проходил ТО. Вы-то знаете, что за пять лет эксплуатации с машиной не было никаких проблем. Но покупатель этого не знает. Он видит перед собой еще сотню внешне таких же машин – кузов вроде не битый, салон в хорошем состоянии, моторный отсек чистый и 99% из них имеют скрытые проблемы (потому их и продают).  Вы никогда не получите за такую машину справедливую цену, так зачем же её продавать? 

Хорошие подержанные автомобили вымываются с рынка. На это обратил внимание Нобелевский лауреат по экономике Джордж Акерлоф в своей работе «Рынок «лимонов»: неопределенность качества и рыночный механизм» (выжатыми лимонами в США называют подержанные автомобили, которые выработали свой ресурс). Если не предпринять специальных мер, то такой рынок схлопывается  и со временем перестает существовать. Одни люди хотели бы продать автомобили, находящиеся в хорошем состоянии, а другие хотели бы их купить. Но ни первые, ни вторые не могут этого сделать. Рынок заполнен «выжатыми лимонами». Никто не хочет писать качественную литературу. Чтобы продать новую книгу, нужен известный автор, звучный заголовок,  красивая обложка, пара рецензий и реклама в метро. Никто не снимает хорошее кино. Достаточно пригласить несколько звезд и снять минутный рекламный ролик о фильме. Никто не будет делать качественное программное обеспечение. По крайней мере, до тех пор, пока мы не научимся отличать хорошее от плохого.

Есть еще один аспект хорошего программного обеспечения. Эрик Реймонд в знаменитой работе «Собор и базар» отметил, что «Каждая хорошая работа над программным обеспечением начинается с реализации персональных целей разработчика». Проще говоря, хорошее программное обеспечение не пишется за деньги на заказ, на основании требований пользователя. Реализуя ваши требования, программисты зарабатывают себе на жизнь, а хорошие программы пишут вечером после работы для собственных нужд. Даже если кто-то захочет нарушить такой порядок вещей, то в ситуацию вмешается проектный менеджер, у которого есть дедлайны и, как правило, отсутствует понимание внутреннего устройства информационных систем.

Что же делать в сложившейся ситуации? Честно говоря, я бы оставил этот вопрос открытым. 20-21 декабря мы пообсуждаем его на очередном тренинге по архитектуре информационных систем. Если же у кого-то есть свой рецепт, то я буду рад вашим комментариям к этому сообщению.

Неопределенность качества информационных систем: 13 комментариев

  1. “Хорошая программа будет продаваться и с плохим маркетингом. Хороший маркетинг продаст и плохую программу. Идеальный маркетинг продаст программу, которая вообще не работает. Идеальная программа продаст себя сама” 🙂

  2. На самом деле, дело не только в недостатке маркетинга…

    Любые идеальные продукты (не только ИТ) – вредны, т.к. они чаще всего оторваны от жизни, плохо учитывают потребности, слишком дорого стоят и т.п. В каждой практичной и живучей системе будут ошибки, недостатки и т.п. – как у любого продукта эволюции. Это следствие того, что реально практичная система должна постоянно меняться, чтобы удовлетворять потребностям – а вот эти самые изменения не могут происходить “без проб и ошибок”. Более того, наличие в системе ошибок и создаёт условия для её эволюции:).

    1. Slava :
      Более того, наличие в системе ошибок и создаёт условия для её эволюции:).

      Кажется, теперь я знаю, какой должен быть софт с большим потенциалом к развитию. Это должен быть кривой софт! 🙂
      Условия для эволюции системы создаёт прежде всего ее активное использование, имхо.

      1. Согласен с вами. Именно под “практичным” я и подразумеваю то, что система или софт активно используется. Избегая крайностей, софт должен иметь такое колво ошибок, которое позволяет с его помощью решать критические для пользователя задачи и конкурировать с аналогами. А учитывая то, что сам эффективный пользователь постоянно находится в непрерывном процессе оптимизации своей работы, он же постоянно хочет нечто большее, нечто другое что хотел вчера – пользователь и сам софт обязаны постоянно эволюционировать, пробовать, ошибаться…

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

    2. Да, в принципе, я согласен. Только данный взгляд на качество программного обеспечения будет понят, если мы предварительно договоримся считать ПО не продуктом, а услугой. А это глобальное изменение в мировоззрении заказчика.

      Аналогия с автомобилями и здесь работает. “Выжатый” автомобиль, он же не сейчас не работает. Он потом, возможно, сломается. И покупатель заинтересован в том чтоб его починили быстро и дешево, а не в деталях и причинах поломки. В Америке приняты законы, называемые Lemon laws, защищающие покупателей “лимонов” гарантиями за счет продавца.

      1. В целом, покупая продукт, заказчик изначально рассчитывает решать, с его помощью свои задачи, но также рассчитывает на поддержку продукта со стороны поставщика, обновления и т.п. – т.е. услуги. Собственно, всякие апп-сторы и т.п., как мне кажется, уже достаточно сильно размазали границу продукта и услуги (поддержки жизненного цикла продукта, доп-услуги для продукта и т.п.) – без последних, опытный заказчик хорошо подумает, стоит ли покупать софт. Не секрет, что сейчас достаточно важным критерием выбора софта является частота и объем его обновлений – чем они чаще, тем софт кажется более привлекательным. Таким образом, мне кажется, что бизнес-модель поставщика/разработчика, который хочет сейчас конкурировать на рынке, просто обязана больше ориентироваться на услуги, а не коробочные продукты и т.п. Не хочется здесь обсуждать технические вопросы связанные с безопасностью, тонкими клиентами, оффлайн-приложений в браузере и т.п. в условиях банков и т.п. – очевидно, сейчас они решаемые. В конце концов, учитывая реалии банков и т.п., разработчики интернет-сервисов типа crm и склада уже предоставляют возможность локальной инсталляции сервера их софта в окружении организации, который сымитирует локально вэбсервис, который доступен в интернет.
        Вообще, мне кажется, что именно модель услуг, lean development, agile, DDD и т.п. – все это инструменты улучшения и ускорения обратной связи в процессах заказчика и поставщика, без которой не получить устойчивой системы. А те заказчики и cio, которые все еще не понимают смысла их вовлечения в указанную деятельность на стороне поставщика, создают для своих компаний потери в стратегической перспективе.

        Что с этим делать поставщику? Отказываться от таких клиентов, т.к. потери заказчика – это их потери.

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

          В принципе, у некоторых продуктов это уже есть.
          Здесь главное, чтоб кто-то из поставщиков начал раскачивать эту лодку

      2. Насчет “лимонов” (или более обще – т.н. информационной ассиметрии), вероятно, это достаточно распространенная проблема в нашей жизни, если ее переформулировать, как “выбор среди худших”, когда лучшие скрываются или недоступны. Видимо, это можно решать только с привлечением 3х сторон, которые должны сыграть роль аудиторов качества, которым будет доступен весь объем софта, из которого можно выбирать и т.п. Другой вариант, возможно это сертификация на соответствие качеству опять же через 3х лиц, которым не нужны откаты и т.п.:). Но мне кажется, что это дорогой и плохо работащий подход (особенно для России), заказчику лучше ориентироваться поставщика, который готов поддерживать обратную связь и работать с ним в одной связке, забывая про коробки.

  3. То же самое относительно неопределенности качества ИТ-директоров. Имел счастье со многими ранее встречаться. 80% не имеют базового высшего образования в области ИТ, грубо говоря, программировать не умеют. Но практически все обладают самым важным для выживаемости достоинством – харизмой и умением рассуждать абстрактно на темы ИТ. Это главное, что нужно, чтобы производить впечатление на собственников и акционеров (которые, к их счастью, в ИТ не разбираются) и “вписаться в команду”. Ну еще нужно не рисковать и выбирать решения от IBM, SAP и EMC, за которые трудно критиковать, и успеть вовремя до краха проекта сменить работу – по статистике, средний срок работы ИТ-директора 2 года, а срок проектов от этих вендоров – более 3-х лет. Неплохо также периодически пиариться и стать членом клуба ИТ-директоров (некоторые умудрились стать и почетным членом! Обнаружил, кстати, в списке своих бывших сотрудников – помню, что о программировании имели весьма смутное представление).

    А потом к разработчикам того самого софта, которым можно быстро и надежно заткнуть все проблемы, но качество которого такие топ-менеджеры почему-то никак не могут определить, несмотря на наличие бесплатных версий, бесплатных пилотных проектов и бесплатной техподдержки, снова приходят предложения поучаствовать в конкурсе там, где 4 года назад за 4 миллиона $ победил D. (угадайте сами, кто, пиара было немерено), но теперь новому составу ИТ-службы этого большого региона нужна реальная работающая система, способная без проблем обслуживать 2 000 пользователей с одного сервера. Но известно, что история не учит, зато повторяется

  4. >>Если же у кого-то есть свой рецепт, то я буду рад вашим комментариям к этому сообщению

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

    Берете какую-нибудь свою модельную задачу, которую должна решать выбираемая система (какой-нибудь свой стандартный бизнес-процесс или, например, кейс, если вам реально дорога эта тема 🙂 ) и просите поставщиков предложить решение в рамках своей системы. Те системы, где отделаются словами, слайдами и обещаниями, не подходят. А та система, где через несколько дней предъявят работающее решение, и является той самой, подходящей. И вся “неопределенность качества” тут же превращается в определенность. Понятно, что за несколько дней сложный БП будет предъявлен лишь как макет, но это же итерационный процесс – сделайте 2-3 этапа, пусть конкурирующие решения проявят себя. Большинство отвалятся уже на 1-м этапе.

    И с “лимонами”, т.е. подержанными авто то же самое. Для нормального специалиста, например, дилера таких авто, “неопределенности качества” нет, он сразу определит, что за “лимон” перед ним, а после прогона на стенде основных узлов, которые больше изнашиваются, будет знать состояние точно. Индивидуальному покупателю да, труднее. Но, если покупатель – крупная корпорация, которая содержит своих специалистов (ИТ-службу в данном контексте), то такой покупатель знает как решать проблему “неопределенности качества”.

    1. В принципе, согласен. Некоторые поставщики имеют свои модельные примеры. Остальным же приходится делать их для каждого потенциального заказчика 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *