Привет, Хабр. Меня зовут Алексей, и я сейчас расскажу, как меня привело в архитекторы из мира бетона и строительных конструкций.
Представьте: завод железобетонных изделий, где делают разные плиты, сваи, кольца и тяжёлые строительные штуки. И вот там есть процесс пропарки, когда изделие сначала обрабатывается при температуре 40°С, через два часа — 60°С, потом ещё одно изменение — и уже 80°С. На 80°С выдерживается, потом плавный отпуск, чтобы не было трещин.
Для этой установки на заводе есть специальный человек-скрипт, который в нужные моменты переключает температурный режим. Днём эти люди били рекорды по количеству выпитого чая и выкуренных сигарет. Ночью датчиками автоматизации работали сантехники завода (так сложилось). Сантехники включали режим и засыпали, а с утра узнавали про трещины в изделиях. Из сантехников вообще получаются довольно плохие устройства автоматизации.
Брак можно было уменьшить двумя путями: поставить опытного человека, пачку чая и чайник либо купить специальную железяку, которая делала бы то же самое (только не тратила чай). Железка готовая есть, продаётся как программно-аппаратный комплекс, стоит 15 миллионов рублей.
Я тогда был студентом, был предельно любознателен и любил усовершенствовать все, до чего руки дотянутся. Пришёл на завод, огляделся — ага, вот задача. Взял ардуину, термодатчик и написал простейший аналог электронного реле. И эта штука выдерживала режим пропарки.
Так сначала я стал технологом, потом замглавинженера, а потом перешёл в ИТ и понял, что там всё то же самое, даже экспрессия в острые моменты та же.
Кто такой технолог завода ЖБИ
Технолог — это тот человек, к которому вы приходите с параметрами своего будущего изделия, а он пытается придумать, как его делать. В простом виде он ищет просто способ его изготовить и прописывает каждую операцию. Образуется техкарта, которая похожа на готовое ТЗ на изготовление изделия.
То есть технолог — это такой близкий аналог аналитика из мира кровавого энтерпрайза. Он сначала внимательно слушает пожелания, а потом пытается перевести их в вид задач для производства.
В отличие от ИТ-аналитика, в работе технолога есть нюансы, потому что нужно продумывать сразу много вариантов изготовления изделия. От него требуется обеспечить эффективность процесса. Но в условиях реального завода это не минимизация ресурсов как таковая, а распределение техпроцессов так, чтобы учитывать другие процессы завода. Например, если сейчас завод занят изготовлением огромного изделия, можно уместить 150 нужных штук на поддоне рядом с ним, и это будет хорошо и оптимально. А вот если большого заказа нет, то нужно делать такие же штуки, только на другой линии. И не по 150 штук за раз, а по три штуки. Потому что запускать крупный процесс будет просто нерентабельно. На заводе есть простаивающие и занятые мощности, есть миллион вариантов сделать каждый заказ. Надо понять, как оптимально и эффективно, с учётом всех особенностей ситуации, всех возможных бутылочных горлышек и так далее. Поэтому часто прописываются две техкарты или более, а к ним условия: когда и какую использовать.
Главный технолог, стоящий над всеми технологами, — это уже архитектор из мира ИТ-процессов. Он думает не только про то, как всё это сделать в текущих потоках и паттернах, а как улучшить завод в будущем. И видит всю систему.
С карьерой на заводе задалось: я довольно быстро прошёл путь от студента-стажёра до технолога (особенно после решения вопроса с железякой за 15 миллионов), а потом и до главного технолога. В целом на заводах дефицит людей, готовых мыслить нестандартно, но при этом не разрушать производство в процессе опытов. Обычно они уходят куда-то ещё дальше.
На должности главного технолога я задержался всего на год и перешагнул на новую ступеньку — заместителя главного инженера. Главный инженер на заводе — это король. А вот замглавинженера — это аналог CTO из мира ИТ.
В отличие от технологов, работающих только с чистым миром пара и бетона, замглавинженера отвечает за ведение документации, контроль качества, ведение процессов. На этой позиции очень много переговорной и административной работы: например, надо как-то вписать всё в требования Ростехнадзора, Росприроднадзора, пожарных и так далее. Нужно уметь проводить совещания со всеми этими замечательными людьми, пытаться понять их требования, переводить их сначала на русский, а потом на технологический язык. Замглавинженера очень много коммуницирует с заказчиками и решает все спорные моменты. Если при приёмке что-то идёт не так, именно он доказывает, что не главный технолог сказочный идиот, а что именно это было написано в ТЗ и дважды согласовано заказчиком. Ну или наоборот.
Эта сугубо техническая должность дала отличный опыт прокачки софт-скиллов. Позже, когда пришлось работать в продуктовых командах, мне это очень пригодилось. Совещания заводские и в ИТ-командах во многом похожи, легко провести параллели.
Если очень коротко, то:
- На заводе ЖБИ всегда был процесс, что делать и кому говорить. То есть проблема крайне редко эскалировалась, если она относилась к текущей работе, а не к внедрению нового узла, например.
- Когда что-то случается, это живо беспокоит всех рабочих, и они очень хотят объяснить и доказать свою точку зрения. Не всегда могут сделать это понятно, но всегда хотят рассказать.
- В случае ИТ проблема обратная: не все хотят договариваться. Например, мне очень неожиданно поначалу было то, что бэкендеры с фронтендерами не хотят общаться. Для меня это было несколько дико, и сама идея поставить им координационную встречу поначалу была для меня в новинку. На заводе митапы и ежедневные стендапы проводятся в курилке, там же отслеживается процесс спринта и делаются ретро.
- Процесс получения требований с бизнеса очень напоминает процесс общения с крупным заказчиком. А процесс общения с пожарными принципиально не отличается от процесса общения с информационной безопасностью. У тех и у других есть требования, которые повлияют на процесс дальше.
В общем, стоит один раз научиться проходить все эти сложные процессы и дальше ничего страшного не случится.
Для ИТ-специальности оставалось проработать одно звено — хард-скиллы.
Учился я самостоятельно. Первой крупной задачей было оптимизировать бетонорастворную установку — это место, где, собственно, делается состав. Нужно было точно взвешивать разные компоненты смеси в дозаторах и, исходя из этого, отдавать команды на открытие-закрытие разных задвижек в устройстве. Это позволило бы смешивать раствор не на глаз, а очень точно. А качественный раствор — основа качества изделия. Вместо того чтобы купить новую БСУ за несколько чемоданов денег, мы с главным инженером купили тензодатчики и терминалы. Дозирующее оборудование на линиях щебня, песка и так далее соединили в одну сеть и поставили контроллер с самым настоящим фекально-дендральным кодом. Потому что учились сами. Но у этого сверхкостыльного кода было одно большое преимущество — он работал. Основные задачи были не в разработке, а в её стыках с реальным миром. Например, для разных материалов нужны были разные задержки в дозаторах: сигнал идёт не сразу, после измерения и решения на закрытие заслонки материала ещё немного отсыпается. Нужно было проводить опыты, придумывать, как решать такие задачи. После получения первых результатов нас уже было не остановить: один раз получив результат автоматизации, мы переходили дальше и делали что-то ещё. Процесс увлёк.
Завод постепенно покрывался костылями, но никто не знал, что это вообще такое, никто не слышал про техдолг или что-то подобное. Это работало.
Время шло, я учился, решения становились всё более продуманными и всё менее костыльными. К 2014 году удалось автоматизировать несколько заводов группы компаний, потому что был от них запрос на это.
В 2014 году у промышленности настали тяжёлые времена. Перспективы карьерного роста тоже не радовали. И тут вдруг я внезапно понял, что, пожалуй, смогу работать джуном в разработке — и через пару лет получать столько же, сколько на заводе, и даже больше, да, собственно, и на старте разница была не критично существенна. Да ещё без Росприроднадзора, пожарных и нескольких тонн бумажной документации на каждый чих. Устроился в CRM-хостинг, поработал джуном. Для разработчика моих технических навыков было недостаточно, но это перекрывалось жаждой деятельности и прокачанными скиллами в диалогах с заказчиками. И вот в какой-то момент мне предложили расти в сторону лида. Поначалу предложение озадачило: какого нахрен лида — я же вообще ничего не знаю! Помогло то, что я не боялся говорить, что чего-то не знаю, и быстро искал способ узнать. В общем, ещё пара лет — и появились и навыки, и позиция управления разработкой.
Страх сказать: «Я не понимаю, скажи, как работает» — это бич среди джунов, многие боятся на своём уровне показать, что они некомпетентны. И хоть я был старше своей группы, мне было в целом плевать на то, кто что подумает. Не понимал — спрашивал. Потом пытался объяснить другим. Так и учился.
В итоге в какой-то момент мне позвонили и предложили переход в консультационный бизнес на старт нового проекта со знакомой мне технологией. Решился и после всех положенных формальностей перешёл. Проект мы внедрили, а потом докрутили до того, что вынесли его на открытый рынок, и появились ещё коммерческие заказчики.
Сегодня я уже системный архитектор, и так сложилось, что все проблемы продукта на мне замыкаются, и частично я выполняю работу технического директора. Как в старые добрые времена, можно сказать.
Мой рабочий день выглядит ровно как раньше: переговоры с заказчиками, анализ новых задач для развития, совещания по разным техническим вопросам, потом попытки свести вместе разных людей и дать им общаться друг с другом.
Так что в ИТ попадают не только с должности директора кладбища. И не только в ручные тестировщики.