Обновить
2
0
Дмитрий Терехов@Alanir

Senior QA Automation

Отправить сообщение

Прекрасная статья! Мало того, что школы понавыпускали людей с завышеными ожиданиями на свои нулевые знания, так необходимо ещё им рассказать, что скакать по работам в поисках развлечений - это нормально для IT! Браво, автор, вы помогаете российкой разработке растить больше раздолбаев! Жду следующих статей, подписался.

Вы сравниваете влияние сбоя сервисов компании (фактически пока ещё частной) уровень которых "заработай сто рублей" и влияние сбоя сервисов государственного масштаба. Я рад, что в гос. структурах по-старинке придерживаются стандартов качества, ГОСТов и прочего - это даёт стабильность. Но у яндекса, как у большинства IT компаний (особенно выросшей на гиках, из стартапов), весьма вольная политика отношения к качеству и стабильности. Это жертва, которую приносит бизнес для быстрого деливеринга функциональности на продакшен, а следовательно получения прибыли и сокращения издержек на разработку/тестирование. Всё это описано в свободном доступе их инженерами на конференциях и блогах.

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

Автору - сил пережить кризис.

>Я не была уверена, стоит ли отправлять тестовое задание кандидатам. Сейчас все активно топят за то, что тестовое задание — это эксплуатация труда кандидата
Это активно эксплуатируемое определёнными слоями общества явление. Ввиду дефицита кадров в определённый момент времени на рынке, люди начали гнуть пальцы "не хочу тратить время на тестовое"/"моё время дорогое"/"почему я должен работать за бесплатно" - отсюда и сформированный нарратив о том, что кандидаты проходят мимо тестового.

С точки зрения подхода к взаимодействию с сотрудниками, в каком-то момент времени любой из них достигает потолка практических возможностей в рамках данных ему условий - компания просто не может ему предложить новых технологий для изучения или задач в рамках текущих бюджетов, потому что есть набор задач, которые необходимо выполнять. Нет возможности дальше расти вертикально или горизонтально. Именно в этот момент проявит себя то самое качество человека, которое вы вольно или невольно выявляли наличием тестового задания: одни скажут "тогда я пошёл в другую компанию, мне тут уже неинтересно", а другие начнут в доступное им время изучать новые технологии и подходы, которые можно применить к текущей работе, чтобы сделать её более эффективной или обновить стек технологий: с одной стороны удовлетворяя свои потребности, а с другой продолжая рост. конечно при условии, что есть возможность изучив новые технологии их применить - для этого надо создавать условия и атмосферу). Вторые - это люди, которые не боятся вкладывать немного своего времени в развитие себя и компанию, что напрямую связано с тем хотят ли они тратить своё время на тестовое задание. Лично для меня - это способ фильтрации кандидатов, в зависимости от потребностей компании.

Рекомендую, всем любителям "свободно редактировать википедию" поинтересоваться как происходит работа над статьями вики и чем они являются - https://www.youtube.com/watch?v=AudsAM6CKXs

Какое там "непредвзятое мнение", "только проверенные факты" и т.д.

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

И вам доброго дня.

"В статье мы имели в виду тот факт, что из-за релокации специалистов компаниям стало сложнее искать новых сотрудников: тех, кто уехал за границу, становится практически невозможно перехантить. "
Но из этого не вытекает, что "ведь большая их часть релоцировала вслед за зарубежными компаниями ", например, хотя бы, потому что люди несклонны менять место работы в период турбулентности рынка труда, и уж тем более в сочетании с периодом турбулентности экономической. Если не брать в расчёт хипстеров и любителей "поработать под пальмой", то 80% консервативного русского населения, в нынешней ситуации предпочтёт переждать, если на текущем месте есть стабильность. И это только одна из причин, почему хантить стало сложнее.

"мы опирались на собственные данные, которые получаем при поиске IT-специалистов"
Тогда нужна оговорка, что речь идёт строго о тех, кто сейчас ищет работу и готов её менять, потому что, опять-таки по описанной выше причине, вы сталкиваетесь с теми, кто хотел бы уехать, или ищет защиты активов. Однако в общей массе нельзя сказать "изменились и требования самих программистов", потому что у тех, кто сейчас не хочет менять место работы - требования не менялись; или, приведу в пример себя, их требования поменялись, но в другую сторону - "я не готов рассматривать иную валюту, кроме как рубль сейчас". Так же стоит отметить, что по ТК РФ работодатель не имеет права платить зп в иной валюте, кроме как рублях. Следовательно, господа и дамы, которые хотят в USD/EUR/JPY должны идти в ИП и сами работать с налоговой, заключая контракты с компаниями напрямую, но это уже не "наш рынок", как мне кажется, а какая-то его параллельная часть
Подкреплю слова неофициальной статистикой. Я кинул опрос среди знакомых it и из 24 ответивших: 50% хочет баксы, 50% хочет рубли в ответе на вопрос: какие предложения они бы рассматривали, если бы искали сейчас работу: rub или usd/eur (те, кто не собирается покидать Россию)? К сожалению у меня нет выборки до 24 февраля, сравнить не с чем, но картина однозначная - нет яркого смещения интереса среди специалистов в сторону доллара или иной, отличной от рубля, валюты.

