Профдеформация, когда работаешь в айти на заводе

Как я тут оказалась

В общем, в чем история. В 2022 году я работала в пресс-службе на крупном электромонтажном предприятии. Задачи решала разные. Рассказывала истории о людях в газете, вела соцсети, создавала брендовую продукцию, логотипы, комиксы. Даже книгу на 300 страниц написала и издала.

Отработала я там честно три года. Стало понятно: потолок достигнут, задачи превратились в рутину. Пора двигаться дальше.

В итиху мне давно хотелось, пробовала разное. Изучала и C#, и HTML / CSS, JS. Но больше всего мне нравилось работать с макетами. Продумывать концепцию, логику. Так я оказалась на курсе Яндекс.Практикума «Дизайнер интерфейсов».

Хороший в целом курс, но в Яндекс после него не берут, не верьте. Я убеждена, что навыки приобретаются и оттачиваются на практике. Поэтому пошла искать новую работу.

Как я тут оказалась
В общем, в чем история. В 2022 году я работала в пресс-службе на крупном электромонтажном предприятии. Задачи решала разные. Рассказывала истории о людях в газете, вела соцсети, создавала брендовую продукцию, логотипы, комиксы. Даже книгу на 300 страниц написала и издала.

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

Пришла к их руководителю. Говорю, вот такая вот особа, хочу заниматься дизайном. А меня на тот момент все руководство и так знало, что уж тут. Что активная, ответственная, разберется в любой теме. Так, мне было предложено заняться не только и столько дизайном, а аналитикой.

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

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

Чтобы потихоньку разгребать этот хаос, нужна была метода. Так меня отправили разрабатывать нормативку. Где-то полгода я этим занималась: изучила самостоятельно нотацию BPMN 2.0, написала и внедрила соглашение о моделировании, требования к описанию бизнес-процессов. Выпустили и документ, который концептуально закрепляет принципы управления бизнес-процессами на предприятии. Хэйта словили море — никто ж не любит менять привычное, а тут опять что-то от всех требуют.

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

Дальше молва покатилась сама собой. И сейчас, спустя два года, люди уже сами все делают, мы только согласуем и помогаем оптимизировать. Есть проекты, где у меня высокая вовлеченность (весь процесс сама выстраивала и курирую до сих пор). Это как раз те самые крупные проекты, где мы разрабатываем веб-приложения. Но об этом дальше.

Да когда уже дизайн?
Параллельно с написанием методы я занималась проектированием процесса управления потребностью в персонале. Это когда от трудоемкости считается требуемое количество кадров. На деле много всякой запутанной математики, перегруженной логики. Ну такие вот у нас процессы, судостроение — сложная отрасль.

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

Тогда появились мои первые макеты. Ну как: сначала я сделала «чтоб похоже на ЭДО». Сделала сама, без компонентов — потому что их не было. В итоге наш руководитель сказал, что надо переделать. Руководитель наш, для понимания, гениальный человек. Я ему бесконечно благодарна и по сей день за все знания, которые он мне передает. Шарит просто за все. За технику, за логику, за инфраструктуру, политику, проектное управление. Но ради честности — не за дизайн.

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

Манагеры на заводе
Так у нас стали закладываться процессы манагера. Кто такой манагер в заводском ИТ — это и аналитик, и дизайнер, и скрам-мастер, и техподдержка, и, конечно, управленец.

Процессы манагера выглядят так:

Проектируем процесс
Формируем требования к будущему сервису
Проектируем User Flow, создаем макеты
Пишем таски, передаем в разработку, отвечаем на вопросы, участвуем в скрам-активностях
Получаем функциональность, тестим
Деплоим, запускаем в народ
Отвечаем на звонки пользователей, фильтруем баги и хотелки
Поменялся процесс? Все по кругу
Поясню некоторые нюансы. Что из себя представляет проектирование процесса. Это когда манагер работает с функциональщиками. Собирает совещания, где люди, работая в одном процессе, видят друг друга впервые. Раскладываем, что кто кому должен сделать, как должен сделать, в какие сроки. Все рисуем в БПМН, чтоб понять как это работает сейчас и где надо поправить на будущее.

Зачастую это не обсуждение, а холивар, который ни к чему не приводит. Манагеру надо этот хаос отмодерировать, вникнуть в их процесс и привести народ к консенсусу. Количество неминуемо переходит в качество. И спустя месяца три (а иногда полгода и больше) все-таки рождается взаимосогласованные участниками модель и документ к ней.

