Сегодня 22.01.2022 Вы зарегистрированы в системе под именем ANONYMOUS

Rambler's Top100
Начало
Обо мне
Моя семья и звери
Статьи
Проекты
Стихи
Фото-галерея
Досуги
Былое и думы
Универсальная Самообучающаяся Экспертная Система
Мудрости
Приколы
 
Новости
Карта сайта
Все материалы
Обсуждение
Опросы
 
Rambler's Top100







Персональный сайт Андрея Акопянца  >  Статьи  >  Корпоративная автоматизация

    След. материал >>

ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

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

Заметки написаны в 1994г., но актуальности с тех пор не утеряли - просто поменялись некоторые цифры, и области.
Сейчас те же соображения применимы, например, к инструментарию для создания веб-сайтов и ERP-системам.

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

Я объяснял это для себя тремя факторами

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

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

К написанию данных заметок автора подтолкнула беседа с клиентом, который приобрел (за деньги) демострационную версию системы автоматизации деятельности НПФ, а затем, глядя на нее, решил заказывать собственную разработку знакомым программистам.

Сказал этот клиент почти дословно следующее:

"У нас нет претензий к предлагаемой вами программе по существу. Но даже получив за нее деньги и приняв на себя обязятельства по сопровождению, вы останетесь для нас чужими, и мы не будем иметь над программой ту степень контроля, которую хотим. Мы будет от вас зависеть. Кроме того, у вас там много лишнего, мы сделаем все гораздо проще. А у нас в городе много голодных программистов, они напишут."

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

Автор напомнает, что речь идет о выборе: покупать некоторую конкретную систему (предположительно лучшую на рынке) или писать самим, а не о выборе между разными системами на рынке, или о ситуации отсутствия рынка.
____________________________________________________________________________
Иллюзия первая: МЫ СДЕЛАЕМ ЭТО ЛУЧШЕ

│ В имеющеся системе имеются такие-то (следует перечисление) недостатки.
│ Мы сделаем так, что бы их не было.

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

│ Система требует слишком много ресурсов.

По этому поводу см. "Иллюзия вторая", так как этот аргумент - завуалированная попытка сэкономить на оборудовании.

│Система слишком сложна, в ней много лишнего. Мы сделаем проще, поэтому
│сделаем быстро.

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

│Система не подходит под нашу технологию

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

│Система не интегрирована с нашими прочими системами

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

│У нас постановка задачи будет лучше

Для постановки задачи требуется, кроме владения предметной областью, еще понимание чисто программистских аспектов. Грамотная постановка требует специальной квалификации, которой почти никогда не бывает у заказчика, и редко бывает у исполнтеля.

│Систему писали плохие программисты

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

____________________________________________________________________________
Иллюзия вторая: МЫ СДЕЛАЕМ ЭТО ДЕШЕВЛЕ

│Система стоит (следует цифра в долларах с тремя-четырьмя нулями).
|Зарплата программистов обойдется дешевле

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

Единственный случай, когда данный аргумент существенен - это если программисты уже есть и получают зарплату, делать им нечего и система вам нужна не срочно.

│Система требует слишком мощного и дорогого оборудования. Мы же обеспечеим
│работу на более дешевом (в идеале - на имеющемся) оборудовании.

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

И, наконец, просто имейте в виду:
лишние 2 мегабайта памяти стоят 80$
лишие 300МБ дискового пространства стоят менее 200$
замена 386 на 486 - в пределах 150$
Таким образом, все это вместе соизмеримо с месячной зарплатой квалифицированного программиста.
____________________________________________________________________________

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

Так вот, система может быть "своей" в полном смысле слова только для исполнителя.

Если исполнитель совпадает с заказчиком (человек решает - написать самому или купить), то критерий здесь - его загруженность: хватит ли ему времени кроме прочих дел еще и программу писать.

Если пользователь организационно объединен с исполнителем (одно лицо или одно структурное подразделение), то решение - покупать или писать принимает именно он (пользователь/исполнитель), и работодатель практически не может повлиять на этот выбор (только кадровыми изменениями).

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

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

Иллюзия третья: ИЛЛЮЗИЯ КОНТРОЛЯ: СИСТЕМА БУДЕТ "СВОЯ"

│ Система будет нашей, и в нее можно будет быстро вносить изменения по
│ мере появления потребностей.

