Comments 31
«Т.е. исключены ситуации, когда вы все сделали хорошо, а ваш коллега накосячил, из-за чего не приняли всю работу, ну или вам досталась ужасная архитектура, с которой вам приходится мириться и пилить под нее костыли. Все сам и только сам.»
Вовсе нет ;) как раз наоборот. Если Вы один на проекте коллега не накосчит. Может накосячить менеджер, который продал заказчику что-то нереальное или слабореализуемое. А уж ужасная архитектура Вам достается 9 раз из 10. И да, зачастую со стороны заказчика работают люди, которым просто насрать на свою работу. Они будут задавать Вам вопросы, на которые Вы не должны им отвечать т.к. они не по проекту, они будут делать элементарные веши для Вас не час, а неделю, и т.д. и т.п.
Есть много минусов, и поверхностные знания продуктов тоже один из минусов, я так считаю. Может кто-то и хочет знать все и одновременно ничего. По-моему это не очень круто.
Вовсе нет ;) как раз наоборот. Если Вы один на проекте коллега не накосчит. Может накосячить менеджер, который продал заказчику что-то нереальное или слабореализуемое. А уж ужасная архитектура Вам достается 9 раз из 10. И да, зачастую со стороны заказчика работают люди, которым просто насрать на свою работу. Они будут задавать Вам вопросы, на которые Вы не должны им отвечать т.к. они не по проекту, они будут делать элементарные веши для Вас не час, а неделю, и т.д. и т.п.
Есть много минусов, и поверхностные знания продуктов тоже один из минусов, я так считаю. Может кто-то и хочет знать все и одновременно ничего. По-моему это не очень круто.
«Может накосячить менеджер, который продал заказчику что-то нереальное» — ну это общая проблема всего ИТ-сообщества, я ее здесь не описывал. Если менеджер — дурак, то у вас проблемы будут что при разработке, что при внедрении, что при технической поддержке. С заказчиком та же фигня: не повезти может где угодно. С другой стороны в последнее время, по крайней мере в нашем секторе, наблюдаю очень интересную тенденцию к «поумнению заказчика». Связано с тем, что большинство компаний начинает очень активно считать деньги, затрачиваемые конкретными специалистами.
«Есть много минусов, и поверхностные знания продуктов тоже один из минусов, я так считаю. Может кто-то и хочет знать все и одновременно ничего. По-моему это не очень круто.» — значит, не быть вам внедренцем :) Это действительно осознанный выбор людей.
Ну и я бы не рассматривал эти знания как поверхностные. Крутой инженер в тех технологиях, с которыми ему приходится работать, разбирается на уровне миддла. Да, до сеньора он не вырастит никогда, но ему это и не нужно.
«Есть много минусов, и поверхностные знания продуктов тоже один из минусов, я так считаю. Может кто-то и хочет знать все и одновременно ничего. По-моему это не очень круто.» — значит, не быть вам внедренцем :) Это действительно осознанный выбор людей.
Ну и я бы не рассматривал эти знания как поверхностные. Крутой инженер в тех технологиях, с которыми ему приходится работать, разбирается на уровне миддла. Да, до сеньора он не вырастит никогда, но ему это и не нужно.
Я он и есть, и я вижу это изнутри, и это проблема. Не знаю что Вы подразумеваете под словом мидл. Я могу сказать, что везде где я работал 95% инженеров крайне хреново знали продукты. Ну тут вопрос: что и как оценивать. Я свои знания оцениваю как не очень впечатляющие. При том что я постоянно что-то учу и изучаю (как могу).
А текучка у вас большая? Я подобное наблюдал в своей компании, когда только пришел работать. В нашем департаменте был небольшой бардак, из-за чего сотрудники очень быстро обновлялись — естественно, никто не успевал набраться опыта. Сейчас же у нас почти все сотрудники работают не меньше 2х лет, и средний уровень знаний и профессионализма прилично вырос.
А ваши знания не впечатляющие, потому что не успеваете их «качать»? Или потому что руководство не дает применять новые умения?
А ваши знания не впечатляющие, потому что не успеваете их «качать»? Или потому что руководство не дает применять новые умения?
Кстати, по поводу 5го пункта, можно получить и противоположный результат)
А в 6 пункте есть еще одна возможность — уйти работать в ту отрасль для которой собственно внедряемая программа и делалась :-)
Примеров лично у меня уйма под боком :-)
Примеров лично у меня уйма под боком :-)
>пожеланиями к тому, что инженер может знать, можно исписать рулон туалетной бумаги в 54 метра: это и 1С, и Adobe FlexiCapture, и InfoPath, и знание любых ERP, СЭД и так далее, и тому подобное.
Какая интересная аллегория, по Фрейду прям :D
Какая интересная аллегория, по Фрейду прям :D
А, если не секрет, уровень оплаты труда таких людей-оркестров как соотносится с уровнем зарплат узкоспециализированных разработчиков?
А причем тут разработчики?
Абсолютно идентичен как для начинающих, так и для гуру.
Что??
Разве нет?
Вот просто ссылки с HH:
Инженер по внедрению информационных систем — 45-65к
Инженер по внедрению — 60к-90к
Как вы понимаете «старших» и «ведущих» инженеров не ищут на HH: они или уже сидят на работе своей мечты, или их переманивают по рекомендациям.
Вот просто ссылки с HH:
Инженер по внедрению информационных систем — 45-65к
Инженер по внедрению — 60к-90к
Как вы понимаете «старших» и «ведущих» инженеров не ищут на HH: они или уже сидят на работе своей мечты, или их переманивают по рекомендациям.
На hh легко можно найти вакансии разработчика и на 150к и выше. По вашей логике сеньйоры получают еще больше и их не ищут на hh.
Ну в нашей компании зарплаты коррелируют с моими ссылками. Надо понимать, что здесь в вашу пользу играет «уникальность» специалиста: человека знающего конкретную платформу от и до, и способного ее внедрить в одиночку оторвут с руками. Т.е. если вас на текущем рабочем месте не устраивает ЗП или еще что-то, всегда можно продаться конкуренту или заказчику.
Хотя, наверное, в сфере, где спецов много, ситуация может быть иной.
Хотя, наверное, в сфере, где спецов много, ситуация может быть иной.
Самый большой кайф для внедренца — это видеть результат свой работы непосредственно в использовании конечными пользователями. Особенно радует, когда есть возможность, имея почти моментальный фидбэк, корректировать функционал и добавлять функции так, что пользователь получает максимальный профит.
А будучи человеком-оркестром нравится разнообразие видов деятельности: от аналитики до программирования.
А будучи человеком-оркестром нравится разнообразие видов деятельности: от аналитики до программирования.
Не в обиду, но из личного опыта: из инженеров редко получаются хорошие аналитики, слишком уж они погружены в технические детали. Но такие случаи тоже были.
В каждой компании объем задач разный — на предыдущем месте работы (в IT-отделе не IT-компании) я был внедренцем, и при этом занимался внедрением, сопровождением, тестированием, аналитикой — всем, кроме разработки.
На текущем месте я занимаюсь непосредственно внедрением, и бизнес-аналитики уже не касаюсь.
Так что, вполне возможно, вы просто разные наборы сфер деятельности имеете в виду.
На текущем месте я занимаюсь непосредственно внедрением, и бизнес-аналитики уже не касаюсь.
Так что, вполне возможно, вы просто разные наборы сфер деятельности имеете в виду.
Специалист по технической поддержке так же может быть аналитиком например.
Специалист по технической поддержке довольно близок к инженеру по внедрению. Ну только у него общения с пользователями еще больше.
Специалист по технической поддержке довольно близок к инженеру по внедрению.
Это как? Я с пользователями вообще не общаюсь… И никто у нас не общается. И на предыдущей работе не общался.
Это как? Я с пользователями вообще не общаюсь… И никто у нас не общается. И на предыдущей работе не общался.
Вы наверное L3. L1 общается постоянно, Л2 очень часто.
Нет, подождите, если Вы прочите меня в архитекторы, я польщен, но я не там. Я обычный инженер. Я, конечно, общаюсь с представителями заказчика, но никак не с пользователями. С администраторами, да, приходится общаться. С пользователями я уже года 3 не общался.
Ну и опять же, никто у нас не общается с пользователями. Не только я не общаюсь.
Ну и опять же, никто у нас не общается с пользователями. Не только я не общаюсь.
Sign up to leave a comment.
Зачем быть инженером по внедрению