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