Изменения будет легко вносить, если система будет хорошо спроектирована и написана (с учетом возможности изменений). Для этого требуется очень высокая квалификация исполнителей. Кроме того, изменения можно вносить, когда система уже есть. А ее сначала сделать надо...
Достижение просто приемлемого уровня сервиса, как правило, занимает столько рабочего времени, что на остальное его просто не остается. Т.е. все время будет стоять дилемма: делать систему более специфичной или просто более удобной в работе.

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

│ Мы не хотим зависеть от сопровождения разработчика и ждать, пока он будет
│ устранять обнаруженные нами ошибки.

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

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

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

│ Мы не хотим, чтобы разработчик мог выкручивать нам руки.

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

│ Мы не хотим покупать у конкурентов, чтобы не давать им контроль над со-
│ бой.

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

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

____________________________________________________________________________
Иллюзия четвертая: СДЕЛАЕМ - ПРОДАВАТЬ БУДЕМ

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

____________________________________________________________________________

Итак, господа заказчики и пользователи, давайте отдавать себе отчет в
следующем:

  • Самостоятельная разработка практически никогда не оправдывается
  • Зачастую у вас просто нет выбора, так как купленые системы будут оттор-
    гнуты вашим разрабатывающим/эксплуатирующим коллективом
  • Желание подкормить сотрудников и знакомых и решение производственных
    проблем - это разные вещи, и их следует рассматривать отдельно.

И вообще - берите пример с программистов. Они уже давно не пишут себе компиляторы и СУБД. Они пользуются готовыми. Ругаются, но пользуются ...

Еще один практический совет: экплуатацией лучше заниматься женщинам. Для человека, занимающегося эксплуатацией, нет большего греха, чем стремление чего-нибудь самому запрограммировать...
____________________________________________________________________________
Р.S.
Автор берет обязательство написать еще одно эссе на эту же тему, которое
будет называться
"Купить иль не купить,
или почему приходится разрабатывать собственное программное обеспечене"


( опубликовано 09.05.2001)
    След. материал >>

Обсуждение (всего 12 реплик, последняя - 23.01.2006 14:48)    Настройка

26.10.2005 14:38 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Абсолютно согласен - всякую "малую механизацию" c помощью Accessa, Excel-a и какой-то матери можно и нужно делать внутри.

Но когда речь идет именно о более или менее амбициозной РАЗРАБОТКЕ, полностью занимающей ресурсы одного или нескольких программистов на срок неделя и более, и ставящей задачу не "затыкания дыр", а выдачи на гора какой-то СИСТЕМЫ, тут все мои аргументы вступают в силу.

А проблем взаимодействия с поставщиками - как правило, всегда выше крыши, и ничего нового тут нет. Но поверьте, если бы вы писали эту программу самостоятельно, проблем для фирмы было бы гораздо больше :)

>> >>

 
26.10.2005 13:17 Шатунов Виталий Иванович Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Из ответа сотруднику, который отослал меня на эту статью.
Внимательно почитал «почиталку»...
Я бы согласился с автором (впрочем во многом согласен и более того считаю, что основные программные продукты – финансового и складского учета должны быть именно «фирменными» [здесь и поддержка изменений в законодательстве и отчетности и важные прочие мелочи], однако когда необходимо быстро и оперативно решить какие-то локальные задачи (или задачи не требующие строгой финансовой отчетности), то думаю нужно использовать свои умственные резервы.
Например:
Программ...>> >>

 
02.07.2003 05:19 Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Много ...
... много умных и правильных слов ... но

Кем пишутся те большие проекты? Случайно не марсианами? ... На удивление нет ... А подозреваю я пишутся они теми самыми "как правило бывшими сотрудниками" ... которые не нашли себе применения на родном предприятии ... и по этому теперь продают свое "самовыражение" ...

Насчет грамотности специалистов. На мой взгляд автор очень пренебрежительно отзывается в первую очередь в свой собственный адрес. Что начинает делать предприятие купив систему? Ответ очевиден: переписывать, переделывать, донастраивать и т.д. П...>> >>

 

14.11.2002 22:00 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
По поводу единого информационного пространства см. например
http://akop.ru/personal/1234>> >>

 
14.11.2002 21:02 Максим Смирнов Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Я что-то пропустил? :-)
Единое информационное пространство это что?
Если это возможность свободно обмениваться информацией, то никакая комплексная АС для этого не нужна, мы вот с Вами свободно обмениваемся репликами без всякой комплексной системы. Если же единое информационное пространство это один большой мэйнфрейм на всю компанию, то извините, это уже не корпорация получается, а музей вычислительной техники.

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

 