Стрессняк это тот еще. На тебя льется хэйт, мол, зачем эти все описания, да еще так подробно. У нас сотрудники относятся к айти как: надо кнопку «Сделать хорошо». «Как это — хорошо?» — нигде описывать не будем, требования к тому, «что значит —хорошо?» — не скажем. И в итоге, если пойти на уступки и сделать все самостоятельно, они просто позвонят и скажут: вы идиоты, такую ерунду сделали, все неправильно.

Часто в какой-то момент ты просто психуешь и сама перерисовываешь модели и переписываешь все эти регламенты, потому что некоторым людям тяжело изъясняться по-русски.

Но, как говорил мой наставник: страшно не то, что мы в жопе, а решить в ней начать обустраиваться. Поэтому, смахнув слезки, мы продолжаем проектировать процессы. Это уже привело к положительным результатам. В экселе-то проще данные подделать и сдать. А когда находишься в общей системе, где «нормочасы — в людей», а «люди — в деньги» — тут уже не вывернуться. До сих пор есть звонки к нам, мол, мне тут надо, чтоб 2+2=5. Извините, с профанацией не поможем.

Я всегда балдею на этапах два, три, четыре — когда наконец-то занимаюсь тем, за чем пришла. Ну тут вроде все понятно: пишем требования, к ним делаем флоу и макеты, и в разработку отдаем. Таски манагер пишет чаще сам. Иногда что-то расписывают тимлиды — где техника, иногда разрабы сами создают — в основном на баги.

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

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

А давайте еще заработаем
Год назад у нас появились и проекты для внешнего заказчика. Это бизнес-анализ или разработка, где вместо местных функциональщиков — внешние. Тут для манагера появляется еще работа — договора, оценка сроков, оценка бюджета, контроль табеля. Манагерская работа, скажете вы, чего тут особенного. И будете в общем-то правы.

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

А моим развитием занимался руководитель: я участвовала с ним в президентской программе подготовки управленцев как менти, училась разрабатывать проект и готовить бизнес-план. Вместе мы вели занятия в кадровом резерве другого завода, где учили людей управлять проектами (он вел лекции, а я помогала обучающимся на практике искать решения поставленных задач).

Так, а где профдеформация
Вся история выше приведена для понимания, какие компетенции я приобретала все это время. Очевидно, очень разносортные. Тут и управление людьми и проектами, бизнес-анализ и оптимизация, даже разработка. Последнее отдельный мем — иногда, чтоб разъяснить, что надо сделать, приходится лезть в самые дебри. За эти годы я выучила не только разницу между фронтом и бэком, приходилось вникать в различные варианты интеграции, методы общения между системами, что такое AD и как оттуда достать пользователей, что такое SSO и какие они бывают, какие бывают протоколы данных, что такое vite и зачем он нужен и т.п. Это вещи, которые дизайнерам и манагерам в общем-то, наверное, и не нужны, но упрощают принятие решения в ряде вопросов.

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

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

На работе дизайн я сейчас собираю, акцентируя внимание на следующем:

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

Однако, походив по собеседованиям и принценив ситуацию на рынке труда, я поняла, что за три года так и не приобрела тех компетенций, за которыми шла. Я не работала здесь с метриками. Не проводила тестов. Мой основной источник информации — этнография, когда ты просто сидишь с пользователем и смотришь, как он идёт по флоу (что тоже случается редко, ибо время на это не выделяется). Мой UI не впечатляет, а UX строится не из продуктовых гипотез.

При этом меня зовут на собеседования, я даже получила оффер в зеленый банк. Но все это внутренний продукт или какие-то студии (было и предложение пройти собес в контору, которая делает интерфейсы для эротических Ai-приложений).

Конечно, мне бы хотелось работать в продукте, которым пользуюсь я и мои друзья каждый день. В компании, где тебя окружают старшие более опытные коллеги-дизайнеры. И вместе с ними ты растёшь. Занимаешься исследованиями, строишь гипотезы, создаешь UI, который модный и фреш. А не чтобы попроще и побыстрее.

Сейчас, когда я пытаюсь решать задачки из области продуктового дизайна, я применяю свой опыт и делаю не то. При этом я довольно быстро понимаю, что не то. Например, в Детемпре я улучшила свой результат на 1.57 (это очень много) на первой же работе: проанализировала экраны тех, кому дали оценки выше и сделала работу над ошибками. Это не то, что сложно, вопрос в том, что нет релевантного опыта. У тебя куча каких-то космических компетенций, но не тех, что нужны. Ты их применяешь, но на результат это влияет негативно. И возвращаешься в начало пути. Смотришь взглядом новичка, и результат парадоксально становится лучше. Такая вот профдеформация.

