Система. Писать – не писать? Покупать – не покупать?

ЗАПИСКИ ДОБРОГО АВТОМАТИЗАТОРА
Или
Руководителю, обдумывающему компьютеризацию своего бизнеса.

Выпуск 10

Система.
Писать – не писать? Как писать? Покупать – не покупать? Которую покупать?

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

Писать – не писать?

Писать.

Иногда Вы вынуждены разрабатывать ПО (программное обеспечение) заново, поскольку
того, что Вам надо – просто не существует в природе. А если Вы можете выбирать,
то надо взвесить все за и против.

Какие положительные аспекты имеются у такого решения? Прежде всего – свобода
маневра. То есть – полная свобода. Чего хотите – то и сделаете. Если сумеете.
Можно выбрать самые современные технологии создания ПО. Можно выбрать любую систему
управления базами данных (СУБД) и даже операционную систему (ОС). Можно и Linux
– чего же как все на Windows работать, если хочется на Linux, например. Ну, и
конечно, это будет ровно такая программа, которая Вам нужна. Все необходимые
функции. Ничего лишнего.

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

Недостатки самостоятельного (заказного) создания софта.

Стоимость.

Самостоятельное создание софта – очень дорогое удовольствие. Если Вы не очень
много тратите на самостоятельное создание софта, значит Вы чего-то не так делаете.
Есть правда одно исключение.

Маленькие, простые, локальные специальные программы с консервативной функциональностью.
Маленькая программа – это такая, которую создает один человек за несколько недель.
Простая –это такая, в которой может разобраться без посторонней помощи любой
программист. Специальная – это понятно. Она нужна только Вам и больше никому.
Локальная – это значит, что информация, которую программа потребляет и вырабатывает
не поступает из других систем и не передается в другие системы. Иначе – это уже
не маленькая программа, а часть большой системы. Консервативная – такая, которую
никогда не надо будет доделывать/переделывать. Пишется один раз, - работает всегда.

Вот что тогда получается. Нужна Вам такая маленькая программа – Вы поручаете
ее написать кому угодно – собственному специалисту или внешнему, временному,
случайному. Главное – пусть отладит, запустит, обучит и идет куда хочет. Или
пусть у Вас другими делами занимается. Программа эта хлеба не просит. Проработает
сто лет. А если что и случится – любой Вам ее поправит или дополнит. Такие программы
надо писать самостоятельно. Только приведите мне пример, для каких задач может
быть создана такая программа? Я не смог придумать примера. Может быть, программа,
предназначенная для учета конфиденциальной информации, касающейся движения денег
по нескольким банковским счетам? Но это не уникальная задача. Да и на Excel это
все будет лучше, чем в самодельной программе.

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

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

Здесь есть еще один подводный камень. А что нужно написать? Кто ставит задачу?
Кто ее воспринимает? Если Вы думаете, что Вы способны объяснить программистам,
что от них требуется – это заблуждение. Вы способны только в самых общих чертах
высказать пожелания. И может быть, Вы совершенно не так себе представляете, в
чем Вы действительно нуждаетесь. У программистов должен быть человек, который
должен на основании того, что ему будет предоставлено, правильно разобраться
и поставить задачу. Просто не забывайте, что Вы имеете дело с программистами!
Для них главное – программирование! У них в профессии каждые два года меняются
все инструменты и методы работы. Они должны вкладывать огромные личные усилия
в поддержание своей квалификации и они будут тратить недостаточно сил для того,
чтобы научиться воспринимать задачу от таких, как Вы. Это отдельная профессия
– постановщик задач. Поэтому будьте внимательны. Если задачу ставит «крутой»
программист – разбирающийся во всех современных и не очень технологиях программирования
и базах данных – тут что-то не так.

Но, допустим, написали. Допустим, это были мастера своего дела. Допустим, они
действительно тратили силы не на освоение очередных новшеств в программировании,
повышая свою квалификацию, а работали для Вас над Вашим заданием. Допустим, они
действительно сделали это в разумный срок (то есть у них действительно были большие
собственные  наработки и библиотеки классов, и они писали не с чистого листа).
Допустим, они сделали не только «продажи, закупки и склад» а и «финансы» и «бухучет»
и даже «производство». Это уже сразу скорее похоже не на Ваших собственных специалистов,
а на профессиональных подрядчиков. Откуда бы у Вас взялись такие собственные
специалисты? Если они были, то чего они делали до сих пор и откуда у них такая
квалификация? А может Вы их наняли непосредственно перед началом работ?
Итак, допустим, написали. Что дальше?

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

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

Еще – это очень рисковано.

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

Если систему написали внешние подрядчики – проблемы все те же. Они либо должны
распустить группу, создавшую Вашу систему, либо тянуть из Вас средства на ее
пожизненное содержание. Такое положение будет в тягость обеим сторонам. Разработчики
бывают рады избавиться от ответственности за дальнейшую судьбу написанной ими
системы. Договоритесь с ними о передаче всех материалов проекта Вашим собственным
специалистам. Нет необходимости напоминать, что для полноценной передачи надо
здорово поработать. Документировать, консультировать и проч. Оптимально забрать
материалы вместе с человеком – носителем необходимых знаний и навыков. Приготовьтесь
к тому, что самого «главного» специалиста Вам не отдадут. Да и вообще – люди
ведь не вещи. Их нельзя передавать и перепродавать. Речь идет о том, что, договорившись
с компанией-подрядчиком вначале, Вам следует сделать специалисту предложение,
от которого он не сможет отказаться.

Что еще можно сделать?
Посмотрите, может быть, подрядчики не только для Вас написали эту систему? Может
быть они, написав ее для Вас, пытаются продать ее еще кому-нибудь? Не надо возмущаться!
Наоборот, - это очень подходящий для Вас вариант развития событий.

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

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

К сожалению, чтобы сделать тиражную систему, которую можно тиражировать многим
заказчикам, выпускать новые версии, настраивать на специфику каждого заказчика,
надо сразу делать тиражную систему. Это стоит совершенно других денег. Маловероятно,
что из Вашей заказной системы Ваш подрядчик сможет сделать полноценную тиражную
систему и обеспечить ее качественное сопровождение и выпуск новых версий. Копирование
Вашей системы другим заказчикам чаще всего будет означать, что родился новый
«клон». То есть для каждой отдельной копии программы надо будет проводить отдельные
работы по ее модернизации (обновлению). Соответственно, Вам придется сполна заплатить
за эти работы, а не в складчину с другими коллегами, как Вы надеялись. Единственная
прелесть таких обстоятельств – Ваши подрядчики, чувствуя, что от них попали в
зависимость сразу несколько компаний, для которых может работать одна и та же
группа специалистов, не потеряют интерес и не распустят эту группу.

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

Представьте себе, что Вы заполучили систему – такую, как Вам надо. И не должны
потом решать сложную задачу, как дальше быть с командой разработчиков и дальнейшим
развитием и сопровождением. Это возможно? Да, возможно. Если повезет. Есть один
способ.

Читайте об этом подробнее в следующих выпусках.

Ваш Добрый Автоматизатор,
Лев Тришанков
Пожелания и вопросы направляйте по адресу  lev_t60@hotmail.com
Архив рассылки находится здесь: http://subscribe.ru/archive/trade.zapiskidobrogo/