Стоимость любого товара определяется его полезностью и вложенным в его производство трудом. Стоимость данных как товара возрастает по мере их переработки и передачи на более высокий уровень управления, поскольку возрастает и ответственность за решение, принятое на их основе. Например, информация о возможных перебоях в электроснабжении важна сама по себе, но она приобретает еще большее значение, если используется для согласования с графиком запросов потребителей, от нормального функционирования которых могут зависеть критически важные результаты, вплоть до обеспечения национальной безопасности.
Ясно, что качество данных определяется степенью их достоверности, полноты, целостности и непротиворечивости, а для достижения всего этого требуются затраты, поэтому полезность ИТ-решений определяется экономией средств, которую участники системы управления получат в достижении нужного им качества данных. На практике, в качестве альтернативы ручным операциям, программисты предлагают автоматизированные рабочие места (АРМ), сокращающие время выполнения отдельных административных операций, но не оказывающие серьезного влияния на административные процессы. Для преодоления ограниченности отдельных АРМ программистам необходимо обеспечить их эффективное взаимодействие и снабжение данными в нужном составе и объеме. Производители данных должны уметь координировать свои функции, так чтобы на выходе каждого из них получались данные, не противоречащие данным, созданным другими производителями. Однако в конфликт с этими требованиями вступают коммерческие интересы программистов, считающих, что им следует создавать только такие программы, развивать которые могут лишь они сами.
Действительно, заказчику нужны качественные данные, которые извлекаются и предоставляются с помощью программ, из чего следует, казалось бы, простой и очевидный вывод: хочешь продавать больше компьютеров – стимулируй разработку программ, хочешь увеличивать количество разрабатываемых программ – стремись, чтобы твои программы производили все более качественные данные. На практике же мы видим совсем иную картину.
Компании, поставляющие компьютеры, считают, что спрос на их продукцию стимулируют общеупотребительные коробочные программы. Но такие программы, взятые по отдельности, создают данные самого низкого качества. Более того, их несогласованное использование порождает большой объем разрозненных данных, снижая тем самым и без того невысокое их качество, которое, по убеждению разработчиков программ, должно обеспечиваться пользователями. Но это не так – свои бумаги пользователь может аккуратно разложить по папкам, полкам и шкафам, а что ему делать с огромным объемом данных, генерируемых программами? Редкие программисты заботятся о том, чтобы помочь пользователю решать задачи согласования данных. Хуже того, многие разработчики, в надежде поставить заказчика в зависимость от своих услуг, считают нужным максимально усложнить саму возможность такого согласования. То есть снижают полезность, а значит, стоимость данных, произведенных программами, в глазах заказчика.
Качество данных определяется их целостностью, непротиворечивостью и неизбыточностью. Программисты в лучшем случае считают, что этим критериям должны удовлетворять данные лишь в рамках их собственной разработки, тогда как с точки зрения пользователей этим критериям должна отвечать вся совокупность данных, с которыми они имеют дело. Для сотрудника офиса непротиворечивыми должны быть данные, за которые он несет ответственность. Для начальника отдела целостными и непротиворечивыми должны быть данные всех сотрудников отдела, иначе формирование отчетов превращается в кошмар, несмотря на наличие мощных генераторов отчетов, имеющихся в отдельных программах.
СУБД призваны обеспечивать согласованное ведение и хранение данных отделов, департаментов и организаций, причем независимо от пользовательских программ, однако программисты умудряются дискредитировать эту идею, выпуская программы, неотъемлемой частью которых является СУБД. Это превращает СУБД из мощного средства координации деятельности отделов и организаций в простое хранилище данных для одного или нескольких рабочих мест. В результате несколько программ такого типа создают в организации конфликт СУБД, особенно в том случае, когда разработчики пытаются всячески скрыть структуру и форматы «своих» данных. Такие решения также работают на ухудшение качества данных заказчика.
Одновременно с этим программисты стараются уйти от ответственности за качество данных заказчика, предпочитая создавать отдельные автоматизированные рабочие места, а еще лучше – независимые инструменты обработки данных (редакторы, переводчики и т.д.). В этом им неявно «помогают» сами заказчики, которые хотят иметь информационные системы, способные обеспечить их качественными данными, но при этом редко могут четко сформулировать, что же такое качественные данные.
Ремесло программиста само по себе стимулирует к индивидуальности – сидя один на один с компьютером, программист видит, как материализуются его мысли. «Ты – гений» звучит в его голове, но вот беда: программа, для того чтобы можно было продать ее, должна быть полезна другим людям, которых не интересует то, как ловко был оптимизирован цикл или организован поиск. Люди хотят, чтобы компьютер под управлением программы был им помощником и координатором их действий, а для этого программа должна строиться на знаниях о конкретной предметной области. Однако программисты сознательно или бессознательно пытаются избавиться от необходимости ее изучать, настойчиво требуя от заказчика «качественной» постановки задачи путем представления своих желаний в виде набора визуальных компонентов, формальных операций, а также классификаторов и справочников.
Теперь представьте, что квалифицированный специалист в прикладной области пытается изложить свои знания на языке, который он знает лишь в пределах разговорника. Скорее всего, он ограничится только самыми простыми фразами о простых фактах и операциях. Не осведомлен такой специалист и о врожденных проблемах программирования: низкой производительности, трудностях планирования процесса разработки программ, неизбежности ошибок в программах, необходимости их поиска и исправления. Почти любой заказчик, формулируя требования к программе, оказывается в положении такого специалиста. В результате рождаются АРМ, оптимизирующие выполнение лишь отдельных операций и не затрагивающие административный процесс в целом.
Итак, решающим препятствием является отсутствие у программиста знаний о предметной области заказчика. Пренебрежение этим очевидным фактом проявляется, например, в легкости, с которой программист берется переписать заново уже работающую программу. Уверенность в своей правоте такой программист часто черпает лишь в сносном овладении неким новым средством разработки. Выход в том, чтобы изолировать программиста от заказчика путем введения между ними еще двух действующих лиц: бизнес-аналитика (технолога-постановщика) и системного аналитика (архитектора информационных систем). Однако в отечественной отрасли разработки программ сегодня даже не проглядывается тенденция к разделению труда и развитию отраслевой инфраструктуры. Несмотря на то, что приняты стандарты на профессию, реально, судя по объявлениям о найме, востребованы лишь системные администраторы, операторы (пользователь ПК), Web-программисты, программисты, программист «1С», и все.
Возможно, основная причина такого положения дел с разработкой программ в России кроется в административной системе управления, не воспринимающей современные методы управления и, как следствие, не создающей реальный спрос на соответствующее программное обеспечение, хотя законодательные шаги к этому предпринимались.
Основная идея закона № 94-ФЗ «О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд» – отдать заказ на создание программ разработчикам, которые с меньшими затратами, за меньший срок и за меньшую цену для заказчика, могут выполнить нужные работы с нужным качеством. С рациональной точки зрения заказчик хочет получить доход, который ему обеспечат потребительские свойства или качественные характеристики программы. Заказчик действует в соответствии c функцией выигрыша: доход от внедрения программы минус цена контракта. Функция выигрыша программистов: разница между ценой контракта и затратами на разработку программы. Каждый из участников старается максимизировать свою функцию выигрыша.
Однако реальные условия, в которых применяется закон № 94-ФЗ, отличаются от описанных по крайней мере в двух пунктах: заказчик не пытается построить свою функцию выигрыша, а разработчик не отказывается от участия в конкурсе, даже если цена контракта меньше, чем его затраты. Мотивация заказчика, особенно в лице представителей любого органа власти, почти никогда не бывает рациональной и может включать в себя все, что угодно, кроме желания повысить производительность труда или добиться иной разумно обоснованной цели. Если вообще не заключать контракт, то заказчик получает самый большой выигрыш. С другой стороны, программист может уменьшать состав функций и уровень качественных характеристик программы, обеспечивая при этом максимальный доход, а также повышая вероятность выигрыша в конкурсе за счет отсеивания конкурентов и создавая типовое проектное решение, которое, как ему кажется, затем можно будет тиражировать с незначительными издержками.
Таким образом, в практике применения закона № 94-ФЗ отсутствует механизм, который бы ограничивал снижение цены контракта на разработку программного обеспечения. Отсутствие такого механизма (см. рисунок), во-первых, приводит к нехватке средств для развития у компаний, занятых разработкой программного обеспечения. Во-вторых, создает условия для существования компаний, цель которых победить в конкурсе, получить аванс и исчезнуть. В-третьих, удобряет почву для коррупционных схем. Наконец, первыми на таком рынке гибнут разработчики, желающие работать честно.
Перечисленные явления ведут к разрушению отрасли разработки программного обеспечения автоматизированных систем управления для российских организаций с различными формами собственности, а следовательно, делают эту отрасль не способной к решению задач по реализации таких социально значимых проектов, как «Электронная Россия», «Электронный муниципалитет» и т.д.
***
Традиционное отношение программистов к разработке программ, безусловно, всем сказанным не ограничивается, но главной иллюзией программистов является убеждение в том, что все проблемы отрасли разработки программ носят лишь внешний характер – нечестные конкуренты, недалекие чиновники, неразвитость рынка и т.п. не являются определяющими условиями этой отрасли. Главной ее проблемой в нашей стране является неспособность к самоорганизации и сотрудничеству при решении общей задачи создания рынка разработки современных программ. В этом выводе не стоит усматривать попытку снять ответственность с соответствующих федеральных и региональных министерств (особенно когда создание электронных органов власти возведено в ряд первоочередных задач), которые в своей деятельности должны опираться на отраслевой заказ.
Сергей Гладков (gladkovs@list.ru) – сотрудник компании ООО «Торинс» (Красноярск). Автор работает в области разработки программного обеспечения с 1976 года и имеет опыт выполнения различных должностных обязанностей в вычислительных центрах и компаниях Екатеринбурга, Душанбе и Красноярска.
Управление ИТ-бюджетом
Казалось бы, программное обеспечение довольно легко подвергается изменениям, однако на самом деле это не так. Так же, как и в машиностроении или строительстве, сокращение сроков, пропуск этапов аналитики или проектирования приводит здесь к плачевным результатам.
Диполь Тыугу, или Как преодолеть искажения ИС
Почти в каждом программном проекте заказчик что-то считает очевидным и не упоминает об этом, а разработчик так же молча игнорирует часть требований как абсурдные. Что сделать, чтобы противоречивые точки зрения, упущения и умолчания не исказили систему?
Типовые решения и закон Эшби
Программисты, столкнувшиеся с проблемой неограниченного снижения цены контракта, часто тешат себя надеждой на то, что они создадут и отладят программу для одного заказчика, а затем начнут ее тиражировать в качестве типового проектного решения. Эти надежды были бы оправданны, если бы не различие в понимании типового решения у разработчиков, заказчиков и пользователей. Различие во взглядах на типовое решение у управленцев и программистов приводит к противоречиям в оценке качества созданного программного обеспечения.
Рассмотрим обычный сценарий, который иллюстрирует сказанное. В федеральном министерстве принимается решение о создании автоматизированной системы (например, управления федеральным имуществом). Компания–разработчик программного обеспечения выполнила свои обязательства и предлагает свой продукт для внедрения в субъектах федерации и муниципальных образованиях. Программисты компании исходят из того, что структуры данных позволяют хранить данные независимо от того, относятся ли они к категории федеральных, региональных или муниципальных. По этой причине, а также по причине универсальности алгоритмов обработки данных разработчики считают свой продукт пригодным для использования на любом уровне госуправления. Однако общий принцип преодоления проблемы сложности в системах управления состоит в постоянном уменьшении разнообразия данных решаемой задачи. То есть в региональных системах управления используются более детальные данные, чем в федеральных, что неизбежно приводит к изменениям функциональности программ.
Еще одной преградой к внедрению типовых проектных решений оказывается различный уровень организационной зрелости систем управления, определяемый наличием и степенью формализации деловых операций и процессов, наличием механизмов управления принятием решений на основе заранее утвержденной политики (деловые правила и приоритеты) учреждения. Чем ниже уровень организационной зрелости, тем больше возникает связей и взаимодействий, которые часто значительно усложняют программу.
Возможно, эти рассуждения покажутся слишком оторванными от практики, однако уже только тот факт, что «1С»-программист на рынке труда остается одной из самых востребованных профессий, говорит о том, насколько сложно создать типовое проектное решение даже в столь формализованной и регламентированной области, как бухгалтерский учет. А попытки в среде «1С» управлять архивом БТИ или распределением баллонов с бытовым газом – это уже примеры, когда вера программистов в универсальность используемых ими инструментов приводит их к абсурдным решениям.
Закон Эшби утверждает, что разнообразие управляющей системы должно быть не меньше разнообразия управляемого объекта. А следовательно, разнообразие в данных и функциях типовой автоматизированной информационной системы должно быть не меньше разнообразия состояний любой системы управления, в которой это типовое решение применяется.