"В текущих условиях российскому бизнесу всё сложнее искать профессиональные IT-кадры, ведь большая их часть релоцировала вслед за зарубежными компаниями"
Я вот смотрю по сторонам, в разных компаниях Питера, и и релоцировалось примерно 20%, остальные люди на месте. За исключением, конечно тех, где вся компания уехала.
Откуда статистика, что большая часть релоцировалась?

 "Однако изменились и требования самих программистов: они хотят получать зарплату в валюте на уровне с зарубежными рынками. "
К доллару было хорошо привязываться раньше, когда он был мировым стабильным гарантом (или во время истерики, когда он был по 120). Сейчас он таковым уже не является и я не вижу вокруг здравомыслящих людей, которые бы хотели с ним работать. Как и с евро.
Откуда вы взяли, что все хотят доллар?

В заголовке статьи указано "Что учить новичку в QA (тестировании)?"
А статья отвечает на вопрос "самые популярные слова на латинице" в вакансиях на hh.ru

Частота этих самых слов не имеет никакого отношения к тому, что является наиболее востребованными навыками для QA. Язык C не может быть для QA более востребованным навыком, чем python, scrum или http.

К чему в ваших списках навыков перечислять названия компаний - вообще не ясно.

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

Официальная документация + туториалы от сообшества — это отличный старт. С них и начинали. Плюс answerhub и форум, где отвечаю достаточно быстро. Зачастую сами разработчики. Они на форуме сейчас отобрали представителей сообщества, опытных, которые постоянно мониторят его и стараются направлять. Кстати, где-то там собирались запускать что-то рускоязыное, можно уже темы найти.
Однако порой приходится только методами проб и ошибок узнавать как поступить правильно. По-началу вариативность казалась костыльной или каким-то тяжёлым наследием, а сейчас приходим к выводам, что возможность реализовать одни и теже вещи принципиально разными способами (например, работа с камерой) — это направление унификации движка. Т.к., всё-таки UE4 базируется на UE3 и ещё имеет в своей архитектуре местами прибитое гвоздями направление в сторону FPS.
Подводя итог: туториалы+форум+answerhub+свой опыт. Готовьтесь к тому, что вы будете разбираться в исходниках проектов-примеров и исходниках движка. Кстати, их не стоит бояться, они написаны весьма чисто и прозрачно.
Также есть неофициальный irc канал, где постоянно сидит порядка 100 девелоперов и помогают своими советами.
А новичку в гей-деве начать стоит с blueprint'ов, чтобы ознакомиться с архитектурой и понятиями проекта. Когда уже въедешь в иерархию и чем отличается Actor от Pawn'а — тогда уже можно начинать в код идти. Постоянно обращайтесь к проектам — примерам, в них очень много полезного. Даже простые бабочки, которые используются для окружения имеют весьма навороченную систему взаимодействия с окружающей средой и поведение.
Пожалуй самой страшной проблемой для нас была работа с UMG, потому что мы начали использовать его прямо сразу как он появился в прототипизированном виде с 4.3. До 4.6 по всей видимости у них в UMG произошло множество изменений и у нас всё пришло к тому, что любое изменение в любом виджете, при компиляции, приводило к падению UE4.
В остальном, примерно раз в 2 версии, происходят архитектурные изменения и приходится что-то менять, но это занимает крайне мало времени, Epic в этом плане работают на совесть. Ну а что до UMG, то тут конечно проблема в наследии с первых версий.
В 4.7 версии скорость сборки очень хорошо подняли. Конечно всё зависит от размера проекта. Зато используется всё нативное. Мы пока что в этом не ощутили проблемы. Прототип собирался полностью за минуту где-то. И это до оптимизации, с ним мы работали в 4.6 ещё.
Кстати, исходники сейчас распространяют вместе с бинарным вариантом UE4. С версии 4.7.3 насколько я помню. В любой момент можно смотреть исходники и не обязательно работать с github.
Помнится по первости я написал логику сближения корабля с точкой назначения, путём постепенного снижения скорости и продолжения движения к точке — эдакое равномерное падение на точку назначения. В blueprint'ах это заняло три экрана, в коде — 10 строк. Наглядности в них мало. Только для небольших задач.
Вообще не видно никакой необходимости. Тот же AI прекрасно идёт через встроенные Blackboard'ы и немного кода.
Именно. Мы blueprint оставили только для проектирования интерфейсов через UMG, и то их максимально в код заворачиваем. А также шейдеры. Кстати, они уже не считаются blueprint'ами, лишь визуально сходится процесс разработки.
Подводя итоги прототипа, мы сделали вывод, что blueprint'ы хороши только для простеньких игр и несложных операций. Если вы хотите часть игр писать в C++, то лучше всё максимально уносить в код. К тому же через blueprint'ы написать свой movement component — это no way.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Инженер по автоматизации тестирования, Инженер по производительности
Ведущий
От 500 000 ₽