Как не сойти с ума в разработке систем управления нормативно-справочной информацией. Из истории наших проектов

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

    За иллюстрации отдельное спасибо замечательному художнику Васе Ложкину.


    Случай первый. Как загрузить вагон и маленькую тележку


    Создание единой системы управления контрагентами для крупной производственной компании со множеством заводов по всей стране и за рубежом.

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

    Живая история
    Проект был согласован со всеми заинтересованными сторонами (в этом нас убедило руководство заказчика) и разработан в заданные сроки в соответствии с утвержденными требованиями.

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

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

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

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

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


    Случай второй. Как хотим, так и используем


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

    Цель проекта – создание сводной клиентской базы для использования в аналитических приложениях. База данных собиралась со всех филиалов, данные выверялись, дополнялись, дублирующиеся объекты устранялись. Количество клиентов в одном филиале – от тысячи до нескольких миллионов. При этом, пересечений по клиентам между филиалами практически нет.

    Живая история

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

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

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

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

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

    В результате, за несколько часов нечеловеческих усилий модуль сверки все-таки сформировал файл для загрузки, в который вошли все данные филиала. И, да, этот файл был огромным.

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


    На наши возражения, что модуль сверки не предназначен для начальной загрузки данных, заказчик радостно показал ТЗ и спросил, а где это тут написано? Как хотим, так и используем!

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

    Что мы запомнили: всегда включайте в ТЗ описание ограничений – что ваша система делать не должна. Ну, или создавайте решения, которые учитывают все возможные сценарии использования, что сильно дороже.


    Случай третий. Не слонёнок, а слон, да еще и должен летать


    Создание централизованной системы ведения НСИ для финансовой организации.

    Цель проекта — создание централизованной системы ведения справочников и классификаторов с рассылкой изменений в заинтересованные системы и базы данных. Предоставление доступа внешним системам к справочникам через веб-сервисы нашей системы.

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

    В результате нам пришлось сильно изменить порядок работы системы с этим справочником. Фактически, его ведение осуществляется за пределами системы, а мы только предоставляем интерфейс для его использования. Сейчас мы разрабатываем для нашей системы новые способы работы с очень большими справочниками. Надеемся, что заказчику понравится.

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

    Случай четвертый. Сложный фокус с файлами


    Создание централизованной системы ведения НСИ в крупном банке.

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

    Поскольку в дальнейшем мне придется упомянуть наше собственное решение для управления НСИ, позволю себе небольшое лирическое отступление.

    Подробнее о системе NORMA.
    Задачи наших заказчиков во многом схожи, и мы решили снизить затраты на программные разработки и сократить время проектов, создав собственную универсальную платформу для ведения НСИ и основных данных (Reference Data Management & Master Data Management). Система существует уже более 10 лет, и все эти годы мы в ЛАНИТ ее активно развиваем.

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

    NORMA включает графический построитель запросов и дизайнер отчетов. Кроме работы с собственными справочниками, система позволяет через свой интерфейс просматривать и изменять справочники, которые находятся во внешних, по отношению к ней, базах данных, а также использовать эти справочники в построителе запросов и пакетах экспорта/импорта.

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

    Система может масштабироваться как вертикально, путем увеличения мощности сервера приложений и базы данных, так и горизонтально за счет использования многоузлового сервера приложений, в котором каждый узел или группа узлов отвечает за выполнение отдельной функции. Для хранения НСИ система может использовать Microsoft SQL Server, Oracle или PostgreSQL.

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

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

    Начинаем разбираться. Крутим пакет и так, и этак, пробуем разные варианты представления исходных данных, но ошибку повторить не можем. Обращаемся к заказчику с вопросами, может быть, у пакета импорта есть подключенные программные компоненты, может быть на справочник наложены какие-то дополнительные ограничения, может быть данные не от этого процесса? На все получаем ответ — ничего такого нет, все должно легко загружаться и раньше работало.


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

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

    Случай пятый. Я привыкаю к несовпадениям


    Создание системы управления НСИ в производственной компании.

    Цель проекта – создание системы ведения НСИ в управляющей компании со множеством филиалов, заводов и конструкторских подразделений.

    В этот раз мы дальше нескольких презентаций не продвинулись. Наша система NORMA очень понравилась технарям. Она закрывала все их существующие проблемы. Дальше пришла очередь показывать систему руководству, и вот тут произошел облом десятилетия. Высокий руководитель посмотрел, послушал и сказал: «Мы тут все работаем на продуктах Apple, у них есть определенный стиль, а ваша система в этот стиль не вписывается. Мы ее даже рассматривать не будем».


    Что мы запомнили: заказчики бывают разные, и некоторым вы просто не подходите. Стиль другой.

    Подобные истории случаются в различных проектах. Что интересного было в вашей проектной жизни? Что стало для вас неожиданным уроком? Делитесь в комментариях.

    ГК ЛАНИТ 252,10
    Ведущая многопрофильная группа ИТ-компаний в РФ
    Поделиться публикацией
    Комментарии 13
    • +4
      Главный вывод: всегда все прописывать в ТЗ как можно четче и детализировано, и тщательно проверять (перепроверять) ТЗ на возможность иного толкования заказчиком.
      И да, согласен, нужно налаживать связь и общаться не только с заказчиком, но и с конечным пользователем и учитывать их пожелания и «хотелки», но опять же — в рамках ТЗ.
      Материал классный :)
      • +3
        всегда все прописывать в ТЗ как можно четче и детализировано, и тщательно проверять (перепроверять) ТЗ на возможность иного толкования заказчиком.


        К сожалению, невозможно «взять и единым махом разрешить все проблемы простым способом».

        Подробное ТЗ — никакая не панацея.

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

        В результате можно потратить годы только на ТЗ. Которое все равно потом если и будут читать — то только в случае факапа, чтобы задницу прикрыть. А это явно не та цель, для которой нужно ТЗ.

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

        • +1
          Я полностью согласен с тем, что нельзя прописать в ТЗ детальные требования к каждой функции и каждому процессу. Как правило, ТЗ содержит требования, достаточные для понимания того, что и как должна делать система. Но я твердо убежден, что в ТЗ обязательно должно быть указано, что система делать НЕ должна. Любой заказчик может в процессе реализации сказать, что он бы еще хотел получить вот это и вон то, и что эти функции подразумевались им при написании ТЗ. И возразить что-либо на такие дополнительные требования достаточно сложно по различным причинам. Но если в ТЗ явно указано, что система не будет, например, вести справочник персонала заказчика, то навязать вам бесплатные работы по этому справочнику будет гораздо сложнее.
          • 0
            То для чего система не предназначена по определению гораздо больше, чем то для чего она предназначена, и поэтому прописать в ТЗ ВСЕ для чего она не предназначена вообще не возможно.

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

            Поэтому assumptions лучше прописывать в позитивной форме. На основе знания о вашей системе.

            Например для вашего случая:
            «до начала использования механизма синхронизации данных небходимо провести первоначальную загрузку данных методом А»

            А это прописать в Нефункциональные требования:
            «подразумевается что объём ежедневной передаваемой информации для механизма синхронизации меньше 100000 записей»

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

            Так что ещё один важный вывод из ситцуации который нужно было сделать: Должны быть нормальные взаимоотношения с клиентом, без попыток втоптать друг друга в грязь и/или подставить на деньги.
            • +1
              Конечно, не надо писать в ТЗ все подряд. Вот ограничение, которое Вы указали, как нефункциональное требование, очень подходит для ТЗ. Говоря о том, для чего система не предназначена, я имел в виду набор ограничений и допущений, которые должны быть включены в ТЗ. То, что их надо прописывать в позитивной манере, очень интересное предложение. Мы обычно использовали отрицательную форму: «Система не должна ...», «Система обрабатывает не более ....».
              Что касается отношений с заказчиком, то они, безусловно, должны основываться на взаимоуважении. Причем, отношение к заказчику должно быть уважительным, как при непосредственном общении с заказчиком, так и внутри проектной команды. Очень часто внутри некоторых команд приходилось слышать фразы вроде «Эти идио… (не очень умные люди) опять прислали новые требования!». У нас подобные фразы практически отсутствуют. Уважение к заказчику должно начинаться внутри проектной команды. Заказчик это чувствует.
              • То для чего система не предназначена по определению гораздо больше, чем то для чего она предназначена, и поэтому прописать в ТЗ ВСЕ для чего она не предназначена вообще не возможно.


                Категорически не согласен.
                Моя практика показывает, что метод прописывания ограничений, того, чего не будет сделано — это очень хороший метод.
                Попробуйте.
                Весьма компактно и надежно защищает он недопонимания заказчика и претензий.
            • 0
              По структуре, в само ТЗ все пихать не нужно, согласен. Но в ТЗ можно сделать ссылку на документ, в котором уже будет прописано то, что необходимо. И таким образом разбить ТЗ на составные части, которые будут удобны для восприятия.

              Которое все равно потом если и будут читать — то только в случае факапа, чтобы задницу прикрыть. А это явно не та цель, для которой нужно ТЗ.
              Как исполнителю, ТЗ вас выручит, если заказчик начнет дурить. В принципе, сейчас оно больше всего для прикрытия пятой точки и пишется, чтобы потом не было претензий со стороны заказчика, и соответственно незапланированных трат. Часто встречаюсь с тем, что ТЗ от заказчика, не совпадает с реальными требованиями конечного пользователя, и в итоге напрямую приходится работать уже с пользователем, чтобы понять что ему нужно, и потом все подгонять под ТЗ.
          • +1

            Не в тему, но все же — откуда иллюстрации в статье, кто художник? Есть в них что-то сильное и тяжёлое.


            По теме — упомянутая NORMA — это полностью ваша собственная разработка? С чем вы конкурируете этим продуктом?

            • +2
              кто художник?

              Вася Ложкин

              • +1
                NORMA — это полностью наша разработка. Система предназначена для управления НСИ (общероссийские, ведомственные, отраслевые справочники, реестры) и основными данными компании (контрагенты, договоры, оборудование и т.п.). Конкурируем мы с другими продуктами, предназначенными для управления MDM, например, 1C MDM, SAS MDM, Oracle MDM. Кроме того, сейчас наши потенциальные заказчики начинают рассматривать вместо отдельных систем MDM продукты (наборы продуктов) класса Data Governance (управление корпоративными данными). Мы тоже смотрим в этом направлении и готовим обновления и дополнения для нашей системы.
              • +1
                «Мы тут все работаем на продуктах Apple, у них есть определенный стиль, а ваша система в этот стиль не вписывается. Мы ее даже рассматривать не будем».


                У Apple есть продукты для автоматизации???
                • +2
                  У Apple, конечно, нет продуктов для автоматизации. Просто у заказчика все руководство и многие менеджеры работали на компьютерах Apple, использовали планшеты и телефоны Apple. И речь шла не о функциональных возможностях системы, а об интерфейсе. У нас используется интерфейс в стиле Windows, который на интерфейс Apple не очень похож.
                • +1
                  Прекрасные жизненные кейсы.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое