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