Инженерная культура: роль личного в корпоративной истории

Рассказываем о том, как построить в ИТ-компании команду с высоким уровнем инженерной культуры.

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

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

У любого производства - ИТ не исключение - должны быть предусмотрены стандарты, в которых расписывается, что и как нужно делать.

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

Личная инженерная культура сотрудника – сумма его личных навыков и привычек работы с оборудованием и приборами, а также общая аккуратность выполнения поставленных задач в рамках рабочих процессов.

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

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

Наличие обоих типов инженерной культуры критически важно для ИТ-компаний. Так, даже при наличии сильной корпоративной инженерной культуры команда не защищена от "ляпов" сотрудников, которые недостаточно внимательно относятся к стандартам.

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

Такой подход помогает и при адаптации новичков: в идеале любой человек, который приходит на работу, должен благодаря стандарту быстро понять, как все устроено, и включиться в работу.

Есть ряд ошибок, которые ИТ-предприятия нередко совершают в процессе развития инженерной культуры.

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

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

В условиях голода в профессиональных сотрудниках, для минимизации времени разработки продукта ИТ-предприятия начинают разрабатывать устройства в тех САПР, в которых умеют работать их новые специалисты, а не обучать их принятому на предприятии САПР.

Поддерживая два или три направления САПР, очень трудно сделать единую систему документооборота с единой выверенной библиотекой элементов. Ротация кадров в таком случае приобретает большую проблему. Аналогичная ситуация и с другими направлениями в ИТ-компании (программирование, конструкторы и т.д.).

Хочется отметить и то, что если брать квалифицированного профессионала, но без знания нужного САПРа - и ждать, пока он переучится, то срок проекта может увеличиться от нескольких месяцев до года. В зависимости от обучаемости сотрудника. Но тогда этот проект в дальнейшем можно будет поддерживать и развивать с помощью других сотрудников этого предприятия.

Третья ошибка: на предприятии нет единой библиотеки (конструкторской, программной или электрических элементов).

Каждый разработчик работает с библиотекой, которую он нарабатывал за время своей карьеры, и это уже серьезная проблема. Заставить всех перейти на единую библиотеку – головная боль для предприятия. Однако если этого не сделать, общая инженерная культура неизбежно упадет, как упадет и качество разрабатываемого продукта.

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

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

Проявляется это так: просишь на собеседовании нарисовать функциональную схему устройства, которую разрабатывал ранее соискатель.

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

Трудно описать словами то, что иногда приходится видеть на собеседовании.

У программистов достаточно посмотреть код, который он писал на предыдущем месте работы: код без единой строчки комментариев очень «красив» и «понятен».

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

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

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

Как же все-таки создать оптимальную инженерную культуру в компании? Для начала критически важно создание собственного корпоративного стандарта, где прописаны алгоритмы и правила составления ТЗ, требования к оформлению структурных схем и программного кода.

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

Разберем на примере нашего бизнеса, как выглядит путь проекта в сфере ИТ.

Этап 1 - ТЗ. ТЗ следует уделять очень большое внимание и привлекать к его составлению специалистов из разных областей, программистов, конструкторов, архитекторов, менеджеров по продажам и т.д.

Чем больше специалистов будет привлечено, тем быстрее и качественнее получится продукт, отвечающий требованиям рынка. На этом этапе разрабатываются функциональные схемы. Всем необходимо четко понимать, что, кто и как будет делать - качественное ТЗ дает 20% успеха проекта в целом.

Этап 2 - Архитектура. По функциональной схеме архитекторы осуществляют декомпозицию на отдельные устройства, а устройства - на отдельные платы. На этом этапе идет плотная работа архитекторов и конструкторов.

Этап 3 - Разработка. Разрабатывается принципиальная электрическая схема и топология для каждой из плат. Разработка электрических схем происходит в тесном сотрудничестве инженеров с программистами и конструкторами. Прорабатываются методы отладки готовой платы и программного обеспечения.

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

Этап 4 - Отладочный стенд. Разрабатываются стенды, методика тестирования и программное обеспечение для диагностики плат и устройств на производстве.

Этап 5 - Изготовление платы. После согласования с конструкторами и проведения работ по моделированию печатных плат принимается решение об изготовлении их по заданных характеристикам. Выбираются производства, отвечающие заданным характеристиками и срокам.

Этап 6 – Тестирование. Производится тестирование собранных устройств по разработанным методикам тестирования на тестовых стендах. Для этого нужны очень хорошо задокументированная принципиальная электрическая схема и программное обеспечение, чтобы у тестировщиков был максимум информации по схеме и по программному коду.

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

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

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

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

Такой человек должен описать стандарт предприятия и стать его «евангелистом» для коллег. Коллективу, конечно, придется сделать над собой усилие при адаптации такого подхода к работе.

Соответственно, обязательно придется отрабатывать сценарии отторжения - и потратить на это какое-то время и нервы.

Важно объяснить сотрудникам, что культура инженерной работы – это прежде всего про уважение к коллегам. Если у тебя как у специалиста хорошо задокументированы код или электрическая схема – это знак такого уважения, поскольку при таком подходе им не придется тратить свое время на поиск документации, разборов, почему все реализовано именно так.

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