Почему ИТ оказываются невостребованными и как этому способствуют программисты

«Молчите, проклятые струны!»

Аполлон Майков

Молчите проклятые мысли

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

Треугольники на встречном пути

Не знаю когда впервые при помощи треугольника стали символически обозначать структуру организации, а следом за ней и функции, выполняемые на каждом уровне управления организацией (Рис. 1). Я лишь воспользуюсь этой традицией в дальнейшем изложении, именуя треугольное представление структуры организации треугольником управления.

Рисунок 1
Рис. 1. Символическое представление структуры организации.

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

Рисунок 2
Рис. 2. Парадокс полезности информации в системе управления

Для иллюстрации этого вывода воспользуемся другим треугольником – треугольником полезности. Все предыдущие рассуждения говорят, что вершина треугольника полезности обращена к основанию треугольника управления, а основание треугольника полезности совмещена с вершиной треугольника управления.
Следует иметь в виду, что с помощью треугольника полезности схематично изображается не оценка важности поступающих извне данных, а степень их качества, которая приобретается по мере согласования, обобщения и своевременного предоставления. Так информация о возможных перебоях в электроснабжении очень важна сама по себе, но она приобретает более высокое качество по мере ее согласования с графиком потребности в электроэнергии административных операций и влияния этих операций на критически важные результаты. Не менее важно, чтобы эта информация поступила заблаговременно так, чтобы можно было успеть принять решение, сокращающее отрицательное влияние прекращения электроснабжения на административный процесс.
Такое понимание качества административных данных тесно связано с эффективностью их использования. Так Майкл Хаммер и Джеймс Чампи в своей книге «Реинжениринг корпорации: Манифест революции» в бизнесе приводят следующий пример изменения процесса оформления кредита на приобретение компьютеров, программного обеспечения и услуг производимого «ИБМ Корпорэйшн».
Оформление кредита в «ИБМ Кредит Корпорэйшн»проходило в пять этапов: прием регистрация запроса на кредит; проверка платежеспособности потенциального заемщика; внесение особых условий в типовой кредитный договор; вычисление процентной ставки назначаемой клиенту; подготовка письма решением и отправка торговому представителю. Весь этот процесс отнимал в среднем 6 дней, хотя порой растягивался до двух недель. С целью выяснения причин задержек в два высших менеджера «ИБМ Кредит» взяли один бланк и лично прошли с ним все пять этапов, предлагая персоналу в каждом из подразделений отложить все текущие дела и обработать запрос по всем правилам, исключив лишь время, в течении которого бланк, ожидая своей очереди, обычно пролеживал на столе каждого клерка в стопке документов. В результате подобного «следственного эксперимента» обнаружилось, что на обработку одного запроса требуется 90 минут чистого времени.
В итоге, «ИБМ Кредит» заменила своих специалистов (по проверке платежеспособности, калькуляции цен и т.д.) на работников широкого профиля. Никакой поэтапной пересылки! Рост производительности, достигнутый в итоге описанного перепроектирования процесса, превзошел все ожидания. «ИБМ Кредит» урезала время прохождения запроса до четырех часов. Причем добилась этого без всякого увеличения штата – даже наоборот, появилась возможность несколько сократить число работающих. В то же самое время количество оформленных сделок возросло в 100 раз. Не на 100%, а в сто раз.
Невысокое качество данных на отдельных стадиях (проверки платежеспособности, калькуляции цен и т.д.) определяется, во-первых, большой вероятностью того, что эти данные собраны и переработаны напрасно, т.к. за шесть дней заказчик может передумать брать кредит именно в этой организации или вообще совершать задуманную покупку. Во-вторых, время получения этих данных очень незначительно ( ( 1,5 * 100 )/( 6 * 8 )=3% ) по сравнению со временем, которое затрачивается на взаимодействие межу различными подразделениями и сотрудниками(97%), а поэтому уменьшение времени почти не влияет на своевременность предоставления данных. Уменьшите общее время всех операции полтора часа в два раза, и вы выиграете 45 минут из шести дней. На практике этого выигрыша никто не заметит.
Обычно в качестве альтернативы ручным операциям программисты предлагают так называемые автоматизированные рабочие места (АРМ), которые в лучших своих версиях сокращают время отдельных административных операций, но не оказывают серьезного влияния на весь административный процесс в силу рассмотренных выше причин.

Для тех, кто захотел подробнее ознакомиться с описанным Хаммером и Чампи примером, полный отрывок из книги с описанием этого примера можно найти в приложении к этой статье под заголовком «Пример «ИБМ Кредит»»

