Извиняюсь, еще раз прошелся по ссылкам и не нашел каких-то результатов использования survival analysis для предсказания увольнения сотрудников.
Посмотрел на Watson Analytics Use Case for HR: Retaining valuable employees, там ставилась совсем другая задача — выделить драйверы аттришина:
one of my tasks is to determine which factors keep employees at my company and which prompt others to leave
Автор выделил 10 значимых факторов.
У Вас же совсем другая формулировка:
создание модели, прогнозирующей уход сотрудников с заданной точностью (не менее 75-80%)
Про survival analysis люди, касающиеся темы HR даже не слышали. А применение его более оправданно, чем параметризованная классификация.
А этому утверждению есть какое-то подтверждение?
Чтобы я сказал по графику (на уровне гипотез):
30-32 месяца назад в компании были массовые сокращения (или народ начал массово перетекать к конкурентам);
последние 10 месяцев в компании идут сокращения (либо все активно перетекают к конкурентам);
я вовсе не уверен, что при принятии решений о сокращении главным фактором являются переработки (скорее должность или специальность).
Применим ли в этих условиях survival analysis? У пенсионеров гораздо меньше возможностей повлиять на ситуацию, чем у работников или руководителей конкретного предприятия. Отдельная компания гораздо менее устойчива, чем экономика государства, динамика гораздо выше.
Может стоит обратить внимание на подготовку данных для анализа, а не выбор модели?
Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
На самом деле, в статье очень много анти-паттернов управления продуктами и проектами.
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
И за что минусуете человека? Имеете опыт безболезненного переписывания драйверов под Vista? В статье же не зря упоминаются судебные процессы — очень похоже было на зачистку поля под Security Essentials.
Очень полезный экскурс в историю и отличный перевод!
Не имею отношения к MS, но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
Амбициозные планы, от которых отваливаются громадные куски на 2-м или 3-м году…
Промежуточные релизы текущих версий, на которые оттягивается половина команды…
Интеграция, требующая в 3-е больше ресурсов, чем разработка…
Процедура апдейта и миграции данных пишется в последний момент…
Впихивание мега-фич ближе к концу (все равно уж опаздываем)…
Ностальгия :-)
Как раз фейлы таких мега-проектов и способствовали развитию Agile — они объективно перестали срастаться.
Я бы пошел во вторую — выстраивать процессы.
А разработчикам посоветовал бы идти в первую. Т.к. по моим внутренним убеждениям, при прочих равных она выиграет в долгосрочной перспективе. Технический долг сказывается на дистанции, я бы предположил, что во второй команде он выше.
Предлагаю сходу не слушать Scrum консультантов и прочих паразитирующих на профессии людей
На всякий случай, я не отношусь к консультантам, но понимаю, как они позволяют экономить время и деньги, избегая «детских» ошибок и разочарования (конечно, речь идет о достойных).
Если Ваша компания готова спонсировать эксперименты по внедрению Скрама своими силами (или любые другие) — отлично!
Много знаете спортсменов-профессионалов, которые обходятся без тренера? А любители вполне себе могут.
P.S.
Видео и в самом деле интересное, спасибо за ссылку.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама.
Отлично, если Вы ее достигли (с точки зрения читателей).
Я просто обозначил свой интерес и обратил внимание на пару моментов:
1. Ваша интерпретация Скрама отличается от канонической версии (которая изложена в Скрам Гайде). Это включает понимание ролей и взаимодействия между ними в Скрам-команде.
2. Большое внимание уделено тому, как «продать» Скрам менеджменту, но очень мало внимание уделяется команде (только про преодоление сопротивления). Если проблемы, обозначенные в начале, были решены, команда должна быть счастлива. Разве нет?
В первой наделал много ошибок, потом исправлял, набил шишки. Во второй, где работаю по сей день, внедрил скрам вполне успешно...
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать. С моей точки зрения, было бы гораздо интереснее и полезнее.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Можно ссылочку на такого рода исследования?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
У меня нет оснований сомневаться, что Вы успешно внедрили скрам в своей компании.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики. Вероятно, у них тоже не зашел vanilla-scrum… Но наверняка есть все ритуалы, чтобы считать скрам внедренным.
Признаться, я не по почувствовал, что это личный опыт — больше похоже на конспект книги или тренинга.
В небольших компаниях(до 50 человек) я предпочитаю идти вплоть до директора.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
скрам-мастер — это менеджер
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
И на одном из стендапов этот техлид заявляет, что он занимается задачей с низким приоритетом, хотя по доске видно, что есть задачи и поважнее в спринте. Согласно правилам, вы должны попросить его переключиться на более приоритетную задачу.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
К сожалению, у меня нет MS Project на домашнем ноутбуке и нет желания его ставить только для того, чтобы посмотреть на этот проект.
Поэтому сужу только по картинкам.
Да, согласен, что вопрос был не о бюджете проекта, а ФОТ на разработку.
Мое мнение, что выделенный прожект менеджер на команду такого размера — избыточен.
Я бы сказал, что максимум он должен быть утилизирован на четверть (если у него ставка на уровне ведущего разработчика).
Если предполагать, что во время «простоев» люди заняты на других проектах, то возникают «паразитные зависимости» между проектами и переключения контекста.
По сути, нарушается ограничение Work in progress для команды.
Там погрешность в 10% уже становится существенной (скажем, +10% на фазу разработки в одном проекте, -10% во втором, и фазы тестирования в них наложились; или на оборот — фазы разбежались и тестировщики простаивают).
Синхронизовать несколько параллельных проектов, особенно если у каждого из них свой менеджер, гораздо более творческая задача, чем оптимизировать загрузку на одном так, чтобы сократить общее время проекта и снизить накладные расходы.
Я не спорю, возможно кому-то этот темплейт проектного плана и принесет пользу (благо в самом начале четко описан контекст). Просто обращаю внимание на то, что я пытался бы оптимизировать.
Я правильно понимаю, что на прожект менеджера уходит примерно треть бюджета проекта?
При том, что риски проекта 10% — т.е. он достаточно линейный и корректирующих действий особо не требуется?
Фазы проектов не пересекаются (скажем, составление и ревью тест-планов/ПМИ может идти параллельно с разработкой при наличии спецификаций).
Т.е. план не оптимален с точки зрения загрузки ресурсов и сроков поставки, а значит и бюджета проекта.
Автор статьи тоже ценит своих сотрудников, и поэтому не делает контр-офферов.
При работающих механизмах оценки и пересмотра компенсаций, зарплаты команд находятся в равновесном состоянии — т.е. соответствуют «пользе», которую приносят сотрудники.
Оффер на большую з.п. — это может быть не рынок, а аномалия (ну вот не получит Ася такое предложение от любых других компаний, только здесь и сейчас).
Повышая Асе зарплату, мы выводим систему из равновесия — несправедливость по отношению к команде.
Был у меня такой случай.
Собеседовали кандидата, сделали оффер, но он остался на старом месте — зарплату повысили заметно. А через 3 месяца платить перестали — у компании деньги кончились. Это рынок или демпинг?
Не имею отношения к Яндексу и не знаю его внутренней «кухни», но предполагаю (экстраполируя другие крупные комании):
— зарплаты всех сотрудников пересматриваются минимум раз в год (не всем повышают, но обсуждают со всеми);
— кроме зарплаты компании есть что предложить сотруднику (бренд, стабильность, не декларативная, а реальная возможность обучения, развития и карьерного роста и т.п.).
Т.ч. думаю, что с учетом всех факторов Яндекс платит справедливые (т.е. рыночные, а не максимальные) зарплаты сотрудникам. И даже если кого-то берут по «двойному тарифу» то через пару лет оно приходит в равновесие с остальными сотрудниками.
Неужели другое отношение где-то сильно распространено?
Да, в компаниях со зрелыми процессами оценки персонала может быть даже двойной контроль:
Раз в 6-12 месяцев руководитель спрашивает напрямую о желаемом размере компенсации
Анонимный опрос сотрудников о возможных причинах ухода из компании
Конечно, речь о рынке труда с высокой конкуретностью и достаточно крупных компаниях (скажем, IT компания в Москве с достаточным ФОТ от 100 человек). Иногда предлагают сток-опции вместо зарплаты (но это, опять же, компенсационный пакет).
В противном случае так и бывает — повышение зарплаты через контр-офферы («чел получал 600, написал заяву, ему предложили 800»).
Я полностью согласен с основной мыслью статьи: в компаниях с конкурентными зарплатами, грамотными пипл-менеджерами, зрелыми процессами оценки персонала и моделью компенсации, привязанной к этой оценке и анализу рынка труда (приоритеты каждый расставит самостоятельно) необходимость контр-офферов возникает редко.
Есть ровно один вопрос — если вы готовы хантить по «двойным тарифам», почему зазорно противодействовать такому хантигу? Петю все устраивало, пока ему не предложили +25% к зарплате. Отпустим и схантим Васю за +50%?
Скажите, пожалуйста, а в курсе есть какая-то специфика именно для команд разработки?
Или это просто универсальный курс «Руководитель», который позиционируется для определенной аудитории?
Спасибо!
А почему вообще было принято решение организовать одну распределенную команду, а не 2 несвязанные?
Кто (или что) мешает разделить зоны ответственности и отпустить каждую из команд в автономное плавание? Если нет потребности во взаимодействии, то и регулярные коммуникации перестают быть необходимыми.
Я наблюдал скрам-команды, которые были не только кросс-функциональными, но и кросс-региональными. И мне они не показались особо эффективными, в первую очередь, по причине отсутствия командного духа и взаимопомощи. Я бы предпочел «распилить» команды по локациям.
Продаж чего и в каком сегменте?
Если холодные звонки так важны, почему их часто отдают на аутсорсинг или вообще используют ботов?
Массовые продажи не только в ларьках, но и в интернете вполне себе обходятся без холодных звонков — слишком дорогой инструмент для розницы со сделками на небольшие суммы.
Во в целом, это офф-топик к вопросу KPI, не говоря уж про саму статью.
Посмотрел на Watson Analytics Use Case for HR: Retaining valuable employees, там ставилась совсем другая задача — выделить драйверы аттришина:
Автор выделил 10 значимых факторов.
У Вас же совсем другая формулировка:
.
Я просто не улавливаю связи.
А этому утверждению есть какое-то подтверждение?
Чтобы я сказал по графику (на уровне гипотез):
Применим ли в этих условиях survival analysis? У пенсионеров гораздо меньше возможностей повлиять на ситуацию, чем у работников или руководителей конкретного предприятия. Отдельная компания гораздо менее устойчива, чем экономика государства, динамика гораздо выше.
Может стоит обратить внимание на подготовку данных для анализа, а не выбор модели?
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
Не имею отношения к MS, но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
Амбициозные планы, от которых отваливаются громадные куски на 2-м или 3-м году…
Промежуточные релизы текущих версий, на которые оттягивается половина команды…
Интеграция, требующая в 3-е больше ресурсов, чем разработка…
Процедура апдейта и миграции данных пишется в последний момент…
Впихивание мега-фич ближе к концу (все равно уж опаздываем)…
Ностальгия :-)
Как раз фейлы таких мега-проектов и способствовали развитию Agile — они объективно перестали срастаться.
А разработчикам посоветовал бы идти в первую. Т.к. по моим внутренним убеждениям, при прочих равных она выиграет в долгосрочной перспективе. Технический долг сказывается на дистанции, я бы предположил, что во второй команде он выше.
На всякий случай, я не отношусь к консультантам, но понимаю, как они позволяют экономить время и деньги, избегая «детских» ошибок и разочарования (конечно, речь идет о достойных).
Если Ваша компания готова спонсировать эксперименты по внедрению Скрама своими силами (или любые другие) — отлично!
Много знаете спортсменов-профессионалов, которые обходятся без тренера? А любители вполне себе могут.
P.S.
Видео и в самом деле интересное, спасибо за ссылку.
Отлично, если Вы ее достигли (с точки зрения читателей).
Я просто обозначил свой интерес и обратил внимание на пару моментов:
1. Ваша интерпретация Скрама отличается от канонической версии (которая изложена в Скрам Гайде). Это включает понимание ролей и взаимодействия между ними в Скрам-команде.
2. Большое внимание уделено тому, как «продать» Скрам менеджменту, но очень мало внимание уделяется команде (только про преодоление сопротивления). Если проблемы, обозначенные в начале, были решены, команда должна быть счастлива. Разве нет?
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать. С моей точки зрения, было бы гораздо интереснее и полезнее.
Можно ссылочку на такого рода исследования?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
У меня нет оснований сомневаться, что Вы успешно внедрили скрам в своей компании.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики. Вероятно, у них тоже не зашел vanilla-scrum… Но наверняка есть все ритуалы, чтобы считать скрам внедренным.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
Поэтому сужу только по картинкам.
Да, согласен, что вопрос был не о бюджете проекта, а ФОТ на разработку.
Мое мнение, что выделенный прожект менеджер на команду такого размера — избыточен.
Я бы сказал, что максимум он должен быть утилизирован на четверть (если у него ставка на уровне ведущего разработчика).
Если предполагать, что во время «простоев» люди заняты на других проектах, то возникают «паразитные зависимости» между проектами и переключения контекста.
По сути, нарушается ограничение Work in progress для команды.
Там погрешность в 10% уже становится существенной (скажем, +10% на фазу разработки в одном проекте, -10% во втором, и фазы тестирования в них наложились; или на оборот — фазы разбежались и тестировщики простаивают).
Синхронизовать несколько параллельных проектов, особенно если у каждого из них свой менеджер, гораздо более творческая задача, чем оптимизировать загрузку на одном так, чтобы сократить общее время проекта и снизить накладные расходы.
Я не спорю, возможно кому-то этот темплейт проектного плана и принесет пользу (благо в самом начале четко описан контекст). Просто обращаю внимание на то, что я пытался бы оптимизировать.
При том, что риски проекта 10% — т.е. он достаточно линейный и корректирующих действий особо не требуется?
Фазы проектов не пересекаются (скажем, составление и ревью тест-планов/ПМИ может идти параллельно с разработкой при наличии спецификаций).
Т.е. план не оптимален с точки зрения загрузки ресурсов и сроков поставки, а значит и бюджета проекта.
При работающих механизмах оценки и пересмотра компенсаций, зарплаты команд находятся в равновесном состоянии — т.е. соответствуют «пользе», которую приносят сотрудники.
Оффер на большую з.п. — это может быть не рынок, а аномалия (ну вот не получит Ася такое предложение от любых других компаний, только здесь и сейчас).
Повышая Асе зарплату, мы выводим систему из равновесия — несправедливость по отношению к команде.
Был у меня такой случай.
Собеседовали кандидата, сделали оффер, но он остался на старом месте — зарплату повысили заметно. А через 3 месяца платить перестали — у компании деньги кончились. Это рынок или демпинг?
— зарплаты всех сотрудников пересматриваются минимум раз в год (не всем повышают, но обсуждают со всеми);
— кроме зарплаты компании есть что предложить сотруднику (бренд, стабильность, не декларативная, а реальная возможность обучения, развития и карьерного роста и т.п.).
Т.ч. думаю, что с учетом всех факторов Яндекс платит справедливые (т.е. рыночные, а не максимальные) зарплаты сотрудникам. И даже если кого-то берут по «двойному тарифу» то через пару лет оно приходит в равновесие с остальными сотрудниками.
Да, в компаниях со зрелыми процессами оценки персонала может быть даже двойной контроль:
Конечно, речь о рынке труда с высокой конкуретностью и достаточно крупных компаниях (скажем, IT компания в Москве с достаточным ФОТ от 100 человек). Иногда предлагают сток-опции вместо зарплаты (но это, опять же, компенсационный пакет).
В противном случае так и бывает — повышение зарплаты через контр-офферы («чел получал 600, написал заяву, ему предложили 800»).
Есть ровно один вопрос — если вы готовы хантить по «двойным тарифам», почему зазорно противодействовать такому хантигу? Петю все устраивало, пока ему не предложили +25% к зарплате. Отпустим и схантим Васю за +50%?
Или это просто универсальный курс «Руководитель», который позиционируется для определенной аудитории?
Спасибо!
А почему вообще было принято решение организовать одну распределенную команду, а не 2 несвязанные?
Кто (или что) мешает разделить зоны ответственности и отпустить каждую из команд в автономное плавание? Если нет потребности во взаимодействии, то и регулярные коммуникации перестают быть необходимыми.
Я наблюдал скрам-команды, которые были не только кросс-функциональными, но и кросс-региональными. И мне они не показались особо эффективными, в первую очередь, по причине отсутствия командного духа и взаимопомощи. Я бы предпочел «распилить» команды по локациям.
Продаж чего и в каком сегменте?
Если холодные звонки так важны, почему их часто отдают на аутсорсинг или вообще используют ботов?
Массовые продажи не только в ларьках, но и в интернете вполне себе обходятся без холодных звонков — слишком дорогой инструмент для розницы со сделками на небольшие суммы.
Во в целом, это офф-топик к вопросу KPI, не говоря уж про саму статью.