Инженерная культура: роль личного в корпоративной истории
Рассказываем о том, как построить в ИТ-компании команду с высоким уровнем инженерной культуры.
Инженерная культура специалиста в ИТ-отрасли состоит из двух основных компонентов: культуры предприятия (стандарты) и индивидуальной культуры сотрудника (его привычки, отношение к делу).
Их баланс крайне важен для того, чтобы команда функционировала слаженно и без сбоев, а новые сотрудники быстро включались в работу. Разбираемся, как развивать инженерную культуру в ИТ-компании таким образом, чтобы соотношение этих компонентов было оптимальным.
У любого производства - ИТ не исключение - должны быть предусмотрены стандарты, в которых расписывается, что и как нужно делать.
Мелочей здесь быть не может – в них включается все: от требований к документации, принятых терминов, условных сокращений до цветовой маркировки проводов, применяемых в изделиях. Это корпоративная инженерная культура.
Личная инженерная культура сотрудника – сумма его личных навыков и привычек работы с оборудованием и приборами, а также общая аккуратность выполнения поставленных задач в рамках рабочих процессов.
Так, для любого программиста, инженера, схемотехника, технолога или конструктора крайне важно правильное и аккуратное оформление технической документации. Это позволит его команде, а в будущем - потребителям, быстрее разобраться в том, как работает продукт, заняться его развитием, внедрением или приступить к его эксплуатации.
Это относится к любой сфере деятельности: от программирования и ИТ-аналитики, до проектирования инженерных коммуникаций, создания сложных механизмов и цифровых устройств. Если такого навыка нет, нередко сам автор решения уже через полгода не сможет разобраться в собственном коде или схеме.
Наличие обоих типов инженерной культуры критически важно для ИТ-компаний. Так, даже при наличии сильной корпоративной инженерной культуры команда не защищена от "ляпов" сотрудников, которые недостаточно внимательно относятся к стандартам.
В стандарте предприятия должно быть описано, каким образом присваиваются имена переменным в программном коде или названия цепей в электрических схемах. А сотрудники - знать и разбираться в этом на безукоризненном уровне, свободно оперируя всеми обозначениями, сокращениями, знаками и стандартными аббревиатурами.
Такой подход помогает и при адаптации новичков: в идеале любой человек, который приходит на работу, должен благодаря стандарту быстро понять, как все устроено, и включиться в работу.
Есть ряд ошибок, которые ИТ-предприятия нередко совершают в процессе развития инженерной культуры.
Во-первых, если у ИТ-компании нет своего принятого стандарта, или же стандарт неполный, то его обычно заменяют набором рекомендаций, которые не обязательны к выполнению, и некоторые сотрудники этим пользуются.
Во-вторых, многие ИТ-предприятия используют разные системы автоматического проектирования (САПР) для разработки продукта. Например, для разработки печатных плат и принципиальных электрических схем можно использовать совершенно различные САПР.
В условиях голода в профессиональных сотрудниках, для минимизации времени разработки продукта ИТ-предприятия начинают разрабатывать устройства в тех САПР, в которых умеют работать их новые специалисты, а не обучать их принятому на предприятии САПР.
Поддерживая два или три направления САПР, очень трудно сделать единую систему документооборота с единой выверенной библиотекой элементов. Ротация кадров в таком случае приобретает большую проблему. Аналогичная ситуация и с другими направлениями в ИТ-компании (программирование, конструкторы и т.д.).
Хочется отметить и то, что если брать квалифицированного профессионала, но без знания нужного САПРа - и ждать, пока он переучится, то срок проекта может увеличиться от нескольких месяцев до года. В зависимости от обучаемости сотрудника. Но тогда этот проект в дальнейшем можно будет поддерживать и развивать с помощью других сотрудников этого предприятия.
Третья ошибка: на предприятии нет единой библиотеки (конструкторской, программной или электрических элементов).
Каждый разработчик работает с библиотекой, которую он нарабатывал за время своей карьеры, и это уже серьезная проблема. Заставить всех перейти на единую библиотеку – головная боль для предприятия. Однако если этого не сделать, общая инженерная культура неизбежно упадет, как упадет и качество разрабатываемого продукта.
Высокие результаты обеспечивает только единоначалие. То есть общепринятые стандарты и библиотеки, номенклатура компонентов и общих функций, которые нужно использовать для сокращения ошибок, а также упрощения поиска недочетов, если они все-таки были допущены.
В личной инженерной культуре - другая базовая проблема: сотрудников, владеющих ей, очень мало. Среди новичков, наверное, только каждый десятый обладает базовым или выше среднего уровнем инженерной культуры.
Проявляется это так: просишь на собеседовании нарисовать функциональную схему устройства, которую разрабатывал ранее соискатель.
Чаще всего получаешь лист, на котором изображено несколько квадратов, соединенных пересекающимися линиями, а если просишь рассказать, как это устройство работает, то дорисовывается еще несколько квадратов поверх проведенных линий и в итоге схема становится полностью нечитаемой.
Трудно описать словами то, что иногда приходится видеть на собеседовании.
У программистов достаточно посмотреть код, который он писал на предыдущем месте работы: код без единой строчки комментариев очень «красив» и «понятен».
Также очень многое о человеке и его инженерной культуре можно узнать, дав ему тестовое задание на проверку электрической схемы, топологии печатной платы или программного кода, в которых сделаны ошибки различного уровня.
При проверке электрической схемы большинство смотрят ошибки оформления, другие - на названия цепей, но очень немногие из претендентов открывают документацию на применяемые микросхемы и проверяют их характеристики и правильность применения.
По существу - проводят полный цикл разработки, что позволяет выявить очень много ошибок.
Как же все-таки создать оптимальную инженерную культуру в компании? Для начала критически важно создание собственного корпоративного стандарта, где прописаны алгоритмы и правила составления ТЗ, требования к оформлению структурных схем и программного кода.
Также следует заняться разработкой собственных библиотек, которые содержат все необходимые компоненты 3D-модели и т.д. Затем - сформировать документацию, описывающую процесс передачи документов от одного отдела к другому.
Разберем на примере нашего бизнеса, как выглядит путь проекта в сфере ИТ.
Полный текст на VC.ru
Читайте наш кейс на РБК: как ИТ-компании прокачать бренд работодателя
16 июля 2024Как вырастить штат ИТ-компании в 15 раз за 3 года - рассказываем в совместном кейсе с IT_ONE
Ася Власова – в шоу «Стражи Леса» на радио «ЭХО лОСЕЙ»
10 июля 2024Ася Власова, сооснователь и управляющий партнёр агентства iTrend, приняла участие в шоу “Стражи Леса” на радио "ЭХО лОСЕЙ". Вместе с Еленой Бочеровой из компании "Киберпротект" поговорили о том, как выстраивать PR и коммуникации в ИТ.
Приглашаем на конференцию для директоров по маркетингу и PR-руководителей ИТ-компаний
5 июня 2024На мероприятии встретятся директора по маркетингу и PR-руководители крупных российских ИТ-компаний.
Экс-редактор Comnews присоединился к команде iTrend
30 мая 2024На позицию руководителя проектов коммуникационного агентства iTrend вышел Денис Шишулин – ранее многолетний выпускающий редактор издательской группы ComNews, одного из самых авторитетных ИТ-изданий в России. В iTrend Денис будет отвечать за стратегическое руководство ряда PR-проектов с ИТ-компаниями, оперативное взаимодействие со СМИ, координацию работы команд, а также за качество проектов, которыми руководит в агентстве.
iTrend — в числе топ-агентств России по версии «Рейтинга Рунета»
28 мая 2024Опубликованы итоги ранкинга коммуникационных агентств от «Рейтинга Рунета–2024». iTrend занял лидирующие места в ключевых для агентства срезах — PR в ИТ-отрасли, SMM в ИТ-отрасли, PR и SMM на аудиторию b2b enterprise, PR-аналитика, PR первых лиц и др.