Сам с усам

Ремесло программиста стимулирует его быть индивидуалистом. Сидя один на один перед компьютером он видит, как его мысли одна за одной превращаются реальность. Компьютер откликается на каждую его команду, а, когда он достиг цели, то радость и облегчение перемешивается с гордостью. «Ты –гений», звучит в его голове.
Но вот беда, для того, чтобы созданную программу можно было продать она должна быть полезна другим людям, которых совсем не интересует то, как ловко был оптимизировал цикл, организован поиск или улучшен стандартный компонент. Они хотят, чтобы компьютер под управление программы был им помощником, советником, учителем, координатором их действий. Для этого программа должна строиться на знаниях о предметной области ее заказчика, которую программист в начале разработки почти всегда не знает и должен прибегать к помощи других людей
Программисты сознательно или бессознательно пытаются избавиться от необходимости изучать предметную область заказчика. И настойчиво требуют от него «качественной» постановки, т.е. представить свои желания виде набора визуальных компонентов, формальных операций, а также классификаторов и справочников. Некоторые теоретики программирования рассматривали процесс разработки технического задания как лингвистическую задачу, состоящую нескольких технологических этапов, на каждом из которых выполняется перевод с языка предыдущего этапа на язык следующего.
Теперь представьте, что квалифицированный специалист пытается изложить свои знания на языке, который он знает в пределах разговорника. Скорее всего, он ограничится только самыми простыми фразами о самых простых фактах и операциях. Почти любой заказчик перед необходимостью сформулировать требования к программе, оказываются в положении такого специалиста-переводчика. В результате такого диалога обычно рождаются программы, относящиеся к классу автоматизированных рабочих мест. Степень полезности таких программ, как было показано выше, не очень высокая. Но на пути создания полезных программ стоит нежелание и, порой, невозможность программиста разобраться в предметной области, с одной стороны, а с другой стороны такие же нежелания и невозможность заказчика понять проблемы программиста.
Эти проблема часто изображается в форме модели с названием «Диполь Тыугу», которую придумал Энн Харалдович Тыугу, известный благодаря своей книге «Концептуальное программирование» и как разработчик языка ПРИЗ для описания сложных программных комплексов. В исходном варианте диполь (см. Рис. 3) показывает, почему искажается восприятие двух участников проекта ИС: «заказчика» и «программиста». Суть в том, что каждому из них проблемы другой стороны видны «издалека», когда чужое становится мелким, а отчетливо видны детали только своих проблем. В результате чего делается вывод о необходимости третьего действующего лица – аналитика, который изучал бы проблемы предметной области заказчика и переводил бы их на язык программиста.

Рисунок 3
Рис. 3. Рисунок заимствован из статьи Евгения Зиндера, Диполь Тыугу, или Как преодолеть искажения ИС

Затем Евгений Захарович Зиндер, теперь президент Фонда ФОСТАС и директор аналитического бюро «Группа 24» в своей статье «Диполь Тыугу, или Как преодолеть искажения ИС» ввел понятие расширенного диполя Тыугу и предложил ввести два действующих лица: бизнес-аналитика и системного аналитика. «Технолог-постановщик» и «архитектор ИС» — вот другие названия этих специалистов (здесь имеется в виду технология той деятельности предприятия, для поддержки которой строится ИС). (см. Рис. 4)

Рисунок 4
Рис. 4. Рисунок заимствован из статьи Евгения Зиндера, Диполь Тыугу, или Как преодолеть искажения ИС

Итак, главным препятствием к тому, чтобы программист мог работать один, является отсутствие у программиста знаний о предметной области заказчика.

ДПК

