Госпроект "Счастье"

Материал из Eludia
Перейти к: навигация, поиск

Содержание

Работая над этим проектом, мы имели полную возможность ощутить себя фигурами чуть ли не исторического масштаба. Шутка ли сказать: многие месяцы практически все выпуски вечерних новостей на центральных каналах непременно освещали предмет нашей работы. Правда, радости от этого было почему-то немного.

Синопсис

Дано: несколько миллионов условных штук товаров на триллионы денег, доставляемые в соответствии с сотнями договоров от десятков поставщиков по десяткам тысяч адресов.

Требуется: отслеживать поставки в реальном времени. От общего процента до последней строчки спецификации.

Эпизод 1. Демо

Началась эта история, поздней осенью 2005 года. Помнится, в ту пору в дисковых киосках по всему Центру наблюдался странный ажиотаж: сначала вдвое подорожал, а потом и вовсе пропал Проджект. Дело было в том, что именно тогда стал доступен в электронном виде сетевой график Госпроектов на 3 года вперёд. Сотни старших сотрудников внезапно обнаружили, что ни Уорд, ни Эксцель не воспринимают формат доставшегося им файла, а почитать очень хотелось.

Перед Дмитрием тогда встала чуть более творческая задача: импортировать данные упомянутого сетевого графика в свою информационную систему. Поначалу перспективы выглядели несколько сомнительно, но менеджер Чёртов настаивал на том, что это было необходимо в течение суток. По счастью, Проджект имел функцию экспорта в реляционную БД. Получив в распоряжение несколько десятков таблиц, Дмитрий за час-другой нащупал, где лежали нужные наименования и даты, а заодно написал скрипт загрузки, попутно пририсовав несколько полей к уже имевшемуся справочнику Государственных программ. Voilà, теперь любой пользователь справочника мог осведомиться о сроках тех или иных мероприятий.

Мог – но откуда бы взялись эти пользователи? До поры-до времени Институт не имел никакого отношения к Госпроектам, так что справочник жил несколько изолированной жизнью. Руководство положило во что бы то ни стало исправить такое досадное упущение. Оно обязательно хотело получить заказ на разработку БД госпроекта "Счастье". Мощнейшим инструментом захвата рынка мыслилась ошеломляющей красоты демо-версия будущей системы.

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

Дмитрий тогда набросал "правильную" систему: мероприятия-лоты-тендеры-договоры-платежи-накладные – и показывал её кому только можно множество раз, но в ответ получал в основном авторитетное пожимание плечами в комплекте с напоминанием о срочности и важности. Впрочем, поступали и кое-какие конкретные замечания, например: "Нужно, чтобы сразу было видно исполнение всех контрактов", – впрочем, не сильно прояснявшие ситуацию.

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

Последнее оказалось не таким простым делом, как можно было бы предположить. Кусочки DHTML элементов управления в то время были неотъемлемой частью ядра, так что пришлось завести отдельную его версию. В рамках одноразового демо такое ещё можно было себе позволить, но перспектива поддержки многих ветвей продукта, по числу эстетских капризов, вовсе не вдохновляла. Почти полгода спустя, в неделю майских праздников 2006-го, Дмитрий локализует DHTML-вёрстку в отдельный пакет и внедрит простой механизм для его смены.

Так вот, увидев вспученный и позеленевший интерфейс, руководство продемонстрировало неподдельный восторг!

Впрочем, программистам рано было расслабляться, поскольку менее чем за час до решающей презентации поступило новое категорическое требование: чтоб были графики. Не важно чего, но чтобы всё сразу видно. Ну что ж, надо – так надо. менеджер Чёртов нарисовал в высшей степени показательную диаграмму, Дмитрий же прошил её статикой. Готово демо. Успели.

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

Эпизод 2. Две базы

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

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

Заявки

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

Вообще-то, процедура ввода поначалу предполагалась одноразовой, но вскоре приняла итерационный характер. Во-первых, реальные данные неохотно умещались в предусмотренные формуляры. Во-вторых, сама модель данных начала непредсказуемо усложняться. Вот, скажем, выяснилось, что некоторые аппараты можно устанавливать только над мощными магнитами. Замурованными в фундамент. Само собой возникло понятие "готовности помещения", специфические отчёты.

