|
В течение ряда лет автор с непреходящим изумлением смотрел на ситуацию с бухгалтерскими системами, где, несмотря на изобилие готовых пакетов, каждая уважающая себя организация писала собственную бухгалтерскую программу. Я объяснял это для себя тремя факторами - Наличием большого количества полубезработной программирующей публики;
- Отсутствием у заказчиков реальной потребности в разрабатываемых системах;
- Пресловутой "Собственной гордостью", которая как известно, в тяжелой форме была у Советских, и у российских осталась по наследству.
Как ни странно, аналогичная ситуация повторяется с операционными днями банков, депозитариями и другими системами из области финансового бизнеса, потребителей которых трудно обвинить в платонической любви к программированию и неумении считать деньги, и где необходимость в автоматизированных системах учета очевидна (или может, в последнем я ошибаюсь?).
Это означает, что идея самообеспечения программными продуктами (и вообще самообеспечения) очень крепко засела в отечественном менталитете. К написанию данных заметок автора подтолкнула беседа с клиентом, который приобрел (за деньги) демострационную версию системы автоматизации деятельности НПФ, а затем, глядя на нее, решил заказывать собственную разработку знакомым программистам. Сказал этот клиент почти дословно следующее: "У нас нет претензий к предлагаемой вами программе по существу. Но даже получив за нее деньги и приняв на себя обязятельства по сопровождению, вы останетесь для нас чужими, и мы не будем иметь над программой ту степень контроля, которую хотим. Мы будет от вас зависеть. Кроме того, у вас там много лишнего, мы сделаем все гораздо проще. А у нас в городе много голодных программистов, они напишут." Эта тирада, несмотря на свою лаконичность, содержит почти все характерные аргументы, которыми люди обосновывают решение о начале самостоятельной разработки.
Автор задумался и, вспомнив еще несколько типичных аргументов, с которыми ему приходилось встречаться, решил придать своим соображениям систематический вид и увековечить их в виде заметок. Они, естественно, субъективны и представляют точку зрения поставщика прикладного программного обеспечения. Автор напомнает, что речь идет о выборе: покупать некоторую конкретную систему (предположительно лучшую на рынке) или писать самим, а не о выборе между разными системами на рынке, или о ситуации отсутствия рынка.
____________________________________________________________________________
Иллюзия первая: МЫ СДЕЛАЕМ ЭТО ЛУЧШЕ │ В имеющеся системе имеются такие-то (следует перечисление) недостатки.
│ Мы сделаем так, что бы их не было. Не забывайте, что перед тем, как устранять недостатки, надо сначала сдеkать все то, что уже есть в готовой системе. А ее авторы в это время тоже не будут стоять на месте.
Исключения бывают в случае прекращения авторами работ над данным направлением. Так было скажем, с soft-ом на PDP-совместимую технику. Но это означает, что у данной работы нет никакой перспективы, и вкладывать усилия в усовершенстование того, что уже морально устарело, вряд ли стоит. │ Система требует слишком много ресурсов. По этому поводу см. "Иллюзия вторая", так как этот аргумент - завуалированная попытка сэкономить на оборудовании. │Система слишком сложна, в ней много лишнего. Мы сделаем проще, поэтому
│сделаем быстро. Как правило, данный аргумент свидетельствует о недопонимании реальной сложности задачи. Разработчики имеющейся системы тоже, наверное, не хотели себе лишних проблем... │Система не подходит под нашу технологию Подумайте - может быть, вам проще поменять технологию или сгладить это несотвествие орагнизационными мерами, чем связываться с разработкой. Ведь разработчики наверняка брали в основу более или менее стандартную технологию, и принимали во внимание действующие нормы.
Бывают ситуации, когда несоовествие фатально и определется законодательной регламентацией технологий и форм отчетности. Поэтому, например, импортные банковские системы малопригодны на отечественном рынке. Но в этом случае, если вы не первопроходец в Вашей предметной области, значит, кто-то уже думает и пишет под эти стандарты. │Система не интегрирована с нашими прочими системами Как правило, приемлемой степени интеграции можно добиться через экспорт/импрот данных. И потом - так ли она вам нужна, эта интеграция, и много ли денег вы потеряете, если ее не будет? │У нас постановка задачи будет лучше Для постановки задачи требуется, кроме владения предметной областью, еще понимание чисто программистских аспектов. Грамотная постановка требует специальной квалификации, которой почти никогда не бывает у заказчика, и редко бывает у исполнтеля. │Систему писали плохие программисты Это едиственный веский аргумент из данной серии. Правда, надо быть уверенным, что ваши программисты не просто лучше, а существенно лучше. ____________________________________________________________________________
Иллюзия вторая: МЫ СДЕЛАЕМ ЭТО ДЕШЕВЛЕ │Система стоит (следует цифра в долларах с тремя-четырьмя нулями).
|Зарплата программистов обойдется дешевле Заказывая разработку, в можете быть уверены в быстром и качественном получение результата только при работе с профессионалами высокого класса (причем имеющими опыт работы со сходными задачами). А они обычно знают себе цену и стоят дорого.
Кроме того, необходимо принять в расчет не только разработку по имеющимся спецификациям, но и дальнейшее развитие и сопровождение, и необходимость иметь минимум двух взаимозаменяемх специалистов. Как известно, к этой фазе относятся две трети затрат.
Не забывайте также, что норма зарплаты растет очень быстро и если разработка расчитана, скажем, на полгода, то ваши затраты могут сильно превзойти расчетные. Единственный случай, когда данный аргумент существенен - это если программисты уже есть и получают зарплату, делать им нечего и система вам нужна не срочно. │Система требует слишком мощного и дорогого оборудования. Мы же обеспечеим
│работу на более дешевом (в идеале - на имеющемся) оборудовании. В отличии от стоимость рабочей силы, которая растет, стоимость оборудования со временем падает.
Кроме того, вам все равно прийдется модернизировать ваш компьютерный парк просто для того, чтобы не терять совместимость с окружающим миром и иметь возможность эксплуатировать современные версии текстовых процессоров, графических редакторов и др. И, наконец, просто имейте в виду:
лишние 2 мегабайта памяти стоят 80$
лишие 300МБ дискового пространства стоят менее 200$
замена 386 на 486 - в пределах 150$
Таким образом, все это вместе соизмеримо с месячной зарплатой квалифицированного программиста.
____________________________________________________________________________ Следующая иллюзия - иллюзия контроля. Формулируется она так: "Программа будет своя". Эта иллюзия зачастую перевешивает по значимости предыдущие две, и является наиболее живучей. Для того чтобы разобраться с этими вопросами, нужно конкретизировать организационную ситуацию:
Имееются:
тот, кто платит деньги (заказчик или работодатель)
тот, кто выполняет разработку (исполнитель)
тот, кто эксплуатирует систему (пользователь) Так вот, система может быть "своей" в полном смысле слова только для исполнителя. Если исполнитель совпадает с заказчиком (человек решает - написать самому или купить), то критерий здесь - его загруженность: хватит ли ему времени кроме прочих дел еще и программу писать. Если пользователь организационно объединен с исполнителем (одно лицо или одно структурное подразделение), то решение - покупать или писать принимает именно он (пользователь/исполнитель), и работодатель практически не может повлиять на этот выбор (только кадровыми изменениями). Мы будем рассматривать ситуацию, когда все три позиции разделены, и заказчик реально имеет выбор - покупать или заказывать. Обратите внимание - для заказчика это уже не называется "делать самому", а называется "заказать" или "поручить". Заметим, аргументацией в пользу самостоятельной разработки занимается всегда исполнитель, как непоредственно заинтересованная сторона. Заказчика он зачастую может убедить или просто заставить принять это решение, если заказчик от него зависим по каким-либо другим позициям (другие работы, личные отношения). Иллюзия третья: ИЛЛЮЗИЯ КОНТРОЛЯ: СИСТЕМА БУДЕТ "СВОЯ" │ Система будет нашей, и в нее можно будет быстро вносить изменения по
│ мере появления потребностей. Изменения будет легко вносить, если система будет хорошо спроектирована и написана (с учетом возможности изменений). Для этого требуется очень высокая квалификация исполнителей. Кроме того, изменения можно вносить, когда система уже есть. А ее сначала сделать надо...
Достижение просто приемлемого уровня сервиса, как правило, занимает столько рабочего времени, что на остальное его просто не остается. Т.е. все время будет стоять дилемма: делать систему более специфичной или просто более удобной в работе. В готовую же систему, если она имеет более одной поставки и развивается, большинство нужных вам измененений будут вноситься и так, независимо от вас. │ Мы не хотим зависеть от сопровождения разработчика и ждать, пока он будет
│ устранять обнаруженные нами ошибки. Безусловно, поставщик системы будет исправлять ошибку и заменять версию дольше, чем ваш собственный программист. С другой стороны, в готовой системе ошибок, как правило, меньше, и исправляются они зачастую раньше, чем персонально вы на них нарветесь.
Вы может понести ущерб от ошибки в купленной программе, но с большей вероятностью вы пострадаете от ошибки в самодельной. Причем в последнем случае спросить будет не с кого - ну уволите вы своего программиста, а дальше что? - кто ошибку-то исправлять будет?
Поставщик же в данной ситуации постарается замять скандал, и удовлетворит вас доступными ему средствами, дабы не пострадала его репутация. При исчезновении вашего разработчика вам остается работать, пока работается, а затем выкинуть программу. Об исправлении ошибок и развитии говорить в этом случае уже не приходится - этим никто не станет
заниматься.
Поэтому Вам нужно иметь как минимум двух взаимозаменяемых специалистов, так как люди имеют свойство болеть, увольняться и (не дай бог!) попадать под машину. Проблемы поставщиков программы вас будут волновать гораздо меньше - разве что они всей фирмой куда-нибудь попадут. Да и в этом случае кто-нибудь возмет на себя сопровождение. │ Мы не хотим, чтобы разработчик мог выкручивать нам руки. Извесно много случаев, когда свои сотрудники весьма эффективно выкручивают руки, особенно становясь бывшими сотрудниками. А при принципиальной (т.е. всегда и объективно имеющей место) недоделанности программы "для себя" заказчик оказывается в такой ситуации совершенно беззащитным, так как вряд ли он найдет желающего заниматься ассенизацией - возня с чужой программной у толковых программистов обычно вызывает похожие чувства. │ Мы не хотим покупать у конкурентов, чтобы не давать им контроль над со-
│ бой. Даже если вы покупаете у конкурентов, взаимодействовать вы будете с конкретными людьми - программистами, которым проблемы конкуренции на рынке банковских и других услуг совершенно до фонаря. Для них вы не конкуренты, а клиенты - те, кто заказывает музыку. А поскольку программа реально находится под контролем разработчиков, то вы всегда найдете способ договориться. Могут быть, кончено, "шпионские страсти" с зараженными программами и "троянскими конями", но это уже из области криминальной хроники (в приличном обществе за это бьют морду). ____________________________________________________________________________
Иллюзия четвертая: СДЕЛАЕМ - ПРОДАВАТЬ БУДЕМ Очень трудно выйти на рынок, где уже есть конкуренция - у конкурентов фора
во времени и клиентах. Хотя конечно, есть удачные примеры, особенно если
есть административные механизмы вляния на некоторый круг потенциальных поку-
пателей. ____________________________________________________________________________ Итак, господа заказчики и пользователи, давайте отдавать себе отчет в
следующем: - Самостоятельная разработка практически никогда не оправдывается
- Зачастую у вас просто нет выбора, так как купленые системы будут оттор-
гнуты вашим разрабатывающим/эксплуатирующим коллективом - Желание подкормить сотрудников и знакомых и решение производственных
проблем - это разные вещи, и их следует рассматривать отдельно.
И вообще - берите пример с программистов. Они уже давно не пишут себе компиляторы и СУБД. Они пользуются готовыми. Ругаются, но пользуются ... Еще один практический совет: экплуатацией лучше заниматься женщинам. Для человека, занимающегося эксплуатацией, нет большего греха, чем стремление чего-нибудь самому запрограммировать...
____________________________________________________________________________
Р.S.
Автор берет обязательство написать еще одно эссе на эту же тему, которое
будет называться
"Купить иль не купить,
или почему приходится разрабатывать собственное программное обеспечене"
(
опубликовано 09.05.2001)
|