ДПК – это своеобразная формула приоритетов потребительского спроса в области информационных технологий. И расшифровывается она так: заказчику нужны качественные данные, данные извлекаются и предоставляются с помощью программ, программы выполняются компьютерами.
Из формулы ДПК следует, казалось бы, простой и очевидный вывод: хочешь продавать больше компьютеров – стимулируй разработку программ, хочешь увеличивать объемы разрабатываемых программ – стремись, чтобы твои программы производили все более качественные данные.
Но это с точки зрения логики… На практике мы видим совсем другую картину. Фирмы, заминающиеся поставкой компьютеров, считают, что спрос на их продукцию достаточно стимулирует общеупотребительные коробочные программы. Но общеупотребительные программы, не объединенные в систему, работают в самом основании нашего треугольника управления, а, следовательно, создают данные самого низкого качества. Более того, несогласованное использование этих программ порождает значительно большее количество несогласованных данных, т.к. производительность труда каждого пользователя увеличивается. Снижая тем самым, тем самым, итак невысокое качество производимых данных.
Разработчики программ, считают, что забота о качестве данных полностью лежит на пользователях. Но, это не совсем так. Свои бумаги пользователь может аккуратно разложить по папкам полкам и шкафам, а что ему делать с огромным объемом данных производимыми им с помощью программ? Редкие программисты заботятся о том, чтобы помочь пользователю решать задачи согласования данных, полученных с помощью различных программ. Хуже того, многие из разработчиков программ в надежде создать зависимость заказчика от своих услуг, считают нужным максимально осложнить саму возможность согласования «своих» данных с данными, произведенными с помощью других программ. То есть снижают полезность, а значит стоимость данных произведенных программами в глазах заказчика.
Как все мы помним из теории баз данных, качество данных определяется их целостностью, непротиворечивостью и неизбыточностью. Причем, если программисты, в лучшем случае, считают, что этим критериям качества должны удовлетворять данные внутри их разработки, то с точки зрения пользователей этим критериям должна обладать вся совокупность данных, с которыми они имеют дело. Для сотрудника офиса непротиворечивыми должны быть данные, за которые он несет ответственность. Для начальника отдела целостными и непроиворечивыми должны быть данные всех сотрудников отдела, иначе формирование квартального и годового отчетов превращается в кошмар, не смотря на наличие мощных генераторов отчетов в составе отдельных разработок.
Для решения задач согласования данных придумана и реализована концепция системы управления базами данных (СУБД), обеспечивающая согласованное ведение и хранение данных отделов, департаментов и организаций независимо от пользовательских программ. Но мы, программисты, дискредитируем и не такие идеи. Мы стали выпускать программы, неотъемлемой частью которых является СУБД. Такое решение превращает СУБД из мощного средства координации деятельности отделов, и целых организаций в простое хранилище данных одного или нескольких рабочих мест. Несколько программ такого создают в организации конфликт СУБД, особенно в том случае, когда разработчики пытаются скрыть структуру и форматы «своих» данных. Т.е. и такие решения работают на ухудшение качества данных заказчика.

ИГРЫ РАЗУМА ВОКРУГ 94-ФЗ

Основная идея закона 94-ФЗ в том, чтобы отдавать заказ на разработку программ на конкурсной основе так, чтобы приоритет имели те программисты, которые эффективнее (с меньшими затратами, за меньший срок), а, следовательно, за меньшую цену для заказчика, могут выполнить нужные работы с нужным качеством.

В целом долю государства на отечественном рынке ИТ компании оценивают в 25-30% и уверены, что оно сохранит за собой роль основного драйвера отрасли.
Госзаказ формирует рынок ИТ в России, CNews Analytics
Федеральный закон за номером 94-ФЗ – это тот закон, на основании которого государственные и муниципальные власти заказывают разработку программных проектов.
Игры разума – это фильм, рассказывающий о жизни Джона Нэша — американского математика, работающего в области теории игр и дифференциальной геометрии, лауреата Нобелевской премии по экономике 1994 года.

 

Немного рассуждений