Что я с этим делаю
Важный момент: в целом я люблю свою текущую работу. У меня классный коллектив, достойная зарплата на уровне рынка. Минус один — здесь нет возможности развиваться туда, куда хочется — в продуктовый дизайн.

Проявлять креатив на заводе можно, но не так, как хотелось бы. Одно дело придумать завлекалку для юзеров в маркете, другое — как перекинуть кабель с заказа на заказ и везде поставить его вовремя. Исследования, гипотезы — здесь это просто лишнее, а на глобальное улучшение UX/UI ресурсов нет.

Надо признать то, что гипотезы и впечатляющий UI — конечно, это core-компетенции для продуктовика. И их отсутствие за три года опыта — отстой. Лучше ли было найти какую-нибудь студию три года назад, а не переходить на своем месте? Я считаю, что нет. Потому что те компетенции, которые я приобрела здесь — они гораздо глубже. С уверенностью могу сказать, что понимаю, как работает бизнес лучше, чем дизайнер из студии. Умею работать с ограниченным ресурсом, выделять главное, что нужно сделать. Работать с дизайн-системой и создавать ее (ведь у меня была такая возможность).

А core добиваю. Беру курсы (прошла недавно у Вики Бреусовой по UI), набиваю руку в домашках от Детемпр. И беру лучшее из профдеформации. Заводской веб ван лов🫶

Преодолеваю профдеформацию и переучиваюсь. Не начинаю с нуля — верю, что с имеющимися компетенциями все это переосвоить будет проще.

Да кто такой этот ваш БПМН

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

Да когда уже дизайн?

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

Манагеры на заводе

Так у нас стали закладываться процессы манагера. Кто такой манагер в заводском ИТ — это и аналитик, и дизайнер, и скрам-мастер, и техподдержка, и, конечно, управленец.

Процессы манагера выглядят так:

Проектируем процесс
Формируем требования к будущему сервису
Проектируем User Flow, создаем макеты
Пишем таски, передаем в разработку, отвечаем на вопросы, участвуем в скрам-активностях
Получаем функциональность, тестим
Деплоим, запускаем в народ
Отвечаем на звонки пользователей, фильтруем баги и хотелки
Поменялся процесс? Все по кругу

Поясню некоторые нюансы. Что из себя представляет проектирование процесса. Это когда манагер работает с функциональщиками. Собирает совещания, где люди, работая в одном процессе, видят друг друга впервые. Раскладываем, что кто кому должен сделать, как должен сделать, в какие сроки. Все рисуем в БПМН, чтоб понять как это работает сейчас и где надо поправить на будущее.

А давайте еще заработаем

Год назад у нас появились и проекты для внешнего заказчика. Это бизнес-анализ или разработка, где вместо местных функциональщиков — внешние. Тут для манагера появляется еще работа — договора, оценка сроков, оценка бюджета, контроль табеля. Манагерская работа, скажете вы, чего тут особенного. И будете в общем-то правы.

Так, а где профдеформация

Вся история выше приведена для понимания, какие компетенции я приобретала все это время. Очевидно, очень разносортные. Тут и управление людьми и проектами, бизнес-анализ и оптимизация, даже разработка. Последнее отдельный мем — иногда, чтоб разъяснить, что надо сделать, приходится лезть в самые дебри. За эти годы я выучила не только разницу между фронтом и бэком, приходилось вникать в различные варианты интеграции, методы общения между системами, что такое AD и как оттуда достать пользователей, что такое SSO и какие они бывают, какие бывают протоколы данных, что такое vite и зачем он нужен и т.п. Это вещи, которые дизайнерам и манагерам в общем-то, наверное, и не нужны, но упрощают принятие решения в ряде вопросов.

На работе дизайн я сейчас собираю, акцентируя внимание на следующем:

Разработка может это сделать
Разработка может это сделать быстро
Разработка может это сделать с минимальными трудозатратами
Это привычно для пользователей, которые всю жизнь обитают в десктопе (привет, гриды!)
Это утилитарно и пройдет ревью у руководителя (никаких свистоперделок, буйства красок и пр.)

Все это позволяет нам разрабатывать более менее быстро и оперативно отвечать на запросы бизнеса (которые, как вы уже поняли из ситуации, меняются тоже часто и хаотично).

Что я с этим делаю

Важный момент: в целом я люблю свою текущую работу. У меня классный коллектив, достойная зарплата на уровне рынка. Минус один — здесь нет возможности развиваться туда, куда хочется — в продуктовый дизайн.