Типичный программист

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

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

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

У нас не было готовой типовой программы для этих подразделений. Тогда с типовыми программами было туго. Даже если бы такая программа появилась, мы запросто могли о ней и не узнать. Интернета не было, а давать рекламу в газетах, радио и на телевидении было не по карману молодым ИТ-компаниям. Поэтому программу для завода нам предстояло написать с нуля.

Первое, что мы сделали – провели обследование этих трех отделов. Результаты зарисовали в виде схем, на которых изобразили основные функции отделов и используемые документы. А также нарисовали стрелочками связи между данными и функциями сотрудников. Собрали образцы всех документов. Тогда еще не были так популярны современные средства формализации требований — разработка моделей «как есть» и «как будет» в case-системах и написание пользовательских историй (use-case). Мы действовали исходя из простого предположения, что раз мы разрабатываем информационную систему, нам нужно знать все о том, кто и какую информацию обрабатывает, и как именно. А рисунки и образцы документов позволяли получить компактное описание системы.

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

«Засада» началась, когда мы приступили к программированию. В этих трех отделах на заводе работало человек 50, каждый рассказал о том, что он делает, и нам надо было написать громадную кучу кода. Товарные и железнодорожные накладные, партионный учет на складе, отгрузка посылками и в контейнерах, учет векселей и других ценных бумаг… Система получалась огромной. А программировать на FoxBase – это вам не в 1С объекты создавать! Каждый справочник, документ и отчет надо было писать как уникальный, вручную. Проработав месяц почти каждый день до глубокой ночи, я задумался. Последнее, что меня окончательно убедило, что мы что-то не то делаем, был случай в январскую ночь. Я приехал на завод в 8 утра, а уезжал в 2 ночи. С утра шел снег, и я с трудом нашел свою машину на стоянке возле завода. Откопал ее. Завел мотор и тут же, через 30 метров, застрял на трамвайных путях, которые просто были не видны под снегом! Мне крупно повезло, что пути ночью чистил специальный трамвай-снегоочиститель. Мужик в кабине поржал немного, увидев мою пятерку на рельсах, прицепил трос и вытащил меня на переезд, откуда я смог выкатиться на шоссе.

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

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

Но деньги все же кончились раньше, чем кодирование. Хорошо, что нам к тому времени было, что показать, и директор завода, хоть и с ворчанием, но подписал дополнительное соглашение. Хороший был руководитель, приходил несколько раз к нам вечером после окончания рабочего дня, наблюдал, как мы работаем. Понимал, что деньги тратятся не впустую. Мы потом еще много раз сотрудничали с ним. Как-то он даже приглашал меня на должность начальника АСУ завода. Но я тогда работал в Сотовой связи и отказался.

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

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

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

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

Напоследок я добавлю только, что наша программа «Свет» положила начало созданию ERP-системы «Лампочки», которая проработала на заводе более двух десятков лет и успешно развивалась собственным АСУ завода.

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

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

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

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

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

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

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

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

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

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

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

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

– А куда еще?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но одной печати счетов было недостаточно для счастья абонентского отдела. Как говорится, вкус приходит во время еды. Запросы к программе росли, и решено было написать вторую версию программы «Абонент», уже для самых современных компьютеров IBM 286.

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

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

Наиль оказал мне еще одну неоценимую помощь. Как-то он увидел структуру таблички «Лицевые счета», которую я создавал в базе данных FoxBase. Она выглядела примерно так:

• Название улицы;

• Номер дома;

• Номер квартиры;

• Номер лицевого счета;

• Фамилия квартиросъемщика;

• ...

– Слушай, – спросил меня Наиль, – ты что, никогда не слышал о третьей нормальной форме?

– Что еще за форма? Почему третья, что с первой и второй? И почему ты думаешь, что у меня форма ненормальная?

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

И он дал мне почитать переводную статью Уильяма Кента, в которой описывались нормальные формы реляционной базы данных – от первой до пятой. После изучения статьи табличка «Лицевые счета» превратилась в пять таблиц – «Улицы», «Дома», «Квартиры», «Жители» и «Лицевые счета», в которых полностью отсутствовало дублирование информации. Теперь улицу можно было переименовать без последствий для домов и лицевых счетов на ней.

Поэтому, когда я встретил Наиля через 20 лет, я сильно удивился. Человек, который так много знал, и сыграл в моей жизни важную роль учителя и наставника, по-прежнему писал программы на FoxBase! Я в то время уже перешел на 1С, создал свою компанию и автоматизировал множество предприятий на этой платформе.

– 1С? Прошу тебя, не рассказывай мне про 1С! Ненавижу эту систему! Она оставила меня практически без работы! Держусь только благодаря двум-трем старым заказчикам! Хочешь, я покажу тебе, какой классный универсальный документ я написал на FoxBase?

Я промолчал. Хорошо, конечно, оттачивать мастерство, создавая все более совершенные программы на старых языках. Но намного лучше идти в ногу со временем, изучая современные платформы. И я еще раз порадовался тому, что платформа 1С не стоит на месте, развивается, седьмая версия, восьмая, веб-сервисы, мобильные приложения, система взаимодействия, работа с большими данными… В каждом релизе появляется что-то новое, и таких релизов выходит несколько в год.

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

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

– У нас никогда не было такой прекрасной программы. Она умеет все! Считает и быстро, и правильно. Правда, в ней не хватает одной небольшой штучки…

– Какой еще штучки?

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

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

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

• Выставление и учет начислений за превышение лимитов по загрязнению окружающей среды;

• Акты за бездоговорное потребление, объем которого рассчитан по времени нарушения и сечению трубы;

• Раздельный учет водоснабжения и водоотведения для бухгалтерии;

• Планирование по статистическим данным за прошлые периоды;

• Счета-фактуры;

• 100 500 новых отчетов...

• … и множество других улучшений, которые я сейчас уже и не припомню.

То есть программа создавалась, сама того не ведая, по модной сегодня идеологии Agile1. Причем, я подозреваю, начальница отдела сбыта «скармливала» мне новые пожелания очень постепенно. Так, чтобы я мог переварить их в период между выставлениями. Вела, скажем так, свой тайный бэклог (список требований). Получался такой спринт длинной в месяц, после которого выходил новый релиз. И релиз этот был вполне рабочий, и внедрялся без проблем.

Ну и, конечно, я не могу не упомянуть тут интерфейс «Абонентов». Он был сделан по образцу программы, которую в то время использовал каждый пользователь Искры-1030, а позднее IBM PC 286, 386 и 486. Это, конечно же, Нортон Коммандер! Как и в прототипе, в «Абонентах» было два экрана. На одном список абонентов, на другом список объектов выбранного абонента. Или на первом карточка абонента, на втором оборотная ведомость со счетами и платежами. И кнопки F2, F3… F10, нажимая на которые можно было открыть нужный объект абонента, счет или платежку. Подсказка по F1, конечно. И никакой мышки, только кнопка Tab для перемещения между полями ввода.

Но все хорошее, когда-нибудь, да и кончается. Через пару лет наступил такой день, когда я вынужден был уйти из Водоканала и сопровождение программы передали другому программисту. Иван много лет развивал программу. Мы с ним часто встречались по работе, и каждый раз он благодарил меня за три вещи: правильную структуру данных, продуманную модульную архитектуру кода и комментарии. За 15 лет, что прожила программа, он внес в нее множество улучшений, и ни одно из них не сломало систему.