Попробуем разобраться в том, почему при рациональном поведении игроков конкурс позволяет получить заказчику максимальную выгоду. С рациональной точки зрения заказчик хочет получить доход, который ему обеспечат функциональные характеристики (потребительские свойства) или качественные характеристики готовой программы. Упрощенно говоря будем считать, что после внедрения программы, на каких то счетах заказчика будет зафиксировано увеличение доходной части, или уменьшение расходной части.
Например, муниципалитет может увеличить суммы поступления арендной платы за счет полноты учета земельных участков и иного недвижимого имущества, точности характеристик этих объектов муниципального имущества (например, величины арендуемой площади, правильного соотнесения с местоположением объекта), а также точности и скорости расчета арендной платы. Последнее условие порой имеет решающее значение при работе с должниками.
Так как при большом объеме арендуемых объектов, высокой частоте изменений условий аренды (величины кадастровой стоимости земельного участка, величины ставки аренды недвижимого имущества, ставки рефинансирования ЦБ, и т.д.), скорость и точность расчета величины накопившегося долга имеют решающее значение. Причина заключается в том, что заставить арендатора вернуть долг можно через арбитражный суд, который при наличии любой неточности и даже помарки в расчете задолженности в своем решении принимает сторону должника. Поэтому в результате внедрения программ аренды земель и недвижимого имущества доходы по соответствующим статьям бюджета могут увеличиться от 10 до 100 раз.
В терминологии теории игр заказчик программ действует в соответствии со следующей функцией выигрыша:
Рисунок 5
где Д – доход от внедрения программы, а Ц – цена контракта на разработку программы.
Функция выигрыша программистов при этом
Рисунок 6
где Ц – цена контракта на разработку программы, а З – затраты программиста на выполнение работ.
В нашем рационально-идеальном случае считается, что:
− заказчик рассматривает отсутствие дохода (Д), который можно получить с применением программы, как свои потери;
− заказчик не будет объявлять конкурс, если не ожидает, что через некоторое время значение функции выигрыша (Д-Ц) станет больше нуля;
− подрядчик (программист) откажется от участия в конкурсе, если его функция выигрыша (Ц-З) меньше или равна нулю;
− каждый из игроков хочет, чтобы значение его функции выигрыша было как можно больше.
При этих условиях и заказчику и программисту выгоднее всего заключить контракт, т.к. при его отсутствии потери заказчика равны –Д, а потери программиста равны –(Ц-З). Поэтому заказчику не выгодно устанавливать первоначальную цену контракта, при которой все подрядчики откажутся выполнять работу. И программистам не выгодно сокращать функциональные возможности программы до такой степени, чтобы заказчик не смог достичь цели (Д — Ц>0).
В результате такой взаимной зависимости заказчика и подрядчика возникает рациональный механизм ограничения выбора допустимых стратегий участников этой игры. Необходимость достижения цели выступает в качестве ограничителя заказчика в его желании снизить цену разработки программы, а возможность контроля над степенью соответствия функциональных характеристик программы поставленной цели является ограничителем подрядчика в его желании снизить свои затраты.
Благодаря этим же условиям, заказчик может свести к минимуму свои потери, прибегнув предоставлению к конкурсу на разработку программы. Надежды заказчика в этом случае основаны на том, что у разных разработчиков разный уровень технологической оснащенности и различная степень готовности нужной ему программы. Т.е. различные разработчики в процессе разработки программы понесут разные затраты (З). Существует подрядчик, который может разработать программу с теми же функциональными характеристиками, но за меньшую цену, получив при этом устараивающий его доход.
Рисунок 7
где цена предложенная i-м подрядчиком.
Так как цена minЦi победителя по условиям конкурса меньше цены установленной заказчиком в условиях конкурса, то, таким образом, заказчику удалость еще увеличить функцию своего выигрыша.

Вернемся на землю

Реальные условия, в которых применяется 94-ФЗ отличаются от предполагаемых по крайней мере в двух пунктах: во-первых, заказчик не пытается построить свою функцию выигрыша, во-вторых, подрядчик не отказывается от участия в конкурсе даже если цена контракта меньше, чем его затраты.
Мотивация заказчика программного обеспечения для нужд управления почти никогда не бывает рациональной. Она, эта мотивация, может включать в себя что угодно, кроме желания получить доход, повысить производительность труда или добиться иной рациональной, в смысле теории игр, цели. Идея о том, что офисный труд может приносить доход, не только не приживается в нашем обществе (вспомните расхожие фразы о деятельности офисных служб: «протирание штанов», «перекладывание бумажек», «офисный планктон» и т.д.), но кажется невероятной, а для некоторых людей даже крамольной.

Года 4 назад, один молодой человек защищал диплом по программе написанной, в нашей организации. Я, пытаясь помочь ему понять назначение программы и принцип получения отдачи от ее использования, для этого изложил распространенный в странах США и Западной Европы взгляд на офис как на завод по производству данных (документов) со своим технологическим циклом и производственными операциями. Упоминание об этой концепции на защите диплома привело к тому, что один член комиссии снизил оценку на два балла за абсурдность излагаемого. Другие члены комиссии были менее категоричны, поэтому молодой человек получил «4-ку» за дипломный проект. Но меня все еще гложет чувство вины за это снижение оценки, ведь это я подставил человека под удар агрессивного невежества.


