О преимуществах готовых продуктов

Перед нами возникает проблема: купить готовое изделие, так называемый продукт, или заказать изготовление такого продукта по своему вкусу?
Как мы подходим к ее решению?
Чаще всего, мы сначала поищем готовый продукт.
Если подходящего не найдем, то принимаем решение заказать изготовление того продукта, который нам необходим.
Здесь перед нами встают две проблемы:
- знаем ли мы и хорошо понимаем, что мы хотим, и
- у кого можно заказать его изготовление, чтобы не получить "новое платье короля"?
           Эта статья была написана в 1993 году и опубликована в журнале "Мир ПК"
           в 1994 году, но к сожалению, актуальна и по сей день!
Конечно, наша цель заказать эту работу у того, кто сделает именно то, что нам нужно.
А вот здесь-то и возникает одна из главных проблем: как угадать того, кто это сделает?
Предложений выполнить эту работу не счесть.
Здесь вам и легион франчайзи популярной компании.
И рота возродившихся или перелицованных компаний прошлых лет.
И взвод старт-апов готовых решить любую проблему с использованием самых современных и передовых средств разработки.

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

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

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

Руководитель считает, что ему негоже носить покупное платье. Позвонив в ателье разряда “Люкс”, он узнает, что там бешеные цены. «Нет, - решает руководитель, - я найму себе портного, и он сошьет то, что мне надо». Дает объявление, что примет на работу людей, умеющих шить, и такие сразу находятся.
Перед ними ставится задача сшить костюм... хороший, очень хороший, самый лучший.
“Храбрые портняжки” начинают описывать, каким будет костюм. Описывают словами приблизительно, в зависимости от того, кто из них что слышал о моде в этом сезоне.
Нетрудно представить, что за костюм они сошьют.
Не исключено, что это будет “новое платье короля”.
Более того, нередко именно так и бывает.
Тем не менее предположим, что костюм удался на славу.
Так могло получиться только в том случае, если в процессе работы сложился дружный творческий коллектив.
Такой коллектив складывается, когда собираются люди приблизительно равной и довольно высокой квалификации.
При этом сплачивает их не стремление заработать как можно больше денег, а цель решения интересной задачи, в результате которой должен получиться высококачественный продукт.
Когда работа у данного заказчика закончилась, маловероятно, чтобы такой коллектив сказал «всем спасибо» и разошелся в разные стороны.
Что ожидает этот коллектив, если он останется на предприятии, даже если заработной платой его члены будут вполне довольны?
Трудно предположить, что они станут довольствоваться тем, что будут вносить эпизодические улучшения в созданное изделие…
Скорее всего, они попрощаются с заказчиком и будут создавать аналогичные изделия для других предприятий, назначая столь же высокие цены, как и в хорошем ателье.
А с чем же останется наш заказчик?
Никаких гарантийных обязательств по этой работе у него не осталось, так как работа производилась его персоналом.
Со всеми пожеланиями о доработках ему придется обращаться теперь к самостоятельному коллективу и, как говорится, «за отдельную плату».
Следует вывод, что пойдя по пути самостоятельной разработки, при очень малой вероятности хорошего результата, он получает то, от чего хотел уйти.

Тем не менее, любой сложный программный продукт требует поддержки. И этим безусловно должен заниматься персонал предприятия, для которого он был создан.
Практика создания таких продуктов показала оптимальный способ взаимодействия исполнителя с заказчиком.
В настоящее время считается общепринятым подход к разработке сложных систем, включающий использование программной платформы, той или иной глубины функциональности, и разработки дополнительных модулей и функциональных средств на базе этой платформы.
Программная платформа, на которой реализован наиболее востребованный функционал, как правило обладает необходимой надежностью и отлаженностью.
Она практически свободна от ошибок и готова к использованию с момента инсталляции. Собственно с ее внедрения и начинается работа над проектом.
Как правило права на ее использование приобретаются в виде срочных или бессрочных лицензий.
На базе использования платформы, что уже дает заказчику ожидаемый результат и уверенность в успешном развитии проекта, проходит разработка дополнительного функционала.
Разумный заказчик уже в период работы над проектом нанимает своих сотрудников, которые включаются в команду проекта, чтобы в дальнейшем поддерживать работу программной системы и, в случае необходимости, развивать ее в дальнейшем самостоятельно.
Но это бывает, когда заказчик разумный!
К сожалению, это не всегда так...
   
