Каково это - быть разработчиком в России, когда тебе сорок (часть 3)
Начало здесь и здесь.
Разработка и ИТ с приставкой «гос»
По знакомству я устроился в организацию атомной отрасли. Численность ~120 человек, с постепенным ростом количества персонала. Всё ИТ сводилось к серверу 1С и файловому серверу, управляемыми единственным админом, периодически жостко злоупотребляющим алкоголем. 80 компьютеров, одноранговая сеть без домена с черепашьей скоростью и постоянные пропадания компьютеров из сети. Я устроился инженером пуско-наладки: во втором человеке, который бы занимался ИТ, компания, по мнению руководства, не нуждалась.
Полгода я занимался делами отдела пуско-наладки и вдруг сверху спустили разнарядку на изменение структуры предприятия. В новой структуре был предусмотрен отдел информационных технологий. Правда, почему-то, помимо ИТ, в функциях отдела были закреплены работы по метрологическому обеспечению производства. Консультации с авторами структуры показали, что ошибки нет. Админ бухал и, за неимением других кандидатур, я подготовил документы нового отдела, внутренне называя его химерой. Более того, в дальнейшем мне пришлось прикладывать усилия, чтобы за отделом информационных технологий не закрепили ещё и функции экологического надзора, но об этом позже 😂 Ну, короче, как-то так появился ИТ-отдел на моём предприятии, в таком же виде он существует и по сей день...
Какая связь между метрологией, экологическим надзором и информационными технологиями? Самая прямая - мало кто понимает, чем занимаются специалисты этих направлений. Поэтому всякую «неведомую хрень» сваливают в одну кучу, не взирая на здравый смысл. И безумие продолжается: теперь эффективные менеджеры переводят отдел информационных технологий в сметно-договорное подразделение.
Вообще, исторически, в отрасли сложилась парадоксальная ситуация: вроде бы отрасль высокотехнологичная, даже есть группа компаний, занимающаяся супервычислениями. В отрасли есть куча институтов, которые занимаются программными системами, промышленными контроллерами, АСУТП, автоматизацией производственных и непроизводственных процессов и прочими высокотехнологичными вещами. Вместе со всем этим существует когорта управленцев, которые воспринимают компьютерную технику и сети как досадное недоразумение, от которого хотелось бы отмахнуться. У этих управленцев отсутствует понимание того, что на дворе уже другой технологический уклад, и самая важная вещь в современном корпоративном мире - это информационные потоки, для которых нужна инфраструктура, квалифицированные пользователи, разработчики и обслуживающий персонал.
Если же у управленца вдруг возникает понимание необходимости построения ИТ-инфраструктуры, то у него же появляются мечты о том, что всё это возникнет само собой из ниоткуда. Другая крайность - что можно сделать любую информационную систему, просто выпустив распоряжение и выделив крупную сумму из бюджета. В купе с тем, что такие управленцы очень смутно представляют себе всю многогранность ИТ-мира, а познания об ИТ-профессиях у них ограничены названиями «сисадмин» и «тыжпрограммист», то с такими людьми очень трудно работать. Невозможно объяснить, что вчерашнего техника по документации нельзя сделать специалистом по базам данных, а очень хорошего мальчика, за которого ручается сам начальник управления, не научишь работе с сетями (во всяком случае - это не в один момент произойдёт). И тем более невозможно объяснить, что хороший Linux/Win администратор не должен заниматься закупками, договорами и составлением бесконечных отчётов, а программист не сможет ничего внятного написать, параллельно сопровождая бухгалтерию/кадры/сметы/договора, в промежутках крутя АТС, заправляя принтеры и ведя складскую базу оборудования.
Потребительское отношение к ИТ, помноженное на непонимание самого предмета, формирует в отрасли странные перекосы: достаточно простые и хорошо масштабируемые вещи, типа документооборота, стоят для предприятий очень дорого. В то же самое время целевые информационные системы не редко финансируются по остаточному принципу.
Есть ещё один тип управленцев, с которыми действительно можно плодотворно работать - это бывшие инженеры ещё советской закалки, которые ратуют за своё дело, не чураются инноваций, и вместо затягивания процесса продвигают дело вперёд. При этом у них есть видение доступных ресурсов, и нет иллюзий по поводу сроков и затраченных усилий на реализацию проекта, если предоставлена адекватная аналитика.
С такими людьми действительно можно работать. Беда таких управленцев в том, что рядом с ними могут оказаться заводные и бодрые исполнители, которые горят желанием заработать на сложном проекте, тщательно скрывая свою некомпетентность. Получив «добро» и административную поддержку, такие исполнители способны долго водить за нос заказчика, получив на выходе неудобовариваемую кашу.
Ранее я зарекался, что никогда больше не буду работать с 1С. Жизнь внесла свои коррективы. Оказалось, что на предприятии в момент моего поступления не было единых и унифицированных информационных систем по основным направлениям деятельности. По сфере деятельности моего пуско-наладочного отдела для каждого типового проекта было своё самобытное, уникальное учетное ПО, написанное залётными людьми на коленке. Под новый проект тоже необходимо было иметь пакет программ автоматизации деятельности. Можно было продолжить использовать старое ПО, к которому накопилось много претензий, исходники которого исчезли вместе с разработчиками. А можно было сделать всё немного по-другому.
Мне повезло, что рядом со мной работал человек, занимающийся регламентами. В момент моего прихода он как раз разрабатывал регламент на новый проект и я смог скорректировать этот регламент так, чтобы в нём не было прописано названий программных продуктов и не было привязок на конкретные технологии. Я долго и методично убеждал его, что таким вещам не место в регламенте, что регламент должен быть написан безотносительно конкретных программных технологий. Только чистый протокол взаимодействия производственных служб - ничего больше. Это сработало, и был принят регламент, не привязывающий нас к старым информационным системам, и кроме того, на основе этого регламента уже можно было разрабатывать ТЗ и при этом уберечься от буйной фантазии производственников.
Если необходимость наличия регламента по старым традициям ещё понимали, то необходимости в ТЗ на информационную систему (тем более, технического решения) под новый проект никто не видел. Для меня это было удивительно, но я знал, что палец о палец не ударю, пока у меня не будет подписанного ТЗ. Разработчики знают, что ТЗ - это единственный надёжный щит от последующих требований «всё переделать». Поэтому я написал и согласовал ТЗ, которое, по сути, никто не читал кроме меня, но которое несколько раз выручало в дальнейшем.
Никакой другой вменяемой программной платформы, кроме 1С, я найти не смог. Копнул в сторону СПО-шного OOBase, бесплатного Дебет Плюс, подумывал о Qt, потыкался в Лазарус, помедитировал над документаций ExtJs. Но ничего из этого набора не подходило. Да и где бы я нашел специалистов кроме себя, способных сопровождать такую экзотику? Дальше пришлось восстанавливать скиллы по 1С, разбираться с тонкостями написания конфигурации в режиме тонкого клиента. В итоге за несколько месяцев была написана конфигурация 1С, многопроектная и многопользовательская. Сервер был поднят на CentOs Linux + PostgreSQL. Было организовано подключение соответствующих отделов со всех филиалов предприятия к арендованному физическому серверу на магистральном кольце. Да, все это пришлось делать самому на чистом энтузиазме, как говорится «в одно рыло».
А дальше началось самое интересное. Когда система заработала, данные стали вноситься, отчёты стали формироваться, сразу появились люди, которые решили руководить процессом и приложить свою, так сказать, руку к развитию и эксплуатации системы. Так же выяснилось, что система, объединяющая все проекты по направлению, которое она автоматизировала, требуется, ни много ни мало, а на самом верхнем корпоративном уровне для ведения аналитики. В общем, в результате всех блужданий и согласований, учётная система вдруг стала называться отраслевой. Потом из названия исчезло понятие «учёт» и появилось понятие «управление», что явно преувеличивало реальность. У меня сложилось впечатление, что такие загадочные трансформации возникают из-за каких-то флуктуаций Вселенной, за ними не стоит какой-то вполне конкретный человек, а просто так работает система. В ходе всей этой деятельности мне пришлось вместо разработки разъезжать по командировкам, согласовывать свои бумажки и писать бумажки за моих «руководителей». Резко активизировалась служба безопасности, и если ранее никому дела не было до того, где и как размещён сервер, а на мои запросы на правила размещения была отговорка «согласно техническим требованиям», то теперь последовательно выдвигались всё новые и новые требования безопасности (служба безопасности изо всех сил демонстрировала свою значимость), так что мне и моему новому специалисту по сетям пришлось 4 раза переносить серверы на совершенно другие каждый раз площадки.
К моменту опытно-промышленной эксплуатации системы я смог убедить руководство в целесообразности принятия ещё одного специалиста-разработчика, помимо меня. Это было просто смешно: если бы мне сказали, что один человек разработал отраслевую информационную систему, я бы просто не поверил. Так не бывает. Проблема была в том, что этим человеком оказался я. Когда появился второй специалист, мне пришлось заниматься согласованием ввода системы в опытно-промышленную, а затем и в промышленную эксплуатацию. Оценивая сейчас количество бумажек и писем, я могу сказать, что их текст был сопоставим с объемом кода самой ИС. Основная разработка была сделана за несколько месяцев. Согласование же, до промышленной эксплуатации, длилось почти 3 года. Сумма, которая была заработана для предприятия, была очень смешной: примерно одна годовая зарплата тимлида в Москве.
Мы очень рассчитывали на то, что основные суммы сможем заработать на ежегодных договорах по поддержке и развитию системы. Но нет. Традиционно, система была передана на сопровождение карманной ИТ-организации. Ребята не сразу осознали, что им придется столкнуться с Linux-виртуалками и сопровождать БД PostgreSQL, а не весело мышевозить связку 1С+Windows+Microsoft SQL Server. Руководитель стал названивать мне и требовать, чтобы всё было переделано на продукты компании Microsoft, причём именно в тот момент, когда уже начались санкции и в стране был взят курс на импортозамещение. Я прикрылся ТЗ и сообщил ему пункты в отраслевых регламентах, в которых разрешалось использование дистрибутивов Linux для информационных систем. После чего попросил его подумать о стоимости, сроках согласования и сроках реализации такой переделки. Видимо, это взымело действие, и спустя пару недель молчания нам предложили заключить договор на техподдержку. На техподдержку третьей очереди. По факту это означало, что на нас будут сваливать все возникающие проблемы, что бы мы, как разработчики системы, их решали за весьма символическую плату. Мы понимали, что такие информационные системы не работают просто так, их нужно и сопровождать и развивать. Тем более, что первичные данные в неё вводят наши сотрудники по всем площадкам. Поэтому даже на таких условиях согласились. Но дальше дело не пошло: договор на третью очередь должна была инициировать сторона заказчика, но никто этим не стал заниматься и дело спустили на тормозах.
И это был один из немногих моментов, когда мой принцип «программы надо писать хорошо» меня подвёл. Наша информационная система проработала в продакшене без поддержки 3 года на полном автопилоте и продолжает работать сейчас. Трепещите, 1С-хайтеры! Сервера приложений этой платформы способны месяцами работать без перезагрузок, если их, конечно, правильно настроить. Единственный серьёзный технический сбой - это когда спустя год закончилось свободное место на разделе хранилища из-за слишком большого числа сканов документов. Никто у владельцев системы за этим не следил, и когда все встало, мы сами начали названивать чтобы нашли хоть кого-то, кто смог бы увеличить квоту и поднять сервер.
Самое большое, о чём я жалею во всей этой истории, так это о том, что я невольно сработал на управленцев, которых описал в начале главы. В результате моей деятельности я только подкрепил заблуждения таких людей в том, что информационные системы появляются сами собой из ниоткуда, они просто есть и они просто работают. Но ведь так не бывает. Обычно.
Профессиональная деградация
Не каждый разработчик способен работать в таких условиях, в которых пришлось работать мне: вместо разработки - согласования, феерическая бумажная безопасность, составление договоров на поставку и обслуживание, закупка ПО и лицензий… Как, я ещё не сказал? Эффективные менеджеры методично выпускают документы, согласно которым каждый специалист должен заниматься всем спектром всех возможных производственных дел. Это называется вовлеченностью в техпроцесс. Забыт общероссийский классификатор профессий, забыт российский реестр профессиональных стандартов. По мнению менеджеров, каждый сотрудник производственного предприятия должен (пишу по памяти):
Суть в том, что такие службы как бухгалтерия, канцелярия, сметно-договорной отдел, административно-хозяйственный отдел и отдел закупок должны выполнять контролирующую функцию. Вся основная же деятельность перечисленных подразделений должна быть возложена на плечи всех сотрудников предприятия.
ИТ-отделам в этом смысле не повезло больше всех: как бы ни хотели закрыть глаза на такое непонятное и такое ненужное ИТ, а современная жизнь диктует, что всё завязано на ИТ-технологии. Поэтому на каждом предприятии ежегодно заключается около двух десятков договоров по ИТ направлению: различные виды телефонной связи (внутренняя, местная, междугородняя, международная, мобильная), аренда интернета, прочие защищённые/служебные линии, служба доставки (ведь оборудование надо возить), информационные системы типа правовых, ИТС, базы отраслевой технической документации, обслуживание печатной техники, заправка и ремонт картриджей, аттестации по различным видам безопасности, подача отчётности, криптография, банковские системы, закупочные договора по категорийным и мелким закупкам. Ни в каких других подразделениях нет такого количества заключаемых расходных договоров. Нам же ещё «повезло» заниматься метрологией… И если прочитать все требования, выставляемые на сотрудников, и подумать сколько бумаги и подписей надо собрать по каждому договору, с соблюдением всех процедур, и учесть, что отчётные документы по договорам появляются каждый месяц, то станет ясно, что ИТ-отдел вынужден круглый год заниматься совсем не ИТ, а планированием, договорами, закупкой, бухотчетностью, обучением, аттестацией и прочим оформлением Очень Важных Документов.
Кажется, речь раньше шла об ИТ и разработке? Перечитав эту главу, невозможно найти требований, которые действительно относились бы к информационным технологиям и/или разработке. Возможно, дело в том, что ИТ и разработка - это разные вещи, и если бы действительно существовал отдел разработки или отдел информационных систем, то в них всё было бы лучше? Нет, конечно нет. Появившийся год назад отдел разработки программных систем имеет ровно полтора человека с «программистским» прошлым. Вечерами этот полтора человека пишет для заказчика ИС, а днём работает в «поле», производя замеры на оборудовании. Его тоже напрягают всей вышеописанной бюрократией, плюс его очень сильно касается бурная деятельность по безопасности труда. Нас - реже, мы «в поле» только в пики работ и при всяких изменениях сетевой инфраструктуры. Но тоже выполняем все нормы охраны труда: работа на высоте, работа внутри электроустановок, блюдём нормы энергетической отрасли с полным оформлением сопутствующих допусков и прочих документов… Безопасность - это очень хорошо, но когда на её бумажное оформление уходит прорва рабочего времени работника ИТ-отдела, я считаю, что это перебор.
В общем, у меня сложилось впечатление, что вся производственная деятельность регулируется людьми, которые ориентируются в какой-либо своей узкой области, и навязывают свои узкие ориентиры на подконтрольные предприятия и сотрудников. На нас сваливают требования по всему чему угодно: от закупок до энергетических политик, от экзаменов по электробезопасности до требований в области качества и экологии, от норм энергетики до информационного взаимодействия с представителями правоохранительных органов. Я честно пытаюсь всё это барахло понимать и учить. Но я каждый раз с ужасом жду очередных экзаменов. Вдруг я не отвечу на вопрос о технологических системах нормальной эксплуатации и системах безопасности РО или что-то не то скажу про технологические системы поддержания ВХР? А если я неправильно перечислю основные полномочия органов государственной власти РФ, субъектов РФ и органов местного самоуправления в сфере отношений, связанных с охраной окружающей среды? Или, что хуже того, забуду требования к обязательному страхованию ответственности за причинение вреда при эксплуатации опасного производственного объекта? Я смотрю на весь объём документов, которые вписываются в должностные и производственные инструкции, и не понимаю: неужели никто не видит всего этого маразма в количестве требований?! Я не знаю ни одного человека, который способен запомнить такой объём информации...
Таким образом, я потихоньку стал деградировать. Я перестал читать, перестал воспринимать новое, стал забывать многие вещи, которые раньше знал. Я уткнулся в предел возможностей моего мозга: если раньше я без труда мог переварить всякую ненужную дребедень, которую на меня выливали учебные заведения, окружающие меня люди и работодатели, то теперь я стал пробуксовывать. Не имеющей ко мне отношения информации стало так много, что я даже дома часто не могу сразу понять, о чём мне говорят домочадцы. Соответственно, уже не могу читать ни художественную, ни - что важно - техническую литературу: вдумчивого чтения не получается. С опаской вожу машину: уже попадал в ДТП после феерического рабочего дня.
Чтобы совсем не съехать с катушек, я пытаюсь снимать психологическое напряжение инстинктивной деятельностью. Немного помогает музицирование, стараюсь играть с подрастающим поколением в простые игры. Ну а чтобы совсем не потерять навыки, продолжаю вечерами и ночами клепать свои давнишние OpenSource проекты. Да, за счёт собственного здоровья. Но это всё уход от проблемы, а не её решение...
И вот теперь, когда мне сорок, я задаюсь вопросом: а сколько я ещё смогу протянуть в таком режиме? В кого я превращусь через пять, десять лет? Мне скучно общаться со своими коллегами, как с молодыми так и в возрасте: мне с ними не о чем говорить, у меня другая сфера интересов. А то, что окружающие меня сотрудники называют информационными технологиями, к настоящему ИТ имеет очень отдаленное отношение. И, честно говоря, какое мне дело до сроков согласования основных видов отчётных документов, оформляемых по результатам готовности на объектах электро-энергетического производства?
Послесловие
Я долго думал, публиковать ли эту статью. Какая-то она получилась грустная и безнадёжная, прям кризис среднего возраста. Но я надеюсь, что такое настроение больше получилось вследствие когнитивного диссонанса: во всех средствах массовой информации рассказывают о том, что развиваются информационные технологии, что как никогда востребованы ИТ-специалисты, как всё это важно и сложно. Фактически же 95% рабочего времени от меня требуется только умение читать и писать канцелярит.
Но сейчас я понял, что публикацию делать обязательно буду. И вот почему.
Сегодня я сижу и устраняю нарушения, внезапно обнаруженные в моём отделе. Вышли новые правила ведения производственных журналов. Журналы моего отдела, по недосмотру, прошиты синтетической нитью, а нужна грубая нить. И теперь журнал прошивается через три отверстия, а не через два. Это очень важно. А главное - понятно проверяющим органам.
Я чувствую себя средневековым писарем: у меня те же амбарные книги, шило, суровая нитка, железные ножницы, перо для письма и указ Боярской думы. Это то, с чем должен уметь работать специалист отдела информационных технологий. А не с этими вашими компьютерами. Вот и всё, что хотел я рассказать...
Отсюда
Читать ещё материалы по теме:
Мысли молодого инженера
Мысли молодого инженера (часть 2)
Про кризис с молодыми инженерами в России
Про инженеров в России
Почему у нас так всё трудно? Будни малого и среднего бизнеса в России
Разрыв между умными и глупыми нарастает
Россию превращают в страну дураков
Когда утечка «мозгов» автоматически укрепляет «скрепы»
#историижизни
Разработка и ИТ с приставкой «гос»
По знакомству я устроился в организацию атомной отрасли. Численность ~120 человек, с постепенным ростом количества персонала. Всё ИТ сводилось к серверу 1С и файловому серверу, управляемыми единственным админом, периодически жостко злоупотребляющим алкоголем. 80 компьютеров, одноранговая сеть без домена с черепашьей скоростью и постоянные пропадания компьютеров из сети. Я устроился инженером пуско-наладки: во втором человеке, который бы занимался ИТ, компания, по мнению руководства, не нуждалась.
Полгода я занимался делами отдела пуско-наладки и вдруг сверху спустили разнарядку на изменение структуры предприятия. В новой структуре был предусмотрен отдел информационных технологий. Правда, почему-то, помимо ИТ, в функциях отдела были закреплены работы по метрологическому обеспечению производства. Консультации с авторами структуры показали, что ошибки нет. Админ бухал и, за неимением других кандидатур, я подготовил документы нового отдела, внутренне называя его химерой. Более того, в дальнейшем мне пришлось прикладывать усилия, чтобы за отделом информационных технологий не закрепили ещё и функции экологического надзора, но об этом позже 😂 Ну, короче, как-то так появился ИТ-отдел на моём предприятии, в таком же виде он существует и по сей день...
Какая связь между метрологией, экологическим надзором и информационными технологиями? Самая прямая - мало кто понимает, чем занимаются специалисты этих направлений. Поэтому всякую «неведомую хрень» сваливают в одну кучу, не взирая на здравый смысл. И безумие продолжается: теперь эффективные менеджеры переводят отдел информационных технологий в сметно-договорное подразделение.
Вообще, исторически, в отрасли сложилась парадоксальная ситуация: вроде бы отрасль высокотехнологичная, даже есть группа компаний, занимающаяся супервычислениями. В отрасли есть куча институтов, которые занимаются программными системами, промышленными контроллерами, АСУТП, автоматизацией производственных и непроизводственных процессов и прочими высокотехнологичными вещами. Вместе со всем этим существует когорта управленцев, которые воспринимают компьютерную технику и сети как досадное недоразумение, от которого хотелось бы отмахнуться. У этих управленцев отсутствует понимание того, что на дворе уже другой технологический уклад, и самая важная вещь в современном корпоративном мире - это информационные потоки, для которых нужна инфраструктура, квалифицированные пользователи, разработчики и обслуживающий персонал.
Если же у управленца вдруг возникает понимание необходимости построения ИТ-инфраструктуры, то у него же появляются мечты о том, что всё это возникнет само собой из ниоткуда. Другая крайность - что можно сделать любую информационную систему, просто выпустив распоряжение и выделив крупную сумму из бюджета. В купе с тем, что такие управленцы очень смутно представляют себе всю многогранность ИТ-мира, а познания об ИТ-профессиях у них ограничены названиями «сисадмин» и «тыжпрограммист», то с такими людьми очень трудно работать. Невозможно объяснить, что вчерашнего техника по документации нельзя сделать специалистом по базам данных, а очень хорошего мальчика, за которого ручается сам начальник управления, не научишь работе с сетями (во всяком случае - это не в один момент произойдёт). И тем более невозможно объяснить, что хороший Linux/Win администратор не должен заниматься закупками, договорами и составлением бесконечных отчётов, а программист не сможет ничего внятного написать, параллельно сопровождая бухгалтерию/кадры/сметы/договора, в промежутках крутя АТС, заправляя принтеры и ведя складскую базу оборудования.
Потребительское отношение к ИТ, помноженное на непонимание самого предмета, формирует в отрасли странные перекосы: достаточно простые и хорошо масштабируемые вещи, типа документооборота, стоят для предприятий очень дорого. В то же самое время целевые информационные системы не редко финансируются по остаточному принципу.
Есть ещё один тип управленцев, с которыми действительно можно плодотворно работать - это бывшие инженеры ещё советской закалки, которые ратуют за своё дело, не чураются инноваций, и вместо затягивания процесса продвигают дело вперёд. При этом у них есть видение доступных ресурсов, и нет иллюзий по поводу сроков и затраченных усилий на реализацию проекта, если предоставлена адекватная аналитика.
С такими людьми действительно можно работать. Беда таких управленцев в том, что рядом с ними могут оказаться заводные и бодрые исполнители, которые горят желанием заработать на сложном проекте, тщательно скрывая свою некомпетентность. Получив «добро» и административную поддержку, такие исполнители способны долго водить за нос заказчика, получив на выходе неудобовариваемую кашу.
Ранее я зарекался, что никогда больше не буду работать с 1С. Жизнь внесла свои коррективы. Оказалось, что на предприятии в момент моего поступления не было единых и унифицированных информационных систем по основным направлениям деятельности. По сфере деятельности моего пуско-наладочного отдела для каждого типового проекта было своё самобытное, уникальное учетное ПО, написанное залётными людьми на коленке. Под новый проект тоже необходимо было иметь пакет программ автоматизации деятельности. Можно было продолжить использовать старое ПО, к которому накопилось много претензий, исходники которого исчезли вместе с разработчиками. А можно было сделать всё немного по-другому.
Мне повезло, что рядом со мной работал человек, занимающийся регламентами. В момент моего прихода он как раз разрабатывал регламент на новый проект и я смог скорректировать этот регламент так, чтобы в нём не было прописано названий программных продуктов и не было привязок на конкретные технологии. Я долго и методично убеждал его, что таким вещам не место в регламенте, что регламент должен быть написан безотносительно конкретных программных технологий. Только чистый протокол взаимодействия производственных служб - ничего больше. Это сработало, и был принят регламент, не привязывающий нас к старым информационным системам, и кроме того, на основе этого регламента уже можно было разрабатывать ТЗ и при этом уберечься от буйной фантазии производственников.
Если необходимость наличия регламента по старым традициям ещё понимали, то необходимости в ТЗ на информационную систему (тем более, технического решения) под новый проект никто не видел. Для меня это было удивительно, но я знал, что палец о палец не ударю, пока у меня не будет подписанного ТЗ. Разработчики знают, что ТЗ - это единственный надёжный щит от последующих требований «всё переделать». Поэтому я написал и согласовал ТЗ, которое, по сути, никто не читал кроме меня, но которое несколько раз выручало в дальнейшем.
Никакой другой вменяемой программной платформы, кроме 1С, я найти не смог. Копнул в сторону СПО-шного OOBase, бесплатного Дебет Плюс, подумывал о Qt, потыкался в Лазарус, помедитировал над документаций ExtJs. Но ничего из этого набора не подходило. Да и где бы я нашел специалистов кроме себя, способных сопровождать такую экзотику? Дальше пришлось восстанавливать скиллы по 1С, разбираться с тонкостями написания конфигурации в режиме тонкого клиента. В итоге за несколько месяцев была написана конфигурация 1С, многопроектная и многопользовательская. Сервер был поднят на CentOs Linux + PostgreSQL. Было организовано подключение соответствующих отделов со всех филиалов предприятия к арендованному физическому серверу на магистральном кольце. Да, все это пришлось делать самому на чистом энтузиазме, как говорится «в одно рыло».
А дальше началось самое интересное. Когда система заработала, данные стали вноситься, отчёты стали формироваться, сразу появились люди, которые решили руководить процессом и приложить свою, так сказать, руку к развитию и эксплуатации системы. Так же выяснилось, что система, объединяющая все проекты по направлению, которое она автоматизировала, требуется, ни много ни мало, а на самом верхнем корпоративном уровне для ведения аналитики. В общем, в результате всех блужданий и согласований, учётная система вдруг стала называться отраслевой. Потом из названия исчезло понятие «учёт» и появилось понятие «управление», что явно преувеличивало реальность. У меня сложилось впечатление, что такие загадочные трансформации возникают из-за каких-то флуктуаций Вселенной, за ними не стоит какой-то вполне конкретный человек, а просто так работает система. В ходе всей этой деятельности мне пришлось вместо разработки разъезжать по командировкам, согласовывать свои бумажки и писать бумажки за моих «руководителей». Резко активизировалась служба безопасности, и если ранее никому дела не было до того, где и как размещён сервер, а на мои запросы на правила размещения была отговорка «согласно техническим требованиям», то теперь последовательно выдвигались всё новые и новые требования безопасности (служба безопасности изо всех сил демонстрировала свою значимость), так что мне и моему новому специалисту по сетям пришлось 4 раза переносить серверы на совершенно другие каждый раз площадки.
К моменту опытно-промышленной эксплуатации системы я смог убедить руководство в целесообразности принятия ещё одного специалиста-разработчика, помимо меня. Это было просто смешно: если бы мне сказали, что один человек разработал отраслевую информационную систему, я бы просто не поверил. Так не бывает. Проблема была в том, что этим человеком оказался я. Когда появился второй специалист, мне пришлось заниматься согласованием ввода системы в опытно-промышленную, а затем и в промышленную эксплуатацию. Оценивая сейчас количество бумажек и писем, я могу сказать, что их текст был сопоставим с объемом кода самой ИС. Основная разработка была сделана за несколько месяцев. Согласование же, до промышленной эксплуатации, длилось почти 3 года. Сумма, которая была заработана для предприятия, была очень смешной: примерно одна годовая зарплата тимлида в Москве.
Мы очень рассчитывали на то, что основные суммы сможем заработать на ежегодных договорах по поддержке и развитию системы. Но нет. Традиционно, система была передана на сопровождение карманной ИТ-организации. Ребята не сразу осознали, что им придется столкнуться с Linux-виртуалками и сопровождать БД PostgreSQL, а не весело мышевозить связку 1С+Windows+Microsoft SQL Server. Руководитель стал названивать мне и требовать, чтобы всё было переделано на продукты компании Microsoft, причём именно в тот момент, когда уже начались санкции и в стране был взят курс на импортозамещение. Я прикрылся ТЗ и сообщил ему пункты в отраслевых регламентах, в которых разрешалось использование дистрибутивов Linux для информационных систем. После чего попросил его подумать о стоимости, сроках согласования и сроках реализации такой переделки. Видимо, это взымело действие, и спустя пару недель молчания нам предложили заключить договор на техподдержку. На техподдержку третьей очереди. По факту это означало, что на нас будут сваливать все возникающие проблемы, что бы мы, как разработчики системы, их решали за весьма символическую плату. Мы понимали, что такие информационные системы не работают просто так, их нужно и сопровождать и развивать. Тем более, что первичные данные в неё вводят наши сотрудники по всем площадкам. Поэтому даже на таких условиях согласились. Но дальше дело не пошло: договор на третью очередь должна была инициировать сторона заказчика, но никто этим не стал заниматься и дело спустили на тормозах.
И это был один из немногих моментов, когда мой принцип «программы надо писать хорошо» меня подвёл. Наша информационная система проработала в продакшене без поддержки 3 года на полном автопилоте и продолжает работать сейчас. Трепещите, 1С-хайтеры! Сервера приложений этой платформы способны месяцами работать без перезагрузок, если их, конечно, правильно настроить. Единственный серьёзный технический сбой - это когда спустя год закончилось свободное место на разделе хранилища из-за слишком большого числа сканов документов. Никто у владельцев системы за этим не следил, и когда все встало, мы сами начали названивать чтобы нашли хоть кого-то, кто смог бы увеличить квоту и поднять сервер.
Самое большое, о чём я жалею во всей этой истории, так это о том, что я невольно сработал на управленцев, которых описал в начале главы. В результате моей деятельности я только подкрепил заблуждения таких людей в том, что информационные системы появляются сами собой из ниоткуда, они просто есть и они просто работают. Но ведь так не бывает. Обычно.
Профессиональная деградация
Не каждый разработчик способен работать в таких условиях, в которых пришлось работать мне: вместо разработки - согласования, феерическая бумажная безопасность, составление договоров на поставку и обслуживание, закупка ПО и лицензий… Как, я ещё не сказал? Эффективные менеджеры методично выпускают документы, согласно которым каждый специалист должен заниматься всем спектром всех возможных производственных дел. Это называется вовлеченностью в техпроцесс. Забыт общероссийский классификатор профессий, забыт российский реестр профессиональных стандартов. По мнению менеджеров, каждый сотрудник производственного предприятия должен (пишу по памяти):
- Быть инициатором и исполнителем работ по подготовке, оформлению и регистрации проектов документов в отраслевых системах документооборота, согласовывать документы письменно и электронно, определять согласующих и обязательных согласующих проекта документа, определять сроки согласования проектов документов, вести учет карточек проектов документов как исполнитель (кто знает что такое SAP, тот представляет себе этот адъ);
- Выступать инициатором по составлению соответствующего раздела плана мероприятий по заключению в течение планируемого календарного года расходных договоров на поставку требуемой продукции годовой программы закупок, обладать компетенциями по формированию закупочной документации, выраженными в оформлении комплектов документов:
- обоснование максимальной/минимальной цены;
- локальные сметы, выкопировки либо иные сметы или расчёты;
- техническое задание, приложения к ТЗ;
- проект договора с приложением графика поставки продукции;
- графики оплаты и поставки;
- заключение ПДТК и РИО;
- иные документы и приложения, предусмотренные отраслевыми стандартами. - При формировании ТЗ необходимо:
- выставлять требования к качеству, техническим, функциональным характеристикам;
- выставлять требования к потребительским свойствам продукции;
- выставлять требования к безопасности продукции;
- выставлять требования к порядку приёмки продукции и соблюдением иных показателей, связанных с определением соответствия продукции потребностям, требования стандартов, технических условий или иных нормативных документов;
- выставлять требования к подтверждающим документам, которые должны быть предоставлены в составе заявки;
- контролировать требования к количеству, комплектации, месту, сроку, графику поставки - Как инициатор закупочной процедуры, каждый специалист должен запрашивать и обрабатывать технико-коммерческие предложения потенциальных поставщиков на основе которых составляется расчёт начальных цен договоров. Инициатор несёт ответственность за обоснованность определения плановой стоимости закупки, за обоснованность определения и правильность расчёта НМЦ, за соблюдение положений методики расчёта НМЦ при определении стоимости заключаемых договоров;
- Вести деятельность по отражению хозяйственных операций в бухгалтерском учёте предприятия и самостоятельной регистрации закупочных документов по расходным договорам. Выполнять сценарии работы по расходному договору: создавать заявку на закупку для нужд производственного подразделения, вводить первичные бухгалтерские и финансовые документы в систему управления предприятием в бизнес-подразделениях владельцев договоров;
- Оформлять поступление товаров и прочих активов в подразделение (акты), участвовать в комиссиях по приёмке и списанию товаров (акты), обеспечивать документальное оформление ввода/вывода в эксплуатацию оборудования и программного обеспечения (приказы и распоряжения);
- ...и т. д. про соблюдение безопасности, отраслевых политик и много чего прочего...
Суть в том, что такие службы как бухгалтерия, канцелярия, сметно-договорной отдел, административно-хозяйственный отдел и отдел закупок должны выполнять контролирующую функцию. Вся основная же деятельность перечисленных подразделений должна быть возложена на плечи всех сотрудников предприятия.
ИТ-отделам в этом смысле не повезло больше всех: как бы ни хотели закрыть глаза на такое непонятное и такое ненужное ИТ, а современная жизнь диктует, что всё завязано на ИТ-технологии. Поэтому на каждом предприятии ежегодно заключается около двух десятков договоров по ИТ направлению: различные виды телефонной связи (внутренняя, местная, междугородняя, международная, мобильная), аренда интернета, прочие защищённые/служебные линии, служба доставки (ведь оборудование надо возить), информационные системы типа правовых, ИТС, базы отраслевой технической документации, обслуживание печатной техники, заправка и ремонт картриджей, аттестации по различным видам безопасности, подача отчётности, криптография, банковские системы, закупочные договора по категорийным и мелким закупкам. Ни в каких других подразделениях нет такого количества заключаемых расходных договоров. Нам же ещё «повезло» заниматься метрологией… И если прочитать все требования, выставляемые на сотрудников, и подумать сколько бумаги и подписей надо собрать по каждому договору, с соблюдением всех процедур, и учесть, что отчётные документы по договорам появляются каждый месяц, то станет ясно, что ИТ-отдел вынужден круглый год заниматься совсем не ИТ, а планированием, договорами, закупкой, бухотчетностью, обучением, аттестацией и прочим оформлением Очень Важных Документов.
Кажется, речь раньше шла об ИТ и разработке? Перечитав эту главу, невозможно найти требований, которые действительно относились бы к информационным технологиям и/или разработке. Возможно, дело в том, что ИТ и разработка - это разные вещи, и если бы действительно существовал отдел разработки или отдел информационных систем, то в них всё было бы лучше? Нет, конечно нет. Появившийся год назад отдел разработки программных систем имеет ровно полтора человека с «программистским» прошлым. Вечерами этот полтора человека пишет для заказчика ИС, а днём работает в «поле», производя замеры на оборудовании. Его тоже напрягают всей вышеописанной бюрократией, плюс его очень сильно касается бурная деятельность по безопасности труда. Нас - реже, мы «в поле» только в пики работ и при всяких изменениях сетевой инфраструктуры. Но тоже выполняем все нормы охраны труда: работа на высоте, работа внутри электроустановок, блюдём нормы энергетической отрасли с полным оформлением сопутствующих допусков и прочих документов… Безопасность - это очень хорошо, но когда на её бумажное оформление уходит прорва рабочего времени работника ИТ-отдела, я считаю, что это перебор.
В общем, у меня сложилось впечатление, что вся производственная деятельность регулируется людьми, которые ориентируются в какой-либо своей узкой области, и навязывают свои узкие ориентиры на подконтрольные предприятия и сотрудников. На нас сваливают требования по всему чему угодно: от закупок до энергетических политик, от экзаменов по электробезопасности до требований в области качества и экологии, от норм энергетики до информационного взаимодействия с представителями правоохранительных органов. Я честно пытаюсь всё это барахло понимать и учить. Но я каждый раз с ужасом жду очередных экзаменов. Вдруг я не отвечу на вопрос о технологических системах нормальной эксплуатации и системах безопасности РО или что-то не то скажу про технологические системы поддержания ВХР? А если я неправильно перечислю основные полномочия органов государственной власти РФ, субъектов РФ и органов местного самоуправления в сфере отношений, связанных с охраной окружающей среды? Или, что хуже того, забуду требования к обязательному страхованию ответственности за причинение вреда при эксплуатации опасного производственного объекта? Я смотрю на весь объём документов, которые вписываются в должностные и производственные инструкции, и не понимаю: неужели никто не видит всего этого маразма в количестве требований?! Я не знаю ни одного человека, который способен запомнить такой объём информации...
Таким образом, я потихоньку стал деградировать. Я перестал читать, перестал воспринимать новое, стал забывать многие вещи, которые раньше знал. Я уткнулся в предел возможностей моего мозга: если раньше я без труда мог переварить всякую ненужную дребедень, которую на меня выливали учебные заведения, окружающие меня люди и работодатели, то теперь я стал пробуксовывать. Не имеющей ко мне отношения информации стало так много, что я даже дома часто не могу сразу понять, о чём мне говорят домочадцы. Соответственно, уже не могу читать ни художественную, ни - что важно - техническую литературу: вдумчивого чтения не получается. С опаской вожу машину: уже попадал в ДТП после феерического рабочего дня.
Чтобы совсем не съехать с катушек, я пытаюсь снимать психологическое напряжение инстинктивной деятельностью. Немного помогает музицирование, стараюсь играть с подрастающим поколением в простые игры. Ну а чтобы совсем не потерять навыки, продолжаю вечерами и ночами клепать свои давнишние OpenSource проекты. Да, за счёт собственного здоровья. Но это всё уход от проблемы, а не её решение...
И вот теперь, когда мне сорок, я задаюсь вопросом: а сколько я ещё смогу протянуть в таком режиме? В кого я превращусь через пять, десять лет? Мне скучно общаться со своими коллегами, как с молодыми так и в возрасте: мне с ними не о чем говорить, у меня другая сфера интересов. А то, что окружающие меня сотрудники называют информационными технологиями, к настоящему ИТ имеет очень отдаленное отношение. И, честно говоря, какое мне дело до сроков согласования основных видов отчётных документов, оформляемых по результатам готовности на объектах электро-энергетического производства?
Послесловие
Я долго думал, публиковать ли эту статью. Какая-то она получилась грустная и безнадёжная, прям кризис среднего возраста. Но я надеюсь, что такое настроение больше получилось вследствие когнитивного диссонанса: во всех средствах массовой информации рассказывают о том, что развиваются информационные технологии, что как никогда востребованы ИТ-специалисты, как всё это важно и сложно. Фактически же 95% рабочего времени от меня требуется только умение читать и писать канцелярит.
Но сейчас я понял, что публикацию делать обязательно буду. И вот почему.
Сегодня я сижу и устраняю нарушения, внезапно обнаруженные в моём отделе. Вышли новые правила ведения производственных журналов. Журналы моего отдела, по недосмотру, прошиты синтетической нитью, а нужна грубая нить. И теперь журнал прошивается через три отверстия, а не через два. Это очень важно. А главное - понятно проверяющим органам.
Я чувствую себя средневековым писарем: у меня те же амбарные книги, шило, суровая нитка, железные ножницы, перо для письма и указ Боярской думы. Это то, с чем должен уметь работать специалист отдела информационных технологий. А не с этими вашими компьютерами. Вот и всё, что хотел я рассказать...
Отсюда
Читать ещё материалы по теме:
Мысли молодого инженера
Мысли молодого инженера (часть 2)
Про кризис с молодыми инженерами в России
Про инженеров в России
Почему у нас так всё трудно? Будни малого и среднего бизнеса в России
Разрыв между умными и глупыми нарастает
Россию превращают в страну дураков
Когда утечка «мозгов» автоматически укрепляет «скрепы»
#историижизни