Я не работаю в Касперском. Цифры привёл из того же калькулятора зарплат Хабр Карьера.
И потом, это лишь один пример. Там же можно найти и другие компании, сотрудники которых получают большие зарплаты, но при этом эти фирмы не присутствуют в "чарте".
Интересно, как составлялся "рейтинг" самых щедрых на зарплаты компаний? В него явно не все попали - просто как пример: Лаборатория Касперского отсутствует, хотя средняя з/п выше 300тыс/мес.
Работодателям сейчас сложно объективно оценивать умения соискателей.
Мы хотели повысить доверие к нашей базе со стороны работодателей. Сейчас, с появлением AI-инструментов, проблема стоит особенно остро.
Во-первых, в тесты вшита антифрод-система, которая мешает это сделать. Во-вторых, даже если её обойти, работодатель всё равно поймёт, что соискатель умеет на самом деле.
Получается, что начитирить всё же можно? И какой тогда прок работодателям от такого инструмента, если всё равно им самим придётся проверять навыки кандидатов?
Дело не только в роли в коллективе, но ещё и типе деятельности. Судя по всему, в статье упор на продуктовой разработке или поддержке системы. Ведь на старте нового проекта обычно вообще мало что понятно - и тут не столь важно, новичок ты в компании или работаешь в ней десяток лет.
Мы пришли к выводу, что ИТ‑шник, который каждый год меняет свое место работы, по факту не может создать себе комфортное рабочее пространство и наладить взаимоотношения коллегами по работе.
Такой вывод сделан с опорой на печальную статистику найма сотрудников в вашу компанию? В начале статьи слишком кратко упомянуто про "собственный опыт и знакомых тимлидов", но не уточняется их место работы по отношению к автору. В общем, не хватает конкретных кейсов, чтобы можно было поверить, понять или даже посочувствовать.
Изменение требований это естественный процесс. Куда сложнее ситуация, когда изначально упущены принципиальные хотелки. Причём пожелания заказчика это лишь часть того, что должно быть учтено в процессе выявления требований: ведь в проекте обычно задействованы различные заинтересованные лица, и анализ этих групп обычно выполняется на первичном этапе работ по созданию решения.
Аналитик часто неосознанно, а иногда и осознанно, может выполнять функции проектного менеджера (руководителя проекта). Почему так происходит?
Истинных причин скорее лишь две: 1 - потому что работодатель решил оптимизировать проектную команду сэкономить на ФОТ, 2 - аналитику предложили точку роста в другую роль впихнули обязанности, не обговоренные на собеседовании. Другие мотивы лишь для ширмы. Впрочем, сотрудник действительно может воспользоваться ситуацией, но при этом никак не должен.
Применимо прежде всего для заказной или внутренней разработки. Когда необходимо создавать или дорабатывать продукт, то нужны другие подходы для выявления требований - генерация и валидация гипотез вместе с PO, изучение систем конкурентов, анализ поведения пользователей...
Ситуация схожа с применением ин.яза: можно таскать с собой переводчика, а можно выучить самому на хорошем уровне и не быть зависимым от другого человека или технических средств.
Да какая разница, каким способом написана статья? Если в ней мало пользы (солянка из нескольких случайно выбранных сложностей в работе аналитика), то как она появилась на свет, уже не принципиально.
Дело не в желании потешить самолюбие, а банальном отсутствии понимания, как правильно проводить собеседование. Поэтому обычно и задают груду теоретических вопросов, которые не выявляют опыт и не раскрывают потенциал к решению практических задач.
Верно подмечено! Не хватает анализа корреляции от предметной области, вида системы и ключевых задач. Но видимо, такая информация не собиралась. Хотя приписка, что опрос проводился в группах финтех-компаний отчасти объясняет полученную картину.
Видимо, это как раз те команды (см. первую таблицу), где уже есть сотрудники, которые просто пересказывают слова заказчика, потому что не смогли разобраться в предметной области, и тем самым увеличивают сроки и стоимость разработки.
Как по мне, так "самое ненавистное" в работе аналитика - знать, что твой коллега когда-то не оформил требования/постановку должным образом; и теперь ты должен тратить своё и его время (а часто ещё и других участников проекта) на восстановление этих знаний.
Я не работаю в Касперском. Цифры привёл из того же калькулятора зарплат Хабр Карьера.
И потом, это лишь один пример. Там же можно найти и другие компании, сотрудники которых получают большие зарплаты, но при этом эти фирмы не присутствуют в "чарте".
Интересно, как составлялся "рейтинг" самых щедрых на зарплаты компаний? В него явно не все попали - просто как пример: Лаборатория Касперского отсутствует, хотя средняя з/п выше 300тыс/мес.
Работодателям сейчас сложно объективно оценивать умения соискателей.Мы хотели повысить доверие к нашей базе со стороны работодателей. Сейчас, с появлением AI-инструментов, проблема стоит особенно остро.Во-первых, в тесты вшита антифрод-система, которая мешает это сделать. Во-вторых, даже если её обойти, работодатель всё равно поймёт, что соискатель умеет на самом деле.Получается, что начитирить всё же можно? И какой тогда прок работодателям от такого инструмента, если всё равно им самим придётся проверять навыки кандидатов?
В новостях пишут, что Google вернулся к практике очных собеседований. Ох, скучаю по тем временам!
Исследования показывают: большинство IT-специалистов попадают во вторую зону, что неизбежно ведёт к выгоранию.Исследования говорят: микрообучение круче интенсивов.Множество исследований доказывают: принцип «медленно, но верно» работает лучше героических рывков.После таких статей грех жаловаться на "произведения" от ГПТ: тот хотя бы ссылки на первоисточники выдаёт.
Дело не только в роли в коллективе, но ещё и типе деятельности. Судя по всему, в статье упор на продуктовой разработке или поддержке системы. Ведь на старте нового проекта обычно вообще мало что понятно - и тут не столь важно, новичок ты в компании или работаешь в ней десяток лет.
Мы пришли к выводу, что ИТ‑шник, который каждый год меняет свое место работы, по факту не может создать себе комфортное рабочее пространство и наладить взаимоотношения коллегами по работе.Такой вывод сделан с опорой на печальную статистику найма сотрудников в вашу компанию? В начале статьи слишком кратко упомянуто про "собственный опыт и знакомых тимлидов", но не уточняется их место работы по отношению к автору. В общем, не хватает конкретных кейсов, чтобы можно было поверить, понять или даже посочувствовать.
Изменение требований это естественный процесс. Куда сложнее ситуация, когда изначально упущены принципиальные хотелки. Причём пожелания заказчика это лишь часть того, что должно быть учтено в процессе выявления требований: ведь в проекте обычно задействованы различные заинтересованные лица, и анализ этих групп обычно выполняется на первичном этапе работ по созданию решения.
Аналитик часто неосознанно, а иногда и осознанно, может выполнять функции проектного менеджера (руководителя проекта). Почему так происходит?Истинных причин скорее лишь две: 1 - потому что работодатель решил
оптимизировать проектную командусэкономить на ФОТ, 2 - аналитикупредложили точку роста в другую рольвпихнули обязанности, не обговоренные на собеседовании. Другие мотивы лишь для ширмы. Впрочем, сотрудник действительно может воспользоваться ситуацией, но при этом никак не должен.Применимо прежде всего для заказной или внутренней разработки. Когда необходимо создавать или дорабатывать продукт, то нужны другие подходы для выявления требований - генерация и валидация гипотез вместе с PO, изучение систем конкурентов, анализ поведения пользователей...
Ситуация схожа с применением ин.яза: можно таскать с собой переводчика, а можно выучить самому на хорошем уровне и не быть зависимым от другого человека или технических средств.
Да какая разница, каким способом написана статья? Если в ней мало пользы (солянка из нескольких случайно выбранных сложностей в работе аналитика), то как она появилась на свет, уже не принципиально.
В российских современных ЖК так же делают. Но учитывая общее качество строительных работ, лично я решил всё же кинуть трубку до канализации.
Дело не в желании потешить самолюбие, а банальном отсутствии понимания, как правильно проводить собеседование. Поэтому обычно и задают груду теоретических вопросов, которые не выявляют опыт и не раскрывают потенциал к решению практических задач.
Верно подмечено! Не хватает анализа корреляции от предметной области, вида системы и ключевых задач. Но видимо, такая информация не собиралась. Хотя приписка, что опрос проводился в группах финтех-компаний отчасти объясняет полученную картину.
Видимо, это как раз те команды (см. первую таблицу), где уже есть сотрудники, которые просто пересказывают слова заказчика, потому что не смогли разобраться в предметной области, и тем самым увеличивают сроки и стоимость разработки.
Оставьте в покое уже тему с Use Cases! Технике более 20 лет, но нет - аналитики продолжают про неё рассказывать, будто это что-то невиданное.
SMART не методология, а техника постановки целей или задач. Применяйте инструмент по назначению, и не будет возникать вопрос "Почему оно не работает?"
Как по мне, так "самое ненавистное" в работе аналитика - знать, что твой коллега когда-то не оформил требования/постановку должным образом; и теперь ты должен тратить своё и его время (а часто ещё и других участников проекта) на восстановление этих знаний.
Минтруда с вами не согласно https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=126779