14.11.2002 11:08 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
IMHO островная автоматизация плоха не тем, что не все операции автоматизируются, а тем, что не создается единого информационного пространства.

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

Хотя, надо сказать, "монстры" типа R3 давно вызывают у меня сильные сомнения - я практически не знаю успешных примеров внедрения (говорят, есть одно образцово-показательное в БелгородЭнерго, но оно чуть ли не единственное).

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

А пассаж насчет серьезных менеджеров я не понял...>> >>

 

14.11.2002 00:19 Максим Смирнов Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
И все же давайте еще раз все по порядку:
Чем плоха «островковая» она же «лоскутная» автоматизация? Года с 1995 в народное сознание активное внедряется идея «универсального клиента» (правда Sun говорил что универсальный клиент это VMJ, Microsoft что Wintel с офисом, Netscape что-то про навигатор с javascript. но это не суть важно.). От множества серверов в этом случае не уйдешь, но TCO за счет поддержки клиента не увеличит. Кроме того, если вспомнить пассаж Радучела о том что «межоперабельность(т.е. способность интегрироваться с другими системами) ...>> >>

 
10.11.2002 21:57 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Учитывая, что гонорару там будет примерно на бутылку коньяка - ноу проблем!>> >>

 
10.11.2002 21:11 Прядкин Вячеслав Георгиевич Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Гонорар - на троих ! :o)>> >>

 
10.11.2002 19:33 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Собственно, материалы этого топика уже почти образовали то самое эссе (Купить или не купить, или почему приходится разрабатывать собственное ПО), которое я анонсировал, но в течение 8 лет так и не собрался написать...>> >>

 
10.11.2002 11:08 Прядкин Вячеслав Георгиевич Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Хм... Зашел на этот сайт случайно, по ссылке на Тимура Шаова, а тут такой интересный топик :o). Впрочем, насчет авторской песни тоже чего-нибудь сочиню, но сначала про работу. Сразу подчеркну, что тупая статистика личных наблюдений дает подавляющее превосходство "своих сил", ну хоть ты убейся. И эту линию сейчас буду гнуть долго и нудно. Я хорошо помню, как внедрялось годами (!) изделие крупного солидного ПКБ на металлургическом предприятии в 80-х годах, и каков оказался его жизненный цикл. Как внедрялась западная банковская система в крупном региональном банке, и с каким треском это...>> >>

 
09.11.2002 14:56 Максим Смирнов Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене
Всю жизнь я был противником собственной разработки. Может быть по причине продолжительной работы в Инкомбанке с собственной АБС, может быть же в силу каких-то других причин. Однако, опыт последних двух лет мешает оставаться мне столь категоричным, потому как:
- Вопрос писать или не писать состоит из двух вопросов: купить готовое или разработать заново и разработать своими силами либо привлечь аутсорсера. Соответственно «писать или не писать» перестает быть дилеммой.
- 21 век на дворе, однако. Гордость «покупателя» в глобальной экономике не позволяет действовать в парадигме «не считайте себя умнее других, пользуйте SAP/R3». Что делать с теми же конкурентными преимуществами любимой фирмы, состоящими, например, в том, что отдел из трех-пяти человек поддерживает продажи на сотни MUSD в год, с присущим только нашим сотрудниками users experience и т.п. Коробочные решения, как известно, запросто убивают ключевые компетенции.
- Нельзя игнорировать «новые» идеи вроде XP. Вряд ли поставщики коробок могут ответить что-либо вразумительное Кенту Беку, который говорит о том, что стоимость внесения изменений вовсе не обязана расти во времени по экспоненте.

Согласен, что самовыражение программистов за счет компании – явление отвратительное. Однако, ответ на вопрос «писать или не писать» вряд ли может быть столь категоричным.>> >>

 


Реклама: ведущее mx-x  
В начало страницы (C) Andrey Akopyants
Перепечатка авторских материалов сайта приветствуется! Ссылка на первоисточник при перепечатке обязательна.