Поэтому, функция выигрыша от внедрения программ в представлении заказчика должна сводиться к экономии невосполнимых затрат, т.е. –Ц в формуле 1. С этой точки зрения, если не заключать контракт вообще, то заказчик получает самый большой выигрыш. И это означает, что величина затрат на разработку программы перестает сдерживать желание заказчика снизить цену контракта.
С другой стороны, программист может уменьшать состав функций и уровень качественных характеристик программы, достигая при этом следующие цели:
− обеспечить максимальный доход за счет снижения величины затрат;
− повысить вероятность выигрыша в конкурсе за счет отсеивания конкурентов, не решившихся на ухудшения функциональности качественных характеристик своих программ.
Стратегии заказчика к неограниченному снижению цены контракта и стратегия подрядчика к снижению затрат за счет уменьшения возможностей и качества разрабатываемой программы взаимно дополняют друг друга, убеждая партнеров по этой игре в правильности своих стратегий. Неограниченное снижение уровня функциональности программы приводит к тому, что ее использование даже теоретически не может привести к образованию дохода у заказчика, что дает основание заказчику еще больше снижать цену следующего контракта. И наоборот, неограниченное снижение цены контракта неизбежно вынуждает подрядчика подумать о сокращении функциональных возможностей разрабатываемой программы.
Таким образом, в существующей практике применения закона 94-ФЗ полностью отсутствует какой либо механизм ограничения снижения цены контракта на разработку программного обеспечения.

Отсутствие такого механизма, во-первых, приводит к отсутствию средств для развития у компаний занятых разработкой программного обеспечения.

Во-вторых, создает условия для существования фирм, цель которых победить в конкурсе, получить аванс и исчезнуть. (Смотри статью «Игры на третьей волне» )

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

В четвертых, первыми на таком рынке гибнут фирмы, желающие «честно» разрабатывать программы.
Все перечисленные выше явления уже привели к разрушению отрасли разработки программного обеспечения автоматизированных систем управления для российских организаций с различными формами собственности некоторых регионов Российской Федерации, в том числе в Красноярском крае.
рисунок 8_2
Рис. 5. Схема влияния цены контракта на состояния отрасли разработки программ.

Все как в известном английском стихотворении в переводе Самуила Маршака:

Враг вступает в город,
Пленных не щадя,
Оттого что в кузнице
Не было Гвоздя!

 

В роли такого гвоздя, в нашем случае выступает, рациональный механизм ограничения цены контракта. Когда объявляется конкурс на поставку промышленных товаров роль такого ограничителя играет набор государственных стандартов (ГОСТов) или технических условий (ТУ). Государственные и региональные стандарты на состав и характеристики частей компьютерных программ могли бы значительно смягчить остроту проблемы. Но, во-первых, это очень трудно сделать, потому что стандарты должны быть описаны на языке технологии производства данных, а для этого нужно, хотя бы, признать, что такое производство существует. Во-вторых, в таких стандартах следует учесть, отраслевые особенности технологических операций по производству данных, что еще усложняет задачу создания таких стандартов. В-третьих, в необходимости таких нормативных актов приходится убеждать соответствующие государственные, краевые, муниципальные структуры, что в одиночку это сделать почти невозможно.

Для проверки соответствия качества поставляемых товаров, выполняемых работ, оказываемых услуг требованиям, установленным государственным или муниципальным контрактом, заказчик вправе привлекать независимых экспертов, выбор которых осуществляется в соответствии с настоящим Федеральным законом.» (Глава 1 статья 9 пункт 12).

 

Поэтому следует пойти другим путем, тем более, что в законе 94-ФЗ есть подсказка для нас, о том как решить проблему отсутствия ограничения на снижение цены контракта. Эта подсказка заключена в фразе «заказчик вправе привлекать независимых экспертов». Из чего следует, что для обеспечения применимости этого положения закона, необходимо, выдвинуть из состава фирм разработчиков команду таких экспертов.

Но одного создания института экспертов недостаточно. На следующем шаге, необходимо объединиться и принять, например, соглашение об обязательности проведения экспертизы качества технических заданий на разработку программного обеспечения, а также соответствия качества готового программного продукта, требованиям технического задания. И в дальнейшем настаивать на том, чтобы требование о необходимости соответствующей экспертизы было включено в текст каждого договора на разработку программного обеспечения.
Закончу этот раздел фразой в стиле Джека Траута, обращенной к разработчикам программного обеспечения, «Объединяйся или умирай».

ТИПОВЫЕ РЕШЕНИЯ И ЗАКОН ЭШБИ

Разнообразие управляющей системы должно быть не меньше разнообразия управляемого объекта.
Росс Эшби. Закон Необходимого разнообразия

