Зачем быть инженером по внедрению

в 6:10, , рубрики: ECM/СЭД, Карьера в IT-индустрии, Учебный процесс в IT

Четыре года назад я увидел вакансию инженера по внедрению. Из словосочетания «инженер по внедрению» я мог сделать только очень общий вывод, чем занимается этот специалист. Но т.к. в требованиях было указано знание C# и необходимость писать код, я решил попробовать себя в этой роли. Звезды совпали удачно, и меня позвали на работу.
Как выяснилось в дальнейшем, понятие «инженер по внедрению» так же, как «программист», объединяет в себе очень много разных, но родственных вещей. Все внедренцы так или иначе устанавливают и настраивают «нечто» под требования конечного заказчика. Но областей внедрения так много, что специфику каждой расписать мне кажется невозможным.
В этой статье я постараюсь описать, почему вам может быть интересно стать инженером по внедрению. Если быть точнее, то инженером по внедрению какого-либо ПО, потому что сфера внедрения «железа» для меня — темный лес. Обращаю также внимание на то, что мой личный опыт может быть довольно однобоким.

1. Человек-оркестр

Это, пожалуй, главная причина. Если вы не чувствуете в себе стремления становиться гуру какой-то узкой специфики, то внедренец — это судьба для вас. Я работаю с людьми, которые в определенный момент поняли, что погружаться, например, в тонкости MS SQL до уровня MCSE им не интересно (в этом месте можете подставить любую технологию и «джедайский» уровень для нее). И это не «лень», а осознанный выбор.
Для инженера важно кроме знания внедряемого продукта обладать довольно обширными познаниями во всех соприкасающихся областях. А также во всех потенциально соприкасающихся областях. У нас, например, помимо максимального владения внедряемой программой, обязательным является хороший уровень владения C# и T-SQL, базовый навык администрирования серверной винды и знание всякой «экзотики» вроде XSLT и VBS. А пожеланиями к тому, что инженер может знать, можно исписать рулон туалетной бумаги в 54 метра: это и 1С, и Adobe FlexiCapture, и InfoPath, и знание любых ERP, СЭД и так далее, и тому подобное.

2. Сам себе режиссер

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

3. Пятилетку за два года

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

4. Живые люди

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

5. «Сам испек, сам и кушай»

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

6. Все дороги открыты

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

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

Автор: ogr

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js