Рыночный продукт проверяется всеми, кто его приобрел, и ошибки, без которых программ не бывает, выявляются тем быстрее, чем больше покупателей у этого продукта.
Если фирма-производитель желает оставаться на рынке, то по мере выявления ошибок она их исправляет и программа становится все более надежной.
Появляется и накапливается опыт в использовании, который переносится производителем на его продукт, в результате чего этот продукт постоянно улучшается.
Также постоянно улучшаются инструкции по его применению, что облегчает работу с ним пользователя.
Всего этого лишены программы, разработанные по заказу.
Редкий разработчик согласится бесплатно в течение длительного времени вносить улучшения в сделанную и оплаченную работу.
Почему разработчик рыночного продукта это делает?
Потому что надеется на дальнейшие продажи и расширение объема продаж.

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

Обозначим основные преимущества внешнего разработчика готовых продуктов, которые свойственны ему по определению.

Профессионализм.
Внешний разработчик интегрирует не только опыт многих разработок, но и многих «живых» систем, то есть реальных предприятий, которые ему пришлось автоматизировать.
Реализм.
Внешний разработчик вынужден отчетливо представлять степень реализуемости задания, тем самым предохраняя заказчика от неоправданных затрат финансов и/или времени на нереализуемые проекты.
На мой взгляд, это самое важное преимущество.
Грубовато, но ярко обозначил эту ситуацию Себастиан Брандт в «Корабле дураков»:
      «Наобещает Вам дурак,
      То, что свершить нельзя никак:
      «Любую хворь я излечу,
      Я, мол, и горы сворочу!»
      Весь мир того не совершит,
      Что посулить дурак спешит.»
Ответственность.
Внешний разработчик (в отличие от собственного или случайного) несет перед заказчиком юридическую и финансовую ответственность за разработку в полном объеме.
Экономическая целесообразность.
Разработку системы может выполнить только подготовленный коллектив, имеющий концептуальные, инструментальные и технологические заделы.
На оснащение, обкатку и наработку всего этого уходит немало времени и средств, поэтому при относительно небольших планируемых сроках (до двух лет) на эту работу и несмотря на ее разовый характер на данном предприятии, разработка внешним опытным исполнителем будет стоить дешевле, чем собственным или случайным.
При иных условиях может быть не так, но это требует детального анализа.
К созданию своих коллективов разработчиков обычно тяготеют те фирмы, которые сами специализируются в этой или близких областях. Собирая или приглашая к себе коллектив разработчиков, они чаще всего имеют в виду, что выполнив работу для них, этот коллектив впоследствии создаст рыночный продукт, который окупит разработку и сохранит коллектив для последующих усовершенствований созданной программы.
Конечно, резон в таком подходе есть, и есть примеры успешной его реализации.
Однако есть и обратные примеры.
В общем случае, стимулы у коллектива, который находится «на прокорме» в организации (т.е. на постоянной зарплате), гораздо менее сильные, чем у фирмы, которая привлечена для выполнения конкретной работы за конкретное вознаграждение.
Есть еще один психологический момент, связанный с разработкой, выполненной собственным коллективом.
После того как работа выполнена и ее стали использовать на предприятии, база данных системы начинает очень быстро насыщаться информацией.
Если концепция и средства разработки были выбраны неправильно, то это ведет к стремительному падению эффективности ее применения.
Руководство в этом случае требует ее доработки даже тогда, когда уже понимает, что ущербна сама концепция системы.
Приходится вкладывать все больше и больше средств, а желаемый эффект так и остается недостижимым.
Разум подсказывает, что надо заказывать новую разработку, но страх и амбиции не позволяют это сделать.
Дело в том, что принять решение о создании или приобретении новой системы - значит, признать свою ошибку при принятии первоначального решения.
А это всегда не просто.
Если первоначальное решение было инициировано персоналом, то над ним будет довлеть страх увольнения.
Если же это решение инициировал руководитель или владелец, то им будет владеть стыд
- Что же я такую глупость сотворил! Если я изменю свое решение все будут считать меня дураком!
И он готов поддерживать деньгами свое глупое решение, пока не разорится.
            За прошедшие тридцать лет у нас было не менее десятка таких примеров,
            о некоторых рассказано в статье "Волюнтаризм".

    Прошедшие тридцать лет с момента опубликования этой статьи подтвердили справедливость приведенных рассуждений.
    Известно несколько случаев, когда, заказав разработку системы автоматизации самостоятельной фирме, впоследствии предприятие, безусловно достаточно крупное, покупало всю фирму-разработчика и делало ее своим подразделением. Так поступил завод САМ, приобретя фирму Фолио. Так поступила Балтика, приобретя фирму Монолит-Инфо. Фирма Гепард также была приобретена. Так поступили и многие другие.
И что теперь?!
Все приобретенные фирмы были самобытными самостоятельными коллективами. Со своими идеями и опытом, выдержавшие проверку и временем и многолетним использованием их продуктов.
Были!
И где они теперь?

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