Программисты, столкнувшиеся с проблемой неограниченного снижения цены контракта, часто утешают себя надеждой на то, что они создадут и отладят программу для одного заказчика, а затем начнут ее тиражировать в качестве типового проектного решения за деньги с незначительными издержками. Эти надежды были бы вполне оправданы, если бы не различие в понимании типового решения у разработчиков, заказчиков и пользователей. И причина такого различия понимания в том, что каждый из участников процесса создания типового проектного решения управляет своей системой со своим набором состояний или, говоря словами Уильяма Росса Эшби, со своей степенью разнообразия.
Рисунок 9

Различия и сходство разнообразия программ и систем управления

Характеристика разнообразия систем управления

Сложность системы управления характеризуется сложностью объекта управления (Ду — входные и выходные данные) и сложностью структуры управляющей структуры (Оу — служащие, подразделения, а также их взаимоотношения).

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

Характеристика разнообразия программ

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

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

М.Х. Холстед в книге «Начала науки о программах» показал вывел и обосновал формулу измерения длины программы:
Рисунок 10
Т.е. сложность или разнообразие программы определяется числом операторов среды разработки и числом переменных программы.


Количество состояний разрабатываемой программы в предельном случае равняется количеству состояний предметной области умноженному на количество выразительных средств среды разработки (Дп*Оп). При этом множество переменных программы (Дп) соответствует подмножеству состояний автоматизируемой системы управления Ду*Оу.
Следовательно, степень сложности программы всегда в Оп раз выше степени сложности автоматизируемой ей управляющей системы

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

Компания Oracle представила обновленную версию 11g R2 своей СУБД спустя два года после того, как данная версия впервые появилась на рынке. В создании продукта приняли участие около 1,5 тыс. разработчиков, а на его тестирование потрачено 15 млн часов.

Выпущен Oracle 11g R2

 

Пути преодоления проблемы необходимого разнообразия в системах управления

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

Самый общий принцип преодоления проблемы сложности в системах управления состоит постоянном уменьшении разнообразия решаемой задачи. Для этого решение проблемы разбивается на шаги, так чтобы каждый предыдущий шаг уменьшал разнообразие (или упрощал решение) задачи на следующем шаге. Для этого министерства подразделяются на департаменты, отделы, сектора. Деловые процессы разбиваются на операции.
Другими словами, уменьшение разнообразия в системах управления достигается за счет организационных мер таких как разделение труда и ответственности, специализация подразделений и сотрудников, формализация деловых операций и процессов, внедрение механизма управления принятием решений на основе принятой политики (деловых правил и приоритетов) учреждения. Совокупность организационных мер в системе управления определяет уровень ее организационной зрелости.

Управление сложностью программ

Основной подход, применяемый программистами в преодолении сложности программ, состоит в создании и максимальном использовании универсальных структур. Такими структурами могут быть абстрактные алгоритмы, повторно используемая часть программного кода, универсальные структуры данных, и т.д. Само применение таких универсальных структур в программе невольно создает у разработчика впечатление, что его программа универсальна сама по себе, следовательно, может рассматриваться как типовое проектное решение.

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

Как обстоят дела на практике

На практике в процессе разработки программы самыми доступными для разработчика оказываются данные об объекте управления (Ду) и почти недоступными оказываются данные о порядке и правилах исполнения функций внутри самой системы управления (Оу). И поэтому универсальные структуры внутри программы в большей степени ориентированы на описание объекта управления.

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

Второй причиной мешающей готовой программе стать типовым решением является различная степень организационной зрелости систем управления (Оу).в различных организациях. Во-первых, чем детальнее прописаны и формализована деятельность органа управления тем, меньше затраты на разработку автоматизированной системы. И наоборот, чем ниже уровень организационной зрелости тем выше затраты на разработку программного обеспечения.
Так, например, учет муниципального имущества может выполняться специальным органом управления муниципального образования, а может вестись различными отраслевыми органами (имущество образовательных учреждений в отделе образования, имущество больниц поликлиник, в отделе здравоохранении и т.д.). Нет нужды доказывать, что во втором распределенном случае затраты на автоматизацию системы учета имущества окажутся больше чем в первом случае.
Поэтому на пути распространения готовой программы встает различный уровень организационной зрелости как самой организации, так и муниципального образования,, а также субъекта федерации.