Отработка подобных новостей была бы заурядной программистской рутиной, если бы не специфические требования к срокам. Штатный режим был такой: сначала министерство рассылало по регионам циркуляр по поводу того, какие требуются уточнения, а потом его содержание доводилось до Института, так что на внесение изменений в систему оставалось не более суток. Сочетание недоопрделённых требований, предельно урезанных сроков и обилия удалённых на тысячи километров пользователей создавало некоторую нервозность, которой до "Счастья" не было. Тем не менее, благодаря хорошо отлаженной процедуре зеркалирования системы и установки обновлений, сбоев не возникало.

Контракты

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

Поначалу в систему закладывалась поступательная логика: от сбора заявок через торги к контрактам и поставкам. Если бы данные приходили именно в такой последовательности, то даже при наличии двух независимых БД можно было бы в определённый момент отгрузить заявки с публичного сервера на локальный, сформировать из них лоты и запустить цепочку дальше. Однако в реальности получилось так, что первые накладные потребовалось регистрировать в тот момент, когда блокировку заявок никто гарантировать не мог. Предполагалось, что, скажем, адреса доставки могут ещё меняться и меняться. Контракты утверждены, говорите? Ну так дополнительные соглашения никто не запрещал. Да, спецификации должны быть версионными. А как же?

Синтез

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

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

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

Эпизод 3. Сколько стоит знание

Как мы уже отмечали, "Счастье" – явление необычайно многоплановое. В частности, оно совершенно не ограничивалось поставками. Наряду с ними предполагалось ещё и переобучение специалистов на местах. И тут контракты со спецификациями были совершенно ни при чём, хотя автоматизация, естественно, требовалась.

Первой задачей по академической теме оказался сбор сметы. Надо было собрать с 50 авторизованных центров данные о том, сколько человек и чему они собираются обучить, сколько им требуется на это денег и как конкретно эти деньги будут потрачены. Детализация требовалась весьма подробная. Например, по командировкам требовались не просто количества и суммы, но и названия пунктов назначения, и виды транспорта, и цены на билеты. А поскольку речь шла о бюджетном финансировании, деньги строго делились в соответствии с классификатором расходов. Так, для тех же командировок требовалось учитывать целых 3 отдельных суммы: выплату командировочных (зарплата), цену билетов (транспорт) и оплату гостиницы (прочие расходы). А статья, по которой шли учебные пособия ("приобретение" или "прочие") зависела от того, в своей ли типографии печатал центр методички или заказывал на стороне.

Все эти милые подробности, как всегда, выяснялись по ходу дела, в процессе разработки. Тем не менее, даже несмотря на уже традиционно до неприличия урезанные сроки, Дмитрию это всё до поры до времени казалось интереснейшей головоломкой. Даже не разработка системы как таковая, а оптимизация интерфейсов ввода. Можно ли вообще реализовать всё это нагромождение бизнес-правил так, чтобы оператору не пришлось вводить одно и то же по 3 раза? И чтобы он не имел возможности ввести 3 противоречивых цифры по одному поводу? И, кстати, чтобы в БД наблюдалось хоть какое-то единообразие, а не заводилось по 5 таблиц на каждый новый вид расходов? Оказалось – можно, и без особых проблем.

А вот с чем вышла неприятность – так это с округлением. Когда на очередной эксцель-форме потребовалось распечатать суммы с точностью до десятых долей тысяч рублей, Дмитрий по наивности сделал то, что просили: округлил суммы при выводе. Оказалось, делать-то надо было нечто совершенно иное. Уже несколько позже выяснилось, что Казна принципиально не рассматривает копейки как денежные единицы. И рубли. И десятки тоже. 100 рублей – это казначейский атом. Но исходные данные для смет, тем не менее, собирались с точностью до копеечки. Оказывается, каждое такое слагаемое необходимо было переводить в "тысрубы" (тысячи с точностью до десятых) при каждой операции записи. И отчёты составлять именно из этих, заранее округлённых слагаемых – в противном случае ошибки округления зависели от детализации отчёта, и суммы не сходились – а это практически худшее, что может случиться при подсчёте денег.

