Відчуваю усю боль через текст :) Дякую за розгорнутий команетар
Дякую! Хто знає, може і напишу подалі. Хочу додати статей до нашої спільноти!
Так я же в статті вказував номер релізу :) Даже у прикладах є. Інші пунктики — гарні доповнювання.
Вітання та дякую за питання. З мого досвіду, майже завжди, якщо немає можливості відтворити, то, швидше за все, просто ще не знайшли спосіб. Інакше, то швидше за все якийсь збіг випадковостей, котрий і користувач відтворити не зможе. Але я не вірю в випадковості в IT, то моя порада, якщо ви в глухому куті і не знаєте, як бути далі з відтворенням, а ваше професійне чуття підказує, що проблема є, то найвірнішим способом буде попросити допомоги у розробника цієї частини функціоналу. Описати ситуацію, з якою ви зіткнулися, показати лог та описати що коїлось з продуктом у цей час запису у логах, та запитати куди ще подивитися і покопати, щоб дістатися до істини, та відтворити цей дефект
а я ось посмію не погодиться. Допустимо самарі не вистачило, то тоді, якщо все грамотно описати, вистачить найчастіше AB щоб відтворити, і EB щоб зрозуміти, як потрібно бути. А кроки по відтворенню, це швидше для складних і заплутаних кейсів, або для джуників які ще не так поглунили у проект.
Anyway, порядок цих полів може бути таким яким це зручно усім членам команди, це не є правилом. На мою думку порядок ціх полів не є таким принциповим, щоб за нього сперечатись. Пишить як це зручно для проекту і як це історично склалось :)
Дякую за коментар. Радий, що доповідь сподобалась. Фібек це завжди домога наступним статтям :) За перевірка на дублікат «Шукай перед тим як створити новий» тисну руку, колега. А ось з іншими пунктами не можу не погодатись, а ні оскаржити, бо вони дуже залежні від проекту та процесів на ньому.
Чого тільку не буває, хтось міг дістатись у спадок, когось перевели до команди та погано співбесідували на вході. Наше завдання виправити помилки та виховати грамотних інженерів
Абсолютно верно. Я об этом указала в статье и причины такого решения :)
Спасибо большое, рад что статья нашла отклик.
По вопросам:
1) Первое — attrition и tenure два разных показателя:
Overall это выглядит примерно так:
Attrition = dismissed / average headcount
Tenure = average working period before dismissing
Не смотря на то, что оба показателя касаются увольнений, говорят они совершенно о разном. Attrition дает понять насколько компания способна к росту с текущим уровнем увольнений. Можно много нанимать, когда в компании много увольнений, при этом Attrition держать на относительно низком уровне. Но большой найм никак не отменяет увольнения.
Tenure в свою очередь говорит о среднем стаже работы в компании тех людей, кто уже уволился. Если все компании его считают одним способом, то большой Tenure может говорить как о низком количестве увольнений в компании, так и о том что из компании уходят преимущественно «старички».
Из тех чисел, которыми я могу поделиться касательно DataArt, то у нас например больше трети коллег с нами 3 и больше лет (при том, что компания выросла за год практически в два раза), и больше половины из этих ребят сеньеры или выше.
2) По моим личным наблюдениям, чем выше у человека квалификация, тем реже причина ухода именно ЗП.
3) Стоимость найма и привлечения нового сотрудника я раскрыть не могу, это внутренняя информация.
Сори за долгий срок ответа, но война в стране не способствовала возможности посещать DOU чаще
Чуть другой вариант анкетирования даем и в таком случае, я себе добавляю цель объяснить коллеге причины почему именно было принято такое решение. Поднятый вами поинт крайне важен на самом деле, потому что, если коллега не понимает причин окончания сотрудничества с ним это может привести к странным трактовкам в дальнейшем. У DataArt в этом плане хорошая позиция, так как мы всегда даем второй, а иногда и третий шанс коллегам и всегда доносим фидбек по такой ситуации, чтобы потом не получился «сюрприз» для коллеги.
Мне очень жаль, что в нашей сфере тоже такие истории летают. Хочется верить, что хоть тут все как-то человечней, но видимо не всегда
Мне кажется вы потеряли нить разговора, я попробую помочь, поправьте пожалуйста, если я ошибаюсь. Проблем для ухода потенциального может быть миллион, компенсация лишь один из возможных вариантов. Сидеть о них помалкивать последнее дело, как по мне. Если вы считаете, что это правильно — ваш выбор. Если вам безразличны коллеги, с которыми вы работали в проекте, офисе и компании — ваш выбор. Если вы считаете, что высказать свое мнение по неустраивающим вас проблемам — это «прощальны подарок», который вы делать не хотите — ваш выбор :) Я же только благодарен, что со мною работают коллеги, которые рады поделиться своими мыслями, которые рады указать на узкие места и которые даже после ухода с компании со мной и другими коллегами в отличных отношениях. Каждый дает миру и получает обратно по вложенным усилиям. Кто-то «ушат правды» на спецресурах, кто-то взаимопомощь и взаимовыручку.
Спасибо за мнение. Мне кажется это инструмент, который в любом случае при правильном использовании и подходе принесет пользу и не будет «лишь формальностью». Вопрос обработки результатов — подходов к обработке полученных данных в ходе любого сбора информации существует масса, тут советов не даю, так как это уже совсем другая история. Но, кстати, про необходимость обрабатывать эти результаты я в любом случае упомянул :)
Ни в жизнь. Встречи с коллегами, постоянные HR-синки с моим личным присутствием и 1-2-1 c коллегами вне моего офиса, но с моего проекта — моя прямя обязанность. Эти встречи и Exit review это не замена друг другу и разные вещи
Exit interview никоим образом не отменяет сбор постоянного фидбека от других коллег. Для меня лично, это все же разные инструменты. К теме же самого процесса такого интервью, тут каждый волен сделать его более удобным под свои нужды
Рад, что таких мнений не много и чаще ребята куда более дружелюбны к коллегам
Слышал про подобную практику, мы такое не приветствуем. Более того, лично работал с людьми с подобных списков от других компаний и на деле оказывались отличные ребята. Считаю всегда надо проверять подобные отзывы
достойно уважения :) мое почтение QA инженеру