Третьей причиной, ограничивающей сферу распространения готовой автоматизированной системы управления, является распределение полномочий между различными уровнями вертикали власти. Так, например, наличие у муниципальных образований полномочий по учету жилого фонда, делает систему учета муниципального имущества отличной от аналогичной системы учета имущества в субъекте федерации.
В статье Ирины Шеян «Успехи муниципальной информатизации», опубликованной в журнале Computerworld Россия за 2002, сообщалось, что пропорция распределения средств на ИТ между федеральным, региональным и муниципальным уровнями выглядит так – 91:6:3. Не трудно догадаться что обоснование такого распределения средств выглядит подобным следующему рассуждению. На федеральном уровне должны создаваться типовые проектные решения, которые затем должны тиражироваться на региональный и муниципальный уровни.
Но это рассуждение противоречит самому назначению вертикали власти, которая с целью решения задач управления страной призвана пошагово уменьшать степень разнообразия при движении от муниципального к федеральному уровню. А, следовательно, федеральный уровень управления не обладает всей полнотой информации, циркулирующей на региональных и муниципальных уровнях, т.е. на федеральном уровне нет всех данных для создания типовых проектных решений.
Из сказанного выше не следует, что типовых решений невозможно создать или что они должны создаваться на муниципальном уровне. Здесь утверждается, что к типовым проектным решениям должны предъявляться более высокие требования, чем к решению разрабатываемому для одного заказчика, иначе вся экономия средств на разработку будет многократно перекрыта затратами на поддержание в рабочем состоянии такого решения.

ЛИТЕРАТУРА

1. Информационное сообщение «О результатах исследования уровня внедрения информационно-коммуникационных технологий в муниципальных образованиях России, проведенного при поддержке ФК УРАЛСИБ Институтом дистанционного обучения Российской академии Государственной службы при Президенте РФ» от 01.07.2008 г.

2. Дэвид Васкевич. Стратегии клиент/сервер. Руководство по выживанию для специалистов по реорганизации бизнеса. К: «Диалектика», 1996.

3. Хаммер М., Чампи Дж. Реинжениринг корпорации: Манифест революции в бизнесе. Пер. с англ. – СПб: Издательство С.- Петербургского университета, 1997. – 332 с.

4. Евгений Зиндер, Диполь Тыугу, или Как преодолеть искажения ИС, // Computerworld Россия 6 апреля 1999, №12(173)

5. Федеральный закон от 21 июля 2005 г. N 94-ФЗ»О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд» (с изменениями от 31 декабря 2005 г., 27 июля 2006 г., 20 апреля, 24 июля, 8 ноября 2007 г., 23 июля, 1, 30 декабря 2008 г., 28 апреля, 8 мая, 1, 17 июля 2009 г.) Принят Государственной Думой 8 июля 2005 года Одобрен Советом Федерации 13 июля 2005 года

6. У. Росс Эшби. Введение в кибернетику. Пер. с англ. – М.: Издательство: КомКнига, 2006. – 432 с.

7. Холстед М.Х. Начала науки о программах. Пер. с англ. – М.: Финансы и статистика,1981. 128с.

8. Стаффорд Бир. Мозг фирмы. Пер. с англ. – М.: Издательство: Едиториал УРСС, 2005. 416с.

9. Ирина Шеян. Успехи муниципальной информатизации,. Computerworld Россия №28-29 от 06.08.2002, место постоянного хранения

Выдержка из книги Хаммера и Чампи Реинжениринг корпорации: Манифест революции в бизнесе.


Пример «ИБМ Кредит»

Первым примером служит «ИБМ Кредит Корпорэйшн», дочерняя компания, принадлежащая целиком принадлежащая «ИБМ», которая будь она независимой – заняла бы достойное место в рейтинге журнала «Форчун» 100 крупнейших компаний сферы услуг. «ИБМ – кредит» занимается финансированием продаж компьютеров, программного обеспечения и услуг производимого «ИБМ Корпорэйшн». Эта область деятельности особенно ценится «ИБМ», поскольку кредитование покупок клиентов чрезвычайно прибыльный бизнес.

В ранние годы свое го существования «ИБМ Кредит» действовала в чисто диккенсовском духе. Когда торговые агенты «ИБМ» на местах звонили с просьбой о кредитовании продаж, они попадали к одному из 14 человек, сидевших за столом в конференц-зале «ИБМ Кредит» в Олд Гринвиче, Штат Коннектикут. Тот, кто отвечал на звонок, регистрировал запрос о финансовой сделке на листке бумаги. Это был первый этап.

На втором этапе другой сотрудник доставлял этот листок наверх, в кредитный отдел, где специалист вводил информацию в компьютерную систему и проверял платежеспособность потенциального заемщика. Затем этот специалист записывал результаты проверки все на том же листке бумаги и отправлял в следующее звено процедурной цепочки – в коммерческий отдел.

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