Узнав о таких подробностях, Дмитрий тут же ввёл пересчёт на тысрубы и обработал ранее введённые данные, но – увы – делать это надо было раньше. Калькуляции для 3 центров, содержавшие расхождения по суммам, были подписаны и пропечатаны – а это, как известно, перекрывает законы арифметики. Так что пришлось ещё вставлять в программу спички на предмет того, чтобы именно для этих центров во всех отчётах при дальнейшем просмотре суммы воспроизводились в строгом соответствии с утверждёнными ошибками.

После этой истории Дмитрий дописал ядро на предмет автоматического приведения всех числовых аргументов запросов к классу Number::FixedPrecision. Всех проблем это, конечно, не решило, но польза была несомненная.

Эпизод 4. Верховные отчёты

В мае 2006 года поставочный модуль информационной системы "Счастье" работал на полную мощность: сотни операторов со всей страны регистрировали в БД события, связанные с ходом поставок, а десятки министерских сотрудников работали с сотнями отчётов во всевозможных разрезах.

Поток требований на доработку был пропорционален объёму БД: чем больше там накапливалось данных, тем сложнее становились бизнес-правила и, соответственно, тем чаще требовалось обновлять систему для их реализации. Десяток-другой доделок в течение рабочего дня – это была норма. Ясно, что сколь-нибудь серьёзный недочёт в технологии поддержки автоматически привёл бы к коллапсу системы. Но нет, Subversion позволяла легко сводить воедино правки разных авторов, а ядро Eludia обеспечивало смену версии в реальном времени: с задержкой не более секунды.

И тем не менее, руководство института терзал комплекс вины по поводу того, что заказчику показать было, с его точки зрения, нечего. Ну да, сотни источников данных и сотни же отчётов, весь ход триллионных поставок отслеживается до номеров накладных. Ну и что. А показать-то нечего.

Конечно, этот упрёк можно было переформулировать в "ничего не понятно" и зеркально обратить, конкретизировав до "ничего не смыслите". Однако проблема, тем не менее, была налицо, а совершенствование руководства реальным не представлялась. Итак, на повестке дня возник подпроект "Мониторинг поставок for dummies", или, в официальной версии, "Рабочее место руководителя".

Дмитрий поставил себе задачу разработать такой OLAP-образный отчёт, который в исходном состоянии показывал бы только верхний уровень классификатора товаров и суммарные цифры по стране, но за 3-4 клика позволял бы увидеть статистику с фильтрацией и/или группировкой по товару, региону и поставщику – с многочисленными дополнительными опциями. Точнее, таких гиперотчётов было два: один в рублях, другой – в штуках.

Разработка заняла целую неделю, что несколько превзошло первичные прикидки, однако не стоит думать, что это была неделя full time. А торможение было обусловлено необходимостью сводить аналогичные данные из разных таблиц. В частности, рапорты поставщиков ссылались на классификаторы, связанные с контрактами, а рапорты регионов – на классификаторы, унаследованные от когда-то бывшей независимой системы сбора заявок. Обнаружение этого и ещё нескольких подобных обстоятельств толкнуло Дмитрия на некоторый предварительный рефакторинг системы.

Так или иначе, через неделю были готовы не только оба отчёта, но даже дополнительный $_SKIN для руководителя. Основной его смысл был в том, чтобы держать под рукой постоянно открытое на 2 уровня главное меню, состоявшее из ссылок на одни и те же экраны отчётов, только с разными значениями параметров. И ещё там отсутствовала ссылка "Выйти".

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

Ясное дело, никакой руководитель никогда не воспользовался изготовленным для него АРМ. Зато гиперотчёты вошли в обиход среднего звена, а рефакторинг системы оказался весьма не лишним.


History.gif Это статья по истории. Она не имеет ни малейшего практического смысла.
Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Разработчику
Администратору
Инструменты