Мы идём по тёмному цеху, освещение мерцает, где‑то капает вода, пар свистит, вырываясь из небольшого отверстия в трубопроводе. Старые пульты управления, покрытые пылью, копотью и паутиной. Проходя мимо пультовой, улавливаешь запах сигарет и кофе — верные, вечные спутники оперативной смены. Слева, на высоте метров десяти, работают котлы, издавая звук, схожий с рёвом Роковой горы в самом сердце Мордора. Весь путь пропитан хтоническим ужасом — не хватает только своего Фредди Крюгера или Джейсона Вурхиза. Хотя кто знает, что тут по ночам происходит.
И вот мы приходим к нашему месту «жертвоприношений» — тренажёрному классу для обучения операторов ТЭЦ. За стеной — цех с четырьмя энергетическими котлами БКЗ, за окном — минус 35, а впереди — две недели установки софта, наладки, ввода в эксплуатацию и обучения инструкторов. Хоть и кажется, что вся эта компьютерная техника с красивыми картинками здесь чужеродна…
С чего все началось
Это рассказ о том, как управлять (неуспешно) девятью проектами сразу и побыть и швецом, и жнецом, и на дуде игрецом. Попытка в ироничной, циничной, гипертрофированной и повествовательной манере рассказать о своих факапах и даже попробовать чему-нибудь научиться.
Но начиналось всё весьма позитивно. В какой-то момент старшему инженеру отдела автоматизации и электрики (или Рассказчику) пришёл в голову вопрос: а чего это компания делает только тренажёры для АЭС, ведь есть ещё и ТЭЦ, ГРЭС и другие станции на ископаемом топливе? Почему бы и нет? Открыв для себя потрясающий и удивительный мир закупок и тендеров и начиная погружаться в эту бездну угнетения, я нашёл парочку таких тендеров. Посмотрел ТЗ и с ходу помчался в кабинет к техническому директору: мол, мы это можем сделать. С белым пером в волосах, словно языческий бог, прыгнул в небо гремящий грозами поток. Юношеский задор, помноженный на эйфорию, — и я практически сам подписал себе приговор. Однако до этого ещё пройдёт пара месяцев.
В компании на тот момент начинались смутные времена (без лжецарей и битвы за престол), поэтому новые направления бизнеса и проекты были крайне нужны.
Дисклеймер. Бизнес должен развиваться, создавать новые продукты, услуги, выходить на новые рынки и бла-бла-бла… И генерировать прибыль. Очевидные вещи. Но у технологического бизнеса в нашей стране, как мне кажется, всё очень сложно. Как говорил знаменитый пивовар, ресторатор и банкир, интересные бизнесы — это там, где маржа в 100–200–300, а лучше 100500 процентов. Технологические компании в нашей стране работают с маржинальностью в 10–12 процентов. В таких условиях любые овертаймы и перерасходы бюджета проекта приводят к тому, что прибыль тает на глазах, а поступления новой выручки от контрактов нужно всё больше.
Как говорится, мотивация к развитию новых направлений присутствует де-факто. А тут еще и инициативный сотрудник под рукой. Чем черт не шутит.
В общем и целом, после этого пришлось осваивать сразу несколько смежных специальностей. А именно…
Пресейл
Чтобы не только подаваться на тендеры вхолостую, надо, чтобы о наших продуктах узнали. То есть надо эти самые продукты ещё и показать. Провести презентацию, показать тренажёр, а также ответить на вопросы — и всё это бодро, уверенно и в темпе вальса в присутствии главных инженеров, технических директоров, начальников цехов. Nuff said.
И вроде бы навыки презентации и публичных выступлений есть, и продукт свой я знаю хорошо, а блины — все как один комом. Решение тривиальное: упростить презентацию, сделать демку тренажёра проще и не вываливать на людей всю глубину математических моделей и софта. И, конечно, главное — сделать всё «красиво». Люди любят глазами — это факт.
До глубокой ночи я разрабатывал модели выдачи мощности ТЭЦ: расставлял виртуальные стрелочные вольтметры и синхроноскопы рядом с генератором, рисовал «красивые цифры» на слайдах, чтобы показать товар лицом будущим пользователям. Вот так мы моделируем режим сети, вот это — библиотека блоков релейных защит и автоматики, здесь у нас интерфейс инструкторской станции. Отключаем один из генераторов, включаем систему возбуждения другого, переводим в режим автоматической синхронизации — и машина в сети.
«Не может быть, что вы в реальном времени считаете режимные уравнения, уравнения машин, да ещё и в таком объёме!» — нападали на меня одни, а я им показывал наш САПР и предлагал поработать самим. «Так быстро машину синхронизировать нельзя, это не по инструкции, и вообще в жизни всё по‑другому», — язвили опытные инструкторы. «Так это для целей демонстрации мы ускоряем процесс моделирования. Ну не будем же мы сейчас с вами сидеть и двадцать минут выжидать по инструкции. А лучше вот вам ноутбук — и давайте попробуем вместе поработать».
Тяжело в учении, тяжело и в бою. Проведя с два десятка командировок по просторам необъятной Родины, к концу года мы выиграли девять тендеров на поставку тех самых тренажёров для ТЭЦ. Ещё бы стоимость привлечения клиента посчитать (CAC), но тогда я такого термина ещё не знал. Казалось, невероятный успех — если бы не одно жирное «но»…
Проекты
А кто теперь проекты будет исполнять? Инициатива наказуема, поэтому вперёд и с песней. Осложняло всё ещё и то, что для именно этих проектов сотрудников с нужными компетенциями не хватало. Я мог собрать команду из пяти человек и готов был в условно нормальном режиме выполнить два проекта в срок, но никак не девять. Мало того, что пришлось взяться за менеджерскую работу, — пришлось и много технической работы делать самому: и код писать, и спецификации на серверы и АРМы согласовывать, и вообще побыть таким продукт-оунером одновременно. И швец, и жнец — ну, вы знаете…
И если поначалу всё более-менее получалось, этапы закрывались в срок, и я даже умудрялся снимать заказчикам видеоотчёты о ходе разработки, а не только сухой документацией отбиваться, то к сдаче самих тренажёров неизбежно наступал кошмар.
Яркий управленческий факап я допустил через пару месяцев, когда отправил в командировку двух специалистов принять оборудование совместно с заказчиком, а коллега, отвечавший за доставку, назвал невнятные сроки прибытия груза — и бойцы пару дней прохлаждались, ожидая поставки. Не зафиксировал дату в графике, доверился «уважаемому специалисту» и «хорошему человеку» — и слил часть бюджета на продление командировки.
Критический техдолг
Технологические особенности подходов при создании таких симуляторов заключались в фундаментальной разнице в использовании виртуальных панелей (soft panels) во время процесса обучения. Для аналитических тренажёров АЭС реплика БПУ запускалась один раз при старте обучения и фактически экраны не переключались всю сессию, в то время как в тренажёрах для ТЭЦ вся учебная сессия завязана на частую смену, переходы, открытия и закрытия этих экранных форм. Иными словами, анимационная система тренажёра в одном случае не подходила для использования в других условиях (открытие экранных форм за 300–1000 мс, значительно большее количество виртуальных приборов и ключей).
Наш же софт тихо страдал от «детских болезней» — технического долга. Открытие мнемокадра со 100 приборами занимало до 15 секунд(!).
Пришлось долго профилировать. Задержки распределялись следующим образом:
~2800–3000 мс: уходило на вызов нативного кода через JNI при инициализации сессии обмена данными. Сборщик мусора Java "спотыкался" о границы C++ контекста, вызывая Stop-The-World паузы.
~4000–5000 мс: Двойная интерпретация скриптов. Наш внутренний язык анимации напоминал псевдо-Delphi/Pascal, который был обёрнут в прослойку на Java.
Остальное время: Блокировка Event Dispatch Thread (EDT). Рендеринг тяжелой векторной графики Swing/AWT происходил в том же потоке, что и интерпретация скрипта.
Отдельными приколами стали разбросанные тот тут, то там Thread.sleep() на 2-5 мс, особенно в циклах сборки переменных в список для обмена с сервером. Автора этого чуда найти не удалось, и расследовать с чем он пытался побороться таким методом тоже.
С болячками мы продолжали разбираться постепенно. Первым делом пошла под нож древняя DLL для обмена данными между клиентом и сервером приложений тренажёра. Опытные гуру быстро написали новый сервер поверх TCP/IP и встроили протокол обмена в клиентскую часть.
Дополнительные накладные расходы возникали из-за особенности реализации редактора виртуальных панелей: внутри клиентской программы использовался скриптовый язык и очень медленный его интерпретатор, исторически переписанный с предыдущей версии софта на Delphi и обновлённый до Java. Получалась такая двойная интерпретация. Да и сборщик мусора добавлял непредсказуемых задержек. Так что анимационный движок, таймеры перерисовки и сами элементы пришлось дорабатывать.
Дополнительно написали пару инструкций для разработчиков, как создавать эти самые скрипты анимации: указать максимальный объём кода, выносить все скрипты во внешние файлы (чтобы они один раз загружались при старте клиента, а не при каждом открытии файла), дать рекомендации по настройке таймера перерисовки и таймера обмена данными. В общем — добиться тех самых 300–1000 мс для нагруженных панелей удалось. Наверное, можно и сократить эту задержку, используя UDP-стек, но от этой идеи мы отказались.
Получилась интересная штука. Решение о «переписывании» наследия нулевых на Java с минимальными архитектурными изменениями, чтобы по максимуму сохранить функционал, совместимость файлов и не обучать заново инженеров работе с новым софтом, выглядит как здравая идея руководства. Однако все бенефиты от этого подхода были съедены беспощадным техническим долгом, который пришлось искоренять годами. В итоге (спустя почти 15 лет после старта разработки этого САПРа) пришлось отказаться от этих самых скриптов и использовать новый инструмент рендеринга на JavaFX с предопределёнными типами анимации виртуальных приборов — чтобы ускорить разработку тренажёра и сохранить кроссплатформенность.
Стоит сказать пару слов и о вопросах стандартизации/унификации. Тренажёры уже давно используются в энергетике (в мировой практике, так вообще с 60-х годов прошлого века), но привести техническое задание к стандартизированному виду почти невозможно. Хотя большая часть функциональных и нефункциональных требований была схожа для всех девяти проектов, такие различия, как количество готовых учебно‑методических занятий, видеоинструкций и, конечно, объём моделирования, отличались на порядки: в одном случае достаточно было десяти занятий, а в другом — ста сорока. Очень размытым получается Definition of Done.
Про объем моделирования. Количество коммутационных и, следовательно, автоматики и защит – значительное, типичные цифры под пару сотен листов алгоритмов на проект. Здесь только использовать типовые решения и «дженерики» , как организован процесс разработки такой модели я давно писал здесь.
Как бы побыстрее протестировать все сценарии учебных занятий для тренажера? Как оставить понятные инструкции для обучаемых и руководителя тренировок? Люди постоянно меняются, одни приходят, другие уходят, а функция тренажера останется прежней – обучать специалистов. У нас получилось сделать точные симуляционные модели и исправить систему анимации, но осталось докрутить еще одну функцию – систему учебно-тренировочных занятий (УТЗ). Мы с командой решили совместить этап тестирования и разработку УТЗ следующим образом:
Тест-оператор тренажера, опытный технолог с опытом работы на станции, разрабатывает программу и методику испытаний, фактически создавая сценарий УТЗ.
На этапе тестировании и испытаний, небольшая утилиа, сервер событий, записывает все действия тест-оператора и сохраняет их в файл УТЗ.
Параллельно в этот момент запускается ffmpeg для завхвата экрана и мы получаем видео-инструкцию по прохождению УТЗ, ведь действий в бланке переключений может быть несколько десятков, а перемещаться в между виртуальными панелями щита управления и цеха РЗиА новичку будет непонятно. А тут – готовое видео, посмотри задай вопросы, пройди самостоятельно, а инструктор подскажет.
Файлы действий оператора можно использовать для автоматизированного тестирования, «проиграть» их на тренажерной модели, причем можно это сделать и ночью, а утром проверить отклонения. Так, мы немного ускорили прохождение программы испытаний и подтянули качество.
Все протоколы тренировок сохраняются, и их можно использовать для корректировки программы обучаемых, или интегрировать в корпоративную LMS.
ГОРИМ!
Осень и последующая за ней зима превратились в сплошную череду перелётов. Вылет в 2 ночи понедельника в один северный город, через пару дней — перелёт в следующий, в пятницу возвращаешься домой, субботу тратишь на хоть какое‑то восстановление, а в воскресенье доделываешь либо программу и методику испытаний, либо дописываешь какую‑нибудь модель — и цикл продолжается сначала.
Попахивает дымом — от выгорания. С такой психоэмоциональной нагрузкой мне помогала справляться нагрузка физическая. Это не универсальный совет из сборника «Как брать на себя больше ответственности и не выгореть к чертям», но ситуации разные: мир сложный и опасный, и, чтобы не закипеть и не сгореть, ничего лучше физических упражнений, на мой личный взгляд, попросту нет. Мне нравилось заниматься силовым троеборьем, кому‑то достаточно бегать на дорожке, а кто‑то обожает групповые занятия — но эффект один, и только положительный.
Адаптация технологии под новые проекты, обучение пяти новых сотрудников (трое из которых сбежали через четыре месяца), постоянные командировки на станции — вот такой запуск нового направления. Кстати, о сотрудниках: сбежали они ввиду юного возраста — ведь только что покинули студенческую скамью. Однако двое из них теперь матёрые и крутые инженеры, которые продолжают свой путь в тренажёростроении по сегодняшний день.
Рефлексия
Да, каждый из проектов пришлось доделывать, поскольку гарантийные обязательства никто не отменял. Но на это ушло ещё два года — когда у компании появился дополнительный ресурс как в лице менеджеров, так и технарей, — и теперь стабильно от трёх до пяти тренажёров в год выпускается по этому направлению.
Конечно, нехватка ресурса и организация процессов на тот момент в компании повлияли на сложную реализацию тех проектов. Но отсутствие знаний и опыта сыграло также свою роль. За прошедшие годы я сформировал список книг, которые лучше помогли мне разобраться в менеджменте и применять знания на практике. Я собрал их в этой статье.
И конечно же, выводы:
Планированию надо уделять больше внимания. Скромные возможности нашей внутренней ИСУП в купе с использованием Excel вместо таск-трекера очень быстро превратило стыковку задач между проектами в бардак, а сам проект попал в производственный ад. Ах да, и не верить срокам, которые заявляют разработчики, и основывать на этом план-график – рекомендую ознакомится вот с этим циклом статей от Игоря Ашманова.
Переговоры и умение договариваться. Проджект ты или продакт – а договариваться придется много и со всеми – человеческие взаимоотношения, к сожалению, сложны и запутанны. С начальством – о выделении дополнительного ресурса и согласовывать образ конечного результата(это про продукт), управлять их ожиданиями, с заказчиком – о его ожиданиях, сроках, разногласиях и разночтениях в технических требованиях и заданиях, с командой – о том, какую и кому задачу взять, уговорить поехать в командировку. Этот навык только прокачивать постоянно, и не останавливаться.
«Героическое исполнение проекта», условно, в одиночку – значит масштабировать хаос, а не бороться с ним. Архетип ключевого и незаменимого сотрудника – явный признак того, что система управления организована не верно. Со стороны может показаться, что такая позиция выгодна самому сотруднику, и даже, часто так и есть – но механизм этот работает в две стороны, и вся «незаменимость» выйдет в итоге боком.
Стандартизация ТЗ невозможна там, где физика процесса откровенно плюет на ваши бизнес-процессы. Девять станций имели схожие требования, но декларировать одинаковый объем моделирования от угольной ТЭЦ и ПГУ — всё равно что лечить сломанную ногу и мигрень одним топором.
Бежать за солнцем, игнорируя или не зная о техническом долге – выстрелить себе же по обеим ногам. Эйфория от быстрых побед пройдет, а разбирать бардак все равно кому то придется.