Далее (этап четвертый) запрос поступал к человеку, занимающемуся калькуляцией цен, который вводил данные в электронную таблицу на своем персональном компьютере, чтобы определить какую процентную ставку надо назначить клиенту. Размер ставки опять же записывался на бумажном бланке запроса, который вместе с другими бумагами попадал в канцелярию, на пятый этап.
В канцелярии администратор превращал всю полученную информацию в письмо, готовое к отправке торговому представителю по «Федерал Экспресс».

Весь процесс отнимал в среднем 6 дней, хотя порой растягивался до двух недель. С точки зрения торгового представителя подобный круговорот был слишком долог, поскольку давал клиенту целых 6 свободных дней, в течение которых тот мог бы или найти иной источник финансирования, или соблазниться предложениями другого продавца компьютеров, или же попросту вообще отменить сделку. Поэтому торговому представителю оставалось только постоянно названивать и взывать: «Где договор на мою сделку, когда же вы, наконец, его подготовите?». Естественно, что никто толком не мог ответить на его вопрос, поскольку запрос застревал в одном из звеньев процедурной цепочки.

Пытаясь усовершенствовать этот процесс, «ИБМ Кредит» предприняла несколько попыток добиться хоты бы каких-то изменений. Например, было решено установать контрольный лист, чтобы в любой момент можно было бы оперативно ответить на вопросы торгового представителя о том, на какой стадии в данный момент находится сделка. Теперь каждый из отделов вместо того, чтобы отправлять бланк запроса дальше по цепочке, должен был возвращать его дальше на контрольный пост, куда изначально поступали звонки с запросами. Таким образом, администрация могла регистрировать завершение каждого этапа оформления кредита, прежде чем посылать бумагу дальше.

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

В конце концов, два высших менеджера «ИБМ Кредит» решили провести мозговую атаку на проблему оформления запросов. Они взяли один бланк и лично прошли с ним все пять этапов, предлагая персоналу в каждом из подразделений отложить все текущие дела и обработать запрос по всем правилам, исключив лишь время, в течении которого бланк, ожидая своей очереди, обычно пролеживал на столе каждого клерка в стопке документов. В результате подобного «следственного эксперимента» обнаружилось, что на обработку одного запроса требуется 90 минут чистого времени, то есть всего полтора часа! А остальное время – теперь оно составляло в среднем семь дней – уходило на пересылку из одного отдела в другой. Тем самым, руководство сумело наконец взглянуть в корень проблемы, которая заключалась в общей организации процесса выдачи кредита. В самом деле, если бы по мановению волшебной палочки производительность каждого работника компании увеличилась вдвое, то чистое время обработки запроса сократилось бы всего на каких-то жалких 45 минут. Таким образом проблема заключалась не в рабочих задачах и не в производительности труда, а в самой структуре процесса. Иными словами, менять надо было сам процесс в целом, а не его отдельные звенья.

В итоге, «ИБМ Кредит» заменила своих специалистов (по проверке платежеспособности, калькуляции цен и т.д.) на работников широкого профиля. Теперь вместо того, чтобы пересылать запрос из отдела в отдел, один сотрудник, так называемый координатор сделки (deal structurer), оформлял его от начала до конца. Никакой поэтапной пересылки!

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

Рост производительности, достигнутый в итоге описанного перепроектирования процесса, превзошел все ожидания. «ИБМ Кредит» урезала время прохождения запроса с семи дней до четырех часов. Причем добилась этого без всякого увеличения штата – даже наоборот, появилась возможность несколько сократить число работающих. В то же самое время количество оформленных сделок возросло в 100 раз. Не на 100%, а в сто раз.

То, чего удалось достичь «ИБМ Кредит» 90-процентного сокращения времени прохождения сделки и роста производительности в 100 раз – полностью соответствует нашему определению реинжениринга. Компания достигла существенного улучшения результативности благодаря радикальному изменению процесса в целом. «ИБМ Кредит» не ломала голову над вопросами: как мы можем улучшить число квот на финансирование и как усовершенствовать практику платеже способности? Вместо этого менеджеры компании спросили себя: как можно усовершенствовать процесс выдачи кредита? Более того, при осуществлении радикальных перемен было поколеблено господствовавшее в «ИБМ Кредит» убеждение, что компания нуждается в специалистах для выполнения отдельных этапов оформления кредита.

Эта статья в сокращенном виде «Разработка программ: проблемы и иллюзии«.

This entry was posted in Блог and tagged , , , , , , , . Bookmark the permalink.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *