Прежде чем поведать историю нашего уникального — не побоюсь этого слова — эксперимента, стоит прорисовать фон. Фон, на котором разворачивается драма IT в отечественном судостроении.
Я не буду ссылаться на аналитические отчёты. Только личный взгляд, семь лет в отрасли. Работал с тремя верфями, все как по копирку — одна школа — старая школа.
Картина «мертвой воды». Инвестиции в IT— призрачны, их нет даже на бумаге, как следствие, перспективы — туманны. Всё дело в среде, лишённой здорового соперничества. Рынок разделён: одни живут в тепличных условиях госзаказов, другие выживают, демпингуя на обочинах. Быть лучше соседа здесь никому не нужно.
Одна красноречивая картинка, которая стоит всех графиков.
Эта система была бы идеально сбалансирована в своём застое. Пока в ней не появились мы. А дальше — история.
Глава первая: цепочка событий
Итак, череда событий — то ли случайных, то ли предопределённых — собрала нас под крышей прекрасной компании «Н». Наш коллектив получил удивительную генетику: мать — русская смекалка и авральный энтузиазм, отец — иностранная дисциплина и педантичность. Со стороны, знаю точно, мы выглядели весьма экзотично.
Работы — глубокое море, людей — считанные единицы. Каждый был и швец, и жнец, и на дуде игрец. Но главным сокровищем была та самая, почти мифическая атмосфера стартапа: воздух свободы, пахнущий крепким кофе и дерзкой идеей. Мы хотели выделяться — и делали это по всем направления. В общем, то время до сих пор отзывается у меня в душе тёплой вол��ой ностальгии.
Компания росла. А вместе с ней цвел пышным цветом и хаос от всего этого бурлящего разнообразия. Стало ясно: наше плодотворное «броуновское движение» пора облекать в какие-никакие, но формы. Мы принялись с энтузиазмом внедрять разнообразный софт — который помогает для организации труда. И быстро поняли: рынок информационных систем оказался не готов к появлению такого… прогрессивного организма, как наше КБ. Готовых решений для нас он попросту не приготовил.
Первой ласточкой стал Bitrix 24. Какие-то «знакомые знакомых» так сладко насвистывали о его всесильности, что мы клюнули. Очень скоро выяснилось: система, заточенная под воронку продаж, безнадёжно хромает, когда дело касается выпуска тысяч листов конструкторской документации.
Следом был старый, добрый Redmine. Он продержался достойно, покуда не встал ребром вопрос серьёзной кастомизации и сращивания его с нашими САПР системами. Специалистов по Ruby под рукой не оказалось, а погружаться в этот цифровой нафталин желания совсем не было.
П��рвая головная боль была очевидна: наладить процессы выпуска документации, сделав их прозрачными для всех — от инженера до гендира. Нас было уже под шестьдесят душ, и договариваться «на пальцах» или через бесконечные «эксельки» — это, знаете ли, уже «ну такое»…
По сути, требовался простой таск-менеджер, коих на рынке пруд пруди. Но дьявол, как водится, в деталях - нас пруд не устраивал, нам нужно было море, да поглубже. Сделать какой либо софт удобным для наших корабела — задача не для слабых духом. И как мы уже поняли позже количество логики и функционала, которое в итоге наросло на этот модуль, затмило собой всё остальное. И это закономерно: инженеры пользуются им ежедневно. Через него идёт вся работа, отслеживаются сроки, горят статусы, кипят разборки в комментариях.
У нас конечно же было где вдохновиться, мы смотрели какая есть функциональность у других и как водится брали все самое, лучшее на наш взгляд.
Все процессы компании, связанные с разработкой документации, были оцифрованы в виде задач, каждый со своим уникальным жизненным путем. Для поддержания качества данных в системе пользовате��ьские действия были ограничены ролью в задаче и ее текущим состоянием.
Кстати, чем наш таск-менеджер уж точно отличало от остальных это модель пользователей для каждой задачи, обычно их два: автор и исполнитель. У нас же их было три: автор – тот, кто создал задачу, например на разработку документа, обычно это руководитель проекта. Автор же назначал, вторую роль ответственный – это то кто отвечал за реализацию задачи, обычно это руководитель отдела. Далее ответственным уже назначался непосредственный исполнитель – это третья роль. Такая логика позволяла не засорять доски с задачами, каждый видел только то, что ему нужно видеть.
Любопытный эксперимент на этом пути — внедрение BPM-движка Camunda. Потратили на его внедрение месяца три после чего благополучно отказались, в нашем случае он оказался абсолютно избыточной надстройкой. При каждом изменении процесса, коих было очень много, мы сталкивались с невероятной болью в одном месте. По сути, хватило простого, но продуманного workflow, который реализовали на базе простой таблички. Делали его почти на ощупь, интуитивно. Как выяснилось позже, получился аналог Jira (тем, кто в теме), только без графического интерфейса.
Главный урок той поры: мы так увлеклись «что делать», что почти забыли подумать «кто и как». О ролевой модели и разграничении прав вспомнили позже, когда пришлось с ломом и зубилом переделывать уже готовые механизмы.
Глава вторая: сохрани чертежи навсегда
Следующей вершиной, которую предстояло покорить, стала организация хранилища для плодов труда нашего доблестного коллектива. На каждый проект рождались тонны документации всех мастей и калибров. Её нужно было не просто складировать, а хранить с умом: классифицировать, версионировать, согласовывать и отправлять заказчику.
Чтобы вы, дорогой читатель, в полной мере оценили масштаб нашего «подвига», озвучу красноречивый факт. Корабелы в 2025 году зачастую оперируют документами в аналоговом виде, с живыми подписями и синими печатями. Те, кто прогрессивнее, используют FTP-сервера — этакий цифровой аналог почтового голубя. Ну а если кто заикается об облачных технологиях — так это и вовсе запредельный космос.
В нашем же случае документация, загруженная инженером, не просто ложилась в папку. Она обрастала метаданными: специализация, категория, версия, автор и многое другое. Всё это отображалось в едином окне, создавая полную, прослеживаемую историю жизни каждого чертежа, каждого расчёта. Более того, наши контрагенты могли подписаться на уведомления — и будьте уверены, они тут же узнавали о новой ревизии документа интересующей их специализации. Это был не просто архив. Это была нервная система проекта, выведенная из тёмных папок сетевого-диска на светлый экран.
На этом этапе так же не обошлось без внедрения нестандартных инженерных решений, кому-то взбрело голову, что в качества хранилища мы должны были прикрутить опенсорсный Next Cloud, у которого не было для этого API, и как говорится мы интегрировались как могли. Чтобы выложить документ в систему нужно было провалиться по ссылке в NC там создать директорию с тем же названием как у документа и туда положить документы, при этом никаких метаданных на этом этапе не было… в общем много вопросов…
С этим чудом мы жили достаточно долго, пока не было принято волевое решение, все переделать на самый простой и очевидный вариант хранения на сервере приложения.
Глава третья: почтовые голуби были отпущены на свободу
Как нетрудно представить, такой объём документации, уходившей нашим партнёрам, порождал ровно такое же море уточнений, замечаний и криков души в процессе производства. И прежде чем показать наш механизм, позволю себе небольшой экскурс в священную традицию отрасли — дабы вы в полной мере ощутили ту бездну, из которой мы выбирались.
Сценарий был таков: инженер на производстве, обнаружив нестыковку, шёл в особое помещение. Там лежала особая книга — Тома Священных Вопросов. В неё он, с благоговением, собственноручно вписывал свой запрос. Раз в день туда же наведывался мастер, переписывал вопрос на свой листок, после чего шел в свой кабинет, чтобы отправить его проектанту. Весь этот ритуал, напоминающий средневековую флорентийскую почту, свято чтится и по сей день.
А теперь представьте иной мир. Рабочий, столкнувшись с проблемой, достаёт смартфон, выбирает в системе конкретный документ, при необходимости делает фото требующее прояснение — и в два касания отправляет прямой сигнал нам, проектантам. Не в книгу, не мастеру, а прямо в сердце системы. Именно так всё и заработало у нас.
Единицы измерения времени ответа мгновенно эволюционировали: недели превратились в часы, а часы — порой в минуты.
Для нас, проектантов, все возникающие проблемы по документам стали видны как на ладони — в едином, живом пространстве, с полной и мгновенно поднимаемой историей.
Руководитель проекта же стал модератором этого вихря вопросов — мудрым привратником, отсекающим шелуху и эмоциональные всплески (ибо, увы, не все пользователи системы пребывают в состоянии строгой профессиональной адекватности). Поскольку структурно это были те же самые задачи, изобретать велосипед не пришлось — наша проверенная ролевая модель (автор, ответственный, исполнитель) легла на новую реальность как родная.
Хаос коммуникаций был не уничтожен, но приручён и поставлен на службу делу.
Глава четвертая: фантомные боли или как мы пытались втиснуть творчество в календарные клетки
А дальше речь пойдёт о программных решениях любопытных и даже, пожалуй, уникальных — подобных я не встречал ни в одной подобной системе. Компания была внутренне не готова к такому. И, оглядываясь назад, думаю — что это и к лучшему.
Мы, как и все смертные, хотели заглядывать в будущее. Мечтали понимать, сколько реально тратим времени на создание документации — желание, в общем-то, вполне здравое. Однако для этого мы избрали путь столь тернистый и трудозатратный, что в итоге он не принёс нам ровным счётом ничего, кроме ценного урока.
Фантазия первая:
«А давайте создадим инструмент планирования, чтобы мы могли точно знать, когда закончим работу по проекту!»
— Да пожалуйста!
Фантазия вторая:
«Так, а давайте сделаем так, чтобы никто не мог списывать часы на задачи вне плана! Мы заставим всех актуализировать планы!»
— Нет проблем!
Фантазия третья:
«А если эти злодеи вообще перестанут списывать часы никуда — давайте их вычленять и журить!»
— Ну это вообще легко!
Вдохновившись этой триадой, мы сотворили такого монстра, какого свет ещё не видывал. Даже руководители гестапо, взглянув на наше творение, сказали бы: «Побойтесь Бога…»
Логика была выстроена с железной последовательностью. Чтобы работать в компании, нужно ежедневно списывать часы — на задачу, отпуск, больничный. А чтобы это делать, необходимо сначала установить всё это в планировщике рабочего времени. Интерфейс его напоминал пёструю новогоднюю ёлку: по горизонтали — сотрудники, у каждого на день — восьмичасовой кубик, который обязан быть заполнен. Иначе — ат-та-та.
Работал он по технологии drag&drop: пользователь должен был «перетащить» на нужного сотрудника заранее оцифрованную в часах задачу — и та закрашивала соответствующее количество кубиков. Но это было только началом ада. Далее нужно было, чтобы задачи могли двигаться, сдвигая друг друга, чтобы длинная задача автоматически разрезалась, если в её промежуток попадала мелкая… Кейсы множились, как головы гидры.
Мы наконец выдохнули, думая, что победили хаос. Ага...
«Так, ребята, пользователи жалуются. Говорят, берут задачи… из будущего».
— Из будущего задачи берут? Ммм...Сомнительно. Ну, допустим. И?
— Нужно, чтобы… (делаем глубокий вдох) …когда пользователь списывается на задачу из будущего, кусочек плана от неё летел сквозь время и пространство, разрезал настоящее и вставал в план сотрудника, сдвигая всё остальное вправо».
И знаете что? Всё это в конце концов работало. Механизм скрипел, шестерёнки вращались, время текло вспять.
Но главный вопрос оставался: помогло ли это хоть кому-то? Тут в пору ставить картинку из мема, которую я уже использовать в начале статьи, поэтому повторяться не буду. Ответ — нет. Не помогло. Слава богу, систему тихо забыли, как страшный сон, и пошли дальше — мудрее, чуть более смиренные перед стихией творческого процесса, которую не втиснуть в цветные кубики, даже самыми изощрёнными алгоритмами.
Эпилог
Мой рассказ, я мог бы вести ещё очень и очень долго. Вы, наверное, уже заметили, что в меню нашей системы осталось множество других кнопочек — нераскрытых глав этой истории. Большинство из них ведут в мир инженерных модулей: интеграции с системами САПР, которые помогали инженерам выпускать документацию быстрее и точнее. Но это тема для отдельной статьи. И, скорее всего, я не стану её автором, ибо был меньше погружён в эту алхимию прямого диалога с чертежом.
Всем же, кто дошёл до этих строк, — моё искреннее спасибо. Я давно вынашивал мысль поделиться этим опытом — пёстрым, бесценным, незабываемым. Путь был тернист, порой мы спотыкались о собственные амбиции, но, оглядываясь назад, я испытываю лишь глубокую благодарность. Благодарность тем, кто шёл рядом, плечом к плечу. Мы прошли через многое вместе и делали всё это — от души, с огнём, который не гас даже в самых сложных поворотах.
И, ставя точку, не могу не произнести имён. Персональная благодарность — Богдану, Юле и Динаре. Без вашей веры, упорства и таланта не было бы ни этой системы, ни этой истории. Вы были тем самым фундаментом, на котором мы возводили наш цифровой корабль. Спасибо.