Как программисту съесть слона в диспетчерской Водоканала⁠⁠

Здание нашего Водоканала в то время, в самом начале 90-х, было совсем небольшим. В нем не было лишних кабинетов, и вычислительный центр кооператива «Вода» разместили в подвале. В двух комнатках помещались два отдела – программистов и электронщиков. Весь штат вычислительного центра состоял также из двух человек – меня и Гриши. У меня в комнате стоял стол. На столе – мощная машина «Искра 1030» с болгарским винчестером на 10 мегабайт. Гришины полуразобранные компьютеры, паяльники и провода занимали вторую комнатку. Там всегда приятно пахло канифолью и спиртом.

Диспетчерская Водоканала принимала заявки об авариях на сетях и высылала на устранение протечек аварийные бригады. Начальник диспетчерской, Бабушкин Сергей Петрович, проработал в Водоканале всю жизнь. Он наизусть помнил, как проходит под землей каждая труба и что находится в любом колодце. Разбуди его ночью и спроси: «Петрович, дом № 21 по улице Авроры надо отключить. Что делать?», как он тут же ответит: «Придется отключать весь микрорайон. В 51-м колодце упали плашки на задвижке, даже не лезьте туда».

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

Но Сергей Петрович вовсе не гордился своей незаменимостью. Наоборот, понимая, какие риски такая незаменимость несет для всего предприятия, он старался максимально передать свои знания. Одним из способов это сделать он считал создание базы данных сетей и колодцев.

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

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

Реализацию этой задачи Сергей Петрович видел на основе «паспорта колодца». Поскольку все работы и материалы должны были быть привязаны к колодцам. Вот тут у нас с Бабушкиным и вышел принципиальный спор.

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

– Как два реквизита? Да их десятки, если не сотни! Задвижки, трубы… А где будет информация обо всем этом?

– Пока она будет там же, где и сейчас – у вас в Excel-файлах. Если она не нужна на выходе этой задачи, то она не нужна и на входе. Если же мы посадим диспетчеров вводить информацию, которой они не будут пользоваться, у нас будут проблемы. Во-первых, внедрение программы сильно затянется. У вас тысячи этих колодцев. Одно дело – ввести два реквизита, и совсем другое – двести. Паспорта могут вводить несколько месяцев, а то и лет. Во-вторых, диспетчеры будут воспринимать эту работу как бесполезную и найдут кучу причин, чтобы ее не делать. А представляете, каким может быть бюджет этого проекта? Боюсь, так мы и вовсе ничего не внедрим.

– Ну а если завтра мы захотим решать другую задачу? Например, выполнять плановые работы на колодцах? Тогда нам обязательно нужно будет знать, когда именно были изготовлены задвижки и их марки!

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

– И куда мы их введем? У нас что, будет несколько баз данных с одним и тем же колодцем? В каждой задаче свой колодец? У нас тут знаешь сколько задач? Так мы рано или поздно запутаемся во всех этих «недоколодцах»!

– А почему вы решили, что мы всю эту информацию вообще будем вводить именно в «паспорта колодцев»?

– А куда еще?

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

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

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

– Ладно, это я понял. Но ты так и не ответил, что же произойдет с теми реквизитами, которые точно относятся к колодцам? Куда глубину колодца и тип крышки денем?

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

Но видно было, что сомнения у Бабушкина остались. Очень он хотел вести «паспорт колодца» в базе данных, а не в Excel. Но аргументы про сроки и бюджет проекта все же сделали свое дело.

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

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

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

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

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

Вечером я поделился проблемой с Гришей. Гриша почесал макушку и спросил:

– А с ассемблером2 у тебя FoxBase3 дружит?

– Не знаю, я никогда не пользовался такой возможностью.

– Ну ты посмотри, полистай документацию.

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

– Отлично, – сказал Гриша. – Ложись спать, ни о чем не грусти. Утро вечера мудренее.

Утром Гриша продемонстрировал мне великолепный цветной график на всю ширину экрана. То, чего никак нельзя было сделать на FoxBase, прекрасно получилось реализовать на языке, максимально близком к машинным кодам! Еще пару дней мы возились, обеспечивая бесшовную интеграцию программ и мягкий переход из текстового в графический режим работы дисплея.

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

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

Этот рассказ из моей книжки "Франчайзи на грани нервного срыва". Опубликую постепенно из нее все, что подойдет в группу по тематике. Подписывайтесь.