Писать иль не писать или почему не стоит разрабатывать собственное программное обеспечение
www.akop.ru
Заметки в свободном жанре для пользователей, их начальников и для намеревающихся стать теми или другими. Заметки написаны в 1994г., но актуальности с тех пор не утеряли - просто поменялись некоторые цифры и области. Сейчас те же соображения применимы, например, к инструментарию для создания веб-сайтов и ERP-системам.
В течение ряда лет автор с непреходящим изумлением смотрел на ситуацию с бухгалтерскими системами, где, несмотря на изобилие готовых пакетов, каждая уважающая себя организация писала собственную бухгалтерскую программу. Я объяснял это для себя тремя факторами:
- Наличием большого количества полубезработной программирующей публики;
- Отсутствием у заказчиков реальной потребности в разрабатываемых системах;
- Пресловутой "Собственной гордостью", которая как известно, в тяжелой форме была у Советских, и у российских осталась по наследству.
Как ни странно, аналогичная ситуация повторяется с операционными данными банков, депозитариями и другими системами из области финансового бизнеса, потребителей которых трудно обвинить в платонической любви к программированию и неумении считать деньги, и где необходимость в автоматизированных системах учета очевидна (или, может, в последнем я ошибаюсь?). Это означает, что идея самообеспечения программными продуктами (и вообще самообеспечения) очень крепко засела в отечественном менталитете.
К написанию данных заметок автора подтолкнула беседа с клиентом, который приобрел (за деньги) демонстрационную версию системы автоматизации деятельности НПФ, а затем, глядя на нее, решил заказывать собственную разработку знакомым программистам. Сказал этот клиент почти дословно следующее: "У нас нет претензий к предлагаемой вами программе по существу. Но даже получив за нее деньги и приняв на себя обязятельства по сопровождению, вы останетесь для нас чужими, и мы не будем иметь над программой ту степень контроля, которую хотим. Мы будет от вас зависеть. Кроме того, у вас там много лишнего, мы сделаем все гораздо проще. А у нас в городе много голодных программистов, они напишут."
Эта тирада, несмотря на свою лаконичность, содержит почти все характерные аргументы, которыми люди обосновывают решение о начале самостоятельной разработки. Автор задумался и, вспомнив еще несколько типичных аргументов, с которыми ему приходилось встречаться, решил придать своим соображениям систематический вид и увековечить их в виде заметок. Они, естественно, субъективны и представляют точку зрения поставщика прикладного программного обеспечения.
Автор напоминает, что речь идет о выборе: покупать некоторую конкретную систему (предположительно лучшую на рынке) или писать самим, а не о выборе между разными системами на рынке, или о ситуации отсутствия рынка.
Иллюзия первая: МЫ СДЕЛАЕМ ЭТО ЛУЧШЕ
В имеющейся системе имеются такие-то (следует перечисление) недостатки. Мы сделаем так, что бы их не было.
Не забывайте, что перед тем, как устранять недостатки, надо сначала сделать все то, что уже есть в готовой системе. А ее авторы в это время тоже не будут стоять на месте. Исключения бывают в случае прекращения авторами работ над данным направлением. Так было, скажем, с soft-ом на PDP-совместимую технику. Но это означает, что у данной работы нет никакой перспективы, и вкладывать усилия в усовершенствование того, что уже морально устарело, вряд ли стоит.
Система требует слишком много ресурсов.
По этому поводу см. "Иллюзия вторая", так как этот аргумент - завуалированная попытка сэкономить на оборудовании.
Система слишком сложна, в ней много лишнего. Мы сделаем проще, поэтому сделаем быстро.
Как правило, данный аргумент свидетельствует о недопонимании реальной сложности задачи. Разработчики имеющейся системы тоже, наверное, не хотели себе лишних проблем...
Система не подходит под нашу технологию.
Подумайте - может быть, вам проще поменять технологию или сгладить это несоотвествие организационными мерами, чем связываться с разработкой. Ведь разработчики наверняка брали в основу более или менее стандартную технологию, и принимали во внимание действующие нормы.
Бывают ситуации, когда несоовествие фатально и определется законодательной регламентацией технологий и форм отчетности. Поэтому, например, импортные банковские системы малопригодны на отечественном рынке. Но в этом случае, если вы не первопроходец в вашей предметной области, значит, кто-то уже думает и пишет под эти стандарты.
Система не интегрирована с нашими прочими системами
Как правило, приемлемой степени интеграции можно добиться через экспорт/импрот данных. И потом - так ли она вам нужна, эта интеграция, и много ли денег вы потеряете, если ее не будет?
У нас постановка задачи будет лучше
Для постановки задачи требуется, кроме владения предметной областью, еще понимание чисто программистских аспектов. Грамотная постановка требует специальной квалификации, которой почти никогда не бывает у заказчика, и редко бывает у исполнтеля.
Систему писали плохие программисты
Это единственный веский аргумент из данной серии. Правда, надо быть уверенным, что ваши программисты не просто лучше, а существенно лучше.
Иллюзия вторая: МЫ СДЕЛАЕМ ЭТО ДЕШЕВЛЕ
Система стоит (следует цифра в долларах с тремя-четырьмя нулями). Зарплата программистов обойдется дешевле
Заказывая разработку, вы можете быть уверены в быстром и качественном получении результата только при работе с профессионалами высокого класса (причем имеющими опыт работы со сходными задачами). А они обычно знают себе цену и стоят дорого. Кроме того, необходимо принять в расчет не только разработку по имеющимся спецификациям, но и дальнейшее развитие и сопровождение, и необходимость иметь минимум двух взаимозаменяемых специалистов. Как известно, к этой фазе относятся две трети затрат. Не забывайте также, что норма зарплаты растет очень быстро и если разработка рассчитана, скажем, на полгода, то ваши затраты могут сильно превзойти расчетные. Единственный случай, когда данный аргумент существенен - это если программисты уже есть и получают зарплату, делать им нечего и система вам нужна не срочно.
Система требует слишком мощного и дорогого оборудования. Мы же обеспечим работу на более дешевом (в идеале - на имеющемся) оборудовании.
В отличие от стоимости рабочей силы, которая растет, стоимость оборудования со временем падает. Кроме того, вам все равно придется модернизировать ваш компьютерный парк просто для того, чтобы не терять совместимость с окружающим миром и иметь возможность эксплуатировать современные версии текстовых процессоров, графических редакторов и др. И, наконец, просто имейте в виду (данные 1994 г. - Прим. Ред.):
- лишние 2 мегабайта памяти стоят 80$
- лишие 300МБ дискового пространства стоят менее 200$
- замена 386 на 486 - в пределах 150.$
Таким образом, все это вместе соизмеримо с месячной зарплатой квалифицированного программиста.
Следующая иллюзия - иллюзия контроля. Формулируется она так: "Программа будет своя". Эта иллюзия зачастую перевешивает по значимости предыдущие две, и является наиболее живучей. Для того чтобы разобраться с этими вопросами, нужно конкретизировать организационную ситуацию:
Имееются:
- тот, кто платит деньги (заказчик или работодатель)
- тот, кто выполняет разработку (исполнитель)
- тот, кто эксплуатирует систему (пользователь)
Так вот, система может быть "своей" в полном смысле слова только для исполнителя. Если исполнитель совпадает с заказчиком (человек решает - написать самому или купить), то критерий здесь - его загруженность: хватит ли ему времени кроме прочих дел еще и программу писать. Если пользователь организационно объединен с исполнителем (одно лицо или одно структурное подразделение), то решение - покупать или писать принимает именно он (пользователь/исполнитель), и работодатель практически не может повлиять на этот выбор (только кадровыми изменениями). Мы будем рассматривать ситуацию, когда все три позиции разделены, и заказчик реально имеет выбор - покупать или заказывать. Обратите внимание - для заказчика это уже не называется "делать самому", а называется "заказать" или "поручить". Заметим, аргументацией в пользу самостоятельной разработки занимается всегда исполнитель, как непосредственно заинтересованная сторона. Заказчика он зачастую может убедить или просто заставить принять это решение, если заказчик от него зависим по каким-либо другим позициям (другие работы, личные отношения).
Иллюзия третья: ИЛЛЮЗИЯ КОНТРОЛЯ: СИСТЕМА БУДЕТ "СВОЯ"
Система будет нашей, и в нее можно будет быстро вносить изменения по мере появления потребностей.
Изменения будет легко вносить, если система будет хорошо спроектирована и написана (с учетом возможности изменений). Для этого требуется очень высокая квалификация исполнителей. Кроме того, изменения можно вносить, когда система уже есть. А ее сначала сделать надо...
Достижение просто приемлемого уровня сервиса, как правило, занимает столько рабочего времени, что на остальное его просто не остается. Т.е. все время будет стоять дилемма: делать систему более специфичной или просто более удобной в работе. В готовую же систему, если она имеет более одной поставки и развивается, большинство нужных вам изменений будут вноситься и так, независимо от вас.
Мы не хотим зависеть от сопровождения разработчика и ждать, пока он будет устранять обнаруженные нами ошибки.
Безусловно, поставщик системы будет исправлять ошибку и заменять версию дольше, чем ваш собственный программист. С другой стороны, в готовой системе ошибок, как правило, меньше, и исправляются они зачастую раньше, чем персонально вы на них нарветесь. Вы может понести ущерб от ошибки в купленной программе, но с большей вероятностью вы пострадаете от ошибки в самодельной. Причем в последнем случае спросить будет не с кого - ну уволите вы своего программиста, а дальше что? Kто ошибку-то исправлять будет? Поставщик же в данной ситуации постарается замять скандал, и удовлетворит вас доступными ему средствами, дабы не пострадала его репутация. При исчезновении вашего разработчика вам остается работать, пока работается, а затем выкинуть программу. Об исправлении ошибок и развитии говорить в этом случае уже не приходится - этим никто не станет заниматься. Поэтому вам нужно иметь как минимум двух взаимозаменяемых специалистов, так как люди имеют свойство болеть, увольняться и (не дай бог!) попадать под машину. Проблемы поставщиков программы вас будут волновать гораздо меньше - разве что они всей фирмой куда-нибудь попадут. Да и в этом случае кто-нибудь возьмет на себя сопровождение.
Мы не хотим, чтобы разработчик мог выкручивать нам руки.
Известно много случаев, когда свои сотрудники весьма эффективно выкручивают руки, особенно становясь бывшими сотрудниками. А при принципиальной (т.е. всегда и объективно имеющей место) недоделанности программы "для себя" заказчик оказывается в такой ситуации совершенно беззащитным, так как вряд ли он найдет желающего заниматься ассенизацией - возня с чужой программной у толковых программистов обычно вызывает похожие чувства.
Мы не хотим покупать у конкурентов, чтобы не давать им контроль над собой.
Даже если вы покупаете у конкурентов, взаимодействовать вы будете с конкретными людьми - программистами, которым проблемы конкуренции на рынке банковских и других услуг совершенно до фонаря. Для них вы не конкуренты, а клиенты - те, кто заказывает музыку. А поскольку программа реально находится под контролем разработчиков, то вы всегда найдете способ договориться. Могут быть, конечено, "шпионские страсти" с зараженными программами и "троянскими конями", но это уже из области криминальной хроники (в приличном обществе за это бьют морду).
Иллюзия четвертая: СДЕЛАЕМ - ПРОДАВАТЬ БУДЕМ
Очень трудно выйти на рынок, где уже есть конкуренция - у конкурентов фора во времени и клиентах. Хотя конечно, есть удачные примеры, особенно если есть административные механизмы вляния на некоторый круг потенциальных покупателей.
Итак, господа заказчики и пользователи, давайте отдавать себе отчет в следующем:
- Самостоятельная разработка практически никогда не оправдывается;
- Зачастую у вас просто нет выбора, так как купленные системы будут отторгнуты вашим разрабатывающим/эксплуатирующим коллективом;
- Желание подкормить сотрудников и знакомых и решение производственных проблем - это разные вещи, и их следует рассматривать отдельно;
И вообще - берите пример с программистов. Они уже давно не пишут себе компиляторы и СУБД. Они пользуются готовыми. Ругаются, но пользуются ... Еще один практический совет: эксплуатацией лучше заниматься женщинам. Для человека, занимающегося эксплуатацией, нет большего греха, чем стремление чего-нибудь самому запрограммировать...
P.S. Автор берет обязательство написать еще одно эссе на эту же тему, которое будет называться "Купить иль не купить, или почему приходится разрабатывать собственное программное обеспечение".
Оставить комментарий
Комментарии
Просто главное при принятии решения надо всё взвесить
А, в общем, статья ничего, только для 1994 года.
а нападки на предмет того, что "если взять стороннюю разработку, то потом затрат в несколько раз больше будет, нежели написать свою" подозреваю идут от того, что люди просто не сталкивались с большими системами. одно дело - написать скажем учет компакт-дисков или кассет в прокате и совсем другое - учет потребления электроэнергии для РЭСа. масштабы немного разные. и пока вы будете писать свою поделку, которая будет "полностью своя", конкуренты напишут, отладят и продадут то, до чего вам еще писать и писать.
Статья мне понравилась. Тем более что автор берет обязательство описать свои взгляды, но как бы с другой стороны. Только не нужно поддаваться моде в примитивной критике "Советской гордости", тем более перенося ее на своих соотечественников. Не все было так просто...
Но вернусь к эссе. Систематизировано, последовательно и без "растекания мыслями по древу" - то есть вполне строго придерживаясь избранному сюжету.
Конечно, автор сам отмечает в P.S., что часто нужно (или приходится) писать программы. Но по-моему тема очень правильно раскрыта. Часто требуется затратить достаточно много сил и тем более желания, чтобы сформулировать задачу, поставить цель, найти и купить то ПО (софт по ихнему), что с минимальными настройками (не доработками) и также минимальными изменениями в организации своей работы подошло и быстро бы начало давать отдачу. А ведь лень ... Чего проще и приятнее сесть и сразу начать писать ... Если есть время.
Почему я так думаю? Вот три примера.
1.Еще при Советах, работая над диссертацией, я заметил, что все коллеги увлекаются программированием простых математических задач (умножение матриц, решение диф.уравнений, систем линейных уравнений и т.д.). Это, конечно, все было нужно и либо писалось либо где-то доставалось ворованое. Я как-то раскопал в реферативном журнале заметку о поставке (а фактически продаже) пакета (правильнее набора) программ Белорусским институтом математики. И за деньги (6000р) своего договора купил его. Кстати пакет очень даже неплохой. А потом большинство в моем институте думали, что пакет приобретен вместе с "мощной" машиной ЕС-1061.
2.При разгуле демократии по инерции продолжал заниматься математическим моделированием. И в свободное от зарабатывания время писал пакет ... Ну в общем, "метод конечных элементов" для расчета электромагнитного (магнитного, электростатического) поля. Написал. Все вроде есть, хоть и простенько. И графический редактор, и постпроцессор (это результаты в виде картинок и графиков). Некоторые коллеги даже использовали, писали статьи. В трех "фирмах" научных даже внедрил. Примерно по 200-400 у.е. получил. Сейчас эта штука при расчете процесса нагрева вихревыми токами стальной болванки дает более точные и быстрые результаты чем Femlab 2.3 и 3.1 (более свежих не испытывал). Ну и что? Отстаю я от них. У них и интерфейс богаче и набор задач широченный. Потому, что их много, а я - один.
3.В то же время пришлось подрабатывать в недвижимости. И сами понимаете ... Написал базу на MS Абсцессе (ах простите, Аксессе). Худо-бедно где-то 60 агентств (в основном маленьких) кормят. Я, что-то для них собираю, обобщаю, поставляю. Многие довольны и благодарят. Это мои - они купили.
Но многие не понимают зачем нужна такая сложная программа со множеством меню, кнопок и "окошечек".
Нам бы распечатки по факсу - говорят, такие часто не мои.
Несколько раз были случаи когда "свой" программист (у моих) начинал писать "свою" базу для агентства. Чаще всего он потом исчезал, а агентство оставалось "моим". Но, конечно большие "конторы" держат своих программистов и делают софт "под себя".
Вот три достаточно различных примера. Итак, если писать, то можно застрять. А если бы не писали, то ничего вообще не было бы. "Только челюсти да шерсть".
А фраз а о том что легче пререстроить схему работы предприятия, чем написать готовый продукт-это просто "Гениально".
а про сайты согласен с тем, что надо своими ручками, или ручками тех кого пнуть не долго.
Проверено на практике.
Им не везло в их "програмистской жизни"
Иль они решили сократить конкуренцию?
ИМХО, они пошли на дно, и всех предупреждают об этом...
Ребят, если у вас не получилось, пчему вы думаете, что все остальные не смогут?
Ладно